如何進(jìn)行EMR Spark-SQL性能極致優(yōu)化的分析

這篇文章將為大家詳細(xì)講解有關(guān)如何進(jìn)行EMR Spark-SQL性能極致優(yōu)化的分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

第三次刷榜的 Flag

從上述的 TPCDS Perf 鏈接中，我們可以看到，其實(shí) EMR 團(tuán)隊(duì)在 10TB 規(guī)?？偣蔡峤涣巳纬煽?jī)。第三次也就是這一次打榜，背后還有一個(gè)小故事。因?yàn)樵?Perf 頁面中，最終 TPCDS 關(guān)注的指標(biāo)有兩個(gè)，一個(gè)是性能指標(biāo)一個(gè)是性價(jià)比指標(biāo)。這次項(xiàng)目立項(xiàng)的時(shí)候，我們就給自己立下了一個(gè)艱難的 Flag ，我們要在物理硬件保持不變的條件下，純靠軟件優(yōu)化提升 2 倍+，這樣子性能指標(biāo)和性價(jià)比指標(biāo)就都能翻倍了。

與開源 Spark 版本的一些對(duì)比數(shù)據(jù)

在提交完成績(jī)后，我們用開源 Spark V2.4.3 版本進(jìn)行了 TPCDS 99 Query 測(cè)試，以下是性能數(shù)據(jù)對(duì)比

Load 階段性能提升約 3 X

PT 階段性能提升約 6 X

PS. 其中社區(qū) Spark V2.4.3 版本中 Query 14 以及 Query 95 因?yàn)?OOM 的原因沒法跑出來，不納入計(jì)算

社區(qū) Spark 版本運(yùn)行時(shí)間大于 200S 的 Query 單獨(dú)拿出來對(duì)比

PS. 這幾個(gè) Query 最低的 Query 78 有 3X 性能提升，Query 57有接近 100 倍的性能提升。

優(yōu)化點(diǎn)概述

優(yōu)化器

• 基于 InMemoryTable Cache 的 CTE 物化

簡(jiǎn)單來說，就是盡量更合理的利用 InMemoryTable Cache 去減少不必要的重復(fù)計(jì)算，比如說 Query 23A/B 中的標(biāo)量計(jì)算，本身是非常重的操作，并且又必須重復(fù)的計(jì)算，通過 CTE 優(yōu)化的模式匹配，識(shí)別出需要重復(fù)計(jì)算且比較耗時(shí)的操作，并利用 InMemoryTable 緩存，整體減少 E2E 時(shí)間

• 更加有效的 Filter 相關(guān)優(yōu)化

• Dynamic Partition Pruning 這個(gè)在社區(qū)最新的3.0版本才有這個(gè)功能

• 小表廣播復(fù)用 一個(gè)具有過濾性的小表，如果可以過濾 2 個(gè)或以上的打表數(shù)據(jù)時(shí)，可以復(fù)用該小表的過濾效果 Query 64 就是一個(gè)好例子

• BloomFilter before SMJ 在 SMJ 真正實(shí)施之前，通過前置 BloomFilter ，Join 過程的數(shù)據(jù)進(jìn)一步減少，最大限度的消除 SpillDisk 的問題

• PK/FK Constraint 優(yōu)化 通過主鍵外鍵信息，對(duì)優(yōu)化器提供更多的優(yōu)化建議

• RI-Join 去除 事實(shí)表與維表于主鍵外鍵上做 Join ，但是維表的列并沒有被 Project 的情況下，這次 Join 其實(shí)完全沒有必要執(zhí)行

• GroupBy Keys 去除非主鍵列 當(dāng)GroupBy Keys 中同時(shí)包括主鍵列以及非主鍵列，其實(shí)非主鍵列對(duì) GroupBy 結(jié)果已經(jīng)沒有影響了，因?yàn)橹麈I列已經(jīng)隱含了 Unique 的信息

• GroupBy Push Down before Join

• Fast Decimal

基于 Table Analyze 以及運(yùn)行時(shí)中的 Stat 信息，優(yōu)化器可以決定把某些 Decimal 優(yōu)化為 Long 或者 Int 的計(jì)算，這會(huì)有極大的提升，而 TPCDS 99 Query 里有大量的 Decimal 計(jì)算

運(yùn)行時(shí)

這次的優(yōu)化里面，還有一個(gè)很好玩的優(yōu)化，就是我們引入的 Native Runtime，如果說上述的優(yōu)化器優(yōu)化都是一些特殊 Case 的殺手锏，Native Runtime 就是一個(gè)廣譜大殺器，根據(jù)我們后期統(tǒng)計(jì)，引入 Native Runtime，可以普適性的提高 SQL Query 15～20%的 E2E 耗時(shí)，這個(gè)在TPCDS Perf 里面也是一個(gè)很大的性能提升點(diǎn)。

大致的介紹一下 Native Runtime
基于開源版本的 WholeStageCodeGeneration 的框架，在原有的生成的 Java 代碼，替換成 Weld IR 來真實(shí)運(yùn)行。在整個(gè)項(xiàng)目里，Weld IR 的替換其實(shí)是非常小的一部分工作，為了Weld IR 能夠運(yùn)行起來，我們還需要做以下的工作

• Expression Weld IR CodeGen ( TPCDS 范圍內(nèi)全支持)

• Operators Weld IR CodeGen (除了 SortMergeJoin 用 C++ 實(shí)現(xiàn)，其他均可以用 Weld IR 代替)

• 統(tǒng)一內(nèi)存布局 (OffHeap UnsafeRow => C++ & Weld Runtime)

• Batch 化執(zhí)行框架 (因?yàn)槿绻凑?Java 運(yùn)行時(shí)，每次都是一條記錄的在生成代碼里流轉(zhuǎn)，在 NativeRuntime 的時(shí)間里代價(jià)太高， JNI 以及WeldRuntime 明顯不能這么玩)

• 其他高性能Native算子 SortMergeJoin、PartitionBy、CSV Parsing，這幾個(gè)算子目前用 Weld IR 提供的接口無法直接實(shí)現(xiàn)，我們通過 C++來實(shí)現(xiàn)這些算子的 Native 執(zhí)行

關(guān)于如何進(jìn)行EMR Spark-SQL性能極致優(yōu)化的分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。