数据治理之数据模型管控方案

我主要想和大家分享一些数据治理的经验和数据模型管控的方法。其实数据治理的难度很大，因为牵扯的东西太多、外围的环境太复杂。尤其是IT系统建设到一定程度的时候，你才开始做数据治理，难度真的会非常大。数据治理的技术问题不大，但是想要落地却不是那么简单。我主要讲解2个方面的内容：第一个是数据治理遇到的困难，通过什么样的方式才能保证数据治理的落地。第二个是数据模型的管控方案。

从去年的后半年开始，我们就可以非常明显的感觉到传统行业都开始做数据治理了。最近，我去过至少20家左右的银行，他们无一例外都在做数据治理。他们通常的做法是先找咨询公司做咨询，做完咨询之后开始往下一步走。一般咨询公司都是做两件事。第一个是设计数据主题域，其实就是业务元数据，把企业的数据分成几个大的主题域，并定义每个域里面包含哪些数据项。第二个是定义数据标准，主要是定义业务用语，包括它的内容、英文含义等等。做得深入的一些企业，数据治理成果在数据仓库建设过程中可能已经落地，但是效果不是太好。还有一些企业可能有自己的数据部门，比如跨区域性的银行的数据部门可能有十几个人左右、地区性的银行可能只有四五个人。

IT建设从60年代开始，软硬件技术在发生翻天覆地的变化，但是数据方面的技术和应用却在不断深化，从最早的数据应用、存储到现在的数据分析、管理、统计、整合、挖掘等。

大家有没有思考过为什么从去年的后半年到今年为止，数据治理会这么火?前两年很多企业都在做大数据应用，但是传统企业几乎都是很惨烈的失败了，为什么?技术人员说数据质量太差了，然后领导就会问怎么办?那就做数据治理呗。基于这个原因，今年有很多企业在尝试做数据治理。

现在，数据治理已经是一个普遍的话题了。前两年我还在给大家宣讲什么是数据治理?怎么做数据治理?现在不用讲这个事情了，我去很多客户发现他们已经在做了。

大家可以看一下这个趋势，就会发现2-10年间，数据治理方面的技术需求一直处在上升期，图中标注为红色的部分都是与数据治理有关的技术需求。

数据质量问题是一个历史问题，并不是做了数据治理就能完全解决，只能是在一定程度上有所缓解，从制度上、工具上、流程上有所保障。

上图是数据治理在国内的发展变化。14年之前，我一直在给大家宣讲什么是数据治理?什么是数据架构?为什么一定要做数据治理，不做的话会带来什么问题。但是有很多人觉得这个东西太虚了，离他太远了。有些大企业的IT全部是外包，他们只负责管理，在买来的半成品或者成品的软件中数据标准是不可能被使用的。有时，我建议一些企业管理数据模型，他们觉得没必要，同时也没有人力和精力去管理，需要开发的时候就外包。

早些年这种现象特别普遍，但是随着大家对数据的理解越来越深，尤其是从今年开始，这种情况逐渐发生变化，大家已经进入到第二个的阶段了。我预测16-18年一定是个高速的发展阶段，这种项目从咨询开始到落地大概需要一到两年的发展时间，那么到18年，第一期的效果就会展现出来。所以说经过16-18年的高速发展之后，企业会对数据治理和落地方式有一个全新的认识，也会找到一种适合自己企业的方案。

18-22年的4、5年时间一定是成熟发展的阶段，数据质量的治理是一个长期的过程，不可能一朝一夕就解决问题，所以我认为18年以后是一个长期的过程。

数据治理的发展其实也是数据发展的方向，做数据治理和从事数据方面的技术人员不妨可以朝这个方面去努力，我认为路还很长，未来一定是大有可为的，大家会越做越有经验、越做越深。

我个人认为可以从三个方面来看数据治理的项目：第一个是目标。企业数据治理的宏观目标就是为数据应用、项目管理、项目开发提供数据支持，提升数据获取、共享或数据规划的能力。具体目标是构建数据标准，数据模型、提升数据质量。另外就是要构建一套适合自己企业实际情况的数据治理体系，这里面包含内容的梳理、数据标准、数据模型。有些企业将数据标准分成2部分，一个是业务的，另一个是偏技术的。管理流程，要有相应的人员和相应的流程来保障数据管理的落地，以及数据治理平台的构建，还要构建一套自动化校验体系。

