調(diào)度、模型、同步與任務(wù)——阿里云大數(shù)據(jù)數(shù)倉建設(shè)性能優(yōu)化方案

摘要：?對于阿里云大數(shù)據(jù)數(shù)倉建設(shè)性能優(yōu)化而言，主要可以從調(diào)度優(yōu)化、模型優(yōu)化、同步優(yōu)化以及任務(wù)優(yōu)化這四個方面著手。其實，對于性能優(yōu)化而言，最終還是會歸結(jié)到“資源”之上，所以資源是否足夠，分配是否合理也是我們在進行性能優(yōu)化時必須考慮的關(guān)鍵所在。

摘要：對于阿里云大數(shù)據(jù)數(shù)倉建設(shè)性能優(yōu)化而言，主要可以從調(diào)度優(yōu)化、模型優(yōu)化、同步優(yōu)化以及任務(wù)優(yōu)化這四個方面著手。其實，對于性能優(yōu)化而言，最終還是會歸結(jié)到“資源”之上，所以資源是否足夠，分配是否合理也是我們在進行性能優(yōu)化時必須考慮的關(guān)鍵所在。

以下內(nèi)容根據(jù)演講視頻以及PPT整理而成。

本次演講視頻分享，請戳這里！
本次演講PPT下載，請戳這里！
關(guān)于MaxCompute更多精彩文章，請移步云棲社區(qū)MaxCompute公眾號！

本文將主要圍繞以下四個方面進行介紹：調(diào)度優(yōu)化、模型優(yōu)化、同步優(yōu)化以及任務(wù)優(yōu)化。對于調(diào)度優(yōu)化而言，將分享任務(wù)調(diào)度如何進行優(yōu)化，以及如何看到調(diào)度的瓶頸點，以及在初步進行建設(shè)和使用數(shù)據(jù)倉庫的任務(wù)之后，對于任務(wù)如何進行調(diào)整來滿足業(yè)務(wù)的時間要求。對于模型優(yōu)化而言，主要包括一些優(yōu)化相關(guān)的想法、建議以及技術(shù)的優(yōu)化點。對于數(shù)據(jù)同步優(yōu)化而言，也是大家在建設(shè)數(shù)據(jù)倉庫的過程中經(jīng)常遇到的問題，也就是將數(shù)據(jù)從其他數(shù)據(jù)庫同步過來或者向其他數(shù)據(jù)庫進行數(shù)據(jù)同步的時候，經(jīng)常會遇到一些像某些任務(wù)運行過慢或者影響其他任務(wù)的情況。對于任務(wù)優(yōu)化而言，主要指的是計算任務(wù)，也可以理解為MaxCompute的SQL任務(wù)，這部分將與大家分享如何去優(yōu)化這部分的任務(wù)。

一、調(diào)度優(yōu)化
在數(shù)據(jù)倉庫建設(shè)的過程中，大家都會需要跑一些任務(wù)，那么這些任務(wù)如何進行配置才會是最優(yōu)的呢？如果出現(xiàn)了瓶頸點或者業(yè)務(wù)第二天所需要的數(shù)據(jù)并沒有給到，那么很大一部分的情況需要從調(diào)度方面來考慮，是不是有些任務(wù)的時間點設(shè)置的不合理？或者是不是有些任務(wù)的優(yōu)先級設(shè)置的不合理？這些可能是在調(diào)度層面，大家需要優(yōu)先考慮的一個點。

調(diào)度優(yōu)化方式
調(diào)度優(yōu)化的主要方式如下圖所示，按照道理前三點應(yīng)該在設(shè)計初期提前想到或者提前規(guī)劃好的。而目前大部分客戶還是用了一段時間的數(shù)據(jù)倉庫的時候，才發(fā)現(xiàn)存在一些問題，當?shù)诙煨枰鰣蟊淼臅r候才想到去優(yōu)化這些點。

