本文主要介紹餓了么大數(shù)據(jù)團(tuán)隊(duì)如何通過對(duì)計(jì)算引擎入口的統(tǒng)一，降低用戶接入門檻;如何讓用戶自助分析任務(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é)離線&實(shí)時(shí) Infra 和平臺(tái)工具開發(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ù)集群用戶每天面臨的各種問題。

引擎入口統(tǒng)一

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

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

從用戶角度來說，普通用戶對(duì)此沒有較強(qiáng)的辨識(shí)能力，學(xué)習(xí)成本會(huì)比較高。

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

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

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

 

 

 

 

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

功能模塊

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

 

 

Dispatcher 功能模塊

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

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

邏輯架構(gòu)

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

 

 

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

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

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

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

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

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

• 部署成本低，客戶端可通過 JDBC 方式快速接入。

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

• 降級(jí)模塊提高任務(wù)成功率。

• 各引擎負(fù)載均衡。

• 引擎可擴(kuò)展。

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

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

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

SQL 畫像

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

 

 

SQL 路由模塊

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

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

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

• 各類 Join 次數(shù)

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

• 聚合復(fù)雜度

• 過濾條件

• ……

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

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

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

 

 

SQL 解析示例

從直觀的理解上我們知道，讀入數(shù)據(jù)量對(duì)于引擎的選擇是很重要的。比如當(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)行測(cè)試，采用基于規(guī)則的辦法進(jìn)行路由。

執(zhí)行過程中記錄好每一次查詢的 SQL 畫像數(shù)據(jù)，執(zhí)行引擎，降級(jí)鏈路等數(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é)，以及失敗降級(jí)環(huán)節(jié)，每天總體成功率為 99.95% 以上，整體 PT90 值為 300 秒左右。

目前 Presto 承擔(dān)了 Ad Hoc 查詢的 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)。還可以幫助用戶自助分析任務(wù)運(yùn)行失敗原因，任務(wù)運(yùn)行性能分析等。

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

Grace 使用場(chǎng)景

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

當(dāng)經(jīng)常有用戶找你說，我的任務(wù)為什么跑失敗了?我的任務(wù)為什么跑的這么慢?我的任務(wù)能調(diào)一下優(yōu)先級(jí)么?不要跟我說看日志，我看不懂。我想大家內(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)用戶申請(qǐng)計(jì)算資源時(shí)，到底應(yīng)該給他們分配多少資源?當(dāng)用戶申請(qǐng)?zhí)岣呷蝿?wù)優(yōu)先級(jí)時(shí)如何用數(shù)據(jù)說話，明確優(yōu)先級(jí)到底應(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ù)級(jí)別的數(shù)據(jù)不方便展示。

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

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

 

 

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

 

 

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

任務(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ù)情況

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

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

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

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

 

 

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

任務(wù)性能分析

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

 

 

任務(wù)性能分析

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

 

 

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

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

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

 

 

失敗原因自助分析

除此之外，我們還可以實(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ù)資源消耗趨勢(shì)，定位任務(wù)是否異常。再結(jié)合任務(wù)產(chǎn)出數(shù)據(jù)的訪問熱度，還可以反饋給調(diào)度系統(tǒng)動(dòng)態(tài)調(diào)整任務(wù)優(yōu)先級(jí)等。

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 對(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í)別的匯總信息。

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

對(duì)于 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)等。

總結(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è)，是本次分享的主題。

作者：陳凱明 來源：DBAplus社群

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

標(biāo)簽： isp ssl 大數(shù)據(jù) 大數(shù)據(jù)基礎(chǔ) 大數(shù)據(jù)平臺(tái) 權(quán)限 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。