最常见的方式就是，数据链路也左向右发展，有加工平台负责加工，结果数据导出到服务平台对外提供服务。这个架构在最开始应用的时候还是比较顺利的，大部分公司里面 90%的场景下是这个架构。但是 随着业务越来越多，越来越复杂，每天都有新的报表，每天都有新的业务场景，就会发现每 一个业务调整的时候，都要从源头一步步调整，包括表结构，加工脚本，历史数据重刷等等， 最后造成整个数据加工的链路会变得数据冗余、成本高、开发周期长、甚至数据不一致。于 是我们就需要开始思考这个架构还能不能再有优化的空间，甚至是再简化一些。要解决上述问题，可以看到市面上的选项大致分为 3 个系统，以及它们之间的综合。 第一个是直接用事务系统做分析，Transaction 类型，支持随机读写、事务、可靠， 主要面向 DBA。 第二个系统是专业的分析系统，Analytics，适合大规模数据扫描、过滤、汇总，面向 分析师。第三个系统是在线服务的系统，Serving，支持高并发、简单、快速，面向 API。 三个系统各有擅长，最终落地解决问题的时候，往往多个系统一起使用，数据在系统间 频繁交换，也引起了刚刚提到的各种冗余、复杂、不一致的问题。 我们首先想到的是，能否一个系统支持尽量多的场景，简化运维，少一些数据移动。首先出现的是红线和蓝线交界部分，让一个系统既可以支持分析，又可以支持事务，也 就是我们常说的 HTAP，它有一定的适用场景： 数据来源于业务系统（TP）。 需要机制保证 TP 和 AP 的一致性（数据、 模型，大量同步）。  模型简单，用于简单分析场景。 局限是，事务系统的数据模型是无法直接用于分析场景的，数据需要被加工、抽象才能 用于数据分析师。 在另一侧，蓝色和黄色交界的部分也有一个场景，分析和服务也可以做成一个系统，也 有它的适用场景： 统一实时、离线存储引擎。  没有事务需求，减少针对事务场景的开销（锁、同步）。  埋点数据、机器数据，比 TP 高数量级。 为多场景设计可复用数仓。