【大数据技术】关于Spark Streaming 技术要点的一些汇总

原文链接：https://blog.csdn.net/D55dffdh/article/details/82423831

Spark Streaming 支持实时数据流的可扩展(Scalable)、高吞吐(high-throughput)、容错(fault-tolerant)的流处理(stream processing)。

 

 

架构图

特性如下：

• 可线性伸缩至超过数百个节点;

• 实现亚秒级延迟处理;

• 可与 Spark 批处理和交互式处理无缝集成;

• 提供简单的API实现复杂算法;

• 更多的流方式支持，包括 Kafka、Flume、Kinesis、Twitter、ZeroMQ 等。

001、原理

Spark 在接收到实时输入数据流后，将数据划分成批次(divides the data into batches)，然后转给 Spark Engine 处理，按批次生成最后的结果流(generate the final stream of results in batches)。

 

 

002、API

DStream：

DStream(Discretized Stream，离散流)是 Spark Stream 提供的高级抽象连续数据流。

组成：一个 DStream 可看作一个 RDDs 序列。

核心思想：将计算作为一系列较小时间间隔的、状态无关的、确定批次的任务，每个时间间隔内接收的输入数据被可靠存储在集群中，作为一个输入数据集。

 

 

特性：一个高层次的函数式编程 API、强一致性以及高校的故障恢复。

应用程序模板：

模板1

 

 

模板2

 

 

WordCount示例

 

 

Input DStream：

Input DStream 是一种从流式数据源获取原始数据流的 DStream，分为基本输入源(文件系统、Socket、Akka Actor、自定义数据源)和高级输入源(Kafka、Flume等)。

Receiver：

每个 Input DStream(文件流除外)都会对应一个单一的 Receiver对象，负责从数据源接收数据并存入 Spark 内存进行处理。应用程序中可创建多个 Input DStream 并行接收多个数据流。

每个 Receiver 是一个长期运行在Worker或者 Executor 上的 Task，所以会占用该应用程序的一个核(core)。如果分配给 Spark Streaming 应用程序的核数小于或等于 Input DStream 个数(即Receiver个数)，则只能接收数据，却没有能力全部处理(文件流除外，因为无需Receiver)。

Spark Streaming 已封装各种数据源，需要时参考官方文档。

Transformation Operation

常用Transformation

 

 

updateStateByKey(func)

updateStateByKey可对DStream中的数据按key做reduce，然后对各批次数据累加

WordCount的updateStateByKey版本

 

 

transform(func)

通过对原 DStream 的每个 RDD 应用转换函数，创建一个新的 DStream。

官方文档代码举例

 

 

Window operations

窗口操作：基于 window 对数据 transformation(个人认为与Storm的tick相似，但功能更强大)。

参数：窗口长度(window length)和滑动时间间隔(slide interval)必须是源DStream 批次间隔的倍数。

举例说明：窗口长度为3，滑动时间间隔为2;上一行是原始 DStream，下一行是窗口化的 DStream。

 

 

常见 window operation

 

 

 

官方文档代码举例

 

 

join(otherStream, [numTasks])

连接数据流

官方文档代码举例1

 

 

官方文档代码举例2

 

 

Output Operation

 

 

缓存与持久化：

通过 persist()将 DStream 中每个 RDD 存储在内存。

Window operations 会自动持久化在内存，无需显示调用 persist()。

通过网络接收的数据流(如Kafka、Flume、Socket、ZeroMQ、RocketMQ等)执行 persist()时，默认在两个节点上持久化序列化后的数据，实现容错。

Checkpoint：

用途：Spark 基于容错存储系统(如HDFS、S3)进行故障恢复。

分类：

元数据检查点：保存流式计算信息用于 Driver 运行节点的故障恢复，包括创建应用程序的配置、应用程序定义的 DStream operations、已入队但未完成的批次。

数据检查点：保存生成的 RDD。由于 stateful transformation 需要合并多个批次的数据，即生成的 RDD 依赖于前几个批次 RDD 的数据(dependency chain)，为缩短 dependency chain 从而减少故障恢复时间，需将中间 RDD 定期保存至可靠存储(如HDFS)。

使用时机：

Stateful transformation：updateStateByKey()以及 window operations。

需要 Driver 故障恢复的应用程序。

003、使用方法

Stateful transformation

 

 

需要 Driver 故障恢复的应用程序(以WordCount举例)：如果 checkpoint 目录存在，则根据 checkpoint 数据创建新 StreamingContext;否则(如首次运行)新建 StreamingContext。

 

 

checkpoint 时间间隔

方法：

 

 

原则：一般设置为滑动时间间隔的5-10倍。

分析：checkpoint 会增加存储开销、增加批次处理时间。当批次间隔较小(如1秒)时，checkpoint 可能会减小 operation 吞吐量;反之，checkpoint 时间间隔较大会导致 lineage 和 task 数量增长。