一文看懂“数据中台”建设的方法论

数据中台：小数据的治理机制[*]

 

 

 

    引言

最近一两年来，在互联网领域，再也没有一个概念能够像“数据中台”那么火热的了：不仅是这个概念的首创者阿里在不遗余力地加紧宣传推广所谓的“中台战略”，连阿里的业务竞争企业如腾讯等也认同并推出自己的“中台”架构或发展战略，一些大大小小的企业也加快了开发所谓的“数据中台”产品或解决方案的步伐，唯恐落在他人后面！

同样是在互联网领域，近年来出现的诸多新概念中，再也没有像“数据中台”这样让人搞不懂的了。尽管最近一两年来“严肃”地讨论数据中台的文章越来越多，但看过这些文章后，人们只会对“数据中台”越发地感到糊涂，实际上阿里系的文章同样无法说清楚“数据中台”的科学内涵。

这种情况确实挺让人纳闷的：一方面，一本正经地讨论“数据中台”的文章越来越多，有的文章甚至是将其吹破天，认为是一项重大的科学技术创新；另一方面，在这些文章所构建的所谓“数据中台”的理论架构中，我们却看不出有任何创新的概念、理念或技术，特别是看不出其与现有的有关信息架构设计或前台-后台架构设计有啥本质的区别。看到这种混乱不堪的局面，我这个信息化研究的老兵心里也深感责任重大，必须为扭转这种不利局面做出自己应有的贡献。

为开展“数据中台”问题的研究，几个月来自己收集整理了一百余篇相应的技术论文，对当前有关这个问题的国内研究现状有了初步的认识，并在此基础上提出了自认为科学合理的理论分析框架。

一、“数据中台”的起源

关于“中台”的起源，目前有一个广为流行的说法，该说法与Supercell有关。Supercell是一家位于芬兰赫尔辛基的世界知名移动游戏公司，2010年创立。尽管创立时间很短、企业员工有限（据说在2015年还只有50人），但近年来却开发了不少全球热门游戏，例如《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等。为此，腾讯公司于2016年以86亿美元收购其84.3%的股权。

不仅如此，阿里巴巴的马云对Supercell也敬佩有加。为此，他于2015年亲自率队到Supercell公司进行商务拜访。在听完公司的经营管理情况介绍之后，据说马云对Supercell的高效运营无比感慨，忍不住脱口而出到：“Supercell的秘密武器就是中台战略啊！”并要求阿里巴巴进行研究和学习。于是，“中台”这个说法便在阿里巴巴内部传开了，而且据说阿里巴巴后续的架构改革便是按照“大中台、小前台”的组织原则展开的。

不管上述“中台”的马云说是否属实，但“中台”的概念确实在近年来不断发酵并从去年开始流行起来，日益成为行业共识，尽管大家对如何认识这个共识还没有达成一致意见。

当前，围绕“中台”这个概念，人们又发展出了所谓“数据中台”“组织中台”“业务中台”等诸多概念。不过，在这些“中台”概念中，“数据中台”是其核心。

二、当前关于“中台”问题的研究概述

为全面系统地开展有关“中台”问题的研究，笔者搜罗了互联网和微信上（特别是云栖社区、CSDN(中国开发者社区)）有关“中台”的大量文章，并搜集整理了其中的100多篇。从这些文章来看，当前对于“中台”问题的研究存在着以下几个方面的问题：

首先是定义不清。由于当前仍然处于“中台”概念兴起之际，如何定义“中台”成为人们讨论的焦点，所以当前的各类文章大多用一些“什么是数据中台、中台是什么、中台究竟是个什么鬼、我对中台的理解、白话中台战略、阿里‘小前台、大中台’战略解读”之类的标题。从这些文章来看，大家似乎都对别人的中台定义不满意，都想着“亲自”去为其再定义一次。下面就基于自己所搜集到的上述资料，列举8个“中台”的定义（如表1所示）。

 

表1、“中台”的不同定义

