使用 vacuum 移除未使用的資料檔案
預測優化會自動在 Unity 目錄受控數據表上執行 VACUUM
。 Databricks 建議為所有 Unity 目錄受控數據表啟用預測優化,以簡化數據維護並減少記憶體成本。 請參閱 Unity Catalog 受控資料表的預測性最佳化。
您可以藉由在數據表上執行 VACUUM
命令,移除 Delta 數據表不再參考超過保留閾值的數據檔。 由於下列考慮,定期執行 VACUUM
對於成本和合規性很重要:
- 刪除未使用的數據檔可降低雲端記憶體成本。
- 拿掉的
VACUUM
資料檔可能包含已修改或刪除的記錄。 從雲端記憶體永久移除這些檔案可確保這些記錄無法再存取。
真空的注意事項
執行 VACUUM
後數據文件的預設保留閾值為 7 天。 若要變更此行為,請參閱 設定時間旅行查詢的數據保留期。
VACUUM
從其中移除所有檔案之後,可能會留下空白目錄。 後續 VACUUM
作業會刪除這些空目錄。
Databricks 建議使用預測性優化自動針對 Delta 數據表執行 VACUUM
。 請參閱 Unity Catalog 受控資料表的預測性最佳化。
某些 Delta Lake 功能會使用元資料檔案來將數據標示為已刪除,而不是重寫數據檔。 您可以使用 REORG TABLE ... APPLY (PURGE)
來認可這些刪除並重寫資料檔。 請參閱 清除僅限元數據刪除以強制數據重寫。
重要
- 在 Databricks Runtime 13.3 LTS 和更新版本中,
VACUUM
使用 Unity 目錄受控數據表進行淺層複製的語意與其他差異數據表不同。 請參閱 Vacuum 和 Unity 目錄淺層複製。 -
VACUUM
從 Delta Lake 未管理的目錄中移除所有檔案,忽略開頭為 或_
的.
目錄。 如果您要在 Delta 資料表目錄中儲存其他元資料,例如結構化串流檢查點,請使用目錄名稱,例如_checkpoints
。- 變更數據摘要的數據是由目錄中的 Delta Lake
_change_data
管理,並使用VACUUM
移除。 請參閱 在 Azure Databricks 上使用 Delta Lake 變更數據摘要。 - Bloom 篩選索引會使用
_delta_index
Delta Lake 管理的目錄。VACUUM
清除此目錄中的檔案。 請參閱 Bloom 篩選索引。
- 變更數據摘要的數據是由目錄中的 Delta Lake
- 執行 之後
VACUUM
,查詢早於保留期間之數據表版本的能力會遺失。 - 記錄檔會在檢查點作業之後自動和異步刪除,且不受控管
VACUUM
。 雖然記錄檔的預設保留期間是 30 天,但數據表上執行VACUUM
會移除時間移動所需的數據檔。
注意
啟用磁碟快取時,叢集可能包含已使用 VACUUM
刪除之 Parquet 檔案中的數據。 因此,可以查詢已刪除檔案的舊數據表版本數據。 重新啟動叢集將會移除快取的數據。 請參閱 設定磁碟快取。
真空的範例語法
VACUUM table_name -- vacuum files not required by versions older than the default retention period
VACUUM table_name RETAIN 100 HOURS -- vacuum files not required by versions more than 100 hours old
VACUUM table_name DRY RUN -- do dry run to get the list of files to be deleted
如需 Spark SQL 語法詳細資料,請參閱 VACUUM。
如需 Scala、Java 和 Python 語法詳細數據,請參閱 Delta Lake API 檔。
注意
RETAIN
使用 關鍵詞來指定用來判斷是否應該移除數據檔的臨界值。
VACUUM
命令會使用此閾值來回頭查看指定時間量,並識別該時間點最新的數據表版本。 Delta 會保留查詢該數據表版本和所有較新數據表版本所需的所有數據檔。 此設定與其他數據表屬性互動。 請參閱設定時間移動查詢的資料保留。
完整模式與精簡模式
重要
這項功能在 Databricks Runtime 16.1 和更新版本中處於公開預覽狀態。
您可以在 vacuum 語句中指定 LITE
關鍵詞,以觸發 VACUUM
的替代模式,從而避免列出數據表目錄中的所有檔案。
LITE
模式會使用 Delta 事務歷史記錄來識別不再位於 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 Delta log. Please run VACUUM FULL.
FULL
模式是真空的預設值。 您可以使用下列命令明確地執行完整模式:
VACUUM table_name FULL
請參閱 VACUUM。
清除僅限元數據的刪除以強制數據重寫
命令 REORG TABLE
提供 APPLY (PURGE)
重寫數據以套用虛刪除的語法。 虛刪除不會重寫資料或刪除資料檔,而是使用元數據檔案來指出某些數據值已變更。 請參閱 REORG TABLE。
在 Delta Lake 中建立虛刪除的作業包括:
啟用虛刪除後,即使刪除或更新數據之後,舊數據仍可能實際存在於數據表的目前檔案中。 若要從數據表實際移除此數據,請完成下列步驟:
- 執行
REORG TABLE ... APPLY (PURGE)
。 執行此動作之後,舊數據不再存在於數據表的 目前 檔案中,但仍存在於用於時間移動的較舊檔案中。 - 執行
VACUUM
以刪除這些較舊的檔案。
REORG TABLE
當作業完成時,會建立新版的數據表。 此交易之前歷程記錄中的所有數據表版本都是指較舊的數據檔。 從概念上講,這類似於 OPTIMIZE
命令,即使目前數據表版本中的數據保持一致,也會重寫數據檔。
重要
只有在檔案已時,才會刪除數據檔。 這表示 VACUUM
必須在 之後 REORG
延遲完成 ,才能讓較舊的檔案過期。 的保留期間 VACUUM
可以減少以縮短所需的等候時間,代價是降低保留的最大歷程記錄。
真空需要何種大小叢集?
若要為 選取正確的叢集大小 VACUUM
,它有助於了解作業會在兩個階段中發生:
- 作業會從使用所有可用的執行程序節點開始,以平行方式列出來源目錄中的檔案。 此清單會與 Delta 事務歷史記錄中目前參考的所有檔案進行比較,以識別要刪除的檔案。 此時,驅動程式會閑置。
- 驅動程式接著會針對要刪除的每個檔案發出刪除命令。 檔案刪除是僅限驅動程式的作業,這表示當背景工作節點閑置時,所有作業都會發生在單一節點中。
為了將成本和效能優化,Databricks 建議下列專案,特別是針對長時間執行的真空作業:
- 在為其中 1-4 個背景工作角色 (每個背景工作角色有 8 個核心) 設定了自動縮放的叢集上執行 vacuum。
- 選擇核心數為 8 至 32 的驅動程式。 增加驅動程式的大小,以避免記憶體不足 (OOM) 錯誤。
如果 VACUUM
作業會定期刪除超過 10,000 個檔案,或佔用 30 分鐘的處理時間,您可能會想要增加驅動程式的大小或背景工作角色數目。
如果您發現在識別要移除的檔案時發生速度變慢,請新增更多背景工作節點。 如果刪除命令執行時發生速度變慢,請嘗試增加驅動程式的大小。
您應該執行真空的頻率?
Databricks 建議定期在所有數據表上執行 VACUUM
,以減少多餘的雲端數據儲存成本。 真空的預設保留閾值為 7 天。 設定較高的閾值可讓您存取數據表的歷程記錄,但會增加所儲存的數據檔數目,因此,雲端提供者會產生更大的記憶體成本。
為什麼您無法使用低保留閾值來清空 Delta 數據表?
警告
建議您將保留間隔設定為至少 7 天,因為舊的快照集和未認可的檔案仍可供數據表的並行讀取器或寫入器使用。 如果 VACUUM
清除使用中檔案,並行讀取器可能會失敗,或者更糟的是,刪除尚未認可的檔案時 VACUUM
,數據表可能會損毀。 您必須選擇超過執行中最長並行交易的間隔,以及任何資料流程可以延遲至資料表最新更新的最長期間。
Delta Lake 有安全檢查,以防止您執行危險的 VACUUM
命令。 如果您確定此資料表上未執行比您計劃指定的保留間隔還要久的作業,您可以將 Spark 組態屬性 spark.databricks.delta.retentionDurationCheck.enabled
設定為 false
來關閉此安全性檢查。
稽核資訊
VACUUM
認可至 Delta 事務歷史記錄包含稽核資訊。 您可以使用 查詢稽核事件 DESCRIBE HISTORY
。