第一點就是對于大任務(wù)而言，需要將其預定處理的時間提前，這里的大任務(wù)也就是耗時比較長的任務(wù)，如果任務(wù)已經(jīng)在跑了，那么很好評估，在DataWorks里面可以看到哪些任務(wù)跑得慢。此外還有一個評估方法就是在第一次建立數(shù)倉的時候，表的數(shù)據(jù)量很大那么也肯定是大任務(wù)。對于這些大任務(wù)而言，需要將其定時的時間提前，也就是將其優(yōu)先級提前。第二點就是將關(guān)鍵節(jié)點的定時時間提前，這里所謂的關(guān)鍵節(jié)點并不是說其數(shù)據(jù)量大，而是業(yè)務(wù)很重要的任務(wù)。第三點就是需要做到任務(wù)的隔離，這里主要指的是在使用DataWorks的時候會用到一些調(diào)度資源，不管是運行SQL也好還是運行同步任務(wù)也好，這些任務(wù)都需要跑在DataWorks的調(diào)度資源里面，那么如果將這些任務(wù)都放在一個項目就會出現(xiàn)問題，比如某個同步任務(wù)設(shè)置了10個并發(fā)，這樣就占據(jù)了10多個調(diào)度資源，這樣就可能將資源全部占滿了，這樣就會導致其他任務(wù)需要等待，這里不是指的MaxCompute資源不夠，而是DataWorks的調(diào)度資源不夠了。因此，一方面需要將開發(fā)和生產(chǎn)隔離開，避免因為開發(fā)臨時啟動了測試任務(wù)導致生產(chǎn)環(huán)境受到影響，因此要盡量將DataWorks里面的開發(fā)項目和生產(chǎn)項目分離開。此外，如果生產(chǎn)項目也很大，可能就需要按照數(shù)倉的分層或者不同業(yè)務(wù)拆分成不同的項目，這也是避免資源出現(xiàn)搶占，避免影響其他業(yè)務(wù)的一種方式。當然，這樣的做法有利也有弊，因為這樣做會使得復雜度增加，對于企業(yè)而言，后續(xù)的運維成本也會高一些，因此這需要看大家應(yīng)該如何評估，如果數(shù)據(jù)量達到了一定的規(guī)模其實可以分拆出來的，但是如果數(shù)據(jù)量不是很大，那么就可以先不考慮分拆。第四點就是減少任務(wù)層級的依賴，大家在進行調(diào)度的時候，都會在DataWorks里面看到依賴的上一層或者下游依賴哪一些任務(wù)，而任務(wù)互相依賴的層級應(yīng)該是越少越好的，但是按照數(shù)倉分層，依賴至少需要三層，這三層依賴是肯定存在的，除此之外還會有一些中間表，這樣就會有四層或者五層，但是盡量不要出現(xiàn)10層以上甚至20層的依賴，這樣復雜的任務(wù)依賴會使得后期去排查任務(wù)的依賴成本升高。如果在數(shù)倉建設(shè)的初期或者建設(shè)的過程中發(fā)現(xiàn)了一些問題就可以從以上四個點出發(fā)進行考慮。

二、模型優(yōu)化
對于模型優(yōu)化而言，必須要按照什么方式進行設(shè)計以及模型必須是什么樣子的，其實沒有一個定性的結(jié)論。這里也只是給出一些建議和想法。

對于數(shù)倉的建模而言，其實可以分為3NF建模和維度建模等，而推薦使用維度建模方式，可以按照星型模型或者雪花型架構(gòu)的方式去建模。3NF建模方式或者實體建模方式的應(yīng)用型會差一點，在很多時候其性能也會差一點，但是3NF在很多時候都會避免數(shù)據(jù)的冗余，其擴展性會好一些。而維度建模會有一定的數(shù)據(jù)冗余，并且冗余程度會很高，但是對于上層使用者而言，其易用性要好很多，并且其查詢的性能也會好很多，雖然可擴展性會稍微差一些，但是仍然處于可接受的范圍之內(nèi)。之所以在MaxCompute這邊推薦大家使用維度建模，是因為其特點之一就是會存在數(shù)據(jù)冗余，但是數(shù)據(jù)冗余對于MaxCompute這種離線數(shù)據(jù)倉庫來說，存儲成本并不是很高，因為其都屬于SATA盤的存儲，這樣的存儲成本是很低的，而傳統(tǒng)的數(shù)據(jù)倉庫比如使用Oracle等其他的關(guān)系型數(shù)據(jù)庫構(gòu)建的數(shù)據(jù)倉庫，大家往往會選擇3NF的建模方式，這是因為其數(shù)據(jù)冗余存儲成本會很高，磁盤很貴。

