3、架构总览：Lambda架构详解、Kappa架构详解、混合架构设计、架构选型决策树
聊实时OLAP，绕不开架构选型。我见过不少团队，一上来就追Kappa，觉得Lambda过时了。结果呢？业务需求一变，数据回溯搞不定，又偷偷把批处理加回来了。说白了，没有银弹。
这一章，我把三种主流架构掰开揉碎讲清楚。Lambda、Kappa、混合架构，各自解决什么问题，坑在哪，怎么选。最后给一张决策树，你照着走就行。
3.1 Lambda架构详解
Lambda架构是2011年由Nathan Marz提出的。核心思想很简单：用批处理保证准确性，用流处理保证低延迟。两条路径，各司其职。
核心公式：实时层 + 批处理层 + 服务层 = 完整数据视图
3.1.1 三层职责
- 批处理层（Batch Layer）：存储全量原始数据，定期重算。结果准确，但延迟高（小时级）。
- 实时层（Speed Layer）：处理增量数据，提供秒级视图。有误差，但快。
- 服务层（Serving Layer）：合并批处理结果和实时结果，对外提供统一查询。
我在项目中遇到过一个问题：实时层和批处理层的结果合并逻辑写得很复杂。尤其是做去重计数（Count Distinct）时，两边的中间结果格式不一样，合并时经常对不上。后来我们统一了中间结果的存储格式，才把这个问题解决掉。
3.1.2 优缺点
| 维度 | 优点 | 缺点 |
|---|---|---|
| 准确性 | 批处理全量重算，数据准确 | 实时层可能因乱序数据产生误差 |
| 延迟 | 实时层提供秒级响应 | 批处理层小时级延迟，合并逻辑复杂 |
| 运维 | 批处理和流处理解耦，可独立维护 | 两套代码、两套集群，运维成本翻倍 |
| 回溯 | 天然支持数据回溯，重跑批处理即可 | 回溯期间实时层数据可能不一致 |
避坑指南：我曾经在一个日活千万的报表项目里用了Lambda，结果实时层和批处理层的数据对不上。查了两天，发现是实时层的窗口边界和批处理层的分区边界不一致。嗯，这里要注意：两层的窗口语义必须对齐。
3.2 Kappa架构详解
Kappa架构是Jay Kreps在2014年提出的。他当时说：既然流处理引擎已经能保证Exactly-Once语义，为什么还要维护两套代码？只用一套流处理，搞定所有事情。
3.2.1 核心思想
Kappa架构只有一条链路：所有数据都进入消息队列（如Kafka），流处理引擎从队列中消费数据，计算结果直接写入服务层。需要回溯时，重新消费Kafka中的历史数据即可。
说白了，就是把批处理当成一种特殊的流处理——用更大的窗口、更低的并行度去消费历史数据。
3.2.2 适用场景
- 数据源单一，不需要关联大量外部维表
- 业务逻辑相对简单，状态管理可控
- 团队规模小，没有精力维护两套代码
- 数据回溯频率低，且能接受回溯期间的性能下降
个人经验：我建议在数据量小于100TB、QPS低于10万的场景下优先考虑Kappa。一旦数据量上去，Kafka的存储成本和流处理的状态管理会成为瓶颈。你想想看，Kafka要保留全量数据，磁盘开销可不小。
3.2.3 Kappa的坑
Kappa架构看起来很美，但实际落地时问题不少。我踩过几个坑：
- 状态膨胀：流处理的状态后端（RocksDB）撑不住，GC频繁，导致反压。
- 回溯性能：重新消费Kafka历史数据时，消费速度远低于写入速度，回溯一个月的数可能要跑几天。
- 乱序数据：Watermark设置不合理，导致大量数据被丢弃或延迟处理。
3.3 混合架构设计
Lambda太重，Kappa太理想。实际生产中，大多数团队最终走向了混合架构。说白了，就是取两者的长处，根据业务场景灵活组合。
3.3.1 常见混合模式
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Lambda-Lite | 批处理层用Spark，实时层用Flink，服务层统一用OLAP引擎（如ClickHouse） | 需要高准确性，且实时层数据量不大 |
| Kappa+批处理辅助 | 主链路用Kappa，定期用批处理做数据校验和修正 | 对数据一致性要求高，但不想维护两套集群 |
| 分层混合 | 近实时数据走Kappa，历史数据走批处理，服务层做数据融合 | 既有实时看板需求，又有历史分析需求 |
我个人习惯用Kappa+批处理辅助这种模式。主链路用Flink消费Kafka，写入ClickHouse。每天凌晨跑一个Spark任务，对前一天的数据做全量校验和修正。这样既保证了实时性，又保证了准确性。
3.3.2 混合架构的关键设计点
- 数据一致性协议：定义好批处理和流处理的结果合并规则，比如用时间戳+业务主键做UPSERT。
- 监控对齐：两套链路的延迟、吞吐量、数据质量指标必须统一，否则出了问题你都不知道该查哪边。
- 容灾切换：当实时链路故障时，能平滑切换到批处理链路，保证服务不中断。
核心原则：不要为了架构而架构。混合架构的目的是用最小的成本满足业务需求，而不是把系统搞得更复杂。
3.4 架构选型决策树
讲了这么多，到底怎么选？我整理了一张决策树，你照着走就行。
决策树的逻辑其实很简单：
- 数据准确性要求高 + 团队规模大 → Lambda架构。两套代码虽然重，但各司其职，出了问题好排查。
- 数据准确性要求高 + 团队规模小 → 混合架构（Kappa+批辅助）。主链路用Kappa，定期用批处理做校验修正。
- 数据准确性要求低 + 数据量小于100TB → Kappa架构。纯流处理，简单高效。
- 数据准确性要求低 + 数据量大于100TB → 混合架构（Lambda-Lite）。批处理层用Spark做全量计算，实时层用Flink做增量计算。
个人建议：如果你还在犹豫，我建议从混合架构入手。先搭一个Kappa主链路，跑通核心业务。然后根据实际需求，逐步加入批处理辅助链路。这样风险最小，迭代最快。
3.5 小结
这一章我们聊了三种主流架构：Lambda、Kappa、混合架构。Lambda稳，但重；Kappa轻，但有局限；混合架构灵活，但需要设计好合并逻辑。
架构选型没有标准答案。你想想看，业务场景、团队能力、数据规模、运维成本，这些因素都会影响最终决策。我的建议是：先搞清楚业务的核心诉求，再用决策树做初步筛选，最后通过小规模验证来确认。