概念
1.程序和数据流
并行数据流
任务和操作员链
2.分布式执行
工人、职位、资源
3.时间与Windows
时间
4.状态与容错
容错检查点
状态后端
5.批量上流
程序和数据流
Flink程序的基本组成部分是溪流和变换(注意，数据集在内部也是流)。一个溪流是一个中间结果，而转化是一种以一个或多个流作为输入并从其中计算一个或多个结果流的操作。
执行时，Flink程序被映射到流数据流，由溪流与转型操作者。每个数据流从一个或多个开始。来源并以一个或多个结尾汇。数据流可能类似于任意的有向无圈图 (达格)。(允许特殊形式的循环迭代法构造，为了简单起见，我们省略这里)。
在大多数情况下，程序中的转换与数据流中的操作符之间存在一对一的对应关系。然而，有时一个转换可能由多个转换运算符组成。
并行数据流
Flink中的程序本质上是并行和分布式的。溪流分裂成流分区和操作者分裂成运算符子任务。操作符的任务在不同的线程和不同的机器或容器上独立执行。
操作符子任务的数目是平行性那个特殊的操作者。流的并行性始终是其产生算子的并行性。程序的不同运算符可能具有不同的并行性。
流可以在一对一(或转发)模式，或在再分配模式：
- 一对一流(例如，在来源而地图())保留元素的分区和顺序。这意味着地图()运算符将以相同的顺序看到相同的元素，就像它们是由来源接线员。
- 再分配溪流(之间)地图()和键盘/窗口，以及键盘/窗口和沉槽)更改流的分区。各操作员的任务根据所选转换向不同的目标的任务发送数据。例子有：keyBy()(通过哈希代码重新分区)，（广播)，或再平衡)(随机再分配)。在.再分配元素之间的顺序只为每一对发送和接收任务(例如，子任务[1])保留。地图（和次级任务[2]键盘/窗口).
任务和操作员链
对于分布式执行，Flink链操作符子任务合并成任务。每个任务由一个线程执行。将操作人员链接到任务中是一种有用的优化：它减少了线程到线程切换和缓冲的开销，提高了总体吞吐量，同时减少了延迟。可以在API中配置链接行为。
下图中的示例数据流由五个子任务执行，因此使用五个并行线程执行。
分布式执行
师父，工人，客户
Flink运行时由两种类型的进程组成：
- 这个师父进程(也称为乔布曼)协调分布式执行。他们安排任务，协调检查点，协调故障恢复等。始终至少有一个主进程。高可用性设置将有多个主进程，其中一个始终是领队，其他的是待机.
- 这个工人进程(也称为任务经理)执行任务(或者更确切地说，是子任务)的数据流，缓冲和交换数据。溪流.必须始终至少有一个工作进程。
主进程和工作流程可以以任意方式启动：直接在机器上，通过容器，或者通过资源框架(如纱线)。工人们连接到大师，宣布自己是可用的，并得到分配的工作。
这个客户不是运行时和程序执行的一部分，而是用于准备数据流并将数据流发送给主程序。之后，客户端可以断开连接，或者保持连接以接收进度报告。客户机要么作为触发执行的Java/Scala程序的一部分运行，要么在命令行进程中运行。
工人、职位、资源
每个工作人员(任务管理器)都是一个JVM进程，并且可以在单独的线程中执行一个或多个子任务。若要控制员工接受多少任务，员工已调用了任务槽(至少一个)。
各任务槽表示任务管理器的资源的固定子集。例如，具有三个槽的TaskManager将其托管内存的1/3专用于每个插槽。对资源进行时隙意味着子任务不会与来自其他作业的子任务竞争托管内存，而是拥有一定数量的保留托管内存。请注意，这里没有CPU隔离，时隙目前只分离任务的托管内存。
因此，通过调整任务插槽的数量，用户可以定义子任务是如何相互隔离的。每个TaskManager有一个插槽意味着每个任务组在单独的JVM中运行(例如，可以在单独的容器中启动)。拥有多个插槽意味着更多的子任务共享相同的JVM。同一JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们还可以共享数据集和数据结构，从而减少每个任务的开销。
默认情况下，如果子任务是不同任务的的任务，但来自同一作业，则Flink允许子任务共享插槽。其结果是，一个槽可以容纳整个工作流水线。允许这样槽共享有两个主要好处：
- Flink集群所需的任务槽与作业中使用的最高并行性完全相同。不需要计算程序总共包含多少任务(具有不同的并行性)。
- 更容易获得更好的资源利用率。没有时隙共享，非密集性源/地图()的任务将阻塞与资源密集型相同的资源。窗户的任务。使用时隙共享，将其并行性从2提高到6，就可以充分利用时隙资源，同时仍然确保每个TaskManager只获得相当份额的繁重的任务。
可以在API中控制时隙共享行为，以防止在不希望共享的地方进行共享。这方面的机制是资源组，它定义了哪些(子)任务可以共享插槽。
作为经验法则，一个好的默认任务插槽数将是CPU核心的数目。使用超线程时，每个插槽将接受2个或更多硬件线程上下文。
时间与Windows
聚合事件(例如计数、和)在流上的工作方式与批处理略有不同。例如，不可能首先计算流中的所有元素，然后返回计数，因为流通常是无限的(无界)。相反，流上的聚合(计数、和等)是由窗，如“数过去5分钟”，或“最后100个元素之和”.
窗口可以时间驱动(例如：每30秒)或数据驱动(例如：每100个元素)。通常区分不同类型的窗口，例如翻滚窗(无重叠)，滑动窗(有重叠)，以及会话窗口(活动缺口)。
下面可以找到更多的窗口示例
时间
当引用流程序中的时间(例如定义窗口)时，可以引用不同的时间概念：
- 事件时间创建事件的时间。它通常是由事件中的时间戳来描述的，例如由生产传感器或生产服务所附加的时间戳。Flink通过以下方式访问事件时间戳时间戳指定者.
- 摄食时间事件在源运算符处进入Flink数据流的时间。
- 处理时间执行基于时间的操作的每个操作符的本地时间。
状态与容错
当数据流中的许多操作只查看一个每次事件(例如，事件解析器)，一些操作会记住跨单个事件的信息(例如，窗口操作符)。这些操作称为有状态.
有状态操作的状态是在可以被认为是嵌入式密钥/值存储的情况下维护的。状态与由有状态运算符读取的流一起严格地进行分区和分布。因此，只有在键流，在.之后keyBy()函数，并且仅限于当前事件的键的值。调整流和状态的键可以确保所有状态更新都是本地操作，从而保证一致性，而无需事务开销。这种对齐还允许Flink重新分配状态并透明地调整流分区。
容错检查点
的组合来实现容错。流重放和检查站。检查点定义了流和状态中的一致点，从中可以恢复流数据流，并保持一致性。(精确地-一次处理语义)。自上一个检查点以来的事件和状态更新将从输入流中重放。
检查点间隔是一种利用恢复时间(需要重播的事件数量)来交换执行期间容错开销的方法。
状态后端
存储键/值索引的确切数据结构取决于所选的状态后端。一个州后端将数据存储在内存中的散列映射中，另一个州后端使用RocksDB作为键/值索引。除了定义保存状态的数据结构之外，状态后端还实现了获取键/值状态的实时快照并将该快照存储为检查点的一部分的逻辑。
批量上流
Flink作为流程序的特例执行批处理程序，其中流是有界的(有限的元素数)。一个数据集在内部被视为数据流。因此，上述概念同样适用于批处理程序，也适用于流程序，只有少数例外：
- DataSet API中的程序不使用检查点。恢复是通过完全重播流来实现的。这是可能的，因为输入是有界的。这使得成本更倾向于恢复，但使常规处理更便宜，因为它避免了检查点。
- DataSet API中的有状态操作使用简化的内存/核心外数据结构，而不是键/值索引。
- DataSet API引入了特殊的同步(基于超步的)迭代，这些迭代只能在有界流上使用。