大数据学习（31）—— flink流处理

这一篇很难懂，我也不懂。

有状态流处理

虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但有些操作会记住多个事件的信息（例如窗口操作符）。这些操作称为有状态的。

有状态操作的一些示例：

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

键控状态

键控状态保持在可以被认为是嵌入式键/值存储的东西中。状态与有状态操作符读取的流一起被严格地划分和分布。因此，只能在键控流上访问键/值状态，即在键控/分区数据交换之后，并且仅限于与当前事件的键相关联的值。对齐流和状态的键可确保所有状态更新都是本地操作，保证一致性而没有事务开销。这种对齐还允许Flink重新分配状态并透明地调整流分区。我想说，这个介绍就不能通俗一点，这说的啥玩意儿。

Keyed State 被进一步组织成所谓的Key Groups。Key Groups 是 Fl​​ink 可以重新分配 Keyed State 的原子单元；有与定义的最大并行度一样多的密钥组。在执行期间，键控运算符的每个并行实例都使用一个或多个键组的键。 

状态持久化

Flink 使用流重放和检查点的组合来实现容错，通俗地说，就是快照和redo日志。检查点标记每个输入流中的特定点以及每个操作符的相应状态。数据流可以从检查点恢复，同时通过恢复操作符的状态，从检查点重放记录来保持一致性（恰好一次处理语义）。

检查点间隔是一种权衡执行期间容错开销与恢复时间（需要重放的记录数）的方法。

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

如果程序出现故障（由于机器、网络或软件故障），Flink 会停止分布式数据流。然后系统重新启动操作并将它们重置为最新的成功检查点。输入流被重置到状态快照的点。

检查点

Flink 容错机制的核心部分是绘制分布式数据流和算子状态的一致快照。这些快照充当一致的检查点，系统可以在出现故障时回退到这些检查点。

请记住，与检查点有关的一切都可以异步完成。检查点屏障不会在锁定步骤中移动，操作可以异步快照它们的状态。

屏障

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

流屏障被注入到源的并行数据流中。快照n的屏障被注入的点（我们称之为 S_n）是源中快照覆盖数据的位置。例如，在 Apache Kafka 中，此位置将是分区中最后一条记录的偏移量。这个位置S_n 报告给检查点协调器（Flink 的 JobManager）。

然后屏障向下游流动。当中间操作符从其所有输入流中接收到快照n的屏障时，它会将快照n的屏障发送到其所有输出流中。一旦接收器操作符（流 DAG 的末尾）从其所有输入流中接收到屏障n，它就会向检查点协调器确认快照n。在所有接收器确认快照后，它被认为已完成。

一旦快照n完成，作业将永远不会再向源询问S_n之前的记录。

 

接收多个输入流的操作符需要在快照屏障上对齐输入流。上图说明了这一点：

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

请注意，所有具有多个输入的操作符以及在使用多个上游子任务的输出流时经过 shuffle 后的操作符都需要对齐。

快照状态

当操作符包含任何形式的state 时，这个 state 也必须是快照的一部分。

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

生成的快照现在包含：

• 对于每个并行流数据源，快照开始时在流中的偏移/位置
• 对于每个运算符，指向作为快照一部分存储的状态的指针

 

恢复

这种机制下的恢复很简单：发生故障时，Flink 选择最新完成的检查点k。然后系统重新部署整个分布式数据流，并为每个操作提供作为检查点k一部分的快照状态。源被设置为从位置S_k开始读取流。例如在 Apache Kafka 中，这意味着告诉消费者从偏移量S_k开始获取。

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

未对齐的检查点

检查点也可以不对齐地执行。基本思想是，只要动态数据成为操作状态的一部分，检查点就可以超越所有动态数据。

 

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

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

因此，操作只是简单地停止处理输入以标记缓冲区，转发屏障，并创建另一个状态的快照。

状态后端

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

保存点

所有使用检查点的程序都可以从保存点恢复执行。保存点是手动触发的检查点，它获取程序的快照并将其写出到状态后端，它们依赖于常规的检查点机制。

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

恰好一次 vs 至少一次

对齐步骤可能会给流媒体程序增加延迟。通常，这种额外的延迟大约是几毫秒，但我们已经看到一些显著增加的异常延迟情况。对于要求所有记录始终保持超低延迟（几毫秒）的应用程序，Flink 有一个开关可以在检查点期间跳过流对齐。一旦操作从每个输入中看到检查点屏障，检查点快照仍然会被保存。

当跳过对齐时，操作继续处理所有输入，即使在检查点n 的一些检查点屏障到达之后也是如此。在还原时，将在检查点n之后作为数据的一部分重放。

及时流处理

官网把Timely stream翻译成及时流，感觉怪怪的。

