📚 课程目录第1章 Flink基础与环境搭建

1. Flink基础与环境搭建：从零开始认识实时计算引擎

大家好，我是你们这门课的老朋友。今天咱们正式开篇，聊聊Flink——这个在实时计算领域几乎成了代名词的框架。

说实话，我最早接触Flink是在2016年，那时候它还是个“小众”项目。记得我第一次在生产环境用Flink跑实时ETL，心里直打鼓。结果呢？稳得一批。从那以后，我再也没换过实时计算引擎。

这一章，咱们把地基打牢。我会带你走一遍Flink的发展脉络、核心特性、能干什么、怎么部署，最后上手玩一下命令行和Web UI。嗯，都是硬货，但我会尽量讲得轻松点。

1.1 Flink发展史：从学术项目到工业标配

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

那时候，柏林工业大学的一群博士生在做“大数据处理系统”的研究。他们搞了个项目叫Stratosphere，这就是Flink的前身。说白了，当时就是想做一个比Hadoop更灵活、性能更好的数据处理框架。

2014年，Stratosphere项目捐给了Apache基金会，正式更名为Flink（德语里是“敏捷”的意思）。同年12月，Flink成为Apache顶级项目。这个速度，在开源界算是坐火箭了。

我印象最深的是2015年，Flink 0.9版本发布，首次引入了DataStream API。那时候大家还在用Storm做实时，Flink一出来，直接降维打击——它原生支持Exactly-Once语义，而Storm只能做到At-Least-Once。你想想看，做金融交易、支付对账，数据重复一次就是事故。Flink这个特性，直接让它成了金融、电商行业的首选。

之后的发展就更快了：

2016年：Flink 1.0发布，标志着API稳定。
2017年：Flink 1.3引入Savepoint机制，做版本升级、集群迁移再也不怕丢状态。
2019年：阿里巴巴宣布开源Blink（基于Flink的增强版），随后合并回Flink 1.9。这次合并带来了Table API & SQL的全面增强，Flink从一个“程序员专属”的工具，变成了数据分析师也能用的平台。
2020年至今：Flink 1.11+ 持续优化，PyFlink、Kubernetes原生支持、流批一体全面落地。

一句话总结：Flink从学术里走出来，用了十年时间，成了实时计算的事实标准。我个人觉得，它的成功不是偶然——设计理念超前，社区活跃，而且一直在解决真实痛点。

1.2 核心特性：为什么大家都在用Flink？

好，咱们聊聊Flink到底牛在哪。我挑几个最核心的讲。

1.2.1 真正的流处理架构

很多框架号称“实时”，但底层其实是微批处理——把数据攒一小批再处理。Flink不一样，它是逐条处理的。每条数据到达，立即触发计算。延迟可以做到毫秒级。

为什么会这样？因为Flink的DataStream API是原生流式设计。它不像Spark Streaming那样需要切分微批次。你想想看，做实时风控，一条欺诈交易晚处理1秒，可能钱就转走了。Flink这种设计，天生适合低延迟场景。

1.2.2 Exactly-Once语义

这个我得多说两句。我在项目中遇到过好几次，因为数据重复导致报表对不上账。后来排查发现，是上游Kafka重发了消息，而下游处理框架没做去重。

Flink通过Checkpoint + 两阶段提交机制，保证了每条数据只处理一次。具体来说：

Flink定期做Checkpoint，把状态快照保存到持久化存储（比如HDFS）。
如果任务挂了，从最近的Checkpoint恢复，重新消费Kafka数据。
配合Kafka的幂等生产者，保证数据不丢不重。

嗯，这里要注意：Exactly-Once不是免费的午餐。它需要上下游系统都支持（比如Kafka、HDFS），而且会带来一定的性能开销。但为了数据准确性，这笔账值得。

1.2.3 流批一体

这个特性，我特别喜欢。以前做数据开发，实时和离线是两套代码、两套引擎。实时用Flink/Storm，离线用Hive/Spark。维护成本高，而且两套逻辑可能不一致。

Flink从1.12开始，流批一体全面成熟。同一套API，既能跑实时流，也能跑离线批。底层引擎自动优化执行计划。说白了，你写一个SQL，Flink自己判断是流模式还是批模式。

我个人习惯：新项目直接上Flink SQL，流批都用它。省心。

1.2.4 状态管理与容错

实时计算里，状态是个大问题。比如你要统计过去1小时的UV，这个“UV值”就是状态。Flink提供了Keyed State和Operator State两种状态类型，支持多种后端存储（内存、RocksDB、HDFS）。

容错方面，Flink的Checkpoint机制是异步、轻量级的。它不会阻塞数据处理。我见过有些框架做容错，一Checkpoint就卡住几秒钟，这在实时场景下是灾难。

避坑指南：我曾经在生产环境遇到过Checkpoint超时的问题。排查后发现是RocksDB的写性能瓶颈。后来调整了RocksDB的缓存大小和线程数，问题解决。所以，状态后端选型一定要根据数据量来，别盲目用内存。

1.3 应用场景：Flink能做什么？

Flink的应用场景，我归纳为四大类。你可以对照自己的业务看看。

场景	典型例子	为什么用Flink
实时ETL	从Kafka消费数据，清洗、转换后写入HBase/ES	低延迟、Exactly-Once保证数据不丢不重
实时风控	检测异常交易、反欺诈	毫秒级延迟，状态管理支持复杂规则
实时数仓	实时OLAP、实时大屏	流批一体，SQL友好，与Hive/Kafka无缝集成
实时推荐	用户行为实时分析、实时特征计算	低延迟、高吞吐，支持复杂事件处理（CEP）

我举个例子。之前帮一家电商公司做实时特征计算，用户每次点击、加购、下单，都要在100ms内更新用户画像特征。Flink消费Kafka里的行为日志，用Keyed State维护每个用户的特征向量，然后实时推送到在线服务。效果很好，双11大促也没出问题。

1.4 集群部署：Standalone / YARN / K8s

部署方式，我建议你根据团队基础设施来选。下面三种我都用过，说说我的感受。

1.4.1 Standalone模式

最简单的方式。适合开发测试或小规模集群。

架构：一个Master节点（JobManager）+ 多个Worker节点（TaskManager）。

部署步骤：

下载Flink安装包，解压。
修改 conf/flink-conf.yaml，配置JobManager和TaskManager的地址。
在Master节点执行 ./bin/start-cluster.sh。
在Worker节点启动TaskManager。

嗯，这里要注意：Standalone模式没有资源隔离。一个任务把CPU打满，其他任务就受影响。生产环境慎用。

1.4.2 YARN模式

如果你公司有Hadoop集群，YARN模式是首选。Flink作为YARN的一个Application运行，资源由YARN统一管理。

两种运行方式：

Session模式：先启动一个Flink集群（JobManager + TaskManager），然后提交多个作业共享资源。适合短作业、小作业。
Per-Job模式：每个作业启动一个独立的Flink集群。作业结束，集群自动释放。适合长作业、大作业。

我个人习惯：生产环境用Per-Job模式。隔离性好，一个作业挂了不影响其他作业。

部署命令示例：

# Per-Job模式提交作业
./bin/flink run -m yarn-cluster \
  -yjm 1024 -ytm 2048 \
  -c com.example.MyJob \
  ./my-flink-job.jar

1.4.3 Kubernetes模式

这是未来的趋势。Flink从1.9开始原生支持K8s。如果你公司已经容器化，强烈推荐。

优势很明显：

弹性伸缩：TaskManager可以根据负载自动扩缩容。
资源隔离：每个TaskManager是一个Pod，资源严格隔离。
运维简单：用Helm Chart一键部署。

部署方式：

Session模式：先部署Flink集群到K8s，再提交作业。
Application模式：作业和集群一起部署，作业结束集群销毁。Flink 1.11+推荐这种方式。

警告：K8s模式虽然好，但学习曲线陡。你需要懂Docker、K8s、Ingress、ConfigMap等概念。我建议先在本机用Minikube练手，再上生产。

1.5 Flink命令行与Web UI入门

部署好集群，咱们来实际操作一下。

1.5.1 命令行工具

Flink的命令行工具是 flink，在 bin/ 目录下。最常用的几个命令：

# 提交作业
./bin/flink run -c com.example.MyJob ./my-job.jar

# 查看正在运行的作业
./bin/flink list

# 取消作业
./bin/flink cancel <job-id>

# 触发Savepoint
./bin/flink savepoint <job-id> [savepoint-path]

# 从Savepoint恢复
./bin/flink run -s <savepoint-path> -c com.example.MyJob ./my-job.jar

嗯，这里有个小技巧：我习惯在 ~/.bashrc 里加个别名 alias flink='/path/to/flink/bin/flink'，省得每次敲全路径。

1.5.2 Web UI

Flink的Web UI默认在 http://<jobmanager-host>:8081。打开后，你会看到：

Dashboard：集群概览，JobManager和TaskManager的状态。
Running Jobs：正在运行的作业列表，点进去可以看到DAG图、算子状态、反压情况。
Completed Jobs：已完成的作业，可以查看历史指标。
Task Managers：每个TaskManager的资源使用情况（CPU、内存、网络）。

我最常用的是反压监控。如果某个算子出现反压（背压），说明下游处理速度跟不上上游。这时候就需要优化算子逻辑或增加并行度。

个人经验：刚接触Flink时，我经常盯着Web UI看作业的DAG图。它能帮你直观理解数据流向。如果DAG图里出现奇怪的“数据倾斜”，多半是KeyBy的key分布不均匀。这时候调整key的哈希策略，或者加一层预聚合，就能解决。

1.6 本章知识体系总览

最后，我用一张SVG图把本章的核心内容串起来。你可以把它当作知识地图，后面学新内容时回来对照。

好了，第一章的内容就到这里。你掌握了Flink的来龙去脉、核心优势、部署选型，还亲手操作了命令行和Web UI。这些基础打牢了，后面学实时特征计算就会轻松很多。