Apache spark 如何保持Dataproc纱线nm本地定向尺寸可控

我正在配置有1个主工作进程、2个主工作进程（每个主工作进程使用4个本地SSD）和N个辅助工作进程（没有任何SSD）的GCP Dataproc群集上运行spark作业

我的工作每天都分批处理数据，因此我希望临时数据（洗牌、检查点等）在一天的过程中增长，并在第二天开始之前进行清理

但是，当我运行该作业几天（比如15-20天）后，它最终失败，并出现一个错误，即磁盘空间不足，无法容纳纱线（我记不起确切的错误消息）

Dataproc GCP控制台显示此图，您可以看到HDFS容量单调下降，而其他指标显示与批启动/停止相关的周期性上升和下降

我将自己的日志记录到一名主要工作人员处，以调查SSD的使用情况，因为我记得错误消息指的是

/mnt/{1,2,3,4}

，这是SSD的装载点

$df-h
[...]
/dev/sdb 369G 178G 172G 51%/mnt/1
/dev/sdc 369G 178G 173G 51%/mnt/2
/开发/sdd 369G 179G 171G 52%/mnt/3
/dev/sde 369G 174G 176G 50%/mnt/4
[...]

而且磁盘使用率一直在增加（在我写这篇文章之前是43%）。通过进一步挖掘，我可以找到以下目录：

$ pwd
/mnt/1/hadoop/yarn/nm-local-dir/application_1622441105718_0001

$ du -sh .
178G    .

$ ls
00  03  06  09  0c  0f  12  15  18  1b  1e  21  24  27  2a  2d  30  33  36  39  3c  3f
01  04  07  0a  0d  10  13  16  19  1c  1f  22  25  28  2b  2e  31  34  37  3a  3d
02  05  08  0b  0e  11  14  17  1a  1d  20  23  26  29  2c  2f  32  35  38  3b  3e

所有这些文件夹都包含名为shuffle\u NN\u NNNN\u 0.{index，data}的文件。很多论文档案：目前有38577篇

我假设这些文件是临时数据，但为什么不在每批之后删除它们？ 我是否可以在不中断工作的情况下手动删除它们（something

find.-type f-mmin-120-delete

删除所有超过120分钟的文件（我的批处理大约60分钟长））？ 有没有管理这些文件的好方法

---

编辑 事实上，我测试过用以下方法删除旧文件：

for I in $(seq 1 4); do
( cd /mnt/${I}/hadoop/yarn/nm-local-dir/application_* && sudo find . -type f ! -newerat 2021-05-31T12:00:00 -delete )
done

我的作业仍在运行，似乎没有注意到任何问题，但我将磁盘使用率降至16%（而不是54%）。这是一个手动解决方案，我仍在寻找更好的解决方案

---

编辑2 在@Ben Sidhom之后，更精确一些

我在批处理模式下使用Spark。“标称”用例是每天早上处理最后一天的数据。因此，每天D，我启动一个Spark作业，读取D-1天的数据，对其进行转换并保存生成的数据集。这个过程大约花费1小时，在本例中，我没有注意到任何数据泄漏

然而，有时，我们需要做一些追赶。例如，我实现了一个新的转换作业，需要在前一年的每一天应用它（以填充一些历史数据）。在本例中，我没有启动365个单独的spark作业，而是启动1，它将按顺序处理每天的作业。现在，这项工作的时间要长得多，而且数据泄漏时有发生。大约15小时后（因此在处理15天的数据后），作业失败，因为设备上没有剩余空间

禁用EFM似乎不是一个好的解决方案，因为实际上，正是在这种长时间运行的作业上，它带来了最大的价值，避免了由于可抢占节点丢失而导致作业失败

因此，目前，我将坚持手动解决方案。 请注意，应该在所有主节点上执行delete命令

---

编辑3 再编辑一次，展示我的“生产等级”解决方案

在创建集群之后。通过ssh连接到您的每个主要工作人员，然后启动一个

屏幕

，并每600秒运行一个无限循环删除旧文件（在下面的示例中超过120分钟）：

$ screen -RD
<new screen created>

$ while true; do
date --iso-8601=seconds
for I in $(seq 1 4); do
( cd /mnt/${I}/hadoop/yarn/nm-local-dir/application_* && sudo find . -type f -amin +120 -delete )
done
df -h | grep /mnt/
sleep 600
done

$screen-RD
$虽然正确；做
日期——iso-8601=秒
以美元计算的I（序号14）；做
（cd/mnt/${I}/hadoop/Thread/nm local dir/application_*&&sudo find.-类型f-amin+120-删除）
完成
df-h | grep/mnt/
睡600
完成

当此命令运行时，将自己与屏幕分离（

Ctrl+ad

）。您可以检查命令是否仍在使用

htop

运行

---

就是这样。

有一个已知的问题，即中间洗牌数据可能会泄漏。在此期间可能的解决办法有：

• 手动删除这些临时文件的解决方案
• 暂时禁用EFM。在这种情况下，临时文件直接由Thread管理，不依赖Spark进行清理

---

你能说明你用的是哪种方式的火花吗？这是一个重复运行的批处理作业，还是一个具有小批处理的长时间运行的流式作业？如果是后者，则火花清理钩可能仅在作业结束时发出，这可以解释泄漏。

谢谢您的回答。我更新了我的问题，澄清了我的用例。您是否有任何指向引用此已知问题的bugtracker的链接？在询问问题之前，我在调查中没有发现任何东西。