Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Файлы таблицы Delta со временем фрагментируются. Фрагментация увеличивает затраты на операции файлов, снижает эффективность сжатия и может ограничивать параллелизм чтения. Сжатие перезаписывает множество небольших файлов в меньшее количество файлов оптимального размера, чтобы Spark мог читать и обрабатывать данные более эффективно.
Команда OPTIMIZE является основной операцией сжатия. Он группирует небольшие файлы в ячейки, посвященные идеальному размеру файла, а затем записывает их в хранилище.
См. раздел "Обслуживание и оптимизация таблиц между рабочими нагрузками" для получения рекомендаций по стратегиям сжатия для различных типов рабочих нагрузок, таких как SQL Analytics Endpoint, Power BI Direct Lake и Spark.
Методы сжатия
Microsoft Fabric предлагает несколько подходов к поддержанию оптимальных размеров файлов в таблицах Delta:
Команда OPTIMIZE
Эта OPTIMIZE команда является базовой операцией для сжатия таблиц Delta. Он переформатирует небольшие файлы в большие, чтобы улучшить структуру данных в таблицах Delta.
| Недвижимость | Description | Значение по умолчанию | Конфигурация сеанса |
|---|---|---|---|
| minFileSize | Файлы, которые меньше этого порогового значения, группируются и перезаписываются в виде больших файлов. | 1073741824 (1 ГБ) | spark.databricks.delta.optimize.minFileSize |
| maxFileSize | Целевой размер файла, созданный командой OPTIMIZE . |
1073741824 (1 ГБ) | spark.databricks.delta.optimize.maxFileSize |
OPTIMIZE является идемпотентным, но чрезмерно большой minFileSize может увеличить амплификацию записи. Например, если minFileSize задано значение 1 ГБ, файл размером 900 МБ может быть перезаписан после небольшой дополнительной записи. Инструкции по автоматическому управлению размером файлов см. в статье адаптивный размер целевого файла.
OPTIMIZE с упорядочением по Z-Order
При использовании ZORDER BY предложения перезаписывают активные файлы, OPTIMIZE чтобы строки с аналогичными значениями размещались в одних и тех же файлах. Совмещённая схема повышает эффективность пропуска файлов при выборочной фильтрации. Используйте Z-Order, когда:
- Ваши запросы часто фильтруются по двум или нескольким столбцам одновременно (например, дата и идентификатор клиента), и
- Эти предикаты достаточно выборочные, так что пропуск на уровне файлов снижает количество сканируемых файлов.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2)
OPTIMIZE с системой V-Order
Клаузула VORDER приводит к тому, что файлы, подлежащие сжатию, подвергаются оптимизации V-Order. Дополнительные сведения о V-Order см. в подробной документации.
OPTIMIZE dbo.table_name VORDER
Вы можете объединить Z-Order и V-Order в одной команде. Spark применяет операции в этом порядке: сжатие ячеек → Z-Order → V-Order.
OPTIMIZE dbo.table_name ZORDER BY (column1, column2) VORDER
Поведение V-Order при OPTIMIZE зависит от того, как вы вызываете команду:
| Инвокация | Behavior |
|---|---|
OPTIMIZE table VORDER |
Принудительно применяет V-Order к перезаписываемым файлам независимо от параметров сеанса или таблицы. |
OPTIMIZE table (без VORDER ключевого слова) |
Наследует поведение V-Order от TBLPROPERTIES("delta.parquet.vorder.enabled"), если задано, в противном случае используется конфигурация сеанса spark.sql.parquet.vorder.default. |
OPTIMIZE с кластеризацией жидкостей
Кластеризация liquid указывается как параметр таблицы; Дополнительные сведения см. в разделе "Включение кластеризации жидкости ". При включенной кластеризации жидкости, OPTIMIZE выполняет физическую перезапись, применяя политику кластеризации.
Это важно
Данные кластеризуются только при OPTIMIZE запуске на таблицах с поддержкой кластеризации. Обычные операции записи не кластерят данные. При наличии стратегии уплотнения, такой как использование автоматического уплотнения или ручное планирование заданий оптимизации, важно обеспечить реализацию преимуществ кластеризованных данных (например, улучшенное пропускание Delta-файлов).
Быстрая оптимизация
Быстрая оптимизация интеллектуально анализирует файлы таблиц Delta и пропускает операции сжатия, которые, скорее всего, не повышают производительность.
Вместо слепого сжатия файлов всякий раз, когда имеются небольшие файлы, оптимизация производительности оценивает, соответствует ли каждый контейнер кандидатов (группа небольших файлов) настраиваемым рекомендуемым стандартам сжатия. Быстрая оптимизация выполняет уплотнение только в группе файлов, если их объединение, вероятно, достигнет минимального целевого размера, или если слишком много небольших файлов. В противном случае она пропускает группу или уменьшает количество сжатых файлов.
Быстрая оптимизация может быть точно настроена в соответствии с вашими ожиданиями относительно сжатия:
| Недвижимость | Description | Значение по умолчанию | Конфигурация сеанса |
|---|---|---|---|
| minNumFiles | Количество небольших файлов, которые должны существовать в контейнере для выполнения оптимизации, если контейнер не содержит достаточно данных, чтобы, по оценкам, создать уплотненный файл. | 50 | spark.microsoft.delta.optimize.fast.minNumFiles |
| ParquetCoefficient | Умножено на минимальный размер файла в условиях оптимизации, чтобы определить минимальный объем данных небольшого файла, который должен существовать в контейнере для включения в область применения сжатия. | 1.3 | spark.microsoft.delta.optimize.fast.parquetCoefficient |
Замечание
parquetCoefficient Это приводит к тому, что целевой размер ячейки превышает минимальный целевой размер файла в контексте оптимизации. Этот коэффициент учитывает реальность, что объединение нескольких небольших файлов «parquet» улучшает сжатие и, следовательно, данных получается меньше, чем сумма небольших файлов. Увеличьте значение, чтобы fast optimize реже пропускала бины, или уменьшите его, чтобы разрешить более частый пропуск бинов.
Принцип работы
"Fast Optimize" вводит дополнительные проверки перед сжатием контейнеров. Для каждой ячейки кандидата выполняется быстрая оптимизация:
- Предполагаемый объем необработанных данных в ячейке (сумма небольших размеров файлов)
- Как оценивается объединение небольших файлов для создания собрания файла с настроенным минимальным целевым размером
- Содержит ли контейнер по крайней мере минимально настроенное количество небольших файлов
Быстрая оптимизация оценивает каждую ячейку небольших файлов и сжимает только ячейки, которые, скорее всего, достигают минимального целевого размера или превышают минимальное число файлов. Контейнеры, которые не соответствуют этим пороговым значениям, пропускаются или частично сжимаются. Пропускание неоптимальных групп уменьшает ненужные перезаписи, снижает амплификацию записи и делает задания по оптимизации более идемпотентными.
Замечание
Точную реализацию можно развивать с течением времени.
Быстрая оптимизация может уменьшить количество перезаписанных данных в течение жизненного цикла Delta-таблицы. Как показано на следующей схеме, быстрая оптимизация пропускает неоптимальные ячейки, что приводит к более быстрым и идемпотентным OPTIMIZE заданиям с меньшим увеличением объема записи.
Замечание
В целях иллюстрации предполагается, что размер файла, написанного из сжатия, — это сумма размера небольших файлов. Это также подразумевает наличие parquetCoefficient равного 1.
Ограничения
- Неприменимо к операциям кластеризации жидкости и Z-Order
- Быстрая оптимизация не изменяет поведение автоматического сжатия
Целевые объекты сжатия на уровне файлов
Чтобы избежать перезаписи данных, которые ранее считались компактными (достаточно большими) на основе изменения целевых значений минимального и максимального размера файлов, spark.microsoft.delta.optimize.fileLevelTarget.enabled можно включить, чтобы предотвратить повторную компиляцию уже сжатых файлов. При включении файлы не перекомпактируются, если они ранее достигли как минимум половины целевого размера файла на момент предыдущей компактизации. Поддержание целевых объектов на уровне файлов минимизирует усиление записи по мере изменения целевого размера уплотнения с течением времени (например, в результате оценки и установки более крупного целевого размера адаптивным образом). Если включено, тег OPTIMIZE_TARGET_SIZE добавляется в новые файлы при выполнении команды OPTIMIZE или для любой операции записи, если задано свойство таблиц delta.targetFileSize или delta.targetFileSize.adaptive.
Замечание
Хотя она не включена по умолчанию, корпорация Майкрософт рекомендует включить целевые объекты сжатия на уровне файлов , чтобы ограничить потенциальное увеличение объема записи.
Автоматическое сжатие
Автоматическое сжатие оценивает работоспособности секций после каждой операции записи. При обнаружении чрезмерной фрагментации файлов (слишком большого количества небольших файлов) в секции он запускает синхронную OPTIMIZE операцию сразу после фиксации записи. Подход, управляемый писателем, к обслуживанию файлов является оптимальным, так как сжатие выполняется только при программном определении целесообразности.
Включение на уровне сеанса
Установите spark.databricks.delta.autoCompact.enabled на уровне сеанса, чтобы включить автоматическое сжатие для новых таблиц, создаваемых в этом сеансе Spark.
Включение на уровне таблицы
Задайте свойство delta.autoOptimize.autoCompact таблицы, чтобы включить автоматическое сжатие для определенных таблиц:
CREATE TABLE dbo.table_name
TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Используйте параметр delta.autoOptimize.autoCompact DataFrameWriter, чтобы включить автоматическое сжатие при создании таблицы:
df.write.option('delta.autoOptimize.autoCompact', 'true').saveAsTable('dbo.table_name')
Включите одно и то же свойство таблицы в существующей таблице:
ALTER TABLE dbo.table_name
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
Сокращение затрат на оценку
Начиная с версии 2.0 среды выполнения Fabric Spark (Delta 4.1), можно включить режим onCheckpointOnly автоматического уплотнения. По умолчанию автоматическое сжатие вычисляет метаданные файла после каждой операции записи, чтобы определить, имеет ли таблица слишком много небольших файлов. При этом onCheckpointOnly, вычисление откладывается до операций создания контрольной точки журнала (обычно каждые 10 коммитов). Во время контрольной точки моментальный снимок таблицы уже полностью восстановлен, поэтому оценка считывается из метаданных, которые уже в памяти, а не требуют дополнительного сканирования. Отложенное вычисление уменьшает накладные расходы на каждый коммит, при этом обеспечивая периодическое сжатие таблиц.