更快的SQL查詢與動態文件修剪三角洲湖

有兩個曆史悠久的優化技術進行查詢以更快的速度運行,數據係統:處理數據速度或者隻是過程較少的數據通過跳過無關的數據。這篇文章介紹了動態文件修剪(DFP),一個新的data-skipping技術,可以顯著提高查詢與選擇性連接在三角洲湖non-partition列在表上,現在在磚默認啟用運行時。”

---

檢查為什麼Lakehouse的數據是你的下一個數據倉庫的電子書發現磚的內部運作Lakehouse平台。Beplay体育安卓版本

---

在我們的實驗中使用TPC-DS數據和查詢與動態文件修剪,我們觀察到一個8 x加速查詢性能和36查詢2 x或更大的加速。

動態文件修剪的好處

數據工程師經常選擇一個劃分策略對於大型三角洲湖表允許查詢和跳過大量工作訪問這些表的數據從而大大加快查詢的執行時間。分區修剪可以發生在查詢編譯時查詢包括一個顯式的文字謂詞的分區鍵列也可以在運行時通過舉行動態分區修剪。

三角洲湖磚性能調優

除了消除數據分區的粒度,三角洲湖上動態磚跳過不必要的文件在可能的情況下。這可以實現,因為三角洲湖自動收集關於數據文件元數據由三角洲湖因此,數據可以跳過沒有數據文件訪問。修剪修剪之前動態文件,文件隻發生在查詢中包含一個文本值謂詞,但現在這工作文字過濾器以及加入過濾器。這意味著動態文件修剪現在允許星型模式查詢利用粒度數據跳過文件。

	每個分區	每個文件(僅三角洲湖在磚)
靜態(基於過濾器)	分區修剪	文件修剪
動態(基於連接)	動態分區修剪	動態文件修剪(新!)

動態文件修剪是如何工作的呢?

在我們深入的細節動態文件修剪是如何工作的,讓我們簡要介紹文件如何修剪與文字謂詞。

示例1 -靜態文件修剪

為簡單起見,讓我們考慮以下查詢來自TPC-DS模式來解釋文件修剪可以減少的大小掃描操作。

——第一季度選擇總和(ss_quantity)從store_sales在哪裏ss_item_sk在(40,41,42)

三角洲湖店的最大和最小值每一列在每個文件的基礎上。因此,文件的過濾值(40、41、42)秋季min-max範圍以外的ss_item_sk列完全可以跳過。我們可以減少值的長度範圍使用數據集群技術,如每個文件z值。這是很有吸引力的動態文件修剪因為有更嚴格的範圍每個文件導致跳過效果更好。因此,我們有z值ss_item_sk store_sales表的列。

在查詢Q1謂詞下推發生,因此文件作為metadata-operation部分發生的修剪掃描運營商也緊隨其後過濾器操作來刪除任何剩餘的不匹配的行。

當過濾謂詞包含文字,查詢編譯器可以嵌入這些文字值的查詢計劃。然而,當謂詞指定作為一個連接的一部分,通常是發現在大多數數據倉庫的查詢(例如,星型模式加入),需要不同的方法。在這種情況下,加入過濾事實表查詢編譯時間未知。

例子2 -星型模式沒有DFP加入

下麵是一個例子,與典型的星型連接查詢。

——第二季度選擇總和(ss_quantity)從store_sales加入項在ss_item_sk=i_item_sk在哪裏i_item_id=“AAAAAAAAICAAAAAA”

查詢Q1 Q2返回相同的結果,不過,它指定維度表上的謂詞(項),不是事實表(store_sales)。這意味著過濾的行store_sales通常做的一部分加入操作之前並不知道自ss_item_sk值後掃描和過濾器操作發生在項目表。

下麵是一個邏輯Q2的查詢執行計劃。

正如你所看到的在Q2的查詢計劃,隻有48 k行滿足加入標準未超過8.6 b必須從store_sales表讀取記錄。這意味著查詢運行時可以顯著減少以及掃描的數據量是否有推動下的一種方式加入過濾器進掃描store_sales。

例3 -星型模式與動態文件修剪

如果我們把Q2和啟用動態文件修剪我們可以看到,一個動態創建過濾器從構建的連接和傳遞到掃描store_sales操作。以下邏輯圖代表了這種優化計劃。

應用動態文件修剪的結果掃描操作store_sales是掃描的行數從86億減少到6600萬行。而改進是重要的,我們仍然閱讀比需要更多的數據,因為DFP操作粒度的文件而不是行。

我們可以觀察到的影響動態文件修剪通過觀察火花的DAG UI(片段)查詢和擴大掃描操作store_sales表。特別是,使用動態文件修剪這個查詢中消除超過99%的輸入數據,提高了查詢運行時從10年代小於1。

沒有動態文件修剪

與動態文件修剪

啟用動態文件修剪

DFP在磚自動啟用運行時6.1和更高版本,並應用如果查詢符合下列標準:

• 內部表(探針)加入了三角洲湖格式
• 內或LEFT-SEMI連接類型
• 連接策略是廣播散列連接
• 文件內部表的數量大於spark.databricks.optimizer.deltaTableFilesThreshold的值

DFP可以由下列配置參數:

• spark.databricks.optimizer。dynamicFilePruning(缺省為true)是主要的標誌,使優化器能夠壓低DFP過濾器。
• spark.databricks.optimizer.deltaTableSizeThreshold(缺省為10 gb)這個參數代表了最小大小字節的三角洲表探頭一側連接需要觸發動態文件的修剪。
• spark.databricks.optimizer.deltaTableFilesThreshold(默認是1000)這個參數表示的文件數的差值表探頭的連接需要觸發動態文件修剪。

注意:在本文中的實驗報告我們spark.databricks.optimizer.deltaTableFilesThreshold設置為100,以觸發DFP因為store_sales表有不到1000文件

與TPC-DS實驗和結果

理解動態文件修剪SQL工作負載的影響我們比較TPC-DS查詢的性能1 tb的數據集的分區模式。我們使用z值集群與事實表的日期和項目鍵列。幾乎每一個查詢中DFP提供良好的性能。36個103查詢我們觀察到加速超過2 x的最大加速實現大約8 x的一個查詢。下麵的圖表突出的影響DFP通過展示十大最改進查詢。

許多TPC-DS查詢使用一個典型的星型模式加入日期維度表和事實表(或多個事實表)來過濾日期範圍使其成為一個了不起的工作負載展示DFP的影響。在上麵的圖表給出的數據解釋了為什麼DFP如此有效的這組查詢,他們現在能夠減少大量的數據讀取。每個查詢都有加入過濾事實表的時間限製在一個範圍30至90天(事實表存儲5年的數據)。DFP對這個工作負載非常有吸引力的查詢可以訪問三個事實表。

開始使用動態文件修剪

動態文件修剪(DFP),現在在磚運行時的默認啟用一個新特性,可以顯著提高查詢的性能在三角洲湖。DFP非分區表上運行連接查詢時尤其有效。DFP提供的更好的性能通常是集群的相關數據,因此,用戶可能會考慮使用z值DFP效益的最大化。利用這些最新的性能優化,注冊一個今天磚賬戶!