總之，在MaxCompute上推薦大家使用維度建模，使用星型建模或者雪花型建模的方式，這無論對于后續(xù)的運維還是后續(xù)對于數(shù)據(jù)的使用而言，都是比較便利的，并且性能也會好一些。星型模型其實就是中間一個事實表，周邊圍繞著一堆維度表，其結(jié)構(gòu)會簡單一些，使用比較方便，性能也比較好；對于雪花模型而言，維度表可能還會繼續(xù)關(guān)聯(lián)其他的維度表，這種方式就是雪花模型，它會略微比星型模型復雜一些。其實星型模型也可以理解為較為簡單的雪花模型。這里推薦大家使用星型模型，當然如果業(yè)務(wù)非常復雜，必須要使用雪花型也可以使用。這是因為星型模型雖然有數(shù)據(jù)冗余，但是其結(jié)構(gòu)比較簡單，容易理解，而且使用起來只需要A傳給B就可以了，不需要再關(guān)聯(lián)一個C。

除了上述兩個較大的關(guān)鍵點之外，還有一些值得注意的小點，比如中間表的利用，在這部分主要是將數(shù)倉分為三層，第一層做緩沖，第二層做整合，第三層做應(yīng)用。但是并不是嚴格地只能分為三層，中間還是會有一些中間表的，如果能夠利用好中間表則會增強數(shù)倉的易用性以及整體的性能。其主要是在數(shù)倉的第二層里面，因為需要整合一些數(shù)據(jù)，但是整合之后的數(shù)據(jù)依舊是明細的，可能有幾百億甚至幾千億的量級，對于這些表而言，數(shù)據(jù)量往往很大，而且下游任務(wù)以及依賴于這個表的報表任務(wù)有很多，因此可以做一些輕度的匯總，也就是做一些公共的匯總的中間表，這樣應(yīng)用好了可以節(jié)省很多的計算量和成本的。雖然建議大家利用中間表，但是也不建議使用太多的中間表，這還是因為中間表越多，依賴的層級也會越多。

在某些情況下還需要進行拆表，比如某一個大表字段比較多，但是可能其中某兩三個字段的產(chǎn)出比較慢，產(chǎn)出很慢可能是因為其加工邏輯很復雜或者數(shù)據(jù)量比較大導致的，而其他字段產(chǎn)出卻是很快的，此時就可以將數(shù)據(jù)表拆開，將過慢的字段拆出來，并將原來正常的字段留在原來的表，這樣就可以避免因為兩個過慢的字段影響其他業(yè)務(wù)，拆表的場景雖然比較常見，但是可能不會在數(shù)倉建設(shè)初期就出現(xiàn)。

還有一種場景及就是合表，這與拆表是相對的，當大家使用數(shù)倉一段時間之后會發(fā)現(xiàn)A業(yè)務(wù)部門出了一些表，B業(yè)務(wù)部門也出了一些表，而這些表或者數(shù)據(jù)可能是重疊的，也可能業(yè)務(wù)含義是一樣的，只不過字段不一樣。對于這些表而言是可以進行合并的，因為在合并之后可以做整體批量加工的SQL，這樣要比多個表批量加工的SQL復雜度要低很多，而且性能要好很多。對于分區(qū)的場景而言，也要合理地設(shè)置MaxCompute的分區(qū)。

