2018年12月13日，由中国信息通信研究院、中国通信标准化协会主办，TC601大数据技术标准推进委员会承办的“2018数据资产管理大会”在京召开。Datablau创始人&CEO王琤进行了题为《企业数据资产化之路》的演讲。

王琤

他从数据管理的国际趋势开始，讲述了数据建模的架构，并对传统数据建模和数据模型进行了区分，最后给大家做了一些数据模型在企业中的实践介绍。他向大家分享，企业中的数据建模实践分为三个方面，数据标准的落地，管控的模型，设计态和运行态的一致性。

以下为演讲实录

首先感谢中国信通院给了这样一个平台让各位同业、朋友有一个交流的机会。我把今天会议所有的演讲都听了一遍，非常的精彩，可以看到数据资产管理发展状况百花齐放，既有一些成熟的方法论，还有不同的实践——有主数据的实践、有偏业务咨询的实践。我们的数据资产管理更多的偏技术一点，就是怎么用技术的方式把以前人工要做的事情给它降低成本，更快地、更高效地把这个事做下去。

简单做一个自我介绍，我其实以前在CA做一个产品叫ERwin，年龄大一点的、以前一直做数据领域的朋友可能会用到这样的产品，就是画关系实体图。我以前在大学的时候，学数据库原理交作业就是用ERwin这个产品，很有缘分后来做这个产品做了十一年，负责这个产品的研发，在国际国内参与了很多相关项目，包括大型能源制造型企业，和建行新一代ERwin承载的企业级数据模型。

2016年我出来创业成立了Datablau数语科技，当前是偏产品型公司，做数据治理相关的产品，其他的业务比如做了蛮多的非关系型数据库建模等工作这里就不多说了。

今天我演讲的题目是企业的数据资产化之路，这里有一张图我觉得很好，这是来自于IBM Watson的一张图，现在根据中国的实际情况做了一些稳定化。

我们大家知道IBM Watson更多做的是AI这块的医疗相关分析，比如说癌症分析，从这张图可以看到，Watson是偏AI的但是它更关心的是数据资产。Watson把目前的资产分为四个阶段，第一阶段是数据库运维。这张图有一个虚线，虚线左边是显示数据在IT部门的兜里，IT部门关心的是我是不是能把数据存储出来，我是不是有足够的运算能力，然后出一些业务部门要的报表，这都是IT部门在想怎么利用这个数据。虚线右边跟左边是完全不一样的，虚线右边是说IT部门能不能从兜里面把数据掏出来，掏给不同的业务部门，业务部门发挥自己实际的业务场景，发挥数据实际的业务价值。这样看的话，很多的企业当前还处在虚线的左边，也就是说数据还在IT部门的兜儿里头。企业如何从左边这个阶段往右边阶段迈，一定程度上是从量变到质变的过程。可以看到我这张图里面有数据目录，它是帮助企业从虚线的左边阶段往右边阶段迈的。

我这张图左下角还有一个东西叫“元数据管理”，过去大家做了蛮多的元数据管理相关系统，但是发现效果都不好。原因是这个更多的被IT部门用于存储相关的表、字段、数据，被当做帮助IT部门跟数据打交道的一个系统，没有发挥出它实际的价值。所以数据目录是对整个产业里的系统一个改造升级，可以把元数据系统变得能分享给不同的业务部门，这是从元数据到数据目录整个的升级改造，再之后就是不同的IT部门或者业务部门能够看到相关的数据，进而发挥实际的业务价值。图右边有一个总结，是从IT数据到企业数据资产，从管理控制到共享应用。这是说，原来企业更多关心的是IT部门的数据谁能访问，担心数据泄露问题，现在更多关心的是，能不能够让业务部门知道自己部门里有一些什么样的数据。从IT元数据到业务数据目录，数据在走向服务化、价值化，这是我们当年看到的非常明显的一个国际趋势，国内现在也在向这个方向发展。

