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是我們追求卓越運營的必然產物，一方面增強了平臺用戶體驗，自動排錯診斷，性能預警；另一方面也降低了集羣資源使用浪費的現象。
本文轉載自公衆號eBay技術薈（ID：eBayTechRecruiting）。
原文鏈接：