第二个是项目成功的要素。依照我多年的经验，如果数据治理从以下四个方面着手的话，或大或小都会获得成功。首先项目实施的人员一定要有经验，如果没有经验的话会有很多弯路要走。另外，前期数据标准的制定、数据模型的设计都需要技术有非常丰富的经验人员。其次，要基于数据架构去做数据治理。第三，要有一套管理流程，这个流程是要通过软件把流程部署到产品里面，然后管理起来，同时要可以进行校验。最后是数据可视化，数据治理方面的数据可视化说的更详细一些是元数据的可视化，不管是业务元数据还是技术元数据都要有一定的可视化。

下面我们来详细介绍一下这四个方面的内容。

1.实施人员必须具备丰富项目经验，提供可落地方案

这一部分没有什么可多说的，数据治理的实施人员如果没有5-10年的经验，那么一定会出现很多问题的。

2.提供基于数据架构的数据治理体系

这个架构里面包含了业务架构、应用架构、数据架构，业务部分其实包含了2个部分，数据部分和功能部分，把业务描述里的数据提取出来，就是将来数据治理的对象。所以它一定是首先基于首先业务架构，然后才是应用架构。

那么什么才是数据架构，数据架构里面包含什么呢?主要包括数据标准、逻辑模型、物理模式等内容，其中我们一直强调数据标准化一定要做到单词级的标准化，什么叫单词级的?假设用户是一个单词，姓名、电话、地址分别是不同的单词，这些单词可以拼接成用户姓名、用户电话、用户地址等等用语。接下来为单词定义英文缩写，英文单词缩写与缩写，便可按照一定规则拼接字段名，这种方法很容易在开发过程中落地。逻辑模型向物理模型转换的过程才能基于数据标准去做。紧接着就是要根据业务功能和数据功能去设计模型，设计逻辑、继承关系模型。数据收集，包括数据域。最后是工具和流程的使用。

数据治理很多年前就已经在做了，但是为什么不成功呢?主要原因就是大家都在做偏向业务元数据的治理，而没有基于此对技术元数据做很好的设计和治理。为什么不做呢?究其原因就是太难了，拿着一套标准体系要求开发人员按你的要求去做开发，那是几乎不可能的事情。失败的案例太多了，很多领导对数据治理都失去信心了。所以，大家又换了一个高大上的名字叫数据资产化，通过数据治理将数据变成资产。其实，无论它的名字叫什么，其实都是在做一样的事情，只要产品想要落地，那么模型里一定要应用标准。只有基于业务和应用架构去做，才能在最后实际生产环境里面落地和应用。

3.提供管控型管理流程和自动化应用数据治理系统

之前数据治理不成功的原因还有一个就是管理。数据治理做完之后肯定要通过软件来管理。在设计和开发阶段都按标准来管理，那么测试、上线、运营的时候也会有一些相关的数据要管理起来，那么怎么管呢?如果是要人工加载的话，那么势必得派一个人专门去管理，如果没有专人管理，时间一长，实际生产系统和数据管理系统就完全脱节了，时间再一长的话，这个东西就没有价值了，那么也就意味着这个项目失败了。

这时我们应该改变思路，采用管控型的数据治理方案。数据标准在设计阶段或者分析阶段设计完之后，到模型设计的时候，只要把逻辑模型建完，物理模型就千万不要动了，逻辑模型向物理模型转换的时候一定是基于数据标准去转换的。所以说从逻辑模型向物理模型转换的时候，一定是要基于前面设计的数据标准去做，数据治理和生产系统只有在这里才可以合并，如果合并不了的话，后面又会出现问题。原来是两套并行的生产线，一定会在某个情况下有交叉点，交叉起来后面事情就简单了，现在有大量的工具可以保证数据治理成果的落地至生产系统的设计、开发、测试、运维等阶段。

还有一个比较重要的部分就是单词，单词的英文缩写，包括域的英文缩写都要做到标准用语中去才好落地。如果做不到这个程度的话那就很麻烦。就像我前面介绍的，逻辑设计完成之后，就不需人力参与了，物理转换以及脚本生成全部由工具的实现。

4.提供可视化和共享知识库的数据治理系统

可视化的方法有很多，只要能把东西展现出来就可以。这里重点强调一下可视化数据模型。很多企业数据库里的很多数据是说不清楚的，所以一定要通过模型来管理。