编号	定义	定义出处
1	中台就是“企业级能力复用平台”	《白话中台战略-3：中台的定义》
2	中台通过集合整个集团的运营数据能力、产品技术能力，来对各前台业务形成强力支撑	《大型集团性企业的中台战略--阿里的中台战略其实是个伪命题》
3	中台是一种需求分析的方法论，一套能力接入标准，一套运作机制，集中配置、分布执行的控制台。	《中台如何助力标准化业务？中台关键要快！》
4	“中台”是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将整合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑	《大中台 小前台》
5	中台是居于前台和后台之间、位于基础架构和各产品线间的业务架构。	《关于架构的思考 - 评《阿里巴巴中台战略思想与架构实践》》
6	数据中台是将各个业务版块多年来积累的数据，按业务特征进行横向关联和统一，按数据用途进行纵向分层，最终沉淀为公共的数据服务能力。	《传统企业数据中台的建设与思考》
7	数据中台的实质还是组件化，模块化，是设计模式与业务端的应用	袋鼠云数据中台专栏（一） ：浅析数据中台策略与建设实践
8	中台是一个用技术链接大数据技术能力，用业务链接数据应用场景的能力平台。	《阿里中台建设全解密：包含哪些内容？如何发挥作用？》

注：表中的“定义出处”是指网络上或微信上查找到的文章标题。

 

此外，还有人引用阿里巴巴平台业务负责人玄雄对于中台的观点（如图1所示）。

                   

图1、阿里巴巴业务平台负责人玄雄有关中台的访谈观点

图片来源：《白话中台战略2：中台到底长啥样？》，链接：https://blog.csdn.net/toafu/article/details/85158879

 

从上面这些定义来看，人们对于中台的解释还是很不一致的。有的定义甚至还谈不上是严格的定义，充其量只能说是对其某方面属性的简单描述（如定义3以及玄雄有关中台的访谈观点），还谈不上是对其本质属性的界定。

其次是缺乏明确的架构模型。当前人们在讨论中台的信息化架构时，大多使用阿里巴巴业务架构中的“共享业务事业部”（如图2所示）。不过，图2主要表达的是阿里业务系统的基本情况，说明“共享业务事业部”对于阿里巴巴各业务系统之间的前后关系和相互联系，但是其中并没有具体描述各模块的数据流转关系（尽管其中也有“数据服务中心”）。而且，从逻辑上讲，“共享业务事业部”中的8大模块即“用户中心”“商品中心”“交易中心”“评价中心”“店铺中心”“搜索中心”“数据服务中心”“营销中心”，其颗粒度并不一致。

                           

图2：阿里巴巴业务架构中的“共享业务事业部”

图片来源：《企业IT架构转型之道——阿里巴巴中台战略思想与架构实践》（钟华编著，机械工业出版社2017年5月出版）

 

本来，如果文字定义不清楚，可以通过图形去辅助说明。但从上述阿里业务架构的“共享业务事业部”以及一些公司所提出的中台架构来看，中台的含义仍然不是很清晰。我们可以选取两家企业的中台架构来比较。图3是OPPO数据中台，图4是袋鼠云公司的数据中台架构的开发方法（袋鼠云自称是阿里云数加平台金牌合作伙伴）。显然，在图3、图4中，两个企业对于数据中台的认识和架构是存在着很大的不同的（例如，数据仓库Vs.数据中台）。

 

图3、OPPO数据中台

图片来源：OPPO 大数据平台研发负责人张俊在2019年 4 月 13 日在深圳举行的 Flink Meetup 会议上的发言材料

 

图4、袋鼠云数据中台策略

图片来源：《袋鼠云数据中台专栏（一）：浅析数据中台策略与建设实践》，

https://yq.aliyun.com/articles/604571?spm=a2c4e.11153940.0.0.2ec710b5Q1SAJQ

注：根据“袋鼠云数据中台专栏”的相关文章，图4中的ODS为操作数据层、DWD为明细数据层、DWS为汇总数据层。

 

第三是无法区别“中台”与平台、前台-后台、大数据等概念之间的相互关系。“中台”首先是以阿里巴巴的“大中台、小前台”战略的面目出现的，在这个战略里面缺少“前台-后台”关系以及平台的功能和地位问题。实际上，从某种意义上讲，如果能够科学合理地设计后台并有效地处理业务和数据之间的衔接关系，也就不会有所谓的中台的存在了。因此，所谓的中台战略，必须说清楚中台是如何从后台分离出来以及分离之后的中台与后台的联系和关系。不过，从目前众多的文章来看，我们无法得到满意的答案。

此外，上述众多中台的定义与大数据关联不够。当前人们将“中台”划分为业务中台、技术中台、组织中台和数据中台等几类，并从模块化、组件化、通用性等几个核心特征去界定其各自属性。但是，实际上，光有“模块化、组件化、通用性”等特征是不够的，特别是无法深入地分析“数据中台”的独特性及其专业属性。实际上，所谓的“数据中台”与“业务中台”之间有着本质的不同，不应该简单地以“模块化、组件化、通用性”去模糊、掩盖其相互间的巨大差别，而“数据中台”的这种独特性只有从大数据中去寻找。

