![1.png](https://ucc.alicdn.com/pic/developer-ecology/21af584238254ff7a4b03250cd97cc8e.png)

# 前言

Apache Spark 自 2010 年面世，到現在已經發展為大資料批計算的首選引擎。而在 2020 年 6 月份釋出的Spark 3.0 版本也是 Spark 有史以來最大的 Release，其中將近一半的 issue 都屬於 SparkSQL。這也迎合我們現在的主要場景（90% 是 SQL），同時也是優化痛點和主要功能點。我們 Erda 的 FDP 平臺（Fast Data Platform）也從 Spark 2.4 升級到 Spark 3.0 並做了一系列的相關優化，本文將主要結合 Spark 3.0 版本進行探討研究。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/d1aeaf3f222143c78f26abd7dc38b219.png)

為什麼 Spark 3.0 能夠“神功大成”，在速度和效能方面有質的突破？本文就為大家介紹 Spark 3.0 中 SQL Engine 的“天榜第一”——**自適應查詢框架 AQE**（Adaptive Query Execution）。

# AQE，你是誰？

簡單來說，自適應查詢就是在執行時不斷優化執行邏輯。

Spark 3.0 版本之前，Spark 執行 SQL 是先確定 shuffle 分割槽數或者選擇 Join 策略後，再按規劃執行，過程中不夠靈活；現在，在執行完部分的查詢後，Spark 利用收集到結果的統計資訊再對查詢規劃重新進行優化。這個優化的過程不是一次性的，而是隨著查詢會不斷進行優化, 讓整個查詢優化變得更加靈活和自適應。這一改動讓我們告別之前無休止的被動優化。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/9777f9180e904c58b08aff543e88ef2e.png)

# AQE，你會啥？

瞭解了 AQE 是什麼之後，我們再看看自適應查詢 AQE 的“三板斧”：

- 動態合併 Shuffle 分割槽
- 動態調整 Join 策略
- 動態優化資料傾斜

## 動態合併 shuffle 分割槽

如果你之前使用過 Spark，也許某些“調優寶典”會告訴你調整 shuffle 的 partitions 數量，預設是 200。但是在不同 shuffle 中，資料的大小和分佈基本都是不同的，那麼簡單地用一個配置，讓所有的 shuffle 來遵循，顯然不是最優的。

分割槽過小會導致每個 partition 處理的資料較大，可能需要將資料溢寫到磁碟，從而減慢查詢速度；分割槽過大又會帶來 GC 壓力和低效  I/O 等問題。因此，動態合併 shuffle 分割槽是非常必要的。AQE 可以在執行期間動態調整分割槽數來達到效能最優。

如下圖所示，如果沒有 AQE，shuffle 分割槽數為 5，對應執行的 Task 數為 5，但是其中有三個的資料量很少，任務分配不平衡，浪費了資源，降低了處理效率。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/88779ee92c694cfeb9e49289fe514a41.png)

而 AQE 會合並三個小分割槽，最終只執行三個 Task，這樣就不會出現之前 Task 空轉的資源浪費情況。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/f1de1b182a90444fa232811c1e3aad5c.png)

## 動態調整 join 策略

SparkJoin 策略大致可以分三種，分別是 Broadcast Hash Join、Shuffle Hash Join 和 SortMerge Join。其中 Broadcast 通常是效能最好的，Spark 會在執行前選擇合適的 Join 策略。

例如下面兩個表的大小分別為 100 MB 和 30 MB，小表超過 10 MB (spark.sql.autoBroadcastJoinThreshold = 10 MB)，所以在 Spark 2.4 中，執行前就選擇了 SortMerge Join 的策略，但是這個方案並沒有考慮 Table2 經過條件過濾之後的大小實際只有 8 MB。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/41b07da4a3bd4e4394650fe4002f8c62.png)

AQE 可以基於執行期間的統計資訊，將 SortMerge Join 轉換為 Broadcast Hash Join。

在上圖中，Table2 經過條件過濾後真正參與 Join 的資料只有 8 MB，因此 Broadcast Hash Join 策略更優，Spark 3.0 會及時選擇適合的 Join 策略來提高查詢效能。

## 動態優化資料傾斜

資料傾斜一直是我們資料處理中的常見問題。當將相同 key 的資料拉取到一個 Task 中處理時，如果某個 key 對應的資料量特別大的話，就會發生資料傾斜，如下圖一樣產生長尾任務導致整個 Stage 耗時增加甚至 OOM。之前的解決方法比如重寫 query 或者增加 key 消除資料分佈不均，都非常浪費時間且後期難以維護。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d694449a54cb45e4906c3d684f6964af.png)

AQE 可以檢查分割槽資料是否傾斜，如果分割槽資料過大，就將其分隔成更小的分割槽，通過分而治之來提升總體效能。

沒有 AQE 傾斜優化時，當某個 shuffle 分割槽的資料量明顯高於其他分割槽，會產生長尾 Task，因為整個 Stage 的結束時間是按它的最後一個 Task 完成時間計算，下一個 Stage 只能等待，這會明顯降低查詢效能。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/9c4c0e5a7f44466b8358d2f87e8bfc90.png)

