大數(shù)據(jù)時代的到來，大家開始將數(shù)據(jù)當成資產(chǎn)，數(shù)據(jù)管理的意義也越來越大，但很多企業(yè)的數(shù)據(jù)管理工作，都難言成功，為什么？首先來看下數(shù)據(jù)管理的定義：

數(shù)據(jù)管理，即對數(shù)據(jù)資源的管理。按照DAMA的定義：“數(shù)據(jù)資源管理，致力于發(fā)展處理企業(yè)數(shù)據(jù)生命周期的適當?shù)慕?gòu)、策略、實踐和程序”。這是一個高層而包含廣泛的定義，而并不一定直接涉及數(shù)據(jù)管理的具體操作（摘自維基百科）。 與百度百科的定義比較，百度百科的定義針對的是數(shù)據(jù)應用過程中數(shù)據(jù)的管理，即傳統(tǒng)的數(shù)據(jù)管理。 而維基百科的定義更高一層，針對的是企業(yè)數(shù)據(jù)全生命周期所涉及應用過程數(shù)據(jù)的管理，即對數(shù)據(jù)變化的管理，或者說是針對描述數(shù)據(jù)的數(shù)據(jù)（元數(shù)據(jù)）的管理，在此我們稱之為面向應用的數(shù)據(jù)管理。

定義強調(diào)了數(shù)據(jù)管理的手段，但數(shù)據(jù)管理的最終目的是什么呢？雖然當前如DAMA等的數(shù)據(jù)管理書不少，但考慮到數(shù)據(jù)管理體系太過龐大，看這類書往往如盲人摸象，抓不到頭緒。筆者剛接觸數(shù)據(jù)管理的時候，也是云里霧里，本文純粹是個人的一點實踐和主觀看法，沒有高大上的東西，視野也比較狹隘，算是拋磚引玉，實際上，每個企業(yè)都應該建立適合自己的數(shù)據(jù)管理體系。

首先，為什么要做數(shù)據(jù)管理？個人認為，數(shù)據(jù)管理的目的就是讓數(shù)據(jù)變現(xiàn)高效低成本的運作，正如企業(yè)管理一樣，因此，沒想清楚之前，不要盲目開展一個數(shù)據(jù)管理項目，更不要盲目采購數(shù)據(jù)管理產(chǎn)品，首先得問問，做這個事情，能帶來什么價值？
那么，何謂高效低成本運作？首先，要認識到每個數(shù)據(jù)的實際價值，即哪些核心業(yè)務與這些數(shù)據(jù)，這是定方向，其次，安排好數(shù)據(jù)優(yōu)先級，確保正常出數(shù)，最后，淘汰過時和無用的數(shù)據(jù)，即以最小的代價帶給業(yè)務最大的價值。這個認識很重要，記得筆者剛開始做元數(shù)據(jù)管理的時候，是很盲目的，主要致力于工具的考慮，而未深究做事的本質(zhì)，導致做了大量性價比很低的事情，比如總想著如何進一步提升SQL解析能力，將其作為系統(tǒng)成功的第一要務，但這個真的是最重要的嗎？數(shù)據(jù)管理，不是為了管理而管理，沒有明確的目的，就不要開展數(shù)據(jù)管理工作。很多人談到數(shù)據(jù)管理這類基礎(chǔ)工作很難開展，比如領(lǐng)導不理解，做事沒成效，原因往往是自己都說不清楚緣由，這為數(shù)據(jù)管理工作的失敗埋下了禍根。但有了目的和方向還不夠。
搞數(shù)據(jù)的，做事量化是根本，無數(shù)據(jù)，不管理，數(shù)據(jù)管理工作，也需要用數(shù)據(jù)來決策。以下舉例：數(shù)據(jù)模型的應用價值KPI-比如模型提供了哪些間接收入，規(guī)則可以自己定，但指標要能反映模型對于應用的支撐能力數(shù)據(jù)模型的提供能力KPI-比如模型及時正常出數(shù)的情況，要能反映模型的及時率及正確率，是衡量運營能力的一組標準數(shù)據(jù)模型的優(yōu)勝劣汰KPI-比如關(guān)注投資效益比，要關(guān)注數(shù)據(jù)的生命周期管理，投資當然需要，但也要懂得節(jié)省，該轉(zhuǎn)移或刪除的數(shù)據(jù)，就要堅決的執(zhí)行，一張每天10萬數(shù)據(jù)的臨時小表，一年就是3千多萬，如果有100張，那也是不小的投資，家里有余糧，也不能濫用。
明確了目標和衡量指標，接下來就要制定一系列的規(guī)范和制度，所謂無規(guī)矩不成方圓。數(shù)據(jù)管理規(guī)章制定很難，在起步的時候，不要東訂一個，西訂一個，最好的建制方式是圍繞目標邊制定邊實踐，沒有最好的制度，只有適合自己的。下面先做一個衡量數(shù)據(jù)管理能力的評估題目，注意回答不要泛泛而談，一要量化，二要靠機器回答，三要半小時內(nèi)回答。 能否直接給出每張表對于數(shù)據(jù)變現(xiàn)的價值？或假如這張表不出，會帶來多少潛在損失？（虛擬指標都可以）。 能否直接給出每張表的運行質(zhì)量報告？能否根據(jù)優(yōu)先級給出運行優(yōu)化的具體建議？ 哪些表能直接下線？ 你會發(fā)現(xiàn)，要能回答這些問題，不僅僅是建個數(shù)據(jù)管理系統(tǒng)那么簡單，需要制定對應的數(shù)據(jù)管理的規(guī)范和標準。如果需要知道每張表對于數(shù)據(jù)變現(xiàn)的價值，必須有應用跟表的關(guān)系，因此，開發(fā)上線的時候必須制定規(guī)范，起碼要提交映射關(guān)系，同時為了防止兩張皮現(xiàn)象，必須依賴自動化的系統(tǒng)。如果需要知道每張表的數(shù)據(jù)質(zhì)量報告，必須制定相關(guān)的質(zhì)量指標，并能夠及時預警和處理，這個需要一套數(shù)據(jù)質(zhì)量監(jiān)控制度。如果需要確定哪些表能直接下線，必須制定一套數(shù)據(jù)表生命周期管理制度，需要有表的比如血緣和影響分析，否則怎么知道有多大影響？如果要讓運維人員知道這些表誰是誰，則必須有好的數(shù)據(jù)字典，明確表命名規(guī)范和口徑定義，以降低管理成本。如果….你看，所有的數(shù)據(jù)管理規(guī)章制度其實都是為了確保目的達成，由此會延伸出一個龐大的數(shù)據(jù)管理體系，但還是要懂得能抓住本質(zhì)。因為一開始，不可能想到這么多，能做這么多，需從本源開始思考從何入手。以下是XX公司制定的相關(guān)數(shù)據(jù)管理規(guī)范。

說完制度，接下來就提到數(shù)據(jù)管理工具了。它是數(shù)據(jù)管理規(guī)范貫徹落地的強大保障，當前工具越來越重要，筆者的一個經(jīng)驗是，數(shù)據(jù)管理領(lǐng)域，很難靠人肉保障，大多不靠譜且不可持續(xù)，如果面對大數(shù)據(jù)，更加難以管理成功。談一個親身的經(jīng)歷，曾經(jīng)上線了一個ETL產(chǎn)品，然后項目經(jīng)理告訴一切運行OK，然后我說每個接口的運行報告給一個看看，項目經(jīng)理說報表拿不出來，因為產(chǎn)品沒有這個統(tǒng)計功能，人肉看了幾個大致沒問題，然后全量核查發(fā)現(xiàn)，30%的接口有一致性問題，就是因為當時現(xiàn)場少了一個系統(tǒng)統(tǒng)計功能。另數(shù)據(jù)管理的可視化其實也很重要，ETL任務多達上千個，因此，快速判斷任務是否運行成功很重要，以前，管理者拿到的是運維者的報告，但里面可能是有水分的，某天我們做了運維可視化，發(fā)現(xiàn)運行情況遠沒有報告所稱的那么理想，任務大量失敗而掛起，運維疲于奔命去處理問題，而后提交一個完美的報告，而管理者還以為一切OK，冰山下隱藏的問題，遠遠超過管理者看到的冰山一角。當前數(shù)據(jù)管理的產(chǎn)品不少，但很多其實難以達到要求，原因很簡單，數(shù)據(jù)管理工具太靠近上游，越靠近用戶的產(chǎn)品其實越難做抽象，也越難成功。比如一些元數(shù)據(jù)管理工具，很難解決產(chǎn)品中的元數(shù)據(jù)跟生產(chǎn)系統(tǒng)元數(shù)據(jù)兩張皮的現(xiàn)象。因此，筆者更傾向于采用半定制化的產(chǎn)品的，甚至認為，數(shù)據(jù)管理產(chǎn)品是偏垂直行業(yè)的，阿里以前發(fā)布了“數(shù)加”大數(shù)據(jù)系列產(chǎn)品，但其數(shù)據(jù)管理產(chǎn)品很難作為單獨實體獲得成功，只能平臺捆綁。
怎么才算是好的數(shù)據(jù)管理工具呢？個人認為是能夠?qū)?shù)據(jù)管理能力滲透到數(shù)據(jù)生產(chǎn)流程中去。比如以前生產(chǎn)建表，是開發(fā)人員寫代碼建表，雖然建表有規(guī)范，但開發(fā)人員是否執(zhí)行是另外一回事，而且建表注釋寫得亂七八糟，往往需要靠事后稽核，但大家都知道這很不靠譜，現(xiàn)在，我提供一個可視化開發(fā)界面，將建表規(guī)范作為規(guī)則納入系統(tǒng)，強制要求開發(fā)人員在該界面上建表，只要不符合規(guī)范就予以拒絕，比如注釋缺乏，未有分區(qū)鍵，字段定義長度不符，字段命名不符等等。如果有可能，將所有的數(shù)據(jù)管理規(guī)范提煉成規(guī)則，都納入到系統(tǒng)中強制執(zhí)行，數(shù)據(jù)管理就能實現(xiàn)與生產(chǎn)系統(tǒng)的無縫銜接，數(shù)據(jù)管理成為生產(chǎn)的一部分。前面提到的很多元數(shù)據(jù)管理等工具之所以難以成功，往往因為它是一個外掛系統(tǒng)，所有的信息需要事后喂給它，而不是強制的，導致與生產(chǎn)系統(tǒng)變得越來越不一致從而失去信任直至死亡。有人會質(zhì)疑這對于數(shù)據(jù)管理平臺要求太高，對于開發(fā)約束太多，存量改造太困難，的確，這些都是問題，數(shù)據(jù)管理本來就是個難度極高的工作，不做當然也可以，反正也能活，最多運維質(zhì)量低一點，人肉多一點。但如果希望更進一步，就需要付出代價，近和遠，長痛還是短痛，還是需要依據(jù)企業(yè)的實際情況自己作出選擇。現(xiàn)在這類數(shù)據(jù)管理產(chǎn)品也逐步顯現(xiàn)，比如亞信的DACP（不是做廣告）等，也在往這個方向演進，提供從數(shù)據(jù)規(guī)劃、定義、開發(fā)、預警、調(diào)度、安全等全套功能，并且具備跨平臺的透明訪問能力，我前面提到的半定制化就是指這類產(chǎn)品還需要不斷根據(jù)客戶要求去新增功能，比如H B A S E，R E D I S等各類組件的接入能力。DACP這類產(chǎn)品，似乎也秉承了開發(fā)運維一體化（DevOps）的概念，在開發(fā)階段就開始考慮數(shù)據(jù)運維中的大量問題，所以它能去做，也跟數(shù)據(jù)開發(fā)的一些特點相關(guān)，比如大多數(shù)據(jù)開發(fā)都遵循表-代碼-表-代碼這種邏輯，相對于其它領(lǐng)域要簡單的多，而且，在開發(fā)和運維天生的矛盾中，也似乎能達到一種微妙的平衡，畢竟，做數(shù)據(jù)開發(fā)的，本身會非常關(guān)注業(yè)務和數(shù)據(jù)定義，而做數(shù)據(jù)運維的，理解業(yè)務往往也是必須的，畢竟要做大量數(shù)據(jù)稽核。數(shù)據(jù)管理工具是種輔助手段，是否采用，采用哪種，都依賴于企業(yè)基于性價比去做選擇。
接下來，提一個關(guān)鍵的一點，即管理者的態(tài)度。數(shù)據(jù)管理是個系統(tǒng)工程，你去看DAMA，DIMM等內(nèi)容，都將其上升到企業(yè)戰(zhàn)略這個層面去談，但企業(yè)即使有了數(shù)據(jù)戰(zhàn)略又如何，再好的規(guī)劃也趕不上變化。管理者始終關(guān)注的是效益，數(shù)據(jù)管理也不例外，因此，說服管理者，也應該堅持“效益導向，能力建設(shè)”的原則，堅持向數(shù)據(jù)要收益，比如一個企業(yè)，垃圾數(shù)據(jù)和冗余數(shù)據(jù)占據(jù)了很多空間，做好這類管理可以省一大筆錢，核查問題也一樣，原來看文檔抓人，現(xiàn)在查系統(tǒng)，哪個更有效？現(xiàn)在IT企業(yè)人來人往，沒個知識庫，系統(tǒng)重翻或新人培養(yǎng)，代價有多大大家都清楚的很。數(shù)據(jù)管理也涉及企業(yè)很多流程的再造和新機制的建立，比如規(guī)范開發(fā)流程，影響也是全方面的，必須獲得管理者的支持，否則舉步維艱。

最后，還是要提一下人。這個是最最重要的是，數(shù)據(jù)管理是個專業(yè)化的工作，需要專門的人沉下心去做這個事，不要搞什么兼職（估計是常態(tài)吧），那也是扯淡的事情，一個數(shù)據(jù)管理項目的失敗，往往是自己投入不足，堅持不足所致。人才始終是數(shù)據(jù)管理的第一要務。