2、离线架构基石：Lambda架构与Kappa架构的对比，数据湖与数据仓库的选择。
好，咱们进入第二章。这一章聊的是离线架构的基石。说白了，就是决定你整个推荐系统的数据底座怎么搭。
我见过不少团队，一上来就追新架构，结果数据对不上，修修补补大半年。所以这一章，咱们把Lambda和Kappa掰开揉碎，再把数据湖和数据仓库的账算清楚。
2.1 Lambda架构：经典但有点“重”
Lambda架构，我最早接触是在2015年。那时候做电商推荐，用户行为数据量突然暴增，传统的单机处理根本扛不住。
Lambda的核心思路很简单：批处理层 + 速度层 + 服务层。
- 批处理层：处理全量历史数据。用Spark、MapReduce这类工具，跑T+1的离线任务。产出全量特征和模型。
- 速度层：处理实时增量数据。用Flink、Storm这类流引擎，补偿批处理的延迟。产出实时特征和近线模型。
- 服务层：把批处理和速度层的结果合并，对外提供统一的查询接口。
听起来很完美对吧？但我在项目中遇到过一个大坑：数据一致性问题。
批处理层算出的用户点击率是0.35，速度层因为窗口设置不同，算出来是0.38。服务层合并时，到底信谁的？
所以Lambda架构虽然经典，但维护成本高。你得维护两套代码（批处理和流处理），还得处理结果合并的逻辑。说白了，就是逻辑重复，运维复杂。
2.2 Kappa架构：简化，但有前提
Kappa架构，是Lambda的“瘦身版”。它只保留速度层，用流处理引擎统一处理所有数据。
你可能会问：“那历史数据怎么办？”
答案是：重放。把历史数据当成流数据，重新从Kafka里读一遍。Kappa架构的核心思想是：一切皆流。
我建议你在以下场景考虑Kappa：
- 数据源本身就是流式的（比如用户点击日志、实时曝光）
- 历史数据量不大，重放成本可控
- 团队对Flink这类流引擎非常熟悉
但Kappa也有硬伤。我记得有一次，我们需要回溯三个月的历史数据来重新训练模型。如果用Kappa，就得把三个月的Kafka消息全部重放一遍。Kafka的存储成本、重放时间，都让人头疼。
2.3 Lambda vs Kappa：一张表说清楚
| 对比维度 | Lambda架构 | Kappa架构 |
|---|---|---|
| 数据处理方式 | 批处理 + 流处理 | 纯流处理 |
| 代码维护 | 两套代码（批+流） | 一套代码（流） |
| 数据一致性 | 容易出问题，需合并逻辑 | 天然一致，但依赖重放 |
| 历史回溯 | 方便，直接跑批任务 | 成本高，需重放Kafka |
| 运维复杂度 | 高 | 中 |
| 适用场景 | 复杂ETL、频繁回溯 | 实时推荐、简单ETL |
嗯，这里要注意：没有银弹。选哪个，取决于你的团队能力和业务特点。
2.4 数据湖 vs 数据仓库：存储选型
聊完架构，咱们看看数据存哪。数据湖和数据仓库，这两个概念经常被混淆。
数据仓库，我习惯叫它“整理好的衣柜”。数据进来之前，已经规划好了分区、格式、Schema。查询快，但灵活性差。适合结构化数据，比如订单表、用户表。
数据湖，更像“杂物间”。什么数据都能往里扔，原始格式、半结构化、非结构化都行。查询慢，但灵活。适合存原始日志、图片、文本。
在推荐系统里，我建议这样分工：
- 数据湖：存原始行为日志（点击、曝光、停留时长）。这些数据量大、格式杂，但价值高。用HDFS或S3做底层存储，格式用Parquet或ORC。
- 数据仓库：存清洗后的特征表、标签表、模型训练样本。这些数据需要快速查询，支持复杂的JOIN和聚合。用Hive、ClickHouse或Doris。
2.5 实战中的选择建议
说了这么多，到底怎么选？我给出一个简单的决策树：
- 团队规模小，实时要求高：选Kappa + 数据湖。用Flink处理一切，数据存HDFS。简单粗暴。
- 团队成熟，历史数据重要：选Lambda + 数据湖 + 数据仓库。批处理用Spark，流处理用Flink，数据湖存原始日志，数据仓库存特征。
- 预算有限，不想维护两套：选Kappa，但要做好Kafka的容量规划。我曾经因为Kafka磁盘写满，导致数据丢失，教训深刻。
你想想看，架构选型其实没有绝对的对错。关键是匹配你的业务阶段和团队能力。别为了追新而选Kappa，也别因为保守而死守Lambda。
最后，分享一个我个人的经验：先跑通，再优化。不管选哪种架构，先把端到端的数据链路跑通。哪怕用最简单的Lambda + Hive，也比纸上谈兵强一百倍。
好，这一章就到这里。下一章咱们聊聊实时特征计算，那是推荐系统的“临门一脚”。