鉴于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