01、寫在前面

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

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

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

02、現(xiàn)狀描述

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

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

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

DAMA車輪圖演變

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

03、現(xiàn)狀問題

一、從數(shù)據(jù)來源方面看

有數(shù)據(jù)標(biāo)準(zhǔn)卻很難執(zhí)行，無數(shù)據(jù)標(biāo)準(zhǔn)則更是頭疼。

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

二、從數(shù)據(jù)處理方面看

缺乏數(shù)據(jù)處理基準(zhǔn)、標(biāo)準(zhǔn)、原則和流程，摸著石頭過河，偶爾搬起石頭手滑也會(huì)砸到自己腳，這些都是常態(tài)。

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

三、從數(shù)據(jù)使用方面看

按照既定需求提供的數(shù)據(jù)并不能達(dá)到預(yù)期的使用效果，不是數(shù)不對(duì)，就是數(shù)不準(zhǔn)，問題根源很難找到并解決。

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

四、從其他方面看

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

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

04、解決思路

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

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

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

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

05、寫在最后

都說數(shù)據(jù)治理項(xiàng)目是“一把手工程”，是“永不交鑰匙工程”，一把手真的比門把手都忙，先想想：

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

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

• 咱該如何做好這類產(chǎn)品呢?
• 咱該如何做好這類咨詢項(xiàng)目呢?
• 咱該如何做好這類實(shí)施項(xiàng)目呢?
• ……

編者按：本文作者志明，IT&DT從業(yè)十余年，主要關(guān)注數(shù)據(jù)管理、數(shù)據(jù)治理、數(shù)字化轉(zhuǎn)型、項(xiàng)目管理等相關(guān)領(lǐng)域，擁有CDGP、CDGA、PMP、IPMP等認(rèn)證。