离线采集和实时采集要不要分开——同一份业务数据的Lambda取舍

Lambda架构的真实痛点:
 
  1) 口径双写
     GMV指标要在Flink SQL和Hive SQL里各写一次
     改一次要改两处,容易漏
 
  2) 数据一致性对不上
     实时: server_ts属于业务时间(准)
     离线: 按ds分区(UTC日)
     边界时刻的数据归属不同 → 差0.1-0.5%
 
  3) 运维翻倍
     两套代码 + 两套作业 + 两套监控 + 两套告警
     排查问题要同时查两边
 
  4) 补数据难
     实时只能回放Kafka(保留7天)
     离线可以重跑任意历史
     补数据时实时往往要等离线恢复

Lambda架构:
 
                    ┌─→ Kafka → Flink → Hologres(实时大盘)
  Binlog/埋点 ──────┤                      ↓
                    │                   对账修正
                    │                      ↑
                    └─→ HDFS → Hive → Hologres(T+1修正)
 
  - 实时层(Speed Layer):秒级延迟,近似准确
  - 批处理层(Batch Layer):T+1延迟,100%准确
  - 服务层(Serving Layer):统一对外,实时先行+批处理覆盖
 
  适用场景:
  - 已有成熟的离线数仓,不想推翻重来
  - 对准确性要求极高(金融/财务)
  - 团队实时能力弱,需要批兜底
 
  不适用:
  - 新建项目,没必要背历史包袱
  - 中小数据量,两套太重

Kappa架构:
 
  Binlog/埋点 → Kafka(长保留) → Flink作业 → Hologres/Iceberg
                       ↑
                   回溯时从头消费
 
  特点:
  - 只有一条链路,代码/监控/告警都只一份
  - 补历史靠Kafka回放(需要Kafka保留够长)
  - 所有处理都是流式(批是特殊的流)
 
  适用场景:
  - 新建项目,没有离线包袱
  - 团队Flink/Kafka能力成熟
  - 数据量中等(Kafka存储成本可控)
 
  难点:
  - Kafka长期保留贵(7天 vs 90天存储差10倍+)
  - 超长时间回溯慢(回放一年数据需要几天)
  - 复杂ETL写Flink SQL比Spark SQL难

-- Lakehouse批流一体示例(Paimon)
 
-- 1) 建表:一张表同时支持流式读写和批式读
CREATE TABLE dwd_orders (
  order_id BIGINT PRIMARY KEY NOT ENFORCED,
  user_id BIGINT,
  amount DECIMAL(10,2),
  status STRING,
  op_ts TIMESTAMP(3)
) WITH (
  'connector' = 'paimon',
  'bucket' = '16',
  'changelog-producer' = 'lookup'
);
 
-- 2) Flink流式写入(CDC来源)
INSERT INTO dwd_orders
SELECT * FROM mysql_cdc_orders;
 
-- 3) Flink流式读(实时大盘)
SELECT status, SUM(amount) FROM dwd_orders /*+ OPTIONS('scan.mode'='from-snapshot') */
GROUP BY status;
 
-- 4) Spark批式读(T+1报表)
spark.sql("SELECT DATE(op_ts) AS dt, SUM(amount) FROM dwd_orders GROUP BY 1")
 
-- 5) Presto/Trino查询(Ad-hoc)
SELECT * FROM dwd_orders WHERE order_id = 12345;
 
-- 一张表,四种读写方式,口径天然一致

适用场景：新建项目、希望简化架构；有数据平台团队支持Paimon/Iceberg运维；接受新技术栈的学习成本。

三架构对比

维度	Lambda	Kappa	Lakehouse
链路数量	两套	一套	一套
数据一致性	对账后一致	天然一致	天然一致
开发成本	高(双写)	中	低
运维成本	高	中	中
历史回溯	易(Hive)	难(Kafka回放)	易(时间旅行)
技术栈要求	Hadoop+Flink	Flink为主	新栈学习成本
落地成熟度	非常成熟	成熟	较新

