本文先梳理了为何需要数据中台，以及数据中台构建需要用到什么技术，什么平台。

01

在谈过业务中台和数据中台的区别后，今天再谈下数据中台。首先我们看下网上对于数据中台的一个定义和说法，即：

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。这些服务跟企业的业务有较强关联性，是这个企业独有且能复用的。

如果单独看这个定义，那么数据中台很容易被理解为企业里面的BI系统建设，包括了ODS库和数据仓库，同时支持OLTP和OLAP能力。也可以说是构建企业的大数据平台。

而今天自己想谈下对数据中台这个概念的一些理解：

首先我们要看到数据中台是整个企业中台战略的一部分，是配合企业微服务架构转型和业务中台能力构建不可缺少的部分。

如果没有整个中台战略，那么就不存在数据中台，你单独去建设大数据平台或BI平台就可以了。

数据中台不是一个单纯的数据技术平台，而是一个共享数据能力提供平台。对于数据的采集，清洗，存储和加工最终都是为了开放数据服务能力。

如果说业务中台更多的是业务能力的开发，那么数据中台就是聚合后的数据服务能力的开放。

为何要开放数据服务能力？

这个绝对不是简单的给上层做BI来分析用的，而是这种数据服务能力需要去支撑前台业务场景和业务功能的实现。

即这种数据服务能力需要具备一定的数据实时性要求，那么我们可能看到对于业务中台本身也会提供数据服务能力，比如订单中心也提供订单查询数据服务能力，那么两者的区别究竟在哪里？

初步分析包括：

1. 业务中台数据服务实时性最强，数据中台数据服务准实时
2. 业务中台数据服务单一数据对象，而数据中台数据服务可以提供关联后多数据对象聚合后数据
3. 业务中台数据服务包括了CRUD各种类型，但是数据中台的数据服务一般为单一的查询服务

02

这点理解清楚后，我们再回来就容易搞清楚为何数据中台需要提供准实时的数据服务API接口——

要看到在微服务架构下构建的业务中台各个中心，按照标准的微服务架构要求，各个中心对应的数据库本身也完全是独立和拆分的，订单中心是订单数据库，用户中心是用户数据库，相互之间完全垂直独立以方便应用的灵活扩展。

但是这种数据库拆分带来最大的问题就是——当业务场景需要底层多个业务数据对象提供关联后聚合后的查询数据集的时候极不方便。

为了解决这个问题，实际上我们有两种做法来进行处理：

第一种：构建一个领域服务层组件

即我们单独构建一个领域服务层组件或微服务模块，来提供整合后的领域服务能力，这个组件如果需要提供一个关联多个业务对象的数据集合，那么就需要调用过个API接口返回多个独立数据集合，然后在组件业务逻辑实现中来完成多个数据集的整合工作。

虽然对于查询类服务没有分布式事务问题，但是这种方式在性能上肯定存在较大损耗，优势则在这种方式不用前台访问多次API接口服务，同时又保证了数据的实时性。

第二种：构建数据中台，然后提供开放数据服务能力接口

这种方式就是构建数据中台，在数据中台完成业务中台多个数据库数据的数据采集和整合，形成一个完整的跨越的数据模型，由于有了完整的数据，因此很自然能够提供关联聚合数据对象服务的能力。

但是这种方式的问题也比较明显，就是如何保证数据本身的实时性和一致性，完全的实时往往很难保证，那么如何保证数据的准实时性，如何保证数据采集过程中出现问题而导致数据不一致也需要考虑。

把整个想清楚了，也就是想清楚了数据中台的一个关键作用，就是提供准实时的聚合数据服务能力API接口并进行开放给前台使用，方便前台业务场景和功能的实现，而不是简单的提供一个供分析决策的数据库。因此对于数据中台的这个关键能力我们可以简单的理解为：

分布式ODS库+能力开放平台+准实时数据能力提供

这个就是我们前面谈到的数据中台的一个关键能力提供，那么我们谈到数据采集集成技术，分布式数据存储，实时数据集成，数据流处理，包括类似Hadoop大数据平台等，所有这些都是数据中台在实现过程中为了满足分布式+实时性的技术支撑。

先理解清楚为何需要数据中台，再来搞清楚数据中台构建需要用到什么技术，什么平台，整个对中台战略，中台构建的思考逻辑才会清楚。

本文由 @人月神话 授权发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议