通用增量计算101：统一批流，迈向Kappa架构
背景: 数据处理技术经历了数据库时代、大数据时代和流计算时代，但经典的Lambda架构因其“不可能三角”问题（数据新鲜度、低成本、高性能难以兼顾）而存在缺陷。业界一直在探索打破这一困境的最佳设计，Kappa架构成为理想目标。
批处理与流计算的局限性: 批处理模型针对静态数据进行全量计算，缺乏实时性；流计算模型虽然解决了实时性问题，但架构复杂，数据一致性差，且难以同时满足数据不可能三角。
通用增量计算 (GIC) 的提出: GIC基于动态数据和增量计算原理设计，通过计算数据变化部分并与历史结果合并，快速生成最新查询结果，同时面向高性能和低延迟优化。其设计目标是统一批、流、交互三种计算模式，实现Kappa架构，并覆盖数据不可能三角。
GIC 的核心概念:
- 声明式定义: 用户只需声明业务逻辑，无需关注增量计算细节，通过标准SQL即可完成开发。
- 动态表 (Dynamic Table): 以SQL形式定义查询结果，通过增量计算方式保证查询结果实时写入表中，简化ETL链路构建。
- 数据流 (Table Stream): 记录对表所做的数据操作语言 (DML) 更改，包括插入、更新和删除，以及有关每次更改的元数据。
- 增量算子: 包括SCAN、PROJECT、FILTER、UNION ALL、AGGREGATE、WINDOW、INNER JOIN等，用于处理增量数据。
GIC 的关键技术:
- 增量算法: 针对不同的增量算子，GIC提供相应的增量算法，例如FILTER只需要读取输入表的增量数据即可完成计算，而JOIN和AGGREGATE则需要读取历史数据。
- 增量任务的调度: GIC提供多种调度模式，包括数据到达立即消费、按时间周期性调度、根据依赖触发调度等，以满足不同业务场景的需求。
GIC 的性能优势: 与传统的流计算模型相比，GIC在资源消耗和处理延迟方面具有显著优势，能够在同等条件下比主流开源引擎(Spark/Flink)提效3X-10X。
GIC 的适用场景:
- 计算逻辑可以用标准SQL语言或者UDF描述。
- 数据非一次性全量写入，而是分时分批抵达系统的，形成持续的增量数据集。
- 希望计算结果的数据新鲜度在分钟级/小时级，同时要求计算资源成本显著低于全量计算或流计算。
- 业务逻辑不涉及流计算特有的时间窗口、事件时间对齐、乱序数据处理等复杂逻辑。
- 希望渐进式升级数仓架构，增量计算可作为批处理与流计算的中间形态。
GIC 的限制项: 目前，GIC在包含随机函数的场景中存在诸多限制，例如current_timestamp等随机函数会削弱增量计算的优势。
GIC 的未来展望: 未来GIC将朝着更完整的语法语义支持、性能优化、数据新鲜度优化、完善的运维开发体系以及与现有流/批计算作业和pipeline的兼容等方向发展。