此外還有拉鏈算法，這在傳統(tǒng)數(shù)倉里面也會用到，大家往往會需要使用拉鏈算法來記錄歷史變化情況。而拉鏈算法會使得計算成本變得比較高，尤其在MaxCompute里面或者離線數(shù)倉Hive里面，這是因為其沒有Update的操作，因此需要遍歷全表，需要對比昨天的全量和今天的增量，甚至是比較昨天的全量和今天的全量，才能得到所想要的拉鏈算法的結(jié)果，這樣的計算成本對于MaxCompute而言要高很多。如果數(shù)據(jù)量不大，每天做全量的拉鏈算法也是沒有問題的，只需要考慮保留多久歷史數(shù)據(jù)的問題。而實際上，有些業(yè)務(wù)不會關(guān)心這些歷史數(shù)據(jù)的變化問題，對于這樣的業(yè)務(wù)其實可以只保留最近多少天的歷史數(shù)據(jù)就可以了。其實是因為MaxCompute這邊的數(shù)據(jù)存儲成本很低，如果不使用拉鏈算法，那么就意味著數(shù)據(jù)冗余會高很多，所以其實大家可以計算一下每天增量數(shù)據(jù)的存儲成本有多少，再對比一下數(shù)據(jù)的計算成本，根據(jù)自己的業(yè)務(wù)進行均衡。但是如果每天增量數(shù)據(jù)達到百億這種級別，保留全量數(shù)據(jù)肯定是不現(xiàn)實的，那么就還是去做拉鏈算法。

模型優(yōu)化-合理設(shè)計分區(qū)
MaxCompute分區(qū)的功能一定要合理利用，這對于性能會產(chǎn)生很大的影響，一級分區(qū)一般都是按照天劃分的，建議大家一天一個增量或者一天一個全量來做。二級分區(qū)的選擇反而會多一些，首先大家可以選擇是否建立二級分區(qū)，其次大家可以選擇二級分區(qū)的建立方式。二級分區(qū)比較適合于在where語句中經(jīng)常使用到的字段，而且這個字段應(yīng)該是可枚舉的，比如“男”和“女”這樣的。這里還有一個前提，就是如果這個字段的值的分布是非常不均勻的，那么就不太建議做二級分區(qū)。

如下圖中的例子所示，登錄表每天會有9個億的數(shù)據(jù)，而其中的一個字段是“是否登錄成功”，成功可能有4億，失敗可能有5億，這就比較適合做二級分區(qū)，因為比較均衡。第二個例子是用戶訪問表，每天新增20億數(shù)據(jù)，其中一個字段是“頁面訪問狀態(tài)”，成功訪問“202”是18億，而失敗“203”只有0.5億，其他就更少了，這樣的字段就不適合做二級分區(qū)。在數(shù)量級不大的情況下，不建議做二級分區(qū)，因為幾百萬的數(shù)據(jù)在MaxCompute里面掃描起來也會很快，在數(shù)據(jù)量大了之后可以再考慮二級分區(qū)，因為MaxCompute本身對于分區(qū)有一個上限就是6萬，也就是一級分區(qū)乘以二級分區(qū)的個數(shù)不能超過6萬個。

三、同步任務(wù)優(yōu)化
同步任務(wù)優(yōu)化可以從下圖所示的這樣幾個點進行考慮。正如下面的這張PPT中圖所示。數(shù)據(jù)同步其實就是源庫通過網(wǎng)絡(luò)進入到DataWorks或者自定義的調(diào)度資源里，再從DataWorks里面同步到MaxCompute里面，或者反過來從MaxCompute同步到源庫，但是無論怎么說同步就是分為這樣的幾個點：源庫、網(wǎng)絡(luò)1、DataWorks調(diào)度資源、網(wǎng)絡(luò)2以及MaxCompute，出現(xiàn)瓶頸的地方也就在這幾部分中，如果同步任務(wù)運行緩慢，那么瓶頸點就只能出現(xiàn)在這幾個點中。最常見的情況就是從其他數(shù)據(jù)庫向MaxCompute抽取數(shù)據(jù)，一般情況下的瓶頸點就在源庫這部分，出現(xiàn)問題大家可以優(yōu)先在源庫處尋找。在網(wǎng)絡(luò)層面，從DataWorks到MaxCompute之間的網(wǎng)絡(luò)2大家一般不用關(guān)心，因為這部分是由阿里云負責的，但是從源庫到DataWorks調(diào)度的網(wǎng)絡(luò)1這一段需要由用戶自己保證，公網(wǎng)、內(nèi)網(wǎng)和專線，不同的網(wǎng)絡(luò)環(huán)境中同步的速度也是不一樣的。

