来源Spark官方文档
http://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#programming-model

编程模型

结构化流中的核心概念就是将活动数据流当作一个会不断增长的表。这是一个新的流处理模型，但是与批处理模型很相似。你在做流式计算就像是标准针对静态表的批查询，Spark会在一个无限输入的表上进行增量查询。我们来从更多详细内容来理解这个模型。

基本概念

将输入的数据流理解为“写入表”，每个流中到达的数据就像是写入表中新增的一行。

Stream as a Table

针对输入的查询会生成“结果表”。每个触发间隔之间（比如1秒钟），就会有新的行添加到“写入表”，最终更新结果表。当结果表变更后，我们能够将变更的结果行写入外部存储。

Model

“输出（Output）”定义为写入外部存储的内容。输出存在几种模式：

• 完全模式（Complete Mode） ：整个更新后的结果表会全部写入外部存储。具体的全表写入方式取决于与存储的底层连接。

• 增量模式（Append Mode） ：从上次触发后的新增结果表数据才会写入外部存储。这个模式只适用于那些预期结果表中的存量数据不会变化的查询。

• 更新模式（Update Mode） ： 从上次触发后的更新结果表数据才会写入外部存储（从Spark 2.1.1开始生效）。注意本模式和完全模式的差异，本模式下只会输出上次触发后的变更行。如果查询不包含聚合，基本会和增量模式相同。

要注意每个模式都有确定的适配的查询，这个会在稍后讨论。

为了解释这个模型的使用方式，我们用上面的快速示例来辅助理解模型。第一个DataFrame类型的变量 line 就是写入表，而最后DataFrame类型的变量 wordCounts 就是结果表。注意针对流的查询方法，从 line 生成 wordCounts 和一个静态的DataFrame完全相同。当查询开始之后，Spark会持续检查从socket链接传入的新数据。如果存在新数据，Spark会运行“增量”查询，并且针对新数据计算更新的计数，整合之前运行的计数，如下图所示。

Model

注意结构化流并没有存储整张表。从数据源读取最近有效的数据，增量的处理并且更新结果数据，然后丢弃源数据。Spark只保留最小中间状态数据，用于更新结果（例如上面例子中的中间统计结果计数）。

这个模型明显和其他的流处理引擎不同。许多流处理系统要求用户自行维护运行聚合，因为有诸如容错性（fault-tolerance）、数据一致性（data consistency：at-least-once, at-most-once, exactly-once）。在这个模型中，当有新数据时，由Spark负责更新结果表，因此解放了用户无需关注。我们以模型处理事件时间和延迟数据作为例子来看下。

处理事件时间和延迟数据

事件时间是包含在数据本身的。很多应用都希望基于事件时间操作。例如你的想要获取物联网设备每分钟产生事件数量，然后你可能希望使用数据生成的时间（这就是事件时间），而不是Spark接收到他们的时间。事件时间在这个模型中是很自然的，因为每个设备产生事件都是都是表中的一行数据，而事件时间就是一行数据中的一列。这样基于窗口的聚合（例如每分钟的事件数量）可以作为基于事件时间列做的特别的分组和聚合。每个时间窗口都是一个分组，每行数据也可以属于多个窗口或分组。因此类似这种基于事件时间的聚合查询能够在静态数据集（例如收集的设备事件日志）和动态数据流，能够是用户的使用比较简单。

此外模型天然的能够基于事件时间处理延迟到达的数据。当Spark更新结果表时，他仍然能够针对延迟数据来更新历史聚合的结果，也同时可以清除历史聚合数据，从而限制中间状态数据的大小。从Spark2.1开始，我们支持水位线概念（watermarking），允许用户指定延迟数据的阈值，系统也能够清理旧状态数据。稍后会在窗口操作章节介绍。

容错性

保证唯一投送端到端是结构化流的设计中的关键目标之一。为了达成这样的目标，我们设计了结构化流的源（Source）、汇（Sink）以及执行引擎能够可靠的跟踪处理进度，从而能够重启/重新处理来应对各种故障。每个数据流的源应该都有偏移量概念（类似Kafka的偏移量，或者Amazon Kinesis 的序列编号）来跟踪流中的读取位置。引擎使用保存点和先写日志来记录每次处理的数据偏移边界。流的汇设计天然就支持重新处理的幂等性。整合起来，使用可重放的源与幂等的汇，结构化流在面对任何故障时都能保证端对端严格一致性（end-to-end exactly-once semantics）。