三、科学界定“数据中台”问题的基本原则

至少近十年来，信息化对于我国国民经济和社会发展的各个方面都发挥了极大的促进作用。无论是国家的网民规模还是电子商务交易额、移动支付规模等，中国都已经远远地走在了世界最前列，并将美国甩到后面。尽管我们的IT技术主要来源于美国，但毫无疑问，在我们这些年的快速发展过程中，我们仍然会遇到众多的技术和管理问题；同样，毫无疑问的是，我们也解决了这些问题。因此，发现提炼这些问题、总结提高这些问题，也就具有特别的意义，不仅表明我们对于互联网经济（数字经济、信息经济）的业务创新、技术进步和理论认识达到了一个新的高度，更是对我们这段伟大历史进程的最好的诠释和纪念。

“中台”正好为我们丰富信息化理论提供了很好的技术工具。不过，现有文献关于“中台”的理论构建及其信息化架构却难担此重任。为了克服当前有关中台理论构建及其信息化架构的诸多不足，有必要明确和理解以下三个方面的问题。

（一）遵循数据管理科学发展基本规律。

最近十年来，数据资源管理科学正在不断出现新的技术与理论创新。这可以从两个方面来认识和理解。

首先，这种理论创新来自人们对于信息化发展特别是数据与业务的不断细化分离趋势的规律的认识（如图5所示）。根据图5，主数据正在成为数据资源整合的一个崭新工具和手段；而从近年来企业信息化和数据库建设实践来看，主数据及主数据管理已经成为人们建设基础数据库的基本方法。这些发展趋势表明，作为数据分离趋势中的主要内容形式的元数据、主数据应该成为数据中台的核心内容。

图5：信息化发展过程中的业务、数据的四次分离
 

 

其次，这种技术与理论创新来自于企业（信息）架构的不断深化。上世纪80年代出现的Zachmann模型有力地推动了企业架构技术的发展并带动了企业信息架构技术的进步与发展，特别是在一些美国政府机构的作用下，企业信息架构标准化取得很大进展并成为国际标准化组织的规范来源。当前，企业信息化建设不仅需要构建技术架构、业务架构，也要构建其数据架构（如图6所示）。

图6、企业信息化三大架构
 

图片来源：云架构师进阶攻略（来自微信公众号“刘超的通俗云计算”）

 

美国政府应用信息化架构技术方法去规划设计其电子政务顶层设计，于2000年实施其联邦政府组织架构（FEA ，Federal Enterprise Architecture）（如图7所示）。从FEA参考模型可以看出，美国政府对于信息化架构的认识和应用更加深入了，进一步丰富了人们对于信息化架构的认识。

 

图7、FEA参考模型
 

图片来源：李广乾，FEA 促美国电子政务转型，《计算机世界》2005 年/12 月/19 日/第C03 版

 

（二）数据中台是中台思维的核心

从上述有关企业架构的简要介绍可以看出，对于业务、技术和数据，必须分别地构建各自的业务参考模型；不应该简单地以所谓的“模块化、组件化、通用性”去抹平不同类型中台的独特性，特别是不能将所谓的业务中台的属性等同于“数据中台”属性。

有一点必须注意的是，我们不能将业务架构等同于业务中台架构。实际上，在FEA参考模型中，不仅有业务参考模型（BRM），也有服务构件参考模型（SRM）（如图8所示）。SRM是一种业务驱动的功能架构，它根据业务目标改进方式而对服务架构进行分类。所谓构件就是一项可以自我控制的、事先已经进行功能设定的业务过程或服务，其功能可以通过业务或技术界面加以体现。SRM基于横向的业务领域，与具体的部门业务职能无关，因此，它能够为实现业务重用、提高业务功能、优化业务构件及业务服务种类提供基础杠杆。SRM由7个服务域、29项服务类型和168项服务构件构成（如图9所示）。

图8、服务构件参考模型（SRM）的结构

图片来源：李广乾，《中国信息化建设的理论与政策研究》（电子工业出版社2016年出版）。

图9、SRM的示意图
 

图片来源：李广乾，《中国信息化建设的理论与政策研究》（电子工业出版社2016年出版）

 

而从目前有关中台的“模块化、组件化、通用性”属性来看，上述服务构件参考模型（SRM）在很多方面与业务中台的含义最为吻合。因此，我们可以将服务构件参考模型看作是业务中台参考模型。

