Structured Streaming

引擎：Spark SQL
入口：SparkSession
计算模型：Micro-batch/Continus
延迟：
在 Micro-batch 模式下，每个微批次作为一个job调度单元，官网描述其带来的延迟在 100ms
在 Continus 连续处理模式下，延迟低于1ms

好的架构在于其巧妙的构思，而最终形式又是极其精简的。

编程模型：可将流看做是不断地往一个表上append内容的过程，查询操作相当于对一个触发批次内的静态表的查询。

端到端的exactly-once语义

我们所强调的exactly-once语义都是指同一数据的最终结果只产生一次。这就对系统的容错要求比较高了，即不管中间过程失败几次、源数据重新读取几次，最终的输出只一次。Struct Streaming也提供了exactly-once，但它是结合上游组件（源）流重放功能和幂等输出。所以重点有三个：
1、Struct Streaming的上游数据接入系统必须能够按位置读取（支持从某个偏移点开始读取数据）
2、Struct Streaming本身需要做检查点（checkpointing）或者WAL（write-ahead logs）记住触发期间所处理的数据偏移范围
3、结果输出到外部系统存储时支持幂等输出或者需要Sink系统支持事务（Flink的2CP也是需要Sink系统支持事务）

水印（watermark）

既然表不可能无限扩张，内存中保持的状态肯定需要清理，具体是怎么做的，这里只针对Window操作说明，对于无状态的操作，无需在内存中维持上一job触