Kappa架构：对Lambda"必须维护两套系统"这个核心缺陷的回应

在工程实践中使用Lambda架构，最突出的两个痛点被反复提及：一是逻辑一致性问题——许多公共的数据分析逻辑需要在批处理和实时处理两套系统里各实现一遍，还要花额外的精力去保证这两套实现最终结果口径一致，公共逻辑的抽取和复用本身就很费力；二是维护和调试两套完全独立的技术平台，这个长期运维成本不会随时间自然消失。业界对此有不同的回应：Jay Kreps（基于在LinkedIn构建Kafka和Samza的经验）认为Lambda架构只是当前工具还不够成熟时的一种临时性折中方案，并提出了一套替代架构——在保持相同性能特性的前提下，具备更好的开发和运维特性。社区在这个方向上进一步提出了Kappa架构：核心思路是用一套统一的系统同时满足实时和批处理的需求，不再人为地把批处理和实时处理拆成两条独立的技术路径分别实现。这背后还有一个更基础的认识转变：所谓”实时”和”批量”之间并不存在绝对的界限，区别只在于延迟的长短——十秒钟内处理完可以被认为是实时，两秒钟内处理完也可以被认为是实时，这只是不同业务对延迟容忍度的主观划线，而不是两种本质不同的计算范式；既然如此，一套流处理系统理论上完全可以通过调整批量大小和窗口长度，同时覆盖原本被人为分割成”批处理”和”实时处理”的两类需求。Lambda到Kappa的演进方向，本质上是行业发展朝着”用一个统一的实时框架主动去包含批量处理能力”，而不是让批处理和实时处理始终作为两套并行独立的系统存在。