1 Spark Streaming 不足
Apache Spark在2016年的时候启动了Structured Streaming项目，一个基于Spark SQL的全新流计算引擎Structured Streaming，让用户像编写批处理程序一样简单地编写高性能的流处理程序。
个人总结:spark Streaming就是对RDD进行批量处理,Structured Streaming就相当于SparkSql一样进行操作,并且更加完善的函数.
Structured Streaming并不是对Spark Streaming的简单改进，而是吸取了在开发SparkSQL和Spark Streaming过程中的经验教训，以及Spark社区和Databricks众多客户的反馈，重新开发的全新流式引擎，致力于为批处理和流处理提供统一的高性能API。同时，在这个新的引擎中，也很容易实现之前在Spark Streaming中很难实现的一些功能，比如EventTime（事件时间）的支持，Stream-Stream Join（2.3.0 新增的功能），毫秒级延迟（2.3.0即将加入的 Continuous Processing）。
Spark Streaming是Apache Spark早期基于RDD开发的流式系统，用户使用DStream API来编写代码，支持高吞吐和良好的容错。其背后的主要模型是Micro Batch（微批处理），也就是将数据流切成等时间间隔（BatchInterval）的小批量任务来执行。
Structured Streaming则是在Spark 2.0加入的，经过重新设计的全新流式引擎。它的模型十分简洁，易于理解。一个流的数据源从逻辑上来说就是一个不断增长的动态表格，随着时间的推移，新数据被持续不断地添加到表格的末尾，用户可以使用Dataset/DataFrame 或者 SQL 来对这个动态数据源进行实时查询。
文档：http://spark.apache.org/docs/2.4.5/structured-streaming-programming-guide.html
Spark Streaming 会接收实时数据源的数据，并切分成很多小的batches，然后被Spark Engine执行，产出同样由很多小的batchs组成的结果流。
本质上，这是一种micro-batch（微批处理）的方式处理，用批的思想去处理流数据。这种设计让Spark Streaming面对复杂的流式处理场景时捉襟见肘。
Spark Streaming 存在哪些不足，总结一下主要有下面几点：
第一点：使用 Processing Time 而不是 Event Time
Processing Time 是数据到达 Spark 被处理的时间，而 Event Time 是数据自带的属性，
一般表示数据产生于数据源的时间。
比如 IoT 中，传感器在 12:00:00 产生一条数据，然后在 12:00:05 数据传送到 Spark，
那么 Event Time 就是 12:00:00，而 Processing Time 就是 12:00:05。
Spark Streaming是基于DStream模型的micro-batch模式，简单来说就是将一个微小时间段（比如说 1s）的流数据当前批数据来处理。如果要统计某个时间段的一些数据统计，毫无疑问应该使用 Event Time，但是因为 Spark Streaming 的数据切割是基于Processing Time，这样就导致使用 Event Time 特别的困难。
第二点：Complex, low-level api
DStream（Spark Streaming 的数据模型）提供的API类似RDD的API，非常的low level；
当编写Spark Streaming程序的时候，本质上就是要去构造RDD的DAG执行图，然后通过
Spark Engine运行。这样导致一个问题是，DAG 可能会因为开发者的水平参差不齐而导
致执行效率上的天壤之别；
第三点：reason about end-to-end application
end-to-end指的是直接input到out，如Kafka接入Spark Streaming然后再导出到HDFS中；
DStream 只能保证自己的一致性语义是 exactly-once 的，而 input 接入 Spark
Streaming 和 Spark Straming 输出到外部存储的语义往往需要用户自己来保证；
第四点：批流代码不统一
尽管批流本是两套系统，但是这两套系统统一起来确实很有必要，有时候确实需要将的流
处理逻辑运行到批数据上面；
Streaming尽管是对RDD的封装，但是要将DStream代码完全转换成RDD还是有一点工作
量的，更何况现在Spark的批处理都用DataSet/DataFrameAPI；
流式计算一直没有一套标准化、能应对各种场景的模型，直到2015年Google发表了The
Dataflow Model的论文（ https://yq.aliyun.com/articles/73255 ）。Google开源Apache Beam项
目，基本上就是对Dataflow模型的实现，目前已经成为Apache的顶级项目，但是在国内使用不多。
国内使用的更多的是Apache Flink，因为阿里大力推广Flink，甚至把花7亿元把Flink母公司收购。
使用Yahoo的流基准平台，要求系统读取广告点击事件，并按照活动ID加入到一个广告活动的
静态表中，并在10秒的event-time窗口中输出活动计数。比较了Kafka Streams 0.10.2、Apache Flink1.2.1和Spark 2.3.0，在一个拥有5个c3.2*2大型Amazon EC2 工作节点和一个master节点的集群上（硬件条件为8个虚拟核心和15GB的内存）。
上图(a)展示了每个系统最大稳定吞吐量（积压前的吞吐量），Flink可以达到3300万，而
Structured Streaming可以达到6500万，近乎两倍于Flink。这个性能完全来自于Spark SQL的内置
执行优化，包括将数据存储在紧凑的二进制文件格式以及代码生成。
2 Structured Streaming 概述
或许是对Dataflow模型的借鉴，也许是英雄所见略同，Spark在2.0版本中发布了新的流计算的
API：Structured Streaming结构化流。Structured Streaming是一个基于Spark SQL引擎的可扩展、容错的流处理引擎。统一了流、批的编程模型，可以使用静态数据批处理一样的方式来编写流式计算操作，并且支持基于event_time的时间窗口的处理逻辑。随着数据不断地到达，Spark 引擎会以一种增量的方式来执行这些操作，并且持续更新结算结果。
2.1 模块介绍
Structured Streaming 在 Spark 2.0 版本于 2016 年引入，设计思想参考很多其他系统的思想，比如区分 processing time 和 event time，使用 relational 执行引擎提高性能等。同时也考虑了和 Spark 其他组件更好的集成。
Structured Streaming 和其他系统的显著区别主要如下：
第一点：Incremental query model（增量查询模型）
Structured Streaming 将会在新增的流式数据上不断执行增量查询，同时代码的写法和批处理 API（基于Dataframe和Dataset API）完全一样，而且这些API非常的简单。
第二点：Support for end-to-end application（支持端到端应用）
Structured Streaming 和内置的 connector 使的 end-to-end 程序写起来非常的简单，而且 “correct by default”。数据源和sink满足 “exactly-once” 语义，这样我们就可以在此基础上更好地和外部系统集成。
第三点：复用 Spark SQL 执行引擎
Spark SQL 执行引擎做了非常多的优化工作，比如执行计划优化、codegen、内存管理等。这也是Structured Streaming取得高性能和高吞吐的一个原因。
1.2.2 核心设计
2016年，Spark在2.0版本中推出了结构化流处理的模块Structured Streaming，核心设计如下：
第一点：Input and Output（输入和输出）
Structured Streaming 内置了很多 connector 来保证 input 数据源和 output sink 保证 exactly-once 语义。
实现 exactly-once 语义的前提：
Input 数据源必须是可以replay的，比如Kafka，这样节点crash的时候就可以重新读
取input数据，常见的数据源包括 Amazon Kinesis, Apache Kafka 和文件系统。
Output sink 必须要支持写入是幂等的，这个很好理解，如果 output 不支持幂等写入，那么一致性语义就是 at-least-once 了。另外对于某些 sink, StructuredStreaming 还提供了原子写入来保证 exactly-once 语义。
补充：幂等性：在HTTP/1.1中对幂等性的定义：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。
第二点：Program API（编程 API）
Structured Streaming 代码编写完全复用 Spark SQL 的 batch API，也就是对一个或者多个 stream 或者 table 进行 query。
query 的结果是 result table，可以以多种不同的模式（追加：append, 更新：update, 完全：complete）输出到外部存储中。
另外，Structured Streaming 还提供了一些 Streaming 处理特有的 API：Trigger,watermark, stateful operator。
第三点：Execution Engine（执行引擎）
复用 Spark SQL 的执行引擎；
Structured Streaming 默认使用类似 Spark Streaming 的 micro-batch 模式，有很多好
处，比如动态负载均衡、再扩展、错误恢复以及 straggler （straggler 指的是哪些执行明显慢于其他 task 的 task）重试；
提供了基于传统的 long-running operator 的 continuous（持续） 处理模式；
第四点：Operational Features（操作特性）
利用 wal 和状态State存储，开发者可以做到集中形式的 rollback 和错误恢复FailOver。