再回到同步優(yōu)化的幾個關(guān)鍵點，首先核心同步任務(wù)需要定時優(yōu)先考慮，如果表的數(shù)據(jù)量比較大或者業(yè)務(wù)的優(yōu)先級比較高，那么這些絕對需要提前考慮，因為如果這樣的任務(wù)不提前，那么排在其后面的任務(wù)就會受到影響。第二點就是網(wǎng)路對于同步性能的影響，公網(wǎng)、內(nèi)網(wǎng)或者專線對于性能也會有一定的影響。第三點就是DataWorks調(diào)度資源對于同步任務(wù)的影響，大家在DataWorks里面進行同步都是使用默認的調(diào)度資源，如果同步任務(wù)設(shè)置的并發(fā)過高，就會導致某一個任務(wù)會影響其他任務(wù)，比如處理一百萬數(shù)據(jù)啟動了20個并發(fā)，顯然這是沒有必要的，但是這樣就占掉了全部的同步任務(wù)，導致后續(xù)運行SQL以及其他的同步任務(wù)都跑不起來了，這是因為DataWorks的調(diào)度資源不夠了。所以數(shù)據(jù)同步的并發(fā)絕對不是越多越好的，當處理一兩百萬數(shù)據(jù)的時候，僅需要2到3個并發(fā)就足夠了。此外，還有就是如何判斷源庫和目標庫哪個是瓶頸點。數(shù)據(jù)同步主要使用的是數(shù)據(jù)集成，當離線任務(wù)運行完成之后都會產(chǎn)生這樣的一個日志，在日志的最后會顯示開始時間、結(jié)束時間以及寫入速度等。在圖中有標紅的兩個點，分別是Task WaitWriterTime和Task WaitReaderTime。如果是從RDS往MaxCompute同步，那么Reader指的就是讀取RDS等待的時間，那Writer指的就是寫入MaxCompute的等待的時間，哪一邊的時間更長就意味著哪一邊存在瓶頸點，如果讀的方面時間更長，那么就需要從RDS或者網(wǎng)絡(luò)1入手，也就是通過兩方面的時間來判斷瓶頸點究竟在哪一部分。

計算任務(wù)優(yōu)化
在計算任務(wù)優(yōu)化部分部分，也只與大家分享在SQL部分開發(fā)者應(yīng)該如何進行優(yōu)化。大家平時在進行數(shù)據(jù)處理、數(shù)據(jù)清洗、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)加工等過程中都會使用到SQL。對于SQL的優(yōu)化而言，主要集中在這樣的兩個大方面進行：減少數(shù)據(jù)輸入和避免數(shù)據(jù)傾斜。減少數(shù)據(jù)輸入是最核心的一點，如果數(shù)據(jù)輸入量太大，包括很多無效的數(shù)據(jù)，那么就會占用很多的計算資源。而數(shù)據(jù)傾斜是在離線的數(shù)倉里面經(jīng)常會遇到的，幾乎每個人都會遇到，數(shù)據(jù)傾斜也分為好幾種，需要對應(yīng)地進行優(yōu)化。接下來就為大家展開進行論述。

