读数据中台笔记整理(200904)

这本书《数据中台-让数据用起来》是我和中台战略一起购买的另外一本中台方面的书，今天读完前面4个小章节，并对整个书籍内容做了下泛读，整体质量还是不错，但是比中台战略要偏技术化点，适合数据规划和数据架构师阅读。

在读一本书的时候，我始终在强调其一你要抓住最核心的概念模型，其二你要对对比解析搞清楚和其它概念的区别。类似数据中台来说，首先你要搞清楚的就是数据中台的概念和定义，其次就是要搞清楚数据中台和业务中台的区别，和传统的大数据平台，BI了数据仓库的区别。只有把这些搞清楚了你对数据中台的概念才能够有一个完整的理解和掌握。

首先我们看下这本书给数据中台的一个定义：

数据中台是一套可持续的让企业的数据用起来的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断的把数据变成资产并服务于业务的机制。数据来源于业务并反哺业务，不断的迭代循环，实现数据可间，可用和可运营。

这里面最核心的就是将数据变化为资产并服务于业务的机制，数据来源于业务并反哺业务。我们基于这个核心内容可以进一步抽象下数据中台对核心的定义，我个人理解和定义如下：

数据中台本质是一个能够实现跨域数据融合，并在数据融合后对数据进行整合加工和分析，提供增值的数据服务能力给业务使用的一个平台。在我这个概念里面多强调了两点，一个是实现跨域数据融合，一个是提供增值的数据API服务能力给业务使用。

书籍里面提到了书籍中台四个方面的关键能力：

书籍中台需要具备 数据汇聚整合，数据加工提纯，数据服务可视化，数据价值 变现4个核心能力，让企业员工，客户，伙伴能够方便的应用数据。而这个里面的数据提纯加工对应的是数据资产管理的核心内容，即数据中台必须通过连通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，以满足企业业务对数据的需求。

数据中台和其它概念的关键差异分析

数据中台和业务中台的关系

我们先看下书里面的一些解释即：

业务中台更加偏向于业务流程管控，将业务流程中的共性服务能力抽象出来，形成通用服务能力。而数据中台则是抽象数据能力的共性，形成统一的数据服务能力。

对于上面这个解释不足够准确，为什么呢？

因为业务中台本身也会抽象数据共性提供数据服务能力，类似业务中台的供应商中心，客户中心本身也提供数据服务能力。那么时间最大的差异点在哪里呢？

即我们前面提到的，数据中台是实现业务中台核心共享数据的跨域整合，再通过加工后提供整合后的数据服务能力。这里面有两个重点，即： 第一数据要跨域整合，第二数据要加工处理后再提供增值服务能力 ，这个加工可能简单的汇总表，也可能是复制的底层数据模型和智能分析算法。

业务中台重点是业务数据化，而数据中台重点是数据业务化 ，数据来源于业务并反哺业务。就建设和支撑层面来说我原来也总结过，即业务中台是基础业务能力支撑，必须要有，数据中台是增值能力支撑，刚开始没有也不会影响到业务本身的运作。

再简单来说，以电商平台来举例，业务中台关键功能缺失导致的是业务流程走不下去，在业务协同上出现问题。而数据中台能力缺失导致的是没能够为用户提供增值服务，让用户顺带多买点东西。

两者的联系，书里面有一句总结还是比较准确，即数据中台和业务中台本身是相辅相成的，业务中台中沉淀的业务数据进入到数据中台进行体系化加工，再以服务化的方式支撑业务中台上的应用，而这些应用产生的新数据又重新流转到数据中台，形成循环不息的数据闭环。

数据中台和数据仓库和大数据平台

对于数据中台和数据仓库的区别，书里面的总结比较到位。

即数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是数据能力渗透到各个业务环节，不限于决策分析类应用场景。数据中台持续不断的将数据进行资产化，价值化并应用到业务，而且关注数据价值的运营。

这里面的关键区别就在于数据中台能力要服务于业务系统准实时协同需要。

