Performance Spark结构化流媒体-性能下降

我们有一个spark结构化流式查询，它从eventhub读取数据，进行一些处理并将数据写回eventhub。我们启用了检查点——我们将检查点数据存储在Azure Datalake Gen2中

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

在同一检查点目录上运行2天后，查看查询性能，很明显是预写日志/“walCommit”，它在增长，并且在一段时间后占据了大部分处理时间

---

我的问题是：这种行为的驱动力是什么？WALCOMIT花费越来越长的时间是正常的吗？它可能是Azure Datalake Gen2特有的吗？我们甚至需要eventhub的预写日志吗？如何改进这一点的一般方法是什么（不假设禁用WA）

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

我也经历过同样的行为，原因是检查点/偏移量目录中隐藏的crc文件泄漏。这是一个hadoop重命名错误，在Spark 2.4.4中有解决方法

链接到

如果在检查点目录中执行的以下find命令返回编号>~1000，则您会受到此错误的影响：

find . -name "*.crc" | wc -l

Spark<2.4.4的解决方法是禁用创建crc文件（JIRA评论中建议）：

---

我已经通过Slack写信给你，但我也将在这里分享答案

我也经历过同样的行为，原因是检查点/偏移量目录中隐藏的crc文件泄漏。这是一个hadoop重命名错误，在Spark 2.4.4中有解决方法

链接到

如果在检查点目录中执行的以下find命令返回编号>~1000，则您会受到此错误的影响：

find . -name "*.crc" | wc -l

Spark<2.4.4的解决方法是禁用创建crc文件（JIRA评论中建议）：

---

谢谢@tomas bartalos的回答

---

我们发现了另一个问题，这是问题的真正原因-Azure Gen2存储的属性（启用了分层命名空间）。在列出大量文件时，Azure Gen2似乎速度很慢。我们尝试使用Azure Explorer打开流式检查点目录，大约花费了20秒（类似于

walCommit

时间）。我们切换到Azure Blob存储，问题就消失了。我们没有对

crc

文件做任何处理（tomas的回答），因此我们得出结论，te存储模式是主要问题。

感谢@tomas bartalos的回答

我们发现了另一个问题，这是问题的真正原因-Azure Gen2存储的属性（启用了分层命名空间）。在列出大量文件时，Azure Gen2似乎速度很慢。我们尝试使用Azure Explorer打开流式检查点目录，大约花费了20秒（类似于

walCommit

时间）。我们切换到Azure Blob存储，问题就消失了。我们没有对

crc

文件做任何处理（tomas的回答），因此我们得出结论，te存储模式是主要问题。