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

傅一平评语：

讲中台理论和方法的文章很多了，但能以案例形式讲出来的不多，这篇文章挺接地气，以一个订单案例的形式说明了数据中台和业务中台的核心价值。

1、业务中台解决业务数据化问题，包括一致性、响应力、维护性和性能等问题

2、数据中台解决数据智能化问题，包括分布式数据架构、服务化、实时化及全域数据的一致性等问题

复杂的概念简单化，挺不容易，举案例是很好的方式，但有多少人在讲概念的时候，实际是举不出案例的，这叫知行不合一吧。

01.前言

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

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

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

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

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

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

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

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

这样带来的问题很明显：

1. 用户体验不佳，一个用户不能看到在不同渠道的订单。

2. 数据一致性差，订单数据分散在不同的应用系统中，数据不一致，同步复杂。

3. 维护困难，当一个订单逻辑发生了变化，所有的应用逻辑都要重写，带来的很大的维护工作量，响应慢。

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

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

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

1. 数据分析不实时，不能够实时出报表。

2. 数据仓库往往都是单体架构，受限于数据的处理计算能力，扩展能力不强，往往只能分析一个阶段的数据。

3. 响应慢，ETL的过程依赖于预设的分析主题设计，当要分析的数据结构发生变化时需要重新设计抽取逻辑，导致响应慢。

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

数据中台业务用例：精准营销

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

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

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

业务中台业务用例：订单中心

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

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

双中台共存业务用例：动态价格

数据中台不仅为前台应用直接提供调用服务，并且也能够为业务中台提供服务。下图是典型的双中台共存的业务用例：动态价格。

这个场景在很多需要实时计算动态价格的业务中存在，比如机票预订和滴滴打车的下单服务中。

业务中台统一为不同的应用提供订单生成服务，而在生成订单的过程中，需要根据不同用户的情况，动态计算一个价格，这种情况下，业务中台就需要调用数据中台中的动态价格计算模型。

所以，数据中台是同时为业务中台和业务前台提供数据和智能服务的。

业务中台和数据中台的关系

通过上面一个典型的订单服务的几个泛化场景的演进过程，我们粗浅的分析了业务中台和数据中台应用的典型业务用例，我们可以简单的总结为：

业务中台解决的是业务数据化的问题，数据中台解决的是数据智能化的问题。

03. 业务中台解决业务数据化的问题

目前大部分的企业系统都是业务数据化的系统，所有的OLTP应用也都是为了实现业务数据化的目的，而业务中台解决的是业务数据化过程中的如下问题：

• 一致性问题，将处理逻辑相似的业务流程封装成业务中台的服务，从而保证业务的一致性，也保证了业务数据化后的数据一致性问题

• 响应力问题，通过对业务中台服务的复用，提高业务前台系统开发的效率从而提高响应力

• 维护性问题，将多个服务抽象成一个，提升系统的可维护性

• 性能问题，通过微服务，容器化技术，能够针对性的解决高并发的服务需求问题，实现硬件资源的共享，解决性能问题

总的来讲，业务中台是为了业务更高效，更准确，更弹性的数据化。

更简单的说，业务中台解决的是生产数据过程中的问题。

4. 数据中台解决数据智能化的问题

数据中台是为了让所有的业务流程都能够尽可能的利用数据产生的洞察，促进流程的优化，让业务更加智慧。所以，数据中台解决的是数据智能化的问题：

• 通过分布式数据架构，解决传统单体架构数据系统比如数据仓库、中心式数据湖的问题

• 通过数据模型/报表服务化方式，实时被业务应用所调用，提升业务的实时性

• 通过融合企业全域数据，提升数据的一致性和准确性

05.总结

    业务中台是为了让企业更好的响应业务同时生产数据，业务更加弹性。

    数据中台是构建弹性的数据基础设施，为了让企业更好地利用数据，让业务更智慧。

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！