大数据实时流处理场景化解决方案-实时处理技术框架介绍-Structured Streaming
Structured Streaming
Structured Streaming简介
• Structured Streaming是构建在Spark SQL引擎上的流式数据处理引擎，使用Scala编写，具有容错功能。
• sparkstreaming官方已经停止了维护，从spark2.2开始全力打造Structured Streaming
• Spark 1.x 时代里，以 SparkContext（及 RDD API）为基础，在 structured data 场景衍生出了 SQLContext, HiveContext，在 streaming 场景衍生出了 StreamingContext，很是琳琅满目。
• Spark 2.x 则精简到只保留一个 SparkSession 作为主程序入口，以 Dataset/DataFrame 为主要的用户 API，同时满足 structured data, streaming data, machine learning, graph 等应用场景，大大减少使用者需要学习的内容，爽爽地又重新实现了一把当年的 “one stack to rule them all” 的理想。
RDD、Dataset与DataFrame
• Spark 1.x的RDD更多意义上是一个一维、只有行概念的数据集，比如RDD[Person]，那么一行就是一个Person，存在内存里也是把Person作为一个整体。
• Spark2.x里，一个Person的Dataset或DataFrame，是二维行+列的数据集，比如一行一个 Person，有name:String, age:Int, height:Double三列；在内存里的物理结构，也会显式区分列边界。
• Dataset/DataFrame 在 API 使用上有区别：Dataset 相比 DataFrame 而言是 type-safe 的，能够在编译时对 AnalysisExecption 报错。
• Dataset/DataFrame 存储方式无区别：两者在内存中的存储方式是完全一样的、是按照二维行列（UnsafeRow）来存的，所以在没必要区分 Dataset 或 DataFrame 在 API 层面的差别时，我们统一写作 Dataset/DataFrame
程序模型
• Structured Streaming的核心是将流式的数据看成一张不断增加的数据库表，这种流式的数据处理模型类似于数据块处理模型，可以把静态数据库表的一些查询操作应用在流式计算中，Spark运行这些标准的SQL查询，从不断增加的无边界表中获取数据。
• 想象一下，我们把不断输入的流式数据加载为内存中一张没有边界的数据库表，每一条新来的数据都会作为一行数据新增到这张表中
• 每一条查询的操作都会产生一个结果集Result Table。每一个触发间隔（比如说1秒），当新的数据新增到表中，都会最终更新Result Table。无论何时结果集发生了更新，都能将变化的结果写入一个外部的存储系统（OutPut）。
• OutPut可以定义不同的存储方式：
• Complete Mode：整个更新的结果集都会写入外部存储。整张表的写入操作将由外部存储系统的连接器Connector操作。
• Append Mode：当时间间隔触发时，只有在Result Table中新增加的数据行会被写入到外部存储。这种方式只适用于结果集中已经存在的内容（不希望发生改变的情况下），如果已经存在的数据会被更新，不适合适用此种方式。
• Update Mode：当时间间隔触发时，只有在Result Table中被更新的数据才会被写入到外部存储系统（在Spark2.x中暂时尚未可用）。
时间窗口
• Structured Streaming支持处理时间和事件时间，同时支持watermark机制处理滞后数据。
• 处理时间：处理时间是指每台机器的系统时间，当流程序采用处理时间时，将使用各个实例的机器时间。
• 事件时间：是指事件在其设备上发生的时间，这个时间在事件进入Structured Streaming之前已经嵌入事件，然后Structured Streaming可以提取该时间。
• 处理时间
• 处理时间是指每台机器的系统时间，当流程序采用处理时间时将使用运行各个运算符实例的机器时间。处理时间是最简单的时间概念，不需要流和机器之间的协调，它能提供最好的性能和最低延迟。然而在分布式和异步环境中，处理时间不能提供消息事件的时序性保证，因为它受到消息传输延迟，消息在算子之间流动的速度等方面制约。
• 事件时间
• 事件时间是指事件在其设备上发生的时间，这个时间在事件进入 flink 之前已经嵌入事件，然后 flink 可以提取该时间。基于事件时间进行处理的流程序可以保证事件在处理的时候的顺序性，但是基于事件时间的应用程序必须要结合 watermark 机制。基于事件时间的处理往往有一定的滞后性，因为它需要等待后续事件和处理无序事件，对于时间敏感的应用使用的时候要慎重考虑。
• 注入时间
• 注入时间是事件注入到 flink 的时间。事件在 Source 算子处获取 Source 的当前时间作为事件注入时间，后续的基于时间的处理算子会使用该时间处理数据。
• 相比于事件时间，注入时间不能够处理无序事件或者滞后事件，但是应用程序无序指定如何生成 watermark。在内部注入时间程序的处理和事件时间类似，但是时间戳分配和 watermark 生成都是自动的。
事件时间的窗口定义
• 上面的例子：计算10分钟内的单词，每5分钟更新一次。也就是说，在10分钟窗口12：00-12：10,12：05-12：15,12：10-12：20等之间收到的单词数量。请注意，12：00 - 12:10表示数据在12:00之后但在12:10之前到达。现在，考虑一下在12:07收到的一个字。这个词应该增加对应于两个窗口12:00 - 12:10和12:05 - 12:15的计数。因此，计数将由分组键（即单词）和窗口（可以从事件时间计算）索引。
流连接
• Spark2.x支持流与流的连接。在两个数据流之间生成连接结果的挑战是，在任何时间点，数据集的视图对于连接的两侧都是不完整的，这使得在输入流之间找到匹配的数据更加困难。一个输入流接收的任何行都可以与另一个来自未来的、尚未接收的输入流中的任何行进行匹配。因此，对于两个输入流，Structured Streaming可以将过去的输入流缓冲为流状态，以便将每个未来输入流与过去的输入流相匹配，从而生成连接结果。
Source数据源
Sink输出源
• 幂等操作：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品使用支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。
• 可以简单理解成upsert操作，有则更新，无则插入