網易大數據智能運維平臺 EasyEagle

作者：范欣欣 2023-10-10 07:43:15

本次分享的主題是網易數帆的大數據智能運維平臺 EasyEagle。EasyEagle 是一個大數據智能運維平臺服務，智能運維主要是為了監控、分析與解決大數據平臺在使用過程中遇到的諸多問題。在長時間的大數據研發及運維實踐中，我們發現大數據組件以及任務在治理運維中存在許多問題。

一、大數據集群現狀

首先來介紹一下 EasyEagle 誕生的背景。

1、Hadoop 大數據生態圈現狀

EasyEagle 是一個大數據智能運維平臺服務，智能運維主要是為了監控、分析與解決大數據平臺在使用過程中遇到的諸多問題。在長時間的大數據研發及運維實踐中，我們發現大數據組件以及任務在治理運維中存在許多問題，可以總結為四個不透明：

首先是服務健康不透明。比如 HDFS、Hive 等這類組件服務，他們的健康情況是不透明的。主要表現為三個方面，第一是組件服務是否真正可用是不透明的，很多公司會使用進程監控來看服務是不是異常了，但實際上很多情況下進程變成了僵尸進程，看起來進程還在，但是服務已經不可用了。第二是服務雖然可用，但實際上存在健康風險，可能運行一段時間后就不能正常工作了。第三是服務組件出現了異常，如何快速的定位、分析以及解決。這三個方面問題在原生的 Hadoop 生態里目前是沒有提供解決方案的。
第二是計算資源不透明。首先大數據集群的隊列資源水位怎么樣是不清楚的，哪些隊列的資源使用率高，哪些空閑。其二是任務的真實資源利用率是怎么樣的不清楚，真實資源利用率指的是任務實際執行過程中使用的資源量與任務申請資源量的比值，有可能申請的多但使用的很少。其三，假如隊列的資源水位比較高，那么哪些任務的資源申請最多，這些任務是否真正需要申請這么多資源，這部分信息是拿不到的。這些計算資源的不透明導致在集群運行時，出現了非常普遍的資源浪費以及任務運行效率偏低。
第三是任務運行不透明，指的是Spark任務、Hive任務或Impala任務運行過程中的細節信息不透明。比如某個Spark任務今天比昨天執行的耗時長了很多，那到底耗時長在哪里，現在實際是沒有的。另外，集群中跑了幾千個或上萬個任務，這其中哪些任務可以進行參數優化提高運行效率，當前系統并沒有提供這些信息。
最后是存儲資源不透明。在實際的運維實踐中，包括跟客戶的溝通過程中發現，很多客戶反饋現在集群容量水位比較高，已經到百分之七八十了。這種情況下被動的解決方案是擴容機器，但這是要增加企業成本的，更加主動的解決方案是進行存儲資源治理，而治理的前提是搞清楚到底哪些表的存儲增長比較快，這些表的增長是否合理。另外，集群中一定是有很多無用文件的，這些文件是可以直接清理的，哪些文件是無用文件目前也是拿不到這些信息，支持我們做下一步的決策。除此之外，還有比如集群小文件比較多，但是又不知道哪些表的小文件比較多，小文件的平均大小到底小到什么程度。這些都屬于存儲資源的不透明。

接下來分別用幾個案例展開講解這四個不透明。

2、服務健康不透明

上圖是 HDFS 的 NameNode 的排隊時間監控圖，可以看到在10點40左右，有一波排隊時間大幅增加，到12點才下去。這個時間段所有的任務請求在 HDFS 都會出現排隊，一旦排隊時間達到秒級，很多 Spark 任務的 Driver 階段因為有大量 rename 操作就會卡頓，會導致 Spark 任務耗時延遲，這樣的 RPC 異常使得 SLA 沒辦法得到保證，危險性是非常大的，尤其對于底層 HDFS 服務一旦異常，所有上層任務比如 Hive 任務、Spark 任務都會受到影響。

現在知道了這個現象，但還不知道具體原因，如果是某個任務執行異常命令引起的話，人工定位可能會花費幾個小時甚至幾天，難度非常大，影響也非常大，對于我們來說是非常致命的問題。

因此服務健康不透明，對保障性和穩定性來說是一個非常大的隱患。

3、計算資源不透明