由FEA的业务参考模型分离出服务构件参考模型从而构建业务中台参考模型的思路，对于我们由数据参考模型到数据构件参考模型从而构建数据中台参考模型，提供了有益的思路，尽管FEA尚未发展出这套方法。实际上，FEA的数据参考模型（DRM）也构建了一个比较新颖的架构模型（如图10所示）。不过，也许是由于这个模型相对简单、抽象，无法像前面经由BRM细化、分离出SRM即业务中台那样，分离出数据中台来。

图10、DRM标准区

 

此外，FEA-DRM无法分离出数据中台，还要技术的、历史的原因。FEA是2000年前后发展起来的，当时尚未出现大数据的技术和方法，数据管理知识体系尚未完备地建立起来，因而无法发展出“数据构件”的工具和方法。尽管如此，从上述FEA的整个架构及其逻辑关系来看，数据参考模型及应该补充上的“数据构件参考模型”（数据中台）毫无疑问将构成整个信息化架构设计及业务数字化的基础，而仅就中台来看，数据中台将构成业务中台及其他中台的基础。

（三）合理地借鉴现有创新

从上述分析来看，政府的电子政务架构早已经发展出当前所谓的“中台”思维了。这是一个合乎逻辑的过程，因为在电子政务发展到一定阶段之后，就自然地面临着一个加强系统整合、克服重复建设的问题。因此，在2000年之后，无论是美国还是其他国家，都开始对各自的电子政务建设进行顶层架构设计，在这个过程中就自然地衍生出前述的所谓“业务中台”来了。我国也在2006年出台了《国家电子政务总体框架》，也试图借鉴国际上的“业务中台”理念以克服重复建设的难题。

从上述分析可以得知，电子政务比电子商务更早地发展出了中台思维。不过，电子政务领域的“中台”并没能得到推广；而且，当前电子商务（互联网企业）所倡导的中台战略与此似乎并没有传承关系，看过去更像是电子商务企业自己独立发现并发展起来的。不过，我国电子商务企业发展出中台战略，显然要比电子政务中的中台做法晚得多。出现这种情况，是多种因素相互作用的结果：

首先，政府是一个持续存在的组织机构，对于信息化业务系统的发展容易进行长期的战略性规划，因而容易发展出合理的架构并找到中台的技术方法；而企业是一种一直置身于市场化竞争之中的不断演进的存在，自身的生存受到诸多因素的影响，因而对于信息化业务架构的需求不像政府机构那么强烈。而且，只有等企业发展到相当规模、企业信息化业务系统达到相当复杂程度、相对成熟之后，企业才能考虑信息化总体规划设计的问题。这也是美国跨国企业的信息化架构相对比较发达的原因。
    其次，我国工业企业在发展信息化架构方面的能力和动力都严重不足。改革开放四十年来，我国工业企业主要是在OEM、靠承接外国的业务订单发展起来，产业链、价值链、供应链都相对单一，在这种情况下是无法发展出合理的信息化架构的，因为信息化架构需要全产业链的系统支撑。而我国的电子商务企业（互联网企业）最初大都实力很弱，以复制、模仿外国模式为主，至少在前十年以业务拓展、市场扩张为主，在这个过程中发展出了众多的业务条线及其信息系统，这些系统各自独立且互不兼容。这给企业的发展壮大带来了很大的障碍，近年来随着这些互联网企业的日益成熟，如何构建科学合理高效的业务信息系统，便成为人们的自然选择。与此相对应的是，近年来我国的BAT类企业业务规模都已经足够大了，成为世界500强，这也给其信息化业务架构化提供了保障基础。这些可以看作是互联网企业近期开始热衷于开展所谓数据中台战略运动的根本原因。

不过，我国电子商务（互联网）企业掀起的数据中台战略仍然具有重要意义。这表明，我国互联网企业已经走出“复制模仿”的困境，开始独立思考自己的业务系统规划了。这为创新提供了最好的土壤，不仅为我国开发自己的信息化解决方案、设计自己的数据库产品提供了最好的条件，也将有力地促进我国软件产业的创新发展。从软件发展历史来看，信息架构理论的进步与软件产业发展相影随行、相互促进和提高，因此数据中台的建设也将有力地推进我国软件产业发展。

四、小数据是理解数据中台的关键[1]

要正确地构建FEA的“数据构件参考模型（数据中台）”，关键是如何认识和理解大数据的管理属性，而其中的关键是如何认识小数据。

