餓了么BDI-大數(shù)據(jù)平臺研發(fā)團(tuán)隊(duì)目前共有20人左右工腋，主要負(fù)責(zé)離線&實(shí)時(shí)Infra和平臺工具開發(fā)又碌。其中6人的離線團(tuán)隊(duì)需要維護(hù)大數(shù)據(jù)集群規(guī)模如下：

Hadoop集群規(guī)模1300+

HDFS存量數(shù)據(jù)40+PB，Read 3.5 PB+/天憾赁，Write 500TB+/天

14W MR Job/天污朽，10W Spark Job/天，25W Presto/天

此外還需要維護(hù)Hadoop龙考、Spark蟆肆、Hive、Presto等組件餓了么內(nèi)部版本晦款，解決公司400+大數(shù)據(jù)集群用戶每天面臨的各種問題炎功。

本文主要介紹餓了么大數(shù)據(jù)團(tuán)隊(duì)如何通過對計(jì)算引擎入口的統(tǒng)一，降低用戶接入門檻缓溅。如何讓用戶自助分析任務(wù)異常及失敗原因蛇损，以及如何從集群產(chǎn)生的任務(wù)數(shù)據(jù)本身監(jiān)控集群計(jì)算/存儲(chǔ)資源消耗，監(jiān)控集群狀況坛怪，監(jiān)控異常任務(wù)等淤齐。

01

引擎入口統(tǒng)一

_____

目前在餓了么對外提供的查詢引擎主要有Presto、Hive和Spark袜匿，其中Spark又有SparkThrift Server和Spark SQL兩種模式更啄，并且Kylin也在穩(wěn)步試用中，Druid也正在調(diào)研中居灯。各種計(jì)算引擎都有自身的優(yōu)缺點(diǎn)祭务，適用的計(jì)算場景各不相同内狗。

從用戶角度來說，普通用戶對此沒有較強(qiáng)的辨識能力义锥，學(xué)習(xí)成本會(huì)比較高柳沙。并且當(dāng)用戶可以自主選擇引擎執(zhí)行任務(wù)時(shí)，會(huì)優(yōu)先選擇所謂的最快引擎拌倍，而這勢必會(huì)造成引擎阻塞赂鲤，或者將完全不適合的任務(wù)提交到某引擎，從而降低任務(wù)成功率贰拿。

從管理角度來說蛤袒，大數(shù)據(jù)集群的入口太多，將難以實(shí)現(xiàn)統(tǒng)一管理膨更，難以實(shí)現(xiàn)負(fù)載均衡妙真、權(quán)限控制，難以掌控集群整體對外服務(wù)能力荚守。并且當(dāng)有新的計(jì)算需求需要接入错览，我們還需要為其部署對應(yīng)的客戶端環(huán)境忍法。

用戶使用多種計(jì)算引擎

1? ??功能模塊

針對這種情況齿风，餓了么大數(shù)據(jù)團(tuán)隊(duì)開發(fā)了Dispatcher杜恰，該組件的主要功能如下圖所示：

Dispatcher功能模塊

用戶所有任務(wù)全部通過Dispatcher提交，在Dispatcher中我們可以做到統(tǒng)一的鑒權(quán)敞贡，統(tǒng)一的任務(wù)執(zhí)行情況跟蹤泵琳。還可以做到執(zhí)行引擎的自動(dòng)路由，各執(zhí)行引擎負(fù)載控制誊役，以及通過引擎降級提高任務(wù)運(yùn)行成功率获列。

2? ??邏輯架構(gòu)

Dispatcher的邏輯架構(gòu)如下圖所示：

Dispatcher系統(tǒng)邏輯架構(gòu)

目前用戶可以通過JDBC模式調(diào)用Dispatcher服務(wù)，或者直接以Driver模式運(yùn)行Dispatcher蛔垢。Dispatcher接收到查詢請求后击孩，將會(huì)統(tǒng)一進(jìn)行鑒權(quán)、引擎路由等操作將查詢提交到對應(yīng)引擎鹏漆。另外巩梢，Dispatcher還有SQL轉(zhuǎn)換模塊，當(dāng)發(fā)生從Presto引擎降級到Spark/Hive引擎時(shí)艺玲，將會(huì)通過該模塊自動(dòng)將Presto SQL轉(zhuǎn)換成HiveQL括蝠。

通過Dispatcher對查詢?nèi)肟诘慕y(tǒng)一，帶來的好處如下：

用戶接入門檻低饭聚，無需再去學(xué)習(xí)各引擎使用方法和優(yōu)缺點(diǎn)忌警，無需手動(dòng)選擇執(zhí)行引擎；

