一、前言
　　
　　在大数据时代，几乎所有企业都看到了数据的价值，快速开始探索数据应用场景和商业模式、建设数据中台。但是，如果在大数据拼图中遗忘了数据治理，那么即使做再多的业务和技术投入也是徒劳的，因为很经典的一句话:Garbage in Garbage out，数据质量没有保证。而保证数据质量，数据治理是必须的手段。
　　
　　数据治理这个话题看似阳春白雪高大上，实际上是非常下里巴人接地气，或者说必须要顶天立地才能见实效。顶天是指，与信息化建设类似，数据治理也是一把手工程，没有高层推动、在业务与业务间、业务与技术间协调，数据治理无法落地；立地是指：一般是数据开发和上游使用数据的业务人员对数据问题有深刻体会，也是这批人最先意识到数据治理的重要性，而且数据治理最终也是在数据层面落地的。
　　
　　二、基本概念
　　
　　1.数据分类
　　
　　在谈数据治理之前，我们首先了解一些基本概念部分。既然谈到数据，我们首先要看一下数据的分类。其实我有点担心提到“分类”这个词，因为每个人、每个角色分类的视角都是不同的，各有道理。我所提的数据分类，是指在企业信息化领域做数据治理通常的分类方式。有其他方式也欢迎提出来大家一起探讨。我们通常将数据分为：主数据、事务数据、参考数据、元数据和统计分析数据（指标）。用表1来说明：
　　
　　为什么要谈数据分类，因为对每类数据进行治理时，关注点、方法和效果都不同，需要区别对待。
　　
　　主数据关注的是“人”和“物”，主数据管理（MDM）是数据治理领域一个专门的话题，其主要目的是对关键业务实体（如员工、客户、产品、供应商等）建立统一视图，让客观世界里本是同一个人或物，在数据世界里也能做到唯一识别，而不是在不同系统、不同业务中成为不同的人或物。主数据管理在各行业的企业已经有大量的实践，其核心管理思想是和后面要谈的数据治理方法一脉相承的。
　　
　　事务数据关注的是“事”，事务数据没有形成单独的数据治理领域，由于事务数据是BI分析的基础，因此往往在数据质量管理中重点关注。
　　
　　参考数据是更细粒度的数据，是对“人”“事”“物”的某些属性进行规范性描述的，对参考数据的管理一般会与主数据管理同时进行，或与BI数据质量管理同时进行，因为指标维度和维值直接影响到BI数据质量。
　　
　　元数据是一个包罗万象的概念，其本质是为数据提供描述，所以任何数据都有元数据。数据治理领域的元数据，更多是指BI、数据仓库这个范畴内的元数据。但深入做元数据的专业人士现在极少谈“元数据”，而是谈“数据定义”，谈数据必谈定义，但却又不将其作为专门一类数据来管理，在数据治理领域单独做元数据管理，收效甚微。
　　
　　主要原因有两点：
　　
　　1）数据生产与数据管理脱节，元数据管理更多是在数据生产的事后进行元数据收集和应用展现，对数据生产起到的管控作用极小。
　　
　　2）工具自身问题：虽然很多工具都号称支持CWM（CommonWarehouseMetamodel）规范，但元数据自动获取始终是技术难题，而且对于存储过程、自定义脚本很难自动解析和获取，就无法准确、完整展现细节的数据处理过程。
　　
　　统计分析数据（指标）：无需多言，目前BI系统建设的主要作用就是做各种指标和报表的计算和展示。指标往往是数据治理的重点，指标统一口径、指标统一管理、指标数据质量监控，几乎是各个企业做数据治理的必备应用。
　　
　　2.数据治理
　　
　　谈完数据分类，再来谈“什么是数据治理”。数据治理的英文是Data Governance，不同软件厂商和咨询公司给出的定义也会有所不同，但本质都是相似的。这里引用《DAMA数据管理知识体系指南》一书给出的定义：数据治理是对数据资产管理行使权力和控制的活动集合（规划、监控和执行）。数据治理职能指导其他数据管理职能如何执行。可能有些抽象，有图有真相，国际数据管理协会（以下简称DAMA）把数据管理划分了10个职能，图1说明了数据治理与其他几个数据管理职能的关系。
　　
　　DAMA对10个职能的定义如下：
　　
　　1）数据治理：在数据资产的管理和使用层面之上进行规划、监督和控制。
　　
　　2）数据架构管理：明确定义企业数据需求，设计可实施的实现蓝图，包括企业数据架构和应用系统架构。
　　
　　3）数据开发：数据需求分析、设计、实施、测试、部署、维护等工作。
　　
　　4）数据操作管理：从数据的产生、获取、存档、再到清除的技术支持。
　　
　　5）数据安全管理：定义安全策略与实施方法，提供授权、审计等服务。
　　
　　6）数据质量管理：定义质量衡量方法，运用技术监控和提高数据质量。
　　
　　7）参考数据和主数据管理：管理数据的黄金版本和副本。
　　
　　8）数据仓库和商务智能管理：为分析报告、查询提供技术支持。
　　
　　9）文档和内容管理：管理数据库以外的数据。
　　
　　10）元数据管理：元数据的整合、控制以及提供元数据。
　　
　　可以看到数据治理贯穿在数据管理的整个过程中，重点关注的是有关数据的战略、组织、制度等高层次的话题，并通过制定和推行战略、组织、制度，将其他几个数据管理职能贯穿、协同在一起，让企业的数据工作能够成为一个有机的整体而不是各自为政。
　　
　　因为官方的定义比较抽象，与实际工作相结合，再来理解一下这10个职能，详见图2。
　　
　　1）治理专项PM：数据治理、数据安全、元数据管理按我们现行负责情况都会成立单独的团队来负责，或是单独立项来进行管理。
　　
　　2）数据研发：数据架构（业务数据架构、应用系统架构设计）、数据开发（数据加工处理）、数据仓库（模型设计、层次结构设计）、数据操作（数据集成、数据清理）、数据质量（四个方面的保障）。
　　
　　3）数据分析：商务智能（分析业务场景、定义指标口径、监控数据表现、支持决策分析）。
　　
　　4）数据平台：数据架构（底层数据计算与存储系统的设计与开发）、数据操作（数据操作工具的设计与开发）、数据质量（通用策略定义、辅助工具的开发）。
　　
　　从数据管理工作的各职能和角色来看，数据治理是数据管理中的核心职能，在数据治理过程中要协同与处理的内容是非常复杂的，且很多时候是环环相扣。
　　
　　5）从实践层面对数据治理的体会：治理与管控缺一不可，治理在前、管控在后，治理针对的是存量数据，是个由乱到治、建章立制的过程，而管控针对的是增量数据，实现的是执法必严、行不逾矩的约束。
　　
　　至于为什么要做数据治理？从理论上来讲数据治理主要是三个目的：保证数据的可用性、数据质量和数据安全。而在实践层面，谈到数据治理，其主要目的都是数据质量，对于数据安全，往往是有专门的团队和管理举措。
　　
　　三、数据治理的方法
　　
　　在方法部分，我们主要讲三个内容：谁负责数据治理？治理或者管控对象是什么？技术工具有哪些？
　　
　　1.组织架构
　　
　　首先来谈谁负责数据治理，也就是数据治理的组织架构，图3为阿里数据治理组织架构图。一般大型企业都会建立企业级数据治理委员会，有业务部门领导、数据部门领导共同参与，让业务与业务之间、业务与技术之间能够有更充分的讨论沟通，从而对宏观的数据战略、制度达成共识。在企业级之下，还可以有部门级、项目级的委员会，负责某些局部的数据治理，在最基层面向某一个业务域应该有相应的数据治理专员，这个角色通常由一个经验丰富的数据开发人员担当。说的是虽然数据资产不是归数据治理专员所有，但是他们替表Owner代管，由此也衍生出Stewardship一词，表明代管、托管制度，这里面蕴含了一种兢兢业业、克己奉公的管家精神，何其难得！数据治理委员会、数据管理专员会制定出一系列数据相关的标准和制度，由业务治理、数据平台、协同合作团队去执行。
　　
　　2.治理/管控对象
　　
　　这个部分主要是我个人实践经验的总结，我个人总结为“内容管控”和“过程管控”。此处我用了管控一词，体现一些管理的“力道”。
　　
　　3.内容管控
　　
　　先说内容管控，数据在业务系统中是以不同形态体现的，需要将每种形态管理好，才有可能管好最终的数据质量。从宏观到微观，数据的形态体现为数据架构、数据标准和数据质量标准。
　　
　　1）数据架构：包括了数据模型（概念模型、逻辑模型、物理模型）以及数据的流转关系，一般在企业级和系统级会谈数据架构，主要对企业数据的分类、分布和流转进行规划、设计，确保新建系统、新建应用能够与现有系统保持一致和融合，避免产生信息孤岛，或者带来重复不必要的数据集成、数据转换。
　　
　　2）数据标准：包括了数据项、参考数据、指标等不同形式的标准。举例来说，“客户类型”是一个数据项，应该有统一的业务含义，将客户归类为大客户、一般客户的规则是什么，数据项的取值是几位长度，有哪些有效值（如01,02,03）等。这方面有国际标准可以参考，如ISO11179，行业也制定了行业数据标准，如电子政务数据元、金融行业统计数据元等等。共同的问题是，标准定义出来之后，执行的情况怎么样？是否真正落地。
　　
　　3）数据质量标准：包括数据质量规则以及稽核模型（即规则的组合应用）。数据质量规则一般会关注及时性、完整性、准确性、一致性，展开来谈还有许多内容，有的专家整理出12个数据质量维度，有定性的也有定量的。数据部门应该牵头制定并且定期更新企业级的数据架构、数据标准和数据质量标准，作为新建系统和应用的指导约束。值得注意的是，在标准制定的过程中，要避免数据部门的闭门造车，一定要让业务部门充分参与进来。举一个例子，我个人作为技术人员参与一次数据架构的规划，需要设计数据的流转关系。我发现从技术角度看，数据从哪流向哪里似乎都是合理的，也都可以有相应的工具去支撑，似乎没有什么可以决策的依据。其实，这时就应该有业务的参与，因为业务职能、业务流程和业务部门间的职能边界划分，直接决定了数据来源和去向，数据部门更多是从技术层面考虑具体实现方案。
　　
　　4.过程管控
　　
　　下面说过程管控。这里谈的过程，是指信息系统建设过程。因为大量的实践表明，数据质量不佳主要原因之一是在信息系统建设的过程中忽视了对数据的管控，这就会造成数据的设计与需求不一致，开发与设计不一致，对数据质量要求考虑缺失，不同系统对数据的定义和技术实现不一致等等诸多问题。等待系统上线后再去解决这些问题，亡羊补牢，消耗资源。其实，数据管理甚至IT行业都应该虚心向传统行业学习管理理念。比如制造业的质量管理是在产品生产线各个环节进行质量管控，有些理念也很有启发：Quality By Design，质量是设计出来的，不是检查出来的；Quality check is a cost not benefit，质量检查是成本而非收益。
　　
　　5.技术工具
　　
　　元数据、主数据、数据质量工具是数据治理主要的技术手段。这里我不详细聊技术工具如何在治理中发挥作用，打个广告：在涤生大数据有专门的数据治理项目，这里我主要谈一谈工具在数据治理工作中的定位。从数据治理的实践经验来看，如果前面所说的组织架构、内容管控、过程管控等管理机制、技术标准不到位，仅仅上一套技术工具，起不到任何效果。以上技术工具的作用又是什么呢？核心作用在于治理知识的沉淀和固化以及提高数据治理人员的工作效率。比如：需要手工编写程序收集的元数据，工具帮你自动获取；需要人工识别或编写代码实现的数据质量检查，工具帮你自动识别问题；用文档管理的数据字典，工具帮你在线管理；基于邮件和线下的流程，工具帮你线上自动化。除此之外，数据治理的技术工具与其他软件工具一样，没有什么神奇之处，没有数据治理人员的参与和数据治理工作的推进，软件也只是看上去很美。这也是为什么数据治理咨询服务一直有其市场，以及为什么国内大部分单纯数据治理软件项目未能达到预期目标。
　　
　　四、数据治理的实践
　　
　　这里提供一些思路来帮助大家对数据治理的实操有些定性的认识。
　　
　　1.数据治理实施思路
　　
　　数据治理的实施整体可以分为两大类：
　　
　　1）全局出发：定义数据管理过程中，各职能的规范、标准、执行策略，让数据治理位于其他数据职能之上的控制地位，从而推进执行。这种方式适合从企业管理者的角度出发，同时投入的成本会较大，落地成形的周期会相对较长，但实施成功后是最稳定的。实施结构详见图4所示。
　　
　　2）现有的问题出发：在局部形成解决问题的闭环，定义执行策略，明确执行结果观测指标，以衡量最终完成情况。一般是以事前、事中、事后的流程开展。
　　
　　2.数据治理面对的问题一些解法
　　
　　一线数据研发可以从日常工作中现有问题出发，针对性的制定解决方案，主要从数据质量、数据资产、数据操作及补充完善相应的文档规范。
　　
　　3.数据质量
　　
　　数据质量是数据研发的生命线，交付的数据一定要保证是正确的。面对的问题如表2描述。
　　
　　4.基线延时
　　
　　事后操作：通过基线实例的运行情况，发现耗时长的关键节点，目前是每天由值班同学观测运行情况，手动发现之后通知节点负责人进行调整。
　　
　　事前操作：发布节点上基线时，要对节点任务进行模型评审，确认层次依赖与数据逻辑的合理性，同时监控节点近一周的完成时间是否符合其线要求。
　　
　　5.数据量波动
　　
　　事中操作：对核心的公共层及数据产品交付的表，配置DQC以保证数据量波动较大时得到通知，进一步确认是否在数据同步与计算中发生了异常。
　　
　　6.业务指标波动
　　
　　业务指标波动的监控，可以有两种，尤其对重点业务kPI及运营类指标，一定要有DQC的配置以保证质量。
　　
　　DQC主要监控相关指标间的逻辑关系：如按业务逻辑，A指标一定不会大于B指标等，需要手动写SQL配置到DQC之中。DQC的配置为事中监控。
　　
　　其次，One Monitor可以根据指标运行一段时间的结果：来判断运行结果的波动。One Monitor的配置为事后监控。
　　
　　7.相同指标交付不一致
　　
　　在数据产品的交付结果中会遇到相同指标，在不同产品报表中结果不同，被业务方质疑。指标口径的一致性，一定要控制到事前的监控。一般要经历以下几个步骤：
　　
　　1）数据分析师及产品定义指标，录入指标字典。
　　
　　2）数据研发确认业务逻辑与数据支持情况，录入OneData。
　　
　　3）数据仓库表依据OneData定义引入模型中，且核心公共层数据模型要进行模型评审。
　　
　　4）数据仓库核心公共层表代码，一定要进行codereview。
　　
　　5）开发完成的表，预执行近三天的数据结果，交由数据分析师验证。
　　
　　6）验证通过后，交付上线使用。
　　
　　8.相同维度值域不同
　　
　　与指标相比，维度的管理是比较麻烦的，且在实际工作中维度的拆分与组合，也是数据分析中经常要做的工作。按维度的生产来源，一般有两种类型的维度，原生维度和衍生维度。
　　
　　1）原生维度：是指数据在生产时，维度的值域由产品定义，前端或后端服务生成，会生成码表在数据库中依业务的变化进行维护。这对数据质量来说，是最理想的状态。其次，以硬编码的形式在事实数据中生产，其值域管理的稳定性低于码表的形式。
　　
　　2）衍生维度：来自业务方或数据分析同学基于原生维度的二次映射，非服务端生产数据，由数据研发侧生产。目前衍生维度没有工具支持维度，主要由数据研发在代码中维护，其可靠性也是相对较低的。目前维度的管理没有工具支持，主要依赖指标字典的定义和对数据结果的测试。
　　
　　9.数据资产
　　
　　从BU实际消耗的计算和存储资源出发，对比BU预算，进行治理和优化。数据资产的治理，主要依托于数据资产管理平台，平台中已列出了明确的计算优化项和存储优化项，且每周会有邮件推送给每位同学，这里不做过多的复述，大家可以在平台上了解的比较全面。我们做的更多的是监督执行。需要提出的一点是，对计算和存储中发现的优化问题，要反补到《开发规范》与《模型规范》中，把治理的工作尽量控制到事前。
　　
　　10.数据操作
　　
　　数据操作主要是依据数据资产治理项对数据表下线删除操作。这里要说一个问题，数据资产能发现一部分不再使用表和长周期表，但在实际的治理过种中我们发现应用层交付的数据表，其数量还是很大的，大几千的数量，在这里，我们可以做两件事情来发现其存在的必要性，将无用的表下线。
　　
　　1）事前的操作：加强模型规范与模型评审，明确是否要新增表。
　　
　　2）事后的操作：记录数据产品的访问日志，监控访问频次和目标用户，对低频次和一段时间无访问的数据，确认其存在的必要性。背后问题是，每一次接收的数据需求，要明确真正的业务价值所在。
　　
　　11.文档规范
　　
　　主要完善《模型设计规范》与《数据开发规范》。
　　
　　12.模型设计规范
　　
　　模型设计中通过规范解决的主要问题如下：
　　
　　1）完善源系统调研，并形成文档：源系统调研是模型设计的基础，源系统调研要做的工作如下：
　　
　　（1）明确系统内部的业务过程。
　　
　　（2）业务事件发生时的数据流向。
　　
　　（3）核心数据表及表的ER关系。
　　
　　（4）明确每个核心数据表覆盖的数据范围及字段定义。
　　
　　（5）同时要清楚不同业务系统之间的交互流程，业务系统间发生数据流动时，是由哪些事件触发的。
　　
　　2）补充指标字典
　　
　　指标字典是非常重要的，一定要在需求沟通的过程中沉淀下来，当我们回头去看的时候，大量的时间在沟通指标和维度的定义。指标和维度要按分析主题分类管理和记录。目前指标的管理没有系统工具支持，核心还是以wiki文档的形式在记录。
　　
　　3）避免重复开发
　　
　　避免重复开发核心的解决方案是人工的模型评审。这里需要有经验的同学主导，在评审前要准备好规范中要求的业务文档，如源系统调研文档、指标字典等。由于人员与工作量的关系，人工的模型评审主要是针对CDM公共层的数据表。这里要特别说明的是，模型的设计与评审，目前是没有平台工具在支持的，主要以人工的方式。从集团数据仓库的设计理念上看，核心还是以Kimball的维度建模的思想，个人认为可以形成一套完整的、体系化的工具，逐步完善模型设计的管理。说到这里，有的同学应该会想起OneData，个人在使用OneData后的感受是设计方法是好的,但功能是记录和参考,并没有和数据开发平台之间进行强关系的打通。目前只有在数据开发时使用OneData定义的指标时,数据表才会在OneData中被关联出来,核心还是要看团队的管理和个人素质。
　　
　　4)加强输出表的数据字典描述
　　
　　对开发好的数据表加强数据字典说明,尤其是表的数据范围描述,要让使用的同学尽可能清晰的了解到表的使用方法。在数据地图的使用说明中加入样例SQL,以加强解释说明。
　　
　　5)表命名规范
　　
　　强化数据表命名的监控,通过对元数据的调研,开发脚本来校验每天上线数据表的命名规范性,以T+1报表的形式,将命名异常的数据表发送到团队的邮件组中,以要求命名的规范性。
　　
　　13.开发规范
　　
　　1)数据开发中通过规范解决的问题如下:加强脚本的注释,对核心的业务逻辑,要有注释来明确使用的数据范围,及逻辑的流程。
　　
　　2)运行参数的使用场景及设置方法,以提高计算时效。
　　
　　3)SQL脚本的规则限定,在某些场景下应如何编写,以避免哪些问题。在这个问题上,可以通过配置SQLScan来在提交时校验。
　　
　　4)加强数据测试,目前数据测试可以使用Onebeyond工具来支持,覆盖的测试功能点已很全面。
　　
　　14.需求模板
　　
　　在数据研发过程中,很多时候是要沟通与理解业务,明确要做的数据需求。一个好的需求模板,是可以简化沟通过程,提高沟通时效的。明确的告诉需求方,如果要得到想要的数据,前期应做好哪些准备工作是很必要的。
　　
　　需求模板中一般包括的要素如下:
　　
　　1）需求价值描述,帮助判断优先级。
　　
　　2）需求内容描述,帮助理解需求。
　　
　　3）指标的定义。
　　
　　4）维度的定义。
　　
　　5）数据报表的demo样例（选填）。
　　
　　6）数据的实效性要求。
　　
　　15.问题总结
　　
　　以上问题中总结几点比较重要的内容:
　　
　　1）数据质量:数据质量是数据研发的生命线,也是底线,无论如何都要守住,数据可以不出,但不能出错。一定是数据治理中的重中之重。
　　
　　2）源系统调研:数据仓库核心解决的问题是数据孤岛和数据一致性。不要从一个数据孤岛再建设成另外一个数据孤岛,所以在设计之前一定要做充分的源系统调研。
　　
　　3）数据模型设计与指标字典:核心的问题是缺少平台化的、集成的工具,以进行可靠的管理和设计。大多数时间主要还是以人工的方式在维护。
　　
　　4）需求模板:时效、时效、还是时效,不要把有限时间放到无限的沟通中去。
　　
　　编辑：Harris