2024年数据计算架构分析：通用增量计算技术将推动Kappa架构成为主流

在当今数据驱动的商业环境中，企业对数据处理的需求正经历着前所未有的变革。从早期的批处理到后来的流计算，再到如今备受关注的增量计算，数据处理技术正在经历一场深刻的范式转变。本文聚焦于数据计算架构领域的最新发展——通用增量计算技术(Generic Incremental Compute，简称GIC)，分析这一创新技术如何打破传统Lambda架构的局限，推动Kappa架构成为未来五年的主流选择。

一、数据处理架构的演进：从Lambda到Kappa的必然趋势

数据处理技术在过去二十年经历了显著演变。以关系计算理论为核心的数据库技术(Database时代)发展数十年后，在2000年左右遇到了扩展性瓶颈。随后，以高扩展性分布式理论为核心设计的大数据系统(Big Data时代)开始高速发展，继承自Map-Reduce的典型批处理模型首先成为大数据的主流技术。

然而，批处理模型面向高吞吐优化设计，缺乏实时处理能力的缺陷促使流计算诞生并成长为与批处理并列的计算模式。这导致了经典的Lambda架构出现，成为主流架构，但也带来了典型的"数据不可能三角"问题——即数据新鲜度、低成本、高性能三个方面无法同时获得。

Lambda架构的主要缺陷已为从业者所熟知：架构复杂、数据/计算冗余、数据一致性差、系统复杂度高、开发成本高等。为实现新一代Kappa架构，业界进行了多种尝试，包括Apache Flink多年前立项探索流批一体，但均未成功。"哪种计算模型能最终实现Kappa架构？"这已成为困扰行业十年的问题。

通用增量计算(GIC)模式的提出，旨在统一当前主流的批、流、交互三种计算模式，实现Kappa架构并覆盖数据不可能三角。与传统计算模式相比，GIC具有显著优势。

Kappa架构的核心价值在于简化数据处理架构，通过单一实时处理引擎替代Lambda架构中的批处理和流处理两套系统。这不仅降低了系统复杂度，还消除了数据冗余和一致性问题，同时提供了更灵活的数据新鲜度调节能力。随着企业对实时数据分析需求的增长，Kappa架构的优势将愈发明显，而通用增量计算技术正是实现这一愿景的关键。

二、批处理与流计算的局限性：为何无法实现真正的Kappa架构

要理解通用增量计算的价值，首先需要分析传统批处理和流计算模型的本质及其局限性。批处理计算模型是针对静态数据的全量计算模型，其设计目标是吞吐率(throughput)优先，以扩展性为前提，数据新鲜度不作为主要考量方向。

批处理模式的关键特征包括：主动计算：作业主动发起计算；全量计算：每次作业下发，数据版本应当被锁定，引擎不理解数据变化；静态存储：仅支持对静态数据表达的计算；标准SQL+UDF：语言表达能力全面且丰富；

批处理虽然在高吞吐场景表现出色，但其"不理解数据变化"的本质特性使其难以满足实时数据处理需求。这正是流计算诞生的背景。

流计算针对批处理做了三个关键扩展：提出无界数据(unbounded data)概念，以及数据的无序性和延迟数据(Late Event)问题在流数据上保证一致性处理已经产出计算结果后新输入数据对之前数据的修改(Retraction问题)

流计算通过引入EventTime、Watermark、Window、Trigger等系统级概念来处理这些挑战，但这些特化设计也带来了显著问题：打破了SQL作为声明式语言与引擎解耦的设计，显著增加了使用复杂度。流计算将业务逻辑与增量语义混合在一起，SQL需要包含各种流处理特有的时间窗口、事件时间对齐、乱序数据处理等复杂逻辑。

流计算模式的核心局限在于：是一种基于window的管道式处理模式，输入输出都是管道模式，不包含全量数据为了高效retraction和状态存储，将event time、trigger、watermark做成系统概念，增加了使用复杂度不支持标准数仓建模能力，更像流水线模型，中间数据不可全量/重新访问采用非标准SQL，背离标准SQL，难以复用/统一

这些根本性差异使得在流计算框架基础上实现真正的流批一体化面临巨大挑战。Apache Flink的流批一体项目虽然进行了多年探索，但在算子层统一后，行式处理引擎架构、内置状态存储以及流语义均没有对应的升级迭代，最终未能实现真正的Kappa架构。

三、通用增量计算的技术突破：实现Kappa架构的关键路径

通用增量计算(Generic incremental Compute)基于动态数据+增量计算原理设计，是一种同时面向高性能和低延迟优化的新计算模式。其核心思想是：当上游数据不断变化时，通过只计算数据变化的部分，与之前的查询结果合并，快速生成最新查询结果。这是一种以最小运算成本、最快速度计算出最新查询结果的技术。

