楊彥彬，干禎輝

（1.中通服軟件科技有限公司，上海 200000；2.杭州東方通信軟件技術(shù)有限公司，浙江 杭州 310013）

0 引言

隨著大數(shù)據(jù)時代到來，關(guān)系型數(shù)據(jù)結(jié)構(gòu)逐漸被NOSQL所替代。但是，由于傳統(tǒng)SQL語法方便易學(xué)且普及率高，因此直接廢棄難度很大，最終以Hive SQL及Spark SQL為代表的大數(shù)據(jù)組件也轉(zhuǎn)向支持傳統(tǒng)SQL。這些組件提供了SQL解析為分布式運算引擎的功能，但在如何提升執(zhí)行效率方面則沒有更多論述。本文以此為切入點，一方面討論了SQL遷移后出現(xiàn)的問題原因，另一方面給出了簡單實用的解決技巧，以利于在未來生產(chǎn)實踐中推廣。

1 大數(shù)據(jù)處理框架Spark概述

Spark是一個日常數(shù)據(jù)處理框架，它在接受job的時候，內(nèi)部會對其進行細致劃分，分為邏輯執(zhí)行計劃和物理執(zhí)行。邏輯執(zhí)行計劃是將一個RDD切分成不同的Stage，并產(chǎn)生一系列依賴關(guān)系，也就是Task之間窄依賴和寬依賴，其中寬依賴部分形成了Shuffle[1]。大部分Shuffle處后續(xù)會切分成多個Stage提交節(jié)點后執(zhí)行Action操作，稱之為物理執(zhí)行。

Spark的Task執(zhí)行可以分為兩種計算形式：流水線性計算和非流水線性計算，前者直接計算完成，有效減少內(nèi)存空間，典型的是filter（）或者map（）等操作。而后者則需要借助內(nèi)存空間完成，典型的是Groupbykey（）或者Reducebykey（）等操作。因此流水線性計算速度要快于非流水線性計算。圖1是Spark整體轉(zhuǎn)換流程[2]。

圖1 Spark整體轉(zhuǎn)換流程

2 業(yè)務(wù)數(shù)據(jù)遷移帶來的問題

Hive SQL及Spark SQL這些組件出現(xiàn)，實現(xiàn)了將收集后的海量數(shù)據(jù)按照原有業(yè)務(wù)模型進行計算的可能，但是這個過程中也帶來了很多問題，最典型的無疑是數(shù)據(jù)傾斜。所謂數(shù)據(jù)傾斜，即海量數(shù)據(jù)的主鍵執(zhí)行一對多關(guān)聯(lián)后由于分配節(jié)點計算量不均勻，導(dǎo)致一個節(jié)點還在執(zhí)行計算時候，其他節(jié)點已經(jīng)完成，都在等待該節(jié)點結(jié)束運行[3]。圖2左側(cè)就是數(shù)據(jù)傾斜的原因圖示，明顯節(jié)點1計算量遠大于節(jié)點2和3。數(shù)據(jù)傾斜在實際工作當(dāng)中的外在表現(xiàn)是某一個Task進度長時間徘徊在99%左右。而在最終結(jié)果集WEB UI中明顯看到某節(jié)點執(zhí)行時間與其他差異。圖2右側(cè)WEB UI中，紅框的節(jié)點計算時間遠大于其他節(jié)點。

圖2 數(shù)據(jù)傾斜產(chǎn)生原因和表現(xiàn)

3 Spark環(huán)境下SQL優(yōu)化方法

3.1 傳統(tǒng)Spark SQL優(yōu)化方法不足

常規(guī)優(yōu)化SQL手段就是簡化其復(fù)雜程度，將聚合、分組函數(shù)多次拆分，形成若干個簡單SQL，以此降低Task之間的join操作，同時單個SQL盡量利用流水線模式加快計算速度。但是該方法對數(shù)據(jù)傾斜幾乎產(chǎn)生不了實質(zhì)作用，因為簡化的SQL的無法解決數(shù)據(jù)分布不均的問題。

3.2 Spark SQL擴展主鍵優(yōu)化

數(shù)據(jù)傾斜產(chǎn)生的核心原因在于相同的業(yè)務(wù)主鍵聚集于一個計算節(jié)點，這是分布式計算模型特點所決定的。因此如果能將主鍵打散，并以打散的主鍵進行數(shù)據(jù)關(guān)聯(lián)，通常是首選解決方案。實踐當(dāng)中我們一般將主鍵按照一定規(guī)則編碼，形成新主鍵，并進行關(guān)聯(lián)。圖3描述了主鍵規(guī)則編碼前后的變化。左側(cè)以10000作為主鍵，各節(jié)點分布不均。右側(cè)則是通過主鍵編碼：分別形成10000-1、10000-2、10000-3，此時任務(wù)被均勻分布到各個節(jié)點。但是需要指出，該方法也會增加任務(wù)分區(qū)和Task數(shù)量，加大了資源調(diào)度難度。因此使用時要進行斟酌[4]。

圖3 按規(guī)則編碼主鍵前后的變化

另外，某些時候即使采用主鍵編碼也很難解決Spark在最后階段Reduce過程中的傾斜，因而在此基礎(chǔ)上需要配合廣播join持續(xù)優(yōu)化。

3.3 Spark SQL廣播join優(yōu)化

廣播join的實質(zhì)在于將較小的表通過Driver端分發(fā)到各計算節(jié)點，將原來計算方 式，即各個分區(qū)計算完成后再與小表進行join操作變化為小表直接在分區(qū)join，從而避 免了海量數(shù)據(jù)主鍵在最后階段Reduce過程時一對多出現(xiàn)場景[5]。圖4描述了廣播join的原理。

圖4 廣播join的實現(xiàn)原理

典型的廣播join用在Hive表，一般能夠提前確認表大小，避免廣播后出現(xiàn)錯誤。在非Hive表上則需要通過強制廣播join實現(xiàn)，Spark通過broadcast（）方法來完成。但是由于Spark無法提前確認分發(fā)表大小，在使用該方法的時候，當(dāng)Driver端內(nèi)存不足會出現(xiàn)OOM現(xiàn)象。同時過大的表亦不適合廣播join方法。因此使用前盡量確認分發(fā)表大小。

4 優(yōu)化前后性能比對

使用前述方法優(yōu)化之后性能一般有明顯提升。圖5是優(yōu)化前后比對圖。以1.8億數(shù)據(jù)量測試，50 G內(nèi)存提交。優(yōu)化前計算用時1 229 585 ms約等于20.5 min，優(yōu)化后用時877 460 ms約等于14.6 min，相比優(yōu)化前提速約30%。圖5紅圈是同一個計算節(jié)點，未優(yōu)化之前明顯的數(shù)據(jù)傾斜，優(yōu)化之后Task分布更為均勻，數(shù)據(jù)傾斜也相應(yīng)消失。

圖5 優(yōu)化前后的對比

5 結(jié)束語

隨著各類技術(shù)的不斷研究，相信在不久的將來會出現(xiàn)更多基于大數(shù)據(jù)的SQL優(yōu)化方法和手段，為進一步提升大數(shù)據(jù)計算應(yīng)用提供了堅實的保證。