一、引言
早期的流处理系统存在两个问题：
(1). 系统需要用户去考虑复杂的物理执行概念，比如at-least-once delivery、状态存储、触发模式等流处理独有的概念。
(2). 许多系统只关注流计算这一件事，然而在实际应用场景中，流处理仅仅是一个大型商业应用程序的一部分，该应用程序同时还会包括批处理、静态数据连接和交互式查询等处理流程。-
论文贡献：为流数据处理描述了一个高层次的API —— 结构化流媒体（Structured Streaming），该API于2016年由Apache Spark开发。
借鉴了近期流处理系统的许多思想，比如①将处理时间从触发器和事务时间中分离出来；②为了性能使用了关系型执行引擎；③提供了集成化语言的API。
创新点：
（1）提供增量查询模型：通过Spark SQL，可以自动增量化查询静态数据。
（2）支持端到端的应用：
二、流处理的挑战
- 复杂性和低层次的API：由于其复杂的语义，用户总认为流处理系统不如批处理系统容易使用，这些复杂性一方面来源于某些仅在数据流处理中存在的新的概念，比如，在收到与某种特定实体相关的全部数据之前，用户就需要考虑好应该输出什么类型的中间结果，另一方面来源于低层次的API，这些API总是要求用户从物理操作元的层面来描述自己特定的应用程序，且语义十分复杂。
Google Dataflow有强大的API，其拥有十分丰富的选项来处理事务时间聚合、窗口机制和无序数据。
然而在操作上，它需要用户指定具体的窗口模式和触发模式，然后再为每一个聚合操作元触发由用户定制的这种模式。
其他的API也依靠操作元的DAG来表达逻辑。
-
在端到端应用程序中的集成： 目前多数Stream API着重关注的是如何从数据源读取数据流，以及如何将数据流输出到sink中，但是商业的端到端应用程序需要的是更多其他的任务。
（1）在最新的数据上进行交互式查询。此时，流式作业的作用是要在结构化存储（如RDBM或Hive）中实现对汇总表的更新。
（2）ETL作业中需要用到流处理。
（3）某些团队有时会需要把流媒体业务逻辑作为批处理应用程序来运行。 - 操作层面的挑战：容错率、代码更新、可伸缩性、节点淘汰机制、监控机制。
三、Structured Streaming总览
-
输入和输出设置： 可连接至多种输入源和输出接收器，与现有的 “exactly-once"系统类似，用两点来保证此性能以及容错率——（1）连接的输入源是可重放的，即当有节点崩溃的时候，系统可以重读最近的输入数据（通常会使用可靠的消息传输系统如Kafka）；（2）输出接收器支持幂等写入，以保证可靠恢复。
此外，Structured Streming同时支持连接Spark SQL中的表格的输入和输出。
-
API：用批处理的方式来处理数据流。
用户用SQL来编写自己的业务逻辑，实现对stream 和 table 的查询，而论文中的API将其视为定义了一个输出表，同时在处理时用table来代替输入stream中的所有数据，然后由引擎来决定如何对该表进行增量查询与更新
为了支持流数据处理，SS在现有的Spark SQL API中添加了一些针对流处理的特性，包括（1）用触发器来控制引擎计算新结果和更新输出接收器的频率；（2）可以标记事务时间列，同时设置watermark策略（类似窗口机制）；（3）添加状态操作符。
执行： 一旦收到查询，SS会优化该查询，使之增量化，然后开始执行它。默认情况下，系统使用类似于Spark Streaming中的microbatch模型（支持动态负载平衡，缩放，故障恢复和零散缓解）来计算。
容错率保障： 用了两种持久化存储。（1）预写日志，用于追踪是否已可靠写入输出接收器中；（2）大规模状态存储库，用于保存 operator 状态的快照。操作特征： 两种持久化存储使之可以实现回滚与快速恢复；执行微批次的能力使之能自适应地批量处理数据。
四、编程模型
当用户从流媒体数据源读取数据并使用Spark SQL建表尝试计算时，Spark会自动启动流媒体服务。
-
语义：
（1） 每个输入源提供一组随时间部分有序的记录
（2） 用户提供查询语句，跨输入数据地执行命令，最终输出结果表；
（3） 触发器是告知系统，何时对结果表执行一个新的增量化计算和更新；
（4） 三种输出模式：Complete将文件完全重写。Append追加数据到结果表。Update根据key来更新结果表。用 prefix consistency 来实现一致性
关于Execution： Structured Streaming 的做法是：
- 引入全局范围、高可用的 StateStore
- 转全量为增量，即在每次执行时：
- 先从 StateStore 里 restore 出上次执行后的状态
- 加入本执行的新数据，再进行计算
- 如果有状态改变，将把改变的状态重新 save 到 StateStore 里
所以 Structured Streaming 在编程模型上暴露给用户的是，每次持续查询看做面对全量数据，但在具体实现上转换为增量的持续查询。
-
流媒体特殊操作元：
（1） 事务时间水印
（2） 状态操作员
五、查询规划
由三个部分组成：分析查询是否有效，增量化，优化。