校验一定要有一套自动化的校验工具。标准数据模型在一定程度上是可以实现自动化校验的，但是无法实现100%校验。不管是开发人员还是测试人员都需要制定一些规则去校验，只有校验了才能及时发现问题，比如，把员工的同义词定为职员或者管理员，可能在使用过程中，大家没有使用标准用语，这边是职员、那边是员工，但是自动校验工具可以自动把它们都转换成员工。校验可以避免在使用中出现错误的使用或不正确的使用。

现在知识库做的并不复杂，基本不会出现问题，但是有些大企业是数据质量一套库、数据标准一套库、数据模型一套库，数据库一套库，但是最终的数据治理只能用一套知识库来管理，否则的话，像构建IT系统去构建数据治理体系，肯定也会出现问题。因为你的标准是企业级的，那么就要覆盖企业的各种业务系统，如果你拆分在不同的系统里面或者不同的应用里面，就无法实现企业级。我们做数据治理的最终目标一定是面向企业，而不是面向某个部门或者某个业务系统，所以我建议一定要有一套统一的知识库来实现数据治理。

为什么要做数据模型管控?数据治理最核心的就是数据模型管控，我们先看看现在都存在哪些问题。第一个是生产库里面存在大量的字段和表没有注释，意思含糊不清，同名不同义、同义不同名，冗余字段、枚举值不一致的现象是普遍存在的，这些问题都会直接影响到你对数据的识别。举个例子，有一家很大的公司要做新一代的CRM系统，在过程中发现普遍存在上述的问题，因为很多人都离职了，而且环境换了很多次，所以没有办法只能把核心的功能改造了，把剩下的功能直接原封不动的迁移过去。所以，如果不做数据模型管控，那么这些历史问题会给新一代系统改造带来很多困扰。

第二个问题，模型变更前的合理性是没有任何判断的。很多项目都是以开发为主，开发人员说变就变。管理稍微好一些的企业可能会去追究变更是否合理。但是很多企业是不管的，任由开发人员变更。

第三个是修改过程中缺乏监管和管理，因为有很多模型变更的评审通过了，但是变更的过程是否按照原来的标准变更是不得而知的。

第四个就是大家经常会遇到的问题。因为工期特别紧，有的时候就直接写脚本进生产库了，变更完之后没有人知道。但是要上线时出现问题了，回头调查问题的时候发现，原来是谁给某个地方加了个字段或者加了一个表，但是这个问题解决之后就又不管了。所以我们经常说，很多企业的数据模型就是一个黑盒子，好多大型业务系统里面表结构几万个，能说得清楚的也就一两百个，这是一件多么可怕的事情!

下面我们来总结一下这些问题。第一个是审计工作或者评审工作的缺失，评审有没有指标?变更合不合理?人员能力够不够?第二个就是管理流程缺失，没有把数据模型变更的事情纳入到开发管理的流程体系里去。第三个方面缺乏管理工具来辅助我们完成这件事情。第四个是没有弥补措施，一旦发现问题了，没有很好的弥补措施。

如何解决这些问题呢?我认为应该从这三个方面去着手：第一个是岗位设置;第二个是管理工具;第三个是管理流程。

岗位设置方面，我认为一个企业里面最少得有一个架构师，来做数据建模、数据标准管理、数据质量方面的工作。前期管理是有很大帮助的。管理工具方面是指要有数据建模、数据标准变更的工具支撑完成工作;管理流程方面，要尽量说服企业把模型的变更流程纳入到生产管理流程里面去。最后就是事前的监控和事后的弥补措施，数据模型的管控其实应该分成事前、事中、事后三个阶段，其中最主要的就是事前和事后。

银行行业在事前的阶段就做的比较好，在模型变更之前它会有相应的人员去判断变更的合理性。这就说明他们有这样的岗位设置，但是每个企业的审计指标是不一样的，也是需要逐渐去完善的。目前，审计工具没有特别好的，大多数是在靠人力。事中就是监测变更过程中是不是按照原来规划好的去变更。

事后包含两个部分，一个是数据库对象不同版本之间的比对，另外一个是模型与数据库的比对。比如上周的数据库版本、尤其是表里的数据，和今天的版本是不是一致?模型与数据库是否一致?

上图是某个企业的管控模型，大家可以看到他将每个模型都管控起来了，这是一个14年建立的移动行业的企业，它的IT系统建立的非常快，仅仅一年就全部建立起来了，而且效率非常好、质量也很高。这里还有一个非常值得我们借鉴的地方，就是他每个项目组里一定有一个专门的人去负责数据架构，每一个模型之间有一个模型负责人，上面有一个总负责人来负责整个数据架构的管理。