大家好，很高興有機(jī)會(huì)分享一些大數(shù)據(jù)方面的思考。當(dāng)集群到達(dá)一定的規(guī)模以后，不可避免會(huì)碰到一些管理上的痛點(diǎn)，今天我就唯品會(huì)在面對這些痛點(diǎn)的一些解決方法和思路，與大家交流討論。
單超，現(xiàn)任唯品會(huì)大數(shù)據(jù)平臺高級架構(gòu)師
本次演講主要分為四個(gè)部分：
1、唯品會(huì)大數(shù)據(jù)平臺規(guī)劃和現(xiàn)狀
2、大數(shù)據(jù)中的資源管理
3、存儲(chǔ)資源管理和計(jì)算資源管理
4、案例分享
一、唯品會(huì)大數(shù)據(jù)平臺規(guī)劃和現(xiàn)狀
這是唯品會(huì)大數(shù)據(jù)平臺一個(gè)中長期的規(guī)劃。目標(biāo)很明確，我們希望從技術(shù)上能把整個(gè)大數(shù)據(jù)做成一個(gè)包含離線計(jì)算平臺、流式計(jì)算平臺、模型訓(xùn)練平臺、VRE、 DMP和多種應(yīng)用的完整生態(tài)鏈，并且希望通過這個(gè)平臺，讓我們公司的分析師、開發(fā)人員可以很簡易地運(yùn)用起來。
這是唯品會(huì)大數(shù)據(jù)平臺的現(xiàn)狀，總體和上面的規(guī)劃圖類似，重點(diǎn)在于離線平臺的搭建，目前離線計(jì)算平臺也已經(jīng)做得差不多了。我們現(xiàn)在有一套很完整的數(shù)據(jù)開發(fā)平臺，可以讓公司的分析人員在不需要任何培訓(xùn)的情況下，方便地利用這個(gè)系統(tǒng)去挖掘大數(shù)據(jù)中的各種知識，為業(yè)務(wù)服務(wù)。除此之外，我們也有很多產(chǎn)品，看到圖中數(shù)據(jù)產(chǎn)品一塊，有情報(bào)中心、比價(jià)、選品、數(shù)讀、魔方羅盤、儀表盤等。
二、大數(shù)據(jù)中的資源管理
大數(shù)據(jù)管理本身是一個(gè)很廣的概念，涵蓋了很多知識面。但資源管理是今年讓唯品會(huì)特別難受的一個(gè)點(diǎn)，很多工作人員經(jīng)過長時(shí)間的不眠不休，才最終把它解決掉。所以今天我會(huì)把資源管理作為重點(diǎn)，單獨(dú)拿出來分享。
這里的“數(shù)據(jù)平臺使用申請”打了引號，我想說的是這個(gè)“平臺使用申請”在初創(chuàng)公司或者建設(shè)數(shù)據(jù)平臺的初期，一般是很難做到這么完善的。因?yàn)槲覀冃枰脩籼峤缓芏嘁�，而且這些要求是明確的，包含了比如我需要什么樣的資源，HDFS的存儲(chǔ)、數(shù)據(jù)庫、計(jì)算都需要多少，資源的數(shù)目是多少，要通過什么方式去訪問。拿到這個(gè)申請以后，管理員會(huì)負(fù)責(zé)去分配同樣的資源，比如HDFS中分配多少資源給你使用，Hive也是，如果我想要這樣一個(gè)資源分配隊(duì)列，需要明確分配給你的最大/最小資源是多少。
當(dāng)然，這是一個(gè)理想的情況，現(xiàn)實(shí)卻很骨感。因?yàn)檫@個(gè)行業(yè)的發(fā)展非常快，相信很多做大數(shù)據(jù)的同學(xué)，很多時(shí)候你是被業(yè)務(wù)和領(lǐng)導(dǎo)推著向上的，所以這時(shí)你的思考可能不是很完善，你會(huì)發(fā)現(xiàn)，你的理想狀態(tài)是系統(tǒng)很強(qiáng)大、數(shù)據(jù)規(guī)范、流程規(guī)范、技術(shù)成熟、業(yè)務(wù)成熟，但現(xiàn)實(shí)呢？唯品會(huì)在半年前也是這種現(xiàn)狀：模型的變更非常迅速，線上的那些代碼實(shí)際上是我們的人員按小時(shí)為單位去做變更的。用戶的能力參差不齊。有很多的歷史包袱，唯品會(huì)的數(shù)據(jù)平臺其實(shí)四年前就開始搭建了，其中有三年的歷史包袱。同時(shí)，有大量的技術(shù)包袱，而且平臺非常不穩(wěn)定，掌控力差，有各種各樣的瓶頸。整個(gè)大數(shù)據(jù)平臺的分層也不是很明確。這是我們面臨的現(xiàn)實(shí)。
那么，這種情況下，維護(hù)人員或者像我們這樣的技術(shù)架構(gòu)人員就會(huì)經(jīng)常接到用戶各種各樣的投訴和問題。這里我列了一些用戶經(jīng)常會(huì)抱怨的問題：
•這個(gè)任務(wù)昨天還好好的，為什么今天跑不出來了？
•2-10倍的數(shù)據(jù)量，能撐得住嗎？
•怎么幾千個(gè)任務(wù)都慢了？
•最近磁盤使用率急劇增加，誰在用？
•這個(gè)表好像不用了，我能刪除掉嗎？
•集群要擴(kuò)容嗎？擴(kuò)多少？
當(dāng)你在沒有足夠能力應(yīng)付的情況下，面對這些問題，你是一籌莫展的。而由此也引申出今天的核心議題——資源管控。
三、資源管控中的存儲(chǔ)資源和計(jì)算資源
做運(yùn)維、DBA，或者大數(shù)據(jù)管理人員，都需要了解一個(gè)核心，那就是資源管控。做資源管控，其實(shí)和分田到戶是同樣的道理。當(dāng)把一塊田交給你，那你就在這塊田里自己玩，不要到別人的田里去摻和。通過資源管控，可以實(shí)現(xiàn)很多目的：
•從亂序到有序。
•申請和分配有據(jù)可查。
•規(guī)則公開透明。
•數(shù)據(jù)公開透明。
•有多少資源，干多少事。
•有合理的KPI和懲罰機(jī)制。
•ROI，資源傾斜給回報(bào)率高的項(xiàng)目。
以Hadoop為例。Hadoop平臺是大家都在用的一個(gè)技術(shù)框架，它有哪些資源呢？總的來說，有四個(gè)模塊：計(jì)算資源、存儲(chǔ)資源、權(quán)限資源、業(yè)務(wù)資源。今天我會(huì)重點(diǎn)講右側(cè)的計(jì)算資源和存儲(chǔ)資源。
為什么存儲(chǔ)和計(jì)算需要關(guān)注？
首先是NameNode。NameNode在Hadoop中相當(dāng)于一個(gè)技術(shù)的管理節(jié)點(diǎn)，我們平臺目前已經(jīng)存儲(chǔ)2億的文件超過2億的blocks，現(xiàn)在NameNode的內(nèi)存使用在100G左右。在這么大的一個(gè)集群規(guī)模情況下，會(huì)遇到很多問題。
•standby namenode updateCountForQuota緩慢影響主從一致性，進(jìn)而影響切換（HDFS-6763）
•standby checkpoint緩慢導(dǎo)致增量blockreport匯報(bào)被skip， 影響主從一致性，進(jìn)而影響切換（HDFS-7097）
•standby checkpoint GC導(dǎo)致transfer Fsimage超時(shí)失敗
這里列了幾個(gè)問題點(diǎn)，都在社區(qū)被不少人提出來，我們也確實(shí)受到了影響。
其中，最重要的是集群啟動(dòng)時(shí)，規(guī)模越大，你的啟動(dòng)時(shí)間可能越慢，除非你把這部分的代碼全部進(jìn)行重構(gòu)。舉個(gè)例子，可能我們的集群重啟需要30分鐘，因?yàn)樾枰總�(gè)block去上報(bào)。
另外，第二個(gè)瓶頸就是資源管理，叫做ResourceManager，這也是Hadoop中的一個(gè)技術(shù)組件。唯品會(huì)現(xiàn)在的規(guī)模并行度是高峰期可以有一千個(gè)任務(wù)在跑，每天有將近40萬的任務(wù)提交到Hadoop集群里，基本24小時(shí)內(nèi)時(shí)時(shí)刻刻都有人在運(yùn)行。因?yàn)楝F(xiàn)在的電商，包括現(xiàn)在的大數(shù)據(jù)已經(jīng)不是以前那種玩法，不是你晚上跑個(gè)批處理，事情就做完了。現(xiàn)在大家的要求是，你能不能5分鐘內(nèi)跑出來，所以我的批處理在上面可能是5分鐘一個(gè)力度去提交的，所以這個(gè)集群對我們來說已經(jīng)不是夜間作業(yè)的集群，而是24小時(shí)專機(jī)，永遠(yuǎn)不能宕機(jī)的一個(gè)服務(wù)。
•https：//issues.apache.org/jira/browse/YARN-3547部分解決問題
•https：//issues.apache.org/jira/browse/YARN-518 our patch for fairscheduler
這里也列了兩個(gè)問題，就不展開講了，關(guān)鍵是第二個(gè)，我們提交給社區(qū)的補(bǔ)丁。這些問題社區(qū)還沒有解決，我們這個(gè)補(bǔ)丁也還沒有打到任何社區(qū)的版本里去，但是如果當(dāng)你的集群規(guī)模非常大，運(yùn)行HDFS時(shí)肯定會(huì)遇到和我們同樣的問題——分配能力有瓶頸。目前我們通過這個(gè)補(bǔ)丁，分配能力提升到了近10-15倍。這其實(shí)很夸張，我們一直考慮的是，現(xiàn)在已經(jīng)有幾百臺節(jié)點(diǎn)了，那能不能變到幾千臺？如果分配這個(gè)問題不解決，你的瓶頸永遠(yuǎn)卡在那，即使再加機(jī)器，管理也會(huì)因?yàn)槠款i上不去，無法提升到幾千臺這樣的規(guī)模。
前面講到了很多問題，怎么解決呢？開源節(jié)流。分兩塊，一塊要提升各方面主機(jī)的性能，圖中列出來的，包括了NameNode RPC性能、yarn的container assign性能，以及加機(jī)器。另外一塊，就是要做各種優(yōu)化管理。大家想，原先你就有幾百個(gè)用戶在用，當(dāng)開放出去后，隨著大數(shù)據(jù)應(yīng)用的發(fā)展，不斷有人去用，久而久之就會(huì)變成上萬個(gè)用戶在用。這時(shí)，你的存儲(chǔ)是否被有效地利用呢？是否都是有價(jià)值的數(shù)據(jù)放在上面呢？你的計(jì)算是否都是有效的計(jì)算呢？還有人在用這樣的一個(gè)任務(wù)嗎？
管理數(shù)據(jù)化成果
給大家看一下我們在這一塊的成果。理念很簡單，就是做一個(gè)閉環(huán)。把整個(gè)數(shù)據(jù)倉庫和Hadoop做成一個(gè)閉環(huán)，大家可以看到內(nèi)圈，其實(shí)就是正常開發(fā)的一個(gè)數(shù)據(jù)倉庫，你會(huì)建立任務(wù)、執(zhí)行、下線，這是一個(gè)循環(huán)。而外循環(huán)是從整個(gè)任務(wù)建立時(shí)就開始對它進(jìn)行管理，當(dāng)你任務(wù)申請好之后，你會(huì)分配到一個(gè)隊(duì)列，查看你的每一個(gè)日志。存儲(chǔ)和計(jì)算會(huì)告訴你用了多少，同時(shí)還可以做一些智能的分析。在你的任務(wù)執(zhí)行完之后，可以在系統(tǒng)里面看到任務(wù)的整個(gè)生命周期運(yùn)行情況。
基本上我們就是把整個(gè)大數(shù)據(jù)分到項(xiàng)目，分到人，分到數(shù)據(jù)庫，分到幾個(gè)任務(wù)，所有的指標(biāo)都可以可視化地讓你看到，也就是說，即使你只是簡單地在系統(tǒng)里提交了一個(gè)SQL，可實(shí)際上你得到的是一個(gè)可視化、數(shù)據(jù)化的成果。你可以知道，今天我提交了多少個(gè)SQL，占用了多少資源，剩下多少文件，所有這些東西在系統(tǒng)里都可以看到。
這樣數(shù)據(jù)分析師也能主動(dòng)跟你講，今天慢了可能是因?yàn)樘峤坏娜蝿?wù)太多，今天提交的任務(wù)比上周多了一倍。你也能主動(dòng)地在系統(tǒng)里找，為什么多了一倍？什么樣的任務(wù)最占用資源？整個(gè)架構(gòu)閉環(huán)大大降低基本架構(gòu)技術(shù)人員的工作量。而當(dāng)我們所有的數(shù)據(jù)都開放給數(shù)據(jù)分析師時(shí)，他們又能通過這些數(shù)據(jù)去做一些自己的分析，這也是一個(gè)閉環(huán)的形成。對很多公司來說，通過構(gòu)建閉環(huán)，這一塊的工作效率將會(huì)得到很大的提升。
接下來重點(diǎn)講兩塊資源的管理。一塊是存儲(chǔ)的資源，一塊是計(jì)算的資源。
存儲(chǔ)資源管理
一般情況下，大家在Hadoop中都是用Hive這個(gè)數(shù)據(jù)庫，它對應(yīng)的是后端的一些一二三級目錄等數(shù)據(jù)庫和表的目錄。我們要怎樣獲取這些數(shù)據(jù)呢？從我們的角度來說，我們也是數(shù)據(jù)分析人員，我們要做的東西和其他的分析師其實(shí)是一樣的，只不過我們分析的對象是系統(tǒng)的性能數(shù)據(jù)。我們會(huì)想要獲取各種各樣的性能數(shù)據(jù)，同時(shí)，我們需要去計(jì)算這些性能數(shù)據(jù)，做多維度的各種計(jì)算，然后把它推出去給用戶看。
存儲(chǔ)資源基本上就是通過這幾大塊來收集，左邊是獲取到的各種存儲(chǔ)的信息，文件、表、數(shù)據(jù)倉庫、ETL、Hadoop的日志……第二步是把它轉(zhuǎn)化為Hive里計(jì)算的文件元數(shù)據(jù)信息、表元數(shù)據(jù)信息、調(diào)度任務(wù)元數(shù)據(jù)信息、路徑訪問信息，最后得到的產(chǎn)出通過各種維度的計(jì)算，可以得到：
1.維度：包括分區(qū)、表、數(shù)據(jù)庫、任務(wù)、業(yè)務(wù)、人、目錄層級、時(shí)間等所有維度；
2.指標(biāo)：全量、增量、趨勢、平均文件大小、最大文件大小、最小文件大小、文件數(shù)目、占比等；
3.熱度：哪些表被頻繁訪問？哪些表3個(gè)月沒人訪問，是否可以下線了？
4.安全：有沒有敏感信息被非法訪問。
通過這一系列的存儲(chǔ)資源管理，可以把所有的關(guān)鍵信息收集起來。下面，講一下這些數(shù)據(jù)的使用，這也是我們公司目前正在踐行的：
•容量計(jì)費(fèi)
通過計(jì)費(fèi)來控制資源，使存儲(chǔ)數(shù)據(jù)完整透明。消費(fèi)預(yù)警，會(huì)提前知會(huì)用戶。
•空間管理
自動(dòng)配置生命周期管理規(guī)則；存儲(chǔ)格式，壓縮格式選擇（orc+gzip）；
•文件管理
自動(dòng)配置生命周期管理規(guī)則；小文件har歸檔。
控制存儲(chǔ)的價(jià)值：一方面可以解決NN“單點(diǎn)”瓶頸，控制服務(wù)器的數(shù)量，降低成本。如果沒有加以控制，很快你的規(guī)模就會(huì)變成幾百、幾千，逐漸失控。另一方面，規(guī)范數(shù)據(jù)生命周期管理，統(tǒng)計(jì)冷熱數(shù)據(jù)的使用，區(qū)別哪些數(shù)據(jù)是能刪的、哪些是能歸檔的、哪些是被頻繁使用的，都可以通過這個(gè)手段反饋給ETL生命周期管理。
計(jì)算資源管理
這是yarn的一個(gè)架構(gòu)圖。大家都知道yarn是Hadoop的一個(gè)統(tǒng)一的調(diào)度管理。但yarn好像把所有資源管理的事情都搞定了，我們還需要管理什么呢？實(shí)際上，還有很多沒有解決的問題。
問題比較多，這里挑兩個(gè)出來詳細(xì)說說。
先講一個(gè)維護(hù)人員比較關(guān)心的問題。當(dāng)維護(hù)大量的機(jī)器時(shí)，判斷這些機(jī)器本身是不是在正常運(yùn)行其實(shí)很難。因?yàn)橐粋�(gè)機(jī)器是不是fail其實(shí)很難去權(quán)衡，可能是硬盤有問題，或者網(wǎng)絡(luò)、CPU有問題，但最終表現(xiàn)出來的都是對Hadoop集群有影響。Hadoop對機(jī)器硬件的要求其實(shí)并不高，那我們可以通過什么數(shù)據(jù)來告訴你Hadoop集群是有問題呢？很簡單，所有上面跑過的任務(wù)都統(tǒng)計(jì)過了，我們就可以知道，跑了100個(gè)任務(wù)，失敗了多少個(gè)。如果你定下指標(biāo)，跑了100個(gè)，結(jié)果失敗的超過了20個(gè)，這明顯是不合理的，肯定需要去管理，所以這是從數(shù)據(jù)角度去反饋給運(yùn)維人員，就是我告訴你這個(gè)系統(tǒng)是有問題的，你反回去查。
再講一下數(shù)據(jù)傾斜。怎么知道一個(gè)任務(wù)是不是數(shù)據(jù)傾斜？一種是靠數(shù)據(jù)分析師人為的經(jīng)驗(yàn)，另一種從技術(shù)角度，當(dāng)你跑MapReduce的時(shí)候，你的MapReduce可能是100個(gè)，前面99個(gè)在一分鐘內(nèi)跑完，有1個(gè)跑了一個(gè)小時(shí)，這時(shí)肯定是出現(xiàn)傾斜了。解決這個(gè)問題也很簡單，就是把數(shù)據(jù)開放給用戶，通過智能的分析告訴用戶任務(wù)傾斜了，至于為什么會(huì)傾斜，讓用戶自己通過數(shù)據(jù)去反查。
現(xiàn)在我們的大數(shù)據(jù)平臺上每天有幾十萬的任務(wù)在跑，數(shù)據(jù)量也不小，每個(gè)任務(wù)都分到MapReduce里，加起來有千萬級別的數(shù)據(jù)。所以為了拿到剛才講的各種數(shù)據(jù)，就需要考慮數(shù)據(jù)的收集問題。目前我們有很多不同時(shí)間力度的收集方案，會(huì)每分鐘去拿，實(shí)時(shí)去拿，也會(huì)在每個(gè)任務(wù)提交后自己主動(dòng)去上報(bào)，每個(gè)ETL任務(wù)完成后也會(huì)上報(bào)。
這一部分資源怎么用呢？跟存儲(chǔ)資源類似：
•容量計(jì)費(fèi)
1）通過計(jì)費(fèi)來控制資源
2）存儲(chǔ)數(shù)據(jù)完整透明
3）消費(fèi)預(yù)警，提前知會(huì)用戶
•實(shí)時(shí)告警和自動(dòng)處理
1）根據(jù)隊(duì)列設(shè)置不同的規(guī)則，如運(yùn)行時(shí)長、使用資源、自動(dòng)發(fā)現(xiàn)和觸發(fā)停止動(dòng)作
2）通過業(yè)務(wù)注碼，自動(dòng)展示運(yùn)行中的業(yè)務(wù)細(xì)節(jié)
•數(shù)據(jù)傾斜自動(dòng)識別
•隊(duì)列數(shù)據(jù)化運(yùn)營
關(guān)于公平調(diào)度，我們有自己的一套管理原則：
1.盡量細(xì)化，單個(gè)業(yè)務(wù)分配單獨(dú)隊(duì)列。
細(xì)化和大鍋飯的區(qū)別就是兩個(gè)人吃一碗飯和每人分一小碗的區(qū)別。這樣就可以很清楚地知道你吃了多少，你是不是還餓著，另一個(gè)人可能是浪費(fèi)的。我們的管理理念基本上就是盡可能去細(xì)化，來一個(gè)新的項(xiàng)目我給你分一個(gè)新的獨(dú)立資源。
2.隊(duì)列分配的min/max/weight由實(shí)際業(yè)務(wù)來評估，上線初期會(huì)不斷調(diào)整、觀察。
3.min是保證的最小資源，確保優(yōu)先獲得。
4.max是業(yè)務(wù)的最大資源限制，確保不會(huì)超過。
5.每個(gè)隊(duì)列由多個(gè)不同級別的子隊(duì)列組成，子隊(duì)列業(yè)務(wù)可靈活調(diào)整。
6.子隊(duì)列大小可以基于時(shí)間動(dòng)態(tài)調(diào)整：
1）白天，天任務(wù)隊(duì)列縮小，小時(shí)任務(wù)隊(duì)列放大；
2）夜晚，天任務(wù)隊(duì)列放大，小時(shí)任務(wù)隊(duì)列縮��；
3）關(guān)鍵任務(wù)確保隊(duì)列內(nèi)的最小隊(duì)列保證。
四、案例分享
接下來講一些實(shí)操的例子。
Yarn實(shí)時(shí)運(yùn)行情況監(jiān)控
這張圖，用過Hadoop的同學(xué)會(huì)比較熟悉，這是Hadoop官方提供的關(guān)于yarn實(shí)時(shí)運(yùn)行監(jiān)控情況。從圖中可以看到你的集群到底跑了多久，和你的集群使用率。這個(gè)數(shù)據(jù)是完全實(shí)時(shí)的，也就是過時(shí)不候，沒有歷史時(shí)序數(shù)據(jù)，展現(xiàn)不夠直觀。那我們要如何去獲取這樣的表格數(shù)據(jù)呢？
一個(gè)方法就是通過Hadoop的jobhistory，獲取每個(gè)application的明細(xì)執(zhí)行結(jié)果。缺點(diǎn)是只有在任務(wù)完成后才能獲取到完整信息。另一個(gè)方法是job api。通過api實(shí)時(shí)獲取到所有job的基礎(chǔ)信息，比默認(rèn)rm的api提供更多字段信息，如SQL信息，但也有缺點(diǎn)，它獲取的不是100%完整的數(shù)據(jù)，定期獲取必然會(huì)丟失數(shù)據(jù)。
秒級計(jì)算資源管理
剛才提到的秒級計(jì)算資源管理， 就是通過把實(shí)時(shí)數(shù)據(jù)計(jì)算的過程監(jiān)控移植到產(chǎn)品中，那么在這個(gè)產(chǎn)品中我們就可以看到一共有多少資源、你用了多少、什么樣的查詢、什么時(shí)候提交、進(jìn)展怎樣、是否需要reduce，這些都可以在界面看到。同時(shí)，我們還可以根據(jù)實(shí)時(shí)拿到的數(shù)據(jù)，檢查有些任務(wù)是否跑了過長時(shí)間，有些資源使用是否超過預(yù)值了，可以把它kill掉。
分鐘級計(jì)算資源管理
分鐘級的話，我們可以每分鐘獲取Hadoop內(nèi)部jmx的信息。這里列了一些信息：
這些信息拿出來之后會(huì)做成下面這種實(shí)時(shí)監(jiān)控的圖，交給運(yùn)維人員去使用。
如果隊(duì)列分配紅線跑平，而隊(duì)列等待藍(lán)線升高，就可以得出單個(gè)業(yè)務(wù)資源吃緊，需要增加最大可分配資源。
這是另一個(gè)Bug，也是剛才我們提到的yarn分配能力出問題了。藍(lán)色是等待的線，當(dāng)?shù)却臄?shù)據(jù)在急劇增加時(shí)，綠色的線反而在下降，這是因?yàn)槌霈F(xiàn)資源分配不均，資源使用率越來越低。我們看到，整個(gè)集群在高峰期等待非常多，但集群使用率低于50%，這是很不正常的現(xiàn)象，說明你的集群根本沒有得到合理的釋放。
再簡單講一下前面這些資源管控的優(yōu)化展現(xiàn)。一方面是隊(duì)列的展現(xiàn)，目前我們可以看到任意時(shí)刻任何隊(duì)列的使用情況，看到集群總體資源分布的情況，同時(shí)也可以查看最消耗資源的是什么任務(wù)，以及實(shí)時(shí)/歷史的數(shù)據(jù)查看。
天級計(jì)算資源管理
離線資源天級的場景，我們也會(huì)做一些匯總。比如：
•查詢集群的資源使用場景
•時(shí)間/應(yīng)用/隊(duì)列維度的資源使用情況
•核心ETL任務(wù)近期map/reduce使用情況
•單個(gè)attempt的metrics指標(biāo)查看，如讀取超過1kw行數(shù)據(jù)的map任務(wù)
對于數(shù)據(jù)傾斜的識別，就是通過數(shù)據(jù)來分析，看所有的計(jì)算中數(shù)據(jù)量是不是一致的，會(huì)不會(huì)有1到2個(gè)計(jì)算的數(shù)據(jù)量是異常的，可以通過這種方法分析出來。這里列了一個(gè)從數(shù)據(jù)到日志、到系統(tǒng)的數(shù)據(jù)表。
下面是一些優(yōu)化的例子。
•用更少的資源計(jì)算
1）orcfile，壓縮率更高，列式存儲(chǔ)降低資源消耗
2）權(quán)衡資源和性能，基于record而不是size調(diào)整reduce數(shù)量
3）基于hll的uv估算函數(shù)，提供可增量的uv計(jì)算
•用更多的資源計(jì)算，更快的釋放
1）sparksql，內(nèi)存需求高，復(fù)雜計(jì)算快
2）presto/impala，利用mpp框架提高計(jì)算性能
•不同隊(duì)列的資源使用上限限制
1）基于項(xiàng)目粒度的隊(duì)列資源把控，個(gè)性化控制最大可提交資源
2）項(xiàng)目隊(duì)列的最大值限制，避免單個(gè)項(xiàng)目失控
•Reduce Slow Start
1）基于實(shí)際m/r的比值設(shè)置該參數(shù)
2）資源更快的獲得和釋放，整體集群受益
資源使用報(bào)告
最后，制作資源使用報(bào)告時(shí)，我們可以把它轉(zhuǎn)化、精簡，保證所有集群使用的信息都可以在里面看到，并每周定時(shí)給業(yè)務(wù)發(fā)一份詳細(xì)的報(bào)表和郵件就可以了。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
相關(guān)文章
