大數據時代的到來，讓政府、企業看到了數據資產的價值，快速開始探索應用場景和商業模式、建設技術平臺。這無可厚非。但是，如果在大數據拼圖中遺忘了數據治理，那么做再多的業務和技術投入也是徒勞的，因為很經典的一句話：Garbage in ，Garbage out，數據質量沒有保證。而保證數據質量，數據治理是必須的手段。數據治理這個話題看似陽春白雪高大上，實際上是非常下里巴人接地氣，或者說必須要頂天立地才能見實效。頂天是指，與信息化類似，數據治理也是一把手工程，沒有高層推動、在業務與業務間、業務與技術間協調，數據治理無法落地；立地是指：一般是IT人員對數據問題有深刻體會，也是IT人員最先意識到數據治理的重要性，而且數據治理最終是在IT層面落地的。1.1 數據分類言歸正傳，首先是基本概念部分，既然談到數據，首先要看一下數據的分類。其實筆者有點擔心提到“分類”這個詞，因為每個人、每個角色分類的視角都是不同的，各有道理。這里所提的數據分類，是指在企業信息化領域做數據治理通常的分類方式。有其他方式也歡迎提出來大家一起探討。我們通常將數據分為：主數據、交易數據、參考數據、元數據和統計分析數據（指標）。上一張圖來說明：

為什么要談數據分類，因為對每類數據進行治理時，關注點、方法和效果都不同，需要區別對待。下面談一點筆者個人的理解：主數據關注的是“人”和“物”，主數據管理（MDM）是數據治理領域一個專門的話題，其主要目的是對關鍵業務實體（如員工、客戶、產品、供應商等）建立統一視圖，讓客觀世界里本是同一個人或物，在數據世界里也能做到唯一識別，而不是在不同系統、不同業務中成為不同的人或物。主數據管理在各行業企業已經有大量的實踐，受限于時間，今天不單獨展開，其核心管理思想是和后面要談的數據治理方法一脈相承的。交易數據關注的是“事”，交易數據沒有形成單獨的數據治理領域，由于交易數據是BI分析的基礎，因此往往在數據質量管理中重點關注；參考數據是更細粒度的數據，是對“人”“事”“物”的某些屬性進行規范性描述的，對參考數據的管理一般會與主數據管理同時進行，或與BI數據質量管理同時進行，因為指標維度和維值直接影響到BI數據質量；元數據是一個包羅萬象的概念，其本質是為數據提供描述，所以任何數據都有元數據。數據治理領域的元數據，更多是指BI、數據倉庫這個范疇內的元數據（國際上有Common Warehouse Meta-model規范），此外還有信息資源管理的元數據（如Dublin core協議）、地理信息元數據、氣象元數據等等。正因為如此廣泛，也造成了從業者對其有極高的預期以及實踐后的極大失落。多說兩句元數據：筆者從事過4年左右元數據管理的產品設計和方案規劃，但現在極少談“元數據”，而是談“數據定義”，談數據必談定義，但卻又不將其作為專門一類數據來管理，在數據治理領域單獨做元數據管理，收效甚微。主要原因有兩點： 數據生產與數據管理脫節，元數據管理更多是在數據生產的事后進行元數據收集和應用展現，對數據生產起到的管控作用極小。 工具自身問題：雖然很多工具都號稱支持CWM規范，但元數據自動獲取始終是技術難題，而且對于存儲過程、自定義腳本很難自動解析和獲取，就無法準確、完整展現細節的數據處理過程。 統計分析數據（指標），無需多言，目前BI系統建設的主要作用就是做各種指標和報表的計算和展示。指標往往是數據治理的重點，指標的數據流分析、指標數值的波動性、平衡性監控，幾乎是各個企業做數據治理的必備應用。

1.2數據治理

談完數據分類，再來談“什么是數據治理”。數據治理的英文是DataGovernance，不同軟件廠商和咨詢公司給出的定義也會有所不同，但本質都是相似的。這里引用《DAMA?數據管理知識體系指南》一書給出的定義：數據治理是對數據資產管理行使權力和控制的活動集合（規劃、監控和執行）。數據治理職能指導其他數據管理職能如何執行。可能有些抽象，有圖有真相，下面這張圖說明了數據治理與其他幾個數據管理職能的關系：

可以看到數據治理貫穿在數據管理的整個過程中，重點關注的是有關數據的戰略、組織、制度等高層次的話題，并通過制定和推行戰略、組織、制度，將其他幾個數據管理職能貫穿、協同在一起，讓企業的數據工作能夠成為一個有機的整體而不是各自為政。有關DataGovernance的中文翻譯，國內最常見的翻法有兩種：數據治理、數據管控。國內客戶似乎更喜歡數據管控，因為這個詞有力度、體現權威。筆者從實踐層面的體會：治理與管控缺一不可，治理在前、管控在后，治理針對的是存量數據，是個由亂到治、建章立制的過程，而管控針對的是增量數據，實現的是執法必嚴、行不逾矩的約束。為什么要做數據治理？下面是一份國際數據質量協會的調研結果可以參考。

