來源：eBay技術(shù)薈

eBay 一直倡導(dǎo)數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)。數(shù)據(jù)處理和分析的及時(shí)與深入與否，直接影響了業(yè)務(wù)的效益。因此，一站式的工作負(fù)載自助分析工具對(duì)數(shù)據(jù)處理工程師和平臺(tái)的運(yùn)維人員顯得尤為重要。

“為什么處理作業(yè)要比平時(shí)運(yùn)行得慢?”

“最近有哪些作業(yè)失敗了?它們?yōu)槭裁词��?”

“哪個(gè)作業(yè)占用了平臺(tái)最多的資源?”

”平臺(tái)上是不是還能支撐更多的工作負(fù)載?“

這是數(shù)據(jù)處理工程師以及分析師和數(shù)據(jù)平臺(tái)管理員之間經(jīng)常發(fā)生的對(duì)話。我們亟需一個(gè)智能化的工作負(fù)載管理引擎提供自助分析體驗(yàn)使得管理員能輕松駕馭這些日常的問題，從而達(dá)到：

♦ 幫助用戶更快地進(jìn)行應(yīng)用程序排錯(cuò)

♦ 對(duì)于應(yīng)用程序的性能問題，可以很快給出有效建議

♦ 通過應(yīng)用程序優(yōu)化，提高集群的整體利用率

在一個(gè)多租戶的 Hadoop 環(huán)境中，首要解決的問題是如何有效實(shí)現(xiàn)系統(tǒng)資源的隔離和共享，并能最大化利用系統(tǒng)的資源。在提供 Workload Analytics System 能力之前，我們嘗試了其他各種方法來解決集群的性能問題，但終究無法讓我們深入了解集群。Workload Analytics System 為我們解決問題提供了詳細(xì)的數(shù)據(jù)支撐，細(xì)粒度的作業(yè)、平臺(tái)指標(biāo)監(jiān)控 - 給管理員、開發(fā)者、業(yè)務(wù)運(yùn)維工程師提供近乎實(shí)時(shí)的平臺(tái)運(yùn)行洞察。

下面將從 集群資源監(jiān)控 和 用戶作業(yè)監(jiān)控 兩方面入手詳細(xì)闡述 eBay 大數(shù)據(jù)團(tuán)隊(duì)行之有效的解決方案。

集群資源監(jiān)控

首先，Workload Analytics System提供的實(shí)時(shí)資源監(jiān)控可以讓管理員和普通用戶了解整個(gè)集群的資源使用狀況，或者是對(duì)應(yīng)的資源池的資源使用情況，以便了解到集群通常的的閑置或者繁忙時(shí)段，那么相關(guān)的作業(yè)調(diào)度可以做適當(dāng)?shù)恼{(diào)整。在閑置時(shí)間的調(diào)度，可以讓計(jì)算資源得到該有的保證;在繁忙時(shí)段的資源調(diào)度會(huì)出現(xiàn)大量的爭(zhēng)用情況。集群的普通用戶偶爾會(huì)發(fā)現(xiàn)自己的批處理作業(yè)似乎運(yùn)行變慢了，首先要查看的是資源的調(diào)度情況是不是有變壞的跡象，然后再去查看是不是有其他的原因?qū)е隆?/p>

對(duì)于集群的管理員或者一個(gè)資源池的所屬者，他不僅僅要知道集群或者隊(duì)列的整體繁忙情況，通常也要針對(duì)繁忙的情況給集群或者隊(duì)列的使用者合理的說明，哪些作業(yè)在某個(gè)時(shí)間段占用了集群絕大多數(shù)的資源。Workload Analytics System 提供了深度資源使用分析能力，可以讓管理員很快地獲取這些信息。如圖例：

 

 

每個(gè)重要的集群都有資源的使用視圖，不用的資源池占用的集群資源以不同的顏色標(biāo)注，用戶也可以選擇不同粒度的資源池查看。在資源的使用視圖上(Memory Usage)任意選擇一個(gè)點(diǎn)，在下方的列表中就會(huì)顯示在這個(gè)時(shí)間片段內(nèi)使用資源最多的作業(yè)有哪些，默認(rèn)是 5 分鐘的間隔，用戶可以根據(jù)自己的作業(yè)運(yùn)行時(shí)長(zhǎng)選擇不同的時(shí)間段查看。

所有的資源表述都遵循HCU(Hadoop Compute Unit，1 HCU=1 GB*Sec)的定義。每個(gè)集群在某個(gè)時(shí)間段的資源總量可以用 HCU 來衡量，每個(gè)作業(yè)運(yùn)行所消耗的資源也可以用 HCU 來衡量。

