通過文件管理優化性能

為了提高查詢速度，Databricks上的Delta Lake支持優化存儲在雲存儲中的數據布局。Databricks上的Delta Lake支持兩種布局算法:bin packing和z - ordered。

本文描述了:

如何運行優化命令。
兩種布局算法的工作原理。
如何清理陳舊的表快照。

的常見問題解答解釋為什麼優化不是自動的，並包括關於運行優化命令的頻率的建議。
關於演示優化好處的筆記本，請參見優化的例子．
有關Delta Lake on Databricks SQL優化命令參考信息，請參見
- 磚運行時7。x,上圖:優化(Delta Lake on Databricks)

壓實(裝箱)

Databricks上的Delta Lake可以提高從表中讀取查詢的速度。提高速度的一種方法是將小文件合並為大文件。方法觸發壓縮優化命令:

               優化δ．' /數據/事件｀
              

               從delta.tables進口＊deltaTable＝DeltaTable．forPath（火花，“/數據/事件”）deltaTable．優化（）．executeCompaction（）
              

               進口io．δ．表．＿瓦爾deltaTable＝DeltaTable．forPath（火花，“/數據/事件”）deltaTable．優化()。executeCompaction（）
              

或

               優化事件
              

               從delta.tables進口＊deltaTable＝DeltaTable．forName（火花，“事件”）deltaTable．優化（）．executeCompaction（）
              

               進口io．δ．表．＿瓦爾deltaTable＝DeltaTable．forName（火花，“事件”）deltaTable．優化()。executeCompaction（）
              

如果您有大量的數據，並且隻想優化其中的一個子集，您可以使用在哪裏：

               優化事件在哪裏日期> =“2022-11-18”
              

               從delta.tables進口＊deltaTable＝DeltaTable．forName（火花，“事件”）deltaTable．優化（）．在哪裏（“日期= 2021-11-18”）．executeCompaction（）
              

               進口io．δ．表．＿瓦爾deltaTable＝DeltaTable．forName（火花，“事件”）deltaTable．優化()。在哪裏（“日期= 2021-11-18”）.executeCompaction（）
              

請注意

裝箱優化冪等，這意味著如果在同一個數據集上運行兩次，那麼第二次運行沒有效果。
Bin-packing的目的是根據磁盤上的大小生成均勻平衡的數據文件，而不是每個文件的元組數量。然而，這兩個指標通常是相關的。
用於執行Python和Scala api優化操作在Databricks Runtime 11.0及以上版本可用。

Delta表的讀取器使用快照隔離，這意味著它們不會被中斷優化從事務日誌中刪除不必要的文件。優化不對表進行與數據相關的更改，因此在優化結果是一樣的。執行優化在作為流源的表上不影響將此表作為源的任何當前或未來流。優化返回操作刪除的文件和添加的文件的文件統計信息(最小值、最大值、總數等)。優化統計信息還包含z - ordered統計信息、優化的批數量和分區。

您還可以使用自動壓縮小文件自動優化Databricks．

數據不

在將數據寫入Delta表時，會自動收集數據跳過信息。Databricks上的Delta Lake利用查詢時的這些信息(最小值和最大值)提供更快的查詢。不需要配置數據跳過;隻要適用，該特性就會被激活。然而，它的有效性取決於數據的布局。為了達到最佳效果，請使用z值．

關於Delta Lake在Databricks上的數據跳過和z順序的好處的例子，請參閱優化的例子．默認情況下，Databricks上的Delta Lake收集表模式中定義的前32列的統計信息。方法可以更改此值表屬性delta.dataSkippingNumIndexedCols．在寫入文件時，添加更多的列來收集統計信息會增加更多的開銷。

收集長字符串上的統計信息是一項昂貴的操作。要避免在長字符串上收集統計信息，可以配置table屬性delta.dataSkippingNumIndexedCols避免包含長字符串的列或將包含長字符串的列移動到大於delta.dataSkippingNumIndexedCols使用改變表格改變列．看到的:

磚運行時7。x,上圖:ALTER TABLE

