导读
在实时数据需求爆炸式增长的背景下，传统“批流分离”的Lambda架构正面临成本、一致性与运维复杂度的多重绞杀。本次分享中，云器科技解决方案架构师石静猛，结合快手与小红书两大万核级集群的生产实践，系统阐述了通用增量计算（GIC）如何以一套引擎、一套标准SQL破解“不可能三角”。本文将从业务痛点透视、技术特性解析、大规模落地验证到实施路径规划，逐层拆解增量计算的实战逻辑。
Lambda 架构下难以调和的代价
当数据量达到千亿级日均规模时，典型的 Lambda 架构（Flink + Spark + Iceberg/Paimon + ClickHouse）会暴露出三重死穴，而这些痛点因规模扩大被急剧放大。
第一，时效性与成本严格互斥 。 离线批处理的全量计算模型意味着，即使上游仅有 1% 的数据变化，系统也必须重算 100% 的历史分区，这种计算惯性直接导致了结果的 T+1 滞后。而实时流处理虽然能带来秒级延迟，但其长驻资源与按峰值锁定的计费模式，在流量波动的业务场景下造成了严重的资源闲置与浪费。
第二，数据结果天然打架 。 这套架构最致命的隐患在于两套代码、两套语义。实时链路为了保吞吐，往往被迫对数据进行采样、裁剪非核心维度、限制开窗跨度；离线链路则全量兜底、逻辑完备。最终的结果是实时大盘与离线报表永远存在 2%-5% 的对账差异。对于 A/B 实验这类算法场景，一旦误差超过 3%，实验结果即告失效，业务方只能继续等待次日的离线报表，实时投入失去了决策意义。
第三，运维的不可控 。 流计算状态管理的复杂度随状态大小指数级上升，口径变更或历史数据修正往往意味着废弃状态、重启回放，操作门槛极高。而离线补数链路耗时漫长，人工调度极易触发基线破线。
为了打破这一困局，我们必须寻找一种新的计算范式——它不应在流和批之间做非此即彼的选择，而是能根据业务需求动态调整计算粒度。云器的答案是通用增量计算(GIC)
GIC 的设计逻辑与技术特性
通用增量计算（GIC）给出的解法并不复杂：核心只有一句话——每次只算该算的数据，每份数据只算一次。但它实现这一目标的方式，涉及到从引擎到存储的全链路重构。
从“被动计算”到“主动合并” 。 传统流计算是被动地等待数据触发计算，而 GIC 采用主动计算模式，同时支持用户主动查询与系统定时刷新。数据模型从静态存储或 Pipe 管道，演进为动态数据（Dynamic Data）。系统会追踪基表的每一次变更（Append/Update/Delete），并在触发刷新时仅对增量数据进行运算，再与存量合并输出。
架构的一体化收口 。 通过一体化引擎与一套标准 SQL，GIC 直接取代了复杂的 Lambda 双链路。外部数据（如 Kafka）通过 Pipe 管道无缝摄入 Lakehouse，用户只需声明 CREATE DYNAMIC TABLE 并配置 REFRESH EVERY（如 1 分钟、5 分钟），系统便自动按照设定的分钟级周期触发增量计算。彻底放弃了资源长驻模型，真正实现了时效性与计算成本的按需平衡。
落地体验：标准 SQL 的开发手感与开放存储
对于一线开发人员而言，GIC 带来的最直观改变在于研发体验。它并非要求开发者学习新的计算模型，而是将复杂性下沉到底层引擎。
全量语义，增量执行 。 开发者只需要按照 Spark 离线的全量语义编写 SQL，系统自动进行增量逻辑转换。无论是复杂多流 Join、窗口函数、CTE 还是自定义 UDF/UDAF，绝大部分离线逻辑可直接复制粘贴迁移。唯一的限制仅是不支持像 random 这类非确定性函数。
开放格式与分层建模 。 存储底座基于 Apache Iceberg 标准，文件格式为 Parquet，这意味着数据资产并不绑定在单一引擎上，可由其他大数据生态组件直接消费。数仓分层（ODS -> DWD -> DWS）逻辑得以完整保留，每一层均可作为独立资产对外提供查询。更重要的是，GIC 支持对历史分区的直接增量更新，在进行补数或重算时，旧数据自动融合修正，且完全不阻塞新数据的实时写入——这彻底告别了流批两套逻辑下的状态丢弃痛点。
按需调节的灵活性 。 系统在每次刷新时都会基于代价（Cost-Based）进行动态优化，根据数据变更类型与数据量选择最优执行计划。业务方只需调整调度周期这一个参数，就能在极致实时与极致成本之间平滑游走。相较于传统架构的多组件拼凑，GIC 在技术栈复杂度、开发语言统一性、增量算子覆盖度上均表现出代际优势。
快手离线转实时的严苛测试
理论上的优势必须经受住超大规模生产环境的考验。快手数据平台部从线上抽取了日均千亿级数据的真实离线任务，设计了两层验证体系：“能做”（技术可行性）与“做好”（业务收益）。
在“能做”层面，快手验证了完整语法语义的增量化支持（覆盖 Count、Join、Window、复杂 UDF），验证了增量结果与离线结果的严密一致性（差异需 < 1%），并确认了离线 SQL 可直接复用，无需重写。在“做好”层面，重点考察时效性是否能从 T+1 跃升至分钟级，以及资源开销是否可控。
快手选取了三个梯度场景进行对标：
简单场景 （几十 GB/天，计算简单）。时效性从 T+15 分钟提升至 5 分钟，增量计算累计开销仅为离线基准的 1/20。
中等场景 （几十 TB/天，计算简单）。时效性从 T+1 小时提升至 5 分钟，增量累计开销不到离线的 1/3。
复杂场景 （10+ 表关联，涉及 10TB+ 大表、复杂 Join/Window/UDF 嵌套，4 层加工）。时效性从 T+3.5 小时提升至 50 分钟，增量开销基本与离线持平。
当三个场景混合执行时，简单、中等任务以 5 分钟周期刷新，复杂任务以 40 分钟周期刷新，总增量资源开销与离线基准持平。这意味着在将核心业务从 T+1 提升至近实时的过程中，并未产生额外的计算成本。
快手的最终收益是四重的 ： 算法 A/B 实验实现近实时调参；时效性提升的同时资源开销低于原离线成本；高频次增量执行将夜间沉重负载分摊至全天，极大缓解了基线破线焦虑；一套架构收敛所有需求，大促时只需调整调度参数即可注入算力。
小红书近实时实验指标的架构演进
小红书面临的则是另一类典型困境：其线上千亿级流量日志服务于 A/B 实验场景，原有 Flink + Spark + ClickHouse 的 Lambda 架构，实时链路为了保时效裁剪了非核心维度，导致与离线数据差异经常大于 5%，业务方无法信任实时数据。此外，大开窗导致的状态膨胀与 Flink 高额成本也是巨大痛点。
小红书最终选择将这套 Lambda 架构整体迁移至基于云器 Lakehouse 的 Kappa 架构。
在增量计算基础之上，关键设计额外包含了三个亮点：
1.分钟级聚合 DWS 层 。 利用增量计算引擎，直接将数千亿原始明细日志聚合成 5 分钟粒度、带 user_id 的 DWS 层数据，数据量瞬间缩容至亿级，为上层 OLAP 铺平了性能道路。
2.Partial Update 实时维表 。 利用部分列更新能力，将庞大的用户维表拆解为高频实时维度（1 分钟调度）与稳定离线维度（天级调度），极大缓解了传统流关联在超大状态下的内存消耗。
3.实验数组倒排优化与 JSON 查询加速 。 在 OLAP 层对实验维表建立底层倒排索引，使复杂圈群查询性能飙升 20 倍。同时将易变动的算法监控指标直接表达为 JSON 列，业务方可实现免 DDL、免重启的自助字段增减。
改造效果显著 。 资源投入从原实时链路的 5000+ Core 降至 1800 Core（降低 64%+）；数据一致性从 2%-5% 的差异收敛至 < 1%；核心指标从十几个扩展到上百个，且无上限横向扩展。整个改造成本极低，全程复用标准 SQL，彻底摆脱了对多种引擎方言的维护负担。
从场景甄选到平滑割接
增量计算的落地并非一蹴而就，云器在实践总结中给出了一套可复制的实施路径。
场景优先级划分（P0-P2） 。 优先级最高（P0）的是日志流量与 A/B 实验指标场景，建议采用分钟级（1-5min）调度，时效性可从 T+1 跃升至分钟级，资源成本硬降 60%+。其次是 P1 场景，如大窗口延迟数据补算与复杂维表高频更新，利用增量精准补算可将重跑耗时从数小时骤降至数分钟。P2 场景则针对日常经营报表，采用宽松调度即可进一步压缩资源。
迁移策略与 Skill 辅助 。 在迁移方式上，云器提供了结合 AI Agent 的增量计算 Skill，开发者只需输入“把这个 SQL 改成增量的”，系统即可辅助完成转化。在生产切换阶段，建议采用“三步走”原则：精准切入最痛场景 -> 建立增量 vs 离线的自动对账机制（确保差异 < 1%）-> 渐进式双跑流量切换。待老链路与 GIC 旁路并行稳定数周、覆盖完整业务波峰波谷周期后，再执行零感知割接。
云器 Lakehouse GIC 价值总结
回顾快手与小红书的实战过程，增量计算带来的价值并非边际改善，而是架构层级的代际跃升。
它实现了时效性的跨越（T+1 → 分钟级），满足了近实时决策需求；资源成本大幅降低（降低 70%+）；数据一致性得到了铁一般的保障（增量 = 离线，差异 < 1%） 。 更重要的是，它用一套 SQL 替代了 Lambda 双链路，将开发工作量降到了极低，同时允许业务方像调节音量一样，通过调度参数灵活平衡时效性与成本。
如果要用数字来浓缩这场变革——资源成本降低为原来的三分之一，开发运维成本降低为原来的三分之一，存储成本（因去重与高效压缩）同样降低为原来的三分之一 。 在这个数据量持续暴涨的时代，实现三个“三分之一”的降本增效，或许正是增量计算获得快手与小红书共同选择的核心原因。
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