之后的背景我不再赘述了，大家都在企业做了十几年企业信息化，建设了很多的IT系统，不同的IT系统都是不同的IT供应商来做的，这就导致数据互相之间口径不一致，无法拉通，有关系型数据库有非关系型数据库。

下面重点讲一讲，到底数据目录是什么？它与元数据有什么差别？

左边展示的是一个制造业的企业，核心业务版块包括生产域、市场域、工程域等板块，这版块有一些什么样的业务术语，每一个业务术语我们会将它往中间这一列去兑。中间这一列是物理的数据库，比如当前的气象预报，这个业务对应哪个表，具体哪个表对应的更细节的东西，比如一些字一些关联关系数据信息都会把它展现出来。这样从业务到物理的东西，如何把中间的GAP弥补上，就是通过数据目录完成的。这些东西是分开开放给不同的业务部门的，生产部门进来系统后会看到生产域里面相关的信息，营销部门的人应该看到的是营销域里面的相关信息。

第二方面，基于我们公司的背景先把今天要讨论的范围界定一下，我们今天讨论的是数据模型，数据模型是我们实际物理数据库、逻辑模型、概念模型跟物理模型之间三层的关系。至于分析模型、挖掘模型是面向数据分析领域的。对数据模型定义好后，我们继续往下说。

以前做传统数仓的人不会对数据建模陌生，就像当我们要盖建筑的时候一定要先设计一个图纸。如果企业没有数据模型，就相当于右下角这张图——在一块地面上先是盖了一个小平房子，然后又往上建阁楼，阁楼建好后还没有停止，继续向上不断的搭建，最终形成了一个不稳固的四不像建筑，这就是没有设计就进行建造会造成的后果。当企业里的数据已经复杂到一定的情况，如果继续单纯往上不断加盖，是很危险的状态，这样就比较容易理解数据建模的重要性相当于盖楼前做图纸设计。

建筑图纸设计中有一些标准组件，比如说到水管就是PVC水管，说到水泥就是用某某标号，我们画的图纸应该都是用这些标准组件组装出来的。这些标准组件的标准，就相当于企业中的数据标准，应该用数据标准组装设计出来的数据模型。今天上午建行的分享中提到的企业级数据模型就是这个样子。

数据模型分为三个层次，概念模型、逻辑模型、物理模型，这个层次跟国际上的实践方式是一样的，核心就是逻辑模型，即C模型企业级数据模型。真正的物理模型是到物理数据库的时候，实际物理数据库有叫Client的，有叫CUST，有叫CTABLE-16，在逻辑上的物理数据库概念都是叫CUST，数据模型等于是把这些东西都串起来。

大家做这些的最终的目标都是做好我的数据应用，把我们企业的数据分析模型做好，把分析模型的算法做好。数据应用一定是依赖于数据集市和数仓的，数据集市和数仓的质量对数据应用有很大的影响。数据集市和数据数仓要做到标准化，数据要清洗好、拉通好，每个数据源要理解透彻它对应的数据标准是什么样的，它的补充语境等等这些东西都要放进来，才能把它顺起来。我们过去十几年在国内国外的一些实践当中，就是从系统的数据模型做起，每个系统都应该在把数据模型弄清楚然后往上继续加盖“建筑”，不要在沙滩上盖大厦。企业在每一个系统的数据模型理清楚之后再搞企业数据模型，未来的应用和数仓都是基于企业数据模型，然后在上面搭建数据应用等等一些分析场景。

传统的数据建模跟数据模型不是一个概念，数据建模是一个行为，数据模型是这个行为的产物。企业数据建模是说企业进行多人协作，若干个人一块儿做模型设计——可能是核心业务系统开发，也可能是一个数仓的开发。另外企业数据建模还有一个特点，就是开发维护的人员和最终使用的人员是两波人，来自几个不同的部门。这样的话数据模型需要被多个部门去看这个东西，这件事才能变得有意义。

