自適應查詢執行:加速運行時引發的SQL

Lakehouse讀取的數據探索為什麼lakehouses未來的數據架構和數據倉庫的父親,Bill Inmon。

---

這是一個聯合工程磚Apache引發的工程團隊之間的工作

——Wenchen風扇,範龍佩(Herman van Hovell和瑪麗安薛

參見下麵AQE筆記本演示解決方案覆蓋或深入研究磚的內部運作Lakehouse平台Beplay体育安卓版本

多年來,有一個廣泛和持續努力改善火花SQL查詢優化器和規劃師為了生成高質量的查詢執行計劃。最大的一個改進是基於成本優化的框架,利用各種數據的收集和統計數據(例如,行數,不同值的數量,NULL值,最大/最小值,等等)來幫助火花選擇更好的計劃。這些基於成本的優化技術的例子包括選擇正確的連接類型(廣播散列連接與排序合並連接),選擇正確的構建方麵的散列連接,或調整多路連接的連接順序。然而,過時的統計和不完美的基數估計值可能導致次優的查詢計劃。自適應查詢執行,在即將到來的新的Apache火花^TM3.0版本7.0在磚和可用的運行時,為了解決這樣的問題,現在看來重新優化和調整查詢計劃基於運行時統計數據收集在查詢執行的過程。

自適應查詢執行(AQE)框架

適應查詢執行的一個最重要的問題是什麼時候再優化。火花運營商往往管線式和並行執行流程。然而,洗牌或廣播交流打破了這種管道。我們稱之為實體化點和使用術語“查詢階段”來表示這些物質化點部分有界的一個查詢。每個查詢階段實現它的中間結果和以下階段隻能繼續如果所有運行實體化的並行過程已經完成。這對於以提供了一種自然的機會,因為這是當數據統計所有分區可用和連續操作還沒有開始。

查詢開始時,自適應查詢執行框架首先開始葉階段階段,不依賴於任何其他階段。當一個或多個階段完成實體化,框架標誌著他們在物理查詢計劃並更新邏輯完成相應的查詢計劃,與運行時統計數據從完成檢索階段。框架基於這些新數據,然後運行優化器(邏輯優化規則的選擇列表),物理規劃,以及物理優化規則,其中包括常規的物理規則和adaptive-execution-specific規則,如合並分區,斜加入處理,等。現在,我們已經有了一個新優化的查詢計劃的完成階段,自適應框架將執行搜索並執行新的查詢都被物化階段的兒童階段,並重複上述execute-reoptimize-execute過程,直到整個查詢完成。

在火花3.0中,AQE框架附帶三個特點:

• 動態合並調整分區
• 動態切換連接策略
• 動態優化傾斜連接

下麵的部分將詳細討論這三個特性。

動態合並調整分區

運行查詢時火花處理非常大的數據,洗牌通常有一個非常重要的對查詢性能的影響在許多其他的事情。洗牌是一項昂貴的操作,因為它需要在整個網絡中傳遞數據,以便數據重新分配在下遊運營商要求的一種方式。

混亂的一個重要性質是分區的數量。最好的分區數量是數據依賴,但數據大小可能不同不同階段階段,查詢來查詢,讓這個數字很難調整:

1. 如果有太少的分區,每個分區的數據量可能非常大,和任務處理這些大分區可能需要泄漏數據到磁盤(例如,當涉及到排序或聚合),查詢結果,減緩。
2. 如果有太多的分區,每個分區的數據量可能非常小,而且會有很多小的網絡數據獲取閱讀洗牌塊,也會減緩查詢由於低效的I / O模式。有大量的任務也讓更多的火花任務調度器的負擔。

為了解決這個問題,我們可以設置一個相對大量的洗牌分區開始,然後相鄰小分區合並成更大的分區在運行時通過觀察洗牌文件數據。

舉個例子,假設我們正在運行的查詢選擇馬克斯(i)由j。從資源組輸入數據(資源是很小所以分組之前隻有兩個分區。最初的洗牌分區號設置為5,所以本地分組後,部分分組數據重組成五個分區。沒有AQE,火花將五項任務開始做最後的聚合。然而,這裏有三個非常小的分區,這將是一個浪費開始對每一個單獨的任務。

相反,AQE聚集成一個和這三個小分區,因此,最後聚合現在隻需要執行三個任務,而不是5個。

動態切換連接策略

火花支持許多連接策略,其中廣播散列連接通常是最高效的如果一方加入可以適合在內存中。,出於這個原因,引發計劃廣播散列連接,如果連接關係的估計規模低於broadcast-size閾值。但是很多事情可以讓這個大小估計出錯——比如一個選擇性濾波器的存在,或者是一係列複雜的連接關係運營商除了掃描。

為了解決這個問題,現在AQE重新計劃加入策略在運行時基於最準確的連接關係的大小。在下麵的例子中,我們可以看到右邊的加入是發現小於估計和廣播也足夠小,所以AQE後以靜態計劃排序合並連接現在轉換為一個散列連接播放。

廣播的散列連接轉換在運行時,我們可以進一步優化常規局部轉移(即洗牌。洗牌,讀取每個映射器上而不是每個減速器的基礎上)來減少網絡流量。

動態優化傾斜連接

數據傾斜時數據集群分區的分布是不均勻的。嚴重的傾斜可以顯著降低查詢性能,尤其是連接。AQE傾斜連接優化檢測這種傾斜自動從洗牌文件數據。然後將分區分成小subpartitions傾斜,將加入到相應的分區分別從另一側。

讓我們把這個表聯接表B的例子,在這表有一個分區A0顯著大於其他分區。

沒有這種優化,會有四個任務排序合並連接一個任務將運行更長的時間。這種優化後,會有五個任務運行加入,但每個任務需要大致相同的時間,導致整體更好的性能。

從AQE TPC-DS性能收益

在我們的實驗中使用TPC-DS數據和查詢,適應了一個8 x加速查詢執行的查詢性能和32查詢有超過1.1倍加速下麵的圖10 TPC-DS查詢擁有最AQE性能改進。

大多數這些改進來自動態分區合並和動態連接策略切換自隨機生成TPC-DS數據沒有傾斜。然而我們看到更大的改進在生產工作負載AQE是杠杆的所有三個特征。

使AQE

可以通過設置啟用SQL配置spark.sql.adaptive AQE。啟用為true(默認錯誤引發3.0),並應用如果查詢符合下列標準:

• 它不是一個流媒體查詢
• 它包含至少一個交易所(通常當有一個連接、聚集或窗口操作符)或子查詢

通過查詢優化較少依賴靜態統計,AQE解決了一個最偉大的鬥爭引發基於成本的優化——之間的平衡數據收集開銷和估計精度。達到最好的估計精度和計劃的結果,通常是需要保持詳細的,最新的統計數據和一些昂貴的收集,如列直方圖,可以用於提高選擇性和基數估計或檢測數據傾斜。AQE在很大程度上消除這種統計的必要性以及手工調優工作。最重要的是,AQE也使SQL查詢優化更有彈性的存在任意udf和不可預測的數據集的變化,例如,數據大小的突然增加或減少,頻繁和隨機數據傾斜等等。沒有必要提前“知道”你的數據。AQE將算出的數據,提高查詢計劃的查詢運行時,速度分析和係統性能提高查詢性能。

在我們了解更多關於火花3.0預覽網絡研討會。今天嚐試AQE火花3.0免費磚7.0作為我們的磚運行時的一部分。