及时流处理是有状态流处理的扩展，其中时间在计算中起一定作用。除其他外，当您进行时间序列分析、基于特定时间段（通常称为窗口）进行聚合时，或者当您进行事件发生时间很重要的事件处理时，就会出现这种情况。

在下面的部分中，我们将重点介绍在使用及时的 Flink 应用程序时应该考虑的一些主题。

事件时间和处理时间

在流媒体程序中提及时间时（例如定义窗口），可以指代不同的时间概念：

• 处理时间：处理时间是指正在执行相应操作的机器的系统时间。

  当流程序按处理时间运行时，所有基于时间的操作（如时间窗口）将使用运行相应算子的机器的系统时钟。每小时处理时间窗口将包括在系统时钟指示整小时之间到达特定操作员的所有记录。例如，如果应用程序在上午 9:15 开始运行，则第一个每小时处理时间窗口将包括上午 9:15 至上午 10:00 之间处理的事件，下一个窗口将包括上午 10:00 至上午 11:00 之间处理的事件，依此类推在。

  处理时间是最简单的时间概念，不需要流和机器之间的协调。它提供最佳性能和最低延迟。然而，在分布式和异步环境中，处理时间不提供确定性，因为它容易受到记录到达系统（例如来自消息队列）的速度，以及记录在系统内部操作之间流动的速度的影响，以及中断影响。

• 事件时间：事件时间是每个单独事件在其产生设备上发生的时间。这个时间通常在记录进入 Flink 之前嵌入在记录中，并且可以从每条记录中提取该事件时间戳。在事件时间中，时间的进度取决于数据，而不是任何挂钟。事件时间程序必须指定如何生成事件时间水印，这是一种表示事件时间进度的机制。

  在完美的世界中，事件时间处理将产生完全一致和确定性的结果，无论事件何时到达，或它们的顺序如何。但是，除非已知事件按顺序到达（按时间戳），否则事件时间处理在等待乱序事件时会产生一些延迟。由于只能等待有限的时间段，因此这限制了确定性事件时间应用程序的能力。

  假设所有数据都已到达，事件时间操作将按预期运行，即使在处理乱序或延迟事件，或重新处理历史数据时，也会产生正确且一致的结果。例如，每小时事件时间窗口将包含所有带有属于该小时的事件时间戳的记录，无论它们到达的顺序或处理时间如何。

  有时当事件时间程序实时处理实时数据时，它们会使用一些处理时间操作以保证它们及时进行。

事件时间和水印

支持事件时间的流处理器需要一种方法来衡量事件时间的进度。例如，当事件时间超过一小时结束时，需要通知构建每小时窗口的操作，以便可以关闭正在进行的窗口。

事件时间可以独立于处理时间（由挂钟测量）进行。例如，在一个程序中，操作的当前事件时间可能稍微落后于处理时间（考虑到接收事件的延迟），而两者以相同的速度进行。另一方面，另一个流程序可能会在几周的事件时间中进行，只需几秒钟的处理，通过快速转发一些已经缓冲在 Kafka 主题（或另一个消息队列）中的历史数据。

Flink 中衡量事件时间的机制是水印。水印作为数据流的一部分并带有时间戳t。水印(t)表示数据流中在时刻t到达的事件，这意味着该流中不存在时间戳 t'<=t的元素。

下图展示了带有（逻辑）时间戳和内联流水印的事件流。在这个例子中，事件是有序的，这意味着水印只是流中的周期性标记。

 

水印对于乱序流至关重要，如下图所示，其中事件不是按时间戳排序的。一般来说，水印是一种声明，即到流中的那个点，直到某个时间戳的所有事件都应该已经到达。一旦水印到达，操作就可以将其内部事件时钟提前到水印的值。

迟到

某些元素可能会违反水印条件，这意味着即使在Watermark(t)发生之后，也会出现更多时间戳为t' <= t 的元素。事实上，在许多现实世界的设置中，某些元素可以任意延迟，因此无法指定某个事件时间戳的所有元素将发生的时间。此外，即使可以限制延迟，将水印延迟太多通常也是不可取的。

出于这个原因，流媒体程序可能会明确地期待一些后期元素。迟到的元素是在系统的事件时间时钟（由水印发出信号）已经超过迟到元素的时间戳时间之后到达的元素。

开窗

聚合事件（例如，计数、总和）在流上的工作方式与在批处理中的工作方式不同。例如，不可能对流中的所有元素进行计数，因为流通常是无限的（无界）。相反，流上的聚合（计数、总和等）由窗口限定范围，例如 “过去 5 分钟内的计数”或“最后 100 个元素的总和”。

窗口可以是时间驱动的（例如：每 30 秒）或数据驱动的 （例如：每 100 个元素）。通常区分不同类型的窗口，例如滚动窗口（无重叠）、滑动窗口（有重叠）和会话窗口（由不活动的间隙打断）。