內(nèi)容來源:本文轉(zhuǎn)載自戰(zhàn)略合作伙伴 DBAplus社群,微信公眾號(ID:dbaplus)
責(zé)編 | 菱酒
第 700 篇技術(shù)好文:5350字 | 14 分鐘閱讀
陳凱明,具有多年從事大數(shù)據(jù)基礎(chǔ)架構(gòu)工作經(jīng)驗(yàn)。目前擔(dān)任餓了么數(shù)據(jù)平臺研發(fā)團(tuán)隊(duì)資深數(shù)據(jù)工程師,主要負(fù)責(zé)餓了么離線平臺及底層工具開發(fā)。 餓了么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ù)等。 01 引擎入口統(tǒng)一 _____ 目前在餓了么對外提供的查詢引擎主要有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%流量。 02 充分利用集群本身數(shù)據(jù) _____ 餓了么大數(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)目就是在這方面的一個示例。 對集群任務(wù)運(yùn)行狀況詳細(xì)數(shù)據(jù)沒有明確認(rèn)識的話,很容易當(dāng)出現(xiàn)問題時陷入困境,從監(jiān)控看到集群異常后將無法繼續(xù)進(jìn)一步快速定位問題。 當(dāng)經(jīng)常有用戶找你說,我的任務(wù)為什么跑失敗了?我的任務(wù)為什么跑的這么慢?我的任務(wù)能調(diào)一下優(yōu)先級么?不要跟我說看日志,我看不懂。我想大家內(nèi)心都是崩潰的。 當(dāng)監(jiān)控發(fā)出NameNode異常抖動,網(wǎng)絡(luò)飚高,block創(chuàng)建增加,block創(chuàng)建延時增大等告警時,應(yīng)該如何快速定位集群運(yùn)行的異常任務(wù)? 當(dāng)監(jiān)控發(fā)出集群中Pending的任務(wù)太多時,用戶反饋任務(wù)大面積延遲時,如何快速找到問題根本原因? 當(dāng)用戶申請計(jì)算資源時,到底應(yīng)該給他們分配多少資源?當(dāng)用戶申請?zhí)岣呷蝿?wù)優(yōu)先級時如何用數(shù)據(jù)說話,明確優(yōu)先級到底應(yīng)該調(diào)到多少?當(dāng)用戶只管上線不管下線任務(wù)時,我們?nèi)绾味ㄎ荒男┤蝿?wù)是不再需要的? 還有,如何通過實(shí)時展示各BU計(jì)算資源消耗,指定BU中各用戶計(jì)算資源消耗,占BU資源比例。以及如何從歷史數(shù)據(jù)中分析各BU任務(wù)數(shù),資源使用比例,BU內(nèi)部各用戶的資源消耗,各任務(wù)的資源消耗等。 以下示例展示一些Grace產(chǎn)出數(shù)據(jù)圖表。有關(guān)BU、用戶、任務(wù)級別的數(shù)據(jù)不方便展示。 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)等。 03 總結(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è),是本次分享的主題。 Q:能簡單介紹一下調(diào)度系統(tǒng)嗎?管理上萬個任務(wù)不容易。 A:調(diào)度系統(tǒng)說起來挺復(fù)雜的。就提幾個關(guān)鍵點(diǎn)吧,一個是任務(wù)之間的依賴,一個是血緣關(guān)系,一個是任務(wù)與實(shí)例,還有集群反壓、分布式調(diào)度、底層環(huán)境統(tǒng)一。 其中血緣關(guān)系應(yīng)該是必須的,因?yàn)楫?dāng)你集群規(guī)模大了之后,用戶配置任務(wù)時根本無法完整地添加依賴。 通過血緣系統(tǒng),對任務(wù)進(jìn)行解析,當(dāng)用戶配置好新任務(wù)后,自動推薦前置依賴,保證任務(wù)有序運(yùn)行。 Q:如何得出集群的每天讀寫規(guī)模?Hadoop有接口? A:集群讀寫規(guī)模是通過前面介紹的Grace收集的。因?yàn)槲覀儠治雒總€mr task或者spark task的HDFS數(shù)據(jù)讀寫量。還包括spill到磁盤的數(shù)據(jù)量、shuffle write、shuffle read數(shù)據(jù)量,以及每個任務(wù)的GBHour信息。 其實(shí)這些數(shù)據(jù)你通過YARN或者Spark的WEB UI頁面都能看到,你需要做的只是實(shí)時地去解析,收集這些數(shù)據(jù)。這也是本次分享介紹中提到的,從數(shù)據(jù)角度運(yùn)維集群。 除了業(yè)務(wù)數(shù)據(jù)之外,集群本身產(chǎn)生的數(shù)據(jù)也很有價值。 Q:這個就是從大數(shù)據(jù)本身產(chǎn)出的數(shù)據(jù)來精細(xì)化運(yùn)維集群吧? A:是的。如果你也從事數(shù)據(jù)架構(gòu)方向的話,可以回想一下自己每天的工作內(nèi)容。我們只不過是把人肉分析變成自動化,然后再加入一些實(shí)時性。 https://m./live/channel/channelPage/2000000411799213.html |
|