1. Flink概述与调度系统简介

各位同学好，我是老张。今天咱们开始这门课的第一章。说实话，Flink 这个词在圈子里已经火了好几年了，但很多人对它的理解还停留在「一个流计算框架」的层面。嗯，这没错，但不够。

我最早接触 Flink 是在 2018 年，那时候公司要上一套实时数仓，选型时在 Spark Streaming 和 Flink 之间纠结了很久。后来踩了不少坑，才真正体会到 Flink 的设计哲学。今天我就把这几年的心得掰开了讲给你听。

1.1 Flink到底是什么？

Flink，全称 Apache Flink，是一个分布式、高性能、有状态的流处理框架。说白了，它就是用来处理「源源不断产生的数据」的。

你想想看，传统的批处理框架，比如 MapReduce，是把数据攒成一堆再算。但 Flink 不一样——数据来一条，它处理一条，延迟能做到毫秒级。

我记得有一次做风控项目，业务方要求延迟不能超过 200 毫秒，而且数据偶尔会乱序。当时用 Spark Streaming 的微批方案，延迟死活压不下来。换成 Flink 的事件时间 + 精确一次，问题直接解决。嗯，从那以后我就成了 Flink 的铁粉。

1.2 为什么需要调度系统？

好，现在你有了 Flink 任务。但问题来了——这个任务跑在哪？谁来分配资源？挂了怎么办？

这就引出了调度系统。我个人习惯把调度系统比作「数据工厂的车间主任」：

• 它决定任务在哪个机器上跑
• 它负责分配 CPU、内存、磁盘
• 它监控任务健康，挂了就重启
• 它管理多租户，防止互相抢资源

没有调度系统，你只能手动部署 Flink 任务。我早期带团队时干过这事——每台机器手动配环境、手动启停、出问题手动排查。结果呢？凌晨三点被电话叫醒是常态。后来上了 YARN，世界清净多了。

1.3 Flink on YARN / K8s / Mesos 架构对比

目前主流的调度系统有三类：YARN、Kubernetes（K8s）、Mesos。我三个都用过，下面给你讲讲它们的区别。

1.3.1 Flink on YARN

YARN 是 Hadoop 生态的老牌调度器。Flink 跑在 YARN 上，说白了就是把资源申请交给 YARN 的 ResourceManager 去管。

工作流程：

1. 客户端提交 Flink 作业到 YARN
2. YARN 分配一个 Container 启动 ApplicationMaster
3. ApplicationMaster 再向 YARN 申请 TaskManager 的 Container
4. TaskManager 启动后，JobManager 分配任务

我习惯用 YARN 做离线 + 实时混部。因为公司 Hadoop 集群本来就搭好了，直接复用，省心。

1.3.2 Flink on Kubernetes

K8s 是云原生的调度标准。Flink on K8s 有两种模式：

• Session 模式：先起一个 Flink 集群，再往里面提交作业
• Job 模式：每个作业独立起一个集群，用完就销毁

我个人更推荐 Job 模式。为什么？资源隔离性好，一个作业挂了不影响别的。我在做实时数仓时，几十个 Flink 任务跑在 K8s 上，每个任务独立 Pod，互不干扰。

1.3.3 Flink on Mesos

Mesos 现在用得少了，但老项目里还有。它的特点是两级调度：Mesos 管资源，Flink 管任务。不过社区已经不活跃了，新项目不建议选。

架构对比表

维度	YARN	Kubernetes	Mesos
资源粒度	Container	Pod	Container
弹性伸缩	手动	自动（HPA）	手动
社区活跃度	成熟稳定	最活跃	已衰退
学习成本	低	中高	中
适用场景	Hadoop 生态	云原生	遗留系统

1.4 三种架构的核心流程图

下面这张图是我自己画的，帮你理清三种架构的核心流程。你仔细看，重点在资源申请和任务调度这两步。

1.5 怎么选？我的实战建议

说了这么多，到底选哪个？我根据实际项目经验给你几个判断标准：

• 公司技术栈：如果已经是 Hadoop 生态，YARN 最省事。如果是云原生路线，K8s 是唯一选择。
• 团队能力：YARN 上手快，K8s 需要懂容器化、网络、存储，学习曲线陡一些。
• 运维成本：YARN 相对成熟稳定，K8s 版本迭代快，升级要注意兼容性。
• 弹性需求：流量波动大的场景，K8s 的自动伸缩是杀手锏。