在這個(gè)資源使用視圖下方，Workload Analytics System還提供了一些直觀的準(zhǔn)實(shí)時(shí)資源等待分析，包括有多少應(yīng)用在等待被提交到 YARN; 對(duì)于已經(jīng)提交在運(yùn)行或者還未提交應(yīng)用，還有多少資源請(qǐng)求尚未被提供。

 

 

總之，在 Workload Analyitics System 的資源使用視圖中，管理員可以概覽資源的實(shí)時(shí)使用狀況，以及那些應(yīng)用有可能過度占用了集群的資源，對(duì)于這些應(yīng)用，我們可以快速進(jìn)入它們的詳細(xì)資源使用分析，以確定相應(yīng)的優(yōu)化方案，這部分我們稍后會(huì)有詳細(xì)介紹。

用戶作業(yè)監(jiān)控

除了提供集群的資源使用分析外，Workload Analytics System 方便了用戶的自助式排錯(cuò)或者優(yōu)化體驗(yàn)，對(duì)作業(yè)的運(yùn)行數(shù)據(jù)提供了全方位的分析，可以快速診斷作業(yè)的錯(cuò)誤或者性能問題。

在 eBay 內(nèi)部，ETL 的作業(yè)仍然占用了絕對(duì)多數(shù)的資源，而且從我們長(zhǎng)期的監(jiān)測(cè)結(jié)果來看，Memory 是系統(tǒng)的瓶頸所在，所以我們目前采用了Memory*Second來描述具體的資源。不管是 MapReduce 框架(包含 Hive)，還是 Spark 作業(yè)，都是從 YARN 來分配資源的，每一個(gè)作業(yè)都有對(duì)應(yīng)的資源(Memory)請(qǐng)求描述，已經(jīng)占用資源的總體時(shí)間。

Workload Analytics System 的作業(yè)儀表盤是一個(gè)自助式的程序性能管理門戶，它從管理員或者用戶對(duì)作業(yè)的錯(cuò)誤和性能問題出發(fā)，為開發(fā)人員提供了用于故障排除和優(yōu)化應(yīng)用程序性能的統(tǒng)一視圖。這個(gè)統(tǒng)一視圖，使大多數(shù)開發(fā)者能夠在一個(gè)地方或者相關(guān)的應(yīng)用信息，性能建議，以便開發(fā)人員輕松快速的提高應(yīng)用性能，有效利用集群的資源，提供更好的多租戶管理使用體驗(yàn)。如圖例:

 

 

從問題出發(fā)，作業(yè)儀表盤分析了用戶過去一天總共有多少應(yīng)用失敗，有多少應(yīng)用占用了絕大多數(shù)的集群資源，有多少應(yīng)用向系統(tǒng)申請(qǐng)的資源要遠(yuǎn)比實(shí)際使用的要多，有多少應(yīng)用有嚴(yán)重的作業(yè)性能問題。Workload Analytics System 還呈現(xiàn)了資源使用的趨勢(shì)圖，以了解過去一段時(shí)間的作業(yè)優(yōu)化對(duì)資源使用的優(yōu)化結(jié)果，或者資源的異常使用情況，并作出下一步的詳細(xì)分析。下面就作業(yè)錯(cuò)誤診斷、作業(yè)性能分析、作業(yè)資源優(yōu)化三個(gè)方面詳細(xì)闡述。

【作業(yè)錯(cuò)誤診斷】

Hadoop 和 Spark 的分布式作業(yè)處理提供了大規(guī)模數(shù)據(jù)處理的便利性，但與此同時(shí)也給作業(yè)診斷帶來了一定的挑戰(zhàn)。分布式計(jì)算的任務(wù)被分配到了大量不同的計(jì)算節(jié)點(diǎn)上，任務(wù)運(yùn)行時(shí)的作業(yè)也都分不到不同的節(jié)點(diǎn)上。一旦發(fā)生應(yīng)用程序的任務(wù)錯(cuò)誤，分布式框架并沒有把任務(wù)的運(yùn)行日志集中進(jìn)行分析。用戶如果要知道一些具體的原因，通常要查看大量的任務(wù)運(yùn)行日志，以確定問題的錯(cuò)誤根源。作業(yè)錯(cuò)誤診斷功能旨在提供快速的錯(cuò)誤分析能力，盡量避免讓用戶去查看大量的原始日志信息，從而加快任務(wù)排錯(cuò)。如圖例：

 

 

