Поделиться через

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

  • Статья

Примечание.

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

Отказоустойчивые кластеры иногда называются "жидкими секциями". Эта статья относится только к устаревшей секционированию delta, а не к кластеризации жидкости.

В этой статье представлен обзор того, как можно секционировать таблицы в 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 или более поздних версий, вы автоматически создаете преимущества от кластеризации времени приема. Время приема предоставляет аналогичные преимущества для стратегий секционирования на основе полей datetime без необходимости оптимизировать или настроить данные.

Примечание.

Для поддержания кластеризации времени приема при выполнении большого количества изменений, использующих UPDATE или MERGE операторов в таблице, Databricks рекомендует выполняться OPTIMIZE с ZORDER BY использованием столбца, соответствующего порядка приема. Например, это может быть столбец, содержащий метку времени события или дату создания.

Используются ли стратегии секционирования 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:

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

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

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

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

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

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

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