Удаление неиспользуемых файлов данных с помощью вакуума

Удалите файлы данных, на которые больше не ссылается таблица и которые старше порога хранения, выполнив команду VACUUM на таблице. Регулярное выполнение VACUUM важно для затрат и соответствия требованиям из-за следующих соображений:

  • Удаление неиспользуемых файлов данных снижает затраты на облачное хранилище.
  • Файлы данных, удаленные с помощью VACUUM, могут содержать записи, которые были изменены или удалены. Окончательное удаление этих файлов из облачного хранилища гарантирует, что эти записи больше не доступны.

Для таблиц с включённой поддержкой чтения Iceberg VACUUM также очищает метаданные Iceberg для более старых версий таблицы. См. VACUUM и очистку метаданных Iceberg.

Прогнозная оптимизация автоматически выполняется VACUUM в управляемых таблицах каталога Unity. Databricks рекомендует включить прогнозную оптимизацию для всех управляемых таблиц каталога Unity, чтобы упростить обслуживание данных и сократить затраты на хранение. См. прогнозную оптимизацию для управляемых каталогом Unity таблиц.

Предостережения для вакуума

Порог хранения по умолчанию для файлов данных после выполнения VACUUM составляет 7 дней. Чтобы изменить это поведение, ознакомьтесь с разделом "Настройка хранения данных для запросов на поездки во времени".

VACUUM может оставить пустые каталоги после удаления всех файлов из них. Последующие VACUUM операции удаляют эти пустые каталоги.

Некоторые функции таблицы, такие как векторы удаления, используют файлы метаданных, чтобы пометить данные как удаленные, а не переписывать файлы данных. Используется REORG TABLE ... APPLY (PURGE) для фиксации этих удалений и перезаписи файлов данных. См. статью "Очистка, предусматривающая удаление только метаданных для принудительной перезаписи данных".

Это важно

  • В Databricks Runtime 13.3 LTS и выше семантика VACUUM для неглубоких клонов с управляемыми таблицами Unity Catalog отличается от других таблиц. См. статью "Использование VACUUM с каталогом Unity с мелкими клонами".
  • VACUUM Удаляет все файлы из каталогов, не управляемых Azure Databricks, игнорируя каталоги, начинающиеся с _ или .. Если вы храните дополнительные метаданные, такие как структурированные контрольные точки потоковой передачи в каталоге таблиц, используйте имя каталога, например _checkpoints.
  • Способность запрашивать версии таблиц старше периода хранения теряется после выполнения VACUUM.
  • Файлы журналов удаляются автоматически и асинхронно после операций контрольных точек и не управляются VACUUM. Хотя срок хранения файлов журнала по умолчанию составляет 30 дней, выполнение VACUUM в таблице удаляет файлы данных, необходимые для перемещения по времени.
  • Если кэширование диска включено, кластер может содержать данные из файлов Parquet, которые были удалены с помощью VACUUM. Таким образом, можно запросить данные предыдущих версий таблиц, файлы которых были удалены. Перезапуск кластера приведет к удалению кэшированных данных. См. раздел Настройка кэша диска.

Пример синтаксиса для вакуума

Чтобы удалить файлы, которые больше не нужны версиям старше стандартного периода хранения, запустите VACUUM без дополнительных параметров:

VACUUM table_name

Чтобы просмотреть список файлов, которые нужно удалить, не удаляя их, запустите VACUUM с помощью DRY RUN:

VACUUM table_name DRY RUN

Сведения о синтаксисе Spark SQL см. в VACUUM.

Сведения о синтаксисе Scala, Java и Python см. в документации по API Delta Lake.

Note

В Databricks Runtime 18.0 и более поздних версиях используйте deletedFileRetentionDuration свойство таблицы для управления хранением. Для управляемых таблиц каталога Unity это относится к Databricks Runtime 13.3 LTS и выше.

См. Настройка сохранения данных для запросов по временному перемещению.

Полный и облегченный режим

Это важно

Эта функция доступна в общедоступной предварительной версии в Databricks Runtime 16.4 LTS и выше.

Чтобы повысить производительность и сократить затраты, избежав перечисления всех файлов в каталоге таблицы, укажите ключевое слово LITE в инструкции VACUUM, чтобы включить альтернативный режим VACUUM. Это полезно для больших таблиц, требующих частых VACUUM операций.

LITE Режим использует журнал транзакций для идентификации файлов данных, которые больше не находятся в VACUUM пороге хранения и удаляют эти файлы данных из таблицы.

Note

Выполнение VACUUM в режиме LITE не удаляет файлы, на которые нет ссылки в журнале транзакций. Например, файлы, созданные прерванной транзакцией.

Используйте следующий синтаксис для VACUUM в режиме LITE:

VACUUM table_name LITE

режим FULL используется по умолчанию для вакуума. Вы можете явно запустить полный режим с помощью следующей команды:

VACUUM table_name FULL

См. VACUUM.

Requirements

LITE режим имеет следующее требование:

  • Необходимо выполнить по крайней мере одну успешную операцию VACUUM в пределах заданного порога хранения журнала транзакций (по умолчанию — 30 дней).