上面這張圖表示一個隊列的資源使用情況，綠線表示資源的申請量已經打滿了，達到百分之百了。

這會引出兩個問題，第一個問題是因為申請不到資源，新增的任務沒辦法提交。第二個是已經提交的任務，不斷申請 Container 的時候會產生競爭，因為資源已經沒了，只能等待，任務延遲增大，最終可能導致產出不及預期。

針對上述問題，因為隊列容量已經滿了，通常會采購機器，但是采購機器會增加成本。實際上，下面這條藍線是隊列的實際資源使用率，可以看到大概在50%左右，表示申請了100核，可能只使用了50核，而申請了100核就把隊列資源申請滿了，這時候任務提交不上來。但是從物理機的層面來看，資源使用率只有50%或者更低。這就是計算資源不透明的現象。

4、任務運行不透明

上圖中顯示的任務執行了7.9個小時，大家會問這個任務執行真的需要這么長時間嗎？到底哪個階段需要這么長時間？

大家知道離線任務，或者 Impala 任務的執行是分很多階段的，它的鏈路非常長。七八個小時到底花在哪個階段了，實際上沒有開源工具來看，這就是任務運行不透明的現象。

5、存儲資源不透明

上圖中左側，從去年8?份到10?份，集群?件數快速增?，會導致 HDFS 元數據量增??常快， NameNode 內存急速往上飚，會出現嚴重的 GC，或其他?些不穩定的因素。這個時候就需要知道到底是哪個業務、哪個表增長比較快，這樣才能針對性地去處理問題。包括小文件也是一樣的，增長這么多，到底有多少小文件是不清楚的。這就是存儲資源不透明。

針對上述問題，第一件事情是要把不透明變成透明。更近一步，是在透明化的基礎上，分析診斷服務健康以及任務健康、分析治理計算（存儲）資源等。這正是 EasyEagle 要做的工作。

二、產品核心能力介紹

接下來就將對 EasyEagle 的核心能力進行介紹。

EasyEagle 是網易數帆國產大數據基礎平臺 NDH 的一個產品。上圖是 NDH 的架構圖，紅色的是原生的組件；藍色組件，包括 HDFS、Impala、Spark、Flink 等，我們做了大量的功能增強；綠色的部分，包括 EasyEagle、湖倉一體、Arctic，是自研產品服務。

EasyEagle 主要是為了解決剛才講的四個不透明問題，并在此基礎上提出相應的分析診斷以及治理的策略，為 NDH 平臺高效健康運行保駕護航。它的核心競爭力是基于大量真實客戶業務經驗和實踐經驗所形成的方法論。

EasyEagle 包括四個模塊，分別針對剛才講的四個不透明。

第一個模塊稱為服務健康的監控診斷，針對服務健康不透明的問題。重點包括三個功能：第一個功能是服務狀態的探針，解決服服務不可用的問題；第二個是服務智能巡檢，解決服務健康是否存在風險，以及應該如何去解決的問題；第三個是異常智能診斷，解決的是服務發生異常后，快速幫忙分析出本質原因，快速止損，這是服務健康診斷的三個能力。

第二個模塊是計算資源監控治理。包括計算、隊列、任務三個層面的資源監控分析，解決從不透明變成透明的問題。資源空閑隊列、資源浪費隊列的治理，這兩項是在透明化之上進行的進一步分析，提出相應的資源治理方法論和產品形態。

第三個模塊是任務全鏈路診斷優化，對應任務運行不透明問題。第一個是集群任務執行的概況；第二個是任務全鏈路監控；第三個是任務自助診斷優化，在透明化的基礎上，怎么去解決優化。

第四個模塊是存儲資源治理模塊，對應存儲資源不透明的問題。首先從集群維度看存儲資源的大盤有多少表，有多少數據這些基本信息。第二是集群容量的分析治理，比如哪些表是無用的，哪些表是沒有壓縮過的，哪些表最近的增長非常快，是從容量分析的視角來看問題。還有一個就是從集群小文件的視角來分析問題。

1、服務健康監控與診斷

接下來重點看一下第一部分，服務健康監控與診斷。上圖以 Impala 服務為例，左邊是基本信息，右邊包含兩部分信息，第一個是探針 SQL 執行的狀態，解決可用不可用的問題。另一部分包括集群的存活狀況，元數據同步的狀況，隊列的排隊狀況，以及隊列內存使用率的狀況。實際上是對相關指標巡檢，解決有沒有風險的問題。

