自動優化Databricks

自動優化是一組可選的特性，在對Delta表進行單獨寫入時自動壓縮小文件。自動優化會增加寫操作的延遲開銷，但會加速讀操作。自動優化在以下場景中特別有用:

  • 以分鍾為單位的延遲是可以接受的流用例

  • 合並成寫三角洲湖的首選方法是什麼

  • 創建表格作為選擇或插入成都是常用操作

自動優化如何工作

自動優化包含兩個互補的特性:優化的寫入和自動壓縮。

優化寫是如何工作的

Databricks會根據實際數據動態優化Apache Spark分區大小，並嚐試為每個表分區寫128mb的文件。這是一個近似大小，可以根據數據集特征而變化。

優化寫道

自動壓縮工作原理

每次寫入後，Databricks檢查文件是否可以進一步壓縮，並運行優化作業(文件大小為128mb而不是標準中使用的1gb文件大小優化)，以進一步壓縮文件的分區，有最多的小文件。

啟用自動優化

在Databricks Runtime 9.1 LTS及以上版本中，以下操作默認啟用優化寫:

  • 合並

  • 更新與子查詢

  • 刪除與子查詢

對於其他操作，或者對於Databricks Runtime 7.3 LTS，您可以使用以下方法之一顯式啟用優化的寫入和自動壓縮:

  • 新表:設置表屬性delta.autoOptimize.optimizeWrite＝真正的而且delta.autoOptimize.autoCompact＝真正的在創建表格命令。

    創建表格學生（idINT，名字字符串，年齡INT）TBLPROPERTIES（δ．autoOptimize．optimizeWrite＝真正的，δ．autoOptimize．autoCompact＝真正的）

  • 現有表:設置表屬性delta.autoOptimize.optimizeWrite＝真正的而且delta.autoOptimize.autoCompact＝真正的在改變表格命令。

    改變表格［table_name|δ．' <表格-路徑>”］集TBLPROPERTIES（δ．autoOptimize．optimizeWrite＝真正的，δ．autoOptimize．autoCompact＝真正的）

  • 所有新表：

    集火花．磚．δ．屬性．違約．autoOptimize．optimizeWrite＝真正的；集火花．磚．δ．屬性．違約．autoOptimize．autoCompact＝真正的；

在Databricks Runtime 10.1及以上版本中，table屬性delta.autoOptimize.autoCompact也接受值汽車而且遺產除了真正的而且假．當設置為汽車(推薦)，Databricks調整目標文件大小以適合用例。當設置為遺產或真正的，自動壓縮使用128mb作為目標文件大小。

此外，您可以通過配置為Spark會話啟用和禁用這兩個特性:

  • spark.databricks.delta.optimizeWrite.enabled

  • spark.databricks.delta.autoCompact.enabled

會話配置優先於表屬性，允許您更好地控製何時選擇加入或退出這些特性。

什麼時候加入，什麼時候退出

本節提供關於何時選擇加入和退出自動優化功能的指導。

何時選擇進入優化的寫入

寫優化的目的是使寫入存儲服務的數據吞吐量最大化。這可以通過減少寫入的文件數量來實現，而不會犧牲太多的並行性。

優化的寫操作要求根據目標表的分區結構對數據進行變換。這種洗牌自然會帶來額外的成本。但是，寫入期間的吞吐量增加可能會抵消shuffle的成本。如果不是，在查詢數據時提高的吞吐量仍然值得使用該特性。

優化寫的關鍵部分是它是一個自適應shuffle。如果您有一個流攝取用例，並且輸入數據速率隨時間變化，那麼自適應shuffle將根據微批間的傳入數據速率進行自我調整。如果你有代碼片段合並(n)或重新分區(n)在您寫入流之前，您可以刪除這些行。

何時選擇加入

  • 幾分鍾的延遲是可以接受的流用例

  • 當使用SQL命令時，比如合並，更新，刪除，插入成，創建表格作為選擇

