01、寫在前面
熟悉筆者的朋友可能知道，筆者之前做的并非純數(shù)據(jù)相關(guān)工作(產(chǎn)品或項目)，筆者屬于半路出家的數(shù)據(jù)人，之前也幾乎沒有直接接觸過數(shù)據(jù)倉庫、數(shù)據(jù)中臺、數(shù)據(jù)平臺等產(chǎn)品或項目，與數(shù)據(jù)庫是一直打交道。要說真正與數(shù)據(jù)結(jié)緣，那得從16年8月起說起，當時因公司某些產(chǎn)品基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫與一些開源數(shù)據(jù)倉庫產(chǎn)品(如InfoBright)跑一些功能遇到了瓶頸——實在是跑不動。

當年臨時從外地出差項目組抽調(diào)回北京公司總部，從0基礎(chǔ)開始研究開源Hadoop+Hive+Spark[-SQL]+ES集群環(huán)境的搭建，到與產(chǎn)品進行整合，最后就是用一些淘汰的PC服務器和精簡的Hadoop相關(guān)套件搭建起集群解決了當時跑不了、跑不動、跑不完等痛點，也算是小有成就。

期間，遇過不少難題，走過不少彎路，掉進過不少坑，感謝這次機會，讓筆者與數(shù)據(jù)結(jié)緣，之后所做之事就沒離開過數(shù)據(jù)，路雖難，行則至;事雖難，做則成!

02、現(xiàn)狀描述
早些年的數(shù)據(jù)項目大多數(shù)是以“XXX數(shù)據(jù)質(zhì)量校驗”、“XXX數(shù)據(jù)分析平臺”、“XXX大數(shù)據(jù)項目”等常見的名稱進行立項，而近些年多以“XXX數(shù)據(jù)治理項目”進行立項，叫啥不重要，其實所做之事基本上與前面的差不多，無非就是數(shù)據(jù)采集、數(shù)據(jù)清洗、數(shù)據(jù)加工、數(shù)據(jù)質(zhì)量、數(shù)據(jù)建模、數(shù)據(jù)挖掘、數(shù)據(jù)分析、數(shù)據(jù)共享、數(shù)據(jù)應用、數(shù)據(jù)展現(xiàn)(可視化、BI、報表、大屏)，幾乎都是短平快的項目，幾乎也都是基于理想化的前提下進行項目實施，而最具價值的交付成果往往是“大屏”，其實項目目標也是實現(xiàn)了的，也算是MVP，但從長遠角度考慮，還是遠遠不夠的，后續(xù)可能會有很多推倒重來的沖動，而又會顧慮前期的“工作成果”而不停妥協(xié)。

受限于資源與成本(預算)，很難有精力去考慮或沉下心規(guī)劃更高、更深層次的東西，諸如：數(shù)據(jù)管理戰(zhàn)略、數(shù)據(jù)管理框架、數(shù)據(jù)管理文化、數(shù)據(jù)管理組織、數(shù)據(jù)生命周期，及元數(shù)據(jù)管理、主數(shù)據(jù)管理、參考數(shù)據(jù)管理、數(shù)據(jù)安全管理等……學過DAMA-DMBOK2知識體系的都知道，萬變不離其宗，基本市面上絕大多數(shù)與數(shù)據(jù)治理相關(guān)的產(chǎn)品都是基于其知識體系所構(gòu)思和設計研發(fā)的，但是上一套這類系統(tǒng)是否就能徹底解決數(shù)據(jù)治理相關(guān)的問題了呢?

DAMA-DMBOK2數(shù)據(jù)管理框架(DAMA車輪圖)

DAMA車輪圖演變

或許大家都有思考，但是基本上思考這些問題的人往往只有IT部門+外包服務廠商的人員，業(yè)務部門的人員參與較少，也缺乏強有力的“一把手”牽頭，部門墻、數(shù)據(jù)孤島、數(shù)據(jù)煙囪該存在還是存在。

03、現(xiàn)狀問題
一、從數(shù)據(jù)來源方面看
有數(shù)據(jù)標準卻很難執(zhí)行，無數(shù)據(jù)標準則更是頭疼。

大部分數(shù)據(jù)來源于外部(下級機構(gòu)、平行部門、其他第三方)，源頭不可控，源頭數(shù)據(jù)質(zhì)量很難提前預判。

二、從數(shù)據(jù)處理方面看
缺乏數(shù)據(jù)處理基準、標準、原則和流程，摸著石頭過河，偶爾搬起石頭手滑也會砸到自己腳，這些都是常態(tài)。

數(shù)據(jù)處理過程中，通常很難提前知道數(shù)據(jù)質(zhì)量的問題，大部分是做一點冒一點，發(fā)現(xiàn)一個反饋一個，發(fā)現(xiàn)問題的反饋路徑和流程過于繁瑣，或上游也很難在短期內(nèi)改正，甚至改不了。

三、從數(shù)據(jù)使用方面看
按照既定需求提供的數(shù)據(jù)并不能達到預期的使用效果，不是數(shù)不對，就是數(shù)不準，問題根源很難找到并解決。

下游用數(shù)需求無法很好的確認，有的需求變更或新增需求的提出，現(xiàn)有數(shù)據(jù)無法滿足，需要從多方源頭重新找數(shù)。

四、從其他方面看
時間緊，任務重，相關(guān)方支持配合不到位，臟活累活很難被認可，能很快看到漂亮的成果(大屏)，但很難看到漂亮的結(jié)果(數(shù)據(jù))。

工欲善其事必先利其器，而“器”不光指“工具”或“系統(tǒng)”，筆者認為，數(shù)據(jù)治理類項目，人最為重要。

04、解決思路
在筆者所處角色來看，以上很多問題是一個死結(jié)，一己之力根本解不開，但筆者堅信，隨著時間的沉淀，一定會有轉(zhuǎn)變的，數(shù)據(jù)治理的項目也會越來越“好做”。

化繁為簡，一開始不用投入那么多人員，而是組建一個小團隊，先把數(shù)據(jù)一點一點梳理清楚、探查明白，而不是學著別人先做什么組織上的變革，成立什么委員會、辦公室等新組織，大家都很忙，這種事情根本不現(xiàn)實。

實在不行，咱也學學別人，立個純咨詢項目，專業(yè)的事情交給專業(yè)的人去折騰，那么問題來了，外來的和尚真的更會念經(jīng)?

從源頭抓起，有很多工作根本不需要通過數(shù)據(jù)治理工作去解決，絕大多數(shù)問題都是上游系統(tǒng)的設計不合理或BUG造成，如果是內(nèi)部數(shù)據(jù)，可以嘗試從上游系統(tǒng)開始下手，該改設計改設計，該修BUG修BUG，總比在數(shù)據(jù)治理過程中處理要靠譜，治標不治本，成倍耗成本，畢竟上游系統(tǒng)肯定需要一直用，有問題也得改，倒不如前人栽樹后人乘涼，都是自己人，遇事好商量。

05、寫在最后
都說數(shù)據(jù)治理項目是“一把手工程”，是“永不交鑰匙工程”，一把手真的比門把手都忙，先想想：

咱真的需要進行數(shù)據(jù)治理嗎?

見過一些系統(tǒng)，還沒設計/開發(fā)呢，就要求出具針對該系統(tǒng)的數(shù)據(jù)治理方案，前瞻性有必要這么前瞻嗎?咱好好開發(fā)系統(tǒng)，后面直接來個簡單的數(shù)據(jù)抽取入倉進湖不是更好嗎?非得經(jīng)過復雜的ETL過程才顯得數(shù)據(jù)更具價值?