Tasks and Operator Chains
为了分布式地运行任务，Flink可以将各种操作的子任务链接成一个任务链，每个任务链由一个线程执行。将这些子任务链接成任务链的好处是：可以减少数据在线程间切换和传输缓存的开销，在增加总体吞吐量的同时，降低了延迟。在Flink作业中，用户可以指定相应的Operator Chain用于将相关性非常强的操作链接在一起，这样可以使该任务链能够在同一个Pipeline中执行。一般情况下，Flink会默认开启TaskChain，以提高作业的整体性能。Flink同时也为用户提供了细粒度的链接控制，用户可以根据自己的实际需求创建或禁止Operator Chain。
Job Managers, Task Managers, Clients
Flink运行时由两种类型的进程组成，分别是JobManager和TaskManager：
- JobManager用于协调分布式任务的分配和调度，也称之为master。通常负责任务安排，检查点协调，故障恢复等。Flink运行时环境中至少需要一个JobManager，高可用性设置中允许有多个作业管理器，但是leader只能有一个，而其他的都只能是standby，只有当leader故障时，Flink会在当前standby中重新选举一个作为leader。
- TaskManager负责数据流中任务的执行、缓存和数据流的交换，也称之为worker。Flink运行时环境中至少需要有一个TaskManager，通常会有多个。
JobManager和TaskManager可以以各种方式启动:作为独立集群直接在机器上启动，或者在容器中启动，或者通过诸如YARN或Mesos之类的资源框架进行管理。TaskManager需要跟JobManager保持通信，向JobManager报告状态信息，同时接受JobManager分配的任务。
在Flink中，Client并不是运行时和程序执行的一部分，而是用于准备和向JobManager发送数据流，之后Client可以断开连接，或者继续等待任务的执行报告。Client可以作为触发执行的Java/Scala程序的一部分运行，也可以在命令行进程中运行./bin/flink run ···。
Task Slots and Resources
Slot是整个Flink系统中所提供的资源最小单元，概念上与YARN中的Container类似，Flink在TaskManager启动后，会自动管理当前TaskManager上所提供的Slot，在任务提交到Flink集群后，由JobManager向TaskManager统一分配指定数量的Slot。每个TaskManager是一个JVM进程，可以在独立的线程中执行一个或多个子任务。为了控制一个TaskManager能接受多少Task，每个TaskManager都维护着一组Task Slot(至少一个)。每个Task Slot表示TaskManager资源的一个固定大小的子集。例如一个维护着3个Task Slot的JobManager会为每个Task Slot分配1/3的托管内存。分配资源意味着一个子任务不会与其他Job的子任务竞争托管内存，而是拥有一个固定大小的保留托管内存。需要注意的是，这里并没有进行CPU隔离，Task Slot只分隔任务的托管内存。
用户可以通过调整任务槽的数量来定义子任务间的隔离级别。例如，当每个TaskManager只维护一个Task Slot时，此时意味着每个task在独立的JVM中运行（例如在不同的容器中启动）。当一个TaskManager维护多个Task Slot时，每个Slot中的任务会共享当前JVM，同一个JVM中的Task会共享TCP连接(通过多路复用)和心跳消息。它们还可以通过共享数据集和数据结构来减少每个任务的开销。
默认情况下，Flink允许同一个Job的子任务共享Task Slot，即使它们是不同任务的子任务。其结果是一个Slot可以容纳Job的整个Pipeline。允许这种Slot共享有两个主要好处：
- Flink集群需要与Job使用的最高并行度相同的任务槽，不需要计算一个程序总共包含多少任务(具有不同的并行度)。
- 更好地利用资源。如果没有Slot共享，非密集型子任务source/map()将阻塞与资源密集型子任务window()一样多的资源。如下图所示，如果使用插槽共享，我们将示例中的基础并行度从2提高到6，可以充分利用Slot资源，同时确保繁重的子任务在TaskManager中得到公平分配。
根据经验，一个好的默认任务Slot数量应该是CPU内核的数量。对于超线程，每个槽需要2个或更多的硬件线程上下文。
State Backends
Flink中提供了StateBackend来存储和管理Checkpoint过程中的状态数据。Flink中一共实现了三种类型的状态管理器，包括基于内存的MemoryStateBackend，基于文件系统的FsStateBackend和基于RockDB作为存储介质的RocksDBStateBackend。这三种类型的StateBackend均能有效地存储Flink流式计算过程中产生的状态数据，默认情况下Flink使用的是内存作为状态管理器。除了定义保存状态的数据结构之外，StateBackend还实现了获取key/value状态的时间点snapshot的逻辑，并将该snapshot存储为Checkpoint的一部分。
Savepoints
使用DataStream API中编写的程序可以使用Savepoint恢复执行。Savepoint允许在不丢失任何状态的情况下更新程序和Flink集群。Savepoint是手动触发的Checkpoint，它获取程序的Snapshot并将其写入StateBackend。它们依赖于常规的Checkpoint机制。程序在执行过程中，会定期在工作节点上进行Snapshot并生成Checkpoint。对于恢复，只需要最后一个完成的Checkpoint，而之前的Checkpoint可以在新的Checkpoint完成后直接安全地丢弃掉。Savepoint类似于这些定期的Checkpoint，只是它们是由用户触发的并且在新Checkpoint完成时不会自动过期。可以从命令行或通过REST API在取消作业时创建Savepoint。
参考
1.https://ci.apache.org/projects/flink/flink-docs-release-1.9/concepts/runtime.html
网友评论