從理論上來講數據治理主要是三個目的：保證數據的可用性、數據質量和數據安全。而在實踐層面，國內外談到數據治理，其主要目的都是數據質量，對于數據安全，往往是有專門的團隊和管理舉措，從數據治理領域涉及的較少。我們下面的討論也繼承這種習慣，主要探討數據質量這個目標。概念探討先告一段落，后面在探討方法和實踐的時候，會反過來對概念有更好的理解。

二、數據治理的方法

在方法部分，主要講三個內容：誰負責數據治理？治理或者管控對象是什么？技術工具有哪些？

2.1組織架構

首先來談誰負責數據治理，也就是組織架構，先上一張圖。

從理論和國外實踐來看，大型企業會建立企業級數據治理委員會，有業務部門領導、IT部門領導共同參與，讓業務與業務之間、業務與技術之間能夠有更充分的討論溝通，從而對宏觀的數據戰略、制度達成共識。在企業級之下，還可以有部門級、項目級的委員會，負責某些局部的數據治理，在最基層面向某一個業務領域應該有相應的數據管理專員（DataSteward）。Steward實際上是管家的意思，但翻譯成管家似乎不夠嚴肅，因此采用了“專員”。Steward一詞與Owner相對應，說的是雖然資產不是歸Steward所有，但是他們替Owner代管，由此也衍生出Stewardship一詞，表明代管、托管制度，這里面蘊含了一種兢兢業業、克己奉公的管家精神，何其難得！數據治理委員會、數據管理專員會制定出一系列數據相關的標準和制度，由數據管理服務組織（DMSO）去執行。從圖中可以看到，DMSO實際上是信息化建設團隊，他們負責數據倉庫、數據集成等技術平臺建設。上面談的是理論和國外，在國內的情況剛好相反，DMSO是主力軍，因為大家普遍“重功能、輕數據，重技術、輕管理”，絕大部分企業是缺失左側的委員會等管理角色的。據筆者的經驗，國內大型銀行在這方面做得相對領先，企業級數據治理委員會或者專職的部門去推動數據治理；能源行業對數據治理的接觸和認同程度比較高，開展了不少數據治理項目，特別是在主數據管理方面。運營商更重視技術手段，數據治理體制機制有待建設、健全。整體而言，國內在企業層面成立數據治理委員會的不多，更多是將數據治理的工作放在“企業信息化領導小組”推動，由信息部門負責具體落實執行。而有些企業雖然信息化水平很高，但信息化建設未實現信息部門的歸口管理，這對數據治理的推行帶來了極大挑戰，跨部門、跨系統的協同異常艱難。

2.2?治理/管控對象

這個部分主要是筆者個人實踐經驗的總結，可能和國外的一些理論不一樣。個人總結為“內容管控”和“過程管控”。此處用了管控一詞，體現一些管理的“力道”。

2.2.1內容管控

先說內容管控，數據在信息系統中是以不同形態體現的，需要將每種形態管理好，才有可能管好最終的數據質量。上一張圖來說明：

從宏觀到微觀，數據的形態體現為數據架構、數據標準和數據質量標準。

數據架構，包括了數據模型（概念模型、邏輯模型）以及數據的流轉關系，一般在企業級和系統級會談數據架構，主要對企業數據的分類、分布和流轉進行規劃、設計，確保新建系統、新建應用能夠與現有系統保持一致和融合，避免產生信息孤島，或者帶來重復不必要的數據集成、數據轉換。

數據標準，包括了數據項、參考數據、指標等不同形式的標準。舉例來說，“客戶類型”是一個數據項，應該有統一的業務含義，將客戶歸類為大客戶、一般客戶的規則是什么，數據項的取值是幾位長度，有哪些有效值（如01，02，03）等。這方面有國際標準可以參考，如ISO11179，國內很多行業也制定了行業數據標準，如電子政務數據元、金融行業統計數據元等等。共同的問題是，標準定義出來之后，執行的情況怎么樣？是否真正落實到IT系統了？

數據質量標準，包括數據質量規則以及稽核模型（即規則的組合應用）。數據質量規則一般會關注及時性、準確性、完整性、一致性、唯一性等，展開來談還有許多內容，有的專家整理出12個數據質量維度，有定性的也有定量的。

IT部門應該牽頭制定并且定期更新企業級的數據架構、數據標準和數據質量標準，作為新建系統和應用的指導約束。值得注意的是，在標準制定的過程中，要避免IT部門的閉門造車，一定要讓業務部門充分參與進來。