关于数据模型，我们希望每一位专家不管是数仓的开发者还是建模的开发者都要做了解，所以在这里推荐几本书给大家，例如《数据建模咨询手册》，《Data Model Resource》，大家都可以学习学习。

我刚才已经把建模和模型这件事阐述清楚了，接下来给大家做一些数据模型在企业中的实践介绍。

第一是数据标准的落地。

通常有很多企业已经做了数据标准的梳理，找咨询公司做了相应的数据标准，然后会发现新问题，数据标准发布以后怎么产生效果？企业可能发布了两三千条数据标准，最后发现这个标准没有人看，没有落地到不同的业务系统里面去。如何避免这个问题，我们花了很多的心思。我们把数据标准和数据模型结合在一起，也就是说数据标准会导入到建模工具里面来，数据模型是由数据标准组装出来的，最终数据库的实际跟数据标准是一致的，这样物理名称、数据类型、业务定义都跟标准是一致的。

第二是管控的模型。

开发人员做模型的设计时，在设计每个字段时都应该用企业的数据标准来选，如果一旦发现该字段没有相应的标准时应该提一个新的标准审批。这样专门有一个标准架构组，由这个组来控制整个企业的数据标准，如果发现该需要审批的标准是一个新的标准，就将它加入到企业的数据标准库中，这样整个的数据模型中，业务系统的数据系统的跟它的数据标准是完全匹配的，是百分之百覆盖到数据标准的。

刚才讲的是一种人工的工作流方式，现在我们有一些更自动、更智能的方式做数据标准与数据模型的落标。随着新系统的不断上线和系统的升级改造，做自动采集，做相应的增量变更版本，然后把逻辑模型和标准自动相应匹配。这是用更智能、更制动化的方式做长期的标准和模型之间的数据对标和管理的管控模式。

再讲设计态和运行态的一致性。刚才我们讲模型设计，模型设计是在开发设计阶段的一个手段，企业永远希望生产态和开发态是一致的，未来大家都应该在模型上面做相应的数据管理、数据管控，这样企业会周期性地去把模型基建和数据库做比对。企业不希望在物理数据上做相应的修改，如果有相应的修改跟原本的模型基建不一致，就会把相应的差异找出来。有些人会上一个新的系统——说白了可能是黑项目，没有报备到数据管理部门就直接上线，在数据库新加了一大片的表。这种一定要管控起来，所有的东西都应该反映到企业的数据模型里面来，这才是正确的模式。

还有一个主动分析模型变更，就是说前面大家都在用我的建模工具来设计它的业务系统，当前业务系统是1.0、2.0、3.0这样不断迭代，在迭代过程中我们会把模型做比对，从1.0到2.0做了什么数据模型的修改，我会对这个修改做一个血缘关系的抽取，看这个修改对后面的数据集市的影响是什么样的。现在我们经常碰到一些部门本身就是数据部门、数据创新部，他们最担心的是前端业务系统不断升级，因为升级的过程中有可能把后面的数据挂掉。我一定要知道前端有哪些要求要做一些什么样的升级，这些升级对后面的应用是什么样的影响。这样靠的是主动方式不是被动方式，数据部门不想要每天都当救火队员，每天突然一个东西挂了，然后去查问题是什么。而是数据部门在一开始做开发的时候就要知道建什么样的数据结构，对后面的影响是什么样的，这样的模式。

整体说起来，我们Datablau就是一个产品型的公司，我们整体的产品方向也是跟着DAMA这套方法论走的，包括数据建模、数据架构、数据质量、元数据等等相关的东西。我们相关的两个产品线，一个叫数据资产管理，一个叫数据建模，把生产态和开发态形成一个闭合的关系。Datablau总部在北京，大部分的人都是从Erwin出来的，拥有做产品的基因。

我的演讲就到这，谢谢大家。

声明：本文来自大数据技术标准推进委员会，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。