背景

大數(shù)據(jù)平臺早期是野蠻生長的魂拦，作業(yè)直接在終端提交運行贝室，處于一種完全無管理的自由狀態(tài)。在17年上線了內(nèi)部的大數(shù)據(jù)平臺后畸裳，用戶開始逐漸在平臺上進行數(shù)據(jù)管理缰犁，代碼編寫，作業(yè)管理等工作怖糊，但是資源治理依舊缺失帅容。

隨著業(yè)務及數(shù)據(jù)量的不斷增加，集群擴容伍伤，存儲和計算資源達到一定規(guī)模后并徘，對大數(shù)據(jù)平臺進行資源治理就非常必要了，本文是基于 HADOOP 生態(tài)的一個總結扰魂。

該項目大部分完成于18年麦乞，由于內(nèi)容較多（人比較懶），幾次提筆都擱置了劝评，全文主要圍繞 為什么做/要做什么 來展開姐直，至于具體怎么做，方法有很多蒋畜，大家就見仁見智了声畏。

組件

HDFS

為什么需要治理

1. 財務預算高

   數(shù)據(jù)增長非常快姻成，不干預的情況下日增能達到100T插龄。在計算與存儲沒有分離的情況下，存儲資源的不足就意味著需要購買新的機器佣渴，不僅成本非常高辫狼，還會造成計算資源使用率低下。

2. 集群負載高

   HDFS 雖然支持水平擴展辛润，但是當集群到了一定規(guī)模膨处，NameNode 就會成為瓶頸见秤，其一為 NN 的內(nèi)存瓶頸，其二為大量DN的心跳RPC請求帶來的網(wǎng)絡瓶頸真椿，同時重啟恢復時間也會變長鹃答。

3. 運維壓力大

   頻繁的擴容，即使有自動化工具的支持突硝，也會給工程師帶來一些低價值的工作测摔。

為什么難以推動

1. 在集群數(shù)據(jù)量級較小的情況下，以優(yōu)先解決業(yè)務需求為主解恰，增加機器遠比開發(fā)一整套資源分析系統(tǒng)的成本要低锋八。
2. 平臺需要推動業(yè)務部門刪除一些”僵尸數(shù)據(jù)“，但業(yè)務部門人數(shù)較多护盈，以開發(fā)業(yè)務為核心挟纱，刪除數(shù)據(jù)在他們看來優(yōu)先級非常低。

需要做什么

核心思想：控制增量腐宋，優(yōu)化存量

1. 冷數(shù)據(jù)

   長期沒有訪問的數(shù)據(jù)紊服，包括一些分析建模留下的中間數(shù)據(jù)，無用數(shù)據(jù)等胸竞。針對這部分數(shù)據(jù)欺嗤，設計了一個資源浪費分的概念，根據(jù)數(shù)據(jù)目錄大小絕對值和最后一次訪問時間進行計算卫枝，該分數(shù)達到一定閾值后會對用戶進行提醒煎饼，不操作則進行刪除。

2. 碎片文件

   通過計算目錄下每個文件的平均大小剃盾，平均大小小于某個閾值時會觸發(fā)腺占，進行合并壓縮處理淤袜，可以參考 Spark 小文件合并優(yōu)化實踐

3. 異常增長

   數(shù)據(jù)目錄增長異常痒谴，可能是業(yè)務存在較大的變動或是用戶的誤操作導致，這種情況需要對用戶進行預警铡羡。

4. 空間占用絕對值高

   使用更高壓縮率的壓縮算法积蔚，例如zstd。統(tǒng)計出日增長絕對值最高或者月環(huán)比 / 季環(huán)比較高的 team 烦周，發(fā)送郵件給相應 team leader尽爆，要求給出解決方案。

5. 集群容量評估

   根據(jù)集群歷史數(shù)據(jù)增長情況读慎，評估目前的容量多久后需要進行擴容漱贱。

6. 數(shù)據(jù)生命周期

   所有的數(shù)據(jù)進行表化，上大數(shù)據(jù)平臺夭委，強制填寫生命周期幅狮，例如物化的臨時表生命周期為7天，到期后會自動刪除，不需要主動進行管理崇摄。普通的數(shù)據(jù)表/分區(qū)生命周期到之前7天給用戶發(fā)郵件/釘釘擎值，用戶可以選擇續(xù)期或者直接過期刪除。

部分效果圖

