📚 课程目录第4章协同策略总览

4. 协同策略总览：Lambda架构的实时与离线分层设计，数据一致性保证方案

聊到实时数仓和离线数仓的协同，绕不开一个经典架构——Lambda。说实话，这玩意儿被讨论得够多了，但真正在生产里把它落地好，其实没那么简单。我见过不少团队，架构图画得漂漂亮亮，一上线就各种对不上数。

这一章，咱们就掰开揉碎，看看Lambda架构到底怎么分层，以及最头疼的数据一致性问题，到底怎么解。

4.1 Lambda架构的核心分层逻辑

Lambda架构的核心思想，说白了就是「两条腿走路」。一条腿处理离线批量数据，保证全量和准确；另一条腿处理实时流数据，保证低延迟。最后在服务层合并，对外提供统一视图。

我个人习惯把Lambda架构分成三层来看：

批处理层（Batch Layer）：负责全量数据的周期性计算。延迟高，但结果准确。典型技术栈就是Hive、Spark SQL跑T+1任务。
流处理层（Speed Layer）：负责增量数据的实时计算。延迟低，但结果可能因为数据乱序或窗口边界问题，存在一定近似。典型技术栈是Flink、Kafka Streams。
服务层（Serving Layer）：合并批处理和流处理的结果，对外提供查询接口。典型技术栈是ClickHouse、Druid、HBase。

关键点：批处理层的结果是「权威数据」，流处理层的结果是「临时补偿」。当批处理层重新计算完历史数据后，流处理层的对应结果必须被覆盖或淘汰。

下面这张图，是我自己项目里常用的分层设计，你可以参考一下：

4.2 实时与离线分层设计的落地细节

分层设计听起来简单，但落地时有不少坑。我挑几个关键点说说。

4.2.1 数据流向与存储隔离

批处理和流处理的数据，在存储上必须物理隔离。为什么？

批处理层的数据，通常是列式存储（Parquet/ORC），按分区组织，适合全表扫描。
流处理层的数据，通常是行式存储或宽表，按事件时间组织，适合点查。

混在一起，性能会互相拖累。我在项目中遇到过，有人图省事把实时结果直接写到离线表里，结果离线任务跑的时候，实时数据还在写，锁冲突导致任务失败。嗯，这里要注意，存储隔离是底线。

4.2.2 窗口对齐与数据补偿

实时流处理通常用滚动窗口或滑动窗口，离线批处理按自然天分区。这两者的时间边界天然不一致。

举个例子：

离线任务统计的是 2025-04-01 00:00:00 到 2025-04-01 23:59:59 的数据。
实时任务可能用 5 分钟窗口，最后一个窗口跨了 00:00 边界。

怎么对齐？我建议的做法是：

实时任务在窗口结束时，把结果写入一张「实时预聚合表」，带上窗口的起止时间戳。
离线任务跑完后，把对应时间段的实时预聚合数据标记为「已覆盖」。
服务层查询时，优先取离线结果，缺失部分用实时结果补全。

小技巧：在实时预聚合表里加一个 batch_version 字段。离线任务跑完后，更新这个版本号。服务层查询时，只取版本号最新的数据。这样能避免数据重复或遗漏。

4.3 数据一致性保证方案

这是Lambda架构里最让人头疼的问题。实时和离线算出来的结果不一样，怎么办？

我把它归纳为三种场景：

场景	原因	典型表现
数据延迟	实时流数据迟到，离线任务没等到	实时结果偏小，离线结果偏大
数据乱序	事件时间乱序，实时窗口计算错误	实时结果偏大，离线结果准确
计算逻辑差异	实时和离线用了不同的去重或聚合算法	两者结果不一致，但各有道理

4.3.1 最终一致性方案（推荐）

我个人最推荐的做法，是放弃强一致，拥抱最终一致。具体来说：

实时层提供「临时视图」：用户看到的实时数据，允许有几分钟的误差。
离线层提供「权威视图」：每天凌晨，离线任务跑完后，覆盖掉前一天的实时数据。
服务层做「版本切换」：离线结果写入后，服务层自动切换到离线数据，实时数据降级为备用。

这样做的好处是，实现简单，性能可控。坏处是，在离线结果出来之前，用户看到的数据可能不准。

注意：最终一致性方案，要求业务方接受「数据在 T+1 之前是近似值」。如果业务要求实时数据必须准确（比如金融交易），Lambda架构可能不适合你，考虑Kappa架构或混合方案。

4.3.2 数据对账与修复机制

不管用哪种方案，数据对账都是必须的。我习惯每天跑一个对账任务：

-- 对账SQL示例：对比实时与离线聚合结果
SELECT 
    dt,
    SUM(real_time_amount) AS rt_amount,
    SUM(batch_amount) AS batch_amount,
    ABS(SUM(real_time_amount) - SUM(batch_amount)) AS diff
FROM (
    -- 实时预聚合数据
    SELECT dt, amount AS real_time_amount, 0 AS batch_amount
    FROM dwd_realtime_agg
    WHERE dt = '${yesterday}'
    UNION ALL
    -- 离线全量数据
    SELECT dt, 0 AS real_time_amount, amount AS batch_amount
    FROM dws_batch_agg
    WHERE dt = '${yesterday}'
) t
GROUP BY dt
HAVING diff > 0;

如果发现差异超过阈值（比如千分之一），就触发修复流程：

先查实时层是否有数据重复或丢失。
再查离线层是否有计算逻辑变更。
最后，以离线层为准，覆盖实时层数据。

我曾经遇到过一个案例，实时任务因为Kafka分区重平衡，导致一批数据被重复消费。对账发现差异后，我们手动清理了实时表里的重复数据，然后重跑了那天的离线任务。嗯，从那以后，我就在对账任务里加了分区偏移量校验。

4.3.3 数据回溯与重算策略

离线任务重算历史数据时，实时层的数据怎么办？

我的做法是：

离线任务重算时，把结果写入一个新的分区（比如 dt=2025-04-01_v2）。
重算完成后，更新服务层的元数据，把查询指向新分区。
旧分区保留一段时间，用于回滚。

这样，实时层的数据不受影响，用户查询时自动切换到新数据。整个过程对业务透明。

核心原则：实时层永远只处理「当前」数据，离线层负责「历史」数据的修正。两者通过服务层的版本机制解耦，互不干扰。

4.4 小结

Lambda架构的分层设计，说白了就是「实时保时效，离线保准确」。数据一致性方案，我建议优先选最终一致，配合对账和修复机制。别追求完美，追求可控。

你想想看，如果实时和离线完全一致，那还要两层干嘛？直接跑一层不就完了。正是因为各有侧重，才需要协同。把握好这个度，Lambda架构就能跑得稳。