Вот пост , который предлагает некоторое представление о проблеме:
Это происходит потому, что при использовании класса MultipleOutputs создается больше небольших файлов.
Допустим, у вас есть 50 сопоставителей, а затем предполагается, что у вас нет искаженных данных, Test1 всегда будет генерировать ровно 50 файлов, а Test2 - от 50 до 1000 файлов (50Mappers x 20TotalPartitionsPossible), и это приводит к снижению производительности при вводе-выводе. В моем тесте было сгенерировано 199 выходных файлов для Test1 и 4569 выходных файлов для Test2.
Это подразумевает, что для нормального поведения число картографов точно эквивалентно количеству дескрипторов открытых файлов. MultipleOutputs очевидно искажает это число на количество картографов, умноженное на количество доступных разделов. Затем редукторы работают в обычном режиме, генерируя один файл (и, следовательно, один файловый дескриптор) на операцию сокращения.
Затем возникает проблема: во время операции spill большинство этих файлов остаются открытыми каждым картографом, так как вывод весело обрабатывается разделением. Отсюда проблема доступных файловых дескрипторов.
Таким образом, предполагаемый в настоящее время максимальный предел дескриптора файла должен составлять:
Фаза карты: number of mappers * total partitions possible
Уменьшить фазу: number of reduce operations * total partitions possible
И это, как мы говорим, вот что.