为了准实时，一方面你会看到数据中台架构上实际上是包括了大数据平台的核心架构和分布式存储内容，同时还包括了大数据平台中的实时计算和流处理能力。其次，为了将能力提供给业务系统，往往数据中台整体架构上一定会体现一个统一的数据服务能力开放层，这个在传统的数据仓库或大数据平台上是没有的。

数据中台和BI数据仓库有重合，也有交集。相同的就是整个数据采集集成，数据存储，数据模型构建，数据开发和分析，这些都需要。差异点在于数据中台需要有统一的数据服务能力开放层，提供给业务使用，而弱化了传统BI里面的数据分析和报表展现层。

所以我们首先搞清楚数据中台是为增值业务需求服务，BI平台为管理经营决策服务。这使得两者在数据模型构建，数据开放和提供策略上有差异，但是核心的技术平台能力则是相同的。即你可以基于Hadoop整个技术框架体系来构建数据中台，也可以用来构建BI数据仓库。

数据中台的业务赋能

简单总结就是： 业务数据化，数据资产化，资产服务化，服务业务化，业务智能化持续赋能业务闭环。 数据中台作为整个企业各个业务所需数据服务的提供方，通过自身的平台能力和业务对数据的不断滋养（业务数据化），会形成一套高效可靠的数据资产体系和数据服务能力（数据资产化和资产服务化）。这样当面对市场变化，需要构建新的前台应用的时候，数据中台能够迅速的提供数据服务能力。

数据中台要求整个企业共用一个数据技术平台，共建数据体系，共享数据服务能力。数据中台的目标是实现企业经营的数据化，精细化，智能化，本质是建立一套可持续让企业数据用起来的机制。

数据中台的建设

对于数据中台的建设，实际上我们要看到两个方面的内容：

• 单纯的数据技术平台的建设
• 数据内容和数据资产的建设

我刚才说了单纯的数据技术平台还可以用于BI分析，技术平台能力本身就是相通的。

对于技术平台我们要考虑就是数据采集集成，数据存储，数据处理加工和计算，数据分析各个层面的技术工具和组件。

对于数据内容的建设，实际上包括了四个方面的内容，书里面总结如下：

1. 技术体系 （包括大数据存储计算技术和数据中台工具技术组件）
2. 数据体系 （围绕数据模型为核心，并围绕数据资产全生命周期展开）
3. 服务体系 （通过数据中台的服务组件能力，将数据变为服务）
4. 运营体系 （将数据服务作为可运营的商品一样，来构建一套运营服务和管理体系）

数据中台的架构

对于数据中台架构后面还要单独写文章详细描述，从书里面给出的架构图我们可以看到基本模式都是一样的，即最底层是数据基础设施和数据技术平台。再往上分别是数据汇集，数据开发，数据体系，数据资产管理，数据服务几个大模块的内容。

所以我们先看下整个数据中台架构里面大模块分法上的一些思路。

数据汇聚和数据开发

这个分开为两个大模块是合理的，即数据汇聚仅仅只复制数据集成的事情，比如我们常说的数据采集，ETL方面的事情。而数据开发即是数据采集过来后还需要对数据进行加工处理，比如形成宽表或汇总表，基于数据分析算法进行数据汇聚计算形成新的数据结果等。

数据资产管理和数据体系

首先我们可以看到数据资产管理即我们常说的数据全生命周期管理，类似我们原来谈MDM主数据管理经常谈到的元数据管理，数据标准，数据质量管理，数据安全，数据创建变更全生命周期流程管理等都在该模块能够看到。

对于数据体系是否理解为不同的数据应用域，书里面提到的数据体系包括了贴源数据，统一数仓，标签数据和应用数据。可以看到数据本身分层，数据也可以分数据域。

从全生命周期如何看数据？

如果从数据全生命周期来看，实际上我们可以看到可以分为数据的入库过程，数据的存储和模型构建，数据的对外能力提供过程。对于数据的入库包括了数据汇聚，数据开发；对于数据的存储包括了数据模型和数据体系，对于数据对外能力提供包括了数据服务层构建。

