给定Hadoop 0.21.0，框架对相对于每个单独的 map 和 reduce 操作的打开文件描述符的数量做出了哪些假设？具体来说，哪些子操作会导致 Hadoop 在作业执行期间打开新的文件描述符或溢出到磁盘？
（这是故意忽略使用MultipleOutputs，因为它非常明显地与系统提供的保证相吻合。）
我的理由很简单：我想确保我为 Hadoop 编写的每个作业都保证每个映射器或缩减器所需的文件描述符数量有限。Hadoop 很乐意将这一点从程序员那里抽象出来，这通常是一件好事，如果不是因为在服务器管理期间另一只鞋掉了下来。
我最初是从集群管理方面问这个关于服务器故障的问题。由于我还负责编程，所以这个问题在这里同样重要。
这是一篇文章，提供了一些对该问题的见解：
发生这种情况是因为使用
MultipleOutputs类时会创建更多小文件。假设您有 50 个映射器，然后假设您没有倾斜数据，Test1 将始终生成正好 50 个文件，但 Test2 将生成 50 到 1000 个文件（50Mappers x 20TotalPartitionsPossible），这会导致 I/O 性能下降。在我的基准测试中，为 Test1 生成了 199 个输出文件，为 Test2 生成了 4569 个输出文件。
这意味着，对于正常行为，映射器的数量完全等于打开的文件描述符的数量。MultipleOutputs显然，这个数字被映射器的数量乘以可用分区的数量。然后 reducer 照常进行，每次 reduce 操作生成一个文件（因此，一个文件描述符）。
那么问题就变成了：在spill操作过程中，这些文件中的大多数都被每个映射器保持打开状态，因为输出很高兴地被 split 处理了。因此，可用的文件描述符问题。
因此，当前假定的最大文件描述符限制应该是：
地图阶段：
number of mappers * total partitions possible减少阶段：
number of reduce operations * total partitions possible
正如我们所说，就是这样。