部署成本低若治，客戶端可通過JDBC方式快速接入慨蓝；

統(tǒng)一的鑒權(quán)和監(jiān)控；

降級模塊提高任務(wù)成功率端幼；

各引擎負(fù)載均衡礼烈；

引擎可擴(kuò)展。

引擎可擴(kuò)展主要是指當(dāng)后續(xù)接入Kylin婆跑、Druid或者其他更多查詢引擎時(shí)此熬，可以做到用戶無感知。由于收集到了提交到集群的所有查詢滑进，針對每一個(gè)已有查詢計(jì)劃犀忱，我們可以獲得熱度數(shù)據(jù)，知道在全部查詢中哪些表被使用次數(shù)最多扶关，哪些表經(jīng)常被關(guān)聯(lián)查詢阴汇，哪些字段經(jīng)常被聚合查詢等，當(dāng)后續(xù)接入Kylin時(shí)节槐，可以通過這些數(shù)據(jù)快速建立或優(yōu)化Cube搀庶。

3? ??SQL畫像

在Dispatcher中最核心的是SQL畫像模塊，基本流程如下圖：

SQL路由模塊

查詢提交后铜异，通過連接HiveServer對查詢計(jì)劃進(jìn)行解析哥倔，可以獲取當(dāng)前查詢的所有元數(shù)據(jù)信息，比如：

讀入數(shù)據(jù)量

讀入表/分區(qū)數(shù)

各類Join次數(shù)

關(guān)聯(lián)字段多少

聚合復(fù)雜度

過濾條件

……

上述元數(shù)據(jù)信息基本上可以對每一個(gè)查詢進(jìn)行精準(zhǔn)的描述揍庄，每一個(gè)查詢可以通過這些維度的統(tǒng)計(jì)信息調(diào)度到不同引擎中咆蒿。

Hive對SQL進(jìn)行解析并進(jìn)行邏輯執(zhí)行計(jì)劃優(yōu)化后，將會(huì)得到優(yōu)化后的Operator Tree蚂子，通過explain命令可以查看沃测。SQL畫像數(shù)據(jù)可以從這個(gè)結(jié)果收集各種不同類型的Operator操作，如下圖所示：

SQL解析示例

從直觀的理解上我們知道缆镣，讀入數(shù)據(jù)量對于引擎的選擇是很重要的芽突。比如當(dāng)讀入少量數(shù)據(jù)時(shí)，Presto執(zhí)行性能最好董瞻，讀入大量數(shù)據(jù)時(shí)Hive最穩(wěn)定寞蚌，而當(dāng)讀入中等數(shù)據(jù)量時(shí)，可以由Spark來執(zhí)行钠糊。

各類計(jì)算引擎數(shù)據(jù)量-執(zhí)行時(shí)間分布

在初始階段挟秤，還可以通過讀入數(shù)據(jù)量，結(jié)合Join復(fù)雜度抄伍，聚合復(fù)雜度等因素在各種計(jì)算引擎上進(jìn)行測試艘刚，采用基于規(guī)則的辦法進(jìn)行路由。執(zhí)行過程中記錄好每一次查詢的SQL畫像數(shù)據(jù)截珍，執(zhí)行引擎攀甚，降級鏈路等數(shù)據(jù)箩朴。基于這些畫像數(shù)據(jù)秋度，后續(xù)可以采用比如決策樹炸庞，Logistic回歸，SVM等分類算法實(shí)現(xiàn)引擎的智能路由荚斯，目前餓了么大數(shù)據(jù)團(tuán)隊(duì)已經(jīng)開始了這方面的嘗試埠居。

目前在餓了么的應(yīng)用中，由Dispatcher統(tǒng)一調(diào)度的Ad Hoc查詢事期，由于增加了預(yù)檢查環(huán)節(jié)滥壕，以及失敗降級環(huán)節(jié)，每天總體成功率為99.95%以上兽泣，整體PT90值為300秒左右绎橘。目前Presto承擔(dān)了Ad Hoc查詢的50%流量，SparkServer模式承擔(dān)了40%流量撞叨。

想學(xué)習(xí)大數(shù)據(jù)或者對大數(shù)據(jù)技術(shù)感興趣的朋友金踪，這里我整理了一套大數(shù)據(jù)的學(xué)習(xí)視頻免費(fèi)分享給大家，從入門到實(shí)戰(zhàn)都有牵敷，大家可以加我的微信：Lxiao_28獲群怼！（備注領(lǐng)取資料）枷餐。也歡迎進(jìn)微信群交流靶瘸，或者獲取Java高級技術(shù)學(xué)習(xí)資料。

