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

成都創(chuàng)新互聯(lián)公司專注于網(wǎng)站建設(shè)|成都網(wǎng)站維護|優(yōu)化|托管以及網(wǎng)絡(luò)推廣，積累了大量的網(wǎng)站設(shè)計與制作經(jīng)驗，為許多企業(yè)提供了網(wǎng)站定制設(shè)計服務(wù)，案例作品覆蓋邊坡防護網(wǎng)等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結(jié)合品牌形象的塑造，量身制作品質(zhì)網(wǎng)站。

第三次刷榜的 Flag

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

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

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

Load 階段性能提升約 3 X

PT 階段性能提升約 6 X

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

社區(qū) Spark 版本運行時間大于 200S 的 Query 單獨拿出來對比

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

優(yōu)化點概述

優(yōu)化器

• 基于 InMemoryTable Cache 的 CTE 物化

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

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

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

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

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

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

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

• GroupBy Keys 去除非主鍵列 當GroupBy Keys 中同時包括主鍵列以及非主鍵列，其實非主鍵列對 GroupBy 結(jié)果已經(jīng)沒有影響了，因為主鍵列已經(jīng)隱含了 Unique 的信息

• GroupBy Push Down before Join

• Fast Decimal

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

運行時

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

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

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

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

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

• Batch 化執(zhí)行框架 (因為如果按照 Java 運行時，每次都是一條記錄的在生成代碼里流轉(zhuǎn)，在 NativeRuntime 的時間里代價太高， JNI 以及WeldRuntime 明顯不能這么玩)

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

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

分享文章：如何進行EMRSpark-SQL性能極致優(yōu)化的分析
鏈接地址：http://aaarwkj.com/article8/ijpoop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、手機網(wǎng)站建設(shè)、建站公司、品牌網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)