Spark结构化流-WAL性能下降

Question

我们有一个Spark结构化的流查询，该查询从 eventhub 读取数据，进行一些处理，然后将数据写回到 eventhub 。 启用了检查点-我们将检查点数据存储在Azure Datalake Gen2中。

运行查询时，我们看到一些奇怪的东西-随着时间的流逝，查询的性能（延迟）会缓慢降低。当我们第一次运行查询时，批处理持续时间约为3秒。运行一天后，批处理持续时间为20秒，两天后达到40秒以上。有趣的是，当我们删除检查点文件夹（或以其他方式重置检查点）时，延迟恢复为正常（2秒）。

在相同的检查点目录上运行2天后，查看查询性能，很明显，它是 write-ahead-log /“ walCommit” ，它会随着时间的推移而增长占处理时间的大部分。

我的问题是：是什么导致了这种行为-walCommit花费越来越长的时间自然吗？可能是特定于Azure Datalake Gen2的吗？我们甚至需要eventhub的预写日志吗？有什么一般的方法可以改善这一点（不假设禁用WAL）。

Answer 1

我已经通过Slack给您写信，但我也会在这里分享答案。

我也遇到过同样的情况，原因是在checkpoint / offsets目录中隐藏了crc文件。这是一个hadoop重命名错误，在Spark 2.4.4中已解决。

链接到Spark JIRA

如果在检查点目录中执行以下查找命令返回的数字>〜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

Answer 2

谢谢@ tomas-bartalos！

我们发现了另一个问题，这是导致问题的真正原因-Azure Gen2存储的属性（启用了分层命名空间）。列出很多文件时，Azure Gen 2似乎慢。我们尝试使用Azure资源管理器打开流式检查点目录，此过程耗时约20秒（类似于walCommit时间）。我们切换到Azure Blob存储，问题消失了。我们没有对crc文件做任何事情（tomas的回答），所以我们得出结论，te 存储模式是主要问题。