（一）认识小数据

可惜的是，当前人们对于小数据的认识同样很混乱，至今也没对小数据形成一个统一权威的定义。从现有的材料来看，人们对于小数据的说法是多种多样的：一是认为，小数据泛指零星的弱信号，往往被当作没有规范、看似随机的偏差或噪音；二是认为结构化的采样数据就是小数据；三是认为小数据是指信息项目和数据规模较小的数据库；等等。根据这些说法，我们发现人们对于小数据的属性界定是根本不同的：第一种说法将小数据看作是小概率事件的数据，第二种说法从数据结构类型去认识小数据，第三种说法则简单地从数据量的多少去界定，显然是太不着边际了。由此可见，目前人们对于小数据的认识和理解，跟上述“中台”概念一样，也是很不一致的。

不过，在正式厘清小数据的概念之前，有必要明确以下三个基本问题：

1、人们采集、加工处理海量数据，通常都是某种具有特定目的的理性行为。因此，尽管大数据的容量很大、涉及的对象很多，但是人们通常会根据业务类型对这些海量数据进行分类处理。

2、要体现出某种价值，“数据”本身必须能够表述一个完整的“信息”。无论是大数据中的“数据”还是小数据中的“数据”，都只是一个抽象的概念。单个的数据本身无法反映什么内容，必须是若干条“数据”综合在一起去反映某种“信息”。而且，从逻辑来看，通常存在着如图11所示的层次递进关系（图11也被称为DIKW模型）。

3、一条完整的信息应该包含一个明确的主体、客体和行为。通常情况下，主体和客体一般都与具体的现实对象（实体）关联在一起。

 

图11. 数据、信息、知识与智慧之间的关系

图片来源：笔者根据相关材料整理

 

上述的三个基本问题，为我们界定小数据的内涵提供了基本思路，我们可以据此去明确那些界定小数据的基本属性：

1、小数据应该与数据容量无关。我们不应该说20KB的数据才是小数据，而20MB的则不是小数据。

2、小数据自身应该包含特定意义。与大数据中的那些不能反映趋势性价值判断的零星数据不同，小数据应该是那些自身包含特定意义的数据，特别是能够反应大数据的某种基本属性。

3、小数据应该是一种结构化数据。从前面两条原则，可以确定小数据应该就是一种结构化数据。小数据的最大价值应该是既界定其他结构化数据的属性及结构，同时也应该能够被用于界定部分非结构化的数据。

4、小数据应该是对于大数据（无论是结构化的还是非结构化的）的数据之间关系的宏观描述。“以小博大”（或者说“统筹大数据”）应该是小数据之于大数据的价值所在。这包含两个方面的内容：

一是对于大数据的基本属性的描述。具体又包括两个方面，一方面是对于特定业务类型的大数据的属性描述，另一方面是大数据中的主体行为特征的描述。

二是对于大数据中所包含的主体、客体的基本特征的管理数据。

5、小数据与大数据形影相随。与大数据相比，小数据的4V(volume、velocity、variety、value)发生了不少变化：小数据的数据容量(volume)肯定无法和大数据相比，数据类型（variety）以结构化数据为主；与大数据的时刻变化（velocity）相比，小数据的属性相对稳定；就等容量的数据而言，小数据的价值（value）要比大数据的大得多且明确得多。

上述5个方面初步概括了小数据的基本内涵及其与大数据的关系。根据这些界定，我们可以据此尝试为小数据进行一次具体的定义：所谓小数据就是描述并管理大数据的数据属性的数据。基于上述分析，我们可以根据这个定义划分三类小数据（如图12所示）：

 

 

 

图12. 小数据的分类

 

第一类：关于特定类型的大数据的数据属性的数据。其中的“数据属性”的“属性”，是包含该数据库的定义、结构、类型、操作、管理等各个方面内容的一般化的描述。

第二类：描述大数据中所包含的主体、客体的基本特征的管理数据。这包括两个方面的内容，一是对于大数据中所包含的主体、客体的一般属性的规定；二是满足某类主（客）体属性的所有对象。

第三类：描述大数据中的行为、过程等的数据。这类数据主要是从海量数据中概括、分析、提取的某种“行业知识”、业务框架和发展模型。这是对于行业业务内容的描述分析。

（二）小数据与元数据、主数据