下面這部分基于時間線，比如選擇了最近五天，有一段時間是正常的，有一段時間有警告，有一段時間紅色變成了有異常。這時候可以追溯服務在最近一周的實際運行情況。對于警告或異常，點進去之后，可以看到一個診斷，告訴你問題是什么原因導致的，包括風險點，建議的措施以及異常的原因等等。

2、計算資源監控與治理

第二個介紹的模塊是集群計算資源監控，包括三個粒度的透明化：集群粒度、隊列粒度、任務粒度。

首先是集群粒度。上圖是我們的集群，有上千臺機器，平均的 CPU 利用率以及內存利用率是怎么樣的，可以看到有兩張折線圖，上面的折線是實際申請的情況，下面是實際使用的情況，可以從集群維度知道資源水位情況。還可以直觀地看出集群是否有資源浪費，對于很多架構師、集群的運維同學、采購同學來說都是非常有幫助的。

下面的散點圖里，每個點都表示集群里面的節點。橫坐標是內存的利用率，縱坐標是 CPU 的利用率。如果在原點附近，表示 CPU 利用率和內存利用率都很低，如果大量的散點落在這個區間，就說明集群是非常空閑的。

接下來是第二個層面，隊列粒度。集群分很多的隊列，每個隊列可能給不同的業務。圖中最上面的曲線是隊列資源的使用情況，一條線是內存資源，一條線是 CPU 資源。下面的曲線是隊列對應 Label 資源的使用情況。

接下來最細粒度的任務層面。第一個圖是任務的 CPU 使用情況，第二個是任務的內存使用情況。以 CPU 來看，上面這條線是任務申請分配的 VCore 的值，下面的綠線是實際使用的 VCore 值。很顯然可以看到，這個任務從啟動到結束，資源的實際使用率非常低，內存也是一樣的。

上面是從集群、隊列到任務三個視角去看資源的透明化，接下來結合這些信息進行資源的分析治理。

上圖中可以看到，通過列表可以知道哪些隊列的水位比較低，哪些隊列的水位比較高。對于低水位的隊列，可以知道通過治理可以省多少內存，省多少 CPU。

上面是解決空閑資源，第二是解決資源滿載。比如剛才隊列資源滿了，可以在產品上定位到對應時間點的任務列表，然后按照內存使用量、CPU 使用量進行排序，找到資源使用量最大的部分任務，結合任務資源監控的分析，進行相應的治理。

還有一種情況是任務的資源利用率異常。可以看到隊列實際內存使用率是相對比較低的，比如內存利用率只有8%，也就是申請了100GB，執行了只有8GB。我們會把這資源利用低的隊列顯示出來，并給出經過治理后可以節省多少內存以及 VCore 等。

這些隊列點進去之后會將這個隊列中的任務按照內存利用率進行排序，浪費資源最多的任務會排在第一名。浪費資源多表現為兩點，第一點就是任務申請了大量資源，但是使用了比較少；第二點就是任務的運行時間比較長。結合這兩點去做乘法，就會把浪費的內存、VCore計算出來，按照這個浪費的資源進行排序。排序之后就可以知道，要針對哪些任務進行優化。根據經驗來看，對Top的隊列的治理能夠獲得顯著的收益。

3、任務全鏈路診斷優化

第三個部分是任務全鏈路的診斷優化，解決的是任務運行不透明的問題。下圖可以很清楚地看到哪些任務是可以優化的，哪些任務是執行出現異常的。

拿到異常或待優化列表之后，就可以開始進行任務的詳細診斷。下圖是任務診斷詳情的一個示例：

這個任務相比平時執行耗時增長了六倍，下面的柱狀圖表示這個調度任務執行一次各階段的耗時，最后一天執行耗時明顯比其他幾天的時間要長很多。原因在圖里面能看出來，是藍色階段耗時最多，藍色階段代表 AM 分配的耗時階段。找到問題后，還會看到一個診斷意見，比如我們發現 AM 內存的使用率達到90%多，其實是沒有 AM 的內存可以分配出來，導致一直在等，這就是問題產生的原因，解決方案就是要去增加 AM 內存。