唯品會大數據存儲和計算資源管理的痛、解決方法與思路(附PPT)

講師介紹：單超，現任唯品會大數據平台高級架構師，曾帶領團隊完成了唯品會的Hadoop平台上線，Greenplum數據倉庫遷移，基於大數據的ETL系統開發，storm/spark實時平台管理等工作。目前致力於完善大數據離線和實時全鏈路監控系統，自動化大數據平台問題管理和資源管理，構建實時多維分析平台等技術方向的工作。

大家好，很高興有機會分享一些大數據方面的思考。當集群到達一定的規模以後，不可避免會碰到一些管理上的痛點，今天我就唯品會在面對這些痛點的一些解決方法和思路，與大家交流討論。

本次演講主要分為四個部分：

1、唯品會大數據平台規劃和現狀

2、大數據中的資源管理

3、存儲資源管理和計算資源管理

4、案例分享

一、唯品會大數據平台規劃和現狀

這是唯品會大數據平台一個中長期的規劃。目標很明確，我們希望從技術上能把整個大數據做成一個包含離線計算平台、流式計算平台、模型訓練平台、VRE、 DMP和多種應用的完整生態鏈，並且希望通過這個平台，讓我們公司的分析師、開發人員可以很簡易地運用起來。

這是唯品會大數據平台的現狀，總體和上面的規劃圖類似，重點在於離線平台的搭建，目前離線計算平台也已經做得差不多了。我們現在有一套很完整的數據開發平台，可以讓公司的分析人員在不需要任何培訓的情況下，方便地利用這個系統去挖掘大數據中的各種知識，為業務服務。除此之外，我們也有很多產品，看到圖中數據產品一塊，有情報中心、比價、選品、數讀、魔方羅盤、儀錶盤等。

二、大數據中的資源管理

大數據管理本身是一個很廣的概念，涵蓋了很多知識面。但資源管理是今年讓唯品會特別難受的一個點，很多工作人員經過長時間的不眠不休，才最終把它解決掉。所以今天我會把資源管理作為重點，單獨拿出來分享。

這裡的「數據平台使用申請」打了引號，我想說的是這個「平台使用申請」在初創公司或者建設數據平台的初期，一般是很難做到這麼完善的。因為我們需要用戶提交很多要求，而且這些要求是明確的，包含了比如我需要什麼樣的資源，HDFS的存儲、資料庫、計算都需要多少，資源的數目是多少，要通過什麼方式去訪問。拿到這個申請以後，管理員會負責去分配同樣的資源，比如HDFS中分配多少資源給你使用，Hive也是，如果我想要這樣一個資源分配隊列，需要明確分配給你的最大/最小資源是多少。

當然，這是一個理想的情況，現實卻很骨感。因為這個行業的發展非常快，相信很多做大數據的同學，很多時候你是被業務和領導推著向上的，所以這時你的思考可能不是很完善，你會發現，你的理想狀態是系統很強大、數據規範、流程規範、技術成熟、業務成熟，但現實呢？唯品會在半年前也是這種現狀：模型的變更非常迅速，線上的那些代碼實際上是我們的人員按小時為單位去做變更的。用戶的能力參差不齊。有很多的歷史包袱，唯品會的數據平台其實四年前就開始搭建了，其中有三年的歷史包袱。同時，有大量的技術包袱，而且平台非常不穩定，掌控力差，有各種各樣的瓶頸。整個大數據平台的分層也不是很明確。這是我們面臨的現實。

那麼，這種情況下，維護人員或者像我們這樣的技術架構人員就會經常接到用戶各種各樣的投訴和問題。這裡我列了一些用戶經常會抱怨的問題：

• 這個任務昨天還好好的，為什麼今天跑不出來了？

• 2-10倍的數據量，能撐得住嗎？

• 怎麼幾千個任務都慢了？

• 最近磁碟使用率急劇增加，誰在用？

• 這個表好像不用了，我能刪除掉嗎？

• 集群要擴容嗎？擴多少?

當你在沒有足夠能力應付的情況下，面對這些問題，你是一籌莫展的。而由此也引申出今天的核心議題——資源管控。

三、資源管控中的存儲資源和計算資源

做運維、DBA，或者大數據管理人員，都需要了解一個核心，那就是資源管控。做資源管控，其實和分田到戶是同樣的道理。當把一塊田交給你，那你就在這塊田裡自己玩，不要到別人的田裡去摻和。通過資源管控，可以實現很多目的：

• 從亂序到有序。

• 申請和分配有據可查。

• 規則公開透明。

• 數據公開透明。

• 有多少資源，干多少事。

• 有合理的KPI和懲罰機制。

• ROI，資源傾斜給回報率高的項目。

