Structured Streaming-编程模型

Structured Streaming的关键思想在于将实时数据流视为不断追加的表。这导致与批处理模型非常相似的流处理模型。我们可以在静态表上将流式计算表示为标准的batch-like查询，而Spark会在无界输入表上作为增量查询来运行它。

一 基本概念

将输入数据流视为“输入表”，到达流的每个数据项都像追加到输入表的新的一行。

对输入的查询将生成“结果表”。 每个触发间隔（例如：每1秒），新行将附加到输入表，最终更新结果表。 无论何时更新结果表，我们都希望将更改的结果行写入外部接收器。 

 

“输出”可以理解为写入外部存储器的内容，我们可以以不同的模式定义输出： 

• 完成模式（complete mode）：将整个更新的结果表写入外部存储，由存储连接器决定如何处理整个表的写入。 
• 追加模式（append mode）：将结果表中自上次触发后附加的新行写入外部存储，这适用于不期望更改结果表中现有行的查询。 
• 更新模式（update mode）：将自上次触发以来在结果表中更新的行写入外部存储（Spark 2.1.1开始可用）。注意，这与完全模式不同，因为此模式仅输出自上次触发以来更改的行。 如果查询不包含聚合，它将等同于附加模式。

为了说明这个模型的使用，我们结合入门中的wordCounts程序来理解这个模型。lines这个DataFrame是输入表，最后的wordCounts DataFrame是结果表。 请注意，Streaming lines DataFrame生成wordCounts的查询与静态DataFrame完全相同。 但是当该查询启动时，Spark将连续检查socket连接中的新数据。 如果有新数据，Spark将运行一个“增量”查询，将以前的running counts与新数据相结合，去计算更新的counts，如下所示：

 

请注意，Structured Streaming不会实现整个表。它从流数据源读取最新的可用数据，递增地处理它以更新结果，然后丢弃源数据。它只根据更新结果所需的最小中间状态数据（例如，前面示例中的中间计数）保持不变。

这种模式与许多其他流处理引擎有显着差异。 许多流系统要求用户自己维护运行的聚合，因此必须对容错和数据一致性（at-least-once, or at-most-once, or exactly-once）进行说明。 在这个模型中，当有新数据时，Spark负责更新结果表，从而减轻用户的负担。 

二 处理基于Event-time以及后期数据

Event-time是数据本身嵌入的时间。对于许多应用程序来说，我们可能需要在此event-time进行操作。 例如，如果要每分钟获取IoT设备生成的事件数，则可能希望使用数据生成的时间（即数据中的event-time），而不是Spark接收到它们的时间 。 这个event-time在这个模型中非常自然地表现出来 - 来自设备的每个事件都是表中的一行，event-time是行中的列值。 这允许window-based的聚合（例如，每分钟的事件数）作为event-time列上的特殊类型的分组和聚合 - 每个时间窗口是一个组，每一行可以属于多个窗口/组。 因此，可以在静态数据集（例如来自收集的设备事件日志）以及数据流上一致地定义基于event-time-window-based的聚合查询，从而使用户的使用寿命更加容易。 
此外，该模型自然地处理晚于event-time到达的数据。 由于Spark正在更新结果表，所以当有迟到的数据它可以完全控制更新旧的聚合，以及清理旧的聚合以限制中间状态数据的大小。 从Spark 2.1开始，我们支持watermarking ，允许用户指定迟到数据的阈值，并允许引擎相应地清理旧状态。 

三 容错语义

提供end-to-end exactly-once语义是Structured Streaming设计背后的关键目标之一。 为了实现这一点，我们设计了structured streaming的sources，sinks和执行引擎，可靠地跟踪处理进程的准确进度，以便它可以通过重新启动和/或重新处理来解决任何类型的故障。 假设每个Streaming源具有跟踪流中读取位置的偏移（类似于Kafka偏移或Kinesis序列号）。 引擎使用检查点和WAL（write ahead logs）记录每个触发器中正在处理的数据的偏移范围。 Streaming sinks为了解决重复计算被设计为幂等。 一起使用可重放sources和幂等sinks，Structured Streaming可以在任何故障下确保end-to-end exactly-once的语义。