文|傅一平

這次數據治理的課題是：面對持續增長的存儲投資需求，如何進一步提升公司大數據的存儲效率，從而實現高效低成本運營？

1、數據治理的驅動力

2015年-2016年我們就完成了企業級大數據平臺的建設和應用上雲遷移，將公司的三域B（業務）/O（網絡）/M（管理）數據進行了統一歸集，但在實施中也發生了很多妥協。

因為大量的O域應用跟存儲的數據是緊耦合的，也就是說這些數據是非標準化的，如果要實施數據的統一標準化歸集，必須進行存量應用的大量改造，但這種改造的代價牽一髮而動全身，在一個大數據平臺項目週期幾乎是不可能完成的，那怎麼辦？

先破後立！

當時的原則就是允許存量應用的數據保留一份，大數據平臺先從這些數據的源頭統一歸集一份，待到時機成熟的時候，再考慮存量應用的改造和數據的合併。

這就意味著大數據平臺從建立伊始，其上的數據並不是企業大數據唯一的一份，還有大量的存量應用在使用用非標準化的數據，更為關鍵的是：這些數據的源頭往往是一個，意味著數據的較高冗餘。

這是很多企業的現狀，發現在建成大數據平臺後，感覺又多了一個山頭？

每年隨著數據量的增長，大數據平臺需要投資擴容，但大量的存量應用依賴的數據也在同步增長，因此也需要擴容，當這份冗餘的數據還是最大的一份的時候，公司的投資也要開始叫了。

因此，所以能實施一次數據治理，往往是數據的問題已經在公司層面顯性化的暴露出來，在降本增效這個大背景下，很多公司是有數據治理的驅動力的，畢竟節省的是真金白銀。

現實中，我們大量的數據治理活動都是小組級、部門級的，跟數據產品，數據變現，智慧運營這些工作相比，重要程度實際是偏低的。

大多時候，公司層面並沒有感覺到未實施數據治理的痛苦。IT部門雖然痛苦，但為公司呈現數據的時候，大多數時候也是打腫臉充胖子，即使你花了大量的人肉去保障，但又有誰會理解人肉的痛苦呢？

因此，數據治理從來都不是自底向上就能幹成的事情，你只有在一個勢上，才能有幹成事的機會，說起來有點悲壯。

數據治理大多數時候也是失敗的結局，因為要治理就要牽扯多方利益，沒有公司的統籌協調，誰願意損失哪怕一點點利益？

因此，並不是說我們就能幹成數據治理，其實很多時候，唯運氣而已。當然要最終幹成事，還是要有實力的，否則一旦有了機會，你也抓不住。

2、數據組織的保障

筆者在反思為什麼還是能最後幹成這個事情？很多企業也有這個驅動力啊！但為什麼很難幹成？

想來想去，我覺得有個統一的實體數據管理組織是非常關鍵的。

為什麼？

因為這個組織就是以數據為生的，搞企業級數據管理的組織，哪個不想“一統天下”，他們天然有數據治理的驅動力，而且這個組織一定會有一批懂數據的人，有機會，就一定會跳出來。

2015年，我們成立了大數據中心，下設了三個科室，而數據管理部就是專幹這個事情的，其是企業進行數據治理真正的組織和人力保障。

雖然大數據中心成立的直接目的是為了變現，但把數據治理這個事情幹了是很順理成章的事情，因為沒有高質量的數據，你也沒法很好變現。

降低數據冗餘這個事情公司提出來，大數據中心自然要牽頭，我們當然有權利要求其它部門進行配合，這就有了事實上的跨部門組織。

你看，天時、地利、人和都全了，接下來，就落到方案層面了。

3、理解冗餘的現狀

理解現狀是第一位的，我們做了與相關部門的充分調研，發現除了大數據平臺公共租戶有一份標準化的DPI（可以理解為上網日誌）數據即A1，在其他應用租戶和Hbase集群有兩套系統內有類似的數據即A2和A3，但三類數據的存儲方式各有不同，但實際源頭是一致的，都來自探針，經過不同的加工處理後，就形成了一定的冗餘，如下圖所示。

