當前位置︰首頁 > 新聞資訊 > 正文

eBay Hadoop/Spark 自助分析系統實踐2019-07-18 09:56:25 | 編輯︰hely | 查看︰ | 評論︰0

eBay 一直倡導數據驅動業務。數據處理和分析的及時與深入與否,直接影響了業務的效益。因此,一站式的工作負載自助分析工具對數據處理工程師和平台的運維人員顯得尤為重要。

來源︰eBay技術薈

eBay 一直倡導數據驅動業務。數據處理和分析的及時與深入與否,直接影響了業務的效益。因此,一站式的工作負載自助分析工具對數據處理工程師和平台的運維人員顯得尤為重要。

“為什麼處理作業要比平時運行得慢?”

“最近有哪些作業失敗了?它們為什麼失敗?”

“哪個作業佔用了平台最多的資源?”

”平台上是不是還能支撐更多的工作負載?“

這是數據處理工程師以及分析師和數據平台管理員之間經常發生的對話。我們亟需一個智能化的工作負載管理引擎提供自助分析體驗使得管理員能輕松駕馭這些日常的問題,從而達到︰

♦ 幫助用戶更快地進行應用程序排錯

♦ 對于應用程序的性能問題,可以很快給出有效建議

♦ 通過應用程序優化,提高集群的整體利用率

在一個多租戶的 Hadoop 環境中,首要解決的問題是如何有效實現系統資源的隔離和共享,並能最大化利用系統的資源。在提供 Workload Analytics System 能力之前,我們嘗試了其他各種方法來解決集群的性能問題,但終究無法讓我們深入了解集群。Workload Analytics System 為我們解決問題提供了詳細的數據支撐,細粒度的作業、平台指標監控 - 給管理員、開發者、業務運維工程師提供近乎實時的平台運行洞察。

下面將從 集群資源監控 和 用戶作業監控 兩方面入手詳細闡述 eBay 大數據團隊行之有效的解決方案。

集群資源監控

首先,Workload Analytics System提供的實時資源監控可以讓管理員和普通用戶了解整個集群的資源使用狀況,或者是對應的資源池的資源使用情況,以便了解到集群通常的的閑置或者繁忙時段,那麼相關的作業調度可以做適當的調整。在閑置時間的調度,可以讓計算資源得到該有的保證;在繁忙時段的資源調度會出現大量的爭用情況。集群的普通用戶偶爾會發現自己的批處理作業似乎運行變慢了,首先要查看的是資源的調度情況是不是有變壞的跡象,然後再去查看是不是有其他的原因導致。

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

 

 

每個重要的集群都有資源的使用視圖,不用的資源池佔用的集群資源以不同的顏色標注,用戶也可以選擇不同粒度的資源池查看。在資源的使用視圖上(Memory Usage)任意選擇一個點,在下方的列表中就會顯示在這個時間片段內使用資源最多的作業有哪些,默認是 5 分鐘的間隔,用戶可以根據自己的作業運行時長選擇不同的時間段查看。

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

在這個資源使用視圖下方,Workload Analytics System還提供了一些直觀的準實時資源等待分析,包括有多少應用在等待被提交到 YARN; 對于已經提交在運行或者還未提交應用,還有多少資源請求尚未被提供。

 

 

總之,在 Workload Analyitics System 的資源使用視圖中,管理員可以概覽資源的實時使用狀況,以及那些應用有可能過度佔用了集群的資源,對于這些應用,我們可以快速進入它們的詳細資源使用分析,以確定相應的優化方案,這部分我們稍後會有詳細介紹。

用戶作業監控

除了提供集群的資源使用分析外,Workload Analytics System 方便了用戶的自助式排錯或者優化體驗,對作業的運行數據提供了全方位的分析,可以快速診斷作業的錯誤或者性能問題。

在 eBay 內部,ETL 的作業仍然佔用了絕對多數的資源,而且從我們長期的監測結果來看,Memory 是系統的瓶頸所在,所以我們目前采用了Memory*Second來描述具體的資源。不管是 MapReduce 框架(包含 Hive),還是 Spark 作業,都是從 YARN 來分配資源的,每一個作業都有對應的資源(Memory)請求描述,已經佔用資源的總體時間。

