3. 实时计算引擎：流处理框架选型
做风控系统，最头疼的是什么？
不是规则怎么写，也不是模型怎么调。而是——数据来了，你能不能接得住、算得快、判得准。
我见过太多团队，离线跑得飞起，一到实时就崩。数据延迟、状态丢失、结果对不上……说白了，就是流处理引擎没选对。
今天咱们就聊聊，实时计算引擎到底怎么选。Flink 和 Spark Streaming，哪个更适合风控场景？事件时间和处理时间到底怎么用？水位线又是个什么鬼？
3.1 流处理框架选型：Flink vs Spark Streaming
先说说我的个人习惯。做风控实时计算，我首选 Flink。为什么？
你想想看，风控场景最核心的需求是什么？低延迟、高吞吐、状态一致性。这三样，Flink 天生就占全了。
| 对比维度 | Flink | Spark Streaming |
|---|---|---|
| 计算模型 | 真正的逐条流处理 | 微批次（Micro-batch） |
| 延迟 | 毫秒级 | 秒级（通常 1-5 秒） |
| 状态管理 | 原生支持，强一致性 | 依赖外部存储，较弱 |
| 事件时间支持 | 原生，完善 | 有限支持 |
| 容错机制 | 分布式快照（Chandy-Lamport） | RDD 血缘 + Checkpoint |
| 风控适用性 | ★★★★★ | ★★★☆☆ |
我在项目中遇到过一件事。有个团队用 Spark Streaming 做实时反欺诈，结果每次数据高峰，延迟就飙到 10 秒以上。风控规则要求 3 秒内出结果，根本扛不住。后来换成 Flink，延迟直接降到 200 毫秒以内。
嗯，这里要注意。不是说 Spark Streaming 不好。如果你的场景对延迟要求不高（比如 5 秒以内都能接受），而且团队 Spark 技术栈已经很成熟，那用 Spark Streaming 也没问题。但风控嘛，每一秒都是钱，我建议还是 Flink 更靠谱。
3.2 事件时间 vs 处理时间
好，框架选完了。接下来要解决一个灵魂拷问：你到底该用哪个时间？
说白了，事件时间是「事情真正发生的时间」，处理时间是「数据到达系统的时间」。这两者，经常不一样。
举个例子。用户凌晨 1 点发起了一笔交易，但网络延迟，数据到 1 点 05 分才进入系统。这时候：
- 事件时间 = 1:00（交易发生的时间）
- 处理时间 = 1:05（数据到达的时间）
你想想看，如果按处理时间算，这笔交易会被归到 1:05 这个窗口。但风控规则是按事件时间来的——凌晨 1 点属于高风险时段，1 点 05 分可能就不是了。结果就是，规则判错了。
所以，风控场景下，事件时间是必须的。处理时间只能用在一些辅助场景，比如监控系统健康度、计算数据到达延迟等。
3.3 水位线机制
说到事件时间，就绕不开水位线。很多人觉得水位线难懂，其实没那么复杂。
水位线，就是告诉系统：到这个时间点了，后面的数据别等了，开始计算吧。
为什么要这个机制？因为数据可能乱序。比如：
- 交易 A：事件时间 1:00，1:02 到达
- 交易 B：事件时间 1:01，1:00 到达（网络快，先到了）
- 交易 C：事件时间 1:02，1:05 到达（网络慢，晚到了）
如果没有水位线，系统会一直等，永远算不出结果。水位线就是「截止时间」——到了这个点，系统认为该来的数据都来了，开始计算。
Flink 里设置水位线很简单：
// 示例：设置水位线，允许 5 秒乱序
DataStream<Transaction> stream = env
.addSource(kafkaConsumer)
.assignTimestampsAndWatermarks(
WatermarkStrategy.<Transaction>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((event, timestamp) -> event.getEventTime())
);这段代码什么意思？就是告诉 Flink：允许数据最多晚到 5 秒。超过 5 秒还没来的数据，对不起，不要了。
3.4 知识体系总览
说了这么多，咱们用一张图把核心逻辑串起来：
这张图把整个逻辑串起来了。从上到下，就是你在做实时风控时必须走完的路径：
- 选框架：Flink 优先，Spark Streaming 备选
- 定时间：事件时间为主，处理时间为辅
- 设水位线：允许乱序，控制延迟
- 开窗口：按事件时间做聚合计算
好了，关于实时计算引擎的核心内容就这些。记住一句话：风控场景，选 Flink、用事件时间、设好水位线。这三步走对了，后面就顺了。