為了收集統計信息，將嵌套列中的每個字段視為單獨的列。

你可以在博客中閱讀更多關於這篇文章的內容:用Databricks Delta在秒內處理pb級數據．

z值(多維聚簇)

z值是一個技術將相關信息合並到同一組文件中。Delta Lake在Databricks跳過數據的算法中自動使用了這種共局部性。這種行為大大減少了Databricks上Delta Lake需要讀取的數據量。對於Z-Order數據，您可以在ZORDER通過條款:

             優化事件在哪裏日期> =current_timestamp（）-時間間隔1一天ZORDER通過（eventType）
            

如果您希望一個列經常用於查詢謂詞，並且該列具有高基數性(即有大量不同的值)，則使用ZORDER通過．

可以指定多個列ZORDER通過作為一個逗號分隔的列表。然而，每增加一列，局部性的有效性就會下降。對沒有收集統計信息的列進行z排序將是無效的，而且會浪費資源。這是因為數據跳過需要列本地統計信息，比如最小值、最大值和計數。您可以通過重新排序模式中的列來配置某些列上的統計信息收集，也可以增加要收集統計信息的列的數量。看到數據不．

請注意

z值是不是冪等但目標是一個增量操作。z順序所花費的時間並不能保證在多次運行中減少。但是，如果沒有新數據添加到一個隻有Z-Ordered的分區，那麼該分區的另一個Z-Ordered將不起任何作用。
z - ordered旨在生成相對於元組數量的均勻平衡的數據文件，但不一定是磁盤上的數據大小。這兩個度量通常是相關的，但有時情況並非如此，從而導致優化任務時間的傾斜。
例如，如果你ZORDER通過日期而且您最近的記錄都比過去的記錄寬得多(例如更長的數組或字符串值)，因此可以預期優化作業的任務持續時間和產生的文件大小都是傾斜的。然而，這隻是一個問題優化命令本身;它不應該對後續查詢有任何負麵影響。

優化文件大小

本節描述如何調優Delta表中的文件大小。

設定目標尺寸

請注意

在Databricks Runtime 8.2及以上版本中可用。

如果要調優Delta表中的文件大小，請設置表屬性delta.targetFileSize到想要的尺寸。如果設置了此屬性，所有數據布局優化操作都將盡力生成指定大小的文件。這裏的例子包括optimize with壓實(裝箱)或z值(多維聚簇)，汽車壓實,優化寫道．

表屬性

delta.targetFileSize

類型:以字節或更高單位表示的大小。

目標文件大小。例如,104857600(字節)或100 mb．

默認值:無

對於現有的表，可以使用SQL命令設置和取消設置屬性修改表集TBL屬性．您還可以在使用Spark會話配置創建新表時自動設置這些屬性。看到表屬性獲取詳細信息。

為了盡量減少手動調優的需要，Databricks可以根據在表上操作的工作負載自動調優Delta表的文件大小。數據庫可以自動檢測一個Delta表是否有頻繁合並重寫文件並可能選擇減少已重寫文件大小的操作，以預期將來進一步的文件重寫。例如，當執行合並操作，如果表上最後10個之前的操作中有9個也是merge，那麼優化寫道而且汽車壓實所使用的合並(如果啟用)將生成比不啟用更小的文件大小。這有助於減少未來的持續時間合並操作。

在發生一些重寫操作後，自動調優將被激活。但是，如果您預期一個Delta表將經曆頻繁合並，更新,或刪除操作並希望立即進行此調優，則可以通過設置table屬性顯式調優用於重寫的文件大小delta.tuneFileSizesForRewrites．將此屬性設置為真正的對於表上的所有數據布局優化操作，始終使用較小的文件大小。將其設置為假永遠不要調優到更小的文件大小，也就是說，防止自動檢測被激活。

表屬性

delta.tuneFileSizesForRewrites

類型:布爾

是否調優文件大小以優化數據布局。

默認值:無

對於現有的表，可以使用SQL命令設置和取消設置屬性修改表集TBL屬性．您還可以在使用Spark會話配置創建新表時自動設置這些屬性。看到表屬性獲取詳細信息。

