一、背景

在目前規模比較大的互聯網公司中，總數據量能達到10PB甚至幾十PB數據量的公司，我認為中國已經有超過了20家了。而在這些公司中，也有很多家公司的 日數據增長達到100TB+ 了。

所以我們每天都要觀察集群的數據增長，觀察是否有哪一天、哪個路徑增長過猛了，是否增長了很多垃圾數據；繼續深挖下去，看看是不是可以刪掉無用的數據。

此外我們還要做“容量預估“，把未來的數據增長規劃出來，主要是依靠數據增長斜率計算出未來一個季度後的數據量，再把機器采購需求匯報出去。

在上一篇《基於FsImage的HDFS數據深度分析》 （ https://zhuanlan.zhihu.com/p/32203951）中，我們創建了基於Fsimage的HDFS數據分析倉庫，並創建了一些分析圖表，比如“HDFS增長趨勢圖”，充分地解決了發現“數據增長異常”的問題。

今天，我們會探討以下4個問題：

1. 怎樣觀察“數據增長”

2. 怎樣治理“數據過快增長”

3. 怎樣清理“無用的冷數據”

4. 怎樣管理“數據存活時間”

HDFS增長趨勢圖

先來算一筆賬： 當下，一臺不錯的Datanode機器配置，能掛12-16塊盤，每塊盤掛上比較大的3TB的硬盤。單臺機器的存儲量大致在50TB。若按每天增長100TB算，就需要2臺機器；按每天增長500TB，則是10臺機器。這個數字實在是Terrible ！

> > > >

數據瘋狂增長帶來的問題

1、加機器對公司的財務預算要求很高

服務器再便宜，也是錢。以一周買幾十臺服務器這種速度來看，即便是財務運轉再好的IT公司也不願意看到數據增長失控。

2、對集群負載的壓力

Hadoop是一個可以水平擴展的技術棧，且大多數分布式系統也都是把“水平Scalable”作為主要的功能點設計， 但在工程中，是否真的能做到“無限水平擴展”呢？

首先Hadoop中有一些“Master節點”，這些 Master 節點要實時地和所有“ Slave節點 ”保持心跳通信。 在集群規模較小時，由於“心跳”只做簡單的網絡通信，且所有的 Datanode 都互相錯峰匯報“心跳”， 所以網絡元數據交換並不是 Hadoop 系統水平擴張的瓶頸。

但在Hadoop集群的規模達到了大幾千甚至上萬臺後，網絡就是Namenode的瓶頸。這些心跳的RPC請求會和“用戶Client”的RPC請求一起搶占Namenode有限的CPU資源。

3、對運維團隊的運維壓力

運維團隊每周／月都要安裝新機器到Hadoop集群裏。做這些事情是重復又無聊的，即使自動化做得再好，也需要人來處理某些環節 。 臟活累活對追求“高技術密集度”的精英工程師團隊，是有危害的。

那為什麽 我們 會有這麽多數據增長問題？直接刪掉無用的數據不就行了嗎？這個事情在公司內部很難做嗎？

> > > >

為什麽這個問題在公司難做？

對於數據的增長，Hadoop Admin應該要對此負責的，但很多公司並沒有做好這件事情，原因如下：

1、一些公司在自己的數據量級並不是很大的時候，不願意重視這個問題。 對他們而言，與其請2個人去做這個事情，花掉半年時間， 不如先把錢拿來買機器，這樣的情形大多發生在 B輪／C輪的公司裏。

業務增長是主要矛盾。 數據每天增長5T，兩個程序員半年的成本確實大於買一些機器先解燃眉之急。 等到公司業務越來越大，問題暴露得越來越嚴重時，公司才開始意識到嚴重性，這往往已經晚了，畢竟建立整套的HDFS分析系統和報表系統也不是一時半會就能搞定的。

2、 受限於管理上的問題。 在公司裏，“業務事業部“和 “基礎架構部”是平級的，那作為“基礎架構部”的普通員工，哪怕是“基礎架構部”的領導，都很難推動其它“業務部門”去Clean他們的數據存儲。比如：

