本文的目的是讨论数据中间平台架构的一般设计方法，输出是数据中间平台的逻辑架构。当然，考虑到业内对数据中台的不同定义，可以预见，大家可能并不认同本文所设想的中台结构，但我认为每一步的推演过程都可能会给大家带来一些启发，或者最终会写出来，大家应该会认为自己在疫情期间做了一次心理体操。
00-1010首先，我们面临的问题域是整个数据系统，是指传统上由数据仓库和数据集市构成的生态环境，不包括线上交易系统(如核心系统、财富管理和销售系统)和纯流程管理系统(如业务审批系统)。
随着技术的发展，该系统增加了大数据和人工智能的元素，使其更加智能。但仍侧重于战略和战术层面的数据能力供给，可以作为业务变革的权威依据和决定性因素，但并不直接改变业务状态。
对于第一次分解，可以先把技术平台和“剩下的”按照有没有业务属性来拆解。这样，从整体架构来看，无论后续分解成多少个系统“其他部分”，这些系统与技术平台的关系都是一致的，即技术平台提供与业务无关的支持能力，包括数据存储和处理，甚至覆盖可视化层面，前提是这种技术能力是平台化所必需的。
在第二次分解中，我们将前台和中间的桌子与其余的分开。支持这种分拆的理由自然是“小前台、大中台”，这也是中台建筑热潮的口号。前台注重灵活性，中台注重稳定性，形成类似“变速档”的关系。
如何理解灵活性和稳定性？我认为一个重要的标准是系统生产的频率。面对需求的变化，前台和中台的生产频率至少要达到2: 1，才能体现出中台的稳定性。另一方面，如果中间站的每次需求变化都受到影响，那么中间站就不成功。
面对数据体系，通过界定中台边界，我们形成了前台、中间平台、技术平台的格局，如下图所示。
第一步：明确中台边界
目前我们描述的边界还是概念性的，比较宽泛，会导致很多理解上的差异。详细的接口可以帮助我们更深入地描述中间站的期望，从而在组织内部达成一致，所以我们将在第二步做这项工作。技术平台和中台之间有各种各样的接口，但是因为和业务无关，不容易模棱两可，所以我们重点关注前台和中台之间的接口。传统上，数据系统的系统接口主要是批处理文件的形式。前台和中台是否应该延续这个界面？在我看来，应该最大程度上避免使用批处理文件作为接口，多使用API服务。具体原因如下。
在
第二步：细化中台外部接口
工程实践中，批处理文件的数据和元数据经常被分离，甚至元数据被简单省略。具体来说，批处理文件通常是一个只包含数据的平面文件，在界面中很少看到源系统中的数据项标识、名称、数据类型和备注(可能存在于数据库中)。当然，如果我们做得更好，也可以在数据治理系统中注册这个接口，但问题是治理系统中“元数据”的正确性与系统的运行无关。它们从未真正得到验证，我们无法确定它们是否会随着业务变化而立即更新。当我们需要基于这些“元数据”做出决策时，我们往往缺乏信心。随着时间的推移，治理系统中的“元数据”不再被使用，变成了死数据。
相对来说，服务的自我描述要好得多，我们甚至可以在组织内部就更丰富的元数据达成一致，并将其与服务发布相集成。基于架构设计的服务注册和发现机制，这些服务将受到更强的约束，
批量文件的自解释性差、可治理性差
我们在系统建设中经常可以观察到一个现象，就是系统会自我驱动，业务会越来越复杂、发散。原因大概是系统的主要利益相关者更倾向于拓展系统内的功能，可以降低与外部(技术、业务等)的协调成本。).从局部来看，尤其是特定的需求，这可能是更快更好的选择，但从整体来看是一种伤害。哲学上，问题是局部最优解不一定是全局最优解。追求局部最优解的后果是建立大量的竖井系统，无法沉淀可重用能力。中国和台湾的使命，恰恰是从整体上打破或削弱这种建设模式。
尽量不要在前台积累数据，这会阻止或控制其逻辑向复杂、发散演变的可能性。我们可以在更高的管理水平和更低的成本下洞察这种进化趋势，然后采取相应的措施。
服务模式自然满足了控制前台系统数据积累的目标。
00-1010数据仓库的方法论是秉承“以空间换时间”的思想，通过ETL(SQL处理)预处理降低用户查询报表时的计算负荷，从而实现低延迟交互。为了整体提高整体处理效率，不会依次处理单个报表，而是合并报表的处理级别，逐步提升共性，一个批次可能有2-3个批次处理批次(通常不会)。
太多）的加工结果大致会在同一个时间段完成。这种方式的弊端是，一旦上游数据或基础层加工出错，发现错误的时点会大幅延后。原本通过单进程查询就可以发现的错误，现在必须预支大量的批量计算成本后才能看到。这个过程浪费了大量的计算资源和时间资源（ETL 必须在当日完成，因此时间资源也是受限的），甚至导致无法在剩余的时间窗口内完成纠错和任务重跑，造成业务的重大影响。
我们应该看到“以空间换时间”的策略是基于若干年前的即时计算能力而做的权衡。今天，分布式技术发展带来了即时计算能力的大幅提升，是时候在 ETL 处理和即时计算之间寻找更优的平衡点了。
我的建议是将一些计算负载迁移到服务中来，用分布式计算框架代替部分 ETL。中台与前台的接口处位于整体 ETL 的末端，所以这里也就更适合采用服务接口。
此外，还要说说第三种接口方式 JDBC，我个人也是不推荐的。一个原因是 JDBC 暴露了数据源的数据存储结构，强化了前台与中台的耦合，既然我们在架构层面希望两者松耦合，那具体接口上也应该选择匹配的技术。第二个原因是业务语义上的差异，RESTFUL 服务有一个“有趣（Interesting）”原则，服务要有业务语义。直接对一张表的访问显然不够“有趣”，那么 JDBC 也就不能称为服务了。
数据中台的外部接口主要是 API 服务。
第三步：梳理中台内部结构
我们继续探讨数据中台的内部结构，按照我们在第一步设定的边界，“数据仓库”与“数据湖”必然是中台的一部分。两者是不是中台的全部呢？我认为并不是全部。
数据中台不只是数据仓库
数据仓库方法论有 Inmon 和 Kimball 两个流派，国内数据仓库的实施多数采用 Inmon 的方法。
具体来说，在数据仓库与数据集市的二元结构中，数据仓库对接上游各类业务系统，按照企业级模型重组数据以消除源系统的特异性，这个模型按照若干主题进行组织，是数据仓库理论体系的核心；数据集市在此基础上，根据具体的应用场景进一步加工数据，实现最终的功能交付。
可以看出两者的指导思想不同，数据仓库是“面向主题”的，数据集市是“面向应用”的。
有些企业以前是竖井式的数据集市，现在把集市中的共性部分下沉，节省了加工成本，认为这就是数据中台。如果笼统得用“能力复用”作为标准，似乎数据仓库与数据集市就是中台和前台了。
那么数据中台是在炒概念吗？我认为并不是。
数据中台与数据仓库的差别不是有没有能力复用，而是因为数据集市仍然太重不符合前台的灵活性要求。同样是二元结构，因为数据集市不等于前台，所以数据仓库也就不等于中台。
前台碎片化
理论上数据集市是满足一个“业务单元”的数据分析需求，实践中这个“业务单元”往往对应到“业务部门”，因为这样业务管控职责明确，能够快速需求边界，和财务管理制度也有直接的关系，项目操作较简便。
但是，今天这种方式遇到了挑战。随着数据应用的深入，需求越来越具体，同一部门的不同团队的需求也各有侧重，都希望保证各自的灵活性，又不希望自身的稳定性受到其他团队灵活性的影响，“业务单元”呈现明显的“碎片化”。
跟随着业务的“碎片化”，数据集市不断裂变，底层逻辑大量重复。显然，该做架构层面的调整了。这就说到前台，其服务的“业务单元”更小，但逻辑相比数据集市要更加轻薄，将原有针对“业务部门”的加工要沉淀到数据中台，沉淀的部分也有再次重组的机会。
数据中台既“面向主题”也“面向应用”
数据中台“面向主题”是因为包含了数据仓库，“面向应用”则是因为包含了数据集市下沉部分。这里的新问题是如何重组数据集市下沉到中台的部分，重组方式依赖设计者的经验，其实没有统一方法。我的建议是按“价值链”和“产品线”两个维度分解，两者正交构成若干单元，这些单元称为“业务域”。
同样是数据沉淀，为什么不使用数据仓库的主题，而要新建“业务域”呢？数据仓库的主题是数据层面的高度抽象，基本不体现业务流程。今天，数据应用的大趋势是强化对“一线操作”数据赋能，必然更加关注业务流程，而价值链正是业务流程的起点；产品则是衔接企业与用户的桥梁，同时也是业务操作的核心。
“业务域”是对业务流程的抽象，可以说是“面向流程的”，本质还是“面向应用”的。“业务域”数据模型不像数据仓库“主题”那样严格的去冗余，有些维度信息会重复出现，比如客户基本信息、机构信息等。
以银行为例，“价值链”上的典型环节包括营销、运营、风控等，“产品线”可以分为零售、对公、同业等，两者正交则可以得到“零售营销”、“对公营销”、“零售风控”等业务域，当然正交得出的业务域也可以适当调整。
数据中台包含一个“面向主题”的数据仓库（及数据湖）和若干个“面向应用”的业务域。
第四步：针对非功能性需求的设计
目前为止，我们仅在数据结构上讨论了中台的构成，并没有考虑系统的非功能性需求。事实上，在不同应用场景下前台的非功能性需求会有较大的差异，其中最有代表性的是对并发和延时的要求。因为我们已经约定中台与前台的接口是 API 服务，这些需求会直接传导到中台。接下来，让我们谈谈中台的针对性设计。
第二步中，我给大家的建议是减少“数据搬家”和 ETL，因为这会导致削弱系统的鲁棒性，对于中台的内部设计我也坚持同样的观点。数据应该通过最短的加工路径，形成 API 服务向前台交付，所以数据仓库和业务域都应该具备 API 服务能力。
数据仓库原本以批量加工为主，以文件方式输出，兼顾 API 服务绝对是个大挑战。设计一个在行业内广泛适应的主题模型，在我看来其实是有点玄学的成分，但既然有超多企业的实践，我们还是先要认同它，但谈到改造这个模型，还真是无从下手。
在找到兼顾的方法前，我更愿意让它保留原来的样子，这样可以沿用成熟实施方法，毕竟目前在数据仓库上继续付出努力还会获得不错的收益。我们可以让数据仓库在现有的结构上提供一些兼职的 API 服务，适合那些延时要求不高的应用场景（比如一些报表查询），一旦不能满足就在更上层的区域重建这些服务。
业务域的数据结构是“面向应用”的，也就有更好的基础提供 API 服务能力。普通查询场景，可以选择兼顾批量处理性能和联机查询性能的存储产品，比如 MPP 数据库或者 HTAP 数据库。
高可靠低延时场景（比如反欺诈、反洗钱，数据查询结果是会阻断异常转账的依据，对延时有极高的要求），可能是两种存储产品的组合，分别提供批量处理和联机访问能力。联机查询可以选择是 K/V 数据库（比如 HBase）或者分布式数据库（NewSQL）或者分库分表方案（MyCat 或者更好的方案），总之是更接近 OLTP 的存储系统。存储产品的组合一定会带来数据冗余，这种冗余虽然也需要数据搬家，但不会带来业务逻辑层面的重叠，没有背离我们的设计理念。
业务域的服务和中台最终交付的服务是存在差异的，这种差异是为了保护业务域的稳定性。无论我们按什么标准划分业务域，也总会有应用场景需要多个业务域参与。所以，在业务域之上还要增加一层，我将其成为“服务联邦层”。
通过“服务联邦层”，我们可以完成服务间的拼接，避免数据复制导致业务域边界的模糊，这种拼接是数据语义上的关联。此外还会对单个服务再加工，隔离应用的特异性和存储数据结构的通用性，这意味着过滤、聚合甚至嵌套子查询。数据语义的加入使“服务联邦层”比标准的服务总线更复杂了一些，更像 Presto 这样的数据联邦产品，但接口是 API 服务而不是 SQL。
最后还会存在一些特殊情况，跨业务域但通过服务拼接无法性能要求，必须通过批量加工完成，我们要专门建立一个区域隔离这种跨域数据加工，称为“数据隔离区”。这里可以汇聚多个业务域的数据，但仅向上层的“数据联邦层”输出。业务域与“数据隔离区”保持单向数据流动，维护业务域的稳定性。
这样，我们得到一个完整的逻辑架构图。
结语
整个架构设计过程中应用了一些基本原则，也是我个人对数据中台的理解，包括以下几点：
中台一定是有业务属性的，中台要比前台更稳定；尽量减少 ETL 加工，引入分布式技术进行即时运算，提升系统的鲁棒性；API 服务接口优于文件和 JDBC 接口。中台内部多层次提供 API 服务，通过服务集成的方式减少跨域的数据集成。一家之言，希望和大家多多交流切磋。
作者介绍
jqdqc，光大银行企业架构师，Pharos 架构设计和主要开发者，曾任职于 IBM 全球咨询服务部从事技术咨询工作。目前负责全行数据领域系统的关键架构设计、评审及内部研发等工作，对分布式数据库、Hadoop 等基础架构研究有浓厚兴趣。个人公众号：金融数士