而实际的数据全生命周期管理刚好应该是贯通前面几个阶段的一个完整管理和管控流程。

上面这个图可以看做是书籍里面的一个配图，给出了数据中台的整体结构，在上面一篇文章里面我也谈到了整个数据中台包括了数据汇聚，数据研发，数据指标体系，数据资产管理和数据服务体系几大块的内容。

在谈之前还是重新回顾下数据中台的定义，即：

数据中台是将数据转变为资产并服务于业务的机制。稍微再扩展下这句话就是实现跨越数据的汇聚和融合，并对数据进行加工处理形成有价值的数据资产，再将数据资产以服务化的方式开放出去满足业务需求。

在简单点来看，从整个数据的生命周期，数据中台包括三个方面的内容。

1. 数据入库的过程（数据的采集，数据的汇聚）
2. 数据的存储和加工过程（数据的存储，加工和开发，数据模型，算法，过程调度）
3. 数据的开放过程（构建完整的数据资产和指标体系，并形成数据服务对外开放)

以上就是一个完整的数据中台内容。

数据中台底层技术架构

当我们在谈数据中台的技术架构的时候，一个无法绕开的还是基于Hadoop的大数据平台和技术架构体系，如下为当前Hadoop 2.0的一个标准技术架构图。

先在网上摘录了一段比较Hadoop2.0和1.0的主要区别和改进点如下：

Hadoop2.0和1.0最大的区别点就在于增加了YARN集群资源管理系统这一层，YARN是一个资源管理系统，负责集群资源管理和调度，MapReduce则是运行在YARN上的离线处理框架。改进点主要还是对1.0架构中类似NameNode，JobTracker的单节点扩展能力进行提升。

1、针对Hadoop1.0单NameNode制约HDFS的扩展性问题，提出HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时彻底解决了NameNode单点故障问题；

2、针对Hadoop1.0中的MapReduce在扩展性和多框架支持等方面的不足，它将JobTracker中的资源管理和作业控制分开，分别由ResourceManager（负责所有应用程序的资源分配）和ApplicationMaster（负责管理一个应用程序）实现，即引入了资源管理框架Yarn。

3、Yarn作为Hadoop2.0中的资源管理系统，它是一个通用的资源管理模块，可为各类应用程序进行资源管理和调度，不仅限于MapReduce一种框架，也可以为其他框架使用，如Tez、Spark、Storm等。

以上区别参考：https://www.jianshu.com/p/23e2634ce1f9

为何重新提到Hadoop，可以看到在构建整个数据中台的时候，我们会用到 数据采集框架，数据存储框架（文件存储，结构化数据库，非结构化数据库，内存数据库），数据计算框架（批计算，流计算，实时即席查询计算），数据分析框架 这四大类的内容。

而实际上上面这四块的内容在Hadoop完整框架体系里面都包括，在搭建完整的大数据平台后，你可以基于实际的业务场景需求来选择使用不同的技术工具和组件来解决问题。

因此如果单纯从技术层面来看，你会发现在构建数据中台的时候确实是需要一个技术平台，能够实现数据从采集集成，到存储，到加工处理，到能力开放的全生命周期管理能力。

基于以上的思考，我们看到实际的构想完全可以是基于Hadoop的底层大数据框架，来构建一个覆盖数据全生命周期管控加治理的平台。这个平台除了Hadoop外还需要做一些外围其它开源工具的集成，基于数据使用场景和需求的定制开放，实现数据能力开放和数据运营。

即底层技术平台下沉，在上层构建一个面向数据全生命周期的管控治理平台。

数据汇聚和存储

首先谈下数据汇聚和集成，实际上包括了多方面的内容，具体为传统的结构化数据库间的数据集成和交换，这个类似传统的ETL工具，但是在大数据场景下增加了结构化和非结构化数据之间的集成和对接。比如结构化数据之间汇聚到HDFS分布式存储等这种场景。当然在这个过程中结构化数据库间的传统ETL集成仍然存在，这个类似DataX这种工具是完全包含的。