何時選擇退出

  • 當寫入的數據為tb級時，存儲優化實例不可用。

  • 使用現貨實例時，現貨價格不穩定，導致大量節點丟失。

何時選擇自動壓縮

自動壓縮發生在對表的寫入成功之後，並在執行寫入的集群上同步運行。這意味著如果您的代碼模式是寫入Delta Lake，然後立即調用優化，您可以刪除優化如果啟用自動壓縮，則調用。

自動壓縮使用不同的啟發式優化．由於它在寫入後同步運行，我們調優了自動壓縮以使用以下屬性運行:

  • Databricks不支持帶有自動壓縮的z - ordered，因為z - ordered比僅僅壓縮要昂貴得多。

  • 自動壓縮生成的文件更小(128 MB)優化(1 GB)。

  • 自動壓縮會貪婪地選擇一組最能利用壓縮的有限分區。選擇的分區數量將根據啟動它的集群的大小而變化。如果您的集群有更多的cpu，就可以優化更多的分區。

  • 控件可控製輸出文件大小火花配置spark.databricks.delta.autoCompact.maxFileSize．默認值為134217728，將大小設置為128 MB104857600設置文件大小為100MB。

何時選擇加入

  • 幾分鍾的延遲是可以接受的流用例。

  • 當你沒有常規食物的時候優化電話在您的桌子上。

何時選擇退出

  • 對於DBR 10.3及以下版本:當其他寫入器執行如下操作時刪除，合並，更新,或優化因為自動壓縮可能會導致這些作業的事務衝突。

    如果自動壓縮失敗，由於事務衝突，Databricks不壓縮失敗或重試。即使自動壓縮沒有成功，相應的寫查詢(觸發自動壓縮)也會成功。

    在DBR 10.4及以上版本中，這不是問題:自動壓縮不會導致與其他並發操作的事務衝突，例如刪除，合並,或更新．其他並發事務具有更高的優先級，不會因為自動壓縮而失敗。

示例工作流:並發刪除或更新的流式攝取

這個工作流假設有一個集群運行24/7的流作業來攝取數據，還有一個集群每小時、每天或特別運行一次，以刪除或更新一批記錄。對於這個用例，Databricks建議您:

  • 在表級啟用優化的寫操作

    改變表格<table_name|δ．｀table_path' >集TBLPROPERTIES（δ．autoOptimize．optimizeWrite＝真正的）

    這可以確保流寫入的文件數量以及刪除和更新作業的大小都是最佳的。

  • 在執行刪除或更新的作業上使用以下設置在會話級別上啟用自動壓縮。

    火花．sql（"set spark. databicks .delta. autocompact .enabled = true"）

    這允許文件在表中被壓縮。由於它發生在刪除或更新之後，因此可以降低事務衝突的風險。

常見問題(FAQ)

自動優化Z-Order文件?

自動優化隻對小文件執行壓縮。它沒有z值文件。

自動優化損壞的Z-Ordered文件?

自動優化忽略Z-Ordered文件。它隻壓縮新文件。

如果我在我流進的表上啟用了自動優化，並且並發事務與優化發生衝突，我的作業會失敗嗎?

不。導致自動優化失敗的事務衝突將被忽略，流將繼續正常運行。

我需要安排時間嗎優化工作，如果自動優化是在我的表上啟用?

對於大小大於10 TB的表，我們建議您保留優化在計劃上運行，以進一步鞏固文件，並減少Delta表的元數據。由於自動優化不支持z排序，您仍然應該調度優化.．.ZORDER通過定期運行的作業。

我有很多小文件。為什麼自動優化不壓縮他們?

默認情況下，auto optimization直到在一個目錄中發現超過50個小文件才開始壓縮。您可以通過設置更改此行為spark.databricks.delta.autoCompact.minNumFiles．擁有許多小文件並不總是一個問題，因為它可以導致更好的數據跳過，並且它可以幫助最小化合並和刪除期間的重寫。但是，有太多的小文件可能表明您的數據分區過度。