Workload Analytics System 的作業儀表盤是一個自助式的程序性能管理門戶,它從管理員或者用戶對作業的錯誤和性能問題出發,為開發人員提供了用于故障排除和優化應用程序性能的統一視圖。這個統一視圖,使大多數開發者能夠在一個地方或者相關的應用信息,性能建議,以便開發人員輕松快速的提高應用性能,有效利用集群的資源,提供更好的多租戶管理使用體驗。如圖例:

 

 

從問題出發,作業儀表盤分析了用戶過去一天總共有多少應用失敗,有多少應用佔用了絕大多數的集群資源,有多少應用向系統申請的資源要遠比實際使用的要多,有多少應用有嚴重的作業性能問題。Workload Analytics System 還呈現了資源使用的趨勢圖,以了解過去一段時間的作業優化對資源使用的優化結果,或者資源的異常使用情況,並作出下一步的詳細分析。下面就作業錯誤診斷、作業性能分析、作業資源優化三個方面詳細闡述。

【作業錯誤診斷】

Hadoop 和 Spark 的分布式作業處理提供了大規模數據處理的便利性,但與此同時也給作業診斷帶來了一定的挑戰。分布式計算的任務被分配到了大量不同的計算節點上,任務運行時的作業也都分不到不同的節點上。一旦發生應用程序的任務錯誤,分布式框架並沒有把任務的運行日志集中進行分析。用戶如果要知道一些具體的原因,通常要查看大量的任務運行日志,以確定問題的錯誤根源。作業錯誤診斷功能旨在提供快速的錯誤分析能力,盡量避免讓用戶去查看大量的原始日志信息,從而加快任務排錯。如圖例︰

 

 

從作業儀表盤的錯誤應用視圖出發,可以詳細的羅列所有問題作業,包含它們的作業名,用戶名(包括個人用戶或者批處理賬號), 作業使用的資源池名稱,等等。

 

 

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

【作業性能分析】

嚴重的作業性能問題不僅影響了作業自身的 SLA,同時也會影響集群或者同一資源池中其他作業的運行,或者是整個集群的性能,比如說作業的過量 RPC 操作降低了 NN 的 RPC 吞吐。在作業儀表盤視圖中,Workload Analytics System 也突出了性能問題的應用,進入之後,我們為用戶高亮了所有有待改善的應用程序列表,以及性能問題的嚴重性。如圖例︰

 

 

我們默認只顯示了包含有嚴重級別以上的提示的作業,進入每一個具體的嚴重問題之後,Workload Analytics System 顯示了詳細的性能問題類別以及優化建議,同時給了了對應優化項的具體說明。

 

 

【作業資源優化】

在作業儀表盤中另外兩個問題都和集群的資源使用相關,對每個應用,Workload Analytics System 都計算了它們的 HCU 消耗,包括實際使用的 HCU 消耗,以及申請的 HCU。

默認情況下,對于絕對資源使用超過集群 0.1% 的作業,我們認為是過大的,這類作業是需要做針對性的優化的,比如是不是作業的任務數太多,任務的請求的資源過多,或者大量任務的執行時間過長。集群是一個多租戶環境,每天都大幾萬個批處理在執行,任何一些大資源佔用作業的運行都可能會影響集群的多租戶能力提供。

 

 

對于絕對資源的使用我們要嚴格控制,這類作業通常要在業務邏輯上進行優化;另外我們也要控制資源的浪費,就是申請的 HCU 必須和實際的 HCU 使用值相近,因為 YARN 的資源分配是按照申請值來分配的,浪費的越多會造成系統的吞吐下降。默認情況下,對于資源的浪費比例超過 40%,並且浪費的絕對值超過集群整體萬分之五的作業也是需要用戶去做針對性優化的。

綜上,Workload Analytics System 是我們追求卓越運營的必然產物,一方面增強了平台用戶體驗,自動排錯診斷,性能預警;另一方面也降低了集群資源使用浪費的現象。

上一篇︰當前區塊鏈技術存在的八大問題 無監督學習是深度學習的未來!Facebook首席科學家呼吁加強對無監督學習的研究下一篇︰

公眾平台

搜索"raincent"或掃描下面的二維碼

?