Spark Structured Streaming - WAL 性能下降
Spark Structured Streaming - WAL performance degradation
我们有一个 spark 结构化流式查询，它从 eventhub 读取数据，做一些 处理 并将数据写回 eventhub。我们已 启用检查点 - 我们将检查点数据存储在 Azure Datalake Gen2 中。
当我们 运行 查询时，我们看到一些奇怪的东西 - 随着时间的推移，我们的 查询的性能（延迟）慢慢降低 。当我们 运行 第一次查询时，批处理持续时间约为 3 秒。 运行 一天后，批处理持续时间为 20 秒，2 天后，我们达到 40 秒以上。有趣的是，当我们删除检查点文件夹（或以其他方式重置检查点）时，延迟又回来了正常（2 秒）。
查看同一检查点目录 运行ning 2 天后的查询性能，很明显是 write-ahead-log / "walCommit"，它会增长并在一段时间后占处理时间的大部分。
我的问题是： 是什么驱动了这种行为 - walCommit 花费越来越长的时间是否自然？它可能是特定于 Azure Datalake Gen2 的吗？我们甚至需要 eventhub 的预写日志吗？改进这一点的一般方法是什么（不假设禁用 WAL）..
我已经通过 Slack 给你写信了，但我也会在这里分享答案。
我遇到过同样的行为，原因是 checkpoint/offsets 目录中隐藏的 crc 文件泄露。这是一个 hadoop 重命名错误，已在 Spark 2.4.4 中解决。
Link 到 Spark JIRA
如果在检查点目录 returns number > ~1000 中执行了以下查找命令，您将受到此错误的影响：
find . -name "*.crc" | wc -l
Spark < 2.4.4 的解决方法是禁用创建 crc 文件（在 JIRA 注释中建议）：
--conf spark.hadoop.spark.sql.streaming.checkpointFileManagerClass=org.apache.spark.sql.execution.streaming.FileSystemBasedCheckpointFileManager --conf spark.hadoop.fs.file.impl=org.apache.hadoop.fs.RawLocalFileSystem
感谢@tomas-bartalos 的回答！
我们发现了另一个问题，这是我们问题的真正原因 - Azure Gen2 存储的属性（启用了分层命名空间）。似乎 Azure Gen2 在列出 很多文件时 很慢。我们尝试使用 Azure Explorer 打开流式检查点目录，大约需要 20 秒（与 walCommit 时间相似）。我们切换到 Azure Blob 存储，问题就消失了。我们没有对 crc 文件做任何事情（tomas 的回答）所以我们得出结论， 存储模式是主要问题。
我们有一个 spark 结构化流式查询，它从 eventhub 读取数据，做一些 处理 并将数据写回 eventhub。我们已 启用检查点 - 我们将检查点数据存储在 Azure Datalake Gen2 中。
当我们 运行 查询时，我们看到一些奇怪的东西 - 随着时间的推移，我们的 查询的性能（延迟）慢慢降低 。当我们 运行 第一次查询时，批处理持续时间约为 3 秒。 运行 一天后，批处理持续时间为 20 秒，2 天后，我们达到 40 秒以上。有趣的是，当我们删除检查点文件夹（或以其他方式重置检查点）时，延迟又回来了正常（2 秒）。
查看同一检查点目录 运行ning 2 天后的查询性能，很明显是 write-ahead-log / "walCommit"，它会增长并在一段时间后占处理时间的大部分。
我的问题是： 是什么驱动了这种行为 - walCommit 花费越来越长的时间是否自然？它可能是特定于 Azure Datalake Gen2 的吗？我们甚至需要 eventhub 的预写日志吗？改进这一点的一般方法是什么（不假设禁用 WAL）..
我已经通过 Slack 给你写信了，但我也会在这里分享答案。
我遇到过同样的行为，原因是 checkpoint/offsets 目录中隐藏的 crc 文件泄露。这是一个 hadoop 重命名错误，已在 Spark 2.4.4 中解决。
Link 到 Spark JIRA
如果在检查点目录 returns number > ~1000 中执行了以下查找命令，您将受到此错误的影响：
find . -name "*.crc" | wc -l
Spark < 2.4.4 的解决方法是禁用创建 crc 文件（在 JIRA 注释中建议）：
--conf spark.hadoop.spark.sql.streaming.checkpointFileManagerClass=org.apache.spark.sql.execution.streaming.FileSystemBasedCheckpointFileManager --conf spark.hadoop.fs.file.impl=org.apache.hadoop.fs.RawLocalFileSystem
感谢@tomas-bartalos 的回答！
我们发现了另一个问题，这是我们问题的真正原因 - Azure Gen2 存储的属性（启用了分层命名空间）。似乎 Azure Gen2 在列出 很多文件时 很慢。我们尝试使用 Azure Explorer 打开流式检查点目录，大约需要 20 秒（与 walCommit 时间相似）。我们切换到 Azure Blob 存储，问题就消失了。我们没有对 crc 文件做任何事情（tomas 的回答）所以我们得出结论， 存储模式是主要问题。