為什么 Spark 作業會因“打開的文件太多”而失敗？

Question

在我的 Spark 作業的 shuffle 階段，我收到“太多打開的文件”。 為什么我的工作打開這么多文件？ 我可以采取哪些步驟來嘗試使我的工作取得成功。

Answer 1

這已在 spark 用戶列表中得到解答：

最好的方法絕對是盡可能增加 ulimit，這是我們在 Spark 中做出的一種假設，即集群將能夠移動它。

您可以通過減少減速器 [或每個節點使用的內核] 的數量來解決這個問題，但這可能會對您的工作產生一些性能影響。

通常，如果集群中的節點具有 C 個分配的內核，並且您使用 X 個 reducer 運行作業，那么 Spark 將並行打開 C*X 文件並開始寫入。 隨機合並將有助於減少創建的文件總數，但任何時候打開的文件句柄數不會改變，因此它不會幫助解決 ulimit 問題。

-帕特里克溫德爾

Answer 2

默認的 ulimit 是 1024，這對於大規模應用程序來說是低得離譜。 HBase 建議最高 64K； 現代 linux 系統似乎不會遇到這么多打開的文件的問題。

用

ulimit -a

查看您當前打開的最大文件數

ulimit -n

可以臨時更改打開文件的數量； 您需要更新系統配置文件和每用戶限制以使其永久化。 在 CentOS 和 RedHat 系統上，可以在

/etc/sysctl.conf
/etc/security/limits.conf

Answer 3

此錯誤的另一個解決方案是減少分區。

檢查您是否有很多分區：

someBigSDF.rdd.getNumPartitions()

Out[]: 200

#if you need to persist the repartition, do it like this
someBigSDF = someBigSDF.repartition(20)

#if you just need it for one transformation/action, 
#you can do the repartition inline like this
someBigSDF.repartition(20).groupBy("SomeDt").agg(count("SomeQty")).orderBy("SomeDt").show()