在数字化转型的浪潮中，企业对数据处理的需求日益复杂多变，传统的批处理和流处理架构已难以满足日益增长的性能和时效性要求。在此背景下，YMatrix CEO 姚延栋发布了深度文章《数仓架构告别「补丁」时代！全新批流一体 Domino 架构终结“批流缝合”》应运而生，为我们揭示了数据处理领域的未来趋势。

接下来，就让我们一同走进这篇文章，共同探索 YMatrix Domino 架构如何引领数据处理领域的新变革。

---

前言

数字洪流冲击下，企业实时数据需求已突破传统架构的承载极限。当'批流缝合'架构深陷性能与时效的泥潭，Domino 以颠覆性设计直击本质：打破批流割裂的底层逻辑，重构数据价值流动范式。这不仅是技术革新，更是认知跃迁——数据世界正以'批流一体'为核心进行板块级重构。

诚邀你体验 YMatrix Domino 架构的变革力量：限时开放全功能企业版，开发者可零门槛接入真实业务场景压力测试。‌告别为架构冗余支付的性能'税款'，突破线性时钟的决策延迟，让数据引擎真正驱动业务创新。

“批流一体”技术缘起

在大数据技术领域，计算框架有两大流派：批处理（Batch Processing）和 流处理（Stream Processing）。两个框架各有优势，各有其适应的场景：

流处理引擎经历了从 Storm 到 Spark Streaming 再到 Flink 的三代技术迭代，大数据处理也随之经历了从 Lambda 架构到 Kappa 架构的演进。

1. 流处理技术的演进 Google Dataflow - Spark - Flink

Google Dataflow

2015年，Google Dataflow 为统一批处理和流处理提出了一个全新的编程模型，目标是让开发者只需编写一套代码，就能既处理历史数据，又能处理实时数据。然而，实际上 Dataflow 的底层仍然依赖于 FlumeJava 和 MillWheel 这类组件的拼接，这种方式虽然在概念上打破了批与流的壁垒，但在实现上仍然存在不少妥协：

• 数据处理管道中，离线数据和实时数据的调度、状态管理、容错机制等部分未能做到完美统一，导致一致性和延迟之间需要进行权衡。
• Dataflow 依赖窗口（Windowing）和水印（Watermark）机制来处理乱序和延迟数据。这些机制虽然保证了事件时间语义和正确性，但它们的参数（例如窗口大小、延迟容忍度等）需要精细调优。对于不同的业务场景，找到合适的调优参数可能非常复杂，不当配置可能导致部分数据丢失或结果不准确。

Apache Spark Structured Streaming：微批模式的局限

Spark Structured Streaming 提出了微批处理（micro-batch）的方式来近似实现实时处理，但本质上仍然是将实时流数据分割成一系列小批次进行处理：

• 实时性与延迟问题，由于微批模式的固有特性，每个微批的处理都会产生固定的延迟。Spark 在低延迟实时计算的表现仍与真正的流处理计算有差距。
• 状态管理和容错机制，Spark Structured Streaming 通过 checkpoint 和状态持久化来实现容错，但对于非常大规模和复杂的状态管理场景，这种方式可能会带来较高的资源消耗和管理复杂性。特别是在需要精确一次处理语义的场景中，状态恢复和维护可能会成为瓶颈。

Apache Flink：流计算优先的批流一体

Flink 作为以流处理为主的系统，在架构上将批处理看作有界流，从而实现了统一的 API 和执行引擎。Flink将批处理视为特殊流处理的方法在理论上实现了批流一体，但是损失了一些批处理场景的性能，并且实际上的使用门槛更高。

• 对纯批处理场景的优化不足，虽然统一模型大大简化了开发，但在纯批处理场景下，其性能差强人意。尤其在某些数据量极大或计算密集型的离线任务中，Flink 可能会有额外的调度和状态管理开销，从而影响整体性能。
• 统一 API 的复杂性，虽然 Flink 实现了统一的 API 和执行引擎，但对于开发者来说，使用统一 API 进行不同模式下的优化往往需要理解较多底层概念（如事件时间、水印、窗口机制等）。这增加了学习曲线，也使得在批处理任务中，调优变得相对复杂。

总结：十多年来的探索与现状

从 Lambda 架构到 Dataflow，再到 Flink 和 Spark Structured Streaming，业内不断尝试统一批处理和流处理。尽管各家方案都有其亮点，但至今尚未有一种彻底、简洁且优雅的解决方案能够同时满足低延迟、高一致性和高容错的要求。这导致当前市场上，企业在同时需要批和流功能时，往往仍然采用类似 Lambda 架构的拼接方案，从而增加了系统的复杂性、开发维护成本以及数据不一致困扰。笔者遇到的大量客户中，大多数批流一体方案是采用 Lambda 架构： Spark/Hive/MPP 数据库等实现离线分析，而使用 Flink 等实现实时计算。

2. Lambda-Kappa

Lambda 架构

理解 Lambda 架构，可以从两个名词入手——批处理、流处理。

Lambda 架构由三层组成，具体如下：

1. 批处理层（Batch Layer）：负责存储和管理完整的历史数据集（不可变的数据集），并通过分布式处理系统（如 Hive）对数据进行批量处理，生成预计算视图。

2. 速度层（Speed Layer）：实时处理新到达的数据，提供低延迟的更新，以弥补批处理层在处理最新数据时的延迟。

3. 服务层（Serving Layer）：将批处理层和速度层的结果进行合并，提供统一的查询接口，响应用户的查询请求。

Lambda架构的优缺点

当以 Storm 为代表的第一代流处理引擎成熟后，一些互联网公司为了兼顾数据的实时性和准确性，采用Lambda架构来处理数据并提供在线服务。

Lambda架构在实时性和准确性之间做了一个平衡，能够解决很多大数据处理的问题，曾大量部署在各大互联网公司。它的好处有：

• 批处理的准确度较高，可以反复对同批数据进行实验。另外，批处理的容错性和扩展性较强。
• 流处理的实时性较高，可以提供一个近似准确的结果。

Lambda 架构的缺点也比较明显：

• 使用两套大数据处理引擎，如果两套大数据处理引擎的 API 不同，有任何逻辑上的改动，需要在两边同步更新，维护成本高，后期的迭代时间周期长。
• 早期流处理层的结果只是近似准确。
• 组件太多：Lambda 架构是非常庞大的，会使用到大量的组件来建设Lambda。例如：Hadoop、Hive、Cassandra、Oozie等）。而针对不同类型的组件去开发，非常麻烦。运维难度也很大。

Kappa 架构

Kafka 的创始人 Jay Kreps 认为在很多场景下，维护一套 Lambda 架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的 Kappa 架构。

以流为核心来建设数据系统。并且，通过重放历史数据来实现数据重跑。

架构特点：

• 去除批处理层：Kappa 架构删除了 Lambda 架构中的批处理层，仅保留速度层（Speed Layer），通过流处理系统处理所有数据。
• 统一处理逻辑：采用统一的流处理引擎，使实时处理和历史数据处理使用相同的代码路径，减少了系统复杂性。
• 数据重放能力：利用消息队列（如Apache Kafka）保存数据日志，支持对历史数据的重放，以应对业务逻辑更新或错误修正的需求。

Kappa架构相对更简单，实时性更好，所需的计算资源远小于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构。

Kappa 架构的问题

根据上述内容，似乎 Kappa 是一个简单，易维护的选择。但为什么很多企业仍旧选择 Lambda 架构呢？Kappa 架构在实际应用中，仍然存在很多问题。

历史数据计算复杂度高，性能慢

Kappa 架构只需要维护实时处理模块，但是强依赖消息中间件的缓存能力，历史数据计算复杂度高，性能慢。Kappa 在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠、性能更高的特点。

数据乱序问题

数据乱序问题在流处理中确实常见，尤其是在分布式系统中，数据可能因为网络延迟、分区处理速度不同等原因导致顺序错乱。比如，一个事件A在时间上发生在事件 B 之前，但由于某种原因，事件 B 先到达处理系统，这时候系统如果按到达顺序处理，就会导致错误的结果，比如窗口计算的错误。

3. YMatrix Domino 内核级创新实现“批流真一体”

无论是 Lambda 架构还是 Kappa 架构，抑或是十年来业界对于流计算技术的探索，在实现“批流一体”的进程中，总是存在多种技术或组件的拼接。开发者在使用上述结构时，往往需要具备多个组件的知识，运维也需要同时维护两套以上的系统。

就像外卖平台高峰期既要接实时订单（流处理），又要统计历史补贴数据（批处理），传统架构如同让骑手同时送外卖和搬仓库，必然导致调度混乱、资源浪费。Domino 的创新相当于为数据处理打造了『智能交通中枢』，让实时订单走专用通道，历史数据走重载卡车，路口却由同一套信号系统协调。

Domino 架构通过数据库内核级的融合，实现了批流一体的真正突破，重新定义了批流一体的数据处理范式。其核心目标是通过统一 everything 的设计与存储计算融合，彻底消除传统流批架构的割裂，降低技术复杂性，同时以 SQL 为核心实现“零代码批流一体开发”。

3.1 统一数据模型：流即是表，表即是流（stream is table，table is stream）

在概念模型上，Domino 架构打破了传统将流与表割裂的思维，将流数据和静态表视为同一数据实体的不同表现形式。换句话说，所有流式更新可以看作是对表的连续修改，而有界批数据则是这一更新流在特定时间点的“快照”。

想象你眼前有杯永续续水的茶杯：

• 流数据是杯口持续注入的水流

• 批数据是某一秒按下暂停键的水位截图

Domino 的创新，就是让茶杯自己记住每一刻的水流轨迹，需要时随时提取任意时刻的快照。这个魔法道具，就是其独创的'流表（Stream Table）'。

流表可以认为是一种特殊的表（类似物化视图），但是具有流的特质，支持实时增量计算。用户可以使用 DDL 和 DML 对流表进行操作。

下面是一个简单的流表（dwd_order_detail) 的示意，实现了一个基础的扩维操作。

CREATE STREAM dwd_order_detail(id, ts, prod_id, prod_name, prod_detail)AS (    SELECT       ods_order.id,       ods_order.ts,       ods_order.prod_id,       dim_prod.prod_name,       dim_prod.prod_detail    FROM STREAMING ALL ods_order    INNERJOIN dim_prod        ON dim_prod.id = ods_order.prod_id ) PRIMARY KEY (id);

对于我们例子中创建的流表 - dwd_order_detail， 一方面具备一般表的批的能力 - 它可以像一般的表一样执行各类查询，同时更重要的是它具备了流的能力 - 无论他的上游ods_order发生了 INSERT, UPDATE 还是 DELETE,dwd_order_detail都会得到实时的更新。

流表是 Domino 批流统一的基石，使得统一批流数据摄取、统一批流计算模型、统一批流存储模型、统一批流编程接口成为可能。

3.2 统一批流数据摄取（Ingestion）

Domino 为批处理和流处理提供统一的标准的数据摄取机制，通过标准 SQL 实现流表数据的增删改，和普通表一般无二，而无需为批流提供不一样的摄取接口。数据摄取的统一消除了因数据格式、数据接口不统一而导致的冗余数据处理，并且降低了学习门槛。此外非常重要的一点是，统一批流，并用表作为统一的底层数据模型，使得对流表的修改和删除变得非常简单。

3.3 统一批流计算模型

在 Domino 架构中，批处理和流处理共用同一套基于 Pipeline 的计算引擎和执行模型。用户创建流表时，Domino 自动为流表创建执行计划；当流表的数据源发生变化时，执行计划自动执行，并计算结果更新流表。这套机制和批处理共用相同的机制，也是数据库领域几十年沉淀的标准 vocano 执行模型。统一的计算模型，使得开发者不需关心内部实现细节，而仅需使用统一的 SQL编写逻辑，零代码实现批流一体。

3.4 统一批流存储模型

由于 Domino 使用和表相同的概念模型表达流表，所以可以使用相同的存储引擎存储批数据（表）和流数据（流表），并保证数据的持久性和事务一致性（ACID）。这种存储模型的统一使得 Domino 流计算实现可以有几乎无限容量存储数据，而无需担忧内存容量不足或者窗口过小的问题（实际上，在 Domino 架构没有流计算传统意义的窗口和水印，因为有几乎无限的存储空间）。这种存算融合的方式降低了数据在存储层与计算层之间转换的开销，从而提高了处理效率。同时内核级的事务支持确保批流处理结果始终保持一致，不再因数据分离而产生不一致风险。

3.5 统一批流编程语言 —— SQL as Streaming Processing Language

Domino 架构基于标准 SQL 扩展出流处理能力，使 SQL 不仅用于传统的查询和数据操作，也能描述实时流数据的变换和聚合。SQL 作为一种声明式语言，其优势在于易学易用，开发者只需掌握 SQL 就能完成复杂的数据处理任务。Domino让使用者只使用SQL语句就能实现批流统一的数据查询与分析，降低了技术门槛。比如'SELECT * FROM 订单流 WHERE 补贴金额 >50'——这条看似普通的SQL，在Domino里既是实时风控，又是离线分析。就像用筷子既能夹菜又能搅拌咖啡，彻底告别Java/Scala/Python的多语言精分现场。

3.6 完善生态，实现多样化数据标准方式接入，而无问批流

Domino 架构支持多种数据接入方式，具有完善的上下游生态，包括 FineDataLink、DSG、Datapipeline、Seatunnel、BluePipe、用友 IUAP、EMQ、Talend 等。Domino 能够作为万能连接器即插即用，无论数据来自 IoT、企业系统、日志系统还是外部 API，Domino 均能统一接入并标准化处理。

3.7 消弭对窗口和水印依赖 —— 降低流计算复杂性

传统流计算引擎在处理无界数据时，通常依赖复杂的窗口和水印机制来保证事件时间的正确性，而这往往增加了系统设计和调试的难度。Domino 架构通过内核级的事务、统一的存储模型、统一的计算模型，消除了对传统窗口技术和水印机制的依赖，使得流计算实现逻辑更加简洁优雅，而无需复杂难懂的各类概念。开发者无需再为窗口边界、数据乱序等问题编写额外逻辑，从而降低了编程复杂度。数据一致性和实时性由内核直接保障，用户只需关注业务逻辑，不必深入底层细节。

通过以上内核级的创新，Domino 架构实现了批流一体的统一性和一致性，形成了“统一 everything”的设计理念——统一流和表、统一数据摄取、统一计算模型、统一存储模型、统一查询语言以及统一事务管理。这样的架构不仅大幅降低了技术架构的复杂度，更使得懂 SQL 的开发者可以轻松驾驭复杂的批流处理任务，从而推动企业数据平台向更高效、更易用的方向发展。

这种创新为企业在实时与离线数据处理间建立了一座桥梁，既满足了业务对高实时性数据的需求，也保证了数据处理的准确性和一致性，是下一代数据处理平台的重要发展方向。

Domino 相比 Flink / Spark 的关键优势：

Domino 是目前唯一真正实现数据库级别批流一体的架构！

现在，Domino 开启免费试用！

Domino 通过统一存储引擎、火山模型优化器、流表抽象层等 18 项核心专利，实现数据库内核级批流融合，开发效率提升 10 倍以上，十亿级数据量实现秒级延迟。这场数据库内核级的范式革命，正在重新定义数据处理的游戏规则。当批流界限如冰融化，或许我们会突然发现：原来数据处理本应如水般无形，又似山岳般可靠。

承载完全版 Domino 的 YMatrix6.0 版本已于 2025 年初正式上线，从现在起正式开放免费咨询与企业试用。（点击“YMatrix”跳转）

批流一体十年迷局，许多尝试折戟沉沙。但答案在未来，长远来看，批流一体绝不是选择题，而是必答题！