鑑於Hadoop 0.21.0,該框架針對相對於每個單獨映射的打開文件描述符的數量做出了什麼假設並減少了操作？具體來說，哪些子操作會導致Hadoop在作業執行期間打開新的文件描述符或者溢出到磁盤？Hadoop中打開的文件描述符的預期消耗0.21.0
（這是故意忽略了使用MultipleOutputs，因爲它很清楚的螺釘與系統提供的擔保）。
我在這裏的理由很簡單：我想確保我寫的Hadoop保證每個作業每個映射器或縮減器需要有限數量的文件描述符。 Hadoop高興地將它從程序員中抽象出來，這通常是件好事，如果不是在服務器管理期間其他鞋子掉落的話。
我原本是asked this question on Server Fault從集羣管理方面看的東西。由於我也負責編程，因此這個問題同樣適用於此。
Here's a post，提供一些洞察問題：
這是因爲當你使用
MultipleOutputs類更小的文件被創建。 假設你有50個映射器，然後假設你沒有歪斜的數據，Test1將始終生成50個文件，但Test2會生成50到1000個文件（50Mappers x 20TotalPartitionsPossible），這會導致I/O性能下降。在我的基準測試中，爲Test1生成了199個輸出文件，爲Test2生成了4569個輸出文件。
這意味着，對於正常行爲，映射器的數量與打開的文件描述符的數量完全相等。 MultipleOutputs明顯地將此數字與映射器的數量乘以可用分區的數量相反。 Reducer然後照常進行，每減少一次操作就會生成一個文件（因此，一個文件描述符）。
然後問題就變成：在spill操作期間，大多數這些文件都被每個映射器保持打開，因爲輸出會被分割打亂。因此可用的文件描述符問題。
因此，當前假設，最大文件描述符限制應該是：
地圖相：
number of mappers * total partitions possible簡化階段：
number of reduce operations * total partitions possible
而且，就像我們說的，是那。
相關地，觀察Hadoop爲每個工作人員消耗全部1024個可用文件描述符並不太有趣。我已經提出了臨時性的限制，但這似乎是一個長期的編程和集羣管理策略。 – MrGomez 2010-12-05 02:30:54