通過分析這三份數據，可以得到如下一份清晰的數據分佈現狀報告，這是數據治理工作的起點。梳理工作來來回回持續的時間長達一個月，因為涉及多方系統和應用，雙方要對齊口徑，確保理解的一致性。

梳理現狀中有幾個要點，特別提一提：

首先，要有標準化意識，比如規範梳理的模板，明確各個指標的口徑，比如存儲量是什麼意思，裸存儲還是可用存儲，事無鉅細，一旦某個口徑出現少許偏差，就可能謬以千里，曾經我們按照口頭約定的方式去梳理，幾周後拿各自的材料一對，發現到處是各說各話的口徑和理解，還得重新來過。

其次，要有迭代的意識，清楚梳理是一個持續逼近真相的過程，無法一步到位，不要想著開一次會就能明確清楚要求，這種治理大多是開了個好頭但最終爛尾，一定要是在每天，每週的溝通中逐步達成共識，畢竟每個部門都有自己的利益。

再次，要有全局的意識，始終站在公司的立場來處理問題，因為凡是涉及到各方利益的事情，一定是有部門牆和本位主義的，比如對方就不想整合某個數據，這個時候數據管理部門就要有原則，先把問題拋出來，如果合理，在公司層面彙報的時候，還要幫助對方去據理力爭，畢竟很多應用積重難返，改造的代價太大了。

最後，要有擔當的意識，如果對方在梳理中存在問題，或者推進困難，就要主動去推進問題的解決，很多時候數據管理部門的同事會抱怨對方不配合，其實很多時候就是藉口，或者為自己的不作為找理由，除非公司本身就不想幹這事，或者升級渠道沒有打開。

升級渠道未打開，往往是未設置專業的數據管理組織導致的，數據的很多治理問題無法解決，根子在於沒人真正的把聲音傳遞到公司決策層，幹不成事情是很顯然的。

4、在業務上的策略

數據治理中的問題，很多需要從業務的視角尋找解決方案，而不是就技術論技術，針對DPI數據冗餘的問題，我們首先考慮的是能否在短期內找到降低存儲的方法，緩解當前的壓力。

在業務層面進行了分析後，發現在字段裁剪、數據採樣和週期優化等方面存在降低數據冗餘的空間，當然這個需要業務方的確認。比如哪些表的字段沒有任何應用上的調用，哪些表的調用週期間隔非常長，哪些表只需要訪問近線的就可以了，然後我們得出了策略，如下表所示：

5、在技術上的策略

有大量的技術可以應用在數據存儲效率的提升上，我們根據分析，採用了兩種手段：

第一種：減少副本

現在諸如hadoop都是三副本，之所有采用三副本其實也是技術上妥協的結果，兩副本也不是不可以，只是恢復起來麻煩而已，比如採用糾錯碼技術就可以做到。假如hadoop平臺的計算資源利用率並不高，就可以採用糾錯碼技術，用計算換空間，4G日誌留存這份數據就滿足了這個條件。

第二種：格式優化

針對不同的場景可以採用不同的壓縮手段，比如針對TextFlie+HIVE，可以採用普適性強、壓縮效果更好的OrcFile文件格式，針對HFile+HBase，由於HFile文件膨脹很大，如果應用的時效性不高，則完全可以替換為HIVE這種格式。很多場合，並不是越快越好，總是要尋求性價比高的方案。

6、在整合上的策略

無論是技術策略還是業務策略，相對還是比較簡單的，這些都是數據治理中低垂的果實，但一旦要進行三份數據的整合，則牽一髮而動全身，你得權衡利弊，尋找最佳方案。

比如要對A1、A2兩類單據進行整合，你得分析兩類單據字段上差異，A1單據共涉及相關表14張，1346個字段，A2單據涉及相關表43張，2262個字段，雖然兩者的源頭一致，但數據的時延、粒度等由於應用的要求已經有很大的差異，因此需要進行詳盡的差異性分析，最後的整合策略往往是妥協的結果。

