一、大數(shù)據(jù)集群現(xiàn)狀

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

1、Hadoop 大數(shù)據(jù)生態(tài)圈現(xiàn)狀

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

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

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

2、服務(wù)健康不透明

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

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

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

3、計算資源不透明

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

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

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

4、任務(wù)運行不透明

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

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

5、存儲資源不透明

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

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

二、產(chǎn)品核心能力介紹

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

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

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

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

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

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

第三個模塊是任務(wù)全鏈路診斷優(yōu)化，對應(yīng)任務(wù)運行不透明問題。第一個是集群任務(wù)執(zhí)行的概況；第二個是任務(wù)全鏈路監(jiān)控；第三個是任務(wù)自助診斷優(yōu)化，在透明化的基礎(chǔ)上，怎么去解決優(yōu)化。

第四個模塊是存儲資源治理模塊，對應(yīng)存儲資源不透明的問題。首先從集群維度看存儲資源的大盤有多少表，有多少數(shù)據(jù)這些基本信息。第二是集群容量的分析治理，比如哪些表是無用的，哪些表是沒有壓縮過的，哪些表最近的增長非?？欤菑娜萘糠治龅囊暯莵砜磫栴}。還有一個就是從集群小文件的視角來分析問題。

1、服務(wù)健康監(jiān)控與診斷

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

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

2、計算資源監(jiān)控與治理

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

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

下面的散點圖里，每個點都表示集群里面的節(jié)點。橫坐標是內(nèi)存的利用率，縱坐標是 CPU 的利用率。如果在原點附近，表示 CPU 利用率和內(nèi)存利用率都很低，如果大量的散點落在這個區(qū)間，就說明集群是非?？臻e的。

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

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

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

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

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

 還有一種情況是任務(wù)的資源利用率異常?？梢钥吹疥犃袑嶋H內(nèi)存使用率是相對比較低的，比如內(nèi)存利用率只有8%，也就是申請了100GB，執(zhí)行了只有8GB。我們會把這資源利用低的隊列顯示出來，并給出經(jīng)過治理后可以節(jié)省多少內(nèi)存以及 VCore 等。

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

3、任務(wù)全鏈路診斷優(yōu)化

第三個部分是任務(wù)全鏈路的診斷優(yōu)化，解決的是任務(wù)運行不透明的問題。下圖可以很清楚地看到哪些任務(wù)是可以優(yōu)化的，哪些任務(wù)是執(zhí)行出現(xiàn)異常的。 

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

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

4、存儲資源監(jiān)控治理

第四部分是存儲資源的治理，包括兩大方面，一個是容量治理，另一個是小文件治理。

 大盤中展示了集群里面的表信息，哪些表的存儲量最大，通過Top N可以排出來。右邊這張圖中可以看到哪些表的月增長量最多，這些可以作為容量治理的重要依據(jù)。

小文件管理方面，可以看到集群里面哪些表有大量的小文件，哪些表的小文件增長最快，也會排列展示出來。對于治理是非常有幫助的。

5、落地成果

最后簡單介紹一下落地成果。

首先是服務(wù)健康透明化。HDFS 集群 RPC 延遲增大等問題的責任應(yīng)用定位耗時，由原先的數(shù)小時，縮短到了5分鐘之內(nèi)。

第二是資源使用的透明化。網(wǎng)易 A 業(yè)務(wù)，高峰時間段集群資源使用率由96%下降到70%左右（釋放了7.9T內(nèi)存），任務(wù)量增長16%左右。網(wǎng)易 B 業(yè)務(wù)，經(jīng)過多維度計算資源治理，總共節(jié)省了上萬vcore資源。商業(yè)化某客戶，在優(yōu)化280個任務(wù)后，集群資源利用率提升了49%以上。

第三是任務(wù)運行透明化。相較于原先的人工排查，整體耗時減少了90%以上，大部分問題能在5分鐘內(nèi)定位，并告知開發(fā)、運行相關(guān)處理意見。

最后是數(shù)據(jù)資產(chǎn)透明化。網(wǎng)易B業(yè)務(wù)，經(jīng)過無用表治理、小文件治理等，降低了20PB+的存儲容量。

三、后期規(guī)劃

后期規(guī)劃主要有三個方面。

首先，繼續(xù)擴展 EasyEagle 在服務(wù)健康診斷方面的能力，將沉淀的更多場景下的成熟診斷和優(yōu)化的方法持續(xù)予以賦能，進一步提升大數(shù)據(jù)平臺核心服務(wù)的健康性和穩(wěn)定性。

另一方面，深化 EasyEagle 在數(shù)據(jù)資產(chǎn)治理方面的能力，將存儲治理的方法策略以及工具以更加友好的方式進行組織，體現(xiàn)治理的邏輯性。

最后，探索 AIGC 賦能，把 EasyEagle 平臺做成更加智能、更加易用的平臺。