flink一些总结

1.flink组件

1.1客户端

严格上说, 客户端不是运行和程序执行的一部分, 而是用于准备和发送dataflow到JobManager. 然后客户端可以断开与JobManager的连接(detached mode), 也可以继续保持与JobManager的连接(attached mode)
客户端作为触发执行的java或者scala代码的一部分运行, 也可以在命令行运行:bin/flink run ...

1.2JobManager

控制一个应用程序执行的主进程，也就是说，每个应用程序都会被一个不同的JobManager所控制执行。
JobManager会先接收到要执行的应用程序，这个应用程序会包括：作业图（JobGraph）、逻辑数据流图（logical dataflow graph）和打包了所有的类、库和其它资源的JAR包。
JobManager会把JobGraph转换成一个物理层面的数据流图，这个图被叫做“执行图”（ExecutionGraph），包含了所有可以并发执行的任务。JobManager会向资源管理器（ResourceManager）请求执行任务必要的资源，也就是任务管理器（TaskManager）上的插槽（slot）。一旦它获取到了足够的资源，就会将执行图分发到真正运行它们的TaskManager上。
而在运行过程中，JobManager会负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调。

JobManager进程包含3个不同的组件 ResourceManager、Dispatcher、JobMaster

1.2.1ResourceManager

负责资源的管理，在整个 Flink 集群中只有一个 ResourceManager. 注意这个ResourceManager不是Yarn中的ResourceManager, 是Flink中内置的, 只是赶巧重名了而已。
主要负责管理任务管理器（TaskManager）的插槽（slot），TaskManger插槽是Flink中定义的处理资源单元。
当JobManager申请插槽资源时，ResourceManager会将有空闲插槽的TaskManager分配给JobManager。如果ResourceManager没有足够的插槽来满足JobManager的请求，它还可以向资源提供平台发起会话，以提供启动TaskManager进程的容器。另外，ResourceManager还负责终止空闲的TaskManager，释放计算资源。

1.2.2Dispatcher

负责接收用户提供的作业，并且负责为这个新提交的作业启动一个新的JobManager 组件. Dispatcher也会启动一个Web UI，用来方便地展示和监控作业执行的信息。Dispatcher在架构中可能并不是必需的，这取决于应用提交运行的方式。

1.2.3JobMaster

JobMaster负责管理单个JobGraph的执行.多个Job可以同时运行在一个Flink集群中, 每个Job都有一个自己的JobMaster.

1.3TaskManager

Flink中的工作进程。通常在Flink中会有多个TaskManager运行，每一个TaskManager都包含了一定数量的插槽（slots）。插槽的数量限制了TaskManager能够执行的任务数量。
启动之后，TaskManager会向资源管理器注册它的插槽；收到资源管理器的指令后，TaskManager就会将一个或者多个插槽提供给JobManager调用。JobManager就可以向插槽分配任务（tasks）来执行了。
在执行过程中，一个TaskManager可以跟其它运行同一应用程序的TaskManager交换数据。

2.flink核心概念

TaskManger与Slots

Flink中每一个worker(TaskManager)都是一个JVM进程，它可能会在独立的线程上执行一个或多个subtask。为了控制一个worker能接收多少个task，worker通过task slot来进行控制（一个worker至少有一个task slot）。
每个task slot表示TaskManager拥有资源的一个固定大小的子集。假如一个TaskManager有三个slot，那么它会将其管理的内存分成三份给各个slot。资源slot化意味着一个subtask将不需要跟来自其他job的subtask竞争被管理的内存，取而代之的是它将拥有一定数量的内存储备。
需要注意的是，这里不会涉及到CPU的隔离，slot目前仅仅用来隔离task的受管理的内存。
通过调整task slot的数量，允许用户定义subtask之间如何互相隔离。如果一个TaskManager一个slot，那将意味着每个task group运行在独立的JVM中（该JVM可能是通过一个特定的容器启动的），而一个TaskManager多个slot意味着更多的subtask可以共享同一个JVM。而在同一个JVM进程中的task将共享TCP连接（基于多路复用）和心跳消息。它们也可能共享数据集和数据结构，因此这减少了每个task的负载。

---- 默认情况下，Flink允许子任务共享slot，即使它们是不同任务的子任务（前提是它们来自同一个job）。 这样的结果是，一个slot可以保存作业的整个管道。
----默认情况下，因为一个算子对应一个task，即使是taskmanager设置一个slot的时候，所有的task都可以进行共享slot，这就是一个slot里面有了整个管道。同理设置多个slot的时候，和一个slot的原理一样，每个slot里面都有整个管道。

TaskSlot是静态的概念，是指TaskManager具有的并发执行能力，可以通过参数taskmanager.numberOfTaskSlots进行配置。

内存相关

!!!per-job模式下，一个机器上可以启动多个taskmanager。
假设有3台机器，一个机器的内存是4G的话，如果设置的时候，设置1个taskmanager的内存是2G ，设置2个slot的话，那么一个机器的话最多可以启动2个taskmanager，那么就是最多有4个slot。
在per-job的模式下，最多可以启动12个slot。

