01.前言
最近很多同学都在微信留言询问数据中台和业务中台的区别，希望能够深入浅出，很容易理解的解释什么情况下需要业务中台，什么情况下需要数据中台以及双中台的关系。
我前面做了很多行业研究和案例分享，但是都是企业级的讲解，感觉都不够简单，不够落地，这里我用一个最清晰的订单服务的演进过程，来深度剖析双中台的关系。

02. 一个订单服务的演进过程

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

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

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

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

该电商企业拓展了多个渠道，构建了另外的电商APP，提供给用户使用。于是，用户下订单就有了两个方法，分别在不同的应用里，比如自营APP和微信小程序，这是最典型的两个渠道。而真实的情况是一个电商企业会有非常多的渠道，有自营的，还有代运营的，还有线下的POS系统，还有合作伙伴通过API接入的，多个应用会同时创建订单。
这样带来的问题很明显：
  1. 用户体验不佳，一个用户不能看到在不同渠道的订单。
  2. 数据一致性差，订单数据分散在不同的应用系统中，数据不一致，同步复杂。
  3. 维护困难，当一个订单逻辑发生了变化，所有的应用逻辑都要重写，带来的很大的维护工作量，响应慢。
在这种情况下，为了能够掌握全局的销量情况，往往企业会构建数据仓库系统，将不同系统的数据都通过ETL的方式抽取到数据仓库中进行分析，这也就是OLAP的过程，但是由于数据量比较大，处理过程复杂，往往OLAP都是T+1以上的响应速度，也就意味着，比如企业要想看所有渠道的销量分析报表，只能看到一天以前的，而不能看实时的数据，如下图所示。
上图的橘黄色箭头表示在线交易处理流程，是生成数据的过程，而绿色箭头表示在线分析处理流程，是抽取处理分析的过程。
这是典型的数据仓库和商业智能的场景，而这样的数据利用的问题也是很明显的：
  1. 数据分析不实时，不能够实时出报表。
  2. 数据仓库往往都是单体架构，受限于数据的处理计算能力，扩展能力不强，往往只能分析一个阶段的数据。
  3. 响应慢，ETL的过程依赖于预设的分析主题设计，当要分析的数据结构发生变化时需要重新设计抽取逻辑，导致响应慢。
以上是现在很多企业典型的应用和数据架构，在这个基础之上，有了数据中台和业务中台的产生。
继续阅读
阅读原文