数据中台技术架构解读

数据中台技术架构解读目录前言 (3)一当前关于“中台”问题研究存在诸多问题 (3)二科学界定“数据中台”问题的基本原则 (7)三小数据是理解数据中台的关键 (11)前言数据中台最近特别火，之前还在炒概念，现在突然就看到有的企业已经宣传自家的数据中台了，有的企业向外介绍如何构建自己的数据中台，利用数据中台打造数据驱动的经营能力。

大家热衷于讨论什么是“数据中台”，并且还有“有一千个企业，就有一千个数据中台”的说法，但大家真的都理解了什么是数据中台了吗？本文基于笔者的个人思考，首先介绍了当前关于“中台”问题研究存在的3个主要问题，然后从3个方面说明了科学界定数据中台的基本原则，最后指出小数据是理解数据中台的关键，以更加科学合理的角度使读者更加清晰、全面的认识数据中台。

”一当前关于“中台”问题研究存在诸多问题Supercell，芬兰移动游戏巨头，成立于2010年，拥有《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等全球热门游戏。

据说，2015年12月马云亲自率队到Supercell公司进行商务拜访，马云对Supercell的高效运营无比感慨，将其经营秘密概括为中台战略，要求阿里巴巴按照“大中台、小前台”的组织原则进行公司架构改革。

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

1.1对数据中台的定义不清目前关于数据中台的定义很多，笔者根据网上数据中台相关著作或文章，搜集了一些对数据中台的定义，供读者参考，如下表所示。

表1 网上关于数据中台的定义从上表这些定义来看，人们对于中台的解释还是很不一致的，有的定义甚至还谈不上是严格的定义，充其量只能说是对其某方面属性的简单描述，还谈不上是对其本质属性的界定。

1.2缺乏明确的数据中台架构模型阿里巴巴从2009年就开始建设共享业务事业部，已经为中台战略在转型过程中将会面临的组织间业务协作、业务核心能力的沉淀、组织KPI考核等方面都做了很好的实践和经验沉淀，阿里巴巴共享业务事业部的架构图也被阿里的人看作是解读阿里中台战略最常用的一个图，讨论阿里中台战略的时候都会用到。

图1 阿里巴巴业务架构中的“共享业务事业部”但这个图也不是太清楚，比如说，“共享业务事业部”并没有具体描述各模块的数据流转关系，其八大模块颗粒度并不一致。

图2是OPPO公司发布的针对公司内部的数据中台的架构，图3是袋鼠云数据中台战略，是一家脱胎于阿里云技术架构的一个技术公司，专门给阿里云提供技术服务的企业，这家企业也算是阿里系的一个部分。

图2 OPPO数据中台OPPO将数据中台分为4个层次，其中最下层是统一工具体系，涵盖了“接入—治理—开发—消费”全数据链路；基于工具体系之上构建了数据仓库，划分成“原始层—明细层—汇总层—应用层”，这也是经典的数仓架构；再往上是全域的数据体系，什么是全域呢？就是把公司所有的业务数据都打通，形成统一的数据资产，比如ID-Mapping、用户标签、内容标签等；最终，数据要能被业务用起来，需要场景驱动的数据产品与服务。

图3 袋鼠云数据中台策略从上图可以对比看出，袋鼠云对于中台的认识和OPPO存在着很大的不同，尤其是对业务、技术、方法是有差别的。

1.3无法区别“中台”与平台、前台-后台等概念的关系从某种意义上讲，如果能够科学合理地设计后台并有效地处理业务和数据之间的衔接关系，也就不会有所谓的中台的存在了。

因此，所谓的中台战略，必须说清楚中台是如何从后台分离出来以及分离之后的中台与后台的联系和关系。

不过，从目前众多的文章来看，我们无法得到满意的答案。

上述众多中台的定义与大数据关联不够。

当前人们将“中台”划分为业务中台、技术中台、组织中台和数据中台等几类，并从模块化、组件化、通用性等几个核心特征去界定其各自属性。

但是，光有“模块化、组件化、通用性”等特征是不够的，无法深入地分析“数据中台”的独特性。

所谓的“数据中台”与“业务中台”之间有着本质的不同，不应该简单地以“模块化、组件化、通用性”去模糊、掩盖其相互间的巨大差别，而“数据中台”的这种独特性只有从大数据中去寻找。

二科学界定“数据中台”问题的基本原则我们应如何正确的认识数据中台？笔者列了以下三个原则，一是应该遵循数据管理科学发展的基本规律；二是数据中台是中台思维的核心；三是合理地借鉴现有创新。

2.1遵循数据管理科学发展基本规律最近十年来，数据资源管理科学正在不断出现新的技术与理论创新，笔者认为可以从两个方面来认识和理解。

首先，这种理论创新来自人们对于信息化发展特别是数据与业务的不断细化分离趋势的规律的认识。

笔者认为应该要遵循这些年来在数据科学发展的基本规律，笔者把数据科学发展分为以下4个阶段：图4 信息化发展过程中的业务、数据的四次分离第1个阶段：数据库从业务系统建设中分离出来，结果就是出现了独立的信息资源中心，数据中心或容灾备份中心。

第2个阶段：信息资源分化出基础信息与业务信息，出现了独立的基础信息管理中心。

第3个阶段：元数据与数据库中结构化或非结构化数据的分离，元数据成为数据库与业务应用之间的又一交换平台。

第4个阶段：作为特定的元数据的具像化，主数据从元数据中独立出来，主数据库成为实现数据资源共享交换的独立基础数据库。

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