開啟 AQE 後，會將 A0 分成三個子分割槽，並將對應的 B0 複製三份，優化後將有 6 個 Task 執行 Join，且每個 Task 耗時差不多，從而獲得總體更好的效能。通過對傾斜資料的自適應重分割槽，解決了傾斜分割槽導致的整個任務的效能瓶頸，提高了查詢處理效率。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/8928d2f7075b4c93a526966e8b93443c.png)

自適應查詢 AQE 憑藉著自己的“三板斧”，在 1TB TPC-DS 基準中，可以將 q77 的查詢速度提高 8 倍，q5 的查詢速度提高 2 倍，且對另外 26 個查詢的速度提高 1.1 倍以上，這是普通優化無法想象的傲人戰績！

![10.png](https://ucc.alicdn.com/pic/developer-ecology/19e86669c6104c59be00d712f400b394.png)

# 真的嗎？我不信

![11.png](https://ucc.alicdn.com/pic/developer-ecology/f485509d33f3454faba773dd5f6699af.png)

口說無憑，自適應查詢 AQE 的優越性到底是如何實現，我們“碼”上看看。

## AQE 引數說明

```shell
#AQE開關
spark.sql.adaptive.enabled=true #預設false，為true時開啟自適應查詢，在執行過程中基於統計資訊重新優化查詢計劃
spark.sql.adaptive.forceApply=true #預設false，自適應查詢在沒有shuffle或子查詢時將不適用，設定為true將始終使用
spark.sql.adaptive.advisoryPartitionSizeInBytes=64M #預設64MB,開啟自適應執行後每個分割槽的大小。合併小分割槽和分割傾斜分割槽都會用到這個引數

#開啟合併shuffle分割槽
spark.sql.adaptive.coalescePartitions.enabled=true #當spark.sql.adaptive.enabled也開啟時，合併相鄰的shuffle分割槽，避免產生過多小task
spark.sql.adaptive.coalescePartitions.initialPartitionNum=200 #合併之前shuffle分割槽數的初始值，預設值是spark.sql.shuffle.partitions，可設定高一些
spark.sql.adaptive.coalescePartitions.minPartitionNum=20 #合併後的最小shuffle分割槽數。預設值是Spark叢集的預設並行性
spark.sql.adaptive.maxNumPostShufflePartitions=500 #reduce分割槽最大值，預設500，可根據資源調整

#開啟動態調整Join策略
spark.sql.adaptive.join.enabled=true #與spark.sql.adaptive.enabled都開啟的話，開啟AQE動態調整Join策略

#開啟優化資料傾斜
spark.sql.adaptive.skewJoin.enabled=true #與spark.sql.adaptive.enabled都開啟的話，開啟AQE動態處理Join時資料傾斜
spark.sql.adaptive.skewedPartitionMaxSplits=5 #處理一個傾斜Partition的task個數上限，預設值為5；
spark.sql.adaptive.skewedPartitionRowCountThreshold=1000000 #傾斜Partition的行數下限，即行數低於該值的Partition不會被當作傾斜，預設值一千萬
spark.sql.adaptive.skewedPartitionSizeThreshold=64M #傾斜Partition的大小下限，即大小小於該值的Partition不會被當做傾斜，預設值64M
spark.sql.adaptive.skewedPartitionFactor=5 #傾斜因子，預設為5。判斷是否為傾斜的 Partition。如果一個分割槽(DataSize>64M*5) || (DataNum>(1000w*5)),則視為傾斜分割槽。
spark.shuffle.statistics.verbose=true #預設false，開啟後MapStatus會採集每個partition條數資訊，用於傾斜處理

```

## AQE 功能演示

Spark 3.0 預設未開啟 AQE 特性，樣例 sql 執行耗時 41 s。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/b3310e8b77de4b6990d40e7c002e216d.png)

存在 Task 空轉情況，shuffle 分割槽數始終為預設的 200。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/1fc21befef1542d0b0b4ba004b4409f2.png)

開啟 AQE 相關配置項，再次執行樣例 sql。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/142fae3c882e447c9309abb0f421ea1e.png)

樣例 sql 執行耗時 18 s，快了一倍以上。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/8fea6b5fbf99455498001186835b1872.png)

並且每個 Stage 的分割槽數動態調整，而不是固定的 200。無 task 空轉情況，在 DAG 圖中也能觀察到特性開啟。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/8d7f7f92e25f4c2e82a6a37a2d5839a7.png)

![17.png](https://ucc.alicdn.com/pic/developer-ecology/627bfa71ea0c42edb017770c74b25822.png)

# 總結

Spark 3.0 在速度和效能方面得提升有目共睹，它的新特性遠不止自適應查詢一個，當然也不意味著所有的場景都能有明顯的效能提升，還需要我們結合業務和資料進行探索和使用。

_注：文中部分圖片源自於網路，侵刪。_

「Spark從精通到重新入門(一)」Spark 中不可不知的動態優化

相關文章