根據表大小自動調優

請注意

在Databricks Runtime 8.4及以上版本中可用。

為了盡量減少手動調優的需要，Databricks會根據表的大小自動調優Delta表的文件大小。Databricks將對較小的表使用較小的文件大小，對較大的表使用較大的文件大小，這樣表中的文件數量就不會增長得太大。方法調優的表不會自動調優特定的目標大小或者基於頻繁重寫的工作負載。

目標文件大小基於Delta表的當前大小。對於小於2.56 TB的表，自動調優的目標文件大小是256 MB。對於大小在2.56 TB到10 TB之間的表，目標文件大小將從256 MB線性增長到1gb。對於大於10 TB的表，目標文件大小為1 GB。

請注意

當表的目標文件大小增加時，現有文件不會被重新優化為更大的文件優化命令。因此，一個大表可能總是有一些小於目標大小的文件。方法將這些較小的文件優化為較大的文件，如果需要將這些文件優化為較大的文件，可以為表配置固定的目標文件大小delta.targetFileSize表屬性。

當以增量方式寫入表時，根據表的大小，目標文件大小和文件計數將接近以下數字。該表中的文件計數隻是一個示例。實際的結果取決於許多因素。

表的大小	目標文件大小	表中文件的大致數目
10 GB	256 MB	40
1 TB	256 MB	4096
2.56結核病	256 MB	10240
3結核病	307 MB	12108
5結核病	512 MB	17339
7結核病	716 MB	20784
10 TB	1 GB	24437
20結核病	1 GB	34437
50個結核病	1 GB	64437
100年結核病	1 GB	114437

筆記本電腦

有關優化好處的示例，請參見優化的例子．

提高交互查詢性能

Delta Lake提供了更多的機製來提高查詢性能。

管理數據近因

在每次查詢開始時，Delta表自動更新到表的最新版本。這個過程可以在筆記本中觀察到，當命令狀態報告:更新的δ表的狀態．然而，當在表上運行曆史分析時，您可能並不一定需要最新的數據，特別是對於頻繁攝入流數據的表。在這些情況下，可以在Delta表的過期快照上運行查詢。這種方法可以降低從查詢中獲取結果的延遲。

您可以通過設置Spark會話配置來配置表數據的過時程度spark.databricks.delta.stalenessLimit例如，對於時間字符串值，1 h，15米，1 d分別持續1小時、15分鍾和1天。此配置是特定於會話的，因此不會影響從其他筆記本、作業或BI工具訪問該表的其他用戶。此外，該設置不會阻止表的更新;它隻是防止查詢必須等待表更新。更新仍然發生在後台，並且將在集群中公平地共享資源。如果過期限製超過，則查詢將在表狀態更新時阻塞。

針對低延遲查詢的增強檢查點

三角洲湖寫道檢查點作為Delta表在優化頻率下的聚合狀態。這些檢查點作為計算表的最新狀態的起點。如果沒有檢查點，Delta Lake將不得不讀取表示提交到事務日誌的大量JSON文件集合(“Delta”文件)，以計算表的狀態。此外，Delta Lake還使用列級統計信息執行數據不存儲在檢查點中。

重要的

三角洲湖檢查站不同於結構化流檢查點．

在Databricks Runtime 7.2及以下版本中，列級統計信息作為JSON列存儲在Delta Lake檢查點中。

在Databricks Runtime 7.3 LTS及以上版本中，列級統計信息以結構的形式存儲。結構格式使Delta Lake讀取速度更快，因為:

Delta Lake不執行昂貴的JSON解析來獲取列級統計信息。
Parquet列修剪功能顯著減少了讀取列統計信息所需的I/O。

struct格式支持一係列優化，這些優化將Delta Lake讀操作的開銷從幾秒減少到幾十毫秒，這大大減少了短查詢的延遲。

在檢查點中管理列級統計信息

