前言
apache spark在6月份分布了3.0.0版本，增加了許多效能優化方面的新特性。作為大資料分析的重要引擎，在sql查詢優化方面的新特性值得期待和使用。spark在sql查詢方面的效能優化主要分為四個方向七個方面：
這7個方面最值得關注的在於動態優化方向的更新，下面來著重講一下。
自適應查詢執行通過使用執行時的統計資訊進行三個方面的優化:
spark2.4的版本中，reducer的個數是通過配置檔案中的shuffle.partition來設定的，如圖有五個分割槽就有五個reducer來進行處理，由上圖可以看到，reducer0的任務量較小，reducer3的任務量較大，這樣整個任務的效率瓶頸就在reducer3上，任務分配的不平衡浪費了資源，降低了處理效率。
spark3.0中，reducer的個數進行了優化，同樣的五個分割槽任務最後只用了三個reducer進行了處理，這樣就不會造成上述reducer0空轉的資源浪費情況。
在大資料中，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時間，因此如上圖所示，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
Spark3 0新特性 SQL相關
目錄 一 動態分割槽修剪 dynamic partition pruning 二 自適應查詢執行 adaptive query execution 三 對映下推 project pushdown 四 謂詞下推 predicate pushdown 靜態分割槽裁剪優化 過濾提前，減少無效資料讀寫，尤其...
大資料入門spark3 0入門到精通
第1節 00 了解 課程內容介紹 第2節 01 了解 spark發展歷史和特點介紹 第3節 02 掌握 spark環境搭建 local本地模式 第4節 03 掌握 spark環境搭建 standalone集群模式 第5節 04 掌握 spark環境搭建 standalone ha集群模式 第6節 0...
大資料查詢優化方案
1 儲存過程 2 建索引 3 分割槽 把資料分成幾個區存放，搜尋的結果合併。做表分割槽，縮小查詢範圍 按乙個有效字段分割槽，比如按月份 4 表空間 5 我們以前大資料量的解決方案是 把資料分批查出來，一次性查出來是沒有什麼好的解決辦法。6 like 必定掃全表 7 硬體 公升級伺服器，有這麼多資料的...