Политика секционирования

Область применения: ✅Microsoft Fabric✅Azure Data Explorer

Политика секционирования определяет, следует ли секционировать экстенты (сегменты данных) для определенной таблицы или материализованного представления.

Политика активирует дополнительный фоновый процесс, который происходит после создания экстентов после приема данных. Этот процесс включает повторное получение данных из исходных экстентов и создание однородных экстентов, в которых все значения столбца, указанного в качестве ключа секции, находятся в одной секции.

Основная цель политики секционирования — повысить производительность запросов в определенных поддерживаемых сценариях.

Поддерживаемые сценарии

Ниже приведены единственные сценарии, в которых рекомендуется задать политику секционирования данных. Во всех остальных сценариях установка политики не рекомендуется.

• Частые фильтры на средней или высокой кратности string или guid столбце:
  • Например: мультитенантные решения или таблица метрик, в которой большинство или все запросы фильтруют по столбцу типа string или , напримерTenantId, или MetricIdguid.
  • Средняя кратность составляет не менее 10 000 различных значений.
  • Задайте для ключа string хэш-секции значение или guid столбец и задайте PartitionAssignmentMode для свойства значение uniform.
• Частые агрегаты или соединения на высоком кратности string или guid столбце:
  • Например, данные Интернета вещей из множества различных датчиков или академических записей многих разных учащихся.
  • Высокая кратность составляет не менее 1000 000 различных значений, где распределение значений в столбце приблизительно равно.
  • В этом случае задайте для ключа хэш-секции столбец, который часто группируется по или присоединениюPartitionAssignmentMode, и задайте для свойства значение ByPartition.
• Прием данных вне порядка:
  • Данные, используемые в таблицу, не могут быть упорядочены и секционированы в экстенты (сегменты) в соответствии с определенным datetime столбцом, который представляет время создания данных и обычно используется для фильтрации данных. Это может быть связано с обратным заполнением из разнородных исходных файлов, которые включают значения даты и времени в течение большого периода времени.
  • В этом случае задайте для столбца ключ секции с универсальным диапазоном datetime даты и времени.
  • Если необходимо, чтобы политики хранения и кэширования соответствовали значениям даты и времени в столбце, вместо выравнивания по времени приема задайте OverrideCreationTime для свойства значение true.

Ключи секции

Поддерживаются следующие типы ключей секций.

Хэш-ключ секции

Если политика включает хэш-ключ секции, все однородные экстенты, принадлежащие одной секции, будут назначены одному узлу данных.

• Функция хэш-модулирования используется для секционирования данных.
• Данные в однородных (секционированных) экстентах упорядочивается ключом хэш-секции.
  • Не нужно включать хэш-ключ секции в политику порядка строк, если он определен в таблице.
• Ожидается, что запросы, использующие стратегию перетасовки, и в которой shuffle key используется joinsummarize хэш-ключ секции таблицы или make-series хэш-ключ таблицы, будут выполняться лучше, так как объем данных, необходимых для перемещения по узлам, уменьшается.

Свойства секционирования

Пример ключа хэш-раздела

Хэш-ключ секции по имени столбца stringс типизированным именем tenant_id. Он использует хэш-функцию, присвоив MaxPartitionCount рекомендуемое значение 128и значение по умолчанию Seed 1.XxHash64

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Ключ секции даты и времени единого диапазона

В этих случаях можно перенашифровать данные между экстентами, чтобы каждый экстент включает записи из ограниченного диапазона времени. Этот процесс приводит к тому, что фильтры столбца datetime более эффективны во время запроса.

Функция секционирования используется bin_at() и не настраивается.

Свойства секционирования

Пример секции datetime с универсальным диапазоном

В фрагменте кода показан ключ секции диапазона даты и времени по типизированному столбцу datetime timestamp. Она используется datetime(2021-01-01) в качестве эталонной точки с размером 7d для каждой секции и не переопределяет время создания экстентов.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

Объект политики

По умолчанию политика секционирования данных таблицы — nullэто политика, в которой данные в таблице не будут повторно разделены после приема.

Политика секционирования данных имеет следующие основные свойства:

