Lambda还是Kappa？两套链路维护成本太高了——架构选型怎么决策？

Lambda架构数据流：
 
              ┌─ Kafka → Flink(实时清洗) → Flink(实时聚合) → Doris ─┐
数据源 ──→ Kafka ──┤                                                  ├──→ 查询服务
              └─ Kafka → HDFS/MaxCompute(离线) → Spark(批处理) → Doris ─┘
 
实时链路：秒级/分钟级出数，可能有误差
离线链路：T+1出数，覆盖修正实时数据

Kappa架构数据流：
 
数据源 ──→ Kafka ──→ Flink(流处理) ──→ Doris/HBase ──→ 查询服务
 
如果需要修正历史数据：
Kafka(回溯消费) ──→ Flink(重新计算) ──→ Doris(覆盖写入)

公司2（某出海硬件品牌）：标准Lambda。因为业务涉及财务核算（用户复购、渠道分成），数据准确性要求极高。实时链路只服务大屏监控，所有报表和分析都以离线为准。100+Spark作业跑在Databricks上，实时只有5-6个Flink作业。

公司3（某短剧出海公司）：实用主义Lambda。核心广告ROI指标走双链路（实时+离线），其他非核心指标（如内容分析、用户画像）只走离线。这样既保证了核心指标的时效性和准确性，又控制了维护成本。

// 我的选型决策树
Q1: 这个指标需要分钟级时效性吗？
  ├─ 否 → 只走离线链路（80%的指标）
  └─ 是 → Q2: 这个指标需要用于财务核算或数据对账吗？
       ├─ 是 → Lambda双链路（实时出数+离线兜底修正）
       └─ 否 → 只走实时链路（风控、推荐等）
 
// 实际结果
// 离线只：用户画像、月度报表、历史趋势分析（~80%指标）
// Lambda双链路：广告ROI、核心转化漏斗、收入报表（~15%指标）
// 实时只：实时风控告警、异常检测（~5%指标）

Lambda最大的坑：口径不一致怎么解

Lambda架构最被诟病的问题就是'两套代码、两套口径'。离线用Spark SQL，实时用Flink SQL，同一个指标要写两遍，稍有不慎口径就不一致。

我的解决方案是'口径文档 + SQL模板复用'：

-- 解决方案：用统一的指标定义文档 + SQL模板
 
-- 指标定义（口径文档）：
-- paid_uv = COUNT(DISTINCT user_id) WHERE event_type = 'purchase'
--          AND pay_status = 'success' AND pay_amount > 0
 
-- 离线SQL（Spark/MaxCompute）
SELECT dt, channel,
    COUNT(DISTINCT CASE WHEN event_type = 'purchase'
        AND pay_status = 'success' AND pay_amount > 0
        THEN user_id END) AS paid_uv
FROM dwd_user_payment_di
GROUP BY dt, channel;
 
-- 实时SQL（Flink）-- 口径完全一致，只是数据源和窗口不同
SELECT window_start, channel,
    COUNT(DISTINCT CASE WHEN event_type = 'purchase'
        AND pay_status = 'success' AND pay_amount > 0
        THEN user_id END) AS paid_uv
FROM dwd_user_payment_stream
GROUP BY TUMBLE(event_time, INTERVAL '1' MINUTE), channel;

面试高频追问

追问一：你现在让你重新选，还会选Lambda吗？

还是会选Lambda，但会更克制地使用实时链路。我现在的原则是'能不做实时就不做实时'——不是因为实时不好，而是因为实时的开发和运维成本是离线的3-5倍。只有业务真正需要分钟级时效性的指标才值得走双链路。我见过很多团队盲目上实时，结果实时链路三天两头出问题，运维压力巨大，最后发现业务方其实看T+1的数据就够了。

追问二：湖仓一体能解决Lambda的双链路问题吗？

理论上可以，但目前还没有完美方案。像Iceberg + Flink的方案，可以让实时和离线读写同一张表，减少数据冗余。但流上写Iceberg的性能和稳定性还不够成熟，我在生产环境暂时没有大规模使用。如果是新项目从0开始，我会认真评估Paimon（Flink社区推的流批一体存储），它的目标就是解决Lambda的双链路问题。但对于已有的成熟项目，切换成本太高。

追问三：两条链路的数据对不上怎么办？

一定会对不上，这是Lambda的宿命。关键是建立对账机制：每天凌晨离线链路跑完后，对比实时和离线的核心指标差异。如果差异在5%以内，认为正常（实时有窗口边界、乱序数据导致的误差）；如果超过5%，触发告警排查。我们的做法是把对账结果写入一张监控表，用Grafana看板展示每日差异趋势。

实战踩坑

在某元宇宙社交应用时，我们最痛的一次踩坑就是前面提到的——Kappa架构下Flink作业OOM重启，丢了20分钟数据。

当时的情况是：晚上8点高峰期，直播间送礼事件暴增，Flink作业的State太大导致Checkpoint超时，连续3次Checkpoint失败后作业自动重启。重启后从上一次成功的Checkpoint恢复，但中间20分钟的数据已经丢了——实时大屏上晚8点到8:20的送礼金额是0，运营一看就炸了。

后来我们的修复方案是：① 紧急从Kafka重放那20分钟的数据手动补数；② 长期方案是加了离线链路每天凌晨跑一遍全量覆盖，确保T+1的数据一定是准的。这就是我说的'Kappa最终还是会走向Lambda'的原因。

# 紧急修复：从Kafka指定offset重放数据
# 1. 找到丢数据的时间范围对应的Kafka offset
kafka-consumer-groups.sh --bootstrap-server kafka:9092 \
  --group flink-gift-consumer --describe
 
# 2. 重置offset到20:00对应的位点
kafka-consumer-groups.sh --bootstrap-server kafka:9092 \
  --group flink-gift-consumer --reset-offsets \
  --to-datetime 2021-03-15T20:00:00.000 \
  --topic ods_user_gift_event --execute
 
# 3. 重启Flink作业消费补数（需要下游幂等写入）

总结

Lambda和Kappa不是'谁更好'的问题，而是'哪个更适合你的业务场景'。准确性要求高、有财务核算需求的，选Lambda；业务逻辑简单、修正需求少的，可以尝试Kappa。现实中大多数公司用的是'实用主义Lambda'——核心指标双链路，非核心指标只走离线。面试时能说清楚你的选型理由、踩过的坑、以及对新架构趋势的思考（湖仓一体/Paimon），会非常加分。

架构选型讲清楚了，但很多时候不是从0开始选——而是'已有离线数仓，老板突然要加实时'。下一篇聊怎么在已有离线数仓上渐进式加实时链路，不翻车。

你们公司用的Lambda还是Kappa？有没有试过湖仓一体？评论区聊聊～

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