#performance #configuration #hadoop #mapreduce #hbase
#Производительность #конфигурация #hadoop #mapreduce #hbase
Вопрос:
Для клиента я изучал краткосрочную возможность запуска кластера hadoop с использованием Cloudera на AWS EC2. По большей части результаты были ожидаемыми, поскольку производительность логических томов в основном ненадежна, тем не менее, делая все возможное, я заставил кластер работать достаточно хорошо для данных обстоятельств.
Прошлой ночью я провел полное тестирование их скрипта импортера, чтобы извлекать данные из указанного пути HDFS и отправлять их в Hbase. Их данные несколько необычны тем, что записи имеют размер менее 1 КБ и были объединены в блоки размером 9 МБ. Всего имеется около 500 тыс. текстовых записей, которые извлекаются из gzips, проверяются на работоспособность, а затем переходят на фазу восстановления.
Задание выполняется в соответствии с ожиданиями среды (я ожидаю количество разлитых записей), но одна действительно странная проблема заключается в том, что когда задание выполняется, оно выполняется с 8 редукторами, но 2 редуктора выполняют 99% работы, а остальные 6 выполняют часть работы.
Моя до сих пор непроверенная гипотеза заключается в том, что я упускаю важную настройку shuffle или blocksize в конфигурации задания, из-за которой большая часть данных помещается в блоки, которые могут использоваться только 2 редукторами. К сожалению, в последний раз, когда я работал над Hadoop, набор данных другого клиента находился в файлах lzo объемом 256 ГБ на физически размещенном кластере.
Чтобы уточнить, мой вопрос; есть ли способ настроить M / R-задание, чтобы на самом деле использовать более доступные редукторы либо путем уменьшения выходного размера карт, либо заставляя каждый редуктор сокращать объем данных, которые он будет анализировать. Даже улучшение на 4 редуктора по сравнению с текущими 2 было бы значительным улучшением.
Ответ №1:
Похоже, у вас возникают горячие точки в ваших редукторах. Вероятно, это связано с тем, что конкретный ключ очень популярен. Каковы ключи в качестве выходных данных mapper?
Здесь у вас есть несколько вариантов:
- Попробуйте больше редукторов. Иногда вы получаете странные артефакты в случайности хэшей, поэтому иногда помогает простое число редукторов. Скорее всего, это не исправит.
- Напишите пользовательский разделитель, который лучше распределяет работу.
- Выясните, почему куча ваших данных объединяется в два ключа. Есть ли способ сделать ваши ключи более уникальными, чтобы разделить работу?
- Есть ли что-нибудь, что вы можете сделать с объединителем, чтобы уменьшить объем трафика, поступающего на редукторы?
Комментарии:
1. Мне нужно будет просмотреть справочную карту клиента / уменьшить приложение, но я думаю (надеюсь), что проблема с ключом может быть виновником. Для запуска кластера и его стабилизации требуется около получаса (namenode safemode и т. Д.), Затем еще несколько часов для запуска / тестирования / проверки, Но я вернусь к проверке ответа, если это окажется так.
2. В итоге я написал быстрый пользовательский M / R, чтобы разобраться. Импорт клиента использует редуктор идентификаторов (исходные данные из пакета hbase mapreduce без расширения), и на самом деле для их первичного ключа есть только 2 значения. В противном случае количество элементов всех других значений в записи либо двоичное, либо равно общему набору записей. Я знаю, что это другой вопрос, но знаете ли вы, могут ли классы импорта hbase по умолчанию объединять разрозненные ключи в задачи сокращения?