Начните использовать Liquid Clustering вместо Partitioning для Delta-таблиц в Databricks.

Используйте Liquid Clustering вместо Partitioning для Delta-таблиц в Databricks и получите новые возможности!

Революционируя способ организации данных, Databricks представил новаторский продукт под названием Liquid Clustering на этом годовом мероприятии Data + AI Summit. Это инновационная функция, которая переопределяет границы разделения и кластеризации для таблиц Delta.

Разделение и Z-Ordering

В Delta Databricks разделение включает организацию данных в логические подмножества на основе определенных столбцов, что упрощает размещение данных в подмножествах и оптимизацию производительности запросов. Кроме того, Z-Ordering используется совместно с разделением для улучшения организации данных. Данные сортируются и хранятся в желаемом порядке, что оптимизирует производительность запросов. Таким образом, разделение и Z-Ordering помогают оптимизировать производительность запросов.

Например, в системе управления коммерческими отношениями –

  • Данные по продажам разделены по регионам и подрегионам, чтобы данные можно было разбить на логические подмножества для легкого доступа к данным.
  • Кроме того, разделенные данные можно отсортировать с помощью временных меток или идентификатора учетной записи, чтобы оптимизировать производительность запросов.

Проблемы с разделением и Z-Ordering

Хотя разделение и Z-Ordering могут быть использованы для эффективного хранения и извлечения данных, они могут замедлить процесс записи данных, так как данные должны быть переорганизованы при каждой записи. Вот некоторые проблемы, связанные с разделением и Z-Ordering:

  • Неравномерное распределение и высокая кардинальность: Неравномерное распределение данных может привести к искажению данных, когда некоторые разделы могут содержать значительно больше данных, чем другие. При использовании Z-Ordering столбцы с высокой кардинальностью внутри раздела могут привести к неравномерному распределению данных. Например, некоторые регионы могут содержать меньше клиентов, тогда как некоторые – больше.
  • Накладные расходы при обновлениях: Выполнение обновлений для существующих данных путем изменения столбцов может привести к перестройке данных, что замедлит процесс.

Таким образом, как разделение, так и Z-Ordering опираются на организацию данных для оптимизации их использования.

Как Liquid Clustering приходит на помощь —

Вместо жестких макетов данных Liquid Clustering автоматически настраивает организацию данных на основе ключей кластеризации без необходимости перезаписи данных, тем самым решая проблему накладных расходов. Кроме того, Liquid Clustering динамически кластеризует данные на основе образцов данных и избегает проблем с разделением, связанных с неравномерным распределением данных.

Liquid Clustering определенно будет полезен в следующих сценариях

  • Таблицы с неравномерным распределением или столбцами высокой кардинальности.
  • Таблицы, которые быстро растут и требуют усилий по обслуживанию и настройке.
  • Таблицы с требованиями к одновременной записи и образцам доступа, которые меняются со временем.

Использование Liquid Clustering

Настройка Liquid Clustering может быть легко выполнена с помощью выражения ‘Cluster by’ при создании таблицы.

CREATE TABLE table1(col0 int, col1 string) USING DELTA CLUSTER BY (col0);

Можно изменить существующую таблицу и включить кластеризацию:

ALTER TABLE table_name CLUSTER BY (new_column1, new_column2);

Liquid Clustering несовместим с разделением и Z-Ordering, поэтому нельзя выполнять кластеризацию, если таблица уже разделена.

После выполнения кластеризации она может быть запущена с помощью команды ‘Optimize’

OPTIMIZE table_name;

Liquid Clustering работает на Databricks Runtime 13.3 LTS и выше

[1] Databricks предоставляет межрядовую конкурентность для кластеризованных таблиц, что позволяет уменьшить количество конфликтов между одновременными операциями записи, включая операции OPTIMIZE, INSERT, MERGE, UPDATE и DELETE.

Запись данных в кластеризованную таблицу —

Большинство операций не кластеризуют данные автоматически при записи. Операции, которые выполняют кластеризацию при записи, включают следующие:

  • INSERT INTO операции
  • CTAS выражения
  • COPY INTO из формата Parquet
  • spark.write.format("delta").mode("append")

Это не применяется в следующих ситуациях —

  • Если операция записи превышает 512 ГБ данных.
  • Если подзапрос SELECT содержит преобразование, фильтр или соединение.
  • Если проектируемые столбцы не совпадают с исходной таблицей.

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

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

Выбор ключей кластеризации

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

Примечание: Мы можем иметь только 4 ключа кластеризации, для которых собираются статистические данные. По умолчанию статистика собирается для первых 32 столбцов в таблицах Delta. Это число можно управлять через свойство таблицы — delta.dataSkippingNumIndexedCols. Все столбцы с позиционным индексом, меньшим значения этого свойства, будут иметь собранные статистические данные.

Надеюсь, это будет полезно… Если “ДА”, попробуйте…

В основном для этой статьи я использовал https://docs.databricks.com/en/delta/clustering.html#see-how-table-is-clustered в качестве справочной информации.

Удачного обучения…