以Hadoop為例。Hadoop平台是大家都在用的一個技術框架，它有哪些資源呢？總的來說，有四個模塊：計算資源、存儲資源、許可權資源、業務資源。今天我會重點講右側的計算資源和存儲資源。

為什麼存儲和計算需要關注？

首先是NameNode。NameNode在Hadoop中相當於一個技術的管理節點，我們平台目前已經存儲2億的文件超過2億的blocks，現在NameNode的內存使用在100G左右。在這麼大的一個集群規模情況下，會遇到很多問題。

• standby namenode updateCountForQuota緩慢影響主從一致性，進而影響切換（HDFS-6763）

• standby checkpoint緩慢導致增量blockreport彙報被skip, 影響主從一致性，進而影響切換（HDFS-7097）

• standby checkpoint GC導致transfer Fsimage超時失敗

這裡列了幾個問題點，都在社區被不少人提出來，我們也確實受到了影響。

其中，最重要的是集群啟動時，規模越大，你的啟動時間可能越慢，除非你把這部分的代碼全部進行重構。舉個例子，可能我們的集群重啟需要30分鐘，因為需要每個block去上報。

另外，第二個瓶頸就是資源管理，叫做ResourceManager，這也是Hadoop中的一個技術組件。唯品會現在的規模並行度是高峰期可以有一千個任務在跑，每天有將近40萬的任務提交到Hadoop集群里，基本24小時內時時刻刻都有人在運行。因為現在的電商，包括現在的大數據已經不是以前那種玩法，不是你晚上跑個批處理，事情就做完了。現在大家的要求是，你能不能5分鐘內跑出來，所以我的批處理在上面可能是5分鐘一個力度去提交的，所以這個集群對我們來說已經不是夜間作業的集群，而是24小時專機，永遠不能宕機的一個服務。

• https://issues.apache.org/jira/browse/YARN-3547部分解決問題

• https://issues.apache.org/jira/browse/YARN-518 our patch for fairscheduler

這裡也列了兩個問題，就不展開講了，關鍵是第二個，我們提交給社區的補丁。這些問題社區還沒有解決，我們這個補丁也還沒有打到任何社區的版本里去，但是如果當你的集群規模非常大，運行HDFS時肯定會遇到和我們同樣的問題——分配能力有瓶頸。目前我們通過這個補丁，分配能力提升到了近10-15倍。這其實很誇張，我們一直考慮的是，現在已經有幾百台節點了，那能不能變到幾千台？如果分配這個問題不解決，你的瓶頸永遠卡在那，即使再加機器，管理也會因為瓶頸上不去，無法提升到幾千台這樣的規模。

前面講到了很多問題，怎麼解決呢？開源節流。分兩塊，一塊要提升各方面主機的性能，圖中列出來的，包括了NameNode RPC性能、yarn的container assign性能，以及加機器。另外一塊，就是要做各種優化管理。大家想，原先你就有幾百個用戶在用，當開放出去後，隨著大數據應用的發展，不斷有人去用，久而久之就會變成上萬個用戶在用。這時，你的存儲是否被有效地利用呢？是否都是有價值的數據放在上面呢？你的計算是否都是有效的計算呢？還有人在用這樣的一個任務嗎？

管理數據化成果

給大家看一下我們在這一塊的成果。理念很簡單，就是做一個閉環。把整個數據倉庫和Hadoop做成一個閉環，大家可以看到內圈，其實就是正常開發的一個數據倉庫，你會建立任務、執行、下線，這是一個循環。而外循環是從整個任務建立時就開始對它進行管理，當你任務申請好之後，你會分配到一個隊列，查看你的每一個日誌。存儲和計算會告訴你用了多少，同時還可以做一些智能的分析。在你的任務執行完之後，可以在系統裡面看到任務的整個生命周期運行情況。

基本上我們就是把整個大數據分到項目，分到人，分到資料庫，分到幾個任務，所有的指標都可以可視化地讓你看到，也就是說，即使你只是簡單地在系統里提交了一個SQL，可實際上你得到的是一個可視化、數據化的成果。你可以知道，今天我提交了多少個SQL，佔用了多少資源，剩下多少文件，所有這些東西在系統里都可以看到。

這樣數據分析師也能主動跟你講，今天慢了可能是因為提交的任務太多，今天提交的任務比上周多了一倍。你也能主動地在系統里找，為什麼多了一倍？什麼樣的任務最佔用資源？整個架構閉環大大降低基本架構技術人員的工作量。而當我們所有的數據都開放給數據分析師時，他們又能通過這些數據去做一些自己的分析，這也是一個閉環的形成。對很多公司來說，通過構建閉環，這一塊的工作效率將會得到很大的提升。

