本文原文出处: http://blog.csdn.net/bluishglc/article/details/80423323 严禁任何形式的转载，否则将委托CSDN官方维护权益！
从Spark 2.0开始，Spark Streaming引入了一套新的流计算编程模型：Structured Streaming，开发这套API的主要动因是自Spark 2.0之后，以RDD为核心的API逐步升级到Dataset/DataFrame上，而另一方面，以RDD为基础的编程模型对开发人员的要求较高，需要有足够的编程背景才能胜任Spark Streaming的编程工作，而新引入的Structured Streaming模型是把数据流当作一个没有边界的数据表来对待，这样开发人员可以在流上使用Spark SQL进行流处理，这大大降低了流计算的编程门槛。
上图非常直观地解释了Structured Streaming模型的设计思想，基本无需多言。另一方面，当具备了这样一张“表”后，流的运作方式是就是在这张表上进行“查询”，并将查询的结果写到另一张结果表上，这种变换与DStream经过某个transform之后形成一个新的DStream是很类似的。我们来看一下Spark Streaming官方文档上给出的一个word count的示例：
这个图直观地展示了Structured Streaming的运作方式，每次流入的文本会作为一行新数据加入到unbounded table上，然后在这个表上执行word count查询后，把统计出的word count写到结果表中并输出。
Structured Streaming同样支持窗口操作，同样是基于unbounded table模型来实现的，较之于DStream的窗口操作，新的API显得更加实用和强大，一个显著的改进是新的窗口运算可以基于”事件时间”(Event Time)进行计算而不在是数据进入到流上的时间（当然，这并不是说DStream不能基于事件时间进行计算，只是实现起来稍显麻烦），所谓”事件时间”是指数据所代表的事件发生时的时间，这显然更加具有实用性。同样以word count为例，下图展示了以10分钟作为window size，5分钟为slide的窗口计算过程：
这个图形象地展示了以每行文本的时间戳为准，以10分钟为窗口尺度，统计了12:00 - 12:10, 12:05 - 12:15, 12:10 - 12:20三个时间窗口上word count值，而对应的实现代码及其地简洁：
import spark.implicits._ val words = ... // streaming DataFrame of schema { timestamp: Timestamp, word: String } // Group the data by window and word and compute the count of each group val windowedCounts = words.groupBy( window($"timestamp", "10 minutes", "5 minutes"), $"word" ).count()除此之外，新的API对数据延时到达也给出了一套简洁的解决方案。在很多流计算系统中，数据延迟到达的情况很常见，并且很多时候是不可控的，因为很多时候是外围系统自身问题造成的。首先，Structured Streaming可以保证一条旧的数据进入到流上时，Structured Streaming依然可以基于这些“迟到”的数据重新计算并更新计算结果，但是这样会一个问题，即需要在流上维持一个很大时间跨度的数据集，这会消耗很大的资源，同时，流计算关注的是近期数据，更新一个很早之前的状态往往已经不再具有很大的业务价值，因此Structured Streaming引入了一种叫watermarking的机制来应对这个问题。watermarking实际上就是数据的事件时间与在其流上能找到的最大事件时间的最大差值（Time-To-Live, TTL），如果这个差值超过了设定的阈值，就意味着数据太陈旧了，时效性超出了流计算应该关注的区间，不再参与计算。watermarking的定义或者说计算方法是非常有道理和有实际意义的，我们说当一组有新有旧（迟到）的数据进入到流上时，我们如何判定怎样的数据才算是太过“陈旧”的数据而不再给予关注？时间差值可以直接给出，10分钟也好，15分钟也罢，但是进行参照计算的“最新时间”怎么定呢？这里有两个可选时间：窗口的截止时间和窗口中最晚/最新的事件时间，显然后者是更加准确的，因为后者反映的是目标系统最后时刻的状态而不是当前数据流的最新状态！
我们官方文档展示的例子：
在这个图中，watermark设定为10分钟，我们先看一个延迟到达但没有超过watermark的例子：(12:09, cat) ，这个数据会最先进入12:05 - 12:15这个窗口(虽然正常情况下它在12：00-12：10这个窗口开启时就应该已经就绪了，显然它是一个迟到的数据)，watermark设定为10分钟话意味着有效的事件时间可以推后到12：14 - 10m = 12:04,因为12：14是这个窗口中接收到的最晚的时间，代表目标系统最后时刻的状态，由于12:09在12:04之后，因此被视为了“虽然迟到但尚且可以接收”的数据而被更新到了结果表中，也就是(12：00 - 12：10, cat, 1)。
另一个超出watermark的例子是(12:04, dog)，这个数据最早进入的窗口是12:15 - 12:25，窗口中最晚的事件时间是12：17，watermark为10分钟意味着有效的事件时间可以推后到12:07，而(12:04, dog)比这个值还要早，说明它”太旧了”，所以不会被更新到结果表中了。
同样的，在编程层面实现这些要求也是很简单的，整个Structured Streaming和Dataset/DataFrame都是声明性的：
import spark.implicits._ val words = ... // streaming DataFrame of schema { timestamp: Timestamp, word: String } // Group the data by window and word and compute the count of each group val windowedCounts = words .withWatermark("timestamp", "10 minutes") .groupBy( window($"timestamp", "10 minutes", "5 minutes"), $"word") .count()对于基于watermarking的窗口计算的最后一个问题就是Update模式和Append模式了，两种模式的区别是：Update模式总是倾向于“尽可能早”的将处理结果更新到sink，当出现迟到数据时，早期的某个计算结果将会被更新。如果用于接收处理结果的sink不支持更新操作，则只能选择Append模式，Append模式就是推迟计算结果的输出到一个相对较晚的时刻，确保结果是稳定的，不会再被更新，比如：12:00 - 12:10窗口的处理结果会等到watermark更新到12：11之后才会写入到sink。
TBD