首先，这种理论创新来自人们对于信息化发展特别是数据与业务的不断细化分离趋势的规律的认识。

这些发展趋势表明，作为数据分离趋势中的主要内容形式的元数据、主数据应该成为数据中台的核心内容；其次，这种技术与理论创新来自于企业（信息）架构的不断深化。

我们要讨论数据中台，应该是在这样一个历史的轨迹下进行科学合理的建构。

我们都知道随着信息化业务的应用越来越复杂，人们对于问题的认识考虑的要素也越来越多，如何科学合理地对这些复杂的现象，各个部分之间的关系进行科学地区分，我们一般都喜欢用信息架构去表述，去理清各方面的关系，下图是企业信息化三大架构。

图5 企业信息化三大架构第一个是IT架构，其实就是计算，网络，存储。

良好设计的IT架构，可以降低CAPEX和OPEX，减轻运维的负担。

数据中心，虚拟化，云平台，容器平台都属于IT架构的范畴。

第二个是应用架构，随着应用从传统应用向互联网应用转型，仅仅搞定资源层面的弹性还不够，常常会出现创建了大批机器，仍然撑不住高并发流量。

良好设计的应用架构，可以实现快速迭代和高并发。

数据库，缓存，消息队列等PaaS，以及基于SpringCloud和Dubbo的微服务框架，都属于应用架构的范畴。

第三个是数据架构，数据成为人工智能时代的核心资产，在做互联网化转型的同时，往往进行的也是数字化转型，并有战略的进行数据收集，有意识的建设统一的数据平台，并给予数据进行数字化运营。

搜索引擎，Hadoop，Spark，人工智能都属于数据架构的范畴。

图6 FEA参考模型而上图是美国联邦政府组织架构，这张图是我们经常讨论信息架构的时候用到的美国政府在用信息架构的技术方法去思考美国联邦政府电子政务的总体架构的图形，这是我们讨论架构理论对我们数据管理科学的又一个基本概括。

美国FEA关于联邦政府组织信息架构里分五个层面，一个是绩效参考模型，第二个是业务参考模型，第三个是服务构件参考模型，第四个是数据参考模型，第五个是技术参考模型。

2.2数据中台是中台思维的核心业务参考模型和服务构件参考模型其实在逻辑上具有很紧密的关系，大家如果能看到，服务构件参考模型是指每个政府机构内部都存在，都需要的共性的业务模块，从整个架构来说把每个部门都抽出来共同统一地开发和管理，方便整个电子政务架构的设计，服务构件参考模型就是业务中台的部分，数据参考模型是作为前面无论是业务参考模型还是服务构件参考模型数字化具体实现。

图7 三大模型与构建数据中台的关系现在所有的业务都要落实到数字化层面，数字化层面表现为数据以及对数据的处理，也就是数据参考模型要完成的工作。

但是在数据参考模型里并没有说数据中台是什么，数据参考模型是指对于整个电子政务架构数据的基本认识。

数据中台没有办法从数据参考模型里分出来，没有办法像前面从业务参考模型里分离出服务构件参考模型，也就是业务中台的内容。

2.3合理地借鉴现有创新当前人们将“中台”划分为业务中台、技术中台、组织中台和数据中台等几类，并从模块化、组件化、通用性等几个核心特征去界定其各自属性。

在2000年之后，无论是美国还是其他国家，都开始对各自的电子政务建设进行顶层架构设计，在这个过程中就自然地衍生出前述的所谓“业务中台”来了。

我国也在2006年出台了《国家电子政务总体框架》，也试图借鉴国际上的“业务中台”理念以克服重复建设的难题。

政府相对于企业更加注重整体规划，容易发展出“中台”思维；我国的工业企业无法独立开展企业信息化架构设计；互联网企业只有等到近年来规模做大、做强之后，才开始思考总体规划问题，也才产生“中台”思维。

三小数据是理解数据中台的关键谈到FEA服务构件参考模型的时候，也谈到了FEA从业务参考模型里汲取出了服务构件参考模型，笔者把服务构件参考模型作为“业务中台”，那么在数据参考模型里能不能也像前面构建出一样数据构件参考模型呢？笔者认为这是思考数据中台的一个基本出发点，关键就在于如何认识大数据的管理属性，而其中的关键是如何认识小数据。

笔者把小数据看作是对于大数据管理属性的数据，小数据非常符合人们对于中台思维的模块化、组块化、通用性等几个核心特征，为构建“数据构件参考模型（数据中台）”提供了最为直接的科学工具和手段，所以关键就是怎么样围绕这几个特征构建我们对于小数据的认识。

3.1关于小数据当前我们对小数据存在很多不同的认识，笔者认为讨论小数据必须明确三个前提：一是人们采集、加工海量数据的时候，通常都是某种具有特定目的的理性行为；二是要体现某种价值，“数据”本身必须能够表述一个完整的“信息”；三是完整的信息应该包含明确的主体、客体和行为。

小数据应该与数据容量无关，应该包含特定的含义，应该是结构化的数据，当然也可以在结构化里引用非结构化的，小数据应该是对于大数据的数据之间的宏观描述，小数据和大数据也是形影相随的。

小数据就是描述并管理大数据的数据属性的数据。

基于上述小数据的定义，笔者对于小数据做了一个区分，主要分为三大类，第一类，是关于特定类型的大数据的数据属性的数据；第二类，是描述大数据中所包含主体客体的基本特征的管理数据；第三类，是描述大数据中的行为过程的数据。

其中，第二类又可细分为两种，一种是对于大数据中所包含的主体、客体的一般属性的规定，另一种是满足某类主（客）体属性的所有对象的数据。