1006大設(shè)計翻譯版

本我，本及其研究工作是由在導師指導下獨立完成的，在完成時所利用的一切資料均已考文獻中列出。：SCOPE，性能分析，大數(shù)據(jù)任JobPerformanceStudyonBigData WeiLiWithwide-adoptionofbig-dataplatform,moreandmorepeoplearecapableofrunningtheirdata-parallelcomputingjobstoyzethemassivedata.Suchjobsaredividedintomul-tiplelogicalstages,andeachstagewillspawnhundredsoreventhousandsofparalleltaskswithsignificantdatathroughput.Thereforejobperformanceiscriticalinsavingbothtimeandresources.Theperformanceresearchonbig-domputingjobshelpsustolocatepoorper-formedjobs,findoutthedeficienciesofexistingbig-dataplatform,andfurtherguidethefuturedata-parallelprogramming.Asthefirststepinthewholeresearchwork,weconductedanempiricaljobperformancestudyinSCOPE,aproductionbig-dataplatformin.Thisstudystartswithtwokeyfactors:degreeofparallelismanddatathroughputtodiscovertherootcauseofthecommonperformanceissues.Afterhavinginvestigated124realSCOPEjobsthoroughly,wefindthattherootcausesforpoorperformancecomefromthreeaspects:programminglanguage,dataandsystem.Wererunsomepoorperformancecaseswithoursolutions,savingupto64%Thebig-dataprogramminglanguagemakesusersfocusontheirbusinesslogic,insteadofthedetailsofparallelism.Howeversuchconveniencesometimeshindersthejoboptimizertoproducebettercode;Thedataimbalancemayleadtosignificantfluctuationsonexecutiontimeoftheparalleltaskswithinastage;Thestaticjobexecutionplanmaydecidetoolowortoohighdegreeofparallelism,whicharealsothereasonsofpoorperformance.AlthoughourstudyisbasedonSCOPE,themethodologyandfindingareprac-ticabletoothersimilarplatforms,includingthreepoorperformanceissues.Andtheresearchre-sultswillbeguidancetothedesignandoptimizationofbothbig-dataplatformanddata-parallel:SCOPE, ysis,BigData1簡介11.1課題來源11.2課題背景11.3課題意義21.4國內(nèi)外研究現(xiàn)狀21.5研究內(nèi)容和目標31.6研究難點與結(jié)果41.7組織結(jié)構(gòu)6272.1MapReduce編模型72.2SCOPE系統(tǒng)72.3SCOPE概念與實例82.4數(shù)據(jù)傾斜（DataSkew）現(xiàn)象 3方法論 3.1任務(wù)的代表性 3.2研究的適用性 3.3人工判斷原因的性 4SCOPE任務(wù)性能表現(xiàn)具體實例分析 4.1語言層面 4.1.1現(xiàn)象與危害 4.1.2實例分析 4.1.3解決方法 4.1.4總結(jié)分析 4.2數(shù)據(jù)層面 4.2.1現(xiàn)象和危害 4.2.2實例分析 4.2.3解決方法 4.2.4總結(jié)與分析 4.3系統(tǒng)層面 4.3.1現(xiàn)象與危害 4.3.2實例一分析 4.3.3實例一解決方法 4.3.4實例二分析 4.3.5實例二解決方法 4.3.6總結(jié)與分析 5相關(guān)工作 6結(jié)論 致謝 參考文獻 本課題來源于航空航天大學軟件開發(fā)環(huán)境國家和微軟亞洲系統(tǒng)組的合作項目，關(guān)于微軟SCOPE大數(shù)據(jù)平臺性能研究和優(yōu)化。課題的整體方向是在了解SCOPE系統(tǒng)，了解SCOPE任務(wù)的整個調(diào)度過執(zhí)行過和優(yōu)化技術(shù)的前提下，從當前的SCOPE大數(shù)據(jù)任務(wù)的執(zhí)行情況和系統(tǒng)日志出發(fā)，SCOPE和其他大課題研究中涉及到的所有數(shù)據(jù)均來自微軟SCOPE產(chǎn)品組集群，覆蓋搜索、、數(shù)據(jù)環(huán)境下失效，和計算重大的。海量數(shù)據(jù)的現(xiàn)實對于分布式計算的編MapReduce類型的數(shù)據(jù)并行（data-parallel）計算模型是將一個計算任務(wù)分成多個不同的計算階段，而每個階段包含多個可以高度并行的子計算任務(wù)，這些計算任務(wù)針對不同的數(shù)據(jù)進行相同的計算，而不同的階段之間有的需要一個稱之為shuffle的階段進行數(shù)據(jù)的清理與重新組織。在整個過中，不同的階段都可以讓用戶定義數(shù)據(jù)進一步的，類似SQL的次的型語言和過型語言（e.g.C#,Java）編寫的用戶定義函數(shù)（UserDefineFunction,UDF）結(jié)合的編模型已經(jīng)在當前的大數(shù)據(jù)平臺上成為主流。這些平臺包括雅虎的PigLatin[2,3]，的Hive[4,5]，的FlumeJava[6]MapReduce過在底層的集SCOPE（StructuredComputationsOptimizedforParallelExecution）[7據(jù)平臺，它擁有類似SQL形式的查詢語法并且支持用C#編寫的豐富的用戶定義函數(shù)，MapReduceDryad[8]，能夠很好的擴展和容錯。SCOPE目前運行在成千上萬臺機器上，服務(wù)于必應搜索、數(shù)據(jù)挖掘、等眾多產(chǎn)品部門，每天運行著數(shù)以十萬計的大數(shù)據(jù)任務(wù)，處理PB級別的數(shù)據(jù)。數(shù)據(jù)平臺任務(wù)的一次運行通常會涉及多臺，有的時候多達數(shù)百臺甚至的機器，而任務(wù)性能的提升可以幫助系統(tǒng)節(jié)省計算資源和能源，進而提升系統(tǒng)的計算能力，從而可以讓集群支持的計算任務(wù)。而從方法上看，大數(shù)據(jù)平臺上的任務(wù)性能分析，與傳統(tǒng)單機序和多線并行序的性能分析有很大不同。大數(shù)據(jù)系統(tǒng)相比于其他系統(tǒng)更加的復雜，因為容錯和綜合調(diào)度等復雜機制的存在，其執(zhí)行過更加的多變，而造能不佳的原因也與傳統(tǒng)任來指導這樣的新環(huán)境下的性能分析工作，而這方面的相關(guān)研究目前非常的少。對于大數(shù)據(jù)平臺的用戶來說，性能研究也是有很大意義的。大數(shù)據(jù)平臺將用戶表達的次的數(shù)據(jù)處理邏輯轉(zhuǎn)化成分布式并行計算的任務(wù)，調(diào)度安排到成千上萬的機也因為這樣，用戶序和最后的執(zhí)行代碼存在較大的差異，從而導致用戶對自身序解任務(wù)低性的根本因，從指導用在數(shù)據(jù)平臺上編實，優(yōu)化統(tǒng)，節(jié)省資源。大數(shù)據(jù)平臺上，對于產(chǎn)品部門的大數(shù)據(jù)任務(wù)的性能研究，能幫助了解真實生產(chǎn)環(huán)境中對于大數(shù)據(jù)平臺的應用情況和實際的需求，從而發(fā)現(xiàn)當前大數(shù)據(jù)平臺存在的根本問題，并未來的系統(tǒng)研究和優(yōu)化方向。MapReduce提出后，在工業(yè)界得到了廣泛的追捧和應用。Hadoop是最流行的MapReduce實現(xiàn)，它已經(jīng)逐漸發(fā)育成為一個成開源生態(tài)系統(tǒng)。目前，基于MapReduce計算模型，針對不同的應用類型，越來越多的應用框架都可以在Hadoop體系中部署，包括實時計算的Storm、Impala，內(nèi)存計算的Spark，數(shù)據(jù)平臺Hive、PigLatin、HBase，DAG圖計算引擎Tez等。越來越多的公司在他們的實際生產(chǎn)應用中部署平集數(shù)和分一今似SL的次型語言和過型語言相結(jié)合的編的方法已經(jīng)成為上層大數(shù)據(jù)任務(wù)編的流行趨勢和發(fā)展pdueSOPE平臺也是這樣的于Hive和Pigatin，它提供海量的數(shù)據(jù)和計算服PB級別的數(shù)據(jù)。性能分析的研究方面，之前關(guān)于大數(shù)據(jù)平臺的性能研究工作多針對研究型集群[9]，本課題的研究目標是：了解當前大數(shù)據(jù)平臺上任務(wù)的運行情況，分類找出不正常任務(wù)的效率。我們的研究將對于真實應用場景下的任務(wù)的運行表現(xiàn)出發(fā)，分析具體影而總結(jié)現(xiàn)今的大數(shù)據(jù)平臺下編實踐，更好的指導今后的分布式系統(tǒng)設(shè)計。熟悉和了解微軟的SCOPE大數(shù)據(jù)平臺，包括平臺架構(gòu)、編語言、調(diào)度機制、原始數(shù)據(jù)，從SCOPE大數(shù)據(jù)平臺上真實的大數(shù)據(jù)任務(wù)的原始數(shù)據(jù)及相 大數(shù)據(jù)平臺上的任務(wù)性能研究有其復雜性?，F(xiàn)在大數(shù)據(jù)平臺上運行的任務(wù)有著復雜的計算邏輯，再加上系統(tǒng)將用戶代碼并行化的過中應用了眾多的優(yōu)化和調(diào)整，最終導致了任務(wù)的低性能瓶頸很難定位。而造成任務(wù)性能不佳的原因也有很多，包括用能，甚至連同一臺機器上運行的不同任務(wù)的tak之間也可能會有相互的影響。這些都使得任務(wù)性能分析和研究充滿了與。與傳統(tǒng)的序不同，大數(shù)據(jù)平臺上的任務(wù)旨在通過并行計算的方式快速的進行海量數(shù)據(jù)的處理，其任務(wù)性能取決于并行的任務(wù)數(shù)和并行執(zhí)行的效率，而不是傳統(tǒng)的復雜度最大的模塊。用戶提交任務(wù)到大數(shù)據(jù)平臺上，均希望能利用其分布式并行計算的優(yōu)勢，能夠方便的和處理海量規(guī)模數(shù)據(jù)，更快更好的完成相應的計算任務(wù)。在大數(shù)據(jù)平臺中，任務(wù)運行的時候不可能的使用資源，所以系統(tǒng)通常會用某行的任務(wù)數(shù)來保證該任務(wù)的計算資源，在SCOPE里稱之為額定并行度（TokenAllocation同導致其需要的并行任務(wù)數(shù)量一般是不一樣的，而現(xiàn)在的大數(shù)據(jù)任務(wù)往往都比較復雜，不只是簡單的一個MapReduce過而不同的階段中又有一些是可以并行執(zhí)行的，從而執(zhí)行的任務(wù)數(shù)是由用戶序邏輯、數(shù)據(jù)和系統(tǒng)等多個因素共同決定的，有可能存在某段時間遠遠達不到系統(tǒng)給定的額定并行任務(wù)數(shù)，也有可能某段時間遠大于這個數(shù)值。本文認為一個好的大數(shù)據(jù)并行任務(wù)應該充分利用系統(tǒng)給予的并行計算資源，保持整個過較以并行執(zhí)行的子任務(wù)數(shù)稱為運行時并行度（RuntimeDegreeofParallelism,RDoP，作為吐量（Throughput）作為重要的參考指標。RDoP可以在宏觀層面上反映一個任務(wù)對于額ThroughputRDoP的不足，幫助研究每一個并MapReduce這樣的為海量數(shù)據(jù)處理設(shè)計的系統(tǒng)的假定，從而可能給系統(tǒng)帶來額外的開SOE（DoP和子任務(wù)吞吐量（Throughput）這兩個指標，展開了第一個針對產(chǎn)品組大數(shù)據(jù)平臺的經(jīng)驗性的性能分析研究工作。我們分類得到了一個潛在的低性能任務(wù)集合，并對其中的124個不同的產(chǎn)品任，進行了工的深入究。本文的研究現(xiàn)，這些務(wù)低性能本原因主要可以歸結(jié)為語言、數(shù)據(jù)和系統(tǒng)三個層面。本文對于這三個方面的原因進行了深入的分析，并總結(jié)了當前大數(shù)據(jù)平臺研究和性能優(yōu)化所的和。在大數(shù)據(jù)平臺的語言層面，因為大數(shù)據(jù)平臺普遍采用比較容易編并符合數(shù)據(jù)處的SQlike語言，同時還支持過型言來靈活實現(xiàn)用戶定義函數(shù)（DF）,這戶編充靈性低寫算序檻用不理繁雜的并行細節(jié)。但是這樣的代碼對于系統(tǒng)底層的優(yōu)化器來說卻并不是那么的友好，特別是在海量機器參與的復雜集群中，上層序的過于靈活導致了有些重要的優(yōu)化難以Prtialggrgte這樣一個顯著減小hufle的，個有行Prtialggrgte優(yōu)化，包括那該更慎重的考慮編語言的設(shè)計，編語言不僅要能夠讓用戶更好表達自己的處理邏輯，而且對于系統(tǒng)優(yōu)化器也應該是友好的，這樣才能做到編靈活性和效率上的兼顧。在數(shù)據(jù)層面，大數(shù)據(jù)平臺上采用數(shù)據(jù)分塊的方式來方便同一個階段內(nèi)任務(wù)的并行執(zhí)行，這潛在的對于數(shù)據(jù)分布的均勻性帶來了要求，數(shù)據(jù)分布的不均勻會直接導致同一階段內(nèi)不同并行任務(wù)間的運行時長不同，這將延長整個階段的完成時間，從而帶來低性能的問題。而且目前大數(shù)據(jù)任務(wù)應用的廣泛性和任務(wù)的復雜性又導致了任務(wù)執(zhí)行的中存多個階段不僅僅原始數(shù)據(jù)，中數(shù)據(jù)也要是均勻，這無是一巨大的。大數(shù)據(jù)平臺上的系統(tǒng)實現(xiàn)也存在很多的。用戶任務(wù)在大數(shù)據(jù)平臺上運行不只是追求任務(wù)運行的正確性，更加看重任務(wù)的效率與性能，這使得任務(wù)的并行度變得尤為的重要。而前系統(tǒng)中靈活的編語言復雜的用戶邏，均導致靜態(tài)的并務(wù)數(shù)決策在現(xiàn)在的應用環(huán)境下不足以滿足任務(wù)的需求。一個計算階段中，如果并行度如果一個階段中，并行度過高，會直接導致計算任務(wù)中每個子計算任務(wù)都只是處理極小的數(shù)據(jù)，這使得整個算過系都有貴的間接開銷性能不好于是，在統(tǒng)實現(xiàn)的角度上，對于不同階段的并行任務(wù)數(shù)進行動態(tài)決策是必要的，但也是有難度和的。產(chǎn)品組集群的任務(wù)特性使得可以結(jié)合產(chǎn)品任務(wù)中任務(wù)反復運行的特點，根據(jù)歷史任務(wù)的信息，結(jié)合運行時動態(tài)的數(shù)據(jù)大小監(jiān)測，采取更好的決策策略。本文在進行任務(wù)運行緩慢性能不佳的根本原因分析的同時，提出了一些解決當前任務(wù)性能緩慢的方法。我們對于部分仍保留原始數(shù)據(jù)的任務(wù)進行了重新運行，我們提64%的任務(wù)運行時間，并且減少了任務(wù)因為運行緩慢而最終失敗的概率，有效提升了性能。隨著大數(shù)據(jù)平臺的應用變得更加的廣泛，在這個新興的領(lǐng)域上的存在很多的問題等待我們?nèi)ニ伎?，任?wù)性能的分析是我們研究的第一步，幫助了解系統(tǒng)中存在的一些現(xiàn)象，?兩個衡量并行任務(wù)性能的重要指標，并利用該指標制定了3個有效的方法組織結(jié)構(gòu)如下第二章介紹相關(guān)的技術(shù)，SCOPE的相關(guān)知識，方便后面具體描述并行計算任務(wù)的MapReduce是公司，在廉價機器集群上做海量數(shù)據(jù)計算的分布式系統(tǒng)。MapReduce包括Map和Reduce兩個過Map過進行過濾和的分組操作，Reduce的過進行一個聚合的操作。Map和Reduce這兩個過都采用過型的語shuffle的階段，進行數(shù)據(jù)的清理和重新組織，系統(tǒng)將按照用戶指定的Reduce階段的關(guān)鍵字，將pdue點上的子任務(wù)出錯失敗時，會通過系統(tǒng)自動的按照出錯的類型進行重新運行，而不需要重新運行整個任務(wù)，也不需要人工介入，這有效的提升了任務(wù)的執(zhí)行效率了在超大規(guī)模并行計算任務(wù)得以順利的完成。MapReduce編模型具有非常容易擴展的特點，結(jié)合系統(tǒng)中擁有復雜的機制來保證整系的負載均衡、異常檢測、失敗恢復等等，很好的滿足了海量數(shù)據(jù)處理的需MapReduce模型才能在這SCOPESCOPE是微軟開發(fā)的應用在微軟的海量數(shù)據(jù)處理系統(tǒng)，其底層是類似于MapReduce的Dryad分布式計算框架，而上層支持用戶采用類似于SQL的型語言或者采用CHivePig。SQL天然適合進行數(shù)據(jù)處理的操作，已經(jīng)獲得了廣泛的應用，具有簡潔的編方式和豐富的語義表達這樣優(yōu)秀的特性，可以提高用戶編的效率；系統(tǒng)還支持過型語言編寫用戶定義函數(shù)（UDF，使得SCOPE語言不失靈活性，能夠應用在的大數(shù)據(jù)處理場景。SOPE序執(zhí)行的各個階段中，一般把數(shù)據(jù)作為結(jié)構(gòu)化數(shù)據(jù)集合來處理，每個數(shù)據(jù)行包括多個列，數(shù)據(jù)集就像數(shù)據(jù)庫的一張表格一樣。數(shù)據(jù)集是實際代碼中每個語句操作的數(shù)據(jù)的基本單位。在實際系統(tǒng)實現(xiàn)上，SCOPEMap-Reduce-Merge的模型，Merge是指將兩個數(shù)據(jù)集合并為一個數(shù)據(jù)集的過在SCOPE中，一般把MapReduce中的Map階段稱為PROCESS階段，Reduce階段仍然稱為REDUCEMerge階段稱為COMBINE階段，為了方便，本文后面都采用SCOPE的說法。SCOPE系統(tǒng)因為其上層提供簡潔高效的表達方式，下層有著強大的海量數(shù)據(jù)處理能力，在微軟的很多產(chǎn)品組中得到廣泛使用，用來編寫處理海量數(shù)據(jù)的分布式并行計算任務(wù)。SCOPE很容易編譯成類似多個MapReduce序互相連接的數(shù)據(jù)并行（Jobt0=SELECTt0=SELECTaasbasBFROMt1=SELECTaasSUM(b)asB,SUM(c)asFROMrawtable1;t2=SELECTt0.*,FROMt0,t1WHEREt0.A==123456789這段類SQL的代碼中，t0rawtable0這個數(shù)據(jù)表中ab兩列，分別稱為AB，t1rawtable1這個數(shù)據(jù)表中選a,bc三列，并且分別bc兩列進行一個求和操作，把生成的數(shù)據(jù)集合三列分別稱為A，B和C，接下來，t0和t1這兩個新的數(shù)據(jù)集合按照A這一列進行接操作，這里把A稱為joinkey，得到一個新的數(shù)據(jù)集合t2。如代碼中所示，SCOPE支持類似SQL的語法持常見的多種聚說COUNT,COUNTIFMINMAXSUMAVGSTDEVVARFIRSTLAST等，它們的圖 運行情況COUNTDISTINCT就是一個常用的計算某一個數(shù)據(jù)列中不同元素數(shù)量方面的語法。SCOPE還支持相等連接操作，也就是SQLJOIN操作。這段代碼被編譯成類似圖2.1所示的樣式，包括PROCESS，REDUCECOMBINE三個階段，每個階段中都包段將不同的Vertexprocessor、reducercombiner。它們最終都將通過調(diào)度器調(diào)度，從而并行的執(zhí)行。processor一般是將數(shù)據(jù)進行格式轉(zhuǎn)換和過濾，其輸出的某些行按照用戶指定將被當做reducekey，在經(jīng)過一個數(shù)據(jù)處理的重新分堆處理的過后，reducerreducerSQL語句表達，reducer計算內(nèi)容由用戶自己定義。processreducedatashuffling的階段processor中的reducerkeyreducer的機器上，而reducer機器上將對于這些數(shù)據(jù)進行一個多路歸并的操作，而后再執(zhí)行reduce過Datashuffling過會給網(wǎng)絡(luò)和系統(tǒng)帶來很大的負擔，因為所有的數(shù)據(jù)都將通過網(wǎng)絡(luò)進行傳輸。在實際實現(xiàn)中，為了減少datashuffling的過的數(shù)據(jù)量，對于那些reducer的計算操作是一個聚合操作，而且是滿換律和結(jié)合律的聚合操作的datashuffling開始前先在本地進行相同的聚合操作，這個優(yōu)化稱為PartialAggregate。在實踐中，很多的任務(wù)都包含聚合操作，所以這個優(yōu)化能有效提升datashuffling的效率。對于復雜的SCOPE任務(wù)，一個MapReduce或者Map-Reduce-Merge過可能沒有辦法完成。最后，SCOPE代碼會被編譯成為一個DAG圖進行執(zhí)行，DAG圖上的每一個節(jié)點稱為一個Stage，一個Stage可能對應為一個PROCESS、REDUCE或者COMBINE義、用戶定義函數(shù)和系統(tǒng)的一些優(yōu)化技術(shù)，每個Stage中包含多個Vertices，每個Vertex包含整個Stage處理的數(shù)據(jù)流處理其中的某一部分數(shù)據(jù)。SCOPE調(diào)度系統(tǒng)會按照這個DAG圖的依賴關(guān)系，調(diào)度并行執(zhí)行對應的Vertices節(jié)點。SCOPESELECTSQLC#寫的自定義處理函數(shù)或者聚合函數(shù)，用戶還可以寫MapReduce形式的序。通過自定義的PROCESS、REDUCE和CONBINE來定義更加靈活的操作。SQL操作也可以用如下的方式重寫。這里的MyProcessor、MyReducerbinerUDFSQL的語義，可以靈活的表達自己對應的業(yè)務(wù)邏輯內(nèi)容。要達到與上面的SQL-like代碼相同的語義，MyProcessor和t0=PROCESSPRODUCEA,t1=t0=PROCESSPRODUCEA,t1=REDUCEONPRODUCEA,B,USINGt2=COMBINEt0WITHt1ONt0.A==t1.APRODUCEA,B0,B1,123456789IEnumerable<Row>reduce(IEnumberable<Row>input,Rowoutput){intsum_b=0;intsum_c=0;foreach(Rowrowininput){output[0].Set(row[0].String);sum_b+=row[1];sum_c+=}output[1].Set(sum_b);output[2].Set(sum_c);yieldreturnoutput;IEnumerable<Row>reduce(IEnumberable<Row>input,Rowoutput){intsum_b=0;intsum_c=0;foreach(Rowrowininput){output[0].Set(row[0].String);sum_b+=row[1];sum_c+=}output[1].Set(sum_b);output[2].Set(sum_c);yieldreturnoutput;}123456789DtaSkw行計算中，很多時候不同階段需要一個等待同步的關(guān)系，等待一個階段中所有的計算任務(wù)完成才能進行下一個階段，這個時候計算階段的完成時間就取決于計算任務(wù)中耗以DtaSkw現(xiàn)象的出現(xiàn)在很大度降低并行計算的效率。現(xiàn)象的嚴重性并沒有得到應有的認識。在后面詳細的進行解釋。SCOPE產(chǎn)品組集群是一個典型的大數(shù)據(jù)計算任務(wù)平臺，每天有上萬個的任1000個任務(wù)作為本文研究的原始數(shù)據(jù)集合，這些任務(wù)中很大一我們的研究發(fā)現(xiàn)任務(wù)運行時并行度（DoP）rtex吞吐量（Throughput）是大數(shù)據(jù)平臺量數(shù)據(jù)規(guī)模下的并行計算任務(wù)運行表現(xiàn)中最重要的特征，可以幫助我們時刻運行的并行節(jié)點數(shù)越高反映了該時間內(nèi)任務(wù)對于并行資源的利用越好，這樣的時間越長對于一個數(shù)據(jù)并行任務(wù)來說越有利，因為它的使用到并行資源進行任務(wù)加速。吞吐量則是一個微觀的指標，可以描述并行計算的子任務(wù)的性能表現(xiàn)。在這樣的并行計算平臺上，調(diào)度一個子任務(wù)進行計算需要一些調(diào)度時間和啟動時間，那么如果rtex該rtex，進行有效計算的時間比例不高，如一個任務(wù)中絕大部分的計算都存在這樣的情況，那么這個任務(wù)很有可能性能不佳。為了更加有針對性的分析任務(wù)性能低下的原因，我們結(jié)合上面提到的兩個重要的衡量任務(wù)表現(xiàn)的指標因素，制定了下列幾個規(guī)則來幫助分類找出這樣的潛在的性能低下的任務(wù)。這里的“連續(xù)的”使得我們找到的長時間低并行的任務(wù)執(zhí)行過是在任務(wù)執(zhí)行的一20%是一個經(jīng)驗值，我們認為如果不正常的低并行階段已經(jīng)占到任務(wù)總時間的五TokenAllocationJob可以有足夠多的額定并行Job1Job表現(xiàn)為有一個或者幾個Vertex運行相當長的時間，而這個時候已經(jīng)沒有其他的子任務(wù)可以與其并行執(zhí)幾個花費異常多時間的VerticesStageJob的完成2JobStageVertex都開始了，但是很長一段時間都沒有任何Vertex完成，這顯然也是不正常的，很有可能是因為每個Vertex的計算復雜度過大或者處理的數(shù)據(jù)過多，但是即便如此，這個時候Job的并行度還是低于額定值的一半，意味著仍然可以通過調(diào)整Stage的并行度來提升性能，調(diào)度這樣的小計算節(jié)點是非常浪費的，因為調(diào)度一臺機器開啟一個計算任務(wù)是需要調(diào)度時間和啟動時間的，對于小任務(wù)，這樣的時間并不可以忽略；而對于系統(tǒng)來說，這樣的小數(shù)據(jù)帶來的隨機上的額外開銷也是一種低性能。我們經(jīng)驗性地認為這樣的小數(shù)據(jù)子任務(wù)在一個大數(shù)據(jù)計算任務(wù)中所占比例如果多于50%，那么這個任務(wù)很有可能是的459個是潛在的性能低下的任務(wù)。其中有部分的任務(wù)是相同的代碼重復提交處理不RecurringJob124個進行了深入的人工分析，通過觀察運行時并行度的統(tǒng)計圖和Vertex吞吐量的統(tǒng)計圖，以及回放整個計算的過來發(fā)現(xiàn)性能瓶頸所在的地方，然后通過人工定位找到對應的用戶代碼，根據(jù)任務(wù)執(zhí)行過中的日志記錄，綜合分析整個執(zhí)行過中用戶層面和系統(tǒng)層面SCOPE平臺上進行了重進行。因為大部分任務(wù)的運行時間很長，而且我們的研究工作不能影響產(chǎn)品部門正常在任務(wù)完成后就會被系統(tǒng)自動刪除，于是無法獲得這部分的數(shù)據(jù)進行實驗，因此這部分的任務(wù)沒有辦法被重新運行。本文研究中所的大數(shù)據(jù)任務(wù)均是微軟工師編寫的，來自微軟多個產(chǎn)品部門。一個在真實應用場景下的產(chǎn)品組集群中廣泛采樣的數(shù)據(jù)集。我們發(fā)現(xiàn)，因為商業(yè)團隊工普遍包括多個MapReduce計算過這可能是由于微軟超大規(guī)模的復雜系統(tǒng)應用的需MapReduce實現(xiàn)的大數(shù)據(jù)集群中是較為少見象用SOPE和#編寫運行在微軟大數(shù)據(jù)平臺上的序。然而，我們發(fā)現(xiàn)的三個層面的導致任務(wù)性能低效的原因在其他的大數(shù)據(jù)平臺上也是存在pdue現(xiàn)Hdoop次Hive和PigSLONT，SMDISTINT樣的重語，并支持過語言定的F我發(fā)采了獨特特性的編方影響任務(wù)的并行性能。本文的研究目標是在對于任務(wù)執(zhí)行過深入了解的基礎(chǔ)上，找出導致用戶任務(wù)性能不佳的原因，這些原因可能有很多種，但是我們不考慮客觀條件的限制因素導致的任務(wù)性能低下，比如說用戶的權(quán)限較低導致其只能在系統(tǒng)中申請到比較少的額定并行資源，進而用戶的任務(wù)受限于這個額定并行資源的量并在最終表現(xiàn)出性能不佳。這樣的問題并不能通過代碼優(yōu)化和系統(tǒng)優(yōu)化來解決，所以在這篇中我們不討論類似這樣的因素導致的性能問題。另外，因為同一臺機器上運行的其他子任務(wù)對于我們研究的子任務(wù)造成了不良的影響，進而最終導致整個任務(wù)運行緩慢的場景在現(xiàn)實中是存在經(jīng)有很多其他的研究工作在解決上面描述到的問題，這種研究對于分布式并行計算系統(tǒng)整體的性能的穩(wěn)定性提升有著重要的研究價值，但是這些因素對于任務(wù)本身來說是大數(shù)據(jù)平臺上的編實踐和系統(tǒng)對于任務(wù)的優(yōu)化工作。人工判斷原因的人工的檢查分析任務(wù)的性能是必不可少的，在整個研究過中，包括找到任務(wù)瓶頸SCOPE平臺是一個復雜的大數(shù)據(jù)平臺，平臺的復雜性和任務(wù)的多樣的任務(wù)，我們采用保守的方法，將其歸類到不明原因的那一類，本文中一種主要的發(fā)現(xiàn)來闡述。對于每個任務(wù)，我們通過反復的確認來盡可能減少性帶來的錯誤。我們通過上面的方法從大量的大數(shù)據(jù)任務(wù)中分類出一部分的潛在的低性能任務(wù)集合。因為產(chǎn)品組的任務(wù)中有很大一部分是urringob以處理新的數(shù)據(jù)，所以我們認為這樣的任務(wù)是相似的，不需要重復的分析。我們分析124言、數(shù)據(jù)和系統(tǒng)三個層面的大數(shù)據(jù)平臺上特有的原因。我們對于這些方面都進行了深入而細致的分析，總結(jié)了當前大數(shù)據(jù)平臺研究和性能優(yōu)化所的和。在語言層面上，大數(shù)據(jù)平臺設(shè)計的初衷就是為了給大量的用戶一個簡單的方法處理海量規(guī)模的數(shù)據(jù)，所以大數(shù)據(jù)平臺采用隱藏分布式并行細節(jié)的編語言，大數(shù)據(jù)平的SQlike語言既符合數(shù)據(jù)處理的語義又容易編而過型語言編寫的用戶定（F的差異。我們發(fā)現(xiàn)用戶一些不良的寫代碼的技巧會導致他們經(jīng)常寫出一些對于底層優(yōu)化器不友好的代碼，無法應用一些編譯優(yōu)化，從而導致整個任務(wù)的性能顯著降低。SPESOPE的語義讓用戶能夠很簡單清晰的完成他們的業(yè)務(wù)邏輯的編寫，但其中有些用戶代碼對于底層系統(tǒng)的優(yōu)化器來說是不友好的，它潛在的破壞了優(yōu)化器的一些假定，從而導致一些并行優(yōu)化沒有辦法應用，這最終導致了整個任務(wù)呈現(xiàn)出性能不佳的現(xiàn)象。而從另代碼是有問題，甚至他們都無法分辨出來這樣的過中存在著性能不佳，唯一知道的就是任務(wù)運行的時間很長，這無疑是非常致命的。PartialAggregate這樣的減少們的優(yōu)化后運行時間減少了64%，獲得了極大的性能提升。在SCOPE圖 種例子中，用戶代碼中的COUNTDISTINCT操作會導致同時進行的其他聚合操作的PartialAggregate優(yōu)化失效，使得代碼一階段完成后沒法通過PartialAggregate進行部分的聚合來減少數(shù)據(jù)項，從而使得DataSkew的現(xiàn)象更加的嚴重。PartialAggregateMapReduce計算模型中的重要優(yōu)化，如第2章中所示，它是指對于在Reducer階段進行的滿換和結(jié)合律的操作可以在Mapper階段完成后shuffle階段開始之Mapper對應的機器上先進行局aggregate，這樣能顯著減shuffle階段的數(shù)據(jù)量。在SCOPE中絕大部分內(nèi)建的聚合函數(shù)都是可交換和結(jié)合的。DtaSkw也如第2章中所示的那樣，是指同一階段中不同的計算節(jié)點間處理的數(shù)據(jù)量上存在差別的現(xiàn)象，而PrtilAgrgte優(yōu)化不只是能顯著減小hufle過的數(shù)DtaSkw的現(xiàn)象對于計算的影響，當上個階段的輸出存在很嚴重的SkwPrtialAgrgteduey一個了，那么下一階段的輸入數(shù)據(jù)項最多就是上一階段的并行機器數(shù)那么多，這樣能DtaSkw的影響。JobRecurringJob中存在上面描述的現(xiàn)象。RecurringJob是一種成產(chǎn)品任務(wù)，其代碼通常是穩(wěn)定的、保持不變的，但是會針對這里我們用這個RecurringJob某一次的運行結(jié)果來作為例子進行分析。圖4.1是那一次的運行性能表現(xiàn)圖，橫坐標表示Job圖 JobTaskJob運行過Vertex。根據(jù)圖4.2JobVertex所屬的SV11_AggregateStage163.91GB51.54GB的數(shù)據(jù)，其并750Vertexdataskew的問題，也就是分配時72%VertexVertex執(zhí)行的時間過長，直接導致了整個Job的執(zhí)行運行時間被大大延遲。雖然這個任務(wù)的低性能表現(xiàn)出來是一個DataSkew的現(xiàn)象，但是我們發(fā)現(xiàn)其中的編譯優(yōu)化后的代碼，將執(zhí)行過的Stage跟用戶代碼進行對應，從而找到導致該現(xiàn)象產(chǎn)最終，我們發(fā)現(xiàn)導致全局性能緩慢的Stage是一個REDUCE過為了更好地抽JobSUM操SELECTaasSELECTaasCOUNT(DISTINCTb)asB,SUM(c)asC,SUM(d)as…FROM123456SCOPE是這樣處理這段代碼的，一個PROCESS（相當于MapReducer中的Mapper）的階段，每一個PROCESSORtable這個表格按照AGroupBy操DISTINCT操作PROCESSOR沒有辦法對于CDPartialAggregate的操作。然后REDUCE階段的每個節(jié)點通過shuffle操作，從每一個Mapper中獲取自己ReduceKeyA這個column上相同的數(shù)據(jù)項放到一起，并按照B排序，之后就可以進行對應的COUNTSUM（c在這個例子中，很不幸的是，輸入的數(shù)據(jù)存在嚴重的數(shù)據(jù)傾斜（dataskew）問題，APartialAggregate導致數(shù)據(jù)沒有顯著的減少，大量的數(shù)據(jù)在shuffle過中將被放置到同一個Vertex上面，進而導致處理這個值的Vertex重負，這也就是導致了它運行的時間占掉了整個Job執(zhí)行時間的72%的原因，從而這個Vertex變成整個Job的瓶頸。PartialAggregate的操作PartialAggregatede操作拆分開，分別處理，最后再合并起來。于是可以把序改寫成下面的形式，從而避免這個問題，提升并行的效率，減少Job的執(zhí)行時間。這樣，對于T1的操作來說，SUM操作是滿換律和結(jié)合律的，系統(tǒng)會通過PartialAggregate優(yōu)化shuffle過最后Mapper上的輸出對于特定的A值只會有一行的數(shù)據(jù)，這樣數(shù)據(jù)量大大減小，即便有DataSkew也能顯著的減少其影響。對于T2的操作，雖然沒有PartialAggregate但是shuffle過不需要對于C和D這T2的操作時可以并行執(zhí)行的，這樣也對于執(zhí)行效率有顯著的提升。T1T1=SELECTaasSUM(c)asC,SUM(d)as…FROMT2=SELECTaasCOUNT(DISTINCTB)asFROMT3=SELECTT1.*,T2.BFROMT1,T223456789我們用修改后的方法重新運行了這個序，運行時間減少了64%，獲得了很好的在這個例子中，SELECTcolumnDISTINCT操作，導致了SELECTcolumnPartialAggregate優(yōu)化，這增大shuffle過的網(wǎng)絡(luò)IO，更不幸的是這個例子還遇到DataSkew的現(xiàn)象，沒有ParticalAggregate最終導致這個現(xiàn)象更加的嚴重。然而系統(tǒng)也不能簡單的自動進行類似上面形式的優(yōu)化，因為如果Acolumn數(shù)據(jù)量很大的話，改寫成后面這種形式反而會增大我們認為，DISTINCT操作在達到語義上便捷的同時對于分布式的運行環(huán)境來說是有不良影響的，因為同其他的聚合函數(shù)的結(jié)合使用會導致這個操作不滿換律和結(jié)合columnDataSkew帶來不良的影響，讓整個Job表現(xiàn)出相當差的性能。不只是DISTINCT和其他聚合函數(shù)的組合，用戶定義的不滿換律或者結(jié)合律的聚合函數(shù)也會帶來一樣的問題。進一步的，我們認為應該重新慎重的考慮大數(shù)據(jù)平臺上編語言的設(shè)計，編語言不僅要能夠讓用戶高效靈活的表達自己的處理邏輯，而且對于系統(tǒng)優(yōu)化器也應該是友好的，這樣才能做到編靈活性和任務(wù)執(zhí)行效率上的兼顧。從另一方面，在當前的編語們對于這種分布式數(shù)據(jù)并行系統(tǒng)實現(xiàn)和優(yōu)化的了解，我們可以找到的不友好的模式，大數(shù)據(jù)平臺上采用數(shù)據(jù)分塊的方式來使得同一階段中的子任務(wù)可以并行的執(zhí)行，廣泛性和任務(wù)的復雜性導致了任務(wù)過中存在多個運行的階段，對于中間階段我們很難控制其均勻性。盡管我們對于數(shù)據(jù)不平衡的操作都提供了一些更好的方法來避免，但是這需要用戶的信息輸入，并且在代碼中給出適當?shù)奶崾?，這樣才能幫助系統(tǒng)優(yōu)化器優(yōu)化整個執(zhí)行過減少整個任務(wù)其他正常運行部分的間接開銷，保持高效率。我們的研究中發(fā)現(xiàn)，除了最常見的GroupBy后數(shù)據(jù)不均勻?qū)е碌腟kew現(xiàn)象，還有JOIN操作帶來的Skew現(xiàn)象，這是一種更加棘手的Skew現(xiàn)象，因為是輸出的數(shù)據(jù)存在的現(xiàn)象，甚至SCOPE開發(fā)都沒有這個現(xiàn)象的存在，連事后分析的Skew現(xiàn)象的系統(tǒng)都沒有關(guān)于JoinSkew現(xiàn)象的反饋機制。Join是數(shù)據(jù)庫中非常普遍的操作，SCOPE也支持這樣的操作。Join操作將有兩個輸入數(shù)據(jù)集，而且Join操作是接的操作，有可能會導致數(shù)據(jù)量的增大，甚至有的時候會導致數(shù)據(jù)變得異常的大，最的情況莫過于Join的操作是一個笛卡兒積（CrossJoin）若兩個輸入表的行數(shù)nm，那么輸n*m行。SkewJoindataskew的一種Join中Join操作連Key存在Vertex這個現(xiàn)象最麻煩的地方在于系統(tǒng)難以預計JoinVertex也有可能有極大的輸出數(shù)據(jù)，這樣導致了調(diào)度上的和任務(wù)性能上的問題在SCOPE系統(tǒng)中，一般默認的把兩個非常大的表連接起來的方法是先讓這兩個輸這里面每個數(shù)據(jù)項會通過這個分塊函數(shù)計算出一個值，稱為PartitionKey，分塊函數(shù)保證JoinKey相同的數(shù)據(jù)他們的PartitionKey也是相同的，之后系統(tǒng)通過shuffle過將具有相同的Key值的數(shù)據(jù)項放到相同的Vertex上面處理。連接操作的JoinKey在同一個Vertex上可能分配不一樣。比如說對于不同的兩個VertexVertex處理partitionkey是aVapartitionkeybVbnm個數(shù)VertexJoinKeyVa1JoinKey是x，Va2JoinKey是yJoin操作后沒有任何輸出，而對于Vb來說，Vb1Vb2JoinKeyzn*m行。顯然，數(shù)據(jù)量大的節(jié)點會花費的時間，導致整個任務(wù)在相當長的一段時間內(nèi)處于現(xiàn)有SCOPE的機制是不允Vertex運行超5個小時，JoinSkew現(xiàn)象會導Vertex有更大的可能會失敗，也會導致失敗恢操作將產(chǎn)生比輸入還要多很多的輸出，這些輸出的結(jié)果將寫在該rtex磁盤中，長時間大數(shù)據(jù)量的寫入將對機器的磁盤帶寬產(chǎn)生影響，這很可能會影響在同rtex的執(zhí)行。個Job運行失敗了。任務(wù)失敗原因是，有幾個Vertices運行超過5個小時導致整個JobJoinColumnStage使用。Join操作的兩個輸入分別SV2，SV3的輸出，大小153GB215MB，數(shù)據(jù)partition1541G左右的數(shù)據(jù)。SV45個小時后被系統(tǒng)停止圖 SkewJoinJob部分執(zhí)行表 ExitProcessexecutiontimeistooProcessexecutiontimeistooProcessexecutiontimeistooProcessexecutiontimeistooVertices5SCOPE系統(tǒng)是不Vertex執(zhí)行超5個小時的，于是整Job被系統(tǒng)終止。表1SV4Stage的Vertex按照運行時間降序排序的前5個Vertex的詳細情況，VertexName一列括JMVertex運行緩慢進而克隆新Vertex來避免過長的運行時間（這個優(yōu)化在這里顯然也沒有起到效果。我們發(fā)現(xiàn)運行超過5個小時的Vertices輸入數(shù)據(jù)都不大，均小于0.5G，比平均值1G還小，但是都產(chǎn)生了上百G的輸出，遠高于所有Vertex平均的13.43G輸出。joinSet=joinSet=SELECTFROMtable1ONtable1.x==12345嚴重的傾斜，導致Vertex運行時間過長，進而被SCOPE系統(tǒng)終止?？梢宰層脩糁付ㄒ笙到y(tǒng)檢測Join過中可能的Skew問題。[ [ 1oinSkwoin的方Hit系統(tǒng)去檢測數(shù)據(jù)傾斜的現(xiàn)象是否存在，并采用更合適的執(zhí)行計劃來對待這部分傾斜數(shù)據(jù)，當然這會引入一些額外的開銷，但是在這個例子中完全足以抵消Skw帶來的不良象如用想要好控這個Skwoin照SkwoinHntprtitionprtition的大小和個數(shù)。SOPEoptmir會根據(jù)oin用戶向系統(tǒng)提示這個Join操作存在嚴重的數(shù)據(jù)傾斜的情況，系統(tǒng)會根據(jù)用戶提示DAG圖，用更好的SkewJoinHint后，整個任務(wù)得以順利的執(zhí)行，從之前的運行將近7個小時后失敗變成了優(yōu)化后3.9個小時的時間完成。數(shù)據(jù)：數(shù)據(jù)存在嚴重的Skew，就是說某個特定PartitionKey上的兩個輸入有相當JoinKeyJoin操作會在數(shù)據(jù)量上有成倍的增長，因此產(chǎn)生非常多的輸出，導致輸出的IO成為了瓶頸。據(jù)具有怎樣的分布情況，是不可知的，一方面用戶沒有告知系統(tǒng)相關(guān)的信息，另一方面由系統(tǒng)自發(fā)的去檢測數(shù)據(jù)模式則會帶來嚴重的性能問題，在大多數(shù)情況圖 優(yōu)化后部分的Job執(zhí)行下是得不償失的。Join操作隱含著帶來的數(shù)據(jù)的特性，該操作的輸出數(shù)據(jù)大0.5GB的輸入居然能產(chǎn)生375GB的輸出，從而讓這個Vertex成為整個序的瓶頸。正是因為系統(tǒng)無法從輸入的數(shù)據(jù)大小上判斷出Join操作是否存在Skew，所以采用了默認的Join的Join方法只不過系統(tǒng)沒法采用。數(shù)據(jù)某些度上的不均衡，會導致中間過存在急劇膨脹的現(xiàn)象，有可能使得一個Vertex需要處理過多的數(shù)據(jù)，從而對于序性能的危害。oin帶來任務(wù)性能不佳的問題，有的時候大數(shù)據(jù)量的本地磁盤寫入操作還會影響在這個機器上運行的其他操作，從而復雜的性能問題。對于序員來說，要有數(shù)據(jù)跟并行計算任務(wù)性能密切相關(guān)的認識。在編寫序的時候要慎重地使用Join操作，同時在提交任務(wù)的時候要確認自己處理的數(shù)據(jù)的數(shù)據(jù)模式，相對的，在Join操作中對于分布不是很均勻的時候，要根據(jù)輸入數(shù)據(jù)依據(jù)數(shù)據(jù)量的大小和傾斜度，配合系統(tǒng)的Hint機制給出的信息，整個執(zhí)行過的優(yōu)化，這供的信息處理好數(shù)據(jù)層面的問題，至少是一些有效的反饋機制。在產(chǎn)品組反復運行的任務(wù)這種背景下，反饋機制可以幫助用戶改進RecurringJob的性能。大數(shù)據(jù)平臺是一個現(xiàn)實中不斷迭代發(fā)展中的軟件系統(tǒng)，系統(tǒng)不可避免的存在一些任務(wù)有可能違背了系統(tǒng)在設(shè)計之初的某些假定，從而導致了一些不良性能的現(xiàn)象。對于一個并行序來說，并行度是很重要的決定并行序性能的指標。然而遺憾的MapReduce模型中，REDUCEMAP階段開始前就決定，因MAPREDUCE階段的任務(wù)數(shù)進行重新分塊，但是這個數(shù)值很難很好的確定，因為一個并行階段的效率跟它的輸入數(shù)據(jù)量和并行任務(wù)PEDE階段的輸入數(shù)據(jù)量的。SOPEDrydpdue的優(yōu)化。它有一個動態(tài)調(diào)整并行任務(wù)個數(shù)的機制，可以在執(zhí)行的過中根據(jù)一些信息對于階段任務(wù)數(shù)進行動態(tài)調(diào)整，但是其本質(zhì)也是不知道上一個階段的實際輸出的，只能通過預估的方式進行調(diào)整，不可避免的有其限制性。SOPE出于效率的考慮，對于EDE和OINE25樣的大數(shù)據(jù)任務(wù)都會在開始伴隨著一個大量的篩選過濾的過實際任務(wù)處理的數(shù)據(jù)量通常比輸入數(shù)據(jù)要小很多，如果這個上限設(shè)置的比較高，會導致有很多rtis只處理極小量的數(shù)據(jù)，系統(tǒng)底層被迫創(chuàng)建很多的小文件，這樣會有很大的上的間接開銷，從而性能表現(xiàn)不好。并且如果上一個階段有m個并行任務(wù)，這一個階段設(shè)置了n的hufle過會有mn個連接，如果m和n都很大話，為一個并行任務(wù)的瓶頸，特別是針對那種中間過也是海量數(shù)據(jù)的計算復雜型任務(wù)的時ReducerReducer階段持續(xù)很長的時間。行計算資源并不是的，這些限決于調(diào)度機制、用戶權(quán)限以及其他的一些因素。Allocation了任務(wù)運行時必須部分的并行資源，另一方面也限制任務(wù)并行度不能無，同時它也是系統(tǒng)優(yōu)化器在確定任務(wù)執(zhí)行流圖的時候會考慮的一個因素。當可以并行執(zhí)行的任務(wù)數(shù)味著單個任務(wù)處理的數(shù)據(jù)量過小，少到幾Mk這樣級別的數(shù)據(jù)，這導致了系統(tǒng)不得不創(chuàng)建很多的小文件，子任務(wù)數(shù)據(jù)的時候幾乎都是碎片般的隨機，這將在存作為介質(zhì)的，大量的隨機小文件使得時間都花在機械硬盤的尋道上，從而延長并行度過高這種現(xiàn)象一般是產(chǎn)生在PROCESSREDUCECOMBINE這兩個階段，SCOPE圖 Job運行性能表現(xiàn)限制，而對于PROCESS階段沒有任何的限制，開始階段的PROCESSOR個數(shù)完全取決于數(shù)據(jù)量和datapartitionPROCESSOR并行度主要取決于上一個階段的Vertex數(shù)。研究過中發(fā)現(xiàn)了這樣一種情況，當前一個階段處理完一個數(shù)據(jù)集后，該數(shù)據(jù)集POESS階段來執(zhí)行的。具體的,rtexpror均處于可以被調(diào)度的狀態(tài)，接下來調(diào)度器基于當前可以調(diào)度的資源量并且綜合考慮數(shù)據(jù)的所在地（olityrtisrtexrties完成之后，調(diào)度系統(tǒng)才知道這個階段的具體輸出數(shù)據(jù)量大?。欢鴮嶋H上在系統(tǒng)實現(xiàn)上，通常為了利用好空rtexrtie，這rtis度器發(fā)現(xiàn)初始階段產(chǎn)生的數(shù)據(jù)量很小，不應該使用這么多的并行任務(wù)，但是也已經(jīng)來不及了。于是我們在最后會看到系統(tǒng)安排了大量的rtis處理極少量的數(shù)據(jù)，這種并行度過高的現(xiàn)象顯然也是一種性能不佳的體現(xiàn)。圖4.5是我們中發(fā)現(xiàn)的一個Job的運行性能表現(xiàn)圖，橫坐標是時間，單位是秒，縱坐標是并行運行的Vertex個數(shù)，不同顏色的色塊代表不同的Stage，具體如圖例圖 局部的Job運行執(zhí)行這里是一個Combiner數(shù)量不合適的例子，當然Aggregator（也就是Reducer）同理也存從圖4.5StageSV7_Combine_Split運行了相當長的時間，顯然是整個任務(wù)的瓶頸。SV7Job263s左右就開始，但是在2500s的時候才結(jié)束，占總運行時間的85%以上，運行時間非常的長。圖4.6JobSV7的輸入數(shù)據(jù)SV3SV6的輸出，兩REDUCE階段。SV7在輸378.43GB數(shù)據(jù)后Join1.14TBSV7將數(shù)據(jù)按照列進行切片，方便下面的Stage使用。圖4.7SV7Stage的詳細執(zhí)行圖，我們可以看出，SV7首先是對于輸入的數(shù)據(jù)進行了Join的操作，然后通過個叫MobileIEDecoder的用戶定義函數(shù)，對于數(shù)據(jù)進行圖4.8SV7Vertex讀寫數(shù)據(jù)量的統(tǒng)計圖，橫坐Vertex的個數(shù)，總共有250個，縱坐標表示數(shù)據(jù)量的大小，單位是GB，藍色的是讀數(shù)據(jù)的量，紅色的是寫數(shù)據(jù)的量。我們從中可以看出，SV7這個Stage處理的數(shù)據(jù)量是比較均勻的，我們對于這個UDF人工的進行靜態(tài)代碼分析，發(fā)現(xiàn)這是一個復雜的字符串圖 SV7的詳細執(zhí)行圖 一個復雜度比較高的用戶定義函數(shù)，而這導致了整個Stage運行緩慢，整個Job的瓶頸只被安排了250個Vertices，也就是說它的最高運行時并行度只能有250。雖然這個Job的TokenAllocation高達1068，但是多于250那部分的計算資源沒有用到。這顯然也是Job的TokenAllocation1068。也就是說這Job可以獲1068的受系統(tǒng)保證的并行度。但是因為SV7250的并行度，Job長期處于并行250的狀態(tài)，大大浪費了申請到的資源。并且從執(zhí)行圖可以看出，SV7Vertex都至少花了1000s才完成。完全可SV7Vertex處理的數(shù)據(jù)量進而減少整個Job的運行時間。這是要求用戶對于自己處理的數(shù)據(jù)量要有一個比較準確的估計，而對于序中的Hint是有可能會沒有作用的，因為優(yōu)化器分析后可能會發(fā)現(xiàn)用戶要求的計劃是做不到的，那么這個PLANHINT就無法生效。有一個產(chǎn)品組任務(wù)，其輸入大約是264TB數(shù)據(jù)，首先是一個數(shù)據(jù)轉(zhuǎn)換和過濾的初始階段，SCOPE40000Vertices進行這部分的處理，這是合理的。然而如圖4.9380MBPROCESS過將對于這個數(shù)據(jù)進行處理，分別是SV17SV28，但是每個階段都安排了40000個圖 Job執(zhí)行流Vertices，而這個時候我們知道并行的意義已經(jīng)不大了，這種情況下高并行對于和調(diào)度系統(tǒng)來說的間接開銷之大已經(jīng)顯而易見了。同實例一一樣，PLANHINT可以幫助解決這個問題，用戶通過給系統(tǒng)提示，限制PROCESS階段的任務(wù)數(shù)，也減小了后繼階段的上的間接開銷，這在提升任務(wù)性能但是這樣的解決辦法還是無法解決最開始階段過濾后產(chǎn)生小量數(shù)據(jù)給系統(tǒng)帶來的這部分間接開銷。除非系統(tǒng)中存在對于極小量的輸出將其放在內(nèi)存中，讓后面階的rtex直接讀內(nèi)存，這樣就能完全避免磁盤隨機所損失的時間。并將得到的數(shù)據(jù)直接輸出到分布式的文件系統(tǒng)中。第二個任務(wù)再讀這個輸出的中間數(shù)據(jù)，利用了分布式文件系統(tǒng)的性質(zhì)把數(shù)據(jù)組織成比較大的文件塊。這樣后面的第二個任務(wù)就減少了很多的調(diào)度和上的間接開銷，其需要調(diào)度的任務(wù)數(shù)也少了，數(shù)據(jù)的過也變成對于大文件的順序了，從而獲得良好的性能表現(xiàn)。特別是對于那種過濾后的中間數(shù)據(jù)將被反復使用的情況，第二種解決方更加的有效。PROCESS、REDUCE和COMBINE的階段都支持采用（UDF在MapReduce系統(tǒng)中，Reducer的個數(shù)必須在Mapper開始前就決定，因為MapperReducerMapper完成前，系統(tǒng)又的數(shù)據(jù)大小來進行估計的，這帶來了系統(tǒng)決策上的。另外，在SCOPE這樣的基于DAGMapReduceREDUCEVertex個數(shù)的設(shè)置是具有全局影響的，這顯然比單獨的、輸入數(shù)據(jù)量是已知的一個MapReduce的情況更加SCOPE系統(tǒng)能夠做到的動態(tài)調(diào)整又非常的有限，當然這種動態(tài)調(diào)整本SOPE對于EDE20務(wù)都會在開始伴隨著一個大量的篩選過濾的過實際任務(wù)處理的中間過數(shù)據(jù)量通被迫創(chuàng)建很多的小文件，這樣會有很大的上的間接開銷。但是隨著現(xiàn)在大數(shù)據(jù)平臺更加廣泛的使用，這樣的限制現(xiàn)在已經(jīng)不適合很多的應用了，現(xiàn)在甚至有任務(wù)是輸入的時候只比較少的數(shù)據(jù)，但是中間的數(shù)據(jù)會很大，這樣顯然違背了平臺設(shè)計的時候潛在的假定。于是，在當前復雜的應用任務(wù)的需求下，采用動態(tài)并行度決策的機制是很有必要的，但是也是很有難度和的。實時的獲取運行時的任務(wù)信息并進行一些調(diào)整肯定會帶來系統(tǒng)的額外開銷，如何在盡可能小的開銷下完成更好的動態(tài)決策是一個非常有性的問題。在產(chǎn)品組集群中，我們可以結(jié)合產(chǎn)品組任務(wù)反復運行的特點，根據(jù)任務(wù)Kvulyatl.[9]和itl.[10]的工作，均對類似的分布式系任務(wù)進行了分析和總結(jié)。前者是分10Hdoop集群的log.%Hdoop任務(wù)消耗了系統(tǒng)的計算資源，因此減少這樣可以有效的增加系統(tǒng)資源，但是前者分析的數(shù)據(jù)源是來自大學的大數(shù)據(jù)研究團隊的數(shù)據(jù)，數(shù)據(jù)量較小而且跟現(xiàn)實的產(chǎn)品SOPE產(chǎn)品組的日常任務(wù)進行了分析，分析中250失任，了些類失原解方。們SOPE系統(tǒng)因為這些錯誤的代碼而損失的計算性能。但是他們的工作只分析了失敗的任務(wù)，而沒有分析運行緩慢性能不佳的任務(wù)。行計算領(lǐng)域非常的問題，很多工作對于這個問題進行了深入的研究，嘗試從系統(tǒng)優(yōu)化的角度，對于這任務(wù)進行更好的分析。這些工作包括Mantri[11]，SkewTune[12]，Scarlett[13]，還有應用了任務(wù)克隆的[14]、任務(wù)推測的[15]。MantriScarlett都是通過對于skew的原因進行建模分析來優(yōu)化調(diào)度的過從而提升性能。Mantri使得在調(diào)度的時候考慮當前資源現(xiàn)狀，從而減少出現(xiàn)Skew的概率；Scarlett則通過分析和預測活躍數(shù)據(jù)所況。SkewTuneSkewDataSkew的，但是消耗了的系統(tǒng)資源。這些工作都有效的優(yōu)化了系統(tǒng)，來減少Skew現(xiàn)象的出現(xiàn)和降低Skew現(xiàn)象的影響。SCOPE從代碼編譯到優(yōu)化執(zhí)行到調(diào)度過都有一系列的系統(tǒng)優(yōu)化的工作，使得整個系統(tǒng)以及運行的大數(shù)據(jù)任務(wù)更加的高效。除了SCOPE[16]提到的優(yōu)化，近幾年還有很多在這個平臺上的優(yōu)化工作。Ananthanarayananetal.[11]的工作通過探測發(fā)現(xiàn)長時間沒有完成的子任務(wù)，也就是Outlier，通過重啟任務(wù)、根據(jù)網(wǎng)絡(luò)環(huán)境調(diào)度任務(wù)和保護有價值的任務(wù)輸出來減少Outlier對于序的影響，加快并行序的運行。Zhangetal.[17]SUDO的優(yōu)化框架，可以對用戶定義的函數(shù)進行分析，使其對于優(yōu)化器來說不再是黑盒，從而采取對應的優(yōu)化，減少data-shuffle過中的網(wǎng)絡(luò)IO。Guoetal.[18]的工作通過分析序代碼，進行相應的代碼優(yōu)化，采取刪掉沒有必要的代碼和數(shù)據(jù)、更早的進行數(shù)據(jù)過濾等操作，減少并行序執(zhí)行過中最耗費網(wǎng)絡(luò)IO的data-shuffle過的數(shù)據(jù)量，從而提高SCOPE序的執(zhí)行效率。這些優(yōu)化在編譯階段和運行階段都對于SCOPE序的執(zhí)行進行了深度的優(yōu)化，從各個方面提高了分布式執(zhí)行計劃的效率。但是即便有這么多的優(yōu)化，我們還是發(fā)現(xiàn)了運行的序中存在這些性能動態(tài)調(diào)度方面，Optimus[Dryad[8CIEL[20]上的執(zhí)行圖動態(tài)重寫的機制，結(jié)合了收集到的數(shù)據(jù)信息統(tǒng)計以及次型語言的語義，獲得了遠高于靜態(tài)產(chǎn)生的執(zhí)行計劃的性能表現(xiàn)。但是我們注意到Optimus并沒有做到對于用戶定義函數(shù)語義的分型SQlike語言和過型語言#va層pdue系統(tǒng)的應用構(gòu)成的大數(shù)據(jù)平臺目前已經(jīng)得到了廣泛的應用，給用戶在海量機器平臺上實現(xiàn)并行計算序帶來了巨大的便利，使其可以不用考慮繁雜的并行計算的細節(jié)，切實的提高了編的效率。對于這樣的大數(shù)據(jù)平臺進行性能研究工作有著重要而深遠的意義。分析工作，抓住了海量數(shù)據(jù)環(huán)境下大規(guī)模并行計算序的特征，找到有效其中一部分性能表現(xiàn)不佳的SCOPE任務(wù)經(jīng)過修改和重新運行后獲得了性能上64%的任務(wù)運行時間，并且大大減少了任務(wù)因為運行時這只是一個剛剛開始的工作，了解大數(shù)據(jù)平臺上目前任務(wù)的性能瓶頸的根源所在可以幫我們更好的了解大數(shù)據(jù)系統(tǒng)當前的根本問題。本文的研究工作也讓我們發(fā)現(xiàn)了在語言、數(shù)據(jù)和系統(tǒng)層面上還有很多的和等待我們?nèi)ネ黄坪徒鉀Q，這都是一些可以進行的進一步工作。包括：語言層面上，設(shè)計大數(shù)據(jù)編語言的時候，在保持其靈活性和透明性的同時應數(shù)據(jù)層面，因為數(shù)據(jù)平衡是一件重要而的問題，系統(tǒng)設(shè)計時應引入相應的制，鼓勵和引導用戶處理好數(shù)據(jù)層面的問題，至少是一些有效的反饋機制。在產(chǎn)品組任務(wù)的背景環(huán)境下，可以通過有效反饋來幫助用戶改善反復運行的Recurringob的性能。分析來提供一種動態(tài)的執(zhí)行過優(yōu)化機制，動態(tài)調(diào)整不同階段的任務(wù)運行的并(SKSDE)(SA)，讓我夠在大三暑期和大四期間學習到分布式系統(tǒng)領(lǐng)域的相關(guān)知識，并且在一個真實的大數(shù)據(jù)平臺上完成。感謝導師李未教授，在百忙之中仍抽出時間對于畢業(yè)設(shè)計進行指導，在在答辯過中的幫助和指導。感謝羅杰老師指導我的寫作。感謝我在微軟亞洲的ntr，首席研究員周禮棟，在科研思維上面對于我學態(tài)度和對于科研前沿的敏銳洞察力讓我受益匪淺。感謝一起參與到這個項目中的楊。感謝輔導員閆昭和，大學四年來從學習到生活上的關(guān)心和幫助，讓我遠離家鄉(xiāng)也倍感。在SA實習期間認識的同組聊天觸發(fā)了我很多的思考，讓我對計算機科研領(lǐng)域有了更加廣泛而深入的了解，感謝他們在科研和生活上給予幫助和鼓勵。感謝女朋友陳倩嵐對于研究工作一直以來的理解支持和無微不至的照顧。最后感謝父母23年來的教育和，這四年來在遠方對支持和鼓勵，沒有就沒有今天。，這篇文章乃至這整個畢業(yè)設(shè)計的完成就是對付出DeanJ.,GhemawatS.MapReduce:SimplifiedDataProcessingonLargeClusters[J].Commun.ACM,2008,51(1):107–113..OlstonC.,ReedB.,SrivastavaU.,etal.Piglatin:anot-so-foreignlanguagefordatapro-cessing[A].Proceedingsofthe2008ACMSIGMODinternationalconferenceonMan-agementofd]..[S.l.]:[s.n.],2008:1099–1110.GatesA.F.,NatkovichO.,ChopraS.,etal.Buildingahigh-leveldataflowsystemontopofMap-Reduce:thePigexperience[J].ProceedingsoftheVLDBEndowment,2009,ThusooA.,SarmaJ.S.,JainN.,etal.Hive:awarehousingsolutionoveramap-reduceframework[J].ProceedingsoftheVLDBEndowment,2009,2(2):1626–1629.ThusooA.,SarmaJ.S.,JainN.,etal.Hive-apetabytescaledatawarehouseusinghadoop[A].DataEngineering(ICDE),2010IEEE26thInternationalConferenceon[C]..[S.l.]:[s.n.],ChambersC.,RaniwalaA.,PerryF.,etal.FlumeJava:easy,efficientdata-parallelpipelines[A].ACMSigplanNotices[C]..[S.l.]:[s.n.],2010，45:363–375.ofMassiveDataSets[J].Proc.VLDBEndow.,2008,1(2):12