大型大數(shù)據(jù)集群維護(hù)指南

1、 大型大數(shù)據(jù)集群維護(hù)指南餓了么大數(shù)據(jù)平臺(tái)運(yùn)維本文主要介紹餓了么大數(shù)據(jù)團(tuán)隊(duì)如何通過(guò)對(duì)計(jì)算引擎入口的統(tǒng)一，降低用戶(hù)接入門(mén)檻；如何讓用戶(hù)自助分析任務(wù)異常及失敗原因，以及如何從集群產(chǎn)生的任務(wù)數(shù)據(jù)本身監(jiān)控集群計(jì)算/存儲(chǔ)資源消耗，監(jiān)控集群狀況，監(jiān)控異常任務(wù)等。餓了么 BDI-大數(shù)據(jù)平臺(tái)研發(fā)團(tuán)隊(duì)目前共有 20 人左右，主要負(fù)責(zé)離線(xiàn)&實(shí)時(shí) Infra 和平臺(tái)工具開(kāi)發(fā)。其中 6 人的離線(xiàn)團(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 Pre

2、sto/天此外還需要維護(hù) Hadoop、Spark、Hive、Presto 等餓了么內(nèi)部版本組件，解決公司 400+ 大數(shù)據(jù)集群用戶(hù)每天面臨的各種問(wèn)題。引擎入口統(tǒng)一目前在餓了么對(duì)外提供的查詢(xún)引擎主要有 Presto、Hive 和 Spark，其中 Spark 又有 Spark Thrift Server 和 Spark SQL 兩種模式。并且 Kylin 也在穩(wěn)步試用中，Druid 也正在調(diào)研中。各種計(jì)算引擎都有自身的優(yōu)缺點(diǎn)，適用的計(jì)算場(chǎng)景各不相同。從用戶(hù)角度來(lái)說(shuō)，普通用戶(hù)對(duì)此沒(méi)有較強(qiáng)的辨識(shí)能力，學(xué)習(xí)成本會(huì)比較高。并且當(dāng)用戶(hù)可以自主選擇引擎執(zhí)行任務(wù)時(shí)，會(huì)優(yōu)先選擇所謂的最快引擎，而這勢(shì)必會(huì)造成引

3、擎阻塞，或者將完全不適合的任務(wù)提交到某引擎，從而降低任務(wù)成功率。從管理角度來(lái)說(shuō)，大數(shù)據(jù)集群的入口太多，將難以實(shí)現(xiàn)統(tǒng)一管理，難以實(shí)現(xiàn)負(fù)載均衡、權(quán)限控制，難以掌控集群整體對(duì)外服務(wù)能力。并且當(dāng)有新的計(jì)算需求需要接入，我們還需要為其部署對(duì)應(yīng)的客戶(hù)端環(huán)境。用戶(hù)使用多種計(jì)算引擎功能模塊針對(duì)這種情況，餓了么大數(shù)據(jù)團(tuán)隊(duì)開(kāi)發(fā)了 Dispatcher，該組件的主要功能如下圖所示：Dispatcher 功能模塊用戶(hù)所有任務(wù)全部通過(guò) Dispatcher 提交，在 Dispatcher 中我們可以做到統(tǒng)一的鑒權(quán)，統(tǒng)一的任務(wù)執(zhí)行情況跟蹤。還可以做到執(zhí)行引擎的自動(dòng)路由，各執(zhí)行引擎負(fù)載控制，以及通過(guò)引擎降級(jí)提高任務(wù)運(yùn)行成功

4、率。邏輯架構(gòu)Dispatcher 的邏輯架構(gòu)如下圖所示：Dispatcher 系統(tǒng)邏輯架構(gòu)目前用戶(hù)可以通過(guò) JDBC 模式調(diào)用 Dispatcher 服務(wù)，或者直接以 Driver 模式運(yùn)行 Dispatcher。Dispatcher 接收到查詢(xún)請(qǐng)求后，將會(huì)統(tǒng)一進(jìn)行鑒權(quán)、引擎路由等操作，將查詢(xún)提交到對(duì)應(yīng)引擎。另外，Dispatcher 還有 SQL 轉(zhuǎn)換模塊，當(dāng)發(fā)生從 Presto 引擎降級(jí)到 Spark/Hive 引擎時(shí)，將會(huì)通過(guò)該模塊自動(dòng)將 Presto SQL 轉(zhuǎn)換成 HiveQL。通過(guò) Dispatcher 對(duì)查詢(xún)?nèi)肟诘慕y(tǒng)一，帶來(lái)的好處如下：用戶(hù)接入門(mén)檻低，無(wú)需再去學(xué)習(xí)各引擎使用方法和

