一、基本特性
1、Flink简介
Flink 是分布式实时和离线计算引擎，用于在无界数据流和有界数据流上进行有状态的计算，能在常见集群环境中运行，并能以内存速度和任意规模进行计算。
要的应用场景包括：实时数据计算、实时数据仓库和ETL、事件驱动型场景，如告警、监控；此外，随着Flink 对机器学习的支持越来越完善，还可以被用作机器学习和人工智能
2、Flink特性
（1）批流一体：Flink从另一个视角看待流处理和批处理，将二者统一起来,流处理看待时输入数据流是无界的；批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的。
（2）Exactly-Once：Flink 通过实现==两阶段提交==和==状态保存==来实现端到端的精确一致性语义
（3）状态管理：Flink在做计算的过程中经常需要存储中间状态，来避免数据丢失和状态恢复。
（4）时间处理：Flink支持事件时间EventTime、注入时间IngestionTime、处理时间ProcessingTime三种时间，同时也支持watermark来处理滞后数据。
（5）支持窗口：支持时间驱动的timeWindow、数据驱动的countWindow，同时支持滚动窗口tumbling windows、滑动窗口sliding windows、会话窗口session windows。滚动窗口中的数据不会叠加；
（6）利用内存性能：任务的状态始终保留在内存中，如果状态大小超过可用内存，则会保存在能高效访问的磁盘数据结构中，非常低的处理延迟,
性能上：ProcessingTime性能最好， IngestTime次之， EventTime最差
延迟上：EventTime延迟最低，IngestTime次之， ProcessingTime延迟最高
确定性：EventTime确定性最高， IngestTime次之， ProcessingTime最低
3、Exactly-Once精确一次
Flink可以通过实现两阶段提交和状态保存来实现端到端的一致性语义。 分为以下几个步骤：
1）开始事务（beginTransaction）创建一个临时文件夹，来写把数据写入到这个文件夹里面
2）预提交（preCommit）将内存中缓存的数据写入文件并关闭
3）正式提交（commit）将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟
4）丢弃（abort）丢弃临时文件
5）若失败发生在预提交成功后，正式提交前。可以根据状态来提交预提交的数据，也可删除预提交的数据。
下级存储不支持事务：
具体实现是幂等写入，需要下级存储具有幂等性写入特性。
·一旦Flink开始做checkpoint操作，就会进入pre-commit “预提交”阶段，同时JobManager的Coordinator会将Barrier注入数据流中。
·当所有的barrier在算子中成功进行一遍传递（就是Checkpoint完成），并完成快照后，“预提交”阶段完成。
·等所有的算子完成“预提交”，就会发起一个commit “提交”动作，但是任何一个“预提交” 失败都会导致Flink回滚到最近的checkpoint。
.两阶段提交API
beginTransaction：在开启事务之前，我们在目标文件系统的临时目录中创建一个临时文件，后面在处理数据时将数据写入此文件。
preCommit：在预提交阶段，刷写（flush）文件，然后关闭文件，之后就不能写入到文件了，我们还将为属于下一个检查点的任何后续写入启动新事务。
commit：在提交阶段，我们将预提交的文件原子性移动到真正的目标目录中，请注意，这回增加输出数据可见性的延迟。
abort：在中止阶段，我们删除临时文件。
4、状态
Flink在做计算的过程中经常需要存储中间状态，来避免数据丢失和状态恢复。 中间状态 state：指一个具体的task/operator的状态，State可以被记录，在失败的情况下数据还可以恢复。
Flink中state有两种基本类型的Keyed State与Operator State，他们都能以两种形式存在：原始状态(raw state)和托管状态(managed state)。
托管状态：由Flink框架管理的状态，我们通常使用的就是这种；原始状态：由用户自行管理状态具体的数据结构，一般不常用。
（1）keyed state 记录的是每个key的状态Keyed state托管状态有六种类型：ValueState、ListState、MapState、ReducingState、AggregatingState、FoldingState
（2）operator state是task级别的state，也就是每个task对应一个state，只有一种托管状态：ValueState`
5、watermark
（1）watermark是一个时间戳，不是固定值，通过结合EventTime与window，来处理迟到的事件，
（2）每个事件都有一个CurrentWatermark，相当于每个事件的计算触发时间，由ProcessTime 或者EventTime 改变为 当前watermark时间
（3）计算方式一般为；
currentMaxEventTime = Math.max(currentMaxEventTime, currentElementEventTime);
new Watermark(currentMaxEventTime - maxOutOfOrderness);
正常事件：EventTime大于currentMaxEventTime，窗口的currentMaxEventTime等于EventTime，不受影响；
晚到事件，EventTime小于currentMaxEventTime，窗口的currentMaxEventTime等于上一个大的EventTime，
有了watermark，窗口触发的时间改变，window延迟秒触发，window触发的时间；
（1）watermark 时间 >= window_end_time
（2）在[window_start_time, window_end_time) 区间中有数据存在，注意是左闭右开的区间，而且是以 event time 来计算的
多个waterMark请看：
一个线程触发当前窗口的waterMark时间，为最大的waterMark时间；多并行度时，多个线程有多个waterMark，触发当前窗口的waterMark时间，取线程间最小的线程内最大waterMark时间。
6、Flink 容错checkpoint概述
Flink 实现容错，主要靠强大的CheckPoint 和 State 机制。Checkpoint 负责定时制作分布式快照、对程序中的状态进行备份；State 用来存储计算过程中的中间状态。
Flink 提供了三种可用的状态后端用于在不同情况下进行状态后端的保存：MemoryStateBackend、FsStateBackend、RocksDBStateBackend
Checkpoint是Flink实现容错机制最核心的功能，它能够根据配置周期性地基于Stream中各个Operator/task的状态来生成快照，从而将这些状态数据定期持久化存储下来，当Flink程序一旦意外崩溃时，重新运行程序时可以有选择地从这些快照进行恢复，从而修正因为故障带来的程序数据异常；
Flink的checkpoint机制，可以与(stream和state)的持久化存储交互的前提：持久化的source，它需要支持在一定时间内重放事件。这种sources的典型例子是持久化的消息队列（如 Kafka，RabbitMQ等）或文件系统（比如HDFS等
7、Flink 中的分布式快照机制
Flink 容错机制的核心部分是，制作分布式数据流和操作算子状态的==一致性快照==，这些快照充当一致性 Checkpoint，系统可以在发生故障时==回滚==。Flink 用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述，它受到分布式快照的标准Chandy-Lamport 算法的启发，专门针对 Flink 的执行模型而定制。
barrier 在数据流源处被注入并行数据流中。快照 n 的 barrier 被插入的位置（我们称为 Sn）是快照所包含的数据在数据源中最大位置。例如，在 Apache Kafka 中，此位置将是分区中最后一条记录的偏移量，将该位置 Sn 报告给 Checkpoint 协调器（Flink 的 JobManager）。
接着barrier 向下游流动。当一个中间操作算子从其所有输入流中收到快照 n 的 barrier 时，它会为快照 n 发出 barrier 进入其所有输出流中。 一旦 sink 操作算子（流式 DAG 的末端）从其所有输入流接收到 barrier n，它就向 checkpoint 协调器确认快照 n 完成。在所有 sink 确认快照后，意味着快照已完成。
一旦完成快照n，job 将永远不再向数据源请求 Sn 之前的记录，因为此时这些记录（及其后续记录）将已经通过整个数据流拓扑，也即已经被处理结束。
8、Flink 中的内存管理
Flink并不是将大量对象存在堆上，而是将对象都序列化到一个预分配的内存块上，此外，Flink 大量使用了堆外内存。如果需要处理的数据超出了内存限制，则会将部分数据存储到硬盘上。Flink 为了直接操作二进制数据，实现了自己的序列化框架。
理论上Flink 的内存管理分为以下 3 部分。
（1）Network Buffers：这个是在 TaskManager 启动的时候分配的，这是一组用于缓存网络数据的内存，每个块是 32K，默认分配 2048 个，可以通过“taskmanager.network .numberOfBuffers”修改。
（2）Memory Manage pool：大量的 Memory Segment 块，用于运行时的算法（Sort/Join/Shuffle 等），这部分启动时会被分配。根据配置文件中的各种参数来计算内存的分配方法，并且内存的分配支持预分配和 lazy load，默认懒加载的方式。
（3）User Code，这个是除了 Memory Manager 之外的内存用于 User Code 和 TaskManager 本身的数据结构。
二、与其他框架的异同
1、Flink 和 Spark Streaming 的异同点有哪些？
1、架构上：
Flink 是实时处理引擎，基于事件驱动，会根据用户的代码处理成Stream Graph，然后优化成为 JobGraph，与 Storm 形成的拓扑 Topology 结构类似。
而 Spark Streaming 是微批（Micro-Batch）的模型，架构是基于Spark，可以把 Spark Streaming 理解为时间维度上的 Spark DAG。
2、时间机制：
Spark Streaming只支持处理时间。
Flink支持处理时间、事件时间、注入时间。同时也支持watermark来处理滞后数据。
3、容错机制：
Spark Streaming 通过checkpoint实现数据不丢失，但无法做到恰好一次处理语义。
Flink 则使用两阶段提交协议和checkpoint实现精准一次处理，容错性好。
4、反压机制：
Flink 在数据传输过程中使用了分布式阻塞队列；
Spark Streaming 用到PID 算法，构造了一个速率控制器，任务的结束时间、处理时长、处理消息的条数。
2、flink kafka
flink提供了一个特有的kafka connector去读写kafka topic的数据。
flink消费kafka数据，并不是完全通过跟踪kafka消费组的offset来实现去保证exactly-once的语义，而是flink内部去跟踪offset和做checkpoint去实现exactly-once的语义，而且对于kafka的partition，Flink会启动对应的并行度去处理kafka当中的每个分区的数据
flink整合kafka官网介绍
实际工作当中一般都是将kafka作为flink的source来使用，先创建好kafka的topic，在建maven工程时porm文件导入flink-connector-kafka的包，在代码里配置好fink的sour为kafka。
3、Flink 的运行必须依赖 Hadoop组件吗？
Flink可以完全独立于Hadoop，在不依赖Hadoop组件下运行。但是做为大数据的基础设施，Hadoop体系是任何大数据框架都绕不过去的。Flink可以集成众多Hadooop 组件，例如Yarn、Hbase、HDFS等等。例如，Flink可以和Yarn集成做资源调度，也可以读写HDFS，或者利用HDFS做检查点。
4、Flink 的 checkpoint 机制对比 spark 有什么不同和优势？
spark streaming 的 checkpoint 仅仅是针对 driver 的故障恢复做了数据和元数据的 checkpoint。
而 flink 的 checkpoint 机制 要复杂了很多，它采用的是轻量级的分布式快照，实现了每个算子的快照，及流动中的数据的快照。
三、架构
1、Flink架构
（1）JobManager：管理者Master，它是整个集群的协调者，负责接收 Job、协调检查点、Failover 故障恢复等，同时管理 Flink 集群中从节点 TaskManager。
（2）TaskManager：负责执行计算的Worker，执行 Flink Job 的一组 Task，每个 TaskManager 负责管理其所在节点上的资源信息，比如内存、磁盘、网络，在启动的时候将资源的状态向 JobManager 汇报。
（3）Client：Flink 程序提交的客户端，当用户提交一个 Flink 程序时，会先创建一个 Client，该 Client 首先会对用户提交的 Flink 程序进行预处理，然后提交到 Flink 集群中处理，所以 Client 需要从用户提交的 Flink 程序配置中获取 JobManager 的地址，并建立到 JobManager 的连接，将 Flink Job 提交给 JobManager。
2、JobManger 在集群中扮演了什么角色？
JobManager 负责整个 Flink 集群==任务调度==及==资源管理==，从客户端中获取提交的应用，然后根据集群中 TaskManager 上 TaskSlot 的使用情况，为提交的应用分配相应的 TaskSlot 资源并命令 TaskManager 启动从客户端中获取的应用。
JobManager 相当于整个集群的 Master 节点，且整个集群有且只有一个活跃的 JobManager，负责整个集群的任务管理和资源管理。
JobManager 和 TaskManager 之间通过Actor System进行通信，获取任务执行的情况并通过Actor System 将应用的任务执行情况发送给客户端。
在任务执行的过程中，JobManager 会触发Checkpoint操作，每个TaskManager 节点收到 Checkpoint 触发指令后，完成 Checkpoint 操作，所有的 Checkpoint 协调过程都是在 Fink JobManager 中完成。
任务完成后，Flink 会将任务执行的信息反馈给客户端，并且释放掉 TaskManager 中的资源以供下一次提交任务使用。
3、JobManger 在集群启动过程中起到什么作用？
首先，我们要回答出JobManager 的主要职责，主要包括负责整个 Flink 集群任务调度和资源的管理，并且负责接收 Flink 作业、调度 Task、收集作业状态和管理 TaskManager。
然后，如果开发者能从源码层面回答出涉及的关键方法，会大大增加面试官的印象
（1）RegisterTaskManager：它由想要注册到 JobManager 的 TaskManager 发送，注册成功则通过 AcknowledgeRegistration 消息进行 Ack。
（2）SubmitJob：将 Job 提交给 Client，提交的信息是 JobGraph 形式的作业描述信息。
（3）CancelJob：请求取消指定ID的作业，成功会返回 CancellationSuccess，否则返回 CancellationFailure。
（4）UpdateTaskExecutionState：由 TaskManager 发送，用来更新执行节点（ExecutionVertex）的状态；成功则返回 true，否则返回 false。
（5）RequestNextInputSplit：TaskManager 上的 Task 请求下一个输入 split，成功则返回 NextInputSplit，否则返回 null。
（6）JobStatusChanged：它意味着作业的状态（RUNNING、CANCELING、FINISHED等）发生变化，这个消息由 ExecutionGraph 发送。
4、TaskManager 在集群中扮演了什么角色？
TaskManager 相当于整个集群的 Slave 节点，负责具体的==任务执行==和对应任务在每个节点上的==资源申请和管理==。
客户端通过将编写好的Flink 应用编译打包，提交到 JobManager，然后 JobManager 会根据已注册在 JobManager 中 TaskManager 的资源情况，将任务分配给有资源的 TaskManager 节点，然后启动并运行任务。
TaskManager 从 JobManager 接收需要部署的任务，然后使用 Slot 资源启动 Task，建立数据接入的网络连接，接收数据并开始数据处理。同时 TaskManager 之间的数据交互都是通过数据流的方式进行的。
Flink 的任务运行其实是采用多线程的方式，这和 MapReduce 多 JVM 并行的方式有很大的区别，Flink 能够极大提高 CPU 使用效率，在多个任务和 Task 之间通过 TaskSlot 方式共享系统资源，每个 TaskManager 中通过管理多个 TaskSlot 资源池对资源进行有效管理。
5、TaskManger 的启动过程是怎样的？
相比JobManager而言，TaskManager 的启动流程较为简单，启动类入口为`org.apache.flink.runtime.taskexecutor.TaskManagerRunner`。
启动过程中主要进行Slot 资源的分配、RPC 服务的初始化，以及JobManager 进行通信等。
6、Flink 组件栈和数据流模型。
（1）DataStream API：对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，支持 Java 和 Scala；
（2）DataSet API：对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，支持 Java、Scala 和 Python；
（3）Table API：对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类 SQL 的 DSL 对关系表进行各种查询操作，支持 Java 和 Scala。
（4）Flink ML：提供了机器学习 Pipelines API 并实现了多种机器学习算法；Gelly、Flink 的图计算库提供了图计算的相关 API 及多种图计算算法的实现。
这些流畅的API 提供了用于数据处理的通用构建块，比如各种形式用户指定的转换、连接、聚合、窗口、状态等。
Flink 程序的基本构建是数据输入来自一个 Source，Source 代表数据的输入端，经过 Transformation 进行转换，然后在一个或者多个 Sink 接收器中结束。数据流（Stream）就是一组永远不会停止的数据记录流，而转换（Transformation）是将一个或多个流作为输入，并生成一个或多个输出流的操作。在执行时，Flink 程序映射到 Streaming Dataflows，由流（Streams）和转换操作（Transformation Operators）组成。
四、计算资源
1、Flink计算资源 Task Slot。
在Flink 中，一个 TaskManger 就是一个 JVM 进程，会用独立的线程来执行 Task。为了控制一个TaskManger能接受多少个Task，Flink 提出了Task Slot的概念，可以把Task Slot理解为TaskManager的计算资源子集。
假如一个TaskManager 拥有5个Slot，那么该TaskManager的计算资源会被平均分为5份，不同的Task在不同的Slot中执行，避免资源竞争。Slot 仅仅用来做内存的隔离，对 CPU 不起作用。
运行在同一个JVM 的 Task 可以共享 TCP 连接，以减少网络传输，在一定程度上提高了程序的运行效率，降低了资源消耗。
2、Flink 计算资源的调度是如何实现的？
TaskManager 中最细粒度的资源是 Task slot，代表了一个固定大小的资源子集，每个 TaskManager 会将其所占有的资源平分给它的 slot。
通过调整task slot 的数量，用户可以定义 task 之间是如何相互隔离的。每个 TaskManager 有一个 slot，也就意味着每个 task 运行在独立的 JVM 中；每个 TaskManager中有多个 slot 的话，也就意味着多个 task 运行在同一个 JVM 中。
而在同一个JVM 进程中的 task，可以共享 TCP 连接（基于多路复用）和心跳消息，可以减少数据的网络传输，也能共享一些数据结构，在一定程度上减少了每个 task 的消耗。
每个slot 可以接受单个 task，也可以接受多个连续 task 组成的 pipeline.
FlatMap 函数占用一个 taskslot，而 key Agg 函数和 sink 函数共用一个 taskslot：
3、Flink 的数据抽象及数据交换过程？
JVM 在对象序列化上有一些固有的缺陷，主要体现在存储对象的密度较低，含有大量不需要的信息，并且FGC 还会对整体的吞吐和响应有严重影响。
为了降低这些影响，Flink 实现了自己的内存管理。主要体现在，Flink 定义了自己的内存抽象：`MemorySegment`,可以把MemorySegment 看作是一个 32KB大的内存块的抽象，这块内存既可以是 JVM 里的一个 byte[]，也可以是堆外内存（DirectByteBuffer）。在 MemorySegment 这个抽象之上，Flink 抽象出了两个关键的进行数据转换的类：
Buffer，用于各个 TaskManager 进行数据传输；
StreamRecord，用于 Java 对象和 Buffer 对象互相转换。
4、Flink 中的并行度设置
并行度，某一个算子被切分成多少个子任务。
Flink 本并行度的优先级依次是：1算子级别 > 2环境级别 > 3客户端级别 > 4集群配置级别。
5、Operator Chain
算子链是我们进行任务调优一定会遇到的问题，主要考察我们对于概念是否正确理解，实际操作中有怎样的指导作用。
为了更高效地分布式执行，Flink 会尽可能地将Operator的Subtask链接（Chain）在一起形成 Task，每个 Task 在一个线程中执行。
将Operators 链接成 Task 是非常有效的优化，它能减少：①线程之间的切换； ②消息的序列化/反序列化；③数据在缓冲区的交换；④延迟的同时提高整体的吞吐量。
6、Flink什么情况下才会把Operator chain在一起形成算子链？
（1）上下游并行度一致
（2）下游数据没有其他的输入
（3）上下游节点都在同一个soltgroup中，默认是一样的，如果不是，单独指定的算子资源，会独占TaskSolt
（4）没有keyed操作
（5）数据发送策略是forward
（6）用户没有禁用chain
7、数据倾斜问题？Flink 中的 Window 出现了数据倾斜，你有什么解决办法？
产生数据倾斜的原因主要有2 个方面：
①业务上有严重的数据热点，比如滴滴打车的订单数据中北京、上海等几个城市的订单量远远超过其他地区；
②技术上大量使用了 KeyBy、GroupBy 等操作，错误使用了分组 Key，人为产生数据热点。
因此解决问题的思路也很清晰：
①业务上要尽量避免热点 key 的设计，例如我们可以把北京、上海等热点城市分成不同的区域，并进行单独处理；
②技术上出现热点时，要调整方案打散原来的 key，避免直接聚合；此外 Flink 还提供了大量的功能可以避免数据倾斜。
五、任务提交
1、任务提交流程（YARN）
· （1）Flink任务提交后，Client向HDFS上传Flink的Jar包和配置
· （2）随后向Yarn ResourceManager提交任务，ResourceManager分配Container资源并通知对应的NodeManager启动
· （3）ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager，之后ApplicationMaster向ResourceManager申请资源启动 TaskManager
· （4）ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager
· （5）NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager
· （6）TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
2、Flink 任务出现很高的延迟，你会如何入手解决类似问题？
（1）在Flink 的后台任务管理中，可以看到 Flink 的哪个算子和 task 出现了反压；
（2）资源调优和算子调优，对作业中的并发数（Parallelism）、CPU（Core）、堆内存（Heap_memory）等参数进行调优；
作业参数调优，并行度的设置、State 的设置、Checkpoint 的设置。
请谈谈你们是如何处理脏数据的？
这也是一个开放性的面试题，建议你结合自己的实际业务来谈。比如可以通过一个fliter 算子将不符合规则的数据过滤出去。当然了，我们也可以在数据源头就将一些不合理的数据抛弃，不允许进入 Flink 系统参与计算。
2、Flink Job 的提交流程。
（1）用户提交的Flink Job 会被转化成一个 DAG 任务运行。Flink Job 的提交涉及的类主要包括：`StreamGraph、JobGraph、ExecutionGraph、TaskManager、JobManager、ResourceManager`。
（2）JobManager 会把接收到的需要执行的应用程序进行打包，然后把 JobGraph 转换成可以执行的ExecutionGraph，接着向 ResourceManager 请求执行任务所需要的资源，也就是我们之前课程中提到的 Slot，如果资源获取成功 JobManager 会负责所有的任务调度，比如 Checkpoint，并且将任务派发给 TaskManager 去执行。
3、Flink 的“三层图”结构是什么意思？
> 这道题要求面试者掌握Flink 框架引擎划分执行计划的详细过程。
一个Flink 任务的 DAG 生成计算图，大致经历以下3个过程。
（1）首先，StreamGraph的拓扑结构，最接近代码层面，主要由 StreamNode和 StreamEdge构成，其中 StreamNode`对应着 Operator，它们通过 StreamEdge进行链接。
（2）其次，JobGraph，是能被Flink引擎识别的数据结构，由JobVertex、JobEdge和 IntermediateDataSet3个元素组成。我们可以把JobGraph形象地比喻为一个抽水系统，JobVertex`是水泵，JobEdge`是水管，而 IntermediateDataSet则是中间的蓄水池。
（3）最后，ExecutionGraph，由 JobGraph 转换而来，包含了任务具体执行所需的内容，是最贴近底层实现的执行图。
4、谈谈Flink 的 SQL 部分是如何实现的？
Table SQL 是 Flink 提供的高级 API 操作。Flink SQL 是 Flink 实时计算为简化计算模型，降低用户使用实时计算门槛而设计的一套符合标准 SQL 语义的开发语言。
Flink 把 SQL 的 解析、优化 和 执行**教给了==Calcite==。从图中可以看到，无论是批查询 SQL 还是流式查询 SQL，都会经过对应的转换器 Parser 转换成为节点树 SQLNode tree，然后生成逻辑执行计划 Logical Plan，逻辑执行计划在经过优化后生成真正可以执行的物理执行计划，交给 DataSet 或者 DataStream 的 API 去执行。
https://mp.weixin.qq.com/s/xRqrojjFITuhswtjNJo7OQ
6、Flink的CEP机制
CEP全称为Complex Event Processing，复杂事件处。Flink CEP是在 Flink 中实现的复杂事件处理（CEP）库，CEP 允许在无休止的事件流中检测事件模式，让我们有机会掌握数据中重要的部分。一个或多个由简单事件构成的事件流通过一定的规则匹配，然后输出用户想得到的数据—— 满足规则的复杂事件
7、Flink-On-Yarn常见的提交模式有哪些，分别有什么优缺点？
1.yarn-session模式：
这种方式需要先启动集群，然后在提交作业，接着会向yarn申请一块空间后，资源永远保持不变。如果资源满了，下一个就任务就无法提交，只能等到yarn中其中一个作业完成后，释放了资源，那下一个作业才会正常提交，这种方式资源被限制在session中，不能超过，比较适合特定的运行环境或测试环境。
2.per-job模式：
这种方式直接在yarn上提交任务运行Flink作业，这种方式的好处是一个任务会对应一个job，即每提交一个作业会根据自身的情况，向yarn中申请资源，直到作业执行完成，并不会影响下一个作业的正常运行，除非是yarn上面没有任何资源的情况下。一般生产环境是采用此方式运行。这种方式需要保证集群资源足够。
六、代码相关
1.Flink连接API
（1）union 多流合并，类型一致
（2）connect 两条流分别处理，类型可不一致，可共享状态
（3）join 相当于innerjoin
（4）coGroup 实现左外连接，第一个流没有join上，也要输出
网友评论