在这个过程中我们看到有要给分支，就是数据库数据的实时采集和处理，类似数据库同步复制技术，在Mysql里面有类似BinLog日志的同步复制，对于Oracle等结构化数据库也有类似商用产品来完成。

除了这个外比较常见的就是日志的采集和处理，类似Flume工具来完成日志的采集和处理。对于基于日志的分析查询系统，当前主流又有ELK的开源整合解决方案。对于Elasticsearch除了本身强调的全文检索和查询能力外，本身也提供了对日志的分布式存储能力，对应的还有类似Solr的解决方案等。

还有一个重要的分支就是互联网数据采集和网页爬虫，比如常说的Nutch，现在各种开源的网页爬虫软件和工具集很多，特别是基于Python的网页爬虫更是发展相当迅速。

离线数据交换和实时数据交换

离线数据交换是针对数据时效要求低，吞吐量大的场景，解决大规模数据的批量迁移问题。而对于这种数据集成实际上我们看当前的各种开源实现，主流的可扩展思路都是构建三类灵活配置的插件，即数据读取插件，数据写入插件，数据交换核心模块。

对于实时数据交换主要是负责把数据库，日志，爬虫等数据实时接入到Kafka, Hive, Oracle等存储中，便于后续实时计算或提供给业务查询分析使用。实时同步两个核心业务，数据订阅服务，数据消费服务。

数据汇聚是数据中台建设的第一个环节，其主要目的是打破企业数据的物理孤岛，形成一个统一的数据中心，为后续数据资产的价值挖掘提供原始材料。即数据汇聚目标就是建立一个大的数据共享中心，同时为了方便后续弹性扩展，这个数据中心应该是一个分布式的ODS数据共享中心。数据集成和汇聚是后续数据开发，数据分析的前提。通过前面内容我们也可以看到数据集成需要考虑的两个关键内容，一个是数据本身的类型，一个是数据集成的实时还是非实时要求。

数据开发

数据开发涉及到的产品能力主要包括三个方面的内容，分别是离线开发，实时开发和算法开发。

1. 离线开发： 离线数据加工发布和运维，数据分析，在线查询，即席查询
2. 实时开发： 数据的实时接入和实时处理，简化数据流处理的加工过程
3. 算法开发： 类似回归，聚类，人工智能，机器学习等算法的开发和应用，挖掘数据价值

数据计算的四种类型

将计算能力根据应用场景抽象为四种类型，包括了批计算，流计算，在线查询和即席查询。对于批计算主要是MapReduce框架进行，对于流计算主要是类似通过Storm ,Spark Streaming框架来实现等。而对于在线查询往往基于内存数据库，或者基于Elasticsearch，Solr来实现。对于即席查询采用类似MPP数据库，Impala等。

对于在线查询和即席查询对数据实时性要求最高，而对于批计算往往更好应对大数据量需求，数据在中间过程也可以落地而不是必须全部在内存里面完成。

实时开发

要看到在构建数据中台的时候，实时开发是一个重点。随着数据应用场景的不断丰富，企业对于数据价值反馈到业务中的时效性要求也越来越高，很早就有人提出一个概念即数据的价值在于数据的在线化。对于实时开发和计算具备如下三个关键特点。

