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。

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

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