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

此外還需要維護(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ì)算/存儲資源消耗，監(jiān)控集群狀況，監(jiān)控異常任務(wù)等。

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

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

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

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

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

Dispatcher功能模塊

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

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

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

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

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

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

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

SQL路由模塊

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

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

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

SQL解析示例

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

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

在初始階段，還可以通過讀入數(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%流量。

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

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

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ù)類型，開始時間，運(yùn)行時長，消耗當(dāng)前隊(duì)列資源比例，以及消耗當(dāng)前BU資源比例等?？煽焖俣ㄎ挥?jì)算資源消耗多并且運(yùn)行時間長的任務(wù)，快速找到隊(duì)列阻塞原因。

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

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

可以監(jiān)控集群所有主機(jī)上的Task執(zhí)行失敗率。已有監(jiān)控體系會對主機(jī)的CPU，磁盤，內(nèi)存，網(wǎng)絡(luò)等硬件狀況進(jìn)行監(jiān)控。這些硬件故障最直觀的表現(xiàn)就是分配在這些有問題的主機(jī)上的任務(wù)執(zhí)行緩慢或者執(zhí)行失敗。運(yùn)行中的任務(wù)是最靈敏的反應(yīng)，一旦檢測到某主機(jī)失敗率過高，可觸發(fā)快速自動下線保障業(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ì)會定期收集各種典型報錯信息，更新維護(hù)自助分析知識庫。

失敗原因自助分析

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

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

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

根據(jù)這些任務(wù)運(yùn)行狀況數(shù)據(jù)建立任務(wù)畫像，監(jiān)控任務(wù)資源消耗趨勢，定位任務(wù)是否異常。再結(jié)合任務(wù)產(chǎn)出數(shù)據(jù)的訪問熱度，還可以反饋給調(diào)度系統(tǒng)動態(tài)調(diào)整任務(wù)優(yō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中存儲的已完成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，我們也做了定制化的變動，比如將其作為Grace體系的一個組件打包依賴。從單機(jī)部署服務(wù)的模式變成了分布式實(shí)時解析模式。將其數(shù)據(jù)源切換為Grace解析到的任務(wù)明細(xì)數(shù)據(jù)。增加每個任務(wù)的ActionId跟蹤鏈路信息，優(yōu)化Spark任務(wù)解析邏輯，增加新的啟發(fā)式算法和新的監(jiān)控指標(biāo)等。

隨著大數(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è)，是本次分享的主題。