Distributed Runtime Environment（分布式运行环境）
Tasks and Operator Chains
在分布式执行情况下，Flink将operator subtasks 链接到一起，形成任务（task）。每个任务（subtask）由一个线程执行。将operator subtasks链接到任务中是一个好处：它减少了线程到线程的切换和缓冲的开销，并在减少延迟的同时提高了总体吞吐量。链接行为是可以进行配置的;有关详细信息，请参阅此文档。
下图中有5个子任务，因此就有5个并行的线程。对图中内容解释下：source和map是两个operator subtasks，组成一个subtask；keyBy()，window()和apply()三个operator subtasks组成一个subtask。
Job Managers, Task Managers, Clients
Flink的运行过程中有两个进程：
- JobManagers（master）：协调分布式的执行。他们调度任务，协调检查点，协调故障恢复等。至少需要有一个Job Manager，有一个是leader。一个高可用的环境，会有多个Job Manager，永远只有一个是leader，其它则是备用。
- TaskManager（worker）：执行数据流中的子任务，缓冲和交换数据流。至少有一个TaskManager。
JobManagers and TaskManagers运行方式：
- standalone cluster
- YARN
- Mesos
TaskManagers连接到JobManagers，告诉JobManagers自己处于可用状态，可以用来执行任务。
Client不是Flink运行时和程序执行的一部分，而是用于准备并向JobManager发送数据流。之后，客户端可以断开连接，或者保持连接以接收进度报告。Client可以作为触发执行的Java/Scala程序的一部分运行，也可以在命令行进程中运行比如说：./bin/flink run ....
Task Slots and Resources（任务槽与资源）
每个TaskManager（worker）是一个JVM进程，可以执行一个或者多个子任务在不同的线程中。为了控制一个TaskManager（worker）接受多少任务，一个TaskManager至少有一个任务槽。
每个任务槽(task slot)拥有TaskManager固定的资源。例如，一个TaskManager有三个任务槽(task slot)，那么每个任务槽(task slot)将会占用TaskManager内存的1/3。任务槽之间的内存资源不存在竞争关系。但是，这里没有发生CPU隔离;目前（Flink1.6），槽只分离，任务的托管内存。
通过调整任务槽的数量，用户可以定义子任务如何相互隔离。每个TaskManager有一个task slot意味着每个任务组在一个单独的JVM中运行(例如，它可以在一个单独的container中启动)。拥有多个task slot意味着更多的子任务共享同一个JVM。相同JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们还可以共享数据集和数据结构，从而减少每个任务的开销。
默认情况下，Flink允许子任务（subtasks）共享任务槽（task slots），即使它们是不同任务的子任务，只要它们来自同一个任务。也就是一个槽可以容纳整个作业管道。允许这种槽共享有两个主要好处:
- Flink集群只需要与作业（job）中使用的最高并行度一样多的任务槽即可。不需要计算程序总共包含多少个任务(每个任务中可能具有不同的并行度)。
- 便于将资源利用最大化。如果没有槽共享，非密集型source/map()子任务将占据与资源密集型窗口子任务一样多的资源。通过task slot共享，将下图示例中的基本并行度从2提高到6，可以充分利用有槽资源，同时确保繁重的子任务在task manager中公平分配。
对图中内容解释一下：图中包含2个进程，也就是两个TaskManager（两个JVM进程）；每个TaskManager有三个task slot，如图现在在task slot共享的情况下，并行度是6。如果不存在task slot共享，那么6个task slot，有2个task slot执行source()，map()操作，两个task slot执行keyBy()，window()和apply()操作，sink操作至少需要一个task slot。这就是基本并行度从2提高到6。
APIs中还包括一个资源组机制，可以用来防止不需要的task slot共享。根据经验，一个好的默认任务槽数是CPU内核数（应用中这样配置就可以）。对于超线程，每个task slot需要2个或更多的硬件线程上下文。
State Backends
键/值索引存储的确切数据结构取决于所选的状态后端（State Backends）。一个状态后端（State Backends）将数据存储在一个内存hash map中，另一个状态后端使用RocksDB作为key/value存储。
除了定义保存状态的数据结构外，状态后端（State Backends）还实现了获取key/value状态的时间点快照的逻辑，并将该快照存储为检查点（checkpoint）的一部分。
Savepoints
程序可以从保存点（Savepoints）恢复执行。保存点允许在不丢失任何状态的情况下，更新程序和Flink集群。
保存点（Savepoints）是手动触发的检查点，它获取程序的快照并将其写入状态后端（ state backend.）。它们依赖于规则的检查点（checkpoints）机制。在程序执行过程中，在工作节点（works）会定期对程序进行快照，并生成检查点（checkpoints）。对于恢复操作来说，只需要最后一个完成的检查点即可；当新的检查点完成，旧的检查点可以安全地丢弃。
保存点（Savepoints）类似于这些定期检查点，只是它们是由用户触发的，在新的检查点完成时，旧的检查点也不会自动过期。保存点可以通过命令行创建，或者在通过REST API取消作业（job）时创建。
原文地址：https://www.cnblogs.com/dreamfor123/p/9542106.html