Spark 持续流处理和微批处理的对比

Spark从2.3版本开始引入了持续流式处理模型，可将流处理延迟降低至毫秒级别，让 Structured Streaming 达到了一个里程碑式的高度。

下面的架构图中，既有微批处理，还有持续流处理，两种模式对用户是暴露的API是高度统一的：

今天我们着重看下两者的设计思路和区别点

在持续模式下，流处理器持续不断地从数据源拉取和处理数据，而不是每隔一段时间读取一个批次的数据，这样就可以及时地处理刚到达的数据。如下图所示，延迟被降低到毫秒级别，完全满足了极低延迟的要求。

持续模式目前支持的 Dataset 操作包括 Projection、Selection 以及除 current_timestamp()、current_date()、聚合函数之外的 SQL 操作。它还支持将 Kafka 作为数据源和数据池（Sink），也支持将控制台和内存作为数据池。

开发者可以根据实际的延迟需求来选择使用持续模式还是微批次模式，总之，Structured Streaming 为开发者提供了容错和可靠性方面的保证。以及端到端的毫秒级延迟、至少一次处理保证等。

微批处理

Structured Streaming  默认使用微批模式，spark 引擎会定期检查是否有新数据到达，然后开启一个新的批次进行处理，如下图：

在微批模式下， driver 在执行每个批次前，都需要先把 offset range 写入 WAL， 为了挂掉后可以 recover，当一条日志到达后，并不会立即处理，需要先处理完上一个批次，然后把这一个批次的 offset 记录后，才会处理，如下图：

这种模式下，最低的延迟可以搞到 100ms， 这种模式是架构在 Spark SQL 上的，所以就坐享 spark SQL 中已有的优化方式（code generation 和 project Tungsten，参考 https://databricks.com/blog/2016/05/23/apache-spark-as-a-compiler-joining-a-billion-rows-per-second-on-a-laptop.html），这种模式主要是面向吞吐量进行设计，而且可以满足绝大部分应用场景，比如ETL和准实时监控，但是对于要求延迟在 10ms 的场景就力不从心了，所以2.3 版本中又引入了 持续流处理 模型。

持续流处理

在持续流模式下，spark不是定期调度新批次的任务，而是启动一直运行的驻守在 executor 上的任务，源源不断的进行读取处理输出数据，如下图：

因为在 executor 端是持续流处理的，所以最低延迟可以降到 几毫秒，spark 内部采用的分布式快照算法类似 Chandy-Lamport 算法，不过略有区别，在source 端隔一段时间注入特殊标记（epoch markers）到数据流，然后就相当于把数据切分为不同的 epochs， 当特殊标记流到 最后的 operator， executor 获取后，向driver 汇报，driver等齐所有executor的汇报，统一发号施令，统一提交，有点类似于二次提交算法，全部的 executor 都提交后，driver 再写入提交日志中，这个 epochs 就算是全部ok了，防止重复执行。

后续这个分布式算法的设计和实现我会抽一篇文章来单独介绍。

大家都在看

▼

关注 【spark技术分享】

一起撸spark源码，一起玩spark最佳实践