论文笔记：Structured Streaming: A Declarative API for Real-Time Applications in Apache Spark

一、引言

1. 早期的流处理系统存在两个问题：
   (1). 系统需要用户去考虑复杂的物理执行概念，比如at-least-once delivery、状态存储、触发模式等流处理独有的概念。
   (2). 许多系统只关注流计算这一件事，然而在实际应用场景中，流处理仅仅是一个大型商业应用程序的一部分，该应用程序同时还会包括批处理、静态数据连接和交互式查询等处理流程。

2. 论文贡献：为流数据处理描述了一个高层次的API —— 结构化流媒体（Structured Streaming），该API于2016年由Apache Spark开发。

   借鉴了近期流处理系统的许多思想，比如①将处理时间从触发器和事务时间中分离出来；②为了性能使用了关系型执行引擎；③提供了集成化语言的API。

   创新点：
   （1）提供增量查询模型：通过Spark SQL，可以自动增量化查询静态数据。
   （2）支持端到端的应用：

二、流处理的挑战

1. 复杂性和低层次的API：由于其复杂的语义，用户总认为流处理系统不如批处理系统容易使用，这些复杂性一方面来源于某些仅在数据流处理中存在的新的概念，比如，在收到与某种特定实体相关的全部数据之前，用户就需要考虑好应该输出什么类型的中间结果，另一方面来源于低层次的API，这些API总是要求用户从物理操作元的层面来描述自己特定的应用程序，且语义十分复杂。

Google Dataflow有强大的API，其拥有十分丰富的选项来处理事务时间聚合、窗口机制和无序数据。
然而在操作上，它需要用户指定具体的窗口模式和触发模式，然后再为每一个聚合操作元触发由用户定制的这种模式。
其他的API也依靠操作元的DAG来表达逻辑。

2. 在端到端应用程序中的集成： 目前多数Stream API着重关注的是如何从数据源读取数据流，以及如何将数据流输出到sink中，但是商业的端到端应用程序需要的是更多其他的任务。
   （1）在最新的数据上进行交互式查询。此时，流式作业的作用是要在结构化存储（如RDBM或Hive）中实现对汇总表的更新。
   （2）ETL作业中需要用到流处理。
   （3）某些团队有时会需要把流媒体业务逻辑作为批处理应用程序来运行。
3. 操作层面的挑战：容错率、代码更新、可伸缩性、节点淘汰机制、监控机制。

三、Structured Streaming总览

1. 输入和输出设置： 可连接至多种输入源和输出接收器，与现有的 “exactly-once"系统类似，用两点来保证此性能以及容错率——（1）连接的输入源是可重放的，即当有节点崩溃的时候，系统可以重读最近的输入数据（通常会使用可靠的消息传输系统如Kafka）；（2）输出接收器支持幂等写入，以保证可靠恢复。

   此外，Structured Streming同时支持连接Spark SQL中的表格的输入和输出。

2. API：用批处理的方式来处理数据流。

   用户用SQL来编写自己的业务逻辑，实现对stream 和 table 的查询，而论文中的API将其视为定义了一个输出表，同时在处理时用table来代替输入stream中的所有数据，然后由引擎来决定如何对该表进行增量查询与更新

   为了支持流数据处理，SS在现有的Spark SQL API中添加了一些针对流处理的特性，包括（1）用触发器来控制引擎计算新结果和更新输出接收器的频率；（2）可以标记事务时间列，同时设置watermark策略（类似窗口机制）；（3）添加状态操作符。

3. 执行： 一旦收到查询，SS会优化该查询，使之增量化，然后开始执行它。默认情况下，系统使用类似于Spark Streaming中的microbatch模型（支持动态负载平衡，缩放，故障恢复和零散缓解）来计算。
   容错率保障： 用了两种持久化存储。（1）预写日志，用于追踪是否已可靠写入输出接收器中；（2）大规模状态存储库，用于保存 operator 状态的快照。

4. 操作特征： 两种持久化存储使之可以实现回滚与快速恢复；执行微批次的能力使之能自适应地批量处理数据。

四、编程模型

当用户从流媒体数据源读取数据并使用Spark SQL建表尝试计算时，Spark会自动启动流媒体服务。

1. 语义：
   （1） 每个输入源提供一组随时间部分有序的记录
   （2） 用户提供查询语句，跨输入数据地执行命令，最终输出结果表；
   （3） 触发器是告知系统，何时对结果表执行一个新的增量化计算和更新；
   （4） 三种输出模式：Complete将文件完全重写。Append追加数据到结果表。Update根据key来更新结果表。

   用 prefix consistency 来实现一致性

   关于Execution： Structured Streaming 的做法是：

   • 引入全局范围、高可用的 StateStore
   • 转全量为增量，即在每次执行时：
     • 先从 StateStore 里 restore 出上次执行后的状态
     • 加入本执行的新数据，再进行计算
     • 如果有状态改变，将把改变的状态重新 save 到 StateStore 里

   所以 Structured Streaming 在编程模型上暴露给用户的是，每次持续查询看做面对全量数据，但在具体实现上转换为增量的持续查询。

---

2. 流媒体特殊操作元：
   （1） 事务时间水印
   （2） 状态操作员

五、查询规划

由三个部分组成：分析查询是否有效，增量化，优化。