📚 课程目录第3章 Lambda架构实战

3. Lambda架构实战：批流分离的代价

Lambda架构，说白了就是一套“既要又要”的方案。你要实时性，我给你Speed Layer；你要准确性，我给你Batch Layer。听起来很完美对吧？但我在实际项目中踩过几次坑之后，才真正理解什么叫“理想很丰满，现实很骨感”。

这一章，咱们就聊聊Lambda架构在落地时最让人头疼的三个问题：批流分离的代价、数据口径不一致、存储冗余。嗯，每一个都是真金白银换来的教训。

3.1 批流分离：两套代码，双倍痛苦

Lambda架构的核心思想，就是把数据管道拆成两条独立的路径。一条跑实时流处理，一条跑离线批处理。最后在Serving Layer把结果合并。

听起来逻辑清晰，但你想想看——这意味着你要维护两套完全不同的代码。

核心痛点：同一份业务逻辑，用Streaming API写一遍，再用Batch API写一遍。两套代码的语义、算子、状态管理机制完全不同。

我举个例子。假设你要计算“过去1小时每个用户的PV”。

实时流处理（Flink SQL）：

-- Speed Layer: 基于Event Time的滚动窗口
INSERT INTO user_pv_1h_speed
SELECT
    user_id,
    COUNT(*) AS pv,
    TUMBLE_END(event_time, INTERVAL '1' HOUR) AS window_end
FROM click_events
GROUP BY
    user_id,
    TUMBLE(event_time, INTERVAL '1' HOUR);

离线批处理（Spark SQL）：

-- Batch Layer: 基于数据分区的全量重算
INSERT OVERWRITE user_pv_1h_batch
SELECT
    user_id,
    COUNT(*) AS pv,
    from_unixtime(
        floor(unix_timestamp(event_time) / 3600) * 3600
    ) AS window_end
FROM click_events_daily
WHERE dt = '${yesterday}'
GROUP BY
    user_id,
    floor(unix_timestamp(event_time) / 3600);

看出来了吗？同样的业务目标，窗口定义方式不同、时间处理函数不同、数据源表名不同。这还只是最简单的计数逻辑。一旦业务规则复杂起来——比如去重、会话切割、多流Join——两套代码的差异会成倍放大。

我的建议：如果团队人力有限，别轻易上Lambda。先问问自己——业务真的需要毫秒级延迟吗？如果分钟级可以接受，Kappa架构（只用一套流引擎）会省心得多。

3.2 数据口径不一致：同一个指标，两个数字

这是Lambda架构最让人抓狂的问题。没有之一。

我在项目中遇到过这么一件事：运营同学早上看实时大屏，显示“今日新增用户 12,350”。到了下午，离线报表跑完，数字变成了“今日新增用户 12,178”。差了172个。

运营跑来问我：“哪个是对的？”

我当时的表情，嗯，很复杂。

为什么会出现口径不一致？原因主要有三个：

时间窗口边界不同：实时流用Event Time + Watermark，离线批用数据分区时间。跨天边界的数据归属可能不同。
数据到达延迟：实时流处理的是“已到达”的数据，离线批处理的是“全量”数据。迟到的数据在实时侧可能被丢弃或进入错误窗口。
去重逻辑差异：实时去重依赖状态后端（如RocksDB），离线去重依赖全量排序或HashSet。状态过期策略不同，结果自然不同。

避坑指南：我曾经因为没处理好迟到数据，导致实时报表连续三天和离线报表对不上。最后花了整整一周排查，才发现是Watermark配置太激进，把正常延迟的数据全丢了。

解决口径不一致，我总结了一套“三步走”策略：

步骤	操作	说明
1. 统一时间语义	批流都使用Event Time	避免Processing Time和Event Time混用
2. 对齐窗口定义	批流使用相同的窗口函数和边界	比如都用TUMBLE，步长一致
3. 建立数据对账机制	每小时/每天自动比对批流结果	差异超过阈值自动告警

说白了，你要把“对账”当成一个常态化操作，而不是出了事故才去查。

3.3 存储冗余：一份数据，存三遍

Lambda架构的存储模型，天然就是冗余的。

Batch Layer：原始数据存一份（比如HDFS上的Parquet文件）
Speed Layer：实时中间结果存一份（比如Kafka Topic或RocksDB状态）
Serving Layer：最终合并结果再存一份（比如HBase或ClickHouse）

你想想看，同样一个用户的“近7日活跃天数”，在Batch Layer的离线表里有一份，在Speed Layer的实时状态里有一份，在Serving Layer的合并视图里又有一份。三份数据，存储成本直接翻倍甚至翻三倍。

数据对比：以日均100亿条日志的中型公司为例，Lambda架构的存储成本大约是Kappa架构的2.5~3倍。

更麻烦的是，冗余带来的不只是存储成本。还有数据一致性维护成本。你改了Batch Layer的计算逻辑，必须同步修改Speed Layer的逻辑，否则Serving Layer合并出来的结果就是错的。

我个人的习惯是，在架构选型阶段就做一次存储成本估算：

存储成本估算公式：
总存储 = 原始数据 × 副本数 × 压缩比
        + 实时状态 × 状态TTL × 并行度
        + 服务层数据 × 预聚合倍数

以日均100亿条、每条500字节为例：
- 原始数据（3副本，Parquet压缩比0.3）：~45TB/天
- 实时状态（RocksDB，TTL 7天）：~10TB
- 服务层（预聚合10倍）：~5TB
- 合计：~60TB/天

这个数字，乘以云存储单价，你大概就能算出每个月的存储账单了。

3.4 一张图看懂Lambda架构的代价

下面这张SVG图，把批流分离、口径不一致、存储冗余这三个问题串在了一起。你可以看到，每个问题都不是孤立的，它们互相影响，最终都指向一个结果——运维复杂度飙升。

3.5 我的建议：什么时候该用Lambda？

说了这么多问题，你是不是觉得Lambda架构一无是处？也不是。它确实有它的适用场景。

我个人认为，只有满足以下至少两个条件时，才值得考虑Lambda架构：

实时性要求极高：秒级甚至毫秒级延迟，Kappa架构无法满足
数据准确性不容妥协：比如金融交易、计费系统，必须通过离线重算来修正
团队规模足够大：有专门的实时团队和离线团队，各司其职
存储成本不敏感：公司愿意为数据准确性支付额外的存储费用

一个小技巧：如果决定用Lambda，可以考虑在Speed Layer和Batch Layer之间共享一部分代码。比如用统一的SQL模板，通过不同的引擎参数来生成Flink和Spark的执行计划。这样至少能减少一半的代码差异。

好了，这一章的内容就到这里。Lambda架构的代价，说白了就是“用复杂度换实时性”。你付出的每一分代价，都要能换来对应的业务价值。否则，不如退一步，选个更简单的方案。