sparkStreaming Batch mode和Continuous mode

💐💐扫码关注公众号，回复 spark 关键字下载geekbang 原价 90 元 零基础入门 Spark 学习资料💐💐

计算模型

当数据像水流一样，源源不断地流进 Structured Streaming 引擎的时候，引擎并不会自动地依次消费并处理这些数据，它需要一种叫做 Trigger 的机制，来触发数据在引擎中的计算。换句话说，Trigger 机制，决定了引擎在什么时候、以怎样的方式和频率去处理接收到的数据流。Structured Streaming 支持 4 种 Trigger，如下表所示。

对于流数据，Structured Streaming 支持两种计算模型，分别是 Batch mode 和 Continuous mode。

Batch mode

它指的是 Spark 将连续的数据流，切割为离散的数据微批（Micro-batch），也即小份的数据集。而每一份 Micro-batch，都会触发一个 Spark Job，每一个 Job 会包含若干个 Tasks。不同种类的 Trigger，如 Default、Fixed interval 以及 One-time，无非是在以不同的方式控制 Micro-batch 切割的粒度罢了。

Continuous mode

Continuous mode 并不切割数据流，而是以事件 / 消息（Event / Message）为粒度，用连续的方式来处理数据。这里的事件或是消息，指代的是原始数据流中最细粒度的数据形式，它可以是一个单词、一行文本，或是一个画面帧。

在 Continuous mode 下，Structured Streaming 使用一个常驻作业（Long running job）来处理数据流（或者说服务）中的每一条消息。Batch mode 吞吐量大、延迟高（秒级），而 Continuous mode 吞吐量低、延迟也更低（毫秒级）。

容错机制

在数据处理上，结合容错机制，Structured Streaming 本身能够提供“At least once”的处理能力。而结合幂等的 Sink，Structured Streaming 可以实现端到端的“Exactly once”容错水平。

Batch mode 容错

在 Batch mode 下，Structured Streaming 利用 Checkpoint 机制来实现容错。在实际处理数据流中的 Micro-batch 之前，Checkpoint 机制会把该 Micro-batch 的元信息全部存储到开发者指定的文件系统路径，比如 HDFS 或是 Amazon S3。这样一来，当出现作业或是任务失败时，引擎只需要读取这些事先记录好的元信息，就可以恢复数据流的“断点续传”。

在 Checkpoint 存储目录下，有几个子目录，分别是 offsets、sources、commits 和 state，它们所存储的内容，就是各个 Micro-batch 的元信息日志。对于不同子目录所记录的实际内容，我把它们整理到了下面的图解中，供你随时参考。

对于每一个 Micro-batch 来说，在它被 Structured Streaming 引擎实际处理之前，Checkpoint 机制会先把它的元信息记录到日志文件，因此，这些日志文件又被称为 Write Ahead Log（WAL 日志）。

Continuous mode 容错

因为 Continuous mode 天然没有微批，所以不会涉及到微批中的延迟，到达 Source 中的消息可以立即被 Structured Streaming 引擎消费并处理。但这同时也带来一个问题，那就是引擎如何把当前的处理进度做持久化，从而为失败重试提供可能。

为了解决这个问题，Spark 引入了 Epoch Marker 机制。所谓 Epoch Marker，你可以把它理解成是水流中的“游标”，这些“游标”随着水流一起流动。每个游标都是一个 Epoch Marker，而游标与游标之间的水量，就是一个 Epoch。在引擎处理并交付数据的过程中，每当遇到 Epoch Marker 的时候，引擎都会把对应 Epoch 中最后一条消息的 Offset 写入日志，从而实现容错。需要指出的是，日志的写入是异步的，因此这个过程不会对数据的处理造成延迟。

可以看到，消息从 Source 产生之后，可以立即被 Structured Streaming 引擎消费并处理，因而在延迟性方面，能够得到更好的保障。而 Epoch Marker 则会帮助引擎识别当前最新处理的消息，从而把相应的 Offset 记录到日志中，以备失败重试。