#凯哥讲数据中台[010]#一个订单服务的演进过程剖析双中台之一

最近很多同学都在微信留言询问数据中台和业务中台的区别，希望能够深入浅出，很容易理解的解释什么情况下需要业务中台，什么情况下需要数据中台以及双中台的关系。

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

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

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

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

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

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

这样带来的问题很明显：

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

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