02

充分利用集群本身數(shù)據(jù)

_____

餓了么大數(shù)據(jù)集群每天運(yùn)行的Spark&MR任務(wù)25W+毛肋，這些數(shù)據(jù)詳細(xì)記錄了每一個(gè)Mapper/Reducer或者Spark的Task的運(yùn)行情況怨咪，如果能夠充分利用，將會(huì)產(chǎn)生巨大的價(jià)值润匙。充分利用集群本身數(shù)據(jù)诗眨，數(shù)據(jù)驅(qū)動(dòng)集群建設(shè)。這些數(shù)據(jù)不僅可以有助于集群管理人員監(jiān)控集群本身的計(jì)算資源孕讳、存儲(chǔ)資源消耗匠楚，任務(wù)性能分析，主機(jī)運(yùn)行狀態(tài)厂财。還可以幫助用戶自助分析任務(wù)運(yùn)行失敗原因芋簿，任務(wù)運(yùn)行性能分析等。

餓了么大數(shù)據(jù)團(tuán)隊(duì)開發(fā)的Grace項(xiàng)目就是在這方面的一個(gè)示例璃饱。

1? ??Grace使用場景

對集群任務(wù)運(yùn)行狀況詳細(xì)數(shù)據(jù)沒有明確認(rèn)識的話与斤，很容易當(dāng)出現(xiàn)問題時(shí)陷入困境，從監(jiān)控看到集群異常后將無法繼續(xù)進(jìn)一步快速定位問題。

當(dāng)經(jīng)常有用戶找你說撩穿，我的任務(wù)為什么跑失敗了磷支？我的任務(wù)為什么跑的這么慢？我的任務(wù)能調(diào)一下優(yōu)先級么食寡？不要跟我說看日志齐唆，我看不懂。我想大家內(nèi)心都是崩潰的冻河。

當(dāng)監(jiān)控發(fā)出NameNode異常抖動(dòng)，網(wǎng)絡(luò)飚高茉帅，block創(chuàng)建增加叨叙，block創(chuàng)建延時(shí)增大等告警時(shí)，應(yīng)該如何快速定位集群運(yùn)行的異常任務(wù)堪澎？

當(dāng)監(jiān)控發(fā)出集群中Pending的任務(wù)太多時(shí)擂错，用戶反饋任務(wù)大面積延遲時(shí)，如何快速找到問題根本原因樱蛤？

當(dāng)用戶申請計(jì)算資源時(shí)钮呀，到底應(yīng)該給他們分配多少資源？當(dāng)用戶申請?zhí)岣呷蝿?wù)優(yōu)先級時(shí)如何用數(shù)據(jù)說話昨凡，明確優(yōu)先級到底應(yīng)該調(diào)到多少爽醋？當(dāng)用戶只管上線不管下線任務(wù)時(shí)，我們?nèi)绾味ㄎ荒男┤蝿?wù)是不再需要的便脊？

還有蚂四，如何通過實(shí)時(shí)展示各BU計(jì)算資源消耗，指定BU中各用戶計(jì)算資源消耗哪痰，占BU資源比例遂赠。以及如何從歷史數(shù)據(jù)中分析各BU任務(wù)數(shù)，資源使用比例晌杰，BU內(nèi)部各用戶的資源消耗跷睦，各任務(wù)的資源消耗等。

以下示例展示一些Grace產(chǎn)出數(shù)據(jù)圖表肋演。有關(guān)BU抑诸、用戶、任務(wù)級別的數(shù)據(jù)不方便展示惋啃。

1）監(jiān)控隊(duì)列

從下圖可以方便的看到各隊(duì)列最大最小資源哼鬓，當(dāng)前已用資源，當(dāng)前運(yùn)行任務(wù)數(shù)边灭，Pending任務(wù)數(shù)异希，以及資源使用比例等，還可以看到這些數(shù)據(jù)的歷史趨勢。

各隊(duì)列任務(wù)情況

隊(duì)列資源使用趨勢

2）任務(wù)監(jiān)控

可以查看指定隊(duì)列中運(yùn)行中任務(wù)的任務(wù)類型称簿，開始時(shí)間扣癣，運(yùn)行時(shí)長，消耗當(dāng)前隊(duì)列資源比例憨降，以及消耗當(dāng)前BU資源比例等父虑。可快速定位計(jì)算資源消耗多并且運(yùn)行時(shí)間長的任務(wù)授药，快速找到隊(duì)列阻塞原因士嚎。

