目录
flink架构中使用了Akka来实现底层的分布式通信，而akka是用Scala开发的，所以在引入flink的依赖时也需要指定Scala的版本。
flink系统架构：
批流一体API：
事实上
Flink
本身是流批统一的处理架构，批量的数据集本质上也是流，没有必要用两套不同的 API
来实现。所以从
Flink 1.12
开始，官方推荐的做法 是直接使用 DataStream API
，在提交任务时通过将执行模式设为
BATCH
来进行批处理：
$ bin/flink run -Dexecution.runtime-mode=BATCH BatchWordCount.jar
默认不指定的情况下是流处理。
任务提交流程
1、Flink提交任务后Client向HDFS上传Flink的jar包和配置；
2、Client 之后向Yarn ResourceManager提交任务;
3、ResourceManager分配容器资源并通知对用的NodeManager启动ApplicationMaster；
4、ApplicationMaster启动后加载Flink的jar包和配置构建环境，然后启动JobManager；
5、之后ApplicationMaster向ResourceManager申请资源（用来）启动TaskManager；ResourceManager分配容器资源后由ApplicationMaster加载Flink的jar包和配置构建环境并启动TaskManager；
6、TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
flink部署方式
在一些应用场景中，对于集群资源分配和占用的方式，可能会有特定的需求。
Flink
为各
种场景提供了不同的部署模式，主要有以下三种：
⚫
会话模式（
Session Mode
）
⚫
单作业模式（
Per-Job Mode
）
⚫
应用模式（
Application Mode
）
它们的区别主要在于：集群的生命周期以及资源的分配方式；以及应用的
main
方法到底
在哪里执行——客户端（
Client
）还是
JobManager
。接下来我们就做一个展开说明。
会话模式（Session Mode）
会话模式其实最符合常规思维。我们需要先启动一个集群，保持一个会话，在这个会话中
通过客户端提交作业，如图
3-10
所示。集群启动时所有资源就都已经确定，所以所有提交的
作业会竞争集群中的资源。
这样的好处很明显，我们只需要一个集群，就像一个大箱子，所有的作业提交之后都塞进
去；集群的生命周期是超越于作业之上的，铁打的营盘流水的兵，作业结束了就释放资源，集
群依然正常运行。当然缺点也是显而易见的：因为资源是共享的，所以资源不够了，提交新的
作业就会失败。另外，同一个
TaskManager
上可能运行了很多作业，如果其中一个发生故障导
致
TaskManager
宕机，那么所有作业都会受到影响。
我们在
3.1
节中先启动集群再提交作业，这种方式其实就是会话模式。
会话模式比较适合于单个规模小、执行时间短的大量作业。
单作业模式（Per-Job Mode）
会话模式因为资源共享会导致很多问题，所以为了更好地隔离资源，我们可以考虑为每个
提交的作业启动一个集群，这就是所谓的单作业（
Per-Job
）模式，如图
3-11
所示。
单作业模式也很好理解，就是严格的一对一，集群只为这个作业而生。同样由客户端运行
应用程序，然后启动集群，作业被提交给
JobManager
，进而分发给
TaskManager
执行。作业
作业完成后，集群就会关闭，所有资源也会释放。这样一来，每个作业都有它自己的
JobManager
管理，占用独享的资源，即使发生故障，它的
TaskManager
宕机也不会影响其他作业。
这些特性使得单作业模式在生产环境运行更加稳定，所以是实际应用的首选模式。
需要注意的是，
Flink 本身无法直接这样运行，所以单作业模式一般需要借助一些资源管
理框架来启动集群，比如 YARN、Kubernetes。
应用模式（Application Mode）
前面提到的两种模式下，应用代码都是在客户端上执行，然后由客户端提交给
JobManager
的。但是这种方式客户端需要占用大量网络带宽，去下载依赖和把二进制数据发送给
JobManager
；加上很多情况下我们提交作业用的是同一个客户端，就会加重客户端所在节点的
资源消耗。
所以解决办法就是，我们不要客户端了，直接把应用提交到
JobManger
上运行。而这也就
代表着，我们需要为每一个提交的应用单独启动一个
JobManager
，也就是创建一个集群。这
个
JobManager
只为执行这一个应用而存在，执行结束之后
JobManager
也就关闭了，这就是所
谓的应用模式，如图
3-12
所示。
应用模式与单作业模式，都是提交作业之后才创建集群；单作业模式是通过客户端来提交
的，客户端解析出的每一个作业对应一个集群；而应用模式下，是直接由
JobManager
执行应
用程序的，并且即使应用包含了多个作业，也只创建一个集群。
总结一下，在会话模式下，集群的生命周期独立于集群上运行的任何作业的生命周期，并
且提交的所有作业共享资源。而单作业模式为每个提交的作业创建一个集群，带来了更好的资
源隔离，这时集群的生命周期与作业的生命周期绑定。最后，应用模式为每个应用程序创建一
个会话集群，在
JobManager
上直接调用应用程序的
main()
方法。
我们所讲到的部署模式，相对是比较抽象的概念。实际应用时，一般需要和资源管理平台
结合起来，选择特定的模式来分配资源、部署应用。接下来，我们就针对不同的资源提供者
（
Resource Provider
）的场景，具体介绍
Flink
的部署方式。
独立模式（Standalone）
独立模式（
Standalone
）是部署
Flink
最基本也是最简单的方式：所需要的所有
Flink
组件，
都只是操作系统上运行的一个
JVM
进程。
独立模式是独立运行的，不依赖任何外部的资源管理平台；当然独立也是有代价的：如果
资源不足，或者出现故障，没有自动扩展或重分配资源的保证，必须手动处理。所以独立模式
一般只用在开发测试或作业非常少的场景下。
另外，我们也可以将独立模式的集群放在容器中运行。
Flink
提供了独立模式的容器化部
署方式，可以在
Docker
或者
Kubernetes
上进行部署
会话模式部署
可以发现，独立模式的特点是不依赖外部资源管理平台，而会话模式的特点是先启动集群、
后提交作业。所以，我们在第
3.1
节用的就是独立模式（
Standalone
）的会话模式部署。
单作业模式部署
在
3.2.2
节中我们提到，
Flink
本身无法直接以单作业方式启动集群，一般需要借助一些资
源管理平台。所以
Flink
的独立（
Standalone
）集群并不支持单作业模式部署。
应用模式部署
应用模式下不会提前创建集群，所以不能调用
start-cluster.sh
脚本。我们可以使用同样在
bin
目录下的
standalone-job.sh
来创建一个
JobManager
。
具体步骤如下：
（
1
）进入到
Flink
的安装路径下，将应用程序的
jar
包放到
lib/
目录下。
cp ./FlinkTutorial-1.0-SNAPSHOT.jar lib/
（2）执行以下命令，启动
JobManager
。
./bin/standalone-job.sh start --job-classname com.atguigu.wc.StreamWordCount
这里我们直接指定作业入口类，脚本会到
lib
目录扫描所有的
jar
包。
（3）同样是使用
bin
目录下的脚本，启动
TaskManager
。
./bin/taskmanager.sh start
（4）如果希望停掉集群，同样可以使用脚本，命令如下。
./bin/standalone-job.sh stop./bin/taskmanager.sh stop
1、flink集群启动方式
进入到 Flink 的安装路径下，在命令行使用 flink run 命令提交作业。
bin/flink run-m hadoop102:8081 -c com.atguigu.wc.StreamWordCount ./FlinkTutorial-1.0-SNAPSHOT.jar
这里的参数 –m 指定了提交到的 JobManager，-c 指定了入口类。
在浏览器中打开
Web UI
，
http://hadoop102:8081
查看应用执行情况，如图
3-9
所示。
在
log
日志中，也可以查看执行结果，需要找到执行该数据任务的
TaskManager
节点
查看日