又比如要對A1、A3進行整合，發現A1僅保留15天，需要全量字段，而A3雖然只有幾個字段，但卻需要保留180天，合併的價值很低，但改造代價卻很大，如果為了治理而治理就缺失了意義。

因此，針對A1、A2、A3三份數據，最後的策略就是A1與A2大部分合並，但A3作為應用單獨保留。

你看，做數據治理從來不是你痛下決心搞標準化就可以搞定的，還是要尊重現狀，給出當前階段對企業最有利的解決方案。

我們以前做指標口徑的統一也一樣，往往是既要建立一套標準化的指標體系，也要保留個性化指標部分，你強制管控，走理想主義，最後的結果就是失敗。

7、預期的治理效果

前面說了這麼多方案，最終就是要明確告訴公司這個數據治理方案能帶來什麼樣的收益，所謂的臨門一腳，否則，前面做得再多也沒有意義。我們很多的數據治理工作卻往往難以跟領導說清楚效果。

多年前做元數據，採購了元數據軟件，SQL解析等功能做了一大堆，轟轟烈烈的完成了項目，但最後卻說不清到底給業務上帶來了什麼價值，你問運維這個血統分析對你有用嗎？他跟你笑笑，好像有用吧，但點擊情況出賣了所有人。

你會發現，項目經理僅僅為系統上線負責，卻沒有人為最終的效果負責，沒有一個人是利益相關的。

我們這個數據治理方案最終會帶來什麼效果呢？

很明確，存儲壓降XX%，節約費用XX萬元，A1、A2融合後只保留一份，A2複用A1的建模結果，降低未來投資的需求。

8、落地的演進策略

數據治理工作涉及的面很廣，無法畢其功於一役，因此，要清單式的列出多方的具體工作內容，如下圖所示，比如A3的從HBASE存儲改為HIVE的策略，就涉及應用和數據的並行改造，時間跨度很長，不能由於數據治理的要求影響前端使用。

然後按照難易程度給出實施優先級，比如我們就給了個三階段的目標。第一階段：單據的獨立瘦身；第二階段：單據的融合演進；第三階段：數據的統一管理。

9、老闆的終極彙報

完成了方案後，數據管理組織就需要代表各方去跟老闆進行最終的彙報，無論前面的梳理如何繁瑣、雙方的分歧有多大、技術方案有多複雜，但給老闆呈現的方案一定是清晰的、可落地的且效果可期的。

筆者當時作為代表去做了彙報，現場黑壓壓的來了幾十號人，因為涉及的面太廣了，大家也都是利益相關著。具體過程就不說了，下圖是簡化的總體思路一頁。

10、項目的落地實施

經過前面的九步，我們才最終走到了第十步，進行真正的落地實施。但所有的思路，方向和內容，都已經在前九步明確掉了，你會發現數據治理最艱難的部分，其實就是說服各方形成方案的過程。

很多企業採用外包的方式進行數據治理，但你會發現，前面九步跟企業現狀有千絲萬縷的關係，如果你自己都理不清頭緒，何況外人乎？

你也會發現，數據治理要實施成功，對於組織的挑戰特別大，即使公司設立了大數據中心這種統一的組織，但並不意味著在那裡簡單的發號施令就可以搞定一樣事情，而是要能夠串接起各方力量，讓大家為同一個目標而奮鬥。

筆者剛接到任務的時候，最擔心的也不是什麼技術，而是想著如何跟外部門的領導協調好，才能為後續的工作鋪平道路。作為數據治理的負責人，你既要知數據，又要懂管理，還要會實施，最後還能運營，一不小心就會搞成爛尾樓。

因此，雖然我們有DAMA的指導，但數據治理更是一門實踐的學問，必須要結合企業的實際才能真正的做成事，數據治理的複雜性也不是一般人能想象的。