舉一個例子，筆者個人作為技術人員參與一次數據架構的規劃，需要設計數據的流轉關系。筆者發現從技術角度看，數據從哪流向哪里似乎都是合理的，也都可以有相應的工具去支撐，似乎沒有什么可以決策的依據。其實，這時就應該有業務的參與，因為業務職能、業務流程和業務部門間的職能邊界劃分，直接決定了數據來源和去向，IT部門更多是從技術層面考慮具體實現方案。

2.2.2過程管控

這里談的過程，是指信息系統建設過程。因為經過大量的實踐我們發現，數據質量不佳主要原因之一是在信息系統建設的過程中忽視了對數據的管控，這就會造成數據的設計與需求不一致，開發與設計不一致，對數據質量要求考慮缺失，不同系統對數據的定義和技術實現不一致等等諸多問題。等待系統上線后再去解決這些問題，亡羊補牢，消耗資源。

其實，數據管理甚至IT行業都應該虛心向傳統行業學習管理理念。比如制造業的質量管理是在產品生產線各個環節進行質量管控，有些理念也很有啟發：QualityBy Design，質量是設計出來的，不是檢查出來的；Quality check is a cost not benefit，質量檢查是成本而非收益。

筆者公司最近完成了對工廠化的數據生產和管理模式的探索和初步實踐，運行效率、開發維護效率和數據質量都有顯著提升，找機會再分享，提供一張效果圖有些感性認識。

下面是過程管控的示意圖：

這張圖的內容比較豐富，其核心內容是將“內容管控”中形成的各項標準規范注入到通過信息系統建設的生命周期中，通過對系統建設各個階段交付物的管控確保標準規范得到遵從，從而保障數據的標準化和規范化。

過程管控一方面依靠開發管理中的評審機制去落實，另一方面就是靠工具去固化一些標準和規范，做到自動化檢查。在系統上線常態運行階段，注重新的數據需求和數據問題的收集和處理，對標準規范進行優化。

在信息化早期階段ERP、CRM等操作型系統的建設是以功能和流程為中心，而后期BI、數據倉庫、大數據平臺等數據分析平臺的建設是以數據為中心的，這就注定一些傳統方式需要改變，應該更加注重對數據架構、數據標準、數據質量的管控，更加關注數據的生命周期，否則數據分析平臺建設成功的概率不高。

2.2.3技術工具

下面簡單談談技術工具。先上一張圖，這是國外對數據治理關鍵技術的調研結論。

可以看到元數據、主數據、數據質量是主要的技術手段。具體的產品功能不是今天要探討的話題，筆者主要想談一談技術工具在數據治理工作中的定位。與ERP遇到的情況非常類似，國內的客戶往往寄望于上一套技術工具就能包治百病的解決數據問題、提升數據質量。

而實際情況是，如果前面所說的組織架構、內容管控、過程管控等管理機制、技術標準不到位，僅僅上一套軟件工具，起不到任何效果。以上軟件工具的作用又是什么呢？核心作用在于知識的固化和提高數據治理人員的工作效率。

比如，需要手工編寫程序收集的元數據，工具幫你自動獲取；需要人工識別或編寫代碼實現的數據質量檢查，工具幫你自動識別問題；用文檔管理的數據字典，工具幫你在線管理；基于郵件和線下的流程，工具幫你線上自動化。

除此之外，數據治理的軟件工具與其他軟件工具一樣，沒有什么神奇之處，沒有數據治理人員的參與和數據治理工作的推進，軟件也只是看上去很美。這也是為什么數據治理咨詢服務一直有其市場，以及為什么國內大部分單純數據治理軟件項目未能達到預期目標。

三、數據治理的實踐案例

第一個案例是運營商客戶的系統級數據治理，主要的啟示在于：組織架構對于推動數據治理的重要性。

運營商數據倉庫建設已有多年，對元數據管理和數據質量管理一直高度重視。數據質量問題往往是在數據倉庫發現的，而有很大比例問題是由于上游BOSS系統的升級或者數據錯誤傳遞到了數據倉庫。

例如，推出了新產品但數據倉庫中尚未注冊、SIM卡號位數升級但未通知數據倉庫等等。這說明兩個問題：業務人員與分析系統技術人員協同不夠；業務系統與分析系統協同不夠。

因此，數據倉庫的主管方嘗試從集團推動BOSS和數據倉庫的數據質量協同管理，通過幾省試點的方式建立了跨系統的元數據血緣圖、數據質量聯動監控等一系列技術手段去解決問題。

但是，數據質量協同管理的工作終于試點、未能全國推廣實施，其原因主要有三點：

組織上，BOSS系統和數據倉庫沒有實現歸口IT管理、是由平級的兩個處室管理。

BOSS系統業務關鍵性高于數據倉庫。

此工作作為技術工作發起，沒有去爭取業務部門的支持、參與甚至牽頭。