• 清一下沒用的冷數據

• 給用戶行為日誌加一些 Data Retention策略

“業務部門”總認為自己的核心任務就是業務開發，能為公司產生更大的利益，因此在做數據清理的任務時，總把排期靠後或是設定為低優先級，總有“幹不完”的開發任務，所以清理數據在公司內部很難推動。

3、Hadoop Admin 能拿出足夠的證據，讓 “業務部門” 刪除冷數據嗎？ 實際上，“業務部門”通常會這樣搪塞：

• /path/a 到底最後訪問的時間是什麽時候，憑什麽說沒人用了？

• /path/b 有100TB，可我都是有用的數據，別人也這麽大，為什麽不刪別人的？

• 你總讓“我們部門”刪數據，我們到底用了多少存儲空間？別的組如果比我們更多呢？

帶著上面這三個問題，繼續往下看。

1. 第一個問題似乎是一個很難避免的問題，需要CTO有掌舵的能力，那筆者則希望有誌於利用起Hadoop技術棧的中小公司CTO在看了這篇文章後，都能增加這個意識。

2. 第二個問題是管理上的問題。一般牽扯到制度上的變革， 最好 是要有Involve更高層領導參與的。多和高層提“成本”和“省錢”，少提“技術”，我認為高層會意識到這個問題的價值。

3. 第三個問題是本文的重點，即如何擺事實、拿證據證明我們可以針對Path做數據優化呢？ 哪些Path可以刪掉？哪些Path應該加Data Retention 策略？

二、行為（Action）

我們需要定期進行一些行為，來保持集群的數據可控。

> > > >

每日行為

每天來到公司，做這樣幾件事：

• 集群增長常規日分析

• 當集群“日增長有異樣”時，分析具體哪個Path增長占主導

• 發現“異常路徑“屬於哪個User或Team

• 發送郵件給對應User／Team，給出Solution

> > > >

季度行為

每個季度結束時 ：

• 哪個Team增長最猛，統計Team日增長平均量

• 找到“環比”增長最猛的Team，找到本季度“新增數據最猛”的新路徑，一般為一些新Hive表

• 發郵件給對應Team，給出Solution

要做到上述行為，我們要對每個Team，每個Path的“數據增長”都有詳盡的數據支持。試想一下， 在理想情況下，我們需要有哪些數據才能搞定？

針對“每日行為””，我們需要確定：

• 每天增長最大的文件是哪些？

• 針對確定的“異常日增長路徑”，能查到這個路徑的歷史數據增長，因為要清楚“平均增長值”，才能看出“某日增長量為異常”，然後再查到其下哪個子路徑貢獻了最大的增長，進一步深入查找問題。

針對“季度行為”，我們需要：

1、所有“數據團隊”對集群存儲的使用情況，按HDFS的使用量做KPI考核；不僅了解每一個“數據團隊”都有哪些“重要路徑”，還需要知道這些路徑的“增長狀況怎麽樣”。

• TeamA 一共使用的存儲空間，占公司總量有多少？

• TeamA 過去一個季度的環比增長速度如何？

• TeamA 過去一個季度的絕對增長量如何？

• TeamA 下的路徑裏，是否新建了很多新數據，比如新Hive表？是否有 Data Retention策略？

2、針對一個Team新增的“異常增長路徑”，我們要能查到這個路徑的歷史數據增長，要知道“平均增長值”，才能看出“某日增長量為異常”，然後查到其下哪個子路徑貢獻了最大的增長，進一步深入查找問題。

3、針對“某些”很大的、Size很久沒有變化過的Folder，我們要知道這個Folder最後的訪問時間是什麽時候、它超過半年沒訪問過的文件占比有多少、超過1年沒訪問過的文件有多少，然後我們才能和所屬的Team聯系，優先決定是否能刪除它。