• PartitionKeys:

  • Коллекция ключей секций, определяющих, как секционировать данные в таблице.
  • Таблица может иметь до 2 секционирования ключей с одним из следующих вариантов:
    • Один хэш-ключ секции.
    • Один ключ секции datetime с универсальным диапазоном.
    • Один хэш-ключ секции и один ключ секции даты и времени единого диапазона.
  • Каждый ключ секции имеет следующие свойства:
    • ColumnName: string — имя столбца, по которому будут секционированы данные.
    • Kind: string — тип секционирования данных для применения (Hash или UniformRange).
    • Properties: property bag — определяет параметры, в соответствии с которым выполняется секционирование.

• EffectiveDateTime:

  • Дата и время в формате UTC, с которого действует политика.
  • Это необязательное свойство. Если он не указан, политика вступит в силу для приема данных после применения политики.

Пример секционирования данных

Объект политики секционирования данных с двумя ключами секционирования.

1. Хэш-ключ секции по имени столбца stringс типизированным именем tenant_id.
   • Он использует хэш-функцию, присвоив MaxPartitionCount рекомендуемое значение 128и значение по умолчанию Seed 1.XxHash64
2. Универсальный ключ секции диапазона дат и времени по столбцу datetime типа с именем timestamp.
   • Она используется datetime(2021-01-01) в качестве эталонной точки с размером для каждой 7d секции.

{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

Дополнительные свойства

Следующие свойства можно определить как часть политики. Эти свойства являются необязательными, поэтому мы рекомендуем не изменять их.

Процесс секционирования данных

• Секционирование данных выполняется как фоновый процесс после приема данных.
  • Ожидается, что таблица, в которую постоянно выполняется прием, всегда имеет "хвост" данных, которые пока не будут секционированы (нехомогенные экстенты).
• Секционирование данных выполняется только в горячих экстентах независимо от значения EffectiveDateTime свойства в политике.
  • Если требуется секционирование холодных экстентов, необходимо временно настроить политику кэширования.

Вы можете отслеживать состояние секционирования таблиц с определенными политиками в базе данных с помощью команды секционирования статистики и секционирования метрик.

Емкость секционирования

• Процесс секционирования данных приводит к созданию дополнительных экстентов. Масштабы объединения могут постепенно увеличиваться, чтобы процесс объединения экстентов мог продолжаться.

• Если есть высокая пропускная способность приема или достаточно большое количество таблиц с определенной политикой секционирования, то емкость секционирования экстентов может постепенно увеличиваться, чтобы процесс секционирования экстентов мог продолжаться.

::: moniker range = "azure-data-explorer"

• Чтобы избежать использования слишком большого количества ресурсов, эти динамические увеличение ограничивается. Вам может потребоваться постепенно и линейно увеличить их за пределами крышки, если они используются полностью.
  • Если увеличение емкости приводит к значительному увеличению использования ресурсов кластера, можно увеличить масштаб кластера /вручную или включить автомасштабирование. ::: moniker-end

Ограничения

• Попытки секционировать данные в базе данных, которая уже имеет более 5 000 000 экстентов, будет регулироваться.
  • В таких случаях EffectiveDateTime свойство секционирования политик таблиц в базе данных будет автоматически отложено на несколько часов, чтобы можно было повторно оценить конфигурацию и политики.

Выбросы в секционированных столбцах

• Следующие ситуации могут способствовать несбалансированному распределению данных между узлами и снижению производительности запросов:
  • Если хэш-ключ секции содержит значения, которые гораздо чаще, чем другие, например пустую строку или универсальное значение (например null , или N/A).
  • Значения представляют сущность (например tenant_id, более распространенную в наборе данных).
• Если ключ секции даты и времени в едином диапазоне имеет достаточно большой процент значений, которые являются "далеко" от большинства значений в столбце, издержки процесса секционирования данных увеличиваются и могут привести к большому большому объему для отслеживания. Примером такой ситуации являются значения даты и времени от далекого прошлого или будущего.

В обоих случаях либо исправьте данные, либо отфильтруйте ненужные записи в данных до приема или во время приема, чтобы сократить затраты на секционирование данных. Например, используйте политику обновления.

Связанный контент

• Команды управления политиками секционирования