一文读懂如何实施数据治理？

大数据时代的到来，让政府、企业看到了数据资产的价值，快速开始探索应用场景和商业模式、建设技术平台。这无可厚非。但是，如果在大数据拼图中遗忘了数据治理，那么做再多的业务和技术投入也是徒劳的，因为很经典的一句话：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人员能够对数据资产的可视、可控。

第三，数据安全，或者说数据隐私的重要性比以往有显著提升，这也需要在数据治理中加强对数据安全的重视。在传统应用场景中，数据由企业收集，在企业内部应用，数据所有权的问题并不突出。

在大数据时代，数据要更多进行跨界整合、外部应用的商业模式创新，这其中就涉及到更多数据所有权、数据隐私的话题。用户信息究竟属于企业还是用户、在什么条件下企业可以拿来用于商业应用？这些问题的答案还在探讨当中，毋庸置疑的是，企业需要在数据治理过程中，需要更加注意数据安全、数据隐私相关的制度和政策。