根据上述有关小数据类型的分析，我们发现，小数据本身并不是什么新创的数据类型，而应该是对于大数据中一些特定数据的概括、总结和归类。而且，这些特定的小数据类型都可以应用现有的专业数据语言（例如元数据、主数据等）去表述。实际上，第一、三类小数据都可以被称为某种元数据；第二类的第一个方面也是一种元数据；而第二类的第二个方面则应该被称为某种主数据（如图13所示）。无论是元数据还是主数据管理，都是在数据库处理领域得到广泛应用的基础性技术。因此，认识和理解元数据和主数据，有助于我们正确地认识和深刻地理解小数据的科学内涵及其本质特征。

 

图13. 小数据分类与元数据、小数据
 

 

１、元数据与元数据管理

“元数据”最初是指网络资源的描述数据，后来逐步扩展到各种用于描述电子化信息资源属性的数据。目前，“元数据”这一术语广泛地应用于各类信息资源的描述记录。

元数据通常被定义为数据的数据，是用于描述某种数据资源的基本信息的结构化数据。具体地来说，元数据是有关一个企业所使用的物理数据、技术和业务流程、数据规则和约束、以及数据的物理与逻辑结构的信息[2]，其目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织与管理[3]。元数据主要包括以下16个潜在主题领域（如表1所示）和四种类型（如表2所示），涵盖信息系统建设的几乎各个方面。

 

表1、元数据可能包含的潜在主题领域

编号	主题领域	内容描述	编号	主题领域	内容描述
1	业务分析	数据定义、报表、用户、使用方法和绩效	9	信息技术架构	平台、网络、配置和许可证
2	业务架构	角色和组织、目的和目标	10	逻辑数据模型	实体、属性、关系和规则、业务名称和定义
3	业务定义	有关组织中的一个特定的概念、事实或其他事物的业务术语和解释	11	物理数据模型	文件、表、列、视图、业务定义、索引使用、性能、变更管理
4	业务规则	标准计算公司和衍生方法	12	流程模型	职能、活动、角色、输入、输出、工作流、业务规则、定时、存储
5	数据治理	政策、标准、程序、项目、角色、组织和管理职责安排	13	系统群和IT治理	数据库、应用程序、项目和计划、整合路线图、变更管理
6	数据整合	数据源、数据目标、数据转换规则、数据血缘关系、ETL工作流、EAI、EII、迁移和变换	14	面向服务架构（SOA）信息	组件、服务、消息、主数据
7	数据质量	缺陷、度量和评级	15	系统设计和开发	需求、设计、测试计划、影响
8	文档内容管理	非结构化数据、文档、术语分类、本体、命名集合、法律发现、搜索引擎索引	16	系统管理	数据安全、许可证、配置、可靠性、服务水平

注：笔者根据以下资料整理：

DAMA International著，马欢等译，《DAMA数据管理知识体系指南》，清华大学出版社，2012年7月第一版。

 

表2、元数据类型、属性与内容

元数据类型	属性与内容
业务元数据	主题和概念领域、实体及属性的业务名称和业务定义，属性的数据类型和其他特性，范围描述，计算公式，算法和业务规则，以及有效值域及其定义。
技术与操作元数据	技术元数据包括物理数据库表名和字段名、字段属性、其他数据库对象的属性和数据存储特性；操作元数据主要用于满足IT运维用户的需求，包括数据迁移信息、数据源和目标系统信息、批处理程序、任务频率、调度异常处理、备份与恢复信息、归档规则和使用等信息。
流程元数据	定义和描述系统的其他元素（如流程、业务规则、程序、任务、工具等）的特性的数据。
数据管理制度元数据	关于数据管理专员、监管制度流程和责任分配的数据。

注：笔者根据以下资料整理：

DAMA International著，马欢等译，《DAMA数据管理知识体系指南》，清华大学出版社，2012年7月第一版。

 

面对种类繁多的元数据，需要实施有效的元数据管理。为此需要建立合理的元数据战略，并通过开展一系列的元数据管理活动贯彻实施该战略。这些元数据管理活动主要包括理解元数据需求、定义元数据架构、开发和维护元数据标准、构建合理的元数据评估标准等。此外，针对业务元数据构建各种本体，有利于加强元数据管理效能；构建合理的元数据管理成熟度模型，有利于促进元数据管理的持续深入的展开[4]。

2、主数据[5]与主数据管理