在前文《基於FsImage的HDFS數據深度分析》 （ https://zhuanlan.zhihu.com/p/32203951）中 ，我們建立了HDFS數據倉庫，這相當於我們存下了HDFS每一天的快照， 所以每一條Path的元數據歷史問題解決了。

再來說說Team Level，每一個Team的數據，都是由一些文件夾下的數據組成的。 比如“推薦系統團隊”，在/hive/warehouse/reco.db下，所有的推薦相關的表數據都存在於這個下面。 另外/user/reco下也存放了很多這個組的數據，這幾個路徑，都屬於“推薦數據組”的“頂級路徑”。 所有“頂級路徑”的“增長聚合”，就是整個組的“數據增長”。

數據組的頂級路徑

每個Folder聚合其下每一個文件的Last_access_time，作為最終這個Folder的Last_access_time.

這個功能對Hive表非常好用。 有些Hive表很久都沒有人訪問過，後面我也會詳細敘述如何清理Hive表。

三、例子

接下來我將用我司的自動化運維系統中的一些報表來做解決問題的展示。

這些報表都是我們根據解決問題的方法論創建出來的，我們希望貫徹“讓一切人的決策基於數據”這一宗旨。讓我們判斷問題、找到問題，甚至說服“數據團隊”，都用Data Driven。

> > > >

每日行為例子

1、查看集群每日增長，發現沒什麽大問題。

2、查看增長貢獻，發現幾個/User下的用戶增長過猛。

3、查看這個路徑，與本路徑歷史增長做比較，發現昨日 確實 是在不正常地增長。

4、分析具體是什麽子文件導致了這個目錄的異常增長。

原來是這個用戶刪除了一些其它路徑的大文件，劃歸到User目錄自己的~/.Trash下了。那這就不用太擔心，因為HDFS第二天會自動清理掉~/.Trash下的垃圾文件。

> > > >

季度行為例子

1、分析“數據團隊”季度增長量

可以看到：

• TeamA的數據總量很大，環比增長也很大，是首要的分析目標。

• TeamB 和 TeamC 相比，雖然TeamB絕對值增量比TeamC大了很多，但還是一個數量級，但TeamC環比增速太高，很可能業務上發生了很大的變化，所以 TeamC是第二目標。

在運維人員有限的工作時間內，一定要把“精力”花在刀刃上。對一個Team的數據進行深度分析，往往要用去個把小時，一定要在單位時間上產出最大化。

2、深度分析Team數據

深度分析也是遵循“單位時間產出最大化，抓最主要矛盾”這一思想。接下來 還是拿我司的“推薦“團隊做例子：

這些所有的頂級路徑，都代表了某種業務的“細分”頂級路徑。

在每個細分“頂級路徑”下，我們要觀察：

• 哪些路徑的“絕對數據量”很大，一頭大象體重增長10%比一只老鼠多生一窩產生的體重多得多；

• 所有“第二檔次數據貢獻量”的路徑，分別調查其“日增長量”和“環比增速”，即“增速”的相對值和絕對值。

還是拿Recoteam數據來舉例子：

根據數據統計，我們分出第一輪目標和第二輪目標。

第一個路徑：

hdfs://beaconstore/user/hadoop/reco/report

它的特點是每日增速固定， 但最近訪問時間“很新”，且“平均文件大小”偏小。

所以策略可能是 ：

• “每日數據量優化”；

• “減少天分區數”；

• 未來對“文件平均大小”做優化。因為文件數量很多，可以節省出很多內存。

第二個路徑：

hdfs://beaconstore/user/hadoop/reco/report

它的特點是已經許久不新增數據， 但最近訪問時間“很新”。

所以策略可能是 ：

• 找到哪些子數據經常訪問；

• 刪掉不訪問的子數據 ；

• 是否有生命周期，有的話記得在未來刪除。

第三個路徑：

hdfs://beaconstore/user/hadoop/reco/online_log

它的特點是很久很久不新增數據， 且最近訪問時間“很老”。

策略是——建議刪除。

可以看出，不同的HDFS路徑，其存在的問題不盡相同，這真的 需要 具體問題具體分析。

