一个具体场景剖析业务中台和数据中台的关系

01.前言

数据中台和业务中台的区别，希望能够深入浅出，很容易理解的解释什么情况下需要业务中台，什么情况下需要数据中台以及双中台的关系。

我前面做了很多行业研究和案例分享，但是都是企业级的讲解，感觉都不够简单，不够落地，这里我用一个最清晰的订单服务的演进过程，来深度剖析双中台的关系 02. 一个订单服务的演进过程

订单服务是最常见的场景，下面我们用一个电商领域的常见订单服务的演进过程来详细剖析双中台为什么会出现，它们的价值以及关系。

第一阶段：单应用订单服务

下图是一个典型的电商订单服务的流程，用户号在某电商自营APP下一个产品订单，这个应用吧订单数据保存到数据库里。

第二阶段：多应用订单服务

该电商企业拓展了多个渠道，构建了另外的电商APP，提供给用户使用。于是，用户下订单就有了两个方法，分别在不同的应用里，比如自营APP和微信小程序，这是最典型的两个渠道。而真实的情况是一个电商企业会有非常多的渠道，有自营的，还有代运营的，还有线下的POS系统，还有合作伙伴通过API接入的，多个应用会同时创建订单。

这样带来的问题很明显：

用户体验不佳，一个用户不能看到在不同渠道的订单。
数据一致性差，订单数据分散在不同的应用系统中，数据不一致，同步复杂。
维护困难，当一个订单逻辑发生了变化，所有的应用逻辑都要重写，带来的很大的维护工作量，响应慢。

在这种情况下，为了能够掌握全局的销量情况，往往企业会构建数据仓库系统，将不同系统的数据都通过ETL的方式抽取到数据仓库中进行分析，这也就是OLAP的过程，但是由于数据量比较大，处理过程复杂，往往OLAP都是T 1以上的响应速度，也就意味着，比如企业要想看所有渠道的销量分析报表，只能看到一天以前的，而不能看实时的数据，如下图所示。

上图的橘黄色箭头表示在线交易处理流程，是生成数据的过程，而绿色箭头表示在线分析处理流程，是抽取处理分析的过程。

这是典型的数据仓库和商业智能的场景，而这样的数据利用的问题也是很明显的：

数据分析不实时，不能够实时出报表。
数据仓库往往都是单体架构，受限于数据的处理计算能力，扩展能力不强，往往只能分析一个阶段的数据。
响应慢，ETL的过程依赖于预设的分析主题设计，当要分析的数据结构发生变化时需要重新设计抽取逻辑，导致响应慢。

以上是现在很多企业典型的应用和数据架构，在这个基础之上，有了数据中台和业务中台的产生。 数据中台业务用例：精准营销

下图是典型的数据中台的业务用例：精准营销。

利用分布式的数据架构替换传统的数据仓库，将ETL的过程更换成ELT的过程，结合批流一体的架构，保证数据的全面覆盖，源数据抽取，实时数据和历史数据并存。在这个基础上，数据中台借助机器学习等算法能力，构建精准营销模型，能够供前台业务应用直接调用，而不需要做成报表以可视化的形式提供给业务人员，业务人员根据自己的经验在去做手工的用户运营。

这是一个典型的数据智能化的过程，通过数据中台，整合了企业所有应用系统的全域数据，通过分布式存储和计算能力，结合人工智能技术和算法，为业务系统提供直接可调用的实时数据和智能服务。 业务中台业务用例：订单中心

智能化是所有的企业希望达到的目标，但是智能化对于数据的质量要求很高，而多个分别创建订单服务，导致的问题很明显，而且随着前台应用系统的不断增多，业务数据化的过程越来越复杂，导致数据与真实的业务出现了很多的不一致和偏差。同时，随着业务变化的速度越来越快，同时维护多个订单服务的工作量很大，响应速度越来越慢，这种情况，就要求对于所有的订单服务进行抽象，复用和包装，这就是业务中台出现的原因。

如下图是最简单的业务中台的服务，也就是订单中心的服务，所有的前台应用当需要创建订单的时候，统一调用业务中台的订单服务，由这个服务统一生成产品订单，从而保证了订单逻辑的一致性和维护的高响应性。