本文主要介紹如何通過對計算引擎入口的統一，降低用戶接入門檻；如何讓用戶自助分析任務異常及失敗原因，以及如何從集羣產生的任務數據本身監控集羣計算/存儲資源消耗，監控集羣狀況，監控異常任務等。
其中 6 人的離線團隊需要維護大數據集羣規模如下：
Hadoop 集羣規模 1300+
HDFS 存量數據 40+PB，Read 3.5 PB+/天，Write 500TB+/天
14W MR Job/天，10W Spark Job/天，25W Presto/天
此外還需要維護 Hadoop、Spark、Hive、Presto 等餓了麼內部版本組件，解決公司 400+ 大數據集羣用戶每天面臨的各種問題。
引擎入口統一
目前在餓了麼對外提供的查詢引擎主要有 Presto、Hive 和 Spark，其中 Spark 又有 Spark Thrift Server 和 Spark SQL 兩種模式。
並且 Kylin 也在穩步試用中，Druid 也正在調研中。各種計算引擎都有自身的優缺點，適用的計算場景各不相同。
從用戶角度來說，普通用戶對此沒有較強的辨識能力，學習成本會比較高。
並且當用戶可以自主選擇引擎執行任務時，會優先選擇所謂的最快引擎，而這勢必會造成引擎阻塞，或者將完全不適合的任務提交到某引擎，從而降低任務成功率。
從管理角度來說，大數據集羣的入口太多，將難以實現統一管理，難以實現負載均衡、權限控制，難以掌控集羣整體對外服務能力。
並且當有新的計算需求需要接入，我們還需要爲其部署對應的客戶端環境。
功能模塊
針對這種情況，餓了麼大數據團隊開發了 Dispatcher，該組件的主要功能如下圖所示：
用戶所有任務全部通過 Dispatcher 提交，在 Dispatcher 中我們可以做到統一的鑑權，統一的任務執行情況跟蹤。
還可以做到執行引擎的自動路由，各執行引擎負載控制，以及通過引擎降級提高任務運行成功率。
在這裏要推薦下大數據學習交流羣:806025609，羣裏都是學大數據開發的，如果你正在學習大數據 ，歡迎你加入,羣內還會不定期分享乾貨（只有大數據軟件開發相關的），進羣即可獲取一份免費大數據學習資料~
邏輯架構
Dispatcher 的邏輯架構如下圖所示：
目前用戶可以通過 JDBC 模式調用 Dispatcher 服務，或者直接以 Driver 模式運行 Dispatcher。
Dispatcher 接收到查詢請求後，將會統一進行鑑權、引擎路由等操作，將查詢提交到對應引擎。
另外，Dispatcher 還有 SQL 轉換模塊，當發生從 Presto 引擎降級到 Spark/Hive 引擎時，將會通過該模塊自動將 Presto SQL 轉換成 HiveQL。
通過 Dispatcher 對查詢入口的統一，帶來的好處如下：
用戶接入門檻低，無需再去學習各引擎使用方法和優缺點，無需手動選擇執行引擎。
部署成本低，客戶端可通過 JDBC 方式快速接入。
統一的鑑權和監控。
降級模塊提高任務成功率。
各引擎負載均衡。
引擎可擴展。
引擎可擴展主要是指當後續接入 Kylin、Druid 或者其他更多查詢引擎時，可以做到用戶無感知。
由於收集到了提交到集羣的所有查詢，針對每一個已有查詢計劃，我們可以獲得熱度數據，知道在全部查詢中哪些表被使用次數最多，哪些表經常被關聯查詢，哪些字段經常被聚合查詢等。
當後續接入 Kylin 時，可以通過這些數據快速建立或優化 Cube。
SQL 畫像
在 Dispatcher 中最核心的是 SQL 畫像模塊，基本流程如下圖：
查詢提交後，通過連接 HiveServer 對查詢計劃進行解析，可以獲取當前查詢的所有元數據信息，比如：
讀入數據量
讀入表/分區數
各類 Join 次數
關聯字段多少
聚合複雜度
過濾條件
……
上述元數據信息基本上可以對每一個查詢進行精準的描述，每一個查詢可以通過這些維度的統計信息調度到不同引擎中。
Hive 對 SQL 進行解析並進行邏輯執行計劃優化後，將會得到優化後的 Operator Tree，通過 explain 命令可以查看。
SQL 畫像數據可以從這個結果收集各種不同類型的 Operator 操作，如下圖所示：
從直觀的理解上我們知道，讀入數據量對於引擎的選擇是很重要的。比如當讀入少量數據時，Presto 執行性能最好，讀入大量數據時 Hive 最穩定，而當讀入中等數據量時，可以由 Spark 來執行。
在初始階段，還可以通過讀入數據量，結合 Join 複雜度，聚合複雜度等因素在各種計算引擎上進行測試，採用基於規則的辦法進行路由。
執行過程中記錄好每一次查詢的 SQL 畫像數據，執行引擎，降級鏈路等數據。
基於這些畫像數據，後續可以採用比如決策樹，Logistic 迴歸，SVM 等分類算法實現引擎的智能路由，目前餓了麼大數據團隊已經開始了這方面的嘗試。
在餓了麼的應用中，由 Dispatcher 統一調度的 Ad Hoc 查詢，由於增加了預檢查環節，以及失敗降級環節，每天總體成功率爲 99.95% 以上，整體 PT90 值爲 300 秒左右。
目前 Presto 承擔了 Ad Hoc 查詢的 50% 流量，SparkServer 模式承擔了 40% 流量。
充分利用集羣本身數據
餓了麼大數據集羣每天運行的 Spark&MR 任務 25W+，這些數據詳細記錄了每一個 Mapper/Reducer 或者 Spark 的 Task 的運行情況，如果能夠充分利用，將會產生巨大的價值。即充分利用集羣本身數據，數據驅動集羣建設。
這些數據不僅可以有助於集羣管理人員監控集羣本身的計算資源、存儲資源消耗，任務性能分析，主機運行狀態。還可以幫助用戶自助分析任務運行失敗原因，任務運行性能分析等。
餓了麼大數據團隊開發的 Grace 項目就是在這方面的一個示例。
Grace 使用場景
你對集羣任務運行狀況詳細數據沒有明確認識的話，很容易當出現問題時陷入困境，從監控看到集羣異常後將無法繼續進一步快速定位問題。
當經常有用戶找你說，我的任務爲什麼跑失敗了？我的任務爲什麼跑的這麼慢？我的任務能調一下優先級麼？不要跟我說看日誌，我看不懂。我想大家內心都是崩潰的。
當監控發出 NameNode 異常抖動，網絡飈高，block 創建增加，block 創建延時增大等告警時，應該如何快速定位集羣運行的異常任務？
當監控發出集羣中 Pending 的任務太多時，用戶反饋任務大面積延遲時，如何快速找到問題根本原因？
當用戶申請計算資源時，到底應該給他們分配多少資源？當用戶申請提高任務優先級時如何用數據說話，明確優先級到底應該調到多少？當用戶只管上線不管下線任務時，我們如何定位哪些任務是不再需要的？
還有，如何通過實時展示各 BU 計算資源消耗，指定 BU 中各用戶計算資源消耗，佔 BU 資源比例。
以及如何從歷史數據中分析各 BU 任務數，資源使用比例，BU 內部各用戶的資源消耗，各任務的資源消耗等。
以下示例展示一些 Grace 產出數據圖表，有關 BU、用戶、任務級別的數據不方便展示。
監控隊列
從下圖可以方便的看到各隊列最大最小資源，當前已用資源，當前運行任務數，Pending 任務數，以及資源使用比例等，還可以看到這些數據的歷史趨勢。
任務監控
可以查看指定隊列中運行中任務的任務類型，開始時間，運行時長，消耗當前隊列資源比例，以及消耗當前 BU 資源比例等。
可快速定位計算資源消耗多並且運行時間長的任務，快速找到隊列阻塞原因。
監控主機失敗率
可以監控集羣所有主機上的 Task 執行失敗率。已有監控體系會對主機的 CPU，磁盤，內存，網絡等硬件狀況進行監控。
這些硬件故障最直觀的表現就是分配在這些有問題的主機上的任務執行緩慢或者執行失敗。
運行中的任務是最靈敏的反應，一旦檢測到某主機失敗率過高，可觸發快速自動下線保障業務正常執行。後續可以結合硬件監控定位主機異常原因。
任務性能分析
用戶可自助進行任務性能分析，如下圖：
並且可以根據異常項按照以下建議自助調整，如下圖：
任務失敗原因分析
對於失敗的任務，用戶也可以按照以下方法快速從調度系統查看失敗原因，以及對應的解決辦法，餓了麼大數據團隊會定期收集各種典型報錯信息，更新維護自助分析知識庫。
除此之外，我們還可以實時監控每個任務的計算資源消耗 GB Hours，總的讀入寫出數據量，Shuffle 數據量等，以及運行中任務的 HDFS 讀寫數據量，HDFS 操作數等。
當出現集羣計算資源不足時，可快速定位消耗計算資源多的任務。當監控出現 HDFS 集羣抖動，讀寫超時等異常狀況時，也可通過這些數據快速定位到異常任務。
基於這些數據還可以根據各隊列任務量，任務運行資源消耗時間段分佈，合理優化各隊列資源分配比例。
根據這些任務運行狀況數據建立任務畫像，監控任務資源消耗趨勢，定位任務是否異常。再結合任務產出數據的訪問熱度，還可以反饋給調度系統動態調整任務優先級等。
Grace 架構
上述示例中使用到的數據都是通過 Grace 收集的。Grace 是餓了麼大數據團隊開發的應用，主要用於監控分析線上 MR/Spark 任務運行數據，監控運行中隊列及任務明細及彙總數據。
邏輯架構如下圖：
Grace 是通過 Spark Streaming 實現的，通過消費 Kafka 中存儲的已完成 MR 任務的 jhist 文件或 Spark 任務的 eventlog 路徑，從 HDFS 對應位置獲取任務運行歷史數據，解析後得到 MR/Spark 任務的明細數據。
再根據這些數據進行一定的聚合分析，得到任務級別，Job 級別，Stage 級別的彙總信息。
最後通過定製化的 Dr-Elephant 系統對任務明細數據通過啓發式算法進行分析，從而給用戶一些直觀化的優化提示。
對於 Dr-Elephant，我們也做了定製化的變動，比如將其作爲 Grace 體系的一個組件打包依賴。
從單機部署服務的模式變成了分佈式實時解析模式。將其數據源切換爲 Grace 解析到的任務明細數據。
增加每個任務的 ActionId 跟蹤鏈路信息，優化 Spark 任務解析邏輯，增加新的啓發式算法和新的監控指標等。
總結
隨着大數據生態體系越來越完善，越來越多背景不同的用戶都將加入該生態圈，我們如何降低用戶的進入門檻，方便用戶快速便捷地使用大數據資源，也是需要考慮的問題。
大數據集羣中運行的絕大部分任務都是業務相關，但是隨着集羣規模越來越大，任務規模越來越大，集羣本身產生的數據也是不容忽視的。
這部分數據纔是真正反映集羣使用詳細情況的，我們需要考慮如何收集使用這部分數據，從數據角度來衡量、觀察我們的集羣和任務。