一张图讲清数据中台来龙去脉

阶段2：传统单体架构阶段的数据应用（DB->DW），引入MDM

传统单体应用有一个问题，就是具有主数据属性的数据分散在各个单体应用中。以物料为例，物料在多个系统（SRM、ERP、CRM）中都会存在。

一个物料涉及到采购属性，它是存放在SRM系统中。

一个物料涉及到库存属性，它又是存放在ERP系统中。

一个物料涉及到销售属性，它又是存放在CRM系统中。

所以对于同一物料，它没有形成一个完整统一的视图，分散在各个系统中。很可能多个系统都在对同一物料分别维护，进而导致数据不统一。

基于这个原因，我们一般在单体架构体系，一般会建设MDM主数据平台，把原来各个业务系统中基础数据统一起来。

如果其他业务系统需要这个主数据，一般通过分发的方式或接口的方式，分发给各个业务系统使用。

阶段3：业务系统从传统单体架构演变为微服务架构，需要数据架构体系从BI架构向数据中台架构演变

数据中台的缘起

原来在大单体下一个业务系统下就能完成的关联查询，在微服务架构下需要跨多个应用，实现起来变得非常麻烦（需要大量API调用或数据冗余），这个时候我们就需要构建一个数据中台，来解决这个问题。

那问题来了，如果企业的系统仍然是一个个单体架构体系，没有进行微服务号，那么有必要建设数据中台么，还是建设传统的数据仓库？答案是建数据中台，因为传统的BI是封闭的系统，它只是为了上层的OLAP数据分析和展示使用，而不能实现数据能力以数据服务的形式提供出来，而数据中台有这个能力。

数据中台核心价值：提供共享的数据服务能力，实现数据反哺业务

数据中台和传统的数据仓库最本质的不同（也是最大的价值），就是通过“数据服务层”实现数据能力开放，把数据资产通过数据服务暴露给业务应用，而不仅仅用于传统的OLAP BI分析。这就是常说的数据实时反哺业务，这样数据的价值就能体现出来了。

MDM与业务中心的关系

微服务架构下，MDM主数据平台存在的价值不大了，因为每个业务中心本质上就是一个个的“主数据中心”了。主数据平台的能力已经变成业务中台领域各个微服务中心的能力。

为什么数据中台更火？

数据中台、业务中台、技术中台等几大中台概念很热，几大中台中数据中台尤为明显。

先说业务中台，那是因为业务中台往往会涉及到原有系统的拆解和改造，如果做不好则伤筋动骨，这很不仅仅是一个技术问题，涉及到原有系统的改造，往往会动到原有体系的奶酪。

再说，技术中台搭建，这个需要时机，也需要掌权人具备长远的眼光，因为短期不容易见到成效，需要基于技术中台不断的搭建业务应用，价值才能显现。

只有数据中台，是在业务应用旁另起炉灶，不会动到原有体系，又能快速把已有数据的价值体现出来，这也是为什么数据中台更受企业以及厂商的追捧。

数据集成需求是否走数据中台？

如果是普通的数据集成，完全没有必要走数据中台。数据中台的价值是数据反哺业务，但他不是用于这种简单的数据集成。走了数据中台，反而因为多了一层，数据的实时性、数据的一致性、以及技术难度都会要做很多工作。那么什么情况走数据中台：

原则1：数据需要跨多个业务系统，需要共享数据，这是核心判断点。

原则2：这个数据不是单一的数据源头，而是要跨多个数据对象，进行关联整合以后的数据。

同时满足以上两点，才走数据中台。比如：整个采购执行统计分析的数据，可以走数据中台，因为它会涉及ERP系统、报账系统、SRM系统等等。再比如供应商基础数据，完全没有必要走数据中台。

数据中台下想要数据反哺业务，但数据实时性不足的问题

实施数据中台数据反哺业务，但是数据获取实时性降低了。关键原因有两个方面：

第一个问题，有些数据中台核心的做法是使用ETL的工具去做数据的采集和集成，ETL工具本身是一种定时数据抽取和采集的方式，所以在这个点上，数据的及时性出现了问题。

第二个问题，数据中台本身提供数据查询服务，业务系统也只能增量的查询数据服务有没有新的数据服务产生。

所以在这两个阶段都出现了时间上的延迟。这种情况，要做到数据实时反哺业务往往就会出现困难，同时由于实时性的问题，还导致了数据的不一致问题。所以甲方奇怪，用了数据中台后反而数据实时性出现问题。数据出现了更多不一致的情况。

解决思路：

1、仍然要参考传统消息中间件、传统集成平台的做法，当采购订单系统有新的订单数据产生的以后，通过消息推送，直接实时推送数据中台里边。

2、数据中台在拿到采购订单数据以后，又需要实时的调用合同系统提供的一些订单导入接口实时推送数据。

不要简单的理解，实在建设一个数据共享中心或者大数据平台。

参考

数据中台来龙去脉-用一张图完整讲解