Spark Structed Streaming的一些主要特性及与Spark Streaming之间的对比

Spark Streaming

众所周知，Spark Streaming中的数据结构是DStream，是对RDD的进一步的封装，是”微批“的准实时处理。将连续的流数据转换为连续的批作业，这里的“批”，就是指RDD序列——DStream。

除了文件数据流之外，所有的输入DStream都会被绑定到一个Receiver对象上，Receiver接受数据。所以一个Spark Streaming程序，至少需要占用2个cpu core，一个给spark streaming application的executor，另一个给Receiver。

程序开发流程：

1. DStream数据源
   （Flink中：Source）（Flink、Spark Streaming中，DStream/Source都可以是并行多个的。）
2. Transformation+Action操作
   （Flink为Transformation）
3. 调用StreamingContext的start开始执行程序
   （Flink为ExecutionEnvironment的execute()方法）
4. stop

Spark Structed Streaming

之前在实时大数据平台技术选型概要这篇文章中有提到：

Structured Streaming是Spark2提出的新的实时流框架（2.0和2.1是实验版本，从Spark2.2开始为稳定版本），Spark2 将流式计算也统一到DataFrame里去。

总的来说，Structured Streaming 的意义有：

• 重新抽象了流式计算
• 易于实现数据的exactly-once（2.0之前的Spark Streaming 只能做到at-least once）
• 解决了Spark Streaming存在的代码升级，DAG图变化引起的任务失败，无法断点续传的问题
• 保证与批处理作业的强一致性
• API简化（引入和流函数的封装。
  举个例子：Kafka中读取的数据，通过stream方法形成流，就可以直接与jdbc中读取的数据在DataSet层面就进行Join，不用使用transform或者foreachRDD方法。
  stream方法底层依赖Dataset和Dataframe，集成了SparkSql和Dataset几乎所有的功能，把流处理的代码编写一下子简化了很多。）
• 基于Event-Time，相比于Spark Streaming的Processing-Time更精确
• 未来将支持使用SQL和JDBC来实时查询Streaming data

通俗的说，以前只是流式计算，数据计算完之后放入外部存储，现在向持续计算发展，希望通过一套API实现数据的持续计算（数据在计算时，既可以结合离线数据，又可以提供实时查询，又可以与外部存储比如redis、hbase交互）。

持续计算

自Spark 2.3以来，引入了一种称为连续处理的新型低延迟处理模式，它可以实现低至1毫秒的端到端延迟，并且具有至少一次保证（at-least-once）。

无边界表

以下内容翻译自：