State Store定义

Structured Streaming中的查询与面向批处理的Spark SQL中的查询不同。在批处理中，查询是针对有限数量的数据进行的，因此计算结果可以是最终的。但这种情况不适用于流处理，因为其结果是不断增长的。因此，不断增长的结果存储在容错的State Store中。

State Store的目的是提供一个可靠的地方，引擎可以从那里读取Structured Streaming聚合的中间结果。因此，即使driver出现故障，Spark也能将状态恢复到故障前的状态。State Store是由类似于HDFS的分布式文件系统支持的。为了保证可恢复性，必须至少存储两个最近版本。例如，如果批次#10在处理过程中失败，那么State Store可能具有批次#9和批次#10一半的状态。Spark将从批次#9开始重新计算，因为批次#9是最后一个成功完成的批次。同时，State Store中还存在对于旧状态的垃圾回收机制。

技术上讲，State Store是存在于每个executor中的对象，将数据存储为key-value对。这个对象是org.apache.spark.sql.stream.state的实现。现在只有一个实现类HDFSBackedStateStore。

State Store实现细节

下面的图片描述了底层的实现细节：

image.png

上面的图表展示了生成org.apache.spark.sql.execution.streaming.state.StateStoreRDD的方法。顾名思义，这个RDD负责执行针对可用State Store的计算。StateStoreRDD的实现非常简单，因为它为给定的方法和partition检索State Store，并执行storeUpdateFunction:(StateStore, Iterator[T]) => Iterator[U]。

image.png

StateStore有一个伴生对象，它定义帮助器方法来根据它们的id创建和检索存储。StateStoreRDD是访问State Store的唯一位置。
另一个重要的类是StateStoreProvider的实现——HDFSBackedStateStoreProvider。在伴生对象里中使用它来获得给定的存储并执行维护任务（清理旧状态）。维护任务还负责生成snapshot文件。这些文件将多个State Store文件（delta文件）合并到一个snapshot文件中。

整个逻辑如下所示：executor将本地更改（添加/更新/删除行）写入临时delta文件的文件流。最后他们调用commit方法：关闭流，为给定版本创建delta文件，使用提交的版本记录在log中。然后将store的状态从UPDATING改为COMMITTED。commit方法是从上面给出的storeUpdateFunction调用的。除此之外，还有一个后台任务做着一些维护工作，将最终确定的delta文件合并为一个snapshot文件，并删除旧的snapshot文件和delta文件。

重要：State Store中的文件

State Store处理两类文件：delta文件和snapshot文件。delta文件包含每个查询执行结果的状态表示。它是由给定executor中注册的行更改提供的tmp delta file构造的（State Store与partition相关，每个executor在一个hash map中存储状态数据）。tmp delta file的名称遵从“temp-{Random.nextLong}”模式。最后，在调用commit方法时，为新版本创建最终的delta文件，其名称遵从“version.delta”模式。最后，多个delta文件合并到snapshot文件中，这些文件的名称遵从“version.snapshot”模式。过程由下图所示：

image.png

作者：阿猫阿狗Hakuna
链接：https://www.jianshu.com/p/83c1d2f27b72