由此可見，組織架構和管理機制不順暢，會制約數據問題的解決，甚至會帶來數據問題。

第二個案例是一個能源行業客戶企業級的數據治理，主要的啟示在于：數據治理既要大處著眼，更要小處著手，而且要善于找時機切入。

該客戶通過信息化規劃設計了企業級數據架構，通過主數據管理項目經過1年時間建立了企業級的主數據標準、實現了不同業務部門對不同領域數據認責（即承擔數據管理專員的角色），又通過數據管控項目理順了業務部門、信息化部門在數據管控工作上的職責，在項目管理辦公室PMO設置了數據管控組對各項目數據統一管控，同時制定了制度、流程和技術標準。組織、制度和標準上都可謂是到位的，但是技術標準的落地工作一直不順利。

舉例來說，以ERP為首的套裝軟件實施團隊對組織機構主數據的標準一直很抵觸，不肯使用8位統一編碼而是使用本地4位編碼。這個問題的影響在只有ERP系統時并不明顯，數據管控組也無法推動8位編碼的應用。隨著項目后期非套裝軟件的建設，系統間的集成需求豐富起來，如果不能統一編碼標準，系統間無法集成。

這時，非ERP系統都遵從標準使用統一8位編碼，ERP項目組不得不讓步，通過映射表的方式實現了4位與8位的編碼映射，確保順利集成。由此可見，組織架構、管理機制和技術標準建立好之后，其推行落地需要找時機，也需要數據治理人員的耐心和智慧，否則只能是紙上談兵。

第三個案例是美國的一個案例，主要的啟示在于：小處著手，可以非常非常小，這對國內客戶喜歡大而全的思路是非常有益的互補。

這個企業也是受困于數據質量問題，希望通過數據治理來解決。但開始時并不知道如何實際操作數據治理，所以他們啟動了一個“企業數據定義”的項目：用6個月的時間梳理現有系統的數據項，識別跨系統、跨業務的數據項作為數據治理的重點。數據項梳理完畢后，他們選擇了7個數據項去重點治理。

注意，只有7個數據項哦！國內客戶一定會認為7個太少，不能當個事情來做。但美國這個企業就是圍繞這7個數據項去調研相關的業務用戶，發現他們的數據使用需求和問題，去分析與這些數據項相關的業務流程和數據流程。后來識別了40多項可以改進的內容，也為數據治理的全面開展積累經驗，在此基礎上制定了總體規劃和實施路線。

四、大數據與數據治理

終于談到了大數據。從前面的討論來看，數據治理大的脈絡并不復雜：對數據資產家底清晰、管理權責分明、建立配套標準規范、確保落地執行，由此去保障數據質量。雖然大數據的規模大、類型多、速度快，但數據治理的原則對于大數據也是同樣適用的。

那么大數據的到來會給數據治理提出哪些新的要求呢？

首先來看《大數據時代》的作者的觀點之一，他認為在大數據時代數據質量不再重要，因為人們需要的是整體趨勢的分析而非精確結果。個人不太同意此觀點，而是認為對大數據而言數據質量更加重要。

作者提的整體趨勢分析僅僅是大數據的應用之一，而從精準營銷、風險識別等應用場景來看，因為數據與運營結合的更緊密、要求數據粒度更細，任何一點錯誤都可能直接帶來業務上的損失；而傳統的指標應用，反而對運營環節沒有如此直接的影響。因此，在大數據環境下對數據質量的需求是提升而非降低。

其次，Hadoop、Spark等大數據技術的應用，對數據治理的技術手段提出新的要求。傳統模式下基于RDBMS進行管理，SQL是通用的數據訪問方式。而在大數據環境中，Hadoop、MPP、RDBMS、Spark并存，如何在混搭的異構環境中實現對數據資產的可視化統一管控，避免大數據系統成為不可管理的黑盒子，這是傳統行業應用大數據技術需要面對的關鍵問題之一。

特別是大數據技術人才目前更多流向互聯網企業，進入傳統行業的少之又少，在人才可得性短期不能快速解決的情況下，需要依靠技術手段來確保傳統企業IT人員能夠對數據資產的可視、可控。

第三，數據安全，或者說數據隱私的重要性比以往有顯著提升，這也需要在數據治理中加強對數據安全的重視。在傳統應用場景中，數據由企業收集，在企業內部應用，數據所有權的問題并不突出。

在大數據時代，數據要更多進行跨界整合、外部應用的商業模式創新，這其中就涉及到更多數據所有權、數據隱私的話題。用戶信息究竟屬于企業還是用戶、在什么條件下企業可以拿來用于商業應用？這些問題的答案還在探討當中，毋庸置疑的是，企業需要在數據治理過程中，需要更加注意數據安全、數據隱私相關的制度和政策。