在正式展開之前還需要講解一下LogView的用法，因為想要判斷問題究竟是因為什么導致都需要從分析LogView入手。每一個SQL執(zhí)行的時候都會產(chǎn)生一個LogView，如下圖中的網(wǎng)址所示，大家可以直接在瀏覽器打開，之后就能打開匯總的頁面，再打開Detail就能看到如下圖所示的明細頁面。對于明細頁面而言，首先需要關(guān)注左側(cè)的執(zhí)行計劃，也就是分為了多少個Map、Reduce以及Join節(jié)點。其次需要關(guān)注TimeLine可以看到哪一個Map運行的時間長，這是尋找數(shù)據(jù)傾斜的依據(jù)。當點擊每一個Map就能看到下面的明細，比如某一個Map有10個節(jié)點在跑，那么就會有10個點。對于明細而言，重點需要關(guān)注的也是TimeLine，需要關(guān)注在分成10個的節(jié)點里面，究竟哪一個跑得快，哪一個跑得慢。下圖中就存在明顯的傾斜，也就是0號節(jié)點跑得很慢，而其他的節(jié)點跑得就比較快，這樣就是一個非常明顯Map階段的傾斜。而使用Long-Task則可以快速定位到跑得慢的節(jié)點，幫助進行快速定位。

當然目前也有了比較好用的工具——MaxCompute Studio，其對于LogView的支持更加強大。在這里面可以直接將剛才的網(wǎng)址粘貼過來，也可以直接連接MaxCompute的項目找到Instance，然后直接點擊Instance查看其執(zhí)行日志，甚至可以將LogView保存在本地或者在本地打開，而網(wǎng)頁版本過期之后就無法打開了。MaxCompute Studio最好用的地方在于其時序圖功能，時序圖能夠列出某一個時間段，哪一個節(jié)點跑得快，哪一個節(jié)點跑得慢，做一個整體地列舉出來，更加方便地定位到Map、Reduce以及里面小的節(jié)點。還有一個分析功能，能夠直接為用戶提供結(jié)果，提示用戶哪一個節(jié)點跑得慢，哪里出現(xiàn)長尾等問題。

分區(qū)的合理使用
前面講述了分區(qū)應(yīng)該如何設(shè)計，這里著重講解分區(qū)應(yīng)該如何使用。如果表存在一級分區(qū)，那么將分區(qū)的篩選放到了條件里面就是一種錯誤的寫法，有可能導致全表掃描。最好的寫法就是像下圖右側(cè)所示的一樣，把Table1的PT先進行篩選做一個子查詢，再把Table2的也做一個分區(qū)先篩選了作為t2，之后將它們兩個Join在一起再加上一個where條件，這樣就能避免全表掃描。對于PT而言，如果使用了系統(tǒng)自帶的函數(shù)，應(yīng)該會做分區(qū)裁剪，而如果使用了自定義的函數(shù)對于PT進行加工，并放到了where條件里就有可能導致全表掃描，而現(xiàn)在DataWorks里面也會有系統(tǒng)提示，也便于大家進行判斷。

多路輸入
在MaxCompute里面支持多路輸入，可以讀取一個表的數(shù)據(jù)并將其同時寫入到兩個地方，這樣就保證了只做了一次查詢，而可以直接生成兩個結(jié)果表。下圖是一個電商的例子，大概就是在銷售訂單表里面有賣家和買家，分別統(tǒng)計了賣家和買家的數(shù)量分別是多少，以前可能需要拆分成兩個SQL，而現(xiàn)在可以用一個SQL同時統(tǒng)計兩者的數(shù)量，只需要讀取一次原表就可以了，既能夠節(jié)省時間，也能夠節(jié)省成本。

慎用SELECT*
因為MaxCompute里面是列式存儲，所以同一列的數(shù)據(jù)都是存儲在一起的，甚至于因為列內(nèi)容相似都會有一些壓縮算法在里面。而SELECT*查詢?nèi)信c直接查詢兩個字段的性能差距是非常大的，所以作為數(shù)據(jù)開發(fā)的規(guī)范，無論數(shù)據(jù)量大小都一定不要使用SELECT*就好了。

先過濾JOIN，REDUCE，UDF
還有一個減少數(shù)據(jù)量的辦法就是在使用Join、Reduce或者UDF的時候，先做過濾在做具體的計算或者Join。

合表
合表也是減少數(shù)據(jù)輸入的一種方式，它其實是從業(yè)務(wù)的角度切入考慮的。比如有一個業(yè)務(wù)分別用到了T1和T2的兩列，另外一個業(yè)務(wù)分別用到了T1和T3的兩列，而這兩個業(yè)務(wù)其實是可以合并到一起的，但是卻放到了兩個表，而這樣就可以將這兩個表合并到一起，這樣只做一次計算就完成了。