指定隊(duì)列任務(wù)情況

3）監(jiān)控主機(jī)失敗率

可以監(jiān)控集群所有主機(jī)上的Task執(zhí)行失敗率。已有監(jiān)控體系會(huì)對主機(jī)的CPU悔叽，磁盤莱衩，內(nèi)存，網(wǎng)絡(luò)等硬件狀況進(jìn)行監(jiān)控娇澎。這些硬件故障最直觀的表現(xiàn)就是分配在這些有問題的主機(jī)上的任務(wù)執(zhí)行緩慢或者執(zhí)行失敗笨蚁。運(yùn)行中的任務(wù)是最靈敏的反應(yīng)，一旦檢測到某主機(jī)失敗率過高趟庄，可觸發(fā)快速自動(dòng)下線保障業(yè)務(wù)正常執(zhí)行括细。后續(xù)可以結(jié)合硬件監(jiān)控定位主機(jī)異常原因。

主機(jī)失敗率監(jiān)控

4）任務(wù)性能分析

用戶可自助進(jìn)行任務(wù)性能分析戚啥。

任務(wù)性能分析

并且可以根據(jù)異常項(xiàng)根據(jù)以下建議自助調(diào)整奋单。

任務(wù)自助優(yōu)化方案

5）任務(wù)失敗原因分析

對于失敗的任務(wù)，用戶也可以按照以下方法快速從調(diào)度系統(tǒng)查看失敗原因猫十，以及對應(yīng)的解決辦法辱匿，餓了么大數(shù)據(jù)團(tuán)隊(duì)會(huì)定期收集各種典型報(bào)錯(cuò)信息，更新維護(hù)自助分析知識庫炫彩。

失敗原因自助分析

除此之外匾七，我們還可以實(shí)時(shí)監(jiān)控每個(gè)任務(wù)的計(jì)算資源消耗GB Hours，總的讀入寫出數(shù)據(jù)量江兢，Shuffle數(shù)據(jù)量等昨忆。以及運(yùn)行中任務(wù)的HDFS讀寫數(shù)據(jù)量，HDFS操作數(shù)等杉允。

當(dāng)出現(xiàn)集群計(jì)算資源不足時(shí)邑贴，可快速定位消耗計(jì)算資源多的任務(wù)。當(dāng)監(jiān)控出現(xiàn)HDFS集群抖動(dòng)叔磷，讀寫超時(shí)等異常狀況時(shí)拢驾，也可通過這些數(shù)據(jù)快速定位到異常任務(wù)。

基于這些數(shù)據(jù)還可以根據(jù)各隊(duì)列任務(wù)量改基，任務(wù)運(yùn)行資源消耗時(shí)間段分布繁疤，合理優(yōu)化各隊(duì)列資源分配比例。

根據(jù)這些任務(wù)運(yùn)行狀況數(shù)據(jù)建立任務(wù)畫像，監(jiān)控任務(wù)資源消耗趨勢稠腊，定位任務(wù)是否異常躁染。再結(jié)合任務(wù)產(chǎn)出數(shù)據(jù)的訪問熱度，還可以反饋給調(diào)度系統(tǒng)動(dòng)態(tài)調(diào)整任務(wù)優(yōu)先級等架忌。

2? ??Grace架構(gòu)

上述示例中使用到的數(shù)據(jù)都是通過Grace收集的吞彤。Grace是餓了么大數(shù)據(jù)團(tuán)隊(duì)開發(fā)的應(yīng)用，主要用于監(jiān)控分析線上MR/Spark任務(wù)運(yùn)行數(shù)據(jù)叹放，監(jiān)控運(yùn)行中隊(duì)列及任務(wù)明細(xì)及匯總數(shù)據(jù)饰恕。邏輯架構(gòu)如下：

Grace邏輯架構(gòu)

Grace是通過Spark Streaming實(shí)現(xiàn)的，通過消費(fèi)Kafka中存儲(chǔ)的已完成MR任務(wù)的jhist文件或Spark任務(wù)的eventlog路徑井仰，從HDFS對應(yīng)位置獲取任務(wù)運(yùn)行歷史數(shù)據(jù)懂盐，解析后得到MR/Spark任務(wù)的明細(xì)數(shù)據(jù)。再根據(jù)這些數(shù)據(jù)進(jìn)行一定的聚合分析糕档，得到任務(wù)級別，Job級別拌喉，Stage級別的匯總信息速那。最后通過定制化的Dr-Elephant系統(tǒng)對任務(wù)明細(xì)數(shù)據(jù)通過啟發(fā)式算法進(jìn)行分析，從而給用戶一些直觀化的優(yōu)化提示尿背。

