大数据Lambda架构升级至Kappa实践路径

一、迁移原则： 逐步演进，不一次性推翻现有系统。

二、迁移步骤：

Step 1：统一消息通道

• 将所有数据源接入Kafka（或Pulsar）
• 配置Kafka Tiered Storage或设置较长的保留时间（如7~14天）
• 确保Kafka可以承载全量数据的回溯（Replay）

Step 2：批处理逻辑流化

• 将批处理ETL逐模块迁移到Flink SQL/DataStream
• 对复杂计算（如T+1统计），用Flink Batch模式执行
• 关键：使用Flink的批流一体API，同一份代码可运行在批/流两种模式

Step 3：历史数据回溯

• 在Flik中启动Savepoint，从Kafka earliest offset重新消费
• 使用大并行度和Checkpoint保证回溯效率
• 回溯完成后与批处理结果做一致性比对

Step 4：分层过渡

前期（混合运行）：
  批处理层（Hive）  →  结果A（全量）
  流处理层（Flink） →  结果B（增量）
  服务层合并A和B

后期（纯Kappa）：
  Flink流处理（全量回溯+实时增量）→ 统一结果

Step 5：逐步关停批处理

• 当一个业务线的流处理结果与批处理一致（经过比对验证）后，下线批处理
• 按业务线逐一切换（低优先级→高优先级）

三、关键挑战与应对：

挑战	应对方案
Kafka保留周期内无法回溯全部数据	使用Tiered Storage（远程存储）或Pulsar
状态大小过大（TB级）	合理设计KeyBy+TTL增量Checkpoint
回溯速度慢	增加并行度+无状态回溯
数据结果不一致	使用Exactly-Once+幂等输出
系统停机时间	蓝绿部署+滚动升级

四、典型迁移时间线：

第1~2周：Kafka统一数据接入+保留时间调整
第3~4周：FlinkSQL重写简单ETL
第5~8周：复杂逻辑迁移+回溯验证
第9~10周：逐业务切换+批处理下线
第11~12周：监控调优+文档沉淀

五、建议：

• 先做非核心业务的迁移（如用户行为分析）
• 核心报表保持双跑（批+流）直到结果稳定
• 建立完善的监控（数据比对监控）