Kappa 架构是什么
Kappa 架构只保留一条流处理链路处理全部数据：正常时消费并处理增量，需要重算时通过重放日志把历史数据重新走一遍同一套逻辑，产出新版本结果后切换。它用一套代码路径替代批处理与流处理的双实现，换取逻辑一致性与运维简化，前提是日志系统能长期保存、可重放、可按序消费。
落地要算的三笔账
第一笔是保留期：重放窗口要覆盖业务的修正需求，保留期不足时历史无法重建，只能退回离线补数；第二笔是成本：日志存储与重放算力都要计入容量规划，全量重放往往比日常消费高出数倍资源；第三笔是隔离：重算任务要用独立消费组与资源池，避免和在线消费争抢资源，把一次重算变成线上事故。
基本信息
| 核心前提 | 日志可长期保存、可重放、可按序消费 |
|---|---|
| 重算方式 | 从日志起点重放并写入新版本结果，切换后生效 |
| 主要收益 | 单一代码路径，逻辑一致性与运维简化 |
| 主要成本 | 日志存储成本与重放算力，保留期越长成本越高 |
| 运维要求 | 重放任务与在线消费资源隔离，定期演练全量重放 |
落地检查
| 检查项 | 要点 |
|---|---|
| 保留期 | 覆盖业务重算需求并留出余量 |
| 重放隔离 | 使用独立消费组与独立资源池 |
| 结果切换 | 新版本结果原子切换，支持快速回滚 |
| 演练频率 | 定期执行全量重放，验证链路可用 |
| 成本核算 | 日志存储与重放算力计入容量规划 |
典型使用场景
- 指标口径频繁调整，需要反复重算历史数据的分析链路
- 团队人力有限，不希望长期维护批处理与流处理两套实现
- 事件日志已成为事实来源，历史可通过重放完整重建
- 流处理框架具备状态管理与可重放消费的能力
重放成本与日志保留策略是落地关键：保留期不足时历史重算能力受限于可回溯的数据范围，需要提前与业务确认修正窗口。
重放任务与在线消费共用资源会把线上延迟一起拖高，重算必须使用独立消费组与资源池，并预先做容量测算。