Когда следует секционировать таблицы в Azure Databricks

Примечание.

Databricks рекомендует кластеризацию жидкости для всех управляемых таблиц. Для управляемых таблиц с помощью Apache Iceberg каталог Unity поддерживает только кластеризацию жидкости и интерпретирует PARTITION BY столбцы как ключи кластеризации. См. Преобразование секционированной таблицы в жидкую кластеризацию.

Большинство таблиц в Azure Databricks с менее чем 100 ТБ данных не требуют секционирования. Azure Databricks по умолчанию использует Delta Lake для всех таблиц и автоматически кластеризует данные в таблицах без секционирования по времени загрузки, обеспечивая производительность, сопоставимую с секционированием, без ручной настройки. Учитывайте настраиваемую стратегию секционирования только в том случае, если она опережает эти значения по умолчанию. См. раздел "Использование кластеризации времени приема".

Пользовательские стратегии разбиения на разделы

Расширенные пользователи Apache Spark и Delta Lake могут определить стратегию секционирования, которая опережает кластеризацию времени приема по умолчанию.

Предупреждение

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

Перед использованием пользовательских стратегий разбиения на разделы Databricks рекомендует жидкую кластеризацию для всех таблиц и предиктивную оптимизацию для управляемых таблиц Unity Catalog. См. Жидкая кластеризация для таблиц и Прогнозирующая оптимизация для управляемых таблиц Unity Catalog.

Чтобы преобразовать существующую таблицу Delta Lake с секционированием в таблицу с жидкой кластеризацией, используйте ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Жидкая кластеризация эффективно работает как со столбцами с низкой, так и с высокой кардинальностью и позволяет избежать фиксированных границ секционирования и проблем, связанных с большим количеством мелких файлов, характерных для статического секционирования. См. Преобразование секционированной таблицы в жидкую кластеризацию.

Поддерживаемые типы данных для столбцов секционирования

Секционирование поддерживает эти типы данных для столбцов секционирования:

• Date
• Timestamp
• TimestampNTZ
• Интервал
• String
• Binary
• Boolean
• Целое число, Длинное, Короткое, Байт
• Float (Число с плавующей запятой одинарной точности), Double (Число с плавующей запятой двойной точности), Decimal (Десятичное число)

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

• Сложные типы, такие как StructType, MapTypeArrayTypeилиVariantType
• Поля структуры, такие как struct_col.field. Delta Lake обрабатывает поле структуры в PARTITIONED BY как выражение, а не как ссылку на столбец.

Чтобы упорядочить таблицу по полю структуры, вместо этого используйте жидкую кластеризацию, поскольку она распознает поле структуры как ключ кластеризации. Кластеризация Liquid — единственный способ пропускать данные по полю структуры, не извлекая его предварительно в столбец верхнего уровня. См. раздел "Использование кластеризации жидкости" для таблиц.

Рекомендации по минимальному размеру

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

• Для таблиц:
  • При объёме данных менее 1 ТБ не разбивайте на разделы.
  • При объёме данных от 1 ТБ до 100 ТБ используйте liquid clustering вместо разбиения на разделы. Секционирование, вероятно, отрицательно влияет на производительность чаще, чем это помогает.
  • При использовании 100 ТБ или более данных секционирование может повысить производительность, но Databricks рекомендует сначала использовать кластеризацию жидкости и проверять улучшения производительности.
• Для секций убедитесь, что каждая секция содержит не менее 1 ГБ данных. Таблицы с меньшим количеством, большими партициями обычно работают быстрее таблиц с множеством небольших партиций.

Использование кластеризации времени приема

При использовании Delta Lake несекционированные таблицы автоматически используют кластеризацию по времени загрузки. Время приема данных обеспечивает улучшение производительности запросов, аналогичное стратегиям секционирования с полями datetime, без какой-либо необходимости вручную оптимизировать или настраивать данные.

Примечание.

Чтобы поддерживать кластеризацию по времени загрузки при выполнении большого количества изменений с помощью инструкций UPDATE или MERGE в таблице, Databricks рекомендует использовать жидкостную кластеризацию в столбце, который соответствует порядку загрузки данных, например метку времени события или дату создания. См. раздел "Использование кластеризации жидкости" для таблиц.

Совместимость секционирования Delta Lake и Parquet

Delta Lake использует Parquet для хранения данных, а некоторые секционированные таблицы Delta Lake имеют макеты данных, аналогичные таблицам Parquet, хранящимся в Apache Spark. Apache Spark использует секционирование в стиле Hive при сохранении данных в формате Parquet. Секционирование в стиле Hive не является частью протокола Delta Lake, и рабочие нагрузки не должны полагаться на эту стратегию секционирования для взаимодействия с таблицами Delta Lake.

Databricks рекомендует взаимодействовать с данными, хранящимися в Delta Lake, с помощью официально поддерживаемых клиентов и API. Многие функции Delta Lake нарушают предположения о макете данных, которые могли использоваться с Parquet, Hive или даже более ранними версиями протокола Delta Lake.

Примечание.

При включении сопоставления столбцов для таблицы Delta Lake случайные префиксы заменяют имена столбцов в каталогах секций для секционирования в стиле Hive. См. : переименование и удаление столбцов с помощью сопоставления столбцов в Delta Lake.

Секционирование Delta Lake по сравнению с другими озерами данных

Методы секционирования, полезные в других технологиях с открытым исходным кодом (таких как Apache Spark, Parquet, Hive и Hadoop), не всегда применимы к Azure Databricks. Если вы решили секционировать таблицу, рассмотрите следующее:

• Транзакции не определяются границами секций. Так как Delta Lake обеспечивает ACID через журналы транзакций, вам не нужно отделять пакет данных по секции, чтобы гарантировать атомарность.
• Вычислительные кластеры Azure Databricks не привязаны к физическому носителю. Данные, собранные в lakehouse, хранятся в облачном хранилище объектов. Хотя данные кэшируются в локальное хранилище дисков во время обработки данных, Azure Databricks использует статистику на основе файлов для определения минимального объема данных для параллельной загрузки.

Z-порядок и разделы

Примечание.

Databricks рекомендует использовать кластеризацию через Liquid Clustering вместо Z-упорядочивания для всех новых таблиц. См. раздел "Использование кластеризации жидкости" для таблиц.

Индексы Z-порядка можно использовать вместе с секциями для ускорения запросов к большим наборам данных. Большинство таблиц используют кластеризацию времени приема, чтобы избежать необходимости настройки Z-порядка и секций.

Помните следующие правила при планировании стратегии оптимизации запросов на основе границ секционирования и порядка Z:

• Для Z-порядка требуется OPTIMIZE команда. Невозможно объединить файлы между границами секций, поэтому кластеризация Z-порядка может выполняться только в пределах секции. Для несекционированных таблиц файлы могут объединяться по всей таблице.
• Секционирование хорошо подходит только для полей с низкой или известной кардинальностью (например, полей дат или физических расположений), но не для полей с высокой кардинальностью, например метками времени. Z-order работает для всех полей, включая поля высокой кратности и поля, которые могут увеличиваться бесконечно (например, метки времени или идентификатор клиента в транзакциях или таблице заказов).
• Нельзя указать порядок Z в полях, используемых для секционирования.

Как Azure Databricks оптимизирует существующие разделы

Многие клиенты переходят на Delta Lake из озёр данных на базе Parquet, например, используя оператор CONVERT TO DELTA для преобразования существующей таблицы в формате Parquet в таблицу Delta Lake без перезаписи существующих данных. Так как преобразование не перезаписывает существующие данные, большие таблицы могут наследовать предыдущие стратегии секционирования.

Некоторые оптимизации Databricks по возможности используют эти разделы, что позволяет снизить негативное влияние на производительность при использовании стратегий разбиения на разделы, не оптимизированных для Delta Lake.

Delta Lake и Apache Spark — это технологии с открытым исходным кодом. Хотя Databricks имеет функции, которые снижают зависимость от секционирования, открытый код сообщество может создавать новые функции, которые добавляют сложность.