!!!yarn-session模式下，一个机器只能启动一个taskmanager。
假设有3台机器，一个机器的内存是4G的话，如果设置的时候，设置1个taskmanager的内存是2G ，设置2个slot的话，那么一个机器的话最多可以启动1个taskmanager，那么就是最多有2个slot。
在yarn-session的模式下，最多可以启动6个slot。

Parallelism（并行度）

打个比方，设置的并行度是18，假如一个taskmanager设置3个slot，那么需要启动6个taskmanager。

-----并行度的设置，主要考虑的是kafka的分区数，数目一样就行了。Kafka分区数目在创建topic的时候指定，具体根据吞吐量来判断。

一个特定算子的子任务（subtask）的个数被称之为这个算子的并行度（parallelism）。一般情况下，一个流程序的并行度，可以认为就是其----所有算子中----最大的并行度。一个程序中，不同的算子可能具有不同的并行度。

slot与并行度的关系

taskmanager的并行度的slot设置为x，那么task的并行度的设置最多就是x。
一个算子就是一个task，task的slot的数目设置为6，也就是该任务最多可以启动6个子任务，也就是6个同时执行这个task，那么效率就提高了很多。并行度设置为7的话，也就是启动了7个子任务，有一个子任务的话，就是没有slot，那么这个job任务就是运行不起来，该job失败。

并行度与slot和taskmanager的关系

需要启动的taskmanager的数目 = max(parallelism) / 每个taskmanager设置的slot 数目（向上取整)

Task与SubTask

一个算子就是一个Task。一个算子的并行度是几, 这个Task就有几个SubTask。

flink的生产环境下的task是如何设置的？

看yarn集群的资源，任务很大的话，数目就设置的少一点，任务很小的话，就设置的多一点。就是看资源的大小。有多少个taskmanager就是由yarn决定的。
task就是算子，task并行度=算子并行度，所以task个数=所有算子的个数。所以是说运行有多少个task的时候，就是代码里面有几个算子，就是想了解一下，业务复杂与否。
slot数量是任务提交的时候，per-job直接设置slot的数目。显然这个设置的数目不能大于集群能给到的数目。比如:集群的资源能给到6个slot，某个算子的并行度设置大于6的话，那么就是启动失败，因为没有多余的slot。总之，slot的数量就是看算子中的最大并行度。
per-job模式下，任务提交的时候设置的slot数目大于集群能给到的slot数目，任务会失败吗？会的，上限就是集群资源的上限。
如果启动设置的slot的数量小于流程序的并行度，那么就是进行算子并联，也就是并行度相同的算子进行合并。

Operator Chains（任务链）

相同并行度的one to one操作，Flink将这样相连的算子链接在一起形成一个task，原来的算子成为里面的一部分。 每个task被一个线程执行。
将算子链接成task是非常有效的优化：它能减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量。链接的行为可以在编程API中进行指定。

3.端到端的一致性

内部保证 —— 依赖checkpoint(barrier对齐)
source 端 —— 需要外部源可重设数据的读取位置
sink 端 ——需要保证从故障恢复时，数据不会重复写入外部系统
而对于sink端，又有两种具体的实现方式：事务性（Transactional）写入。

source 端–重新读取kafka的位置。以kafka为例，看kafka的api，看flinkKafkaConsumer。

Ctrl + n FlinkKafkaConsumer

public class FlinkKafkaConsumer extends FlinkKafkaConsumerBase

FlinkKafkaConsumerBase 这个类下面:

搜pendingOffsetsToCommit

点进去看即可。

事务写入 需要构建事务来写入外部系统，构建的事务对应着 checkpoint，等到 checkpoint真正完成的时候，才把所有对应的结果写入 sink 系统中。kafka是0.11版本开始支持事务，这个事务就不用管了。

4.实时任务的提交

公司怎么提交的实时任务，有多少Job Manager？
1）我们使用yarn session模式提交任务；另一种方式是每次提交都会创建一个新的Flink 集群，为每一个job提供资源，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。线上命令脚本如下：

bin/yarn-session.sh -n 7 -s 8 -jm 3072 -tm 32768 -qu root.. -nm *-d
其中申请7个 taskManager，每个 8 核，每个 taskmanager 有 32768M (32g)内存，jobmanager是4g。

2）集群默认只有一个 Job Manager。但为了防止单点故障，我们配置了高可用。对于standlone模式，我们公司一般配置一个主 Job Manager，两个备用 Job Manager，然后结合 ZooKeeper 的使用，来达到高可用；对于yarn模式，yarn在Job Mananger故障会自动进行重启，所以只需要一个，我们配置的最大重启次数是10次。

5.集群资源

flink走的是yarn集群资源，就看yarn分了多少资源。flink安装在1,2机器上。
那些客户端安装在nn的机器上，因为不占内存，不会影响性能，因为底层是mr，不存数据，数据存放在hdfs上。