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

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

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

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

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

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

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

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

Некоторые функции таблицы используют файлы метаданных для маркировки данных как удаленных, а не перезаписи файлов данных. Используется 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 table_name   -- vacuum files not required by versions older than the default retention period

VACUUM table_name DRY RUN    -- do dry run to get the list of files to be deleted

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

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

Примечание.

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

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

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

Внимание

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

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

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

Примечание.

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

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

VACUUM table_name LITE

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.

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

VACUUM table_name FULL

См. VACUUM.

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

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

Почему вы не можете очистить таблицу с низким порогом удержания?

Предупреждение

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

Существует проверка безопасности, чтобы предотвратить выполнение опасной VACUUM команды. Если вы уверены, что в этой таблице нет операций, которые занимают больше указанного интервала хранения, отключите этот флажок безопасности, задав для свойства spark.databricks.delta.retentionDurationCheck.enabled конфигурации Spark (Delta) или spark.databricks.iceberg.retentionDurationCheck.enabled (Iceberg) значение false.

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

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

Ведение журнала аудита вакуума управляется конфигурациями spark.databricks.delta.vacuum.logging.enabled уровня рабочей области (Delta) или spark.databricks.iceberg.vacuum.logging.enabled (Iceberg). По умолчанию ведение журнала аудита включено на всех платформах для управляемых таблиц каталога Unity.

Примечание.

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