• 对flink-官网的学习和理解
• flink-1.9.0
• 建议看一下官网介绍，更为系统

Tasks and Operator Chains

• 分布式执行时，Flink连接操作子任务到任务中。每个任务都被单独的线程执行。将多个操作连接到一个任务中是非常有用的优化：它减少了线程与线程之间的传输和缓冲的开销，并且在降低延迟的同时增加了总体吞吐量。连接行为是可以配置的，具体可以参考官网文档task-chaining-and-resource-groups

• 下图中的示例数据流有5个子任务，因此有5个并行线程。

  
  
  flink_sample_dataflow.png

Job Managers, Task Managers, Clients

• Flink运行时由两种类型的进程组成：
  • JobManagers(也称作masters)协调分布式执行。它们调度任务，协调检查点，当遇到故障时协调恢复等等。至少会有一个JobManager。高可用的配置会有多个JobManager，其中一个作为leader，其它的作为备份。
  • TaskManagers(也称作workers)执行数据流的任务(或者更具体的说子任务)，并缓冲和交换数据流。至少得有一个TaskManager。
• JobManagers和TaskManagers可以以不同的方式启动：作为一个标准集群直接在机器上启动,在容器中，或者由类似YARN或Mesos的资源框架管理。TaskManagers连接到JobManagers上，上报它们是可用的，并且被分配了工作。
• client不是运行时和程序执行的一部分，但是用来准备和发送一个数据流给JobManager。然后，client可以断开连接，或者保持连接以接收进度报告。client要么是作为触发执行的Java/Scala程序的一部分，要么是在命令行过程中./bin/flink run ...
  
  flink_structure
• 角色通信--akka
• 数据传输--netty

Task Slots and Resources

• 每个worker(TaskManager)是一个JVM进程，并且可能以不同的线程执行一个或多个子任务。为了控制一个worker能够接受多少个任务，worker有了所谓的task solts(至少一个)。
• 每个task slot代表了TaskManager的一个固定资源。例如，一个TaskManager有三个slots，会为每个slot分配1/3的TaskManager内存。对资源进行分配slot意味着一个子任务不会与其它job的子任务竞争memory，而是使用预分配内存。注意CPU并没有隔离：当前slot只隔离task管理的内存。

• 通过调整 task slots，用户可以定义有多少个子任务相互隔离。每个TaskManager只有一个slot意味着每个任务运行在一个单独的JVM上(例如，在一个单独的容器中启动)。多个slot意味着多个子任务共享JVM。相同JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们也共享数据集和数据结构，这可以降低每个任务的负载。

  
  
  flink-slot
• 默认情况下，Flink允许subtasks共享slot，即便它们是不同任务的子任务，只要它们来自相同的job。这样的结果是可能一个slot就持有job的整个管道（即job执行过程都在一个slot中执行）。允许这种slot共享有两个主要的益处：
  • Flink集群精确的需要和job中使用的最高并行度一样的任务槽(slot)数。而不需要计算一个程序总共需要多少个任务(有不同的并行度)。

  • Flink集群更容易提升的集群资源利用率。没有slot共享，非密集型的source/map()子任务会分配与资源密集型的窗口子任务一样多的资源。有了slot共享机制，flink可以更充分的利用资源，同时确保集群中大量的子任务是公平分配集群资源。如下图所示，将flink job的slot由2增加到6:

    
    
    增加flink slots
• As a rule-of-thumb, a good default number of task slots would be the number of CPU cores. With hyper-threading, each slot then takes 2 or more hardware thread contexts.

State Backends

• flink中 key/values index的数据结构取决于选择使用的state backend；
• 一种是将k/v类型的数据存储在内存中hash map结构；另一种选择RocksDB存储k/v类型的state 数据；
• state backend除了定义state data的数据结构外，还要在逻辑上实现获取k/v类型state 数据的point-in-time snapshot,并将snapshot作为checkpoint的一部分；
  
  flink_state-backend.png

Savepoints

• 用Data Stream API编写的程序可以从savepoints恢复执行。 savepoint允许更新程序和Flink群集的state data，因此不会丢失任何的state data。
• savepoint是手动出发的checkpoints，savepoint捕获程序的snapshot并将其写入state backend，这一点的实现是依赖常规的checkpoint机制。
• 在程序运行期间，程序会定期在work node创建snapshot并生成checkpoints，对于程序state恢复，仅需要最后完成的checkpoint，并且一旦完成新checkpoint就可以安全地丢弃旧checkpoint。
• savepoint和周期性的checkpoint类似，不同的是savepoint是由用户触发，并且在新的checkpoint完成时不会自动过期。 savepoint可以从命令行创建，也可以通过REST API取消。

理论指导实践