5、優(yōu)缺點(diǎn)，無(wú)需手動(dòng)選擇執(zhí)行引擎。部署成本低，客戶(hù)端可通過(guò) JDBC 方式快速接入。統(tǒng)一的鑒權(quán)和監(jiān)控。降級(jí)模塊提高任務(wù)成功率。各引擎負(fù)載均衡。引擎可擴(kuò)展。引擎可擴(kuò)展主要是指當(dāng)后續(xù)接入 Kylin、Druid 或者其他更多查詢(xún)引擎時(shí)，可以做到用戶(hù)無(wú)感知。由于收集到了提交到集群的所有查詢(xún)，針對(duì)每一個(gè)已有查詢(xún)計(jì)劃，我們可以獲得熱度數(shù)據(jù)，知道在全部查詢(xún)中哪些表被使用次數(shù)最多，哪些表經(jīng)常被關(guān)聯(lián)查詢(xún)，哪些字段經(jīng)常被聚合查詢(xún)等。當(dāng)后續(xù)接入 Kylin 時(shí)，可以通過(guò)這些數(shù)據(jù)快速建立或優(yōu)化 Cube。SQL 畫(huà)像在 Dispatcher 中最核心的是 SQL 畫(huà)像模塊，基本流程如下圖：SQL 路由模塊查詢(xún)提交后，通

6、過(guò)連接 HiveServer 對(duì)查詢(xún)計(jì)劃進(jìn)行解析，可以獲取當(dāng)前查詢(xún)的所有元數(shù)據(jù)信息，比如：讀入數(shù)據(jù)量讀入表/分區(qū)數(shù)各類(lèi) Join 次數(shù)關(guān)聯(lián)字段多少聚合復(fù)雜度過(guò)濾條件上述元數(shù)據(jù)信息基本上可以對(duì)每一個(gè)查詢(xún)進(jìn)行精準(zhǔn)的描述，每一個(gè)查詢(xún)可以通過(guò)這些維度的統(tǒng)計(jì)信息調(diào)度到不同引擎中。Hive 對(duì) SQL 進(jìn)行解析并進(jìn)行邏輯執(zhí)行計(jì)劃優(yōu)化后，將會(huì)得到優(yōu)化后的 Operator Tree，通過(guò) explain 命令可以查看。SQL 畫(huà)像數(shù)據(jù)可以從這個(gè)結(jié)果收集各種不同類(lèi)型的 Operator 操作，如下圖所示：SQL 解析示例從直觀(guān)的理解上我們知道，讀入數(shù)據(jù)量對(duì)于引擎的選擇是很重要的。比如當(dāng)讀入少量數(shù)據(jù)時(shí)，Pres

7、to 執(zhí)行性能最好，讀入大量數(shù)據(jù)時(shí) Hive 最穩(wěn)定，而當(dāng)讀入中等數(shù)據(jù)量時(shí)，可以由 Spark 來(lái)執(zhí)行。各類(lèi)計(jì)算引擎數(shù)據(jù)量-執(zhí)行時(shí)間分布在初始階段，還可以通過(guò)讀入數(shù)據(jù)量，結(jié)合 Join 復(fù)雜度，聚合復(fù)雜度等因素在各種計(jì)算引擎上進(jìn)行測(cè)試，采用基于規(guī)則的辦法進(jìn)行路由。執(zhí)行過(guò)程中記錄好每一次查詢(xún)的 SQL 畫(huà)像數(shù)據(jù)，執(zhí)行引擎，降級(jí)鏈路等數(shù)據(jù)。基于這些畫(huà)像數(shù)據(jù)，后續(xù)可以采用比如決策樹(shù)，Logistic 回歸，SVM 等分類(lèi)算法實(shí)現(xiàn)引擎的智能路由，目前餓了么大數(shù)據(jù)團(tuán)隊(duì)已經(jīng)開(kāi)始了這方面的嘗試。在餓了么的應(yīng)用中，由 Dispatcher 統(tǒng)一調(diào)度的 Ad Hoc 查詢(xún)，由于增加了預(yù)檢查環(huán)節(jié)，以及失敗降級(jí)環(huán)節(jié)

