鉴于Hadoop 0.21.0,框架对于相对于每个单独的地图的打开文件描述符的数量做了什么假设并减少了操作？具体来说，哪些子操作会导致Hadoop在作业执行期间打开新的文件描述符或溢出到磁盘？
（这是故意忽略MultipleOutputs的使用，因为它非常明显地违背了系统提供的保证。）
我的理由很简单：我想确保我为Hadoop编写的每个作业都保证为每个映射器或减速器提供有限数量的所需文件描述符。 Hadoop高兴地从程序员那里抽象出来，如果没有其他鞋子在服务器管理期间丢失的话，这通常是一件好事。
我最初是asked this question on Server Fault来自群集管理方面的事情。由于我也负责编程，这个问题同样适用于此。
答案 0 :(得分：1)
Here's a post提供了对问题的一些见解：
这是因为使用
MultipleOutputs类时会创建更多小文件。 假设您有50个映射器，然后假设您没有偏斜数据，Test1将始终生成50个文件，但Test2将生成介于50到1000个文件之间（50Mappers x 20TotalPartitionsPossible），这会导致I / O性能下降。在我的基准测试中，为Test1生成了199个输出文件，为Test2生成了4569个输出文件。
这意味着，对于正常行为，映射器的数量与打开的文件描述符的数量完全相同。 MultipleOutputs显然会将这个数字与地图集的数量乘以可用分区的数量相矛盾。然后，Reducers正常进行，每次reduce操作生成一个文件（因此，一个文件描述符）。
然后问题变成：在spill操作期间，大多数这些文件都被每个映射器保持打开状态，因为输出通过拆分来快速地进行武装。因此可用的文件描述符问题。
因此，当前假定的最大文件描述符限制应为：
地图阶段：
number of mappers * total partitions possible缩小阶段：
number of reduce operations * total partitions possible
正如我们所说，就是这样。