当前，主数据已经被越来越多的IT企业应用于其数据管理产品或解决方案中，但是尽管如此，人们对主数据仍然缺乏一个权威的定义。IBM公司发布的有关主数据管理的红皮书《MasterData Manangement:Rapid Deployment Package for MDM》认为，所谓主数据是有关客户、供应商、产品和账户的企业关键信息；有人将主数据定义为“表示‘跟踪事物状态’的数据”；也有人认为，企业主数据是用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等，它是具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据，并且存在于多个异构的应用系统中；等等。国际数据管理协会（DAMA）认为，主数据是关于关键业务实体的权威的、最准确的数据，可用于建立交易数据的关联环境[6]。

这些定义分别从各自不同角度对主数据进行了界定，我们根据这些不同定义做一个比较全面的概括：所谓主数据是指满足跨部门业务协同需要的、反映核心业务实体状态属性的企业（组织机构）的基础信息。就企业数据管理来讲，主数据主要涉及四大主题领域：当事人主数据、财务主数据、产品主数据、位置主数据[7]。

综合前述元数据和主数据的各种概念，我们构建一个业务信息系统中有关主数据与其他各类数据之间的逻辑关系（如图14所示）。在图14中，“业务数据”被分解为“交易数据”和“主数据”“元数据”。在这里，所谓业务数据，是指业务实体完成一项具体行为过程的完整的数据；所谓的交易数据，是业务实体（主数据）基于业务行为规则（元数据）而发生的具体行为过程数据。对于业务数据而言，主数据、元数据是相对不变的，而交易数据是每次都会变化的。

 

图14. 主数据与其他数据之间的关系

 

值得注意的是，图14还有助于我们深化对于图11的DIKW模型的认识。一条业务数据相当于一条“信息”，因为该“业务数据”具有完整的含义；但是，这条“信息”是由多类“数据”共同构成的，即交易数据、元数据与主数据。因此，我们可以将图11进一步细化为下图(如图15所示)。这也表明，DIKW模型中“数据（D）”阶段的数据，并不只是简单的“原始素材”。

 

图15、DIKW模型的深化

 

由于主数据涉及到众多主数据的产生与应用部门，因此为了协调和管理与核心业务实体相关的系统记录和系统登录中的数据和元数据，需要加强主数据管理，为此需要构建一整套用于生成和维护企业主数据的规范、技术和方案，以保证主数据的完整性、一致性和准确性。

3、大数据中的元数据、主数据

元数据和主数据之间有着密切的关系。从概念和逻辑上讲，主数据（结构）属于元数据的一个子集，是一种特定类型的元数据。但是，从产品上讲，主数据和元数据是两个完全不同的概念：元数据是指表示数据的经过抽象的相关信息，比如数据定义等；而主数据是指实例数据，比如产品目录信息等。由于主数据对于业务系统建设具有独特地位，因而人们往往将其独立出来并单独建设、维护，例如客户关系管理系统（CRM）等。另外，无论是主数据还是元数据，都不是系统自行产生的数据，而是在规划建设信息系统时、从加强业务系统管理角度出发所构建的数据(库)。

就常规的大数据信息系统建设而言，小数据（元数据、小数据）为我们认识大数据的核心属性提供了一种有效手段。虽然大数据容量可能很大，但经过初步分析，我们仍然可以从中挖掘、提炼出相关的小数据（元数据、主数据）来。反过来说，小数据虽然数据容量较小，但人们却可以通过小数据去认识大数据系统中的海量数据的基本特征。

（三）小数据治理机制构成数据中台的核心内涵

我们发现，有了上面小数据的架构框架，我们便可深化前述的FEA-DRM，并以此构建其“数据构件参考模型”。完整地来说，我们应该基于大数据建立完善数据参考模型，基于小数据构建“数据构件参考模型”。因此，当前很多人在讨论数据中台时，都把它看作是一个完整的企业数据系统解决方案，这显然是不合适的。数据中台应该是企业数据系统解决方案中的那些可共享、可通用的那些数据业务内容。

不过，在构建数据中台时，必须注意到以下两个问题。

首先，数据中台（“数据构件参考模型”）无法像服务构件参考模型与业务参考模型完全分离那样，与数据参考模型完全分离；数据构件参考模型与数据参考模型是紧密地联系在一起的。

结合图7、图8，我们可以看出来，政府职能业务是各自独立的，但每个职能政府部门处理行政业务的很多流程和程序是类似的、内部管理工作也是类似的；而且这些类似的流程、程序和事务性内部管理工作，与政府职能业务可以没有任何关系，因而可以将其独立出来。当然，就实际情况来看，这种“独立”并非真的要从每个政府职能机构中分离出来，这与行政协调成本和业务时间与机构精简之间的权衡有着密切关系。不过，就信息架构而言，这种权衡则不一定存在。这是FEA从业务参考模型中分离出服务构件并独立构建服务构件参考模型的原因。

