flink

物理部署层  
负责解决Flink的部署模式问题
支持多种部署模式：本地部署，集群部署，云以及kubernetes
通过该层支持不捅平台的部署，用户可以更具自身场景和需求选择使用对应的部署模式
RUntime核心层
是FIlnk分布式计算框架的核心实现层，负责对上层不同接口提供基础服务
支持分布式Stream'作业的执行，JobGraph到ExecutionGraph的映射转换以及任务调度等
将DataStream和DataSet转成同意的可执行的TaskOperator，达到在流式计算引擎下同时处理批数量计算和流式计算的目的
 
API和Libraries层
负责更好的开发用户体验，包括易用性，开发效率，执行效率，状态管理等方面
Flink同事提供平了支撑流计算和批处理的接口，同事在这基础上抽象出不同的应用类型的组件库
基于流处理的CEP（Complex Event Process,复杂事 件处理库） Table & Sql库 基于批处理的FlinkML（机器学习库） 图处理库(Gelly) API层包括两部分 流计算应⽤的DataStream API 批处理应⽤的DataSet API
统⼀的API，⽅便⽤于直接操作状态和时间等底层数据 提供了丰富的数据处理⾼级API，例如Map、 FllatMap操作等， 并提供了⽐较低级的Process Function API
1.运行模式

运模模式核⼼区分点 集群⽣命周期和资源隔离保证 应⽤程序的main()⽅法是在客户端还是在集群上执⾏

所有模式分类说明 ：本地运⾏模式-local standalone模式-独⽴Flink集群 集群运⾏模式 经常是指flink on yarn集群模式，yarn也可以换成 mesos,Kubernetes(k8s)等资源管理平台替换。

共3种： se ssion模式 per-job模式 application模式

本地运行：

运行过程，一个机器启动一个进程的多线程来模拟分布式计算

主要用于代码测试

srandalone模式：

运行过程：完全独立的Flink集群的模式，各个环节均FLink自己搞定，并没有yarn，mesos的同意资源调度平台

主要是只有纯FLink计算的场景，商用场景极少

集群运行模式：

FlinkSEssion集群（会话模式）

集群生命周期：

在Flink Session集群中，客户端连接到以个预先存在的，长期运行的集群，该集群可以接收多个作业提交。即使所有作业完成后，集群（和 JobManager） 仍将继续运⾏直到⼿动停⽌ session 为⽌。因此， Flink Session 集群的寿命不受任何 Flink 作业寿命的 约束。

资源隔离： TaskManager slot 由 ResourceManager 在提交作业 时分配，并在作业完成时释放。由于所有作业都共享 同⼀集群，因此在集群资源⽅⾯存在⼀些竞争 — 例如 提交⼯作阶段的⽹络带宽。此共享设置的局限性在 于，如果 TaskManager 崩溃，则在此 TaskManager 上运⾏ task 的所有作业都将失败；再⽐如，如果 JobManager 上发⽣⼀些致命错误，它将影响集群中 正在运⾏的所有作业。

其他注意事项： 拥有⼀个预先存在的集群可以节省⼤量时间申请资源 和启动 TaskManager。这种场景很重要，作业执⾏时 间短并且启动时间⻓会对端到端的⽤户体验产⽣负⾯ 的影响 — 就像对简短查询的交互式分析⼀样，希望作 业可以使⽤现有资源快速执⾏计算。 Flink Session 集群也被称为 session 模式下的 Flink 集 群。

⼯作模式 附加模式（默认） 特点 客户端与Flink作业集群相互同步 细节描述 yarn-session.sh客户端将 Flink 集群提交给 YARN，但客户端保持运⾏，跟踪集群的状态。 如果集群失败，客户端将显示错误。如果客户端 被终⽌，它也会通知集群关闭。 分离模式（-d或--detached） 特点 客户端与Flink作业集群相互异步，客户端提交 完成后即可退出 细节描述 yarn-session.sh客户端将Flink集群提交给YARN，然后客户端返回。 需要再次调⽤客户端或 YARN ⼯具来停⽌ Flink 集群。