Если это требование не выполняется, при попытке запустить VACUUM в LITE режиме отображается следующее сообщение об ошибке. Чтобы продолжить, необходимо запустить VACUUM в режиме FULL.

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the log. Please run VACUUM FULL.

Удаление метаданных только для принудительной перезаписи данных

Команда REORG TABLE с синтаксисом APPLY (PURGE) позволяет перезаписать данные для применения мягкого удаления. Мягкие удаления не перезаписывают данные и не удаляют файлы данных; вместо этого они используют файлы метаданных для указания, что некоторые значения данных изменились. См. REORG TABLE.

К операциям, которые создают мягкие удаления, относятся следующие:

  • Удаление столбцов с включенным сопоставлением столбцов .
  • Любые изменения данных с включенными векторами удаления.

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

  1. Выполните команду REORG TABLE ... APPLY (PURGE). После этого старые данные больше не присутствуют в текущих файлах таблицы, но они по-прежнему присутствуют в старых файлах, которые используются для перемещения по времени.
  2. Запустите VACUUM , чтобы удалить эти старые файлы.

REORG TABLE создает новую версию таблицы по завершении операции. Все версии таблицы в журнале до этой транзакции относятся к старым файлам данных. Концептуально это похоже на команду OPTIMIZE, где файлы данных перезаписываются, даже если данные в текущей версии таблицы остаются согласованными.

Это важно

Файлы данных удаляются только в том случае, если срок действия файлов истек в соответствии с периодом VACUUM хранения. Это означает, что VACUUM должно быть выполнено с задержкой после REORG, чтобы гарантировать, что срок действия старых файлов истёк. Период хранения VACUUM может быть сокращен, чтобы уменьшить необходимое время ожидания, за счет уменьшения максимальной длительности хранения истории.

Рекомендации по размеру кластера для вакуума

Чтобы выбрать правильный размер VACUUMкластера, следует учитывать, что операция выполняется на двух этапах:

  1. Задание начинается с использования всех доступных узлов исполнителя для перечисления файлов в исходном каталоге параллельно. Задание сравнивает этот список со всеми файлами, на которые в настоящее время ссылается журнал транзакций, чтобы определить файлы для удаления. Водитель находится в бездействии в это время.
  2. Драйвер выдает команды удаления для каждого файла, определенного для удаления. Поскольку удаление файлов является операцией, выполняемой только драйвером, все операции происходят на одном узле, а рабочие узлы простаивают.

Для оптимизации затрат и производительности Databricks рекомендует следующие задачи, особенно для длительных заданий вакуума:

  • Запустите вакуум в кластере с автоматическим масштабированием для 1–4 исполнителей, где у каждого исполнителя есть 8 ядер.
  • Выберите драйвер в диапазоне от 8 до 32 ядер. Увеличьте размер драйвера, чтобы избежать ошибок нехватки памяти (OOM).

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

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

Databricks рекомендует регулярно выполнять VACUUM во всех таблицах, чтобы сократить лишние затраты на хранилище облачных данных. Порог хранения по умолчанию для вакуума составляет 7 дней. При установке более высокого порогового значения вы получаете доступ к более длинной истории изменений таблицы, но при этом увеличивается количество хранимых файлов данных и, как следствие, стоимость хранения у вашего облачного провайдера.

Пороги вакуума и низкого удержания

Warning

Databricks настоятельно рекомендует задать интервал хранения не менее 7 дней. Если у вас есть задания, которые выполняются в течение нескольких дней, долгосрочные задания могут записывать файлы, которые еще не зафиксированы. Если срок хранения слишком короткий, VACUUM может удалить эти незафиксированные файлы до завершения задания.

Существует проверка безопасности, чтобы предотвратить выполнение опасной VACUUM команды. Если вы уверены, что для этой таблицы не выполняются операции, которые длятся дольше интервала хранения, который вы планируете указать, отключите эту проверку безопасности, установив для конфигурации Spark retentionDurationCheck значение false:

Дельта

SET spark.databricks.delta.retentionDurationCheck.enabled = false

Iceberg

SET spark.databricks.iceberg.retentionDurationCheck.enabled = false

Данные аудита

VACUUM фиксирует данные аудита в журнале транзакций. Используйте DESCRIBE HISTORY для запроса событий аудита.

По умолчанию ведение журнала аудита включено на всех платформах для управляемых таблиц каталога Unity. Управление ведением журнала аудита вакуума vacuum.logging с помощью конфигурации Spark:

Дельта

SET spark.databricks.delta.vacuum.logging.enabled = true

Iceberg

SET spark.databricks.iceberg.vacuum.logging.enabled = true

Чтобы применить эту конфигурацию для всей рабочей области во всех кластерах, используйте политику кластера и добавьте следующую команду в JSON политики:

Дельта

{
  "spark_conf.spark.databricks.delta.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Iceberg

{
  "spark_conf.spark.databricks.iceberg.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

См. статью "Создание политик вычислений и управление ими".

Note

Ведение журнала аудита также включается по умолчанию для внешних таблиц.