接下來重點講兩塊資源的管理。一塊是存儲的資源，一塊是計算的資源。

存儲資源管理

一般情況下，大家在Hadoop中都是用Hive這個資料庫，它對應的是後端的一些一二三級目錄等資料庫和表的目錄。我們要怎樣獲取這些數據呢？從我們的角度來說，我們也是數據分析人員，我們要做的東西和其他的分析師其實是一樣的，只不過我們分析的對象是系統的性能數據。我們會想要獲取各種各樣的性能數據，同時，我們需要去計算這些性能數據，做多維度的各種計算，然後把它推出去給用戶看。

存儲資源基本上就是通過這幾大塊來收集，左邊是獲取到的各種存儲的信息，文件、表、數據倉庫、ETL、Hadoop的日誌……第二步是把它轉化為Hive里計算的文件元數據信息、表元數據信息、調度任務元數據信息、路徑訪問信息，最後得到的產出通過各種維度的計算，可以得到：

1. 維度：包括分區、表、資料庫、任務、業務、人、目錄層級、時間等所有維度；

2. 指標：全量、增量、趨勢、平均文件大小、最大文件大小、最小文件大小、文件數目、佔比等；

3. 熱度：哪些表被頻繁訪問？哪些表3個月沒人訪問，是否可以下線了？

4. 安全：有沒有敏感信息被非法訪問。

通過這一系列的存儲資源管理，可以把所有的關鍵信息收集起來。下面，講一下這些數據的使用，這也是我們公司目前正在踐行的：

• 容量計費

  通過計費來控制資源，使存儲數據完整透明。消費預警，會提前知會用戶。

• 空間管理

  自動配置生命周期管理規則；存儲格式，壓縮格式選擇（orc+gzip）；

• 文件管理

  自動配置生命周期管理規則；小文件har歸檔。

控制存儲的價值：一方面可以解決NN「單點」瓶頸，控制伺服器的數量，降低成本。如果沒有加以控制，很快你的規模就會變成幾百、幾千，逐漸失控。另一方面，規範數據生命周期管理，統計冷熱數據的使用，區別哪些數據是能刪的、哪些是能歸檔的、哪些是被頻繁使用的，都可以通過這個手段反饋給ETL生命周期管理。

計算資源管理

這是yarn的一個架構圖。大家都知道yarn是Hadoop的一個統一的調度管理。但yarn好像把所有資源管理的事情都搞定了，我們還需要管理什麼呢？實際上，還有很多沒有解決的問題。

問題比較多，這裡挑兩個出來詳細說說。

先講一個維護人員比較關心的問題。當維護大量的機器時，判斷這些機器本身是不是在正常運行其實很難。因為一個機器是不是fail其實很難去權衡，可能是硬碟有問題，或者網路、CPU有問題，但最終表現出來的都是對Hadoop集群有影響。Hadoop對機器硬體的要求其實並不高，那我們可以通過什麼數據來告訴你Hadoop集群是有問題呢？很簡單，所有上面跑過的任務都統計過了，我們就可以知道，跑了100個任務，失敗了多少個。如果你定下指標，跑了100個，結果失敗的超過了20個，這明顯是不合理的，肯定需要去管理，所以這是從數據角度去反饋給運維人員，就是我告訴你這個系統是有問題的，你反回去查。

再講一下數據傾斜。怎麼知道一個任務是不是數據傾斜？一種是靠數據分析師人為的經驗，另一種從技術角度，當你跑MapReduce的時候，你的MapReduce可能是100個，前面99個在一分鐘內跑完，有1個跑了一個小時，這時肯定是出現傾斜了。解決這個問題也很簡單，就是把數據開放給用戶，通過智能的分析告訴用戶任務傾斜了，至於為什麼會傾斜，讓用戶自己通過數據去反查。

現在我們的大數據平台上每天有幾十萬的任務在跑，數據量也不小，每個任務都分到MapReduce里，加起來有千萬級別的數據。所以為了拿到剛才講的各種數據，就需要考慮數據的收集問題。目前我們有很多不同時間力度的收集方案，會每分鐘去拿，實時去拿，也會在每個任務提交後自己主動去上報，每個ETL任務完成後也會上報。

這一部分資源怎麼用呢？跟存儲資源類似：

• 容量計費

  1）通過計費來控制資源

  2）存儲數據完整透明

  3）消費預警，提前知會用戶

• 實時告警和自動處理

  1）根據隊列設置不同的規則，如運行時長、使用資源、自動發現和觸發停止動作

  2）通過業務注碼，自動展示運行中的業務細節

• 數據傾斜自動識別

• 隊列數據化運營

關於公平調度，我們有自己的一套管理原則：