GIC的设计目标包括：计算模式：通过一套增量计算逻辑统一当前的流、批、交互三种模式系统架构：淘汰Lambda架构，实现真正的Kappa架构数据表达：统一接口、语法/语义，保持经典数据建模形态高性能低成本：同等条件下比主流开源引擎(Spark/Flink)提效3X-10X

通用增量计算遵循"SPOT"标准：​​S​​tandard SQL with Full Syntax/Semantics：标准、统一、完整的SQL语法表达​​P​​erformance：显著提升性能/降低成本​​O​​pen Format：数据采用标准表达方式，可被其他引擎高效消费​​T​​rade-off seamlessly between T+0 and T+1：基于参数动态调整调度周期

GIC的技术实现基于三个关键组件：​​增量计算引擎​​：理解增量并将所有计算抽象成增量形态，支持批处理的全量计算，将流计算中的增量、乱序数据、Retraction等统一到增量计算中​​动态存储​​：在湖仓存储体系上增加支持增量读取和写入，支持全量/增量与读/写的四种组合​​Shared-Everything系统架构​​：利用弹性计算能力高效处理增量计算

在实际应用中，GIC通过"动态表"(Dynamic Table)概念实现声明式编程。用户只需简单声明业务逻辑，增量化等技术细节由系统自动生成。例如，在咖啡店销售统计场景中，传统流计算需要混合业务逻辑与增量语义，而GIC只需表达业务SQL即可，大幅降低了使用复杂度。

四、增量计算的实践价值与行业应用前景

通用增量计算技术已在多个行业场景中得到验证，展现出显著的实践价值。以小红书与云器科技的合作为例，双方联合项目在半年前密集论证了增量计算的原理和框架，通过多个PoC场景证明了落地可行性，完整对比了包括Flink+Paimon+Spark+lceberg+Starrocks等多套方案。最终，项目组选择增量计算技术，并在千亿级别海量互联网日志场景中完整上线了新模型，每天处理的数据量达到千亿日志和百TB级别。

增量计算的优势在四个典型场景的性能测试中得到充分体现。与Apache Flink相比，云器Lakehouse增量刷新在相同测试集和刷新间隔下可节省大量资源。这主要源于三个关键因素：​​设计原理差异​​：GIC与静态全量计算结果对齐，而Flink需要维护大窗口状态存储，成为处理能力和资源利用效率的瓶颈​​引擎实现差异​​：Flink是Java实现且单行处理，执行效率低；云器Lakehouse是native实现的vector引擎​​计算逻辑差异​​：以Join为例，Flink左表前后进来n行就要去状态存储轮询右表n遍；而GIC的增量join是左表新来的n行和整张右表一次性hash join，右表只读一次

通用增量计算特别适用于以下业务场景特征：计算逻辑可用标准SQL或UDF描述；数据分时分批抵达系统，形成持续增量数据集；要求计算结果新鲜度在分钟级/小时级，同时要求计算资源成本显著低于全量计算；业务逻辑不涉及流计算特有的复杂时间窗口处理；希望渐进式升级数仓架构，逐步验证近实时化效果；

在具体实现路径上，增量计算技术将经历五个发展阶段：完整语法语义支持，实现开发语言统一；优化性能，通过更好的增量plan和算子达到接近理论增量计算的性能；优化数据新鲜度，将处理链路从分钟级向秒级优化；完善运维开发体系，将增量计算技术与数仓开发体系更好适配；考虑已有语法/建模方式的兼容，降低切换和上线成本；

随着这些技术阶段的逐步实现，通用增量计算有望在未来五年内推动Kappa架构成为数据处理领域的主流选择，彻底改变当前Lambda架构主导的格局。

以上就是关于通用增量计算技术及Kappa架构前景的全面分析。从数据处理架构的演进历程来看，从批处理到流计算，再到如今的增量计算，技术发展始终围绕着如何更高效、更实时地处理不断增长的数据需求。通用增量计算通过创新的技术路径，成功解决了困扰行业十年的"Kappa架构实现难题"，为数据处理领域带来了新的可能性。

云器科技提出的GIC技术通过统一计算模式、简化系统架构、提升处理效率，正在重塑数据处理的技术版图。随着该技术在更多行业场景中的验证和应用，以及后续在性能优化、新鲜度提升等方面的持续改进，基于通用增量计算的Kappa架构有望在未来五年内成为行业标准，帮助企业应对日益复杂的实时数据处理挑战，释放数据价值的更大潜能。

编辑：666知识控