1、流式计算基础：流式计算概念、与批处理的区别、Lambda架构与Kappa架构
大家好，我是你们的老朋友。今天咱们正式开讲《流式计算在推荐系统中的落地实战》的第一章。
说实话，做了这么多年推荐系统，我最大的感触就是：数据是有生命的。你想想看，用户点一下、滑一下、停留几秒，这些行为转瞬即逝。如果你不能立刻抓住，它就永远消失了。这就是流式计算要解决的核心问题。
1.1 流式计算到底是什么？
流式计算，说白了就是数据一边产生，一边处理。
我习惯用一个比喻来解释：批处理像是去水库打水，攒够一桶再提回来；流式计算呢，就像接了一根水管，水龙头一开，水就源源不断地流进来，你随时可以接一杯喝。
在推荐系统里，用户的行为日志就是这根水管里的水。每次点击、每次滑动、每次加购，都是一个个独立的事件。流式计算要做的，就是在毫秒级或秒级内把这些事件处理完，然后更新用户的兴趣画像。
核心特征：
- 低延迟：数据到达即处理，不等待
- 无界数据：数据源源不断，没有终点
- 持续计算：计算引擎7×24小时运行
- 状态管理：需要维护中间计算结果
嗯，这里要注意一点。流式计算不是简单的「来一条处理一条」。我在项目中遇到过，有些同学把流式计算理解成逐条处理，结果窗口聚合、状态回溯这些功能全用错了。流式计算是有时间语义和窗口概念的，后面我们会详细讲。
1.2 流式计算 vs 批处理：到底差在哪？
很多新手会问：我直接用批处理，每5分钟跑一次不行吗？
行，当然行。但你要看场景。
| 对比维度 | 批处理 | 流式计算 |
|---|---|---|
| 数据范围 | 有界（固定数据集） | 无界（持续流入） |
| 延迟要求 | 分钟级~小时级 | 毫秒级~秒级 |
| 计算模型 | 全量计算 | 增量计算 |
| 容错机制 | 重跑整个任务 | 基于Checkpoint恢复 |
| 典型场景 | 离线报表、模型训练 | 实时推荐、风控、监控 |
我举个例子你就明白了。假设用户刚点了一个「篮球鞋」的链接，你希望下一秒推荐列表里就出现相关商品。如果用批处理，等5分钟后的调度任务跑完，用户可能已经滑走了。这就是为什么实时推荐必须用流式计算。
我的经验：不要盲目追求「全实时」。我见过很多团队，明明业务允许1分钟延迟，非要上毫秒级方案，结果运维成本翻了好几倍。选型前，先问自己：业务到底能容忍多少延迟？
1.3 Lambda架构：批流一体的「过渡方案」
说到流式计算，就绕不开Lambda架构。这个架构是Nathan Marz提出来的，核心思想很简单：用两条路走，最后合并结果。
一条是批处理路径，处理全量历史数据，保证准确性；另一条是流处理路径，处理实时增量数据，保证低延迟。最后在服务层把两条路径的结果合并。
Lambda架构的三层：
- 批处理层（Batch Layer）：存储全量数据，定期计算离线视图
- 流处理层（Speed Layer）：处理实时数据，生成实时视图
- 服务层（Serving Layer）：合并批视图和实时视图，对外提供服务
说实话，Lambda架构在2015年左右非常火。我当时参与的一个电商推荐项目，就是用Lambda架构搭的。批处理用Hive/Spark，流处理用Storm，服务层用HBase。
但用着用着，问题就来了。
我曾经踩过的坑：
- 维护两套代码：批处理和流处理的逻辑要写两遍，改一个业务逻辑要同步修改两个地方
- 结果不一致：批处理和流处理的窗口语义不同，合并时经常出现数据对不上的情况
- 运维成本高：同时维护两套集群，出问题时排查链路特别长
我记得有一次，线上推荐结果突然出现大量重复商品。排查了整整两天，最后发现是批处理层的T+1数据和流处理层的实时数据在合并时，时间窗口没对齐。从那以后，我就开始琢磨：有没有更简单的方案？
1.4 Kappa架构：用一条流搞定所有
Kappa架构是Jay Kreps（Kafka的作者）提出来的。他的想法很直接：既然流处理这么麻烦，那干脆所有数据都走流处理。
核心思路是：把批处理看作流处理的一个特例。历史数据通过Kafka等消息队列重新回放，用同一个流处理引擎处理。这样就不需要维护两套代码了。
Kappa架构的关键点：
- 统一引擎：所有数据都用流处理引擎（如Flink）处理
- 数据重放：历史数据通过Kafka重新消费，实现全量计算
- 状态回溯：利用Checkpoint和Savepoint实现时间旅行
你想想看，这多清爽。一套代码、一个引擎、一个运维体系。我在后来的项目中，基本都转向了Kappa架构。特别是Flink成熟以后，它的状态管理和Exactly-Once语义让Kappa架构真正变得可用。
但Kappa架构也不是银弹。它有个前提：你的消息队列要能保存足够长的历史数据。Kafka的默认保留时间是7天，如果你要回溯30天的数据，就得调整配置或者用分层存储。
我的建议：如果你们的业务对历史数据回溯要求不高（比如只回溯3-7天），直接用Kappa架构。如果需要回溯几个月甚至更久，可以考虑Lambda架构，或者用Kappa架构+离线存储的混合方案。
1.5 怎么选？我的一点心得
说了这么多，到底选Lambda还是Kappa？
我个人习惯这样判断：
- 团队技术栈单一（比如全是Java/Scala），且历史数据回溯需求不大 → 选Kappa
- 团队有成熟的批处理体系，且需要频繁回溯大量历史数据 → 选Lambda
- 从零开始搭建 → 优先考虑Kappa，实在不行再退回到Lambda
我记得2018年帮一个创业公司搭推荐系统，他们只有3个后端开发。我果断选了Kappa架构+Flink+Kafka，一个月就上线了实时推荐功能。要是用Lambda，光维护两套代码就能把他们累死。
好了，第一章就讲到这里。下一章我们聊聊流式计算的时间语义和窗口机制，这可是面试必问、实战必用的硬核内容。咱们下期见。