8、，每天總體成功率為 99.95% 以上，整體 PT90 值為 300 秒左右。目前 Presto 承擔(dān)了 Ad Hoc 查詢(xún)的 50% 流量，SparkServer 模式承擔(dān)了 40% 流量。充分利用集群本身數(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)。還可以幫助用戶(hù)自助分析任務(wù)運(yùn)行失敗原因，任務(wù)運(yùn)

9、行性能分析等。餓了么大數(shù)據(jù)團(tuán)隊(duì)開(kāi)發(fā)的 Grace 項(xiàng)目就是在這方面的一個(gè)示例。Grace 使用場(chǎng)景你對(duì)集群任務(wù)運(yùn)行狀況詳細(xì)數(shù)據(jù)沒(méi)有明確認(rèn)識(shí)的話(huà)，很容易當(dāng)出現(xiàn)問(wèn)題時(shí)陷入困境，從監(jiān)控看到集群異常后將無(wú)法繼續(xù)進(jìn)一步快速定位問(wèn)題。當(dāng)經(jīng)常有用戶(hù)找你說(shuō)，我的任務(wù)為什么跑失敗了？我的任務(wù)為什么跑的這么慢？我的任務(wù)能調(diào)一下優(yōu)先級(jí)么？不要跟我說(shuō)看日志，我看不懂。我想大家內(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í)，用戶(hù)反饋任務(wù)大面積延遲時(shí)，如何快速找到問(wèn)

10、題根本原因？當(dāng)用戶(hù)申請(qǐng)計(jì)算資源時(shí)，到底應(yīng)該給他們分配多少資源？當(dāng)用戶(hù)申請(qǐng)?zhí)岣呷蝿?wù)優(yōu)先級(jí)時(shí)如何用數(shù)據(jù)說(shuō)話(huà)，明確優(yōu)先級(jí)到底應(yīng)該調(diào)到多少？當(dāng)用戶(hù)只管上線(xiàn)不管下線(xiàn)任務(wù)時(shí)，我們?nèi)绾味ㄎ荒男┤蝿?wù)是不再需要的？還有，如何通過(guò)實(shí)時(shí)展示各 BU 計(jì)算資源消耗，指定 BU 中各用戶(hù)計(jì)算資源消耗，占 BU 資源比例。以及如何從歷史數(shù)據(jù)中分析各 BU 任務(wù)數(shù)，資源使用比例，BU 內(nèi)部各用戶(hù)的資源消耗，各任務(wù)的資源消耗等。以下示例展示一些 Grace 產(chǎn)出數(shù)據(jù)圖表，有關(guān) BU、用戶(hù)、任務(wù)級(jí)別的數(shù)據(jù)不方便展示。監(jiān)控隊(duì)列從下圖可以方便的看到各隊(duì)列最大最小資源，當(dāng)前已用資源，當(dāng)前運(yùn)行任務(wù)數(shù)，Pending 任務(wù)數(shù)，以及資源使

11、用比例等，還可以看到這些數(shù)據(jù)的歷史趨勢(shì)。各隊(duì)列任務(wù)情況隊(duì)列資源使用趨勢(shì)任務(wù)監(jiān)控可以查看指定隊(duì)列中運(yùn)行中任務(wù)的任務(wù)類(lèi)型，開(kāi)始時(shí)間，運(yùn)行時(shí)長(zhǎng)，消耗當(dāng)前隊(duì)列資源比例，以及消耗當(dāng)前 BU 資源比例等?？煽焖俣ㄎ挥?jì)算資源消耗多并且運(yùn)行時(shí)間長(zhǎng)的任務(wù)，快速找到隊(duì)列阻塞原因。指定隊(duì)列任務(wù)情況監(jiān)控主機(jī)失敗率可以監(jiān)控集群所有主機(jī)上的 Task 執(zhí)行失敗率。已有監(jiān)控體系會(huì)對(duì)主機(jī)的 CPU，磁盤(pán)，內(nèi)存，網(wǎng)絡(luò)等硬件狀況進(jìn)行監(jiān)控。這些硬件故障最直觀(guān)的表現(xiàn)就是分配在這些有問(wèn)題的主機(jī)上的任務(wù)執(zhí)行緩慢或者執(zhí)行失敗。運(yùn)行中的任務(wù)是最靈敏的反應(yīng)，一旦檢測(cè)到某主機(jī)失敗率過(guò)高，可觸發(fā)快速自動(dòng)下線(xiàn)保障業(yè)務(wù)正常執(zhí)行。后續(xù)可以結(jié)合硬件監(jiān)控定

