2.Concepts之Distributed Runtime

flink 1.8

Distributed Runtime Environment分布式运行环境

Tasks and Operator Chains任务和操作链

 

分布式执行时，Flink将操作算子子任务subtasks一起链接到任务tasks中。每个任务都被单独的线程执行。将操作算子链接到任务中是非常有用的优化：它减少了线程到线程切换handover和缓冲buffering的开销，并且在降低延迟的同时增加了总体吞吐量。连接行为是可以配置的；有关详细信息，请参阅链接文档 chaining docs。

下图中的示例数据流dataflow使用5个子任务subtasks执行，因此使用5个并行线程。

 

Job Managers, Task Managers, Clients

Flink运行时由两种类型的进程组成:

• JobManagers (也称为master)协调分布式执行。他们安排任务，协调检查点，协调故障恢复，等等。

至少有一个Job Manage。一个高可用性的设置将有多个JobManagers，其中一个是领导者leader，其他的都是备用的standby。

• TaskManagers(也称为workers)执行数据流dataflow的任务tasks (或者更具体地说，子任务subtasks)，并缓冲buffer和交换数据流。

须始终至少有一个TaskManager。

JobManagers和TaskManagers可以以多种方式启动:直接在机器上作为独立集群standalone cluster启动，或者在容器containers中启动，或者由类似YARN或者Mesos的资源框架管理。TaskManagers连接到JobManagers，宣布自己可用，并分配工作。

client不是运行时和程序执行的一部分，而是用于准备和向JobManager发送数据流dataflow的。之后，客户端可以断开连接，或保持连接以接收进度报告。客户端可以作为触发执行的Java/Scala程序的一部分运行，也可以在命令行进程中运行./bin/flink run ...。

 

 

Task Slots and Resources

每个worker (TaskManager)都是一个JVM进程，可以在不同的线程中执行一个或多个子任务subtasks。为了控制一个worker能够接受多少任务tasks，worker有了所谓的 task slots(至少一个at least one)。

每个task slot表示TaskManager资源的一个固定子集。例如，一个有三个slots的TaskManager会将其1/3的管理内存分配给每个slot。对资源进行slot意味着子任务subtask不会与来自其他job的子任务争夺管理的内存资源，而是拥有一定数量的预留管理内存。注意，这里没有对CPU进行隔离;当前slot只隔离任务管理的内存。

通过调整task slots的数量，用户可以定义子任务subtasks如何彼此隔离。每个TaskManager只有一个slot，意味着每个任务组task group运行在单独的JVM中(例如，可以在单独的容器中启动JVM)。多个slots意味着多个子任务subtasks共享JVM。相同JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们还可以共享数据集和数据结构，从而减少每个任务的开销。

默认情况下，Flink允许子任务共享slots，即使它们是不同任务tasks的子任务subtasks，只要它们来自相同的job。结果是一个slot可以容纳作业的整个管道pipeline。允许这个slot共享有两个主要好处:

• Flink集群需要的task slots与job中使用的最高并行度是相同的。不需要计算一个程序总共包含多少个任务tasks(具有不同的并行度)。
• 更容易获得更好的资源利用。如果没有slots共享，非密集型的source/map()子任务会分配与资源密集型的窗口子任务subtasks一样多的资源。使用slot共享，将我们示例中的基本并行度从2提高到6，可以充分利用slot资源，同时确保繁忙的子任务subtasks在TaskManagers中得到公平分配。

这些APIs还包括一个资源组 resource group 机制，可用于防止不需要的slot共享。

根据经验，一个好的默认task slots应该是CPU内核的数量。使用超线程，每个slot 将接受2个或更多的硬件线程上下文contexts。

 

State Backends

存储key/value索引的数据结构取决于所选的状态后端state backend：

• • 其中一种状态后端state backend是将数据存储在内存中的散列map中；
  • 另一种状态后端state backend是使用RocksDB作为key/value进行存储。

除了定义保存状态的数据结构外，状态后端state backend还实现了获取某个时刻key/value状态快照的逻辑，并将该快照作为检查点的一部分进行存储。

 

Savepoints

在数据流API中编写的程序可以从保存点savepoint恢复执行。保存点允许在不丢失任何状态的情况下更新程序和Flink集群。

保存点Savepoints是手动触发的检查点checkpoint，它获取程序的快照snapshot 并将其写入状态后端state backend。它们依赖于常规的检查点checkpoint机制。在执行过程中，程序定期在工作节点上快照snapshotted并生成检查点。对于flink程序的故障恢复，只需要最后一个完成的检查点checkpoint，而旧的检查点可以在新检查点完成时安全地丢弃。

保存点Savepoints类似于这些定期检查点checkpoint，但它们是由用户触发的，并且在更新的检查点完成时不会自动过期。可以从命令行 command line创建保存点，也可以在通过 REST API取消job运行时创建的保存点Savepoints。

 

总结：

1.不同操作算子（operator）进行链化优化

链化操作就是讲不同算子放到一个线程thread中执行，作用是减少线程之间的交换和数据的传输，减少延迟和网络传输的开销，从而提高吞吐量。

2.slot概述

一个slot对应一个CPU核，仅运行同一个flink job任务中的subtast，物理机有n个CPU核，则将内存划分成n等份，因此slot的计算和内存资源都是固定的，作用是减少进程资源之间的竞争。

slot资源共享：

将计算资源密集型（如：窗口算子window）和非计算资源密集型（如：filter/map算子等）分配到同一个slot，这样可以最大限度的提高CPU核和内存的利用率。

 

3.checkpoint和savepoint的区别：

（1）checkpoint是系统周期性的触发的，而savepoint是用户手动触发；

（2）checkpoint成功后，在此之前的checkpoint的状态数据就成了过期数据（自动过期），然后就可以进行清除了，savepoint会将完成的检查点状态保存到state backends，保存点允许在不丢失任何状态的情况下更新程序和Flink集群。

 

https://ci.apache.org/projects/flink/flink-docs-release-1.8/concepts/runtime.html

https://flink.sojb.cn/concepts/runtime.html

https://www.jianshu.com/p/92b47e7f612a