您可以使用表屬性管理如何在檢查點中寫入統計信息delta.checkpoint.writeStatsAsJson而且delta.checkpoint.writeStatsAsStruct．如果兩個表屬性都是假湖,δ不能執行數據跳過。

在Databricks Runtime 7.3 LTS及以上版本中:

批處理寫JSON和結構格式的統計數據。delta.checkpoint.writeStatsAsJson是真正的．
delta.checkpoint.writeStatsAsStruct默認情況下未定義。
閱讀器在可用時使用struct列，否則退回到使用JSON列。

對於流媒體寫道:

Databricks Runtime 7.5及以上版本:以JSON格式和struct格式寫入統計數據。
Databricks Runtime 7.3 LTS和7.4:隻以JSON格式寫入統計數據(以最小化檢查點對寫入延遲的影響)。要編寫結構格式，請參見與檢查點中的統計數據進行權衡．

在Databricks Runtime 7.2及以下版本中，閱讀器隻使用JSON列。因此,如果delta.checkpoint.writeStatsAsJson是假,這樣的讀者不能執行數據跳過。

重要的

增強的檢查點不會破壞與開源Delta Lake閱讀器的兼容性。然而,設置delta.checkpoint.writeStatsAsJson來假可能會對三角洲湖的專有閱讀器產生影響。聯係您的供應商了解更多關於性能影響的信息。

與檢查點中的統計數據進行權衡

由於在檢查點中寫入統計信息是有成本的(即使是大型表，通常也小於1分鍾)，因此在寫入檢查點所花費的時間和與Databricks Runtime 7.2及以下版本的兼容性之間需要權衡。如果您能夠將所有工作負載升級到Databricks Runtime 7.3 LTS或更高版本，則可以通過禁用遺留JSON統計信息來降低編寫檢查點的成本。下表總結了這種權衡。

如果數據跳過在應用程序中沒有用處，那麼可以將這兩個屬性都設置為false，這樣就不會收集或寫入任何統計信息。我們不推薦這種配置。

		writeStatsAsStruct
		假	真正的
writeStatsAsJson	假	沒有數據不	Databricks Runtime 7.3 LTS及以上版本的更快查詢稍慢的檢查點在Databricks Runtime 7.2及以下版本的讀取器中沒有數據跳過
writeStatsAsJson	真正的	Databricks Runtime 7.2及以下版本慢查詢	Databricks Runtime 7.3 LTS及以上版本的更快查詢保持與Databricks Runtime 7.2及以下版本的閱讀器的兼容性檢查點具有最高的延遲(以秒為單位)

為結構化流查詢啟用增強檢查點

如果結構化流工作負載沒有低延遲要求(亞分鍾延遲)，可以通過運行以下SQL命令啟用增強檢查點:

               改變表格［<表格-的名字>|δ．' <路徑-來-表格>”］集TBLPROPERTIES（“delta.checkpoint.writeStatsAsStruct”＝“真正的”）
              

如果您不使用Databricks Runtime 7.2或以下版本來查詢數據，您還可以通過設置以下表屬性來改善檢查點寫延遲:

               改變表格［<表格-的名字>|δ．' <路徑-來-表格>”］集TBLPROPERTIES（“delta.checkpoint.writeStatsAsStruct”＝“真正的”，“delta.checkpoint.writeStatsAsJson”＝“假”）
              

禁用不使用stats結構寫檢查點的集群的寫操作

在Databricks Runtime 7.2及以下版本中寫入檢查點沒有stats結構，它阻止了對Databricks Runtime 7.3 LTS閱讀器的優化。

要阻止運行Databricks Runtime 7.2及以下版本的集群寫入Delta表，可以使用upgradeTableProtocol方法:

                從delta.tables進口DeltaTableδ＝DeltaTable．forPath（火花，“path_to_table”）#或DeltaTable.forNameδ．upgradeTableProtocol（1，3.）
               

                進口io．δ．表．DeltaTable瓦爾δ＝DeltaTable．forPath（火花，“path_to_table”）/ /或DeltaTable.forNameδ．upgradeTableProtocol（1，3.）
               

警告

