最佳實踐:三角洲湖

本文描述了使用Delta Lake時的最佳實踐。

提供數據位置提示

如果您希望在查詢謂詞中經常使用一個列，並且該列具有高基數性(即，有大量不同的值)，則使用z值通過．Delta Lake根據列值自動布局文件中的數據，並在查詢時使用布局信息跳過不相關的數據。

詳細信息請參見數據跳躍與z順序索引三角洲湖．

緊湊的文件

如果您不斷地向Delta表寫入數據，隨著時間的推移，它將積累大量的文件，特別是當您以小批量方式添加數據時。這可能會對表讀取的效率產生不利影響，而且還會影響文件係統的性能。理想情況下，應該定期將大量的小文件重寫為少量的大文件。這就是所謂的壓縮。

控件可以壓縮一個表優化命令。

請注意

該操作不會刪除舊文件。要刪除它們，請運行真空命令。

替換表的內容或模式

有時您可能想要替換一個Delta表。例如:

  • 您發現表中的數據不正確，想要替換內容。

  • 您希望重寫整個表以進行不兼容的模式更改(例如更改列類型)。

雖然您可以刪除Delta表的整個目錄，並在相同的路徑上創建一個新表，但它是不推薦因為:

  • 刪除目錄效率不高。一個包含非常大文件的目錄可能需要數小時甚至數天才能刪除。

  • 您將丟失刪除文件中的所有內容;如果刪除了錯誤的表，就很難恢複。

  • 目錄刪除不是原子的。在刪除表時，讀取表的並發查詢可能會失敗或隻看到部分表。

  • 您可能會在S3上遇到潛在的一致性問題，這隻是最終的一致性。

如果不需要更改表模式，也可以更改刪除從Delta表中獲取數據並插入新數據，或者更新該表用來修複不正確的值。

如果要更改表模式，可以原子地替換整個表。例如:

dataframe．寫＼．格式（“δ”）＼．模式（“覆蓋”）＼．選項（“overwriteSchema”，“真正的”）＼．saveAsTable（“<表>”）#管理表dataframe．寫＼．格式（“δ”）＼．模式（“覆蓋”）＼．選項（“overwriteSchema”，“真正的”）＼．選項（“路徑”，“< your-table-path >”）＼．saveAsTable（“<表>”）#外部表
取代表格<你的-表格>使用δ作為選擇.．.——托管表取代表格<你的-表格>使用δ位置“< your-table-path >”作為選擇.．.——外部桌子
dataframe．寫．格式（“δ”）．模式（“覆蓋”）．選項（“overwriteSchema”，“真正的”）．saveAsTable（“<表>”）//管理表dataframe．寫．格式（“δ”）．模式（“覆蓋”）．選項（“overwriteSchema”，“真正的”）．選項（“路徑”，“< your-table-path >”）．saveAsTable（“<表>”）//外部表

這種方法有很多好處:

  • 重寫表要快得多，因為它不需要遞歸地列出目錄或刪除任何文件。

  • 該表的舊版本仍然存在。如果您刪除了錯誤的表，您可以使用時間旅行．

  • 這是一個原子操作。並發查詢在刪除表時仍然可以讀取表。

  • 由於Delta Lake ACID事務保證，如果覆蓋表失敗，表將處於以前的狀態。

  • 在S3上您不會遇到任何一致性問題，因為您不刪除文件。

此外，如果要刪除舊文件以節省覆蓋表後的存儲成本，可以使用真空刪除它們。它針對文件刪除進行了優化，通常比刪除整個目錄更快。

火花緩存

Databricks不建議您使用火花緩存原因如下:

  • 您將丟失任何數據跳過，這些數據跳過可能來自添加在緩存之上的附加過濾器DataFrame．

  • 如果使用不同的標識符訪問表，則緩存的數據可能不會更新spark.table (x) .cache ()然後用spark.write.save(/一些/路徑)．

Delta Lake和Parquet在Apache Spark上的差異

