Spark综合学习笔记（三十）Structured Streaming引入

学习致谢：

https://www.bilibili.com/video/BV1Xz4y1m7cv?p=67

学习目标

SparkStreaming的不足

Spark Streaming是Apache Spark早期基于RDD开发的流式系统，用户使用DStream API来编写代码，支持高吞吐和良好的容错。但随着技术的发展，逐渐暴露出很多的不足:
1:基于微批，延迟高，不能做的真正的实时
Spark Streaming会接收实时数据源的数据，并切分成很多小的batches，然后被Spark Engine执行，产出同样由很多小的batchs组成的结果流。

本质上，这是一种micro-batch(微批处理）的方式处理，用批的思想去处理流数据。这种设计让Spark Streaming面对复杂的流式处理场景时捉襟见肘。
2: API基于底层复杂的RDD，不直接支持简单的SQL
DStream (Spark Streaming的数据模型）提供的API类似RDD的API，非常的low level;
当编写Spark Streaming程序的时候，本质上就是要去构造RDD的DAG执行图，然后通过Spark Engine运行。这样导致一个问题是，DAG可能会因为开发者的水平参差不齐而导致执行效率上的天壤之别;
3∶不支持Event Time

Processing Time 是数据到达Spark被处理的时间，而Event Time是数据自带的属性，一般表示数据产生于数据源的时间。
比如IloT中，传感器在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，但是因为SparkStreaming 的数据切割是基于Processing Time，这样就导致使用Event Time特别的困难。
4:批流代码不统一
尽管批流本是两套系统，但是这两套系统统一起来确实很有必要，有时候确实需要将的流处理逻辑运行到批数据上面;Streaming尽管是对RDD的封装，但是要将DStream代码完全转换成RDD还是有一点工作量的，更何况现在Spark的批处理都用DataSet/DataFrameAPI;
5:需要用户自己实现end-to-end的exactly-once
end-to-end指的是input到out，如Kafka接入Spark Streaming然后再导出到HDFS中;
DStream只能保证自己的一致性语义是exactly-once的，而 input接入Spark Streaming和Spark Straming 输出到外部存储的语义往往需要用户自己来保证;