對于Dr-Elephant端仰，我們也做了定制化的變動(dòng)，比如將其作為Grace體系的一個(gè)組件打包依賴田藐。從單機(jī)部署服務(wù)的模式變成了分布式實(shí)時(shí)解析模式荔烧。將其數(shù)據(jù)源切換為Grace解析到的任務(wù)明細(xì)數(shù)據(jù)。增加每個(gè)任務(wù)的ActionId跟蹤鏈路信息汽久，優(yōu)化Spark任務(wù)解析邏輯鹤竭，增加新的啟發(fā)式算法和新的監(jiān)控指標(biāo)等。

03

總結(jié)

_____

隨著大數(shù)據(jù)生態(tài)體系越來越完善景醇，越來越多背景不同的用戶都將加入該生態(tài)圈臀稚，我們?nèi)绾谓档陀脩舻倪M(jìn)入門檻，方便用戶快速便捷地使用大數(shù)據(jù)資源三痰，也是需要考慮的問題吧寺。

大數(shù)據(jù)集群中運(yùn)行的絕大部分任務(wù)都是業(yè)務(wù)相關(guān)，但是隨著集群規(guī)模越來越大散劫，任務(wù)規(guī)模越來越大稚机，集群本身產(chǎn)生的數(shù)據(jù)也是不容忽視的。這部分?jǐn)?shù)據(jù)才是真正反映集群使用詳細(xì)情況的获搏，我們需要考慮如何收集使用這部分?jǐn)?shù)據(jù)赖条，從數(shù)據(jù)角度來衡量、觀察我們的集群和任務(wù)。

僅僅關(guān)注于集群整體部署谋币、性能仗扬、穩(wěn)定等方面是不夠的，如何提高用戶體驗(yàn)蕾额，充分挖掘集群本身數(shù)據(jù)早芭，用數(shù)據(jù)促進(jìn)大數(shù)據(jù)集群的建設(shè)，是本次分享的主題诅蝶。

Q &?A

Q：能簡單介紹一下調(diào)度系統(tǒng)嗎退个？管理上萬個(gè)任務(wù)不容易。

A：調(diào)度系統(tǒng)說起來挺復(fù)雜的调炬。就提幾個(gè)關(guān)鍵點(diǎn)吧语盈，一個(gè)是任務(wù)之間的依賴，一個(gè)是血緣關(guān)系缰泡，一個(gè)是任務(wù)與實(shí)例刀荒，還有集群反壓、分布式調(diào)度棘钞、底層環(huán)境統(tǒng)一缠借。

其中血緣關(guān)系應(yīng)該是必須的，因?yàn)楫?dāng)你集群規(guī)模大了之后宜猜，用戶配置任務(wù)時(shí)根本無法完整地添加依賴泼返。

通過血緣系統(tǒng)，對任務(wù)進(jìn)行解析姨拥，當(dāng)用戶配置好新任務(wù)后绅喉，自動(dòng)推薦前置依賴，保證任務(wù)有序運(yùn)行叫乌。

Q：如何得出集群的每天讀寫規(guī)模柴罐？Hadoop有接口？

A：集群讀寫規(guī)模是通過前面介紹的Grace收集的憨奸。因?yàn)槲覀儠?huì)分析每個(gè)mr task或者spark task的HDFS數(shù)據(jù)讀寫量丽蝎。還包括spill到磁盤的數(shù)據(jù)量、shuffle write膀藐、shuffle read數(shù)據(jù)量屠阻，以及每個(gè)任務(wù)的GBHour信息。

其實(shí)這些數(shù)據(jù)你通過YARN或者Spark的WEB UI頁面都能看到额各，你需要做的只是實(shí)時(shí)地去解析国觉，收集這些數(shù)據(jù)。這也是本次分享介紹中提到的虾啦，從數(shù)據(jù)角度運(yùn)維集群麻诀。

除了業(yè)務(wù)數(shù)據(jù)之外痕寓，集群本身產(chǎn)生的數(shù)據(jù)也很有價(jià)值。

Q：這個(gè)就是從大數(shù)據(jù)本身產(chǎn)出的數(shù)據(jù)來精細(xì)化運(yùn)維集群吧蝇闭？

A：是的呻率。如果你也從事數(shù)據(jù)架構(gòu)方向的話，可以回想一下自己每天的工作內(nèi)容呻引。我們只不過是把人肉分析變成自動(dòng)化礼仗，然后再加入一些實(shí)時(shí)性。