📚 课程目录第1章 Flink基础入门

1. Flink基础入门：发展历史、核心特性、应用场景与Spark Streaming对比

各位同学好，我是老张。做实时计算这些年，从Storm到Spark Streaming再到Flink，算是亲眼看着这个领域一步步成熟起来的。今天咱们先聊聊Flink的来龙去脉，以及它凭什么能在实时计算领域站稳脚跟。

Flink的故事得从2010年说起。那时候柏林工业大学有个研究项目，叫"Stratosphere"——说白了就是做大数据分析的基础研究。我2014年刚接触它时，这玩意儿还叫Stratosphere，社区小得可怜。

2014年，Stratosphere的代码被捐给了Apache软件基金会，正式更名为Flink。嗯，这个名字挺有意思——德语里"Flink"是敏捷、灵巧的意思。同年12月，Flink成为Apache顶级项目。

真正让Flink火起来的，是2015年那场著名的"Flink Forward"大会。我记得当时阿里的人上台分享，说他们用Flink替换了Storm，性能提升了好几倍。从那以后，Flink在国内的势头就一发不可收拾。

2019年，阿里巴巴收购了Flink的母公司Data Artisans，随后开源了Blink——也就是阿里内部基于Flink改造的版本。Flink 1.9版本合并了Blink的大量特性，批流一体正式成为现实。

到现在，Flink已经发展到1.18版本，社区活跃度在Apache项目中排前三。我个人的感觉是，Flink已经从一个"实时计算引擎"进化成了"统一的数据处理平台"。

关键时间节点：

Flink凭什么能后来居上？我总结了几个核心特性，你品品。

Spark Streaming其实是个"微批"——把流切成小批次，每个批次当成离线任务跑。Flink不一样，它是真正的逐条处理。每条数据来了，立即处理，延迟在毫秒级。

为什么会这样？因为Flink的设计哲学就是"流是本质，批是特例"。它把批处理看作"有界流"，用同一套引擎跑。我在项目中遇到过很多场景，用Spark Streaming做秒级延迟的监控，总是差那么点意思，换成Flink后问题迎刃而解。

做实时计算最怕什么？数据丢或者重复。Flink通过分布式快照（Checkpoint）机制，保证了精确一次语义。说白了，就是每条数据恰好被处理一次，不多不少。

我曾经帮一个金融客户做风控系统，数据重复意味着重复扣款，那问题就大了。Flink的Checkpoint机制配合Kafka的幂等写入，完美解决了这个问题。

这个特性太重要了。很多场景下，数据到达时间和事件发生时间不是一回事。比如用户凌晨1点下单，但因为网络延迟，3点才到系统。如果按处理时间算，这笔订单就算到3点了，明显不对。

Flink支持事件时间语义，配合Watermark机制，能正确处理乱序数据。我建议你在做时间相关的统计时，优先用事件时间。

Flink把状态管理做到了极致。它提供了多种状态后端——内存、RocksDB、文件系统。状态可以自动保存和恢复，节点挂了也不怕。

我记得有一次线上集群一台机器宕机，Flink自动把任务迁移到其他节点，状态从Checkpoint恢复，整个过程不到30秒，业务几乎无感知。

避坑指南：状态大小要控制好。我曾经见过有人把全量用户画像存到状态里，结果RocksDB撑爆了磁盘。建议定期清理过期状态，或者用TTL自动过期。

Flink能干什么？我列几个典型的场景，你看看是不是你正在做的。

我最近做的一个项目，就是用Flink CDC实时同步MySQL数据到ClickHouse。以前用Canal+Kafka+Spark Streaming，链路长、维护成本高。换成Flink CDC一条链路搞定，代码量减少了一半。

这个问题面试必问，也是选型时必须想清楚的。我直接上对比表。

说说我的个人经验。如果你的场景对延迟要求不高（秒级可以接受），而且团队Spark技术栈很成熟，用Spark Streaming完全没问题。但如果你要做毫秒级风控、实时数仓、CDC同步这些场景，Flink是更好的选择。

注意：不要盲目追新。我见过有人为了用Flink而用Flink，结果团队没人会调优，线上频繁OOM。选型要考虑团队能力、运维成本和业务需求。

最后，咱们用一张图看看Flink的整体架构。这张图我画了很多遍，每次给新人培训都用它。

这张图展示了Flink的核心架构。数据从各种Source流入，经过Flink集群处理，最终输出到各种Sink。JobManager是大脑，TaskManager是工人，状态后端是记忆。三者配合，实现了高吞吐、低延迟、强一致性的实时计算。

好了，第一章就到这里。Flink的基础概念先有个印象，后面我们会一步步深入，从环境搭建到实战项目，把每个知识点都吃透。