從作業(yè)儀表盤的錯(cuò)誤應(yīng)用視圖出發(fā)，可以詳細(xì)的羅列所有問題作業(yè)，包含它們的作業(yè)名，用戶名(包括個(gè)人用戶或者批處理賬號(hào)), 作業(yè)使用的資源池名稱，等等。

 

 

進(jìn)入作業(yè)的具體信息頁面，Workload Analytics System 展現(xiàn)了最有可能的直接錯(cuò)誤原因。誠(chéng)然，這個(gè)錯(cuò)誤診斷能力并不能完全分析出所有的錯(cuò)誤直接原因，比如，應(yīng)用經(jīng)常會(huì)出現(xiàn)的 TimeoutException 或者 InterruptedException，但我們希望 95% 的錯(cuò)誤應(yīng)用都可以通過錯(cuò)誤診斷功能直接找到原因，還有一些錯(cuò)誤，還需要用戶綜合多方面的日志信息，進(jìn)行線下分析。高度自動(dòng)的錯(cuò)誤診斷能力著實(shí)降低了用戶排錯(cuò) Hadoop/Spark 任務(wù)的門檻，也極大壓縮了錯(cuò)誤診斷的時(shí)間，加快了應(yīng)用的上線的頻率。

【作業(yè)性能分析】

嚴(yán)重的作業(yè)性能問題不僅影響了作業(yè)自身的 SLA，同時(shí)也會(huì)影響集群或者同一資源池中其他作業(yè)的運(yùn)行，或者是整個(gè)集群的性能，比如說作業(yè)的過量 RPC 操作降低了 NN 的 RPC 吞吐。在作業(yè)儀表盤視圖中，Workload Analytics System 也突出了性能問題的應(yīng)用，進(jìn)入之后，我們?yōu)橛脩舾吡亮怂�有有待改善的�?yīng)用程序列表，以及性能問題的嚴(yán)重性。如圖例：

 

 

我們默認(rèn)只顯示了包含有嚴(yán)重級(jí)別以上的提示的作業(yè)，進(jìn)入每一個(gè)具體的嚴(yán)重問題之后，Workload Analytics System 顯示了詳細(xì)的性能問題類別以及優(yōu)化建議，同時(shí)給了了對(duì)應(yīng)優(yōu)化項(xiàng)的具體說明。

 

 

【作業(yè)資源優(yōu)化】

在作業(yè)儀表盤中另外兩個(gè)問題都和集群的資源使用相關(guān)，對(duì)每個(gè)應(yīng)用，Workload Analytics System 都計(jì)算了它們的 HCU 消耗，包括實(shí)際使用的 HCU 消耗，以及申請(qǐng)的 HCU。

默認(rèn)情況下，對(duì)于絕對(duì)資源使用超過集群 0.1% 的作業(yè)，我們認(rèn)為是過大的，這類作業(yè)是需要做針對(duì)性的優(yōu)化的，比如是不是作業(yè)的任務(wù)數(shù)太多，任務(wù)的請(qǐng)求的資源過多，或者大量任務(wù)的執(zhí)行時(shí)間過長(zhǎng)。集群是一個(gè)多租戶環(huán)境，每天都大幾萬個(gè)批處理在執(zhí)行，任何一些大資源占用作業(yè)的運(yùn)行都可能會(huì)影響集群的多租戶能力提供。

 

 

對(duì)于絕對(duì)資源的使用我們要嚴(yán)格控制，這類作業(yè)通常要在業(yè)務(wù)邏輯上進(jìn)行優(yōu)化;另外我們也要控制資源的浪費(fèi)，就是申請(qǐng)的 HCU 必須和實(shí)際的 HCU 使用值相近，因?yàn)?YARN 的資源分配是按照申請(qǐng)值來分配的，浪費(fèi)的越多會(huì)造成系統(tǒng)的吞吐下降。默認(rèn)情況下，對(duì)于資源的浪費(fèi)比例超過 40%，并且浪費(fèi)的絕對(duì)值超過集群整體萬分之五的作業(yè)也是需要用戶去做針對(duì)性優(yōu)化的。

綜上，Workload Analytics System 是我們追求卓越運(yùn)營(yíng)的必然產(chǎn)物，一方面增強(qiáng)了平臺(tái)用戶體驗(yàn)，自動(dòng)排錯(cuò)診斷，性能預(yù)警;另一方面也降低了集群資源使用浪費(fèi)的現(xiàn)象。

標(biāo)簽： Hadoop Spark 

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