⼯作流程特征说明 多个不同的FlinkJob向同⼀个Flink Session会话上提 交作业，由这⼀个统⼀个的FlinkSession管理所有的 Flink作业。 ⼯作流程示意图 Flink Job 集群(per-job模式）

 FLink job集群（pre_job）

集群生命周期：在flink job集群中，可用的集群管理器列入yarn，用于为每个提交的作业启动一个集群，并且该集群仅可用与该作业，在这里客户端首先从集群管理器请求资源启动jobmanager，然后讲作业提交给在这个进程中运行的DIspatcher，然后根据作业的资源请求惰性的分配TaskMAnager，一旦作业完成，job集群将被拆除

资源管理：jobmanager中的致命错误仅影响在Flinkjob集群中运行的一个作业

其他：由于RM必须应用并登载外部资源管理组件来启东TaskMAnager进程和非配资源，所以器实时计算型并没有Session模式强，所以FLink job更适合长时间运行，具有高稳定性要求并且较长启动时间不敏感的大型作业

⼯作流程特征说明 多个不同的FlinkJob向各⾃由统⼀资源管理器(Yarn) ⽣成的专⽤Flink Session会话上提交作业，由作业所 属的FlinkSession管理⾃⼰的Flink作业。 ⼯作流程示意图

 Flink Application集群（应用模式）

与flink作业执行直接相关的模式，并且main方法在集群上而不是在客户端上运行

提交作业是一个单步骤过程

无需启动Flink集群，然后讲作业提交到现有的session集群，而是将应用程序逻辑和依赖打包为一个可执行jar包，由入口客户端提交jar包和相关资源到hdfs中

然后由调度启动的集群当中jobManager来啦去上一步上传完成的运行代码所需要的所有资源

如果JMHA设置的话，将会同时启动多个JM做HA保障，此时将棉铃JM的选择，最终有一个胜出的JM作为Active进程推进下边的执行

并由jm进程的集群入口节点机器负责调用main方法来提取jG，及作为用户程序的解析和提交的客户端程序于集群进行交互。知道作业运行完成

另外，如果一个main方法中有多个env.execute()/executeAsync()调⽤，在 Application模式下，这些作业会被视为属于同⼀个 应⽤，在同⼀个集群中执⾏（如果在Per-Job模式 下，就会启动多个集群） 该模式也允许我们像在 Kubernetes 上部署任何其 他应⽤程序⼀样部署 Flink 应⽤程序。 因此，Flink Application 集群的寿命与 Flink 应⽤ 程序的寿命有关。

资源隔离： 在 Flink Application 集群中，ResourceManager 和 Dispatcher 作⽤于单个的 Flink 应⽤程序，相⽐于 Flink Session 集群，它提供了更好的隔离。 Flink Job 集群可以看做是 Flink Application 集群”客户 端运⾏“的替代⽅案。 该模式为yarn session和yarn per-job模式的折中选择。 ⼯作流程特征说明 将各个环节更进⼀步进⾏专⽤化处理，相当于每个kJob都有⼀套专⽤的服务⻆⾊进程

总结 应⽤场景 本地布署模式：demo、代码测试场景。 Session模式：集群资源充分、频繁任务提交、⼩作业居 多、实时性要求⾼的场景。(该模式较少） Per-Job模式：作业少、⼤作业、实时性要求低的场 景。 Application模式：实时性要求不太⾼、安全性有⼀定要 求均可以使⽤，普遍适⽤性最强。 ⽣产环境使⽤说明 ⼀般建议⽤per-job或是application模式，提供了更好的 资源隔离性和安全性。

运行流程：

运行时核心角色组成，一个jobManager和一个或者多个TaskmAnager

 补充说明：client客户端不是运行时和程序执行的一部分，而是用于准备数据流并将其发送给jobmanager，提交任务完成之后，client可以断开连接，或保持链接来接收进程报告

client可以作为出发执行java/scala程序的一部分运行，也可以在命令行进程./bin/flink run....中运行

可以通过多种方式启动Jm和TM，直接在机器上作为standalone集群启动，在容器中启动，过着通过yarn或mesos等资源框架管理并启动。TM链接到JM，宣布自己可用，并被分配工作

actor system

各个角色组件互相通信的消息传递系统中间件。actor是一种并发编程模型，豫灵一中模型共享内存完全相反，Actror模型share nothing，既没有任何共享

所有的线程用过消息传递的方式进行合作，这些线程陈伟Actor

缺点：唯⼀的缺点是不能实现真正意义上的并⾏， ⽽是通 过并发实现的并⾏效果，会存在⼀定的不确定性。 纯消息通信，实时性和粒度控制上会略弱于共享内 存的⽅式。

JobManager

JobManager 具有许多与协调 Flink 应⽤程序的分布 式执⾏有关的职责：它决定何时调度下⼀个 task（或 ⼀组 task）、对完成的 task 或执⾏失败做出反应、 协调 checkpoint、并且协调从失败中恢复等等。这个 进程由三个不同的组件组成：

RM

ResourceManager 负责 Flink 集群中的资源提 供、回收、分配 - 它管理 task slots，这是 Flink 集群中资源调度的最⼩单位。Flink 为不同 的环境和资源提供者（例如 YARN、Mesos、 Kubernetes 和 standalone 部署）实现了对应 的 ResourceManager。在 standalone 设置 中，ResourceManager 只能分配可⽤ TaskManager 的 slots，⽽不能⾃⾏启动新的 TaskManager。

DIspatcher

提供了一个rest接口，用来提交Flink应用程序执行，并为每个提交的作业启动一个新的JobMaster。他还运行FlinkWEbUI用来提供作业执行信息

JobMaster

z负责管理单个JobGraph的执行，Flink集群中可以同事运行多个作业，每个作业都有自己的JobMaster 

始终至少有一个JobManager 高可用（HA）设置中可能有多个JobMAnager，其中一个始终是leader，其他的事Standby

TaskMAnager

也称为worker 执行作业留的task，并且缓存和减缓数据流

必须始终至少有一个TaskMAnager在TaskManager中资源调度的做小单位Taskslot

TaskMAnager中tasksolt的数量表示并发处理task的数量，请注意一个task slot中可以执行多个算子