技术选型全景图：Lambda架构 vs Kappa架构，离线与实时引擎选型对比
做事件链路整合，第一个绕不开的问题就是：架构怎么选？引擎用什么？
我记得刚入行那会儿，团队里为了「到底用Lambda还是Kappa」吵了整整两周。后来项目上线，才发现当初的争论其实都集中在「理想情况」上——真正落地的时候，坑全在细节里。
这一章，我就把这两种架构的底牌翻出来，再聊聊离线引擎和实时引擎到底怎么搭。你想想看，选对了架构，后面30%的坑就自动消失了。
2.1 Lambda架构：老牌稳重型选手
Lambda架构是Nathan Marz在2011年提出的。说白了，它就是「批处理+流处理」两条腿走路。
- 批处理层（Batch Layer）：存全量数据，跑离线任务，产出准确结果。
- 速度层（Speed Layer）：处理实时增量，补偿批处理的延迟。
- 服务层（Serving Layer）：合并两边的结果，对外提供服务。
核心思想：用批处理保证准确性，用流处理保证低延迟。两条链路各自独立，最后在服务层合并。
我在项目中遇到过一种典型场景：用户行为分析需要T+1的离线报表，同时又要实时看今日活跃。Lambda架构天然适合——离线用Hive跑全量，实时用Kafka Streams算增量，最后在Redis里合并。嗯，逻辑上很清晰。
但Lambda也有它的痛点：
- 维护两套代码：批处理和流处理的逻辑经常不一致，修一个bug要改两遍。
- 数据合并复杂：服务层要处理「批处理结果覆盖流处理结果」的时序问题。
- 资源浪费：批处理和流处理各占一套集群，成本翻倍。
避坑指南：我曾经在一个项目中，批处理和流处理的聚合逻辑差了0.5%的误差。排查了三天，最后发现是流处理的窗口边界和批处理的日期分区没对齐。所以，两套代码的窗口语义必须完全一致，否则数据对不上。
2.2 Kappa架构：简洁主义的后来者
Kappa架构是Jay Kreps在2014年提出的。它的主张很激进：只用一套流处理引擎，搞定所有事情。
怎么做到的？核心思路是：
- 所有数据都进Kafka（或其他消息队列），存成不可变日志。
- 流处理引擎（如Flink）从Kafka消费数据，实时计算。
- 如果需要重新计算历史数据，就重新消费Kafka里的日志，从头跑一遍。
个人习惯：我建议在Kappa架构中，Kafka的日志保留时间至少设到7天。这样即使逻辑出问题，也能快速回溯重算。如果数据量太大，可以分层存储——热数据在Kafka，冷数据进HDFS，需要时再导回来。
Kappa架构的优点很明显：
- 一套代码：流处理逻辑就是唯一真理，没有批流不一致的问题。
- 运维简单：只需要维护一套集群。
- 实时性强：所有数据天然就是流式的，延迟可控。
但Kappa也不是银弹。我踩过的坑包括：
- 历史数据重算慢：如果Kafka里的数据量太大，重新消费可能要跑几个小时。
- 状态管理复杂：流处理的状态后端（比如RocksDB）如果挂掉，恢复起来很麻烦。
- 不适合大吞吐的批量ETL：纯流处理对大规模数据清洗的支持不如Spark/Hive成熟。
2.3 Lambda vs Kappa：一张表说清楚
| 对比维度 | Lambda架构 | Kappa架构 |
|---|---|---|
| 代码维护 | 两套代码（批+流） | 一套代码（纯流） |
| 数据准确性 | 高（批处理兜底） | 中（依赖流处理语义） |
| 实时性 | 中（速度层延迟低，但合并有开销） | 高（端到端流式） |
| 资源成本 | 高（两套集群） | 低（一套集群） |
| 历史重算 | 容易（离线任务重跑） | 较难（依赖Kafka日志保留） |
| 适用场景 | 离线报表+实时看板混合 | 纯实时链路，数据量可控 |
你想想看，如果你的业务既需要T+1的财务对账，又需要秒级的用户行为分析，Lambda架构更稳妥。但如果你的业务全是实时场景，比如风控、推荐、监控，Kappa架构更清爽。
2.4 离线引擎选型：Hive vs Spark vs Presto
离线引擎的选择，说白了就是看你的数据量和查询模式。
- Hive：老牌离线数仓工具。适合大规模ETL，但查询延迟高（分钟级）。我习惯用它做全量数据的清洗和聚合。
- Spark SQL：内存计算，比Hive快10倍以上。适合复杂的多阶段计算，比如机器学习特征工程。
- Presto/Trino：交互式查询引擎。适合即席分析，但不太适合大规模ETL。
我的选型建议：
- 数据量在TB级以下，用Spark SQL就够了。
- 数据量在PB级，用Hive做ETL，Presto做查询加速。
- 如果团队Spark经验丰富，可以全栈Spark。
2.5 实时引擎选型：Flink vs Spark Streaming vs Kafka Streams
实时引擎的选型，我踩过的坑最多。直接说结论：
| 引擎 | 优势 | 劣势 | 推荐场景 |
|---|---|---|---|
| Flink | 真正的流处理，状态管理强，Exactly-Once语义 | 学习曲线陡，调优复杂 | 复杂事件处理、实时数仓 |
| Spark Streaming | 生态丰富，与Spark批处理无缝衔接 | 微批次架构，延迟在秒级 | 与离线Spark共享集群的场景 |
| Kafka Streams | 轻量级，嵌入应用，无需独立集群 | 功能有限，不适合复杂计算 | 简单的实时ETL、数据路由 |
避坑指南：我曾经在一个项目中用Spark Streaming做实时聚合，结果因为微批次的窗口边界和Kafka的分区分配没对齐，导致数据重复计算。后来换成Flink，用事件时间+Watermark才解决。所以，如果对实时性要求高（秒级以内），直接上Flink，别犹豫。
2.6 架构与引擎的搭配矩阵
最后，我整理了一个搭配矩阵，方便你快速决策：
| 业务场景 | 推荐架构 | 离线引擎 | 实时引擎 |
|---|---|---|---|
| 离线报表+实时看板 | Lambda | Hive/Spark | Flink |
| 纯实时风控 | Kappa | — | Flink |
| 实时数据入湖 | Kappa | — | Kafka Streams |
| 混合数仓（批+流） | Lambda | Spark | Spark Streaming |
嗯，这里要注意：架构和引擎不是绑死的。你完全可以在Lambda架构里用Flink做实时层，用Spark做批处理层。关键是要保证两边的数据语义一致。
2.7 架构选型全景图
下面这张图，我把Lambda和Kappa的核心流程、引擎选型、数据流向都画出来了。你可以把它当作选型时的「速查地图」。
这张图里，我特意把Kafka放在中间——不管选哪种架构，Kafka都是事实上的数据中枢。批处理层和速度层从Kafka消费数据，处理完再写回服务层。Kappa架构则直接砍掉批处理层，所有逻辑都在流处理层完成。
个人经验：我建议刚开始做事件链路整合的团队，先从Lambda架构入手。等流处理能力成熟了，再逐步向Kappa演进。别一上来就搞纯Kappa，万一状态管理出问题，连回退的余地都没有。