1. 实时且无边界的数据流.(数据流按时间发生顺序被实时的消费和订阅）
2. 持续且高效的运算
3. 流式且实时的数据集成

基于Storm，Spark Streaming，Apache Flink构建的一站式，高性能实时大数据处理能力，广泛适用于实时ETL，实时报表，监控预警，在线系统等多种场景。

数据中台的数据体系建设

在谈数据中台的时候，我们一般会谈两个方面的关键内容，一个是数据中台的技术架构，你可以看到前面谈到的数据汇聚和数据开发更多是偏围绕Hadoop体系的中台技术架构；第二个关键内容就是数据本身的内容架构，数据在存储的时候整个数据内容，数据模型，数据标准究竟应该是如何的？

因此数据中台数据体系是在全域原始数据的基础上，进行标准定义和分层建模，数据体系建设最终呈现的结果是一套完整，规范，准确的数据体系，可以方便支持数据应用。

中台的数据体系建设应该具备如下特征

1. 覆盖全域数据（覆盖所有的业务过程域）
2. 结构层次清晰（数据应该是分层的）
3. 数据准确一致(命名，粒度，计算口径，模型等）
4. 性能提升和降低成本

在数据中台的数据体系架构里面，书里面将整个数据体系从下到上分为了四层。

1. 贴源数据ODS层
2. 统一数据仓库DW层
3. 标签数据TDM层
4. 应用数据ADS层

我们对这个分层再做一下理解和解释。首先你可以看到从下到上是即是从系统->业务域-》跨越的一个层层聚合和整合的一个过程；其次就是在整个数据聚合和整合的过程中，数据来源的业务域的边界本身会越来越模糊，同时数据由于不断的汇聚和聚合，数据本身粒度会越来越粗。

这个粗粒度如何理解？

比如我们对客户做分析，最终到顶层你可能只得到一个长期优质VIP客户的结论。但是支撑这个结论，我们在底层采集了大量的数据，经过维度分析，标签计算分析做了大量的工作才完成。

在我们传统的BI和数据仓库设计里面，我们经常说的只有三个内容，即ODS库，DW库，维度建模的数据模型，而 在整个数据中台的数据体系里面增加了标签数据层和应用数据层 ，也可以更好的看到这两个层次的增加更多的都是为了业务应用提供服务的。

对于标签数据层，我们再来看下解释，即是面向对象建模， 对跨业务板块，跨数据域的特定对象数据进行整合 ，通过ID-Mapping把各个业务板块，各个业务过程中的同一对象数据的数据打通，形成对象的全域标签体系。

举个例子来说你要建立客户的标签体系，客户的标签会来源于客户的静态属性信息，同时更多的是来源于动态的行为数据信息，而这些行为包括了注册登录，商品挑选，实际采购发生，支付，商品评价等诸多的业务域和业务模块，要建立完整的客户标签，那么这些业务域数据必须打通并建立关联映射。

对贴源数据层理解

对于书里面谈到的贴源数据层你直接理解为传统的ODS库本身是没有问题的。贴源数据层重点就是将企业已有各个业务系统中的数据抽取和集成到一起，形成全量的业务数据。面对业务中台架构模式下，就是需要对所有业务中台对应的业务数据库进行数据采集和集成。

注意当前主流的方式已经从ETL变化为ELT，即只负责最简单的数据抽取和装载，没有复杂的数据映射和转换动作，当我们看类似DataX这种工具的时候你也可以看到这个特点，变得更加轻量同时性能也更高。

如果要说贴源数据层和传统ODS库的区别，那么贴源数据层仅仅做数据的汇聚和整合，并不具备传统意义上的ODS的如下功能，即数据交换，实时性，报表等功能。

对标签数据层的理解

对应数据仓库层这篇文章不详细展开，只谈下标签数据层。首先我们能够看到就是标签数据层是围绕一个关键对象进行的分析和建模，而且这个动作是完全跨越进行的，数据粒度更粗更抽象，但是能够发挥的数据价值往往却越大。因为标签层真正整合了跨域的数据，包括静态数据和动态数据，同时在数据之间建立了关联，同时通过各种算法对数据进一步加工和聚合。

标签数据层是面向对象建模，把一个对象各种标识打通归一，把跨业务板块数据域的对象数据在同一个粒度基础上，组织起来打到对象上。标签数据层建设，一方面让数据变得可阅读与理解方便业务使用，另一方面通过标签类目体系将标签组织排布，以一种适用性更好的组织方式来匹配未来变化的业务场景需求。

对于标签对象，实际上我们看到主要分为三类，即人，物，关系。对于关系本身有可能是人和人，人和物，物和物都有可能。当然也可以从静态和动态层面来理解，有静态属性类标签，有动态行为类标签，比如采购，支付等就是动态行为类标签。而实际上你可以看到很多关系信息的产生往往也来源于动态行为标签。

对于标签本身的分类，又可以分为基础属性类标签，统计类标签和用户画像。还有一种说法感觉更好，就是基础属性类标签，统计类标签，算法类标签。我们拿一个客户相关的标签来举例。

1. 基础属性类： 年龄段，区域，性别，婚姻状况，年收入段
2. 统计类标签： 活跃度，客单价，最常购买商品类别，复购率
3. 算法类标签： 消费偏好，消费价值，用户画像类特征(类似潮流达人，宅家一族等）

从这个也可以看到，统计类标签往往都来源于动态的关系类数据的分析，但是这些关系类数据分析最终又会关联到具体商品的类目属性上面。

标签和用户画像

当从标签谈到用户画像的时候，原来有一个概念我一直没太理解清楚，今天重新进行了下理解。首先我们看下用户画像，实际上你可以看到两种场景的用户画像。

• 场景一：对用户张三进行用户画像 （结果可能是潮流一族，爱尝鲜，数码玩家等）
• 场景二：对晚上购买啤酒类商品的用户群画像 （结果可能是单身男，IT，加班族等）
• 人物群体 - 人 - 关系 - 物 - 物群体

在前面讲的三个关键对象基础上，我们做下扩展就变成了五大对象，即增加了人物群体和物品群体两个群体对象。有了群体对象我们就有了基于标签设计进行数据聚合的基础。

我前面为啥聚两个场景，实际上你可以看到刚好是聚合的两个端，当我们对单个特定用户画像的时候你可以看到往往对对商品群体进行聚合分析和处理，是在物品这端。当对物品的购买意向进行用户群画像的时候可以看到是在用户群体这段进行聚合，最终得到一个抽象的结果。

那么在场景一我们能否给出用户维度的画像，比如得出张三是单身的画像。而这个就是我们说的大数据里面的关联类分析，比如网上购买啤酒行为和用户的单身属性之间往往具有强关联，当具备这种强关联的时候，我们可以给张三打一个单身的标签。

数据资产管理和数据服务体系建设

企业经营沉淀的数据是企业的核心资产，资产一定有价值体现，即数据经过应用会产生价值，这个价值一方面是直接支撑业务运作，一方面是支撑管理决策。因此在看数据资产的关键特征的时候也看到，其一是数据是企业用拥有和控制，其二是数据能够带来未来经济利益。

数据资产管理功能面临的挑战

1. 缺乏统一的数据视图
2. 数据基础薄弱
3. 数据应用不足
4. 数据价值难以估算
5. 缺乏安全的数据环境
6. 数据管理浮于表面

基于这些问题而提出了数据资产的管理目标主要包括了四个方面，即可见，可懂，可用和可运营。

数据资产在整个数据中台里面承上启下，即数据先通过数据汇聚集成，数据开发后形成数据资产，然后再将数据资产以服务的方式开放出去为数据应用服务。

从这本书的逻辑框架结构出发，当我们在谈数据资产管理的时候，一定会考虑和上一个章节数据指标体系之间的关系，一开始总感觉两者是重复的，但是详细看了内容后基本梳理清楚两者的关系。即数据资产管理你可以更多理解为动态的管理过程，即数据管控和治理过程，但是对于数据资产静态结构呈现是如何的，分层是如何的？这个问题则是在数据指标体系里面解释的。

即数据资产管理更多是数据动态管控治理维度，而数据指标体系是静态结构维度。

数据治理的理论体系

国际数据管理协会DAMA从数据治理生命周期角度对数据资产的管理行使权和控制的活动(规则，监控和执行)进行了重点研究。定义了数据治理，数据架构管理，数据开发，数据操作管理，数据安全，参考数据和主数据管理，数据仓库和商务智能管理，文档和内容管理，元数据管理，数据质量管理这十个领域。以及目标和原则，活动，主要交付物，角色和职责，技术，实践和方法，组织和文化等7个环境因素。

CMMI提到的DMM模型是由五大核心过程域和一套支撑流程组成。五大核心过程域包括了数据管理战略，数据治理，平台和架构，数据运营，数据质量。

在我国也给出了DCMM的数据管理成熟度模型。DCMM充分结合了大数据特点和国内数据治理现状，形成了数据战略，数据治理，数据架构，数据标准，数据质量，数据安全，数据应用，数据生命周期8个核心领域和28个过程域，重点关注数据的管理过程和方法。

数据资产管理和数据治理的关系

数据治理是对数据资产管理行使权力和控制活动的集合。传统的数据治理内容通常包括了数据标准管理，元数据管理，数据质量管理，数据安全管理，数据生命周期管理。而数据资产管理在传统的数据治理的基础上增加了数据价值管理，数据共享管理等。

可以看到，数据资产管理实际核心就是数据全生命周期管理，你需要管理数据如何形成资产的过程，同时又需要管理数据如何形成服务共享支撑应用的过程。同时在这个过程中还存在大量的横切，即安全，质量，标准等。

数据资产管理你可以看到实际并没有太去强调数据集成后的，数据深层次开发和分析建模，更多的是在强调形成统一数据视图服务能力并为应用提供服务。而在数据资产管理我们看到的数据标准体系，元数据管理，数据质量管理等内容你会发现和我们常说的MDM主数据管理是完全相同的。而主数据管理核心目标仍然是形成共享的数据视图，并共享开放给业务应用使用，是为业务协同服务而不是为管理决策服务。

这不得不又重新让我们思考数据资产管理和MDM主数据管理是什么关系？

在这里我们假设一个例子来理解下。

还是以电商平台来举例，存在有用户中心，订单中心，配速中心，支付中心等多个微服务。那么这个时候对于用户信息的完整视图可能存在两种情况。

1. 全部在用户中心完成维护并共享

2. 基本信息在用户中心，地址信息在配送中心，银行账号信息在支付中心

对于情况一我们看到用户中心本身就需要自己完成主数据管理需要的一些关键职能，包括元数据管理，数据质量管理，数据服务能力开放等。但是要主要用户中心仍然是业务中台的一部分内容。而对于情况二可以看到，要提供完整数据视图必须进行数据汇聚，这个就到了数据中台，至少要在ODS层完成这个事情，这时候也不需要太多复杂的数仓建模，直接开放ODS库能力为服务即可。但是我们看到你仍然需要进行数据安全，数据质量管理，而这些管理就需要在数据中台具备这样的能力。同时数据中台也具备了MDM应该具备的部分能力。

基于以上思考可以看到

当大部分基础数据的统一视图能力本身就能够在业务中台单个微服务提供的时候，主数据管理职能基本都可以在业务中台就完成，反之则需要在数据中台完成。 建议是在数据中台的数据资产体系的贴源ODS层增加一个统一数据视图，即这部分往往是对多个贴源ODS表的进一步整合，形成完整的统一数据视图和数据服务能力。

注意，在数据标准里面提到了参考数据，在我们原来谈的时候经常会将参考数据作为主数据的一部分，而现在将参考数据从主数据里面拿出。参考数据是用于将其他数据进行分类或目录整编的数据，可以简单的理解为数据字典。而对于主数据管理也再列下我们经常谈到的核心管理内容。

1. 主数据相关标准和规范设计
2. 主数据建模
3. 主数据梳理和集成
4. 主数据质量管理
5. 建立灵活的主数据共享服务
6. 建立主数据维护流程（创建，变更，废弃等）

实际上大的主数据管理概念是包括了元数据管理，数据质量管理的，书里面单独分开描述也可以。而对于书里面的8.7.9提到的生命周期管理内容，个人感觉是很狭隘的一个理解，即只是将数据分为不可恢复，可恢复来谈了数据存储的生命周期。实际上数据生命周期管理是一个对数据完整的从产生，集成，变更，废弃，删除完整过程的管理，里面既包括了自动化流程，也包括了人工流程。

数据服务体系的建设

要注意一点，对于数据中台和数据仓库的区别，其中有一个关键点，就是数据中台会将数据能力以数据服务的方式开放出去，直接满足业务应用的需求。而不仅仅是用于上层的数据报表和数据分析决策。数据服务体系本身就是将数据变为一种服务能力，通过数据服务让数据参与到业务之中，激活整个数据中台，这也是数据中台的价值所在。

数据服务是对数据进行计算逻辑的封装（过滤查询，多维分析和算法推理等计算逻辑），生成API服务，上层数据应用可对接数据服务API，让数据快速应用到业务场景之中。数据服务是数据中台能力的出口，是支持数据应用的重要支撑。数据服务本身可以分为三类

1. 基础数据服务
2. 标签画像服务
3. 算法模型服务

可以看到对于标签画像和算法模型服务，都需要经过内部大量的算法计算后给出，实际已经不是获取原始的基础数据，而是获取通过原始基础数据加工和计算的结果，是更加粗粒度的数据。

我们再看下总体架构图里面的数据服务体系这层的内容，实际上类似数据服务总线，数据服务网关，数据服务的能力开放平台。即核心还是实现对数据服务的全生命周期管理，包括输入的注册接入，数据的订购消费，数据安全，数据流控等各方面的内容。

数据服务的核心价值主要包括四点

1. 确保数据在业务层的全域流通
2. 降低数据接口的重复建设
3. 保障数据获取的及时性和稳定高效
4. 使能数据能力扩展

其中对于确保数据在业务层全域流通是一个核心价值所在。数据服务可以对数据中台的全量数据进行封装透出，让中台的数据支撑数据业务，加速数据业务化的流程；数据业务产生的反馈数据可以回流到数据中台中，不断优化现有的数据服务，让数据在业务中持续流动。

数据服务本身的实时性和不落地性

在谈ESB服务总线或API网关的时候，实际上我们始终面临一个问题就是对于大量的类似对数据库表的查询类服务是否要接入到网关来统一管理，其典型特点就是不符合服务的粗粒度特征，同时数据量大，并发量大，每次打的数据获取量本身也对总线造成巨大的压力。

实际上我们重新来回顾这个问题可以看到，数据服务本身的开放本身应该是一种实时查询类服务，而不是为了给你查询到数据落地到本地的服务，实时用实时查，那么数据查询类服务完全可以按照应用逻辑层API接口的设计思路进行，即数据服务本身也可以做成分页服务模式解决大数据量的问题。

只要数据服务不用于数据集成和同步，那么网关就没有大的性能压力。

如果将数据服务获取的数据又落地到业务中台的各个微服务模块，那么可以看到这就是一种边界和职责不清的表现，即业务中台一定不关注数据汇聚的问题，对于数据汇聚，包括汇聚后能力的提供只能在数据中台完成。即使你可能会发现通过调用远程的数据服务API接口来是实现功能的时候造成的开发复杂度增加和分布式事务管理难度，也得通过其他方式去解决。

即满足数据一致性和时效性-》带了分布式事务和强耦合的问题-》通过业务应用层去解决问题。

智能应用是数据应用的核心组成部分，是从数据洞察到业务创新的重要支撑。智能应用结合数据建模和人工智能等多种技术，从数据中提取，挖掘，获取有揭示性和可操作性的信息。对于我们常见的人脸识别，图像比对，智能驾驶，语义分析等都可以纳入到智能应用。

当然我们也可以看到，智能应用的API服务接口看起来像是一个业务能力接口的，但是我们要理解实际是数据服务API能力接口，其原因就是在需要一个强大的数据中台或大数据平台，再加上算法模型才能够提供得出我们需要的这些API能力。