1. 盡量細化，單個業務分配單獨隊列。

   細化和大鍋飯的區別就是兩個人吃一碗飯和每人分一小碗的區別。這樣就可以很清楚地知道你吃了多少，你是不是還餓著，另一個人可能是浪費的。我們的管理理念基本上就是儘可能去細化，來一個新的項目我給你分一個新的獨立資源。

2. 隊列分配的min/max/weight由實際業務來評估，上線初期會不斷調整、觀察。

3. min是保證的最小資源，確保優先獲得。

4. max是業務的最大資源限制，確保不會超過。

5. 每個隊列由多個不同級別的子隊列組成，子隊列業務可靈活調整。

6. 子隊列大小可以基於時間動態調整：

   1）白天，天任務隊列縮小，小時任務隊列放大；

   2）夜晚，天任務隊列放大，小時任務隊列縮小；

   3）關鍵任務確保隊列內的最小隊列保證。

四、案例分享

接下來講一些實操的例子。

Yarn實時運行情況監控

這張圖，用過Hadoop的同學會比較熟悉，這是Hadoop官方提供的關於yarn實時運行監控情況。從圖中可以看到你的集群到底跑了多久，和你的集群使用率。這個數據是完全實時的，也就是過時不候，沒有歷史時序數據，展現不夠直觀。那我們要如何去獲取這樣的表格數據呢？

一個方法就是通過Hadoop的jobhistory，獲取每個application的明細執行結果。缺點是只有在任務完成後才能獲取到完整信息。另一個方法是job api。通過api實時獲取到所有job的基礎信息，比默認rm的api提供更多欄位信息，如SQL信息，但也有缺點，它獲取的不是100%完整的數據，定期獲取必然會丟失數據。

秒級計算資源管理

剛才提到的秒級計算資源管理， 就是通過把實時數據計算的過程監控移植到產品中，那麼在這個產品中我們就可以看到一共有多少資源、你用了多少、什麼樣的查詢、什麼時候提交、進展怎樣、是否需要reduce，這些都可以在界面看到。同時，我們還可以根據實時拿到的數據，檢查有些任務是否跑了過長時間，有些資源使用是否超過預值了，可以把它kill掉。

分鐘級計算資源管理

分鐘級的話，我們可以每分鐘獲取Hadoop內部jmx的信息。這裡列了一些信息：

這些信息拿出來之後會做成下面這種實時監控的圖，交給運維人員去使用。

如果隊列分配紅線跑平，而隊列等待藍線升高，就可以得出單個業務資源吃緊，需要增加最大可分配資源。

這是另一個Bug，也是剛才我們提到的yarn分配能力出問題了。藍色是等待的線，當等待的數據在急劇增加時，綠色的線反而在下降，這是因為出現資源分配不均，資源使用率越來越低。我們看到，整個集群在高峰期等待非常多，但集群使用率低於50%，這是很不正常的現象，說明你的集群根本沒有得到合理的釋放。

再簡單講一下前面這些資源管控的優化展現。一方面是隊列的展現，目前我們可以看到任意時刻任何隊列的使用情況，看到集群總體資源分布的情況，同時也可以查看最消耗資源的是什麼任務，以及實時/歷史的數據查看。

天級計算資源管理

離線資源天級的場景，我們也會做一些匯總。比如：

• 查詢集群的資源使用場景

• 時間/應用/隊列維度的資源使用情況

• 核心ETL任務近期map/reduce使用情況

• 單個attempt的metrics指標查看，如讀取超過1kw行數據的map任務

對於數據傾斜的識別，就是通過數據來分析，看所有的計算中數據量是不是一致的，會不會有1到2個計算的數據量是異常的，可以通過這種方法分析出來。這裡列了一個從數據到日誌、到系統的數據表。

下面是一些優化的例子。

• 用更少的資源計算

  1）orcfile，壓縮率更高，列式存儲降低資源消耗

  2）權衡資源和性能，基於record而不是size調整reduce數量

  3）基於hll的uv估算函數，提供可增量的uv計算

• 用更多的資源計算，更快的釋放

  1）sparksql，內存需求高，複雜計算快

  2）presto/impala，利用mpp框架提高計算性能

• 不同隊列的資源使用上限限制

  1）基於項目粒度的隊列資源把控，個性化控制最大可提交資源

  2）項目隊列的最大值限制，避免單個項目失控

• Reduce Slow Start

  1）基於實際m/r的比值設置該參數

  2）資源更快的獲得和釋放，整體集群受益

資源使用報告

最後，製作資源使用報告時，我們可以把它轉化、精簡，保證所有集群使用的信息都可以在裡面看到，並每周定時給業務發一份詳細的報表和郵件就可以了。（文章來源DBAplus社群）