Для клиента я определил краткосрочную выполнимость запуска кластера hadoop-аромата Cloudera на AWS EC2. По большей части результаты были ожидаемы при том, что производительность логических томов была в основном ненадежной, что говорит о том, что, делая все возможное, я получил кластер, работающий достаточно хорошо в данных обстоятельствах.
Прошлой ночью я запустил полный тест их сценария импорта, чтобы извлечь данные из указанного пути HDFS и перенести их в Hbase. Их данные несколько необычны тем, что записи меньше 1 КБ за штуку и скомпонованы в 9-МБ сжатые блоки. Всего около 500 тыс. Текстовых записей, которые извлекаются из gzips, проверяются на работоспособность, а затем передаются на этап редуктора.
Задание выполняется в соответствии с ожиданиями среды (я ожидаю количество пролитых записей), но одна действительно странная проблема заключается в том, что при выполнении задания оно выполняется с 8 редукторами, а 2 редуктора выполняют 99% работы, в то время как остальные 6 выполняют часть работы.
Моя до сих пор не опробованная гипотеза состоит в том, что в конфигурации задания я пропускаю критическую настройку тасования или размера блока, из-за которой большая часть данных помещается в блоки, которые могут быть использованы только двумя редукторами. К сожалению, в прошлый раз, когда я работал над Hadoop, набор данных другого клиента был в lz-файлах размером 256 ГБ в физически размещенном кластере.
Чтобы уточнить мой вопрос; Есть ли способ настроить задание M / R, чтобы фактически использовать больше доступных редукторов, либо уменьшив выходной размер карт, либо заставив каждый редуктор сократить объем данных, которые он будет анализировать. Даже улучшение 4 редукторов по сравнению с текущими 2 было бы серьезным улучшением.