應用upgradeTableProtocol方法阻止運行Databricks Runtime 7.2及以下版本的集群寫入您的表，此更改是不可逆的。我們建議隻有在您決定使用新格式之後才升級您的表。您可以通過創建一個shallow來嚐試這些優化克隆您的表使用Databricks Runtime 7.3 LTS。

升級表寫入器版本後，寫入器必須遵守您的設置“delta.checkpoint.writeStatsAsStruct”而且“delta.checkpoint.writeStatsAsJson”．

下表總結了如何利用Databricks Runtime的不同版本、表協議版本和編寫器類型中的增強檢查點。

	沒有協議升級			與協議升級
	Databricks運行時7.2及以下的編寫器	Databricks Runtime 7.3 LTS及以上批處理程序	Databricks運行時7.3 LTS及以上流寫入器	Databricks運行時7.2及以下的編寫器	Databricks Runtime 7.3 LTS及以上批處理程序	Databricks運行時7.3 LTS及以上流寫入器
Databricks運行時7.2及以下閱讀器性能	沒有改善	沒有改善	沒有改善	不能使用的作家	沒有改善	沒有改善
Databricks Runtime 7.3 LTS及以上閱讀器性能	沒有改善	改進的默認情況下	通過表屬性選擇入(1）	不能使用的作家	改進的默認情況下	通過表屬性選擇入(1）

(1）設置表屬性“delta.checkpoint.writeStatsAsStruct”＝“真正的”

禁用使用舊檢查點格式的集群寫操作

Databricks Runtime 7.2及以下版本的寫入器可以寫入舊的格式檢查點，這將阻止對Databricks Runtime 7.3 LTS寫入器的優化。要阻止運行Databricks Runtime 7.2及以下版本的集群寫入Delta表，可以使用upgradeTableProtocol方法:

                從delta.tables進口DeltaTableδ＝DeltaTable．forPath（火花，“path_to_table”）#或DeltaTable.forNameδ．upgradeTableProtocol（1，3.）
               

                進口io．δ．表．DeltaTable瓦爾δ＝DeltaTable．forPath（火花，“path_to_table”）/ /或DeltaTable.forNameδ．upgradeTableProtocol（1，3.）
               

警告

應用upgradeTableProtocol方法阻止運行Databricks Runtime 7.2及以下版本的集群寫入您的表。這種變化是不可逆轉的。因此，我們建議隻有在使用新格式之後才升級表。您可以通過使用Databricks Runtime 7.3 LTS創建表的淺克隆來嚐試這些優化:

磚運行時7。x,上圖:創建表克隆

常見問題(FAQ)

為什麼不是優化自動的嗎?

的優化操作啟動許多Spark作業，以便通過壓縮優化文件大小(並可選地執行z - ordered)。因為很多優化做的是緊湊的小文件，你必須先積累許多小文件，這個操作才有效果。因此,優化操作不是自動運行的。

此外,運行優化,尤其是在ZORDER，是一項耗費時間和資源的操作。如果磚優化自動或等待批量寫出數據，它將取消運行低延遲Delta Lake流(其中Delta表是源)的能力。許多客戶擁beplay体育app下载地址有從未優化過的Delta表，因為他們隻從這些表中流數據，排除了查詢的好處優化將提供。

最後，Delta Lake自動收集關於寫入表的文件的統計信息(無論是通過優化操作或不)。這意味著無論表或分區是否具有優化運行它。

我應該多長時間跑一次優化?

當你選擇跑步的頻率時優化在美國，性能和成本之間需要權衡。你應該跑優化如果您想要更好的終端用戶查詢性能(由於資源的使用，必然要付出更高的代價)，那麼更經常使用。如果你想優化成本，你應該少運行它。

我們建議你從跑步開始優化每天(最好是在現貨價格較低的晚上)。然後從那裏修改你的工作。

要運行的最佳實例類型是什麼優化(裝箱和z - order)在?

這兩個操作都是CPU密集型操作，進行大量的Parquet解碼和編碼。

我們推薦計算優化實例類型。優化還可以從附加的ssd中獲益。