12、位主機(jī)異常原因。主機(jī)失敗率監(jiān)控任務(wù)性能分析用戶(hù)可自助進(jìn)行任務(wù)性能分析，如下圖：任務(wù)性能分析并且可以根據(jù)異常項(xiàng)按照以下建議自助調(diào)整，如下圖：任務(wù)自助優(yōu)化方案任務(wù)失敗原因分析對(duì)于失敗的任務(wù)，用戶(hù)也可以按照以下方法快速?gòu)恼{(diào)度系統(tǒng)查看失敗原因，以及對(duì)應(yīng)的解決辦法，餓了么大數(shù)據(jù)團(tuán)隊(duì)會(huì)定期收集各種典型報(bào)錯(cuò)信息，更新維護(hù)自助分析知識(shí)庫(kù)。失敗原因自助分析除此之外，我們還可以實(shí)時(shí)監(jiān)控每個(gè)任務(wù)的計(jì)算資源消耗 GB Hours，總的讀入寫(xiě)出數(shù)據(jù)量，Shuffle 數(shù)據(jù)量等，以及運(yùn)行中任務(wù)的 HDFS 讀寫(xiě)數(shù)據(jù)量，HDFS 操作數(shù)等。當(dāng)出現(xiàn)集群計(jì)算資源不足時(shí)，可快速定位消耗計(jì)算資源多的任務(wù)。當(dāng)監(jiān)控出現(xiàn) HDFS 集群

13、抖動(dòng)，讀寫(xiě)超時(shí)等異常狀況時(shí)，也可通過(guò)這些數(shù)據(jù)快速定位到異常任務(wù)?；谶@些數(shù)據(jù)還可以根據(jù)各隊(duì)列任務(wù)量，任務(wù)運(yùn)行資源消耗時(shí)間段分布，合理優(yōu)化各隊(duì)列資源分配比例。根據(jù)這些任務(wù)運(yùn)行狀況數(shù)據(jù)建立任務(wù)畫(huà)像，監(jiān)控任務(wù)資源消耗趨勢(shì)，定位任務(wù)是否異常。再結(jié)合任務(wù)產(chǎn)出數(shù)據(jù)的訪(fǎng)問(wèn)熱度，還可以反饋給調(diào)度系統(tǒng)動(dòng)態(tài)調(diào)整任務(wù)優(yōu)先級(jí)等。Grace 架構(gòu)上述示例中使用到的數(shù)據(jù)都是通過(guò) Grace 收集的。Grace 是餓了么大數(shù)據(jù)團(tuán)隊(duì)開(kāi)發(fā)的應(yīng)用，主要用于監(jiān)控分析線(xiàn)上 MR/Spark 任務(wù)運(yùn)行數(shù)據(jù)，監(jiān)控運(yùn)行中隊(duì)列及任務(wù)明細(xì)及匯總數(shù)據(jù)。邏輯架構(gòu)如下圖：Grace 邏輯架構(gòu)Grace 是通過(guò) Spark Streaming 實(shí)現(xiàn)的

14、，通過(guò)消費(fèi) Kafka 中存儲(chǔ)的已完成 MR 任務(wù)的 jhist 文件或 Spark 任務(wù)的 eventlog 路徑，從 HDFS 對(duì)應(yīng)位置獲取任務(wù)運(yùn)行歷史數(shù)據(jù)，解析后得到 MR/Spark 任務(wù)的明細(xì)數(shù)據(jù)。再根據(jù)這些數(shù)據(jù)進(jìn)行一定的聚合分析，得到任務(wù)級(jí)別，Job 級(jí)別，Stage 級(jí)別的匯總信息。最后通過(guò)定制化的 Dr-Elephant 系統(tǒng)對(duì)任務(wù)明細(xì)數(shù)據(jù)通過(guò)啟發(fā)式算法進(jìn)行分析，從而給用戶(hù)一些直觀(guān)化的優(yōu)化提示。對(duì)于 Dr-Elephant，我們也做了定制化的變動(dòng)，比如將其作為 Grace 體系的一個(gè)組件打包依賴(lài)。從單機(jī)部署服務(wù)的模式變成了分布式實(shí)時(shí)解析模式。將其數(shù)據(jù)源切換為 Grace 解析到的任務(wù)明細(xì)數(shù)據(jù)。增加每個(gè)任務(wù)的 ActionId 跟蹤鏈路信息，優(yōu)化 Spark