前言

Apache Spark在6月份分佈了3.0.0版本，增加了許多效能優化方面的新特性。作為大資料分析的重要引擎，在SQL查詢優化方面的新特性值得期待和使用。Spark在SQL查詢方面的效能優化主要分為四個方向七個方面：

開發互動方向

• 新的Explain格式
• 所有join支援hints

動態優化

• 自適應查詢執行
• 動態分割槽裁剪

Catalyst提升

• 增強巢狀列的裁剪和下推
• 增強聚合的程式碼生成

基礎設施更新

• 支援新的Scala和Java版本

新特性介紹

這7個方面最值得關注的在於動態優化方向的更新，下面來著重講一下。

自適應查詢執行

自適應查詢執行通過使用執行時的統計資訊進行三個方面的優化:

• 根據統計資訊設定reducer的數量來避免記憶體和I/O資源的浪費

Spark2.4的版本中，Reducer的個數是通過配置檔案中的shuffle.partition來設定的，如圖有五個分割槽就有五個reducer來進行處理，由上圖可以看到，reducer0的任務量較小，reducer3的任務量較大，這樣整個任務的效率瓶頸就在reducer3上，任務分配的不平衡浪費了資源，降低了處理效率。

Spark3.0中，Reducer的個數進行了優化，同樣的五個分割槽任務最後只用了三個reducer進行了處理，這樣就不會造成上述reducer0空轉的資源浪費情況。

• 選擇更優的join策略來提高連線查詢效能

在大資料中，join策略可以大致分為三種，分別是HashJoin，BroadCastJon和MergeJoin。Spark會根據表資料的大小選擇合適的Join策略，但是當前的選擇都是基於靜態統計資訊的。

例如在Spark2.4中，如上兩種表的大小分別為100GB和80GB，通過靜態資訊統計，Spark在最後選擇了SortMergeJoin的策略。但是這個方案是基於兩個join表的大小為100和80GB大小的前提下的，並沒有參考table2經過條件過濾之後的大小。

在Spark3.0中，加入了動態資訊統計，引擎不僅會掌握table1和table2的靜態統計資訊，還會在執行過程中，適時收集兩表的資料量的變化，及時調整策略。如上例子，table2原本有80GB的資料參與join操作，但是經過過濾操作，有效的參與join的資料只有80MB，因此這樣的資料量更適合Broadcast Join策略，所以在Spark3.0中會及時調整。

• 優化join資料來避免不平衡查詢造成的資料傾斜

Join的時間取決於最大的分割槽join時間，因此如上圖所示，TableA和TableB的join時間取決於partition2，因為TableA中的資料傾斜導致了整個表連線任務的耗時操作。

在Spark3.0中，通過對傾斜資料的自適應重分割槽，解決了傾斜分割槽導致的整個任務的效能瓶頸，提高了查詢處理效率。

動態分割槽裁剪

動態分割槽裁剪是從下推演化而來，下推資料靜態裁剪，通過將條件下推至資料來源，從而減小了上層運算元計算的資料量（下推可以參考我之前的文章）。動態裁剪是在靜態裁剪的基礎上，加入了執行時的資料裁剪。

在Spark2.4中的靜態裁剪（條件下推）如上圖所示，通過將條件下推到join操作之前，減小參與連線操作的資料量從而達到效能的優化。

但是對於參與連線的左表來說，並沒有起到提前過濾資料的作用，這樣效能提升並不大。在Spark3.0中，加入了動態分割槽裁剪優化，將其中一個表（本例中的小表）過濾後的資料作為新的過濾條件下推到另一個表（本例中的大表）中，從而起到對大表的執行時過濾作用。這樣就大大減少了兩表參與join的資料量，從而提高了查詢效能。

總結

Spark3.0的優化效能遠不止這些，當然也不意味著所有的場景都適合進行優化或者能夠產生明顯的效能提升，還需要結合業務和資料進行探索和使用。

參考：SQL Performance Improvements At a Glance in Apache Spark3.0 , Kazuaki Ishizaki, IBM Research

歡迎關注wx公眾號：DLab資料實驗室關注更多知識乾貨～