struct streaming 是spark 2.3新引入的一个概念用来对标flink，看了两天flink，感觉没有saprk的api用这爽，可能因为我比较菜吧，领会不到阿里大佬们的精髓，一个低延时 exactly once end-end 的概念continues processing 对标flink的continue query，保证1 millsecond的延时还是看好spark ，spark大法好，
val sc=spark.SparkContext
val ssc=StreamingContext(sc,seconds(5))
val spark=SparkSession.builder.appName("xxx").getOrCreate()
import saprk.implicits._
val lines=spark.readStream.format("socket").option("host","localhost").option("port",9999).load()
val words=lines.as[String].flatMap()_.split(" ")
val wordCounts=words.groupBy("value").count()
val query=wordCounts.writeStream.outputMode("complete").format("console").start()
query.awaitTermination()
struct streaming的核心观念是将 实时数据看作是一张不断增加数据的表，和flink的table&sql api观念一样，flink采用的是calcite ，flink底层采用的saprk sql引擎
意思就是新加入每条数据都是无界表的新的一行，这个概念不错
感觉和flink非常相似 输入 处理 sink structstreaming有三种模式
complete mode将结果完全输出出去
append mode
update mode
spark处理事件时间：将时间event-time作为dynamic table的value，对于late data spark会update result table spark2.1也引入了和 flink一样的watermarks来处理late data 可以指定清理 old data time
struct streaming 容错保证：假设每一个流有类似与kafka offest偏移量的东西，用来查看消费记录，ss engine用checkpoint和wal来记录每一次每一次消费的记录，
structStreaming 先在这里简称 SSing
对于late data SSing 结构化流可以在很长一段时间内维护部分聚合的中间状态，以便后期数据可以正确更新旧窗口的聚合
而flink采用watermarks来触发计算乱续数据
在SSing中采用watermarks来处理老旧的中间状态，因为这个状态存储在内存中，不能一直无限变大，
import spark.implicits._
val words = ... // streaming DataFrame of schema { timestamp: Timestamp, word: String }val windowCounts=words.withWatermark("timestamp","10 minutes") .groupBy(window($"timestamp","10 minutes","5 minutes"),$"word").count() //根据window和word字段进行分组再求和
10 minutes后更新 SSing的内部状态，删除老旧的内部状态，类似于flink watermarks中的容错值，但我感觉spark设计的比较好，在内存中随时更新，等很长时间都无所谓，前提内存足够大，而flink 的watermarks 容错时间默认为3.5秒，如果有数据延迟很久，都没有到那么flink将会把其抛弃，
private final long maxOutOfOrderness = 3500; // 3.5 seconds待续。。。。。。