Map傾斜
在LogView里面有一個Map的時序，可以看到每個Map里面有多少個Instance，里面的哪一個耗時比較長就是發(fā)生了數(shù)據(jù)傾斜。同樣的，在LogView里面也能找到Map的平均執(zhí)行時間以及最大執(zhí)行時間，如果兩者相差很大，那么必然出現(xiàn)了傾斜。對于這樣的問題，從業(yè)務(wù)層面進行解決一般是修改上游數(shù)據(jù)，讓上游按照均衡的KV值進行重新分布。如果業(yè)務(wù)層面無法規(guī)避，那么可以調(diào)整Map的個數(shù)，也就是加大Map的計算節(jié)點，在默認情況下是每256M數(shù)據(jù)切一個節(jié)點，可以將其調(diào)小，也就加大了Map處理節(jié)點的個數(shù)，使得數(shù)據(jù)分割得更加均勻一些。

Join傾斜
Join階段的傾斜也是比較常見的，這一現(xiàn)象的發(fā)現(xiàn)與Map傾斜基本相同，也是可以通過LogView判斷。但是其解決方案卻需要分為幾種情況進行處理：
-情況1：如果為大表與小表（加載到內(nèi)存不超過512M)，則對小表加MAPJOIN HINT
-情況2：兩個大表Join，KEY值出現(xiàn)數(shù)據(jù)傾斜，傾斜值為NULL，則需對NULL進行隨時值處理
-情況3：兩個大表Join，可以盡量先去重后再Join?? ?
-情況4：兩個大表Join，業(yè)務(wù)層面考慮優(yōu)化，檢查業(yè)務(wù)的必要性

下圖展現(xiàn)的是Join傾斜的幾個具體例子，可以分析具體造成傾斜的情況做出相應(yīng)的處理。

Reduce傾斜
Reduce傾斜現(xiàn)象的查看方式和前面的Map以及Join查看的方式相同，可以從TimeLine看到。可能的情況主要有以下四種：
-情況1：GROUP BY 某個KEY傾斜嚴重（1. 是否可以過濾 2. 寫法改變，見圖）
-情況2：DISTINCT引起的傾斜（打標+GROUPBY)?? ?
-情況3：動態(tài)分區(qū)引起的傾斜，盡量避免使用動態(tài)分區(qū)
-情況4：窗口函數(shù)引起的傾斜，盡量避免使用窗口函數(shù)，要視具體情況而定

Reduce傾斜-DISTINCT
如果是因為DISTINCT造成的數(shù)據(jù)傾斜，有一種解決方法就是打標+GROUPBY，比如在下圖的例子中就是對于求IP段，求美國IP段、中國IP段以及總的IP段一共有多少個，左邊這種圖簡單的寫法，當出現(xiàn)IP Key的傾斜就會使得作業(yè)比較慢，那么就可以將其打散，先求解這條ID的記錄是美國的還是中國的，在子查詢里先做這一步，在外面再去求解總的Count或者Sum，從原本Map-Reduce兩個階段的處理改成了Map-Reduce-Reduce三個階段處理，這種方案也能解決數(shù)據(jù)傾斜問題。

總結(jié)一下，性能調(diào)優(yōu)歸根結(jié)底還是資源不夠了或者資源使用的不合理，或者是因為任務(wù)分配的不好，使得某些資源分配和利用不合理。大家需要根據(jù)本文的內(nèi)容考慮如何將自己的任務(wù)打散，保證任務(wù)在規(guī)定的時間內(nèi)能夠執(zhí)行完畢，同時能夠保證成本的節(jié)約。當然了，大家不僅需要考慮MaxCompute的計算資源，也需要考慮DataWorks的調(diào)度資源，所以性能優(yōu)化最終還是在和資源作斗爭，看資源是否足夠，分配是否合理。

原文鏈接?

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?