4、Flink入门：Flink发展史、Flink核心特性、Flink应用场景

好，咱们开始聊Flink。这一章算是整个课程的基石。

说实话，在流式计算这个领域，Flink现在几乎是绕不开的存在。我最早接触流式计算的时候，用的还是Storm，后来Spark Streaming火了一阵子。但真正让我觉得「嗯，这东西靠谱」的，还是Flink。为什么？因为它把「流」这件事想得特别透彻。

4.1 Flink发展史：从学术到工业的蜕变

Flink的故事，得从2010年说起。

那时候，柏林工业大学的一个研究团队，搞了个项目叫「Stratosphere」。这名字听着挺科幻，其实就是Flink的前身。他们的目标很纯粹：做一个能同时处理批处理和流处理的统一计算引擎。

2014年，Stratosphere项目中的流处理核心被分离出来，捐赠给了Apache软件基金会，正式更名为Flink。Flink这个名字，德语里是「敏捷、灵巧」的意思。嗯，确实很贴切。

我印象很深的是，2015年左右Flink开始在国内冒头。那时候阿里、美团这些大厂已经开始尝试用Flink替换掉老旧的Storm集群。我记得有个朋友跟我吐槽，说他们Storm的拓扑一挂，状态全丢，恢复起来要命。而Flink的「精确一次」语义和状态恢复机制，简直就是救星。

到了2019年，Flink已经成为Apache软件基金会的顶级项目。社区活跃度、版本迭代速度，都相当惊人。现在，Flink 1.20都出来了，生态也越来越完善。

4.2 Flink核心特性：事件驱动与有状态计算

Flink最核心的两个特性，我理解就是「事件驱动」和「有状态计算」。这两个东西，说白了就是Flink的魂。

4.2.1 事件驱动

什么叫事件驱动？你想想看，传统的处理方式，是把数据一批一批拉过来，然后统一处理。而事件驱动，是来一条数据，就处理一条。每条数据都是一个独立的事件。

举个例子。你在淘宝上点了个「加入购物车」，这就是一个事件。Flink收到这个事件，立刻更新你的购物车状态，然后可能触发推荐、库存扣减等一系列动作。整个过程是实时的，不需要等凑够一批数据再处理。

我个人习惯把事件驱动理解为「随到随处理」。这种模式的好处很明显：延迟低、响应快。在推荐系统里，用户的行为是实时发生的，你不可能等用户刷了10条视频再给他推荐，对吧？

4.2.2 有状态计算

这个特性，我觉得是Flink最牛的地方。

很多流处理框架，处理完一条数据就忘了。但Flink不一样，它记得。它可以在内存或磁盘里维护一个「状态」，比如用户最近10次点击的商品ID、过去5分钟的滑动窗口平均值等等。

为什么会需要状态？你想想看，推荐系统里，你要判断「用户是否已经看过这个商品」，你得记住用户的历史行为吧？这就是状态。

Flink的状态管理做得特别细致。它支持多种状态后端（比如RocksDB、HashMap），还提供了精确一次的状态一致性保证。就算任务挂了，重启后状态也能恢复，不会丢数据，也不会重复计算。

// 一个简单的有状态计算示例
// 统计每个用户过去5分钟的点击次数
DataStream<ClickEvent> clicks = ...;

clicks
    .keyBy(event -> event.getUserId())
    .window(TumblingProcessingTimeWindows.of(Time.minutes(5)))
    .aggregate(new CountAggregate())
    .print();

4.3 Flink应用场景：不只是推荐系统

Flink的应用场景其实非常广。我简单列几个常见的：

当然，咱们这门课主要聚焦在推荐系统。但你要知道，Flink的能力远不止于此。我见过有人用Flink做实时数仓，每天处理几百亿条数据，稳得很。

4.4 小结

这一章，咱们聊了Flink的来龙去脉，也聊了它最核心的两个特性：事件驱动和有状态计算。说白了，Flink就是为「实时」而生的。它让你能像处理批数据一样，优雅地处理流数据。

下一章，咱们会动手搭建Flink开发环境，写第一个Flink程序。到时候你就知道，这东西用起来有多顺手了。