楊彥彬，干禎輝

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

0 引言

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

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

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

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

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

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

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

圖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手段就是簡(jiǎn)化其復(fù)雜程度，將聚合、分組函數(shù)多次拆分，形成若干個(gè)簡(jiǎn)單SQL，以此降低Task之間的join操作，同時(shí)單個(gè)SQL盡量利用流水線(xiàn)模式加快計(jì)算速度。但是該方法對(duì)數(shù)據(jù)傾斜幾乎產(chǎn)生不了實(shí)質(zhì)作用，因?yàn)楹?jiǎn)化的SQL的無(wú)法解決數(shù)據(jù)分布不均的問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語(yǔ)

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