Delta Lake заменяет партиционирование кластеризацией

Delta Lake предлагает отказаться от Hive-стильного сегментирования в облачных хранилищах и перейти к кластеризации данных. Hive-стильное сегментирование подразумевает создание отдельных папок для значений ключевых колонок, например по дате или региону, что приводит к большому числу мелких объектов в S3. Такой подход снижает затраты на listFrom-операции в S3 и ускоряет запросы за счёт пропуска файлов. Журнал транзакций позволяет движку сразу получать точные пути к нужным parquet-файлам без полного сканирования каталога. При принятии решения о переходе важно оценить текущий объём метаданных и частоту list-операций, поскольку в облаке каждая такая операция оплачивается и замедляет работу при тысячах объектов.

Как data skipping работает в журнале Delta

Журнал транзакций хранит min-max статистики по колонкам для каждого файла. Min-max статистики представляют собой минимальное и максимальное значения в колонке внутри отдельного файла, что даёт возможность быстро проверить пересечение с фильтром запроса. При фильтре по году движок отбрасывает файлы, чьи диапазоны не пересекаются с условием, ещё до чтения данных. Это сокращает объём сканируемых байт и число обращений к объектному хранилищу. В отличие от классического listFrom, который требует перечисления тысяч объектов, Delta-rs или Spark читают только метаданные журнала и сразу формируют список релевантных файлов.

Однако эффективность метода напрямую зависит от ширины диапазонов. Если данные в файлах перемешаны по времени или по ключу, min-max значения остаются широкими и пропуск почти не работает. Поэтому кластеризация становится обязательным шагом, а не опциональной оптимизацией. Перед внедрением стоит проверить, насколько равномерно распределены данные в существующих файлах: если диапазоны уже узкие, эффект от кластеризации будет минимальным и затраты на перестроение могут не окупиться.

Почему Z-порядок лучше линейного партиционирования

При кластеризации по нескольким колонкам простое разбиение по одной дате уже не даёт узких диапазонов. Кривая Мортона (Z-order) сворачивает многомерные координаты в одномерный индекс, сохраняя локальность. В результате файлы получают компактные min-max по всем кластерным колонкам одновременно. Линейное партиционирование по одной колонке оставляет широкие диапазоны по остальным измерениям и не позволяет отбрасывать файлы при сложных фильтрах.

В запросах с фильтрами по двум-трём измерениям такой порядок позволяет отсечь до 80-90 % файлов, тогда как линейное партиционирование оставляет для чтения почти все. Ограничение проявляется при частых обновлениях: после слияния или вставки кластеризация может деградировать, и требуется периодический OPTIMIZE с ZORDER. При оценке целесообразности важно учитывать частоту обновлений данных: если таблица в основном читается и редко меняется, кластеризация даёт устойчивый выигрыш; при интенсивных слияниях придётся планировать регулярные операции по поддержанию порядка.

Ограничения и поведение в своём контуре

В российских инфраструктурах чаще всего используют S3-совместимые хранилища с более высокой задержкой и ограничением на количество запросей. Здесь отказ от мелких партиций даёт заметный выигрыш, потому что уменьшает число list-операций. Однако нужно следить за размером файлов после кластеризации: слишком крупные файлы усложняют параллельное чтение и могут упереться в лимиты движка. При миграции существующих таблиц Delta следует сначала оценить текущие min-max статистики. Если они уже узкие, дополнительная кластеризация даст небольшой эффект. Также стоит учитывать, что не все российские дистрибутивы Spark и Trino имеют свежие версии delta-rs с улучшенной поддержкой Z-order.

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

Как это выглядит на практике при росте объёмов

При объёмах в десятки терабайт разница между партиционированием и кластеризацией проявляется в стоимости egress и количестве API-вызовов. Кластеризованные таблицы позволяют держать меньше мелких файлов, что снижает накладные расходы на метаданные. В то же время инженерам приходится добавлять в пайплайн регулярный OPTIMIZE и анализировать статистику после каждого крупного слияния.

Для команд, использующих Delta вместе с Iceberg-совместимыми движками, важно понимать, что Z-order в Delta не переносится автоматически в Iceberg. При параллельной работе двух форматов придётся поддерживать две стратегии кластеризации или выбирать один формат как основной. На этапе планирования стоит просчитать суммарные затраты на хранение и запросы при обоих подходах, включая возможные расходы на перестроение кластеризации, чтобы понять, окупится ли переход в горизонте года-двух.

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Delta Lake заменяет партиционирование кластеризацией.

Курс по теме — Каталог курсов Школы Больших Данных