如果通過分析“第一目標清單”，已經能夠達到控制集群存儲的目的，大幅降低數據存儲，那麽可以適當地忽略“第二目標清單”，記住那個目標“單位時間產出比”。這時可以把時間省下來做更多有意義的事情。

3、最後我們會出具一個Report，給相關的組發送Email，指明應該做哪些優化。

四、數據增長之Hive篇

前文 在講述治理HDFSS的數據增長問題時提到了：

• 每日獨立“異常路徑”數據增長治理

• 每季度數據增長過快的“異常數據Team”的深度數據治理

現在我們就把目標鎖定到Hadoop的數據倉庫Hive，談談數據增長之Hive。

> > > >

方法論

筆者認為Hive的“數據增長治理”，也分為兩點：

• 每日觀察“新增Hive表”，查看“每日增速過快的”以及“總量過快的”。新增的Hive表，被限定在30天（一個月內）新創建的Hive表。Hive表的創建時間，在Hive-metastore的數據裏可以得到。

• 每季度觀察“冷Hive表”，重點抓“Size最大的，最冷的Hive表”。

找到可優化“目標Hive表後”，按照前文提及的步驟來優化Hive表背後的HDFS路徑， 一個控制增量，一個優化存量。

> > > >

細節

1、控制增量

Hadoop管理員每天早上花時間掃一眼最近一個月新建的Hive表裏有沒有很大的表。

這裏的“大”指的是：

• 30天總量達到10個TB。 這個很好理解,"月總量值"是可配的，可以隨著業務增長放大。

• "每天平均日增量"達到1個TB。 因為有些表的生命周期可能只有幾天，日增量大的表，都要進入“待觀察”列表，最好都能強制“被管控”（Data Retention 策略，TTL等）

  

2、優化存量

Hive表的底層數據，是存儲在HDFS上的文件夾。我們可以通過使用SQL，從Hive－metastore這個MySQL數據庫裏，查詢到Hive表的HDFS路徑，Owner等元信息。

select TBL_NAME, location, owner, db.NAME from TBLS tb left join SDS s on tb.SD_ID=s.SD_ID left join DBS db on tb.DB_ID=db.DB_ID

在查找到Hive表 －》 HDFS路徑的對應關系後， 我們又可以根據前文 《基於FsImage的HDFS數據深度分析》所建立的HDFS文件系統數據倉庫，查詢到HDFS路徑的“Last_access_time”，以及路徑的Size，平均文件大小等元數據，這保證並確認了hive表的“最後訪問時間”是可知的。

最後，Hive表的幾項元信息，都會被緩存到另一張經過ETL後的的數據表Hive_meta_after_etl。這張表的結構如下：

hive_meta_after_etl

有了Hive_meta_after_etl表元數據的數據庫，我們就可以設計查詢入口：

在選出了運維的目標Hive表後，按照前文中分析HDFS“異常路徑”的方法，進行進一步分析即可。

架構

總結

總之，為了防患“無止境的數據增長”，公司最好每天都觀察數據增長5分鐘，並在每個季度Review每個數據Team的增長。

這裏總結了一些通用的原則，供大家參考：

• 要明確誰占用的“資源多”，誰Cost的成本高，方便給CTO匯報。

• 要打通數據分析系統，在數據團隊有疑問、甚至不配合工作時，給他們擺事實、講道理。

• 要把不同數據團隊的KPI做排名、做比較，讓數據存儲上做得差的團隊有“羞恥感”。

• 在推動整體數據治理這件事時，有必要Involve更高級別的領導，甚至CTO。

• 要梳理清楚Team的頂級路徑，嚴格規定路徑的使用。承諾只有放在Team頂級路徑下的文件是安全的，否則都可能在系統過載時被管理員刪除。

• 在有限的時間內，讓產出最大化，把精力花在最有價值的點上。

長按二維碼關註我們，每天都有精彩幹貨分享！

應對Hadoop集群數據瘋長，這裏祭出了4個治理對策！