Spark 2.3.1 结构化流状态存储内部工作答案

【问题标题】：Spark 2.3.1 Structured Streaming state store inner workingSpark 2.3.1 结构化流状态存储内部工作
【发布时间】：2019-12-01 22:30:02
【问题描述】：

我一直在阅读 spark 2.3.1 关于结构化流的文档，但找不到有关状态操作如何在状态存储内部工作的详细信息。更具体地说，我想知道的是，（1）国家商店是否已分发？（2）如果是这样，那么如何，每个工人或核心？

在以前的 Spark 版本中似乎是每个工作人员，但现在不知道。我知道它是由 HDFS 支持的，但没有任何解释内存存储的实际工作原理。

确实是分布式内存存储吗？我对重复数据删除特别感兴趣，如果数据是来自一个大数据集的流，那么这需要进行计划，因为所有“不同”数据集最终将保存在内存中，作为该数据集处理的结束.因此，需要根据状态存储的工作方式来计划工作人员或主人的规模。

【问题讨论】：

asyncified.io/2017/07/30/…（免责声明：我是作者）。
但这并不能解释 HDFSBackedStateStore 的实际工作原理。我在文档中没有看到它
我试图在这里jaceklaskowski.gitbooks.io/spark-structured-streaming/… 阅读此文档，但它违背了博客的状态，即不再有每个执行程序的存储。
您能否解释一下键值存储的工作原理。如果它是 HDFS 支持的，我认为这些东西是分布式存储在磁盘上的，但是一旦它在内存中，我想知道如果在内存中没有分布，则相关执行器上的不同核心如何访问相同的数据视图。你能帮忙吗
它的工作原理如下：每个执行者都有一个ConcurrentHashMap。 Spark 中定义的分区器将数据分区到这些映射中的每一个。每个微批次，HDFS 支持的状态存储将获取所有更新的密钥并将它们异步存储在 HDFS 中。每隔一段时间就会发生一次压缩，保存的增量文件将变成一个“快照”文件。此外，还会发生删除。

标签： apache-spark spark-structured-streaming

【解决方案1】：

在结构化流中只有一种状态存储实现，它由内存中的 HashMap 和 HDFS 支持。 In-Memory HashMap 用于数据存储，HDFS 用于容错。 HashMap在worker上占用executor内存，每个HashMap代表一个聚合分区的版本化key-value数据（经过去重、groupByy等聚合算子生成）

但这并不能解释 HDFSBackedStateStore 是如何实际工作的。我在文档中没有看到它

您说得对，没有可用的此类文档。我必须理解代码 (2.3.1) ，写了一篇关于 State Store 如何在 Structured Streaming 内部工作的文章。你不妨看看：https://www.linkedin.com/pulse/state-management-spark-structured-streaming-chandan-prakash/

【讨论】：