Delta Lake自動處理以下操作。千萬不要手動執行這些操作:

  • 刷新表格: Delta表總是返回最新的信息，所以不需要調用刷新表格更改後手動操作。

  • 添加和刪除分區: Delta Lake自動跟蹤表中存在的分區集，並在添加或刪除數據時更新列表。因此，沒有必要跑改變表格(添加|刪除)分區或MSCK．

  • 加載單個分區:不需要直接讀分區。例如，你不需要跑spark.read.format .load(“鋪”)(“/數據/日期= 2017-01-01”)．相反，使用在哪裏子句用於數據跳過，例如spark.read.table(“< table_name >”)。(“日期＝“2017-01-01”)．

  • 請勿手動修改數據文件: Delta Lake使用事務日誌原子地向表提交更改。不要直接修改、添加或刪除Delta表中的Parquet數據文件，因為這可能導致數據丟失或表損壞。

提高三角洲湖泊合並的性能

您可以使用以下方法減少合並所花費的時間:

  • 減少匹配的搜索空間:默認為合並操作將搜索整個Delta表以查找源表中的匹配項。加快速度的一種方法合並是通過在匹配條件中添加已知約束來縮小搜索空間。例如，假設您有一個表，該表是由國家而且日期你想用合並更新最後一天和特定國家的信息。添加以下條件可以使查詢更快，因為它隻在相關分區中查找匹配項:

    事件．日期＝當前日期（）和事件．國家＝“美國”

    此外，該查詢還減少了與其他並發操作發生衝突的可能性。看到數據庫上的隔離級別和寫入衝突欲知詳情。

  • 緊湊的文件:如果數據存儲在許多小文件中，讀取數據以搜索匹配可能會變慢。您可以將小文件壓縮成大文件以提高讀吞吐量。看到緊湊的數據文件與優化三角洲湖獲取詳細信息。

  • 為寫操作控製shuffle分區:合並操作多次打亂數據以計算和寫入更新的數據。用於shuffle的任務數量由Spark會話配置控製spark.sql.shuffle.partitions．設置該參數不僅可以控製並行度，還可以決定輸出文件的數量。增大該值會增加並行度，但也會生成更多的小數據文件。

  • 啟用優化的寫入:對於分區表，合並可以產生的小文件數量遠遠大於shuffle分區的數量。這是因為每個shuffle任務都可以在多個分區中寫入多個文件，這可能成為性能瓶頸。您可以通過啟用來減少文件數量優化的寫．

    請注意

    在Databricks Runtime 7.4及以上版本中，優化的寫自動啟用。合並對分區表的操作。

  • 調優表中的文件大小:在Databricks運行時8.2及以上版本中，Databricks可以自動檢測Delta表是否有頻繁合並重寫文件的操作，可能會選擇減少已重寫文件的大小，以預期將來會進一步重寫文件。請參閱有關調優文件大小獲取詳細信息。

  • 低Shuffle合並:在Databricks Runtime 9.0及以上版本，低Shuffle合並的優化實現合並這為大多數常見工作負載提供了更好的性能。此外，它還保留了現有的數據布局優化，例如z值在未修改的數據上。

管理數據近時性

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

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

用於低延遲查詢的增強檢查點

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

重要的

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

在Databricks Runtime 7.3 LTS及以上版本中，列級統計數據存儲為結構體和JSON(為了向後兼容)。結構體格式使Delta Lake讀取速度更快，因為:

  • Delta Lake不執行昂貴的JSON解析來獲得列級統計信息。

  • Parquet列修剪功能顯著減少了讀取列統計信息所需的I/O。

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

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

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

  • 批處理寫入JSON和struct格式的統計信息。delta.checkpoint.writeStatsAsJson是真正的．

  • delta.checkpoint.writeStatsAsStruct默認情況下未定義。

  • 讀者在struct列可用時使用它，否則會退回到使用JSON列。

對於流媒體寫入:

  • Databricks運行時7.5及以上版本:以JSON格式和struct格式編寫統計數據。

  • Databricks Runtime 7.3 LTS和7.4:隻以JSON格式寫統計數據(以最小化檢查點對寫延遲的影響)。若還要編寫結構體格式，請參見為結構化流查詢啟用增強檢查點．

重要的

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

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

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

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

您還可以通過設置以下表屬性來改善檢查點寫延遲:

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

如果數據跳過在應用程序中沒有用處，可以將這兩個屬性都設置為false。然後沒有統計數據被收集或寫入。Databricks不推薦此配置。