| 编辑推荐: |
| 本文来自于itpub，本文主要介绍了数据治理遇到的困难，通过什么样的方式才能保证数据治理的落地以及数据模型的管控方案。 |
|
我主要想和大家分享一些数据治理的经验和数据模型管控的方法。其实数据治理的难度很大，因为牵扯的东西太多、外围的环境太复杂。尤其是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系统建立的非常快，仅仅一年就全部建立起来了，而且效率非常好、质量也很高。这里还有一个非常值得我们借鉴的地方，就是他每个项目组里一定有一个专门的人去负责数据架构，每一个模型之间有一个模型负责人，上面有一个总负责人来负责整个数据架构的管理。 |