容量評估

2020042314233829.png

用戶資源使用趨勢

20200423213916347.png

用戶數(shù)據(jù)日增量

20200423142316184.png

SPARK & YARN

為什么需要治理

1. 資源使用不平衡

   比較常見的情況是集群中內(nèi)存被申請滿了逐抑，但是 CPU 還有剩余鸠儿。

2. 運行時間不穩(wěn)定

   同個作業(yè)多次運行時間波動幅度大。

3. 資源濫用

   每個業(yè)務方都希望自己的作業(yè)能盡可能快的完成厕氨，導致資源被濫用进每，帶來一些不必要的資源緊張。

需要做什么

1. 作業(yè)資源統(tǒng)計分析

   現(xiàn)實的情況是大多數(shù)作業(yè)直接運行在大數(shù)據(jù)平臺上命斧，少數(shù)作業(yè)因為歷史原因還在終端運行品追。

   • 終端的作業(yè)都是獨享一個 Spark Application ，從 submit 到 shutdown 有一個完整的生命周期冯丙。

   • 大數(shù)據(jù)平臺作業(yè)則分為獨享和共享 Application 兩種肉瓦，獨享和終端類似，共享的方式是一個作業(yè)由 Spark 的幾個 job 組成胃惜。

   對于獨享的任務泞莉，直接計算整個 application 運行期間消耗的 mem_seconds/core_seconds ，共享的任務資源使用則是通過該任務結束時間獲得的 mem_seconds/core_seconds 減去開始時間的值獲得船殉。

   對于 Spark 作業(yè)鲫趁，還可以通過 Listener 對 task 做進一步的分析，幫助優(yōu)化應用資源使用利虫。

2. 集群資源統(tǒng)計分析

   根據(jù)統(tǒng)計信息能獲取當前 cpu/mem 使用較高的一些作業(yè)及用戶挨厚，根據(jù)歷史資源使用趨勢可以更合理的安排作業(yè)的調(diào)度時間。

3. 內(nèi)存及 cpu 使用控制
   spark on yarn cgroup 資源隔離(cpu篇)
   使用 jvm-profiler 分析 spark 內(nèi)存使用

4. 作業(yè)數(shù)量/資源池限制

   在平臺層面對用戶/應用賬號不同類型作業(yè)（schedule/dev/etc.）進行提交數(shù)量限制糠惫，對不同的應用分資源池進行約束疫剃。

部分效果圖

集群資源使用及作業(yè) Top

20200423141941621.png

集群當前狀態(tài)

2020042314184496.png

Spark任務診斷

20200423141331153.png

20200423141346851.png

計費

對于普通用戶來說，提供諸如 core_hour / mem_gb_hour / disk_gb_day 之類的單位過于抽象硼讽，很難意識到自己真正使用了多少資源巢价，所以根據(jù)算法直接將物理資源折算成人民幣，可以具體到每個任務運行花了多少錢固阁。

Spark 計算時會同時申請 mem 和 cpu 資源壤躲，如果一臺物理機內(nèi)存被申請完了，cpu 資源也是無法使用的备燃，所以根據(jù)物理機的配置折算成計算單元更為合理 1cu = (1C,5G)碉克，最后會根據(jù) cu 和存儲占用進行綜合計費。

通過計費的方式可以對資源進行更直觀的展現(xiàn)：

1. 從用戶的角度并齐，可以知道自己的某個任務計算花了多少錢漏麦，某個表存儲花了多少錢法瑟。

2. 從公司的角度，能清晰的從報表上看到哪幾個部門用了多少錢唁奢，哪個Team用了多少錢霎挟。

3. 從業(yè)務的角度，根據(jù)資源的使用可以更好的評估投入產(chǎn)出比以及業(yè)務價值麻掸，讓其更有動力去優(yōu)化業(yè)務代碼酥夭。

任務維度的計費

任務維度的計費

后記

18年上線后進行了四個月的跟蹤觀察，存量數(shù)據(jù)絕對值降低了20%脊奋，文件數(shù)量降低了 35%熬北，增量數(shù)據(jù)增速降低了80%，集群整體的內(nèi)存使用率提升了20%诚隙，同一作業(yè)的多次運行時間波動范圍下降了50%讶隐。

在整個治理過程中，技術只是其中的一小部分久又，同時還需要從行政上進行輔助巫延，否則效果將會大打折扣。