不过，服务构件参考模型（业务中台）相对于业务参考模型的这种独立性，在数据参考模型与数据构件参考模型（数据中台）之间并不显著。造成这种差异的原因，在于数据自身的完整性要求。这种完整性，来自业务与数据之间的动态关联性。前述关于“交易数据”的定义和图14都表述了一个由几类数据综合起来构成一条“信息”的完整的过程，作为小数据核心的元数据、主数据也都在其中，相影随行。与业务中台的独立性相比，数据中台的独立性是相对的；脱离（大）数据管理系统，数据中台就没有价值。因此，数据中台的小数据治理是非常重要的，需要在建立完善相关技术标准和管理规范的条件下，明确各方面职责和业务分工，统筹协调。

这里以作为国家电子政务四大基础数据库之一的法人库的主数据管理为例说明数据中台的治理情况（如图16）。

 

图16、法人主数据管理架构示意图

图片来源：李广乾，《中国信息化建设的理论与政策研究》（电子工业出版社2016年出版）。

 

从管理来看，我们不能仅仅将法人主数据管理看作是微观层面的纯技术问题，而必须从国家治理层面去理解和认识[8]。这包括三个方面：首先，从建设来看，法人主数据管理涉及法人的所有注册登记部门和业务主管机关；其次，从应用来看，法人主数据涉及所有的政府业务处理部门以及银行、保险、征信、民生服务等诸多行业和企业；第三，从信息更新来看，法人主数据管理也涉及各行各业，与其应用过程相配套。总之，一方面，法人主数据管理直接服务于各行各业的业务处理过程；另一方面，法人主数据管理必须从国家宏观层面进行建设、管理和维护，统筹考虑各方面的关系，从国家电子政务顶层设计高度去规划建设。

其次是如何具体构建数据中台？

前面已经从多个方面，对数据中台的定义、属性及其与各方面的关系进行了分析和论述。基于上述分析，我们谈谈构建数据中台的若干注意事项和方法论。

1、选择有效的架构建构方法。目前所见的多数讨论中台问题的材料，大多缺乏合理的架构建构方法，随意性较大。就中台的架构建构方法来看，FEA是很不错的选择。尽管这是规划电子政务的，但对于互联网企业的轻装信息化[9]规划建设仍然具有理论指导意义。

2、综合规划业务中台和数据中台。当前的很多有关中台问题的材料，都是孤立地讨论数据中台或业务中台的建设，从我们的上述分析来看，这显然是不够的。为此，我们借鉴FEA的方法论，在构建业务参考模型的基础上，构建业务中台（服务构件参考模型）；在构建数据参考模型的基础上，构建数据中台（数据构件参考模型）（如图17所示）。这应该是我们在讨论所谓中台战略时所应该有的思维路径和技术方法。

 

图17、中台的构建思路

 

对每个国家来说，业务参考模型-服务构件参考模型（业务中台）、数据参考模型-数据构件参考模型（数据中台）的规划设计，都是不同的[10]；同样，对每个企业来说，必须充分地基于企业的行业发展特性和业务性质，进行深入研究和规划自身的业务参考模型-服务构件参考模型（业务中台）、数据参考模型-数据构件参考模型（数据中台）。

3、基于小数据理念构建数据中台。当前人们将数据中台看作是企业所有业务的数据管理系统的建设，这不应该是构建数据中台的科学合理的方法，从某种程度上是一种“挂羊头卖狗肉”的表现。将“数据中台”看作是包罗万象的企业全部的数据解决方案，只会让“数据中台”失去其时代性、科学性和理论创新价值，特别是抹杀我国互联网企业在企业信息化架构建设方面的探索价值、创新意义。

将小数据看作是数据中台建设的核心，并不会降低数据中台建设的地位和作用。实际上，基于前述分析，小数据系统建设仍然是一个非常复杂的工作，是一项系统工程，几乎涵盖企业信息化建设的各个方面，需要各方面的协同配合。尤其重要的是，小数据系统建设更多的是企业信息化建设的基础性工作；这也就表明，数据中台建设将克服之前的功利性和赚快钱思维，意味着（互联网）企业信息化建设将向纵深发展。

 

 

来源：BigDataplus

作者：李广乾