Очевидно, вам не хватает памяти где-то. Увеличение количества редукторов на самом деле вполне разумно. Посмотрите статистику веб-интерфейса JobTracker и посмотрите, сколько байтов выходит из картографа. Разделите это на количество задач сокращения, и это довольно приблизительная оценка того, что получает каждый редуктор. К сожалению, в долгосрочной перспективе это работает, только если ваши ключи распределены равномерно.
В некоторых случаях JOIN (особенно реплицированный вид) вызовет этот тип проблемы. Это происходит, когда у вас есть «горячая точка» определенного ключа. Например, предположим, что вы выполняете какое-то соединение, и один из этих ключей отображается в 50% случаев. Какому-либо редуктору посчастливится справиться с этим ключом, он будет забит. Возможно, вы захотите выяснить, какие клавиши вызывают горячие точки, и соответственно обработать их. По моим данным, эти горячие точки обычно бесполезны. Чтобы узнать, что горячо, просто наберите GROUP BY и COUNT и выясните, что часто появляется. Тогда, если это бесполезно, просто FILTER из него.
Другим источником этой проблемы является UDF Java, который агрегирует слишком много данных. Например, если у вас есть UDF, который проходит через пакет данных и собирает записи в какую-то структуру данных списка, возможно, вы перегружаете свою память значением горячей точки.
Я обнаружил, что более новые версии Pig (особенно версии .8 и .9) имеют гораздо меньше проблем с памятью. У меня было довольно много случаев исчерпания кучи в .7. В этих версиях обнаружение дисков намного лучше, так что если он собирается уничтожить кучу, он достаточно умен, чтобы пролить на диск.
Чтобы я мог быть более полезным, вы можете опубликовать свой сценарий Pig, а также указать, какую версию Pig вы используете.