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

餓了么 BDI-大數(shù)據(jù)平臺研發(fā)團隊目前共有 20 人左右，主要負責離線&實時 Infra 和平臺工具開發(fā)。

其中 6 人的離線團隊需要維護大數(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/天

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

引擎入口統(tǒng)一

目前在餓了么對外提供的查詢引擎主要有 Presto、Hive 和 Spark，其中 Spark 又有 Spark Thrift Server 和 Spark SQL 兩種模式。

并且 Kylin 也在穩(wěn)步試用中，Druid 也正在調(diào)研中。各種計算引擎都有自身的優(yōu)缺點，適用的計算場景各不相同。

從用戶角度來說，普通用戶對此沒有較強的辨識能力，學(xué)習成本會比較高。

并且當用戶可以自主選擇引擎執(zhí)行任務(wù)時，會優(yōu)先選擇所謂的最快引擎，而這勢必會造成引擎阻塞，或者將完全不適合的任務(wù)提交到某引擎，從而降低任務(wù)成功率。

從管理角度來說，大數(shù)據(jù)集群的入口太多，將難以實現(xiàn)統(tǒng)一管理，難以實現(xiàn)負載均衡、權(quán)限控制，難以掌控集群整體對外服務(wù)能力。

并且當有新的計算需求需要接入，我們還需要為其部署對應(yīng)的客戶端環(huán)境。

用戶使用多種計算引擎

功能模塊

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

Dispatcher 功能模塊

用戶所有任務(wù)全部通過 Dispatcher 提交，在 Dispatcher 中我們可以做到統(tǒng)一的鑒權(quán)，統(tǒng)一的任務(wù)執(zhí)行情況跟蹤。

還可以做到執(zhí)行引擎的自動路由，各執(zhí)行引擎負載控制，以及通過引擎降級提高任務(wù)運行成功率。

邏輯架構(gòu)

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

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

目前用戶可以通過 JDBC 模式調(diào)用 Dispatcher 服務(wù)，或者直接以 Driver 模式運行 Dispatcher。

Dispatcher 接收到查詢請求后，將會統(tǒng)一進行鑒權(quán)、引擎路由等操作，將查詢提交到對應(yīng)引擎。

另外，Dispatcher 還有 SQL 轉(zhuǎn)換模塊，當發(fā)生從 Presto 引擎降級到 Spark/Hive 引擎時，將會通過該模塊自動將 Presto SQL 轉(zhuǎn)換成 HiveQL。

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

• 用戶接入門檻低，無需再去學(xué)習各引擎使用方法和優(yōu)缺點，無需手動選擇執(zhí)行引擎。
• 部署成本低，客戶端可通過 JDBC 方式快速接入。
• 統(tǒng)一的鑒權(quán)和監(jiān)控。
• 降級模塊提高任務(wù)成功率。
• 各引擎負載均衡。
• 引擎可擴展。

引擎可擴展主要是指當后續(xù)接入 Kylin、Druid 或者其他更多查詢引擎時，可以做到用戶無感知。

由于收集到了提交到集群的所有查詢，針對每一個已有查詢計劃，我們可以獲得熱度數(shù)據(jù)，知道在全部查詢中哪些表被使用次數(shù)最多，哪些表經(jīng)常被關(guān)聯(lián)查詢，哪些字段經(jīng)常被聚合查詢等。

當后續(xù)接入 Kylin 時，可以通過這些數(shù)據(jù)快速建立或優(yōu)化 Cube。

SQL 畫像

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

SQL 路由模塊

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

• 讀入數(shù)據(jù)量
• 讀入表/分區(qū)數(shù)
• 各類 Join 次數(shù)
• 關(guān)聯(lián)字段多少
• 聚合復(fù)雜度
• 過濾條件
• ……

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

Hive 對 SQL 進行解析并進行邏輯執(zhí)行計劃優(yōu)化后，將會得到優(yōu)化后的 Operator Tree，通過 explain 命令可以查看。

SQL 畫像數(shù)據(jù)可以從這個結(jié)果收集各種不同類型的 Operator 操作，如下圖所示：

SQL 解析示例

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

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

在初始階段，還可以通過讀入數(shù)據(jù)量，結(jié)合 Join 復(fù)雜度，聚合復(fù)雜度等因素在各種計算引擎上進行測試，采用基于規(guī)則的辦法進行路由。

執(zhí)行過程中記錄好每一次查詢的 SQL 畫像數(shù)據(jù)，執(zhí)行引擎，降級鏈路等數(shù)據(jù)。

基于這些畫像數(shù)據(jù)，后續(xù)可以采用比如決策樹，Logistic 回歸，SVM 等分類算法實現(xiàn)引擎的智能路由，目前餓了么大數(shù)據(jù)團隊已經(jīng)開始了這方面的嘗試。

在餓了么的應(yīng)用中，由 Dispatcher 統(tǒng)一調(diào)度的 Ad Hoc 查詢，由于增加了預(yù)檢查環(huán)節(jié)，以及失敗降級環(huán)節(jié)，每天總體成功率為 99.95% 以上，整體 PT90 值為 300 秒左右。

目前 Presto 承擔了 Ad Hoc 查詢的 50% 流量，SparkServer 模式承擔了 40% 流量。

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

餓了么大數(shù)據(jù)集群每天運行的 Spark&MR 任務(wù) 25W+，這些數(shù)據(jù)詳細記錄了每一個 Mapper/Reducer 或者 Spark 的 Task 的運行情況，如果能夠充分利用，將會產(chǎn)生巨大的價值。即充分利用集群本身數(shù)據(jù)，數(shù)據(jù)驅(qū)動集群建設(shè)。

這些數(shù)據(jù)不僅可以有助于集群管理人員監(jiān)控集群本身的計算資源、存儲資源消耗，任務(wù)性能分析，主機運行狀態(tài)。還可以幫助用戶自助分析任務(wù)運行失敗原因，任務(wù)運行性能分析等。

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

Grace 使用場景

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

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

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

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

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

還有，如何通過實時展示各 BU 計算資源消耗，指定 BU 中各用戶計算資源消耗，占 BU 資源比例。

以及如何從歷史數(shù)據(jù)中分析各 BU 任務(wù)數(shù)，資源使用比例，BU 內(nèi)部各用戶的資源消耗，各任務(wù)的資源消耗等。

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

監(jiān)控隊列

從下圖可以方便的看到各隊列***最小資源，當前已用資源，當前運行任務(wù)數(shù)，Pending 任務(wù)數(shù)，以及資源使用比例等，還可以看到這些數(shù)據(jù)的歷史趨勢。

各隊列任務(wù)情況

隊列資源使用趨勢

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

可以查看指定隊列中運行中任務(wù)的任務(wù)類型，開始時間，運行時長，消耗當前隊列資源比例，以及消耗當前 BU 資源比例等。

可快速定位計算資源消耗多并且運行時間長的任務(wù)，快速找到隊列阻塞原因。

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

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

可以監(jiān)控集群所有主機上的 Task 執(zhí)行失敗率。已有監(jiān)控體系會對主機的 CPU，磁盤，內(nèi)存，網(wǎng)絡(luò)等硬件狀況進行監(jiān)控。

這些硬件故障最直觀的表現(xiàn)就是分配在這些有問題的主機上的任務(wù)執(zhí)行緩慢或者執(zhí)行失敗。

運行中的任務(wù)是最靈敏的反應(yīng)，一旦檢測到某主機失敗率過高，可觸發(fā)快速自動下線保障業(yè)務(wù)正常執(zhí)行。后續(xù)可以結(jié)合硬件監(jiān)控定位主機異常原因。

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

任務(wù)性能分析

用戶可自助進行任務(wù)性能分析，如下圖：

任務(wù)性能分析

并且可以根據(jù)異常項按照以下建議自助調(diào)整，如下圖：

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

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

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

失敗原因自助分析

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

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

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

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

Grace 架構(gòu)

上述示例中使用到的數(shù)據(jù)都是通過 Grace 收集的。Grace 是餓了么大數(shù)據(jù)團隊開發(fā)的應(yīng)用，主要用于監(jiān)控分析線上 MR/Spark 任務(wù)運行數(shù)據(jù)，監(jiān)控運行中隊列及任務(wù)明細及匯總數(shù)據(jù)。

邏輯架構(gòu)如下圖：

Grace 邏輯架構(gòu)

Grace 是通過 Spark Streaming 實現(xiàn)的，通過消費 Kafka 中存儲的已完成 MR 任務(wù)的 jhist 文件或 Spark 任務(wù)的 eventlog 路徑，從 HDFS 對應(yīng)位置獲取任務(wù)運行歷史數(shù)據(jù)，解析后得到 MR/Spark 任務(wù)的明細數(shù)據(jù)。

再根據(jù)這些數(shù)據(jù)進行一定的聚合分析，得到任務(wù)級別，Job 級別，Stage 級別的匯總信息。

***通過定制化的 Dr-Elephant 系統(tǒng)對任務(wù)明細數(shù)據(jù)通過啟發(fā)式算法進行分析，從而給用戶一些直觀化的優(yōu)化提示。

對于 Dr-Elephant，我們也做了定制化的變動，比如將其作為 Grace 體系的一個組件打包依賴。

從單機部署服務(wù)的模式變成了分布式實時解析模式。將其數(shù)據(jù)源切換為 Grace 解析到的任務(wù)明細數(shù)據(jù)。

增加每個任務(wù)的 ActionId 跟蹤鏈路信息，優(yōu)化 Spark 任務(wù)解析邏輯，增加新的啟發(fā)式算法和新的監(jiān)控指標等。

總結(jié)

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

大數(shù)據(jù)集群中運行的絕大部分任務(wù)都是業(yè)務(wù)相關(guān)，但是隨著集群規(guī)模越來越大，任務(wù)規(guī)模越來越大，集群本身產(chǎn)生的數(shù)據(jù)也是不容忽視的。

這部分數(shù)據(jù)才是真正反映集群使用詳細情況的，我們需要考慮如何收集使用這部分數(shù)據(jù)，從數(shù)據(jù)角度來衡量、觀察我們的集群和任務(wù)。

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

作者：陳凱明

簡介：具有多年從事大數(shù)據(jù)基礎(chǔ)架構(gòu)工作經(jīng)驗。目前擔任餓了么數(shù)據(jù)平臺研發(fā)團隊資深數(shù)據(jù)工程師，主要負責餓了么離線平臺及底層工具開發(fā)。