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

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

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

В Databricks Runtime 11.3 LTS и более поздних версиях Azure Databricks автоматически кластеризает данные в незасекционированных таблицах по времени приема. См. раздел "Использование кластеризации времени приема".

Нужно ли секционировать небольшие таблицы?

Databricks рекомендует не разделять таблицы, содержащие меньше терабайта данных.

Какой минимальный размер каждого раздела в таблице?

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

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

Используя Delta Lake и Databricks Runtime 11.3 LTS или более поздней версии, непарментированные таблицы автоматически создают преимущества от кластеризации времени приема. Время загрузки обеспечивает аналогичные преимущества стратегиям секционирования на основе полей даты и времени без необходимости в оптимизации или настройке данных.

Используют ли Delta Lake и Parquet общие стратегии секционирования?

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

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

Как разделы в Delta Lake отличаются от разделов в других озерах данных?

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

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

Как работают Z-порядок и разделы вместе?

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

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

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

Если секции так плохи, почему некоторые функции Azure Databricks используют их?

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

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

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

Можно ли превзойти встроенные оптимизации Azure Databricks с помощью пользовательского разбиения на разделы?

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