面试高频追问

追问一：公司已经是Lambda了，要不要迁移到Kappa/Lakehouse？

看ROI。迁移是大工程（6-12个月+）需要明确收益。决策依据：① 如果双写治理成本每年>2个人力，ROI划算；② 如果Lambda两边口径错误已经影响业务决策，迁移是必须的；③ 如果只是"技术栈新鲜"那就不值得。真实做法：新业务上Kappa/Lakehouse，老业务慢慢迁移，而不是一次性重做。我一般建议"先试点一个核心业务域，跑稳了再推广"。

追问二：Kafka保留多久合适？

Kappa架构下Kafka是"真相之源"，保留时间决定回溯能力。经验值：① 普通业务3-7天够（故障恢复窗口）；② Kappa场景建议14-30天（能回溯两周数据）；③ 金融/监管场景90天以上。但Kafka保留长成本高——1PB数据保存30天比7天贵4倍。对策：热数据Kafka短保留（7天）+ 冷数据归档到S3/OSS（90天+），回溯超过7天从归档重放。

追问三：Lakehouse在生产上稳定吗？踩过哪些坑？

2023年开始成熟了但还有坑：① 小文件问题——流式写产生大量小文件，必须配合compaction作业；② MERGE INTO性能——大表merge依然慢，推荐按主键分桶；③ 元数据管理——文件数爆炸后元数据表会大；④ 工具链还不完善——Flink/Spark兼容性需要测试具体版本。我的建议是先用Iceberg或Paimon做非核心业务试点，跑3-6个月稳定后再推广。Databricks的Delta Lake相对最成熟但绑定生态。

实战踩坑：从Lambda迁Kappa中途回滚的教训

有个项目野心勃勃要一次性从Lambda迁到Kappa，3个月内要废掉整条离线链路。结果上线后第一天Flink作业挂了2小时，期间实时数据全没，没有离线兜底（已经关了），业务大盘空白。被迫紧急恢复Lambda。这次事故后总结出"迁移必须有兜底"——离线链路不能立刻下线，至少保留1个月作为双跑+兜底。

❌ 反模式: 激进切换,一次性关掉老链路
  T日: 上线Kappa,关闭Lambda的离线链路
  T+1: 故障,实时数据缺失,无兜底 → P0事故
 
✓ 正确做法: 灰度+兜底+分阶段迁移
  Stage-1 (1个月): 新链路和老链路双跑,做对账
    - Kappa链路写入新的staging表
    - 每天对比staging和老Lambda表,差异告警
    - 业务报表依然读老表
 
  Stage-2 (1个月): 灰度切流
    - 非核心报表先切到新链路
    - 核心报表依然双跑
    - 观察问题
 
  Stage-3 (1个月): 全量切流但老链路仍保留
    - 所有报表切新链路
    - 老链路作为冷备,继续跑但不供业务
 
  Stage-4 (6个月后): 真正下线老链路
    - 前提: 新链路已经稳定跑3个月
    - 历史Kafka/HDFS数据归档

解决方案：任何架构迁移必须"新老双跑+对账+灰度切流+保留兜底"，严禁"破釜沉舟"式切换。稳定的架构不是技术最新的，是出了问题能快速恢复的。这次教训后团队内部定了《数据架构迁移规范》，所有迁移都要走这个流程。

总结

Lambda/Kappa/Lakehouse三种架构没有绝对的好坏，只有适不适合。Lambda稳但贵、Kappa简洁但Kafka长保留贵、Lakehouse理念最好但工具链还在成熟。实际决策要看业务诉求、团队能力、历史包袱。迁移必须灰度+对账+兜底。面试时体现"架构思维+务实选型+迁移经验"分高得多。

下一篇聊最后一个实战大题：业务方要T+0，离线全量+实时增量的合并策略怎么设计？

你们公司是Lambda还是Kappa？治理成本高吗？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长