作者：林學維，阿裡雲智能EMR團隊技術專家，目前主要專注于EMR産品中開源計算引擎的優化工作
引子
最近阿裡雲 E-MapReduce 團隊在 TPCDS-Perf 榜單中送出了最新成績，相比第二名(其實也是 EMR 團隊于 2019 年送出的記錄)，無論從性能還有成本效益都取得了 2 倍+的優秀成績！詳細看
TPCDS Perf
阿裡雲 E-MapReduce 團隊，除了在産品、易用性、安全性等次元上投入了大量的研發資源和精力，打造了 EMR 這樣一個廣受好評的大資料産品；在引擎層面上也長期投入，持續深耕，目的就是要在保持開源軟體的 100% 相容性的同時，要利用團隊的技術深度去打造産品的技術壁壘，讓客戶在使用開源軟體棧的時候，能夠獲得更多的成本效益，真真切切的把雲上成本降低到極緻，讓客戶能夠在上雲的過程中沒有疑慮和後顧之憂。
阿裡雲 E-MapReduce 團隊在 TPCDS Perf 中取得的成績也足以驗證，團隊在 SPARK 引擎的技術深度以及技術實力，接下來會有一個系列的文章，去介紹我們 2020 年度打榜過程的一些優化點還有思考，歡迎社群裡的 spark 引擎開發者或者 spark 應用開發者可以關注我們的系列文章，也歡迎來和我們交流，最關鍵的是，歡迎多投履歷，加入阿裡雲 E-MapReduce 團隊，我們求賢若渴！！！
第三次刷榜的 Flag
從上述的 TPCDS Perf 連結中，我們可以看到，其實 EMR 團隊在 10TB 規模總共送出了三次成績。第三次也就是這一次打榜，背後還有一個小故事。因為在 Perf 頁面中，最終 TPCDS 關注的名額有兩個，一個是性能名額一個是成本效益名額。這次項目立項的時候，我們就給自己立下了一個艱難的 Flag ，我們要在實體硬體保持不變的條件下，純靠軟體優化提升 2 倍+，這樣子性能名額和成本效益名額就都能翻倍了。
與開源 Spark 版本的一些對比資料
在送出完成績後，我們用開源 Spark V2.4.3 版本進行了 TPCDS 99 Query 測試，以下是性能資料對比
Load 階段性能提升約 3 X
PT 階段性能提升約 6 X
PS. 其中社群 Spark V2.4.3 版本中 Query 14 以及 Query 95 因為 OOM 的原因沒法跑出來，不納入計算
社群 Spark 版本運作時間大于 200S 的 Query 單獨拿出來對比
PS. 這幾個 Query 最低的 Query 78 有 3X 性能提升，Query 57有接近 100 倍的性能提升。
優化點概述
優化器
-
基于 InMemoryTable Cache 的 CTE 物化
簡單來說，就是盡量更合理的利用 InMemoryTable Cache 去減少不必要的重複計算，比如說 Query 23A/B 中的标量計算，本身是非常重的操作，并且又必須重複的計算，通過 CTE 優化的模式比對，識别出需要重複計算且比較耗時的操作，并利用 InMemoryTable 緩存，整體減少 E2E 時間
-
更加有效的 Filter 相關優化
-
Dynamic Partition Pruning
-
小表廣播複用
-
BloomFilter before SMJ
-
-
PK/FK Constraint 優化
-
RI-Join
-
GroupBy Keys 去除非主鍵列
-
GroupBy Push Down before Join
-
-
Fast Decimal
基于 Table Analyze 以及運作時中的 Stat 資訊，優化器可以決定把某些 Decimal 優化為 Long 或者 Int 的計算，這會有極大的提升，而 TPCDS 99 Query 裡有大量的 Decimal 計算
運作時
這次的優化裡面，還有一個很好玩的優化，就是我們引入的 Native Runtime，如果說上述的優化器優化都是一些特殊 Case 的殺手锏，Native Runtime 就是一個廣譜大殺器，根據我們後期統計，引入 Native Runtime，可以普适性的提高 SQL Query 15～20%的 E2E 耗時，這個在TPCDS Perf 裡面也是一個很大的性能提升點。
大緻的介紹一下 Native Runtime
基于開源版本的 WholeStageCodeGeneration 的架構，在原有的生成的 Java 代碼，替換成 Weld IR 來真實運作。Weld詳細參考
http://weld.stanford.edu/。在整個項目裡，Weld IR 的替換其實是非常小的一部分工作，為了Weld IR 能夠運作起來，我們還需要做以下的工作
- Expression Weld IR CodeGen ( TPCDS 範圍内全支援)
- Operators Weld IR CodeGen (除了 SortMergeJoin 用 C++ 實作，其他均可以用 Weld IR 代替)
- 統一記憶體布局 (OffHeap UnsafeRow => C++ & Weld Runtime)
- Batch 化執行架構 (因為如果按照 Java 運作時，每次都是一條記錄的在生成代碼裡流轉，在 NativeRuntime 的時間裡代價太高， JNI 以及WeldRuntime 明顯不能這麼玩)
- 其他高性能Native算子 SortMergeJoin、PartitionBy、CSV Parsing，這幾個算子目前用 Weld IR 提供的接口無法直接實作，我們通過 C++來實作這些算子的 Native 執行
結語
這個文章隻是大概的介紹了這次性能優化的一些優化點，在接下來的系列文章裡，我們會針對每一個優化點細緻的展開、分析，希望對 Spark-SQL 有興趣的同學們可以多多關注，多多捧場。同時，我們也希望對 EMR 團隊有興趣的同學，積極聯系我們，我們真的求賢若渴，海量 HC ，請有興趣者聯系 林學維(峰七) 18518298234，也可郵箱 [email protected] !!!
推薦閱讀
EMR Spark-SQL性能極緻優化揭秘 RuntimeFilter Plus阿裡巴巴開源大資料技術團隊成立Apache Spark中國技術社群，定期推送精彩案例，技術專家直播，問答區近萬人Spark技術同學線上提問答疑，隻為營造純粹的Spark氛圍，歡迎釘釘掃碼加入！
對開源大資料和感興趣的同學可以加小編微信（下圖二維碼，備注“進群”）進入技術交流微信群。
Apache Spark技術交流社群公衆号，微信掃一掃關注