08 Spark 之 Spark Streaming 和 Structured Streaming

这篇总结来自极客时间专栏《大规模数据处理实践》的 16-17 节。

这篇主要看下 Spark 流计算这块的能力,过去 Spark 主推的是 Spark Streaming,现在开始推广 Structured Streaming,在 Streaming101 中是这样介绍 Spark Streaming 的:Spark Streaming 第一次让我们看到流计算是可以做到准确性的。Spark Streaming 诞生于 2013 年,那时业内的主流还是 Storm,但是 Storm 无法做到 exactly once、准确性难以保证、不支持窗口等高阶算子,而 Spark Streaming 的出现,切好弥补了这一缺口,推动流计算进一步的发展。

Spark Streaming

Spark Streaming 本质上与微积分的思想很像(蔡老师这样比较,我是第一次看到的,非常赞),它是把一个无限流逐渐切分为有限流,然后再当作批去计算。

DStream

Spark Streaming 提供了一个对于流数据的抽象 —— DStream,它可以来自 Kafka、Flume 等,也可以由别的 DStream 转换而来,它底层也是由多个 RDD 构成,比如:按时间片切分的每个数据单位就是一个 RDD。

前面说过 Spark 中的 DataSet 和 DataFrame 也是基于 RDD 的,所以 RDD 是 Spark 的最基本抽象。
Spark 是一个高度统一的平台,所有的高级 API 都有相同的性质,它们之间可以相互转化,Spark 就是希望用一套工具统一所有的数据处理场景。

Spark Streaming 将实现细节都封装起来了,对于开发者来说,只需要去操作 DStream 就可以了。

DStream(图片来自极客时间课程)

DStream 的窗口操作

Spark Streaming 提供了一些高阶的窗口操作,这个就不再介绍了,因为 DStream 是由无限切分好的数据分片(每个都是 RDD)组成,所以在这个基础上实现窗口操作就简单很多:

窗口操作(图片来自极客时间课程)

虽然我个人对 Spark Streaming 不是很熟,但从上面的设计思想可以看出,Spark Streaming 是无法做到基于事件时间(event time)切分窗口的。

Spark Streaming 的优缺点

Spark Streaming 在流计算史上是一个非常重要的产品,它第一次让人们看到流计算也是可以做到准确性的,这个是 Storm 不具备的。

优点:

  1. 底层基于 RDD 实现,因此,RDD 的优势在这里都有体现,比如数据的容错性;
  2. 它是 Spark 生态的一部分,可以和 Spark 其他引擎无缝衔接;

缺点:

  1. 实时计算延迟较高,秒级别;

Structured Streaming

接下来看下,Spark 主推的新流计算库 —— Structured Streaming。

先来回顾下 DataSet/DataFrame 的优点:

  1. DataFrame 是高级 API,提供类似于 SQL 的接口(现在 DataFrame 已经完全可以用 DataSet 表示了);
  2. Spark SQL 执行引擎会自动优化 DataFrame 程序,而 RDD 或 DStream 的开发是需要开发者自己构造 RDD 的 DAG 执行图,依赖于工程师自己去优化。

个人认为:本质上,还是 RDD/DStream 的 API 过于 low level,对工程师的要求过高,效率较低(在 Spark Streaming 设计一套流的 SQL 实现难度不亚于重新开发一套新引擎)。

Structured Streaming 是基于 Spark SQL 引擎实现的,数据结果使用的 DataFrame API。

Structured Streaming 模型

流数据处理最基本的问题就是如何对不断更新的无边界数据建模。

之前的 Spark Streaming 是把流数据按一定的时间间隔分隔成许多个小的数据块进行批处理,在 Structured Streaming 模型中,把数据看成一个无边界的关系型数据表,每条数据都是表中的一行,不断会有新的数据行被添加到表里来。

Structured Streaming 中数据结构(图片来自极客时间课程)

Structured Streaming 支持三种输出模式:

  1. 完全模式(Complete Mode):整个更新过的数据表都被写入外部存储;
  2. 附加模式(Append Mode):上一次触发之后新增加的行才会被写入外部存储,如果经常有旧数据被更新,不适合这种模式;
  3. 更新模式(Update Mode):上一次触发之后被更新的行才会被写入外部存储。

Structured Streaming 的模型再根据事件事件(Event Time)处理数据时十分方便。

Structured Streaming 与 Spark Streaming 对比

  1. 简易度和性能上,Structured Streaming 更优;
  2. 实时性上 Structured Streaming 更优,在 Spark 2.3 中,增加了连续处理模型,可以做到毫秒级延迟(参考 Introducing Low-latency Continuous Processing Mode in Structured Streaming in Apache Spark 2.3);
  3. 对事件事件的支持更好。

总结

看完这篇 Introducing Low-latency Continuous Processing Mode in Structured Streaming in Apache Spark 2.3 文章,你会发现 Structured Streaming 的设计也是借鉴 DataFlow 模型,在容错上,也可借鉴了Chandy-Lamport 算法,开始跟 Flink 的设计比较像了,但如果没有超越 Flink 的优势,其实,个人对它的发展并不看好,毕竟现在已经在追随了而且 Structured Streaming 的社区远不如 Flink。

有兴趣的同学,可以通过下面的链接购买,会有一些优惠

二维码扫描购买有一定优惠

推荐阅读更多精彩内容