Flink运行模式

    在idea中运行Flink程序的方式就是开发模式。

    Flink中的Local-cluster(本地集群)模式,单节点运行，主要用于测试, 学习。

        独立集群模式，由Flink自身提供判差计算资源。

把Flink应用提交给Yarn的ResourceManager

Flink会根据运行在JobManger上的job的需要的slot的数量动态的分配TaskManager资源

Yarn又分3种模式

Session-Cluster模式需要先启动Flink集群，向Yarn申请资源。以后提交任务都向这里提交。

这个Flink集群会常驻在yarn集群卖磨中，除非手工停止。

在向Flink集群提交Job的时候, 如果资源被用完了,则新的Job不能正常提交.

缺点: 如果提交的作业中有长时间执行的大作业, 占用了该Flink集群的所有资源, 则后续无法提交新的job.

所以, Session-Cluster适合那些需要频繁提交的多个小Job, 并且执行时间都不长的Job.

一个Job会对应一个Flink集群，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享Dispatcher和ResourceManager，按需接受资源申请；适合规模大长时间运行的作业。

每次提交都会创建一个新的flink集群，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。

Per-job模式执行结果，一个job对应一个Application

Application Mode会在Yarn上启动集群, 应用jar包的main函数(用户类的main函数)将会在JobManager上执行. 只要应用程序执行结束, Flink集群会马上被关闭. 也可以手动停止集群.

与Per-Job-Cluster的区别：就是Application Mode下, 用户的main函数式在集群中执行的，并且当一个application中有多个job的话，per-job模式则是一个job对应一个yarn中的application，而Application Mode则这个application中对应多个job。

Application Mode模式执行结果，多个job对应一个Application

官方建议:

出于生产的需求, 我们建议使用Per-job or Application Mode,因为他们给应用提供了更中冲斗好的隔离!

https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/

0．Flink任务提交后，Client向HDFS上传Flink的Jar包和配置

1．向Yarn ResourceManager提交任务，ResourceManager分配Container资源

2．通知对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager（Dispatcher）

2.1．Dispatcher启动JobMaster

3．JobMaster向ResourceManager（Flink）申请资源

4．ResourceManager（Flink）向ResourceManager（Yarn）申请资源启动TaskManager

5．ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager

6．TaskManager注册Slot

7．发出提供Slot命令

8．TaskManager向JobMaster提供Slot

9．JobMaster提交要在Slot中执行的任务

Flink是一个基于流计算的分布式引擎，以前的名字叫stratosphere，从2010年开始在德国一所大学里发起，也是有好几年的 历史 了，2014年来借鉴了社区其它一些项目的理念，快速发展并且进入了Apache顶级孵化器，后来更名为Flink。

Flink在德语中是快速和灵敏的意思 ，用来体现流式数据处理速度快和灵活性强等特点。

Flink提供了同时支持高吞吐、低延迟和exactly-once 语义的实时计算能力，另外Flink 还提供了基于流式计算引擎困兄处理批量数据的计算能力，困好真正意义上实现了流批统一。

Flink 独立于Apache Hadoop，且能在没有任何 Hadoop 依赖的情况下运行。

但是，Flink 可以很好的集成很多 Hadoop 组件，例如 HDFS、YARN 或 HBase。 当与这些组件一起运行时，Flink 可以从 HDFS 读取数据，或写入结果和检查点（checkpoint）/快照（snapshot）数据到 HDFS 。 Flink 还可以通过 YARN 轻松部署，并与 YARN 和 HDFS Kerberos 安全模块集成。

Flink具有先进的架构理念、诸多的优秀特性，以及完善的编程接口。

Flink的具体优势有如下几点：

（1）同时支持高吞吐、低延迟、高性能；

（2）支持事件时间（Event Time）概念；

事件时间的语义使流计算的结果更加精确，尤其在事件到达无序或者延迟的情况下，保持了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响。

（3）支持有状态计算；

所谓状态就是在流计算过程中，将算子的中间结果数据保存在内存或者文件系统中，等下一个事件进入算子后，可以从之前的状态中获取中间结果，计算当前的结果，从而无需每次都基于全部的原始数据来统计结果。

（4）支持高度灵活的窗口（Window） *** 作；

（5）基于轻量级分布式快照（Snapshot）实现的容错；

（6）基于JVM实现独立的内存管理；

（7）Save Points（保存点）；

保存点是手动触发的，触发时会将它写入状态后端（State Backends）。Savepoints的实现也是依赖Checkpoint的机制。Flink 程序在执行中会周期性的在worker 节点上进行快照并生成Checkpoint。因为任务恢复的时候只需要最后一个完成的Checkpoint的，所以旧有的Checkpoint会在新的Checkpoint完成时被丢弃。Savepoints和周期性的Checkpoint非常的类似，只是有两个重要的不同。一个是由用户触发，而且不会随着新的Checkpoint生成而被丢弃。

在Flink整个软件架构体系中，统一遵循了分层的架构设计理念，在降低系统耦合度的同时，为上层用户构建Flink应用提供了丰富且友好的接口。

整个Flink的架构体系可以分为三层：

Deployment层： 该层主要涉及了Flink的部署模式，Flink支持多种部署模式：本地、集群（Standalone/YARN），云（GCE/EC2），Kubernetes等。

Runtime层：Runtime层提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、JobGraph到ExecutionGraph的映射、调度等等，为上层API层提供基础服务。

API层： 主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向汪尺铅批处理对应DataSet API。

Libraries层：该层也可以称为Flink应用框架层，根据API层的划分，在API层之上构建的满足特定应用的计算框架，也分别对应于面向流处理和面向批处理两类。

核心概念：Job Managers，Task Managers，Clients

Flink也是典型的master-slave分布式架构。Flink的运行时，由两种类型的进程组成：

Client: Client不是运行时和程序执行的一部分，它是用来准备和提交数据流到JobManagers。之后，可以断开连接或者保持连接以获取任务的状态信息。

当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager， JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。 TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。

每个Worker(Task Manager)是一个JVM进程，通常会在单独的线程里执行一个或者多个子任务。为了控制一个Worker能够接受多少个任务，会在Worker上抽象多个Task Slot (至少一个)。

只有一个slot的TaskManager意味着每个任务组运行在一个单独JVM中。 在拥有多个slot的TaskManager上，subtask共用JVM，可以共用TCP连接和心跳消息，同时可以共用一些数据集和数据结构，从而减小任务的开销。

Flink的任务运行其实是多线程的方式，这和MapReduce多JVM进程的方式有很大的区别，Flink能够极大提高CPU使用效率，在多个任务之间通过TaskSlot方式共享系统资源，每个TaskManager中通过管理多个TaskSlot资源池对资源进行有效管理。

---