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

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

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

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

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

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