有状态流处理

什么是State？

而数据流中的许多操作只是针对一个单独的操作atime的活动（例如事件解析器），一些操作会记住多个事件之间的信息（例如窗口运算符）。这些操作称为有状态的.

有状态操作的一些示例：

当应用程序搜索某些事件模式时，状态将存储迄今为止遇到的事件序列。
当按每分钟/小时/天聚合事件时，该状态将保留挂起的聚合。
当在数据点流上训练机器学习模型时，该状态保存模型参数的当前版本。
当需要管理历史数据时，该状态允许有效地访问过去发生的事件。

Flink需要了解状态，以便使用检查点和存储点.

关于状态的知识还允许重新缩放Flink应用程序，这意味着Flink负责在并行实例之间重新分配状态。

可查询状态允许您在运行时从Flink外部访问状态。

在使用state时，阅读以下内容可能也很有用Flink的州后端.Flink提供了不同的状态后端，用于指定状态存储的方式和位置。

键控状态

键控状态保持在可以被认为是嵌入的键/值存储中。状态严格地和有状态运算符读取的流一起进行分区和分布。因此，只有在上才能访问密钥/值状态键控流，即在键控/分区数据交换之后，并且被限制为与当前事件的键相关联的值。对齐流和状态的键可以确保所有状态更新都是本地操作，从而保证一致性而不会产生事务开销。这种对齐还允许Flink透明地重新分配状态和调整流分区。

bc8bd1abb1da4afc7269a7a3af30df46_state_partitioning.svg

Keyed State进一步组织成所谓的关键组密钥组是Flink可以重新分配密钥状态的原子单元；存在与定义的最大并行度一样多的密钥组。在执行过程中，键控运算符的每个并行实例都与一个或多个键组的键一起工作。

状态持久化

Flink使用的组合实现容错流重放和检查点检查点标记每个输入流中的特定点以及每个运算符的相应状态。在保持一致性的同时，可以从检查点恢复惊人的数据流（只处理一次语义）通过恢复操作员的状态并从检查点重放记录。

检查点间隔是一种利用恢复时间（需要重放的记录数量）来权衡执行过程中容错开销的方法。

容错机制不断地绘制分布式流数据流的快照。对于状态较小的流式应用程序，这些快照非常轻，可以频繁绘制，不会对性能产生太大影响。流应用程序的状态存储在可配置的位置，通常存储在分布式文件系统中。

如果程序出现故障（由于机器、网络或软件故障），Flink会停止分布式流数据流。然后，系统重新启动操作员，并将其重置为最新成功的检查点。输入流将重置为状态快照的点。作为重新启动的并行数据流的一部分处理的任何记录都保证不会影响以前的检查点状态。

默认情况下，将禁用检查点设置。看见检查点有关如何启用和配置检查点的详细信息。

为了使该机制实现其完全保证，数据流源（如消息队列或代理）需要能够将流倒带到定义的最近点。Apache Kafka具有这种能力，Flink的Kafka连接器利用了这种能力。看见数据源和接收器的容错保证有关Flink连接器提供的担保的更多信息。

因为Flink的检查点是通过分布式快照实现的，所以我们使用快照和检查点可互换地。Oftenwe也使用这个术语快照意思是检查点或保存点.

检查点

Flink容错机制的核心部分是绘制分布式数据流和操作员状态的一致快照。这些快照作为一致的检查点，系统在出现故障时可以回退到这些检查点。Flink绘制这些快照的机制在分布式数据流的轻量级异步快照. 它的灵感来源于标准Chandy Lamport算法用于分布式快照，并专门针对Flink的执行模型进行定制。

请记住，与检查点相关的所有操作都可以异步完成。检查点屏障不会以锁定的方式移动，操作可以异步地快照它们的状态。

自Flink 1.11以来，可以在对齐或不对齐的情况下设置检查站。在本节中，我们首先描述对齐的检查点。

障碍

Flink的分布式快照中的一个核心元素是溪流屏障这些屏障被注入到数据流中并且与数据流的记录天冬氨酸一起流动。障碍永远不会超过记录，它们严格按照直线流动。屏障将数据流中的记录分为进入当前快照的记录集和进入下一个快照的记录。每个屏障都带有快照的ID，快照的记录被推到它前面。屏障不会中断流的流动，因此非常轻。来自不同快照的多个屏障可以同时在流中，这意味着各种快照可能同时发生。

流屏障被注入到流源处的并行数据流中。快照的障碍所在的点n被注入（我们称之为_Sn)是快照覆盖数据的源流中的位置。例如，在ApacheKafka中，这个位置将是分区中最后一条记录的偏移量。这个位置_Sn报告给检查点协调员（弗林克的工作经理）。

然后障碍物向下游流动。当中间操作员收到快照的载波时n从它的所有输入流中，它发出快照的屏障n进入其所有输出流。一旦汇点操作员（流式DAG的末端）接收到屏障n从其所有输入流中，它确认该快照n到检查点协调器。在所有天坑确认快照后，即视为已完成。

一次快照n已完成，该作业将不再向来源询问以前的记录_Sn，因为此时这些记录（及其子记录）将通过整个数据流拓扑。

接收多个输入流的运算符需要排列快照屏障上的输入流。上图说明了这一点：

操作员一收到快照屏障n从传入流中，在接收到屏障之前，它无法处理该流中的任何进一步记录n也来自其他输入。否则，它将混合属于快照的记录n以及属于快照的记录n+1.
一旦最后一个流接收到屏障n，操作员发出所有挂起的传出记录，然后发出快照n障碍本身。
它会对状态进行快照，并继续处理所有输入流中的记录，在处理来自流的记录之前处理来自输入缓冲区的记录。
最后，操作员将状态异步写入状态后端。

请注意，对于具有多个输入的所有运算符，以及当运算符使用多个上游子任务的输出流时，混洗后的运算符，都需要进行对齐。

快照操作状态

当运算符包含任何形式的状态，此状态也必须是快照的一部分。

操作员在从其输入流接收到所有快照屏障时以及在将屏障发射到其输出流之前，对其状态进行快照。在这一点上，在设置屏障之前，记录中的所有状态更新都已完成，而在应用屏障之后，没有依赖于记录的更新。因为快照的状态可能很大，所以它存储在可配置的状态后端。默认情况下，这是JobManager的内存，但对于生产使用，应配置分布式可靠存储（如HDFS）。在存储了状态之后，操作员确认检查点，将快照屏障发送到输出流中，然后继续。

生成的快照现在包含：

对于每个并行流数据源，启动快照时流中的偏移量/位置
对于每个操作符，一个指针指向作为快照一部分存储的状态

恢复

这种机制下的恢复很简单：失败后，Flink会选择最新完成的检查点k。然后，系统重新部署整个重新分发的数据流，并向每个操作员提供在检查点之前进行快照的状态k。源设置为开始从位置读取流_Sk例如，在Apache Kafka中，这意味着告诉消费者从偏移量开始获取_Sk.

如果状态是增量快照，则操作符从最新完整快照的状态开始，然后对该状态应用一系列增量快照更新。

看见重启策略了解更多信息。

未对齐的检查点

检查点也可以在不对齐的情况下执行。其基本思想是，只要飞行中的数据成为操作员状态的一部分，检查点就可以超越所有飞行中数据。

请注意，这种方法实际上更接近Chandy Lamport算法，但是Flink仍然在源中插入屏障，以避免检查点协调器过载。

该图描述了操作员如何处理未对齐的检查点屏障：

操作员对存储在其输入缓冲器中的第一个屏障作出反应。
它通过将其添加到输出缓冲器的末端，立即将屏障转发给下游操作员。
操作员将所有被超越的记录标记为异步存储，并创建自己状态的快照。

因此，操作员仅短暂停止对输入的处理，以标记缓冲区、转发屏障并创建其他状态的快照。

未对齐的检查点可以确保障碍物尽可能快地到达水槽。它特别适用于至少有一条缓慢移动的数据路径的应用程序，在这些应用程序中，对齐时间可能长达数小时。然而，由于它增加了额外的I/O压力，当到状态后端的I/O成为瓶颈时，它没有帮助。请参阅中更深入的讨论ops其他限制。

请注意，保存点将始终对齐。

未对齐的恢复

操作员首先恢复飞行中的数据，然后在未对齐的检查点中开始处理来自上游操作员的任何数据。除此之外，它执行的步骤与恢复对齐的检查点.

状态后端

存储键/值索引的确切数据结构取决于所选择的状态后端。一个状态后端将数据存储在内存中哈希映射中，另一个状态后台使用RocksDB作为密钥/值存储。除了定义保存状态的数据结构外，状态后端还实现了获取键/值状态的时间快照的逻辑，并将该快照存储为缓存点的一部分。可以在不更改应用程序逻辑的情况下配置状态后端。

保存点

所有使用检查点的程序都可以从保存点。保存点允许在不退出任何状态的情况下更新程序和Flink集群。

保存点是手动触发的检查点，获取程序的快照并将其写入状态后端。为此，它们依赖于常规的检查点机制。

保存点类似于检查点，不同之处在于由用户触发和不会自动过期当完成新的检查点时。

精确一次与至少一次

对准步骤可以增加流式节目的延迟。通常，这种额外的延迟大约为几毫秒，但我们已经看到一些异常值的延迟显著增加的情况。对于所有记录都需要持续超低延迟（几毫秒）的应用程序，Flink有一个开关可以在检查点期间跳过流对齐。一旦操作员看到每个输入的checkpointbarrier，检查点快照仍然会被绘制出来。

当跳过对齐时，操作员会继续处理所有输入，即使在检查点的一些检查点屏障之后也是如此n到了。这样，操作员还可以处理属于检查点的元素n+1检查点的状态快照之前n被带走。在还原时，这些记录将作为重复记录出现，因为它们都包含在检查点的状态快照中n，并将在检查点后作为数据的一部分重播n.

对齐仅适用于具有多个前置器（联接）的运算符以及具有多个发送方的运算符（在流重新分区/混洗之后）。正因为如此，数据流只有令人尴尬的并行流操作(地图, flatMap（）, 滤器，…）实际上很卫生正好一次即使在至少一次模式

批处理程序中的状态与容错

Flink执行批处理程序作为一个特殊的情况，其中流是有界的（有限数量的元素）。A.数据集在内部被视为数据流。因此，上述概念适用于批处理程序，其方式与应用于流化程序的方式相同，但有一些小的例外：

批处理程序的容错不使用检查点。恢复是通过完全重放流来实现的。这是可能的，因为输入是有界的。这将成本更多地推向恢复，但使常规处理更便宜，因为它避免了检查点。
数据集API中的状态操作使用简化的内存内/核心外数据结构，而不是键/值索引。
数据集API引入了特殊的同步（基于超级表的）迭代，这些迭代只能在有界流上实现。有关详细信息，请查看迭代文档.