通用增量计算：架构、原理与最佳实践介绍

返回博客

通用增量计算：架构、原理与最佳实践介绍

数据见闻

2025年11月14日

聚焦 AI 时代数据架构挑战，解析通用增量计算原理、技术及小红书实践，实现架构统一与降本增效。

导读

本文探讨AI时代下数据架构的核心挑战与创新解决方案，提出以通用增量计算（GIC）为核心的新一代数据引擎技术，通过统一计算范式实现效率、实时性与性能的协同优化，并分享了小红书案例的落地实践展示通用增量计算带来的价值。

主要分为以下三部分：

AI时代的数据架构 ：回顾当前数据架构的挑战与行业探索现状。
通用增量计算原理及关键技术 ：深入剖析云器认为的下一代数据平台核心技术——通用增量计算（GIC）。
案例实践 ：通过与小红书的合作案例，体现通用增量计算在生产环境中的应用范式与价值。

AI时代的数据架构挑战与现状

首先，我们来探讨AI时代对数据架构提出的新要求。一个核心结论是，即便在AI时代到来之前，数据体系的架构也尚未完成收敛。

延续十年的“不可能三角”

数据处理领域一个长期存在且广为人知的挑战是“不可能三角”。这个三角的三个顶点分别代表了三种核心诉求：

效率 (Efficiency/Low Cost) ：以尽可能低的成本处理海量数据，典型代表是批处理（Batch Processing）系统。
新鲜度 (Freshness/Up-to-date Data) ：要求最高的数据实时性，典型代表是流计算（Streaming Processing）系统。
性能 (Performance/Fast Query) ：要求极速的查询响应，典型代表是各类OLAP或数据湖加速引擎。

在过去的十年里，为了同时满足这三种需求，业界主流的生产实践仍然是采用由多种系统拼接而成的Lambda架构。一个典型的Lambda架构通常包括一个处理全量数据的批处理层、一个处理实时数据的加速层（流处理），以及一个用于即席查询和报表的数据应用层。这种多路径、多组件的架构，不可避免地导致了数据在不同系统中被复制和存储，带来了数据冗余和一致性难题。

AI时代的新挑战

随着AI时代的到来，尤其是大模型技术的普及，对底层数据体系提出了更高、更严苛的要求：

1. 更高的数据一致性要求 ：AI系统，特别是大模型，在应用过程中非常关注准确率。如果数据在多个系统中存在三份冗余副本，人类尚且难以对齐口径，AI系统面对不一致的数据源，将很难判断真伪，从而影响其决策的准确性。

2. 更高的实时性要求 ：AI系统为了减少幻觉、提升准确度，会进行高频次的试错、反问和纠正。这种由机器驱动的高频交互，对数据系统的实时性和性能都构成了巨大挑战。

3. 更高的多模、性能要求 ：AI应用场景常常涉及结构化与非结构化（如文本、图片）数据的融合处理。将这些多模态数据统一存储在数据湖中，并高效地抽取为向量进行检索和分析，是AI时代的必选项。如何保证原始数据与其生成的向量之间的一致性，将是未来的一个重要问题。

因此，AI时代的到来，将加速数据架构的收敛进程。数据作为AI体系的基石，其架构的统一与简化是推动上层AI应用发展的关键基础。

业界三大路径的探索与局限

面对“不可能三角”的挑战，业界分别从三个顶点出发，进行了大量的工程优化探索，但各有其局限性。

1. 批处理系统：从离线到分析

核心特征 ：批处理系统的设计目标是吞吐率（Throughput）优先，采用主动计算模式，对静态数据进行全量计算。它不理解数据的变化，每次计算都是对锁定版本的一次性完整处理。
行业分化 ：我们观察到明显的两极分化。
- 头部厂商 如Snowflake和Databricks，已经拥有了各自成熟的增量计算实现，例如Snowflake的Dynamic Table和Databricks的Delta Live Table。这些技术已经超越了单纯的批处理范畴。
- 开源社区及多数厂商 则仍在“力大砖飞”的道路上，即通过提升引擎本身的执行性能来缩短批处理的周期，但并未改变全量计算的模型。例如，广泛采用Gluten + Velox等技术将Spark的计算下推到Native层执行，以获得性能增益。在数据体量不大的场景下，一个足够快的批处理引擎有时也能勉强承担分析需求。
局限：单纯的工程性能优化，并未改变其全量计算的本质，难以从根本上解决实时性和成本的矛盾。

2. 流计算系统：从流到流批一体

核心特征 ：以Flink为事实标准的流计算，其设计目标是新鲜度（Freshness）优先。它引入了无边界数据、窗口、水位线、State等一系列抽象概念，以处理动态、无序的数据流。其计算模型是一种基于事件驱动的管道（Pipe）模型，本质上是增量计算的一种特化形态。
发展与挑战 ：
- SQL已成为 Flink 开发的主流，极大地降低了开发门槛。
- 然而，Flink中的“流表”本质上是一个与作业上下文绑定的管道，不具备独立的数仓建模能力，中间结果难以复用。
- 尽管Flink提出了“流批一体”，但在纯离线 ETL 场景下，其稳定性和性能表现依然难以撼动 Spark 的地位。
- 业界出现了如 RisingWave 等新的挑战者，它们尝试将 State 卸载到对象存储，并提供更标准的 SQL 接口（如 PostgreSQL 兼容），使得部分中间表可被访问，但在大规模应用场景下的成本和成熟度仍有待验证。
局限：其为流场景设计的诸多抽象概念和管道模型，使其在推广到批处理场景时存在天然的“优化上限”，难以实现真正的通用性。

3. MPP/OLAP系统：从数仓到湖仓一体

核心特征 ：以StarRocks、Doris等为代表的系统，最初为加速查询而生。近年来，它们纷纷拥抱“湖仓一体”和“存算分离”架构，将数据存储于数据湖（如Iceberg），自身扮演加速查询层的角色。
发展与挑战 ：
- 其关键技术（如向量化执行、Cache）与面向分析场景优化的离线系统趋于同构。Cache的大小和命中率成为影响性能的关键。
- 在一些数据链路较短的场景中，涌现出多种多样的近实时方案。
- 它们支持手工定义物化视图（Materialized View）来加速查询，通常基于分区进行刷新，这在一定程度上可以模拟增量更新，但主要目的仍是查询加速。
局限：这类为低延迟（Latency）设计的系统，在承担大规模、稳定性要求高的ETL负载时，往往会遇到挑战。其物化视图的实现也多为手动、分区级别的全量刷新，距离真正的、通用的增量计算还有距离。

小结

从Lambda架构的三个顶点各自出发，仅通过工程优化的方法，优化方向往往是单一的（如批处理引擎优化查询性能），难以兼顾三角的另外两个顶点，最终无法到达一体化的终极目标。我们坚信，下一代数据架构的革新，需要一次理论层面的创新，实现由单一引擎承载的、真正的Kappa架构。在这个架构中，无论是实时数据接入、离线ETL还是在线分析查询，都由一个统一的引擎来完成，从而彻底打破“不可能三角”。

通用增量计算（GIC）的原理与关键技术

我们认为，能够支撑下一代数据架构的核心理论创新，就是通用增量计算（Generic Incremental Compute, GIC）。

原理：从一个简单的JOIN谈起

让我们通过一个简单的例子来理解GIC的原理。

离线全量JOIN ：考虑一个标准的离线SQL作业：INSERT OVERWRITE TABLE C SELECT * FROM A JOIN B ON A.id = B.id;。其执行计划非常直观：分别全量扫描（TableScan）A表和B表，然后执行JOIN操作，最后将结果写入C表。这里的核心问题是，关系代数作用于静态数据。一旦A表或B表发生任何变化，整个计算过程都需要从头再来一遍。
增量JOIN ：现在，我们用增量的思想来重新审视这个过程。假设我们定义的C表是一个动态表（Dynamic Table），其内容应始终是A与B的JOIN结果：CREATE DYNAMIC TABLE C AS SELECT * FROM A JOIN B ON A.id = B.id;。

在初始时刻，我们已经通过全量计算得到了C的结果。在下一时刻，假设A表和B表都发生了数据新增（我们用 ΔA 和 ΔB 表示增量部分）。那么，结果表C的增量 ΔC，也就是 Δ(A⋈B)，根据关系代数可以展开为：

Δ(A⋈B)=(ΔA⋈BT0 )+(AT0 ⋈ΔB)+(ΔA⋈ΔB)这个公式的含义是，新产生的JOIN结果来源于三个部分：A表的增量与B表上一个时刻的全量JOIN，A表上一个时刻的全量与B表的增量JOIN，以及A、B两表增量之间的JOIN。

这个计算过程，虽然逻辑上仍然是表达两个实体（A和B）的JOIN，但物理执行计划会变得更加智能：它不再需要对A和B进行全量扫描，而是将一次大的JOIN分解为几次小的、基于增量的JOIN，然后将结果合并（Union）到最终结果中。

理论核心与模型统一

通用增量计算的核心思想，就是将“增量”这一概念系统性地引入到关系代数中，使其处理的数据对象从静态数据扩展为动态数据（Dynamic Data）。其数学表达可以被简洁地归纳为：

ResultSetT1 =ResultSetT0 +Δ(T0,T1)即，T1时刻的完整结果，等于T0时刻的完整结果，加上从T0到T1这段时间的计算增量。

这种方式从理论上实现了批处理、流计算、交互式查询等多种计算模式的统一，使得打破“不可能三角”成为可能。相比于流计算为处理动态数据而引入的一整套复杂概念（如无界数据、乱序、Retraction等），GIC仅引入“增量”这一个核心概念，使得整个系统在设计上可以最大程度地复用和兼容成熟的批处理技术栈。流计算中的诸多概念，都可以被看作是“增量”的特化表现形式。

下图对比了三种计算模式的异同：

关键技术

实现一个高效、完备的GIC引擎，依赖于存储层和计算层的多项关键技术。

存储层：高效获取增量（Incremental Read）
- 基础：现代数据湖存储格式（如Iceberg）通过MVCC（多版本并发控制）机制为每个表维护了多个版本（snapshot）。这是实现增量计算的存储基础。
- 挑战：关键在于如何低成本地获取两个版本之间的增量数据（Δ）。
  - 在Iceberg V2 中，获取增量通常需要暴力计算两个版本快照之间的差异，这意味着可能需要扫描两次全量数据，代价高昂。
  - 在最新的Iceberg V3 规范中，通过引入“行级血缘（Row-level lineage）”等技术，可以高效地生成CDF（Change Data Feed），从而以极低的成本识别出变化的行。
云器科技的贡献 ：我们深度参与社区，推动了Iceberg C++ SDK的开发，并致力于维护存储格式的引擎中立性与社区共识，例如，推动Spark的variant类型实现贡献给Parquet社区，而非特定于某一引擎。我们的表存储格式兼容Iceberg，确保了与开源生态系统的互操作性。

黄金标准：SPOT

我们从使用者角度提出了一个判断通用增量计算方案成熟度的黄金标准—SPOT ：

S (Standard SQL) ：支持标准、统一、完整的SQL语法和语义，包括UDF，能够复用现有的技术和代码沉淀。
P (Performance) ：在一体化架构上，能同时获得批处理的高吞吐/低成本和流处理的低延迟/高实时性，并且增量算法本身经过深度优化，避免不必要的计算量放大。
O (Open Format) ：数据采用标准的开放格式（如Iceberg + Parquet）存储，可以被其他引擎高效消费，并支持标准数仓分层建模。
T (Trade-off seamlessly) ：能够在T+0（实时）和T+1（离线）之间进行平滑的权衡与调节。这要求解耦业务需求和工程需求 。业务方可以根据对数据新鲜度的要求（如5分钟）来设置刷新周期，而工程师则可以从运维角度设计分区策略（如按天分区），两者互不干扰。这与通过设置小时间分区（如5分钟分区）来模拟近实时的方案有本质区别。

目前，通用增量计算的核心技术主要掌握在少数商业公司手中。领先者已经证明了技术的可行性和业务价值，并且这些核心技术正开始向开源社区扩散，例如Databricks最近开源了Delta Live Table，以及Iceberg V3为增量计算构筑了存储基础。

案例——小红书数仓生产新范式

接下来，我将结合与小红书的合作案例，展示GIC在实际生产中的应用方式和效果。

开发范式：像写离线SQL一样处理实时数据

1. 从Kafka实时接入数据

日志表（Append-only） ：对于只需追加的日志数据，可以使用COPY INTO语句。我们将READ_KAFKA封装成一个表函数，可以直接用SQL进行查询和转换（甚至复用已有的Hive UDF），然后将结果写入目标表。
维度表（Upsert） ：对于需要更新的维度数据，语法类似，只需将COPY INTO换成MERGE INTO，通过ON条件定义主键匹配逻辑，实现UPDATE或INSERT。
为了实现持续调度，我们引入了CREATE PIPE语法。Pipe负责按指定的时间间隔（如60秒）自动调度SQL作业，并维护Kafka的点位信息，保证至少一次的处理语义。

2. 多源更新维度表

当一个维度表需要由多个数据源更新时，我们引入了TABLE STREAM的概念。

首先，在每个源表上创建一个TABLE STREAM，它代表了该表的增量流。
然后，在一个MERGE INTO语句中，将多个TABLE STREAM通过UNION ALL合并，进行统一的去重、排序（如按更新时间取最新值），最后合并到目标维度表中。这种方式用一个SQL语句就清晰地表达了复杂的多源合并逻辑。

3. 将离线ETL改写为动态表

定义：对于多层级的ETL链路，我们将传统的INSERT OVERWRITE作业改写为CREATE DYNAMIC TABLE。动态表的定义不仅包含了Schema，还直接包含了其计算逻辑（即原先的SELECT子句）。
刷新：定义好的动态表，可以通过一条简单的REFRESH DYNAMIC TABLE ...命令来触发其增量计算更新。

这个REFRESH命令可以由引擎自动调度，也可以由任何外部调度系统（如Airflow, DolphinScheduler）像调度普通离线作业一样进行调度。
通过将会话变量（SESSION_CONFIGS）传入，可以灵活控制每次刷新的分区范围，实现对分区表的高效增量更新。

4. 运维与监控

水位检查 ：数据链路的延迟监控（即水位检查）也可以完全用SQL实现。通过查询上游表的时间戳字段，判断数据是否已准备就绪，逻辑清晰且易于集成到现有调度系统中。
复用离线运维体系 ：由于整个开发和调度范式与离线系统高度兼容，因此可以完全复用已有的离线调度系统的强大能力，包括任务的可视化、依赖管理、重跑、告警等，运维体验与操作离线作业无异。

小红书整体链路与效果

在小红书，我们构建了一套统一的数据处理链路。多个Kafka数据源（包括日志和维表）通过PIPE和动态表，在ODS层和DWD层进行分钟级的增量加工。这些加工后的表，既可以直接服务于上层的BI分析和在线应用，也可以无缝衔接已有的离线Spark流程，因为所有数据都以兼容Iceberg的开放格式存储在湖上。