Комментарии 6
>с большими инсталляциями, подобных таким, какие работают в «Ростелекоме».
Из чистого любопытства — большими это сколько?
>suspend=y,address=6000
Я-я (нем). С большой вероятностью просто не запустится, скажет что порт занят. Или у вас недостаточно большой и нагруженный кластер ;) Например, Spark UI по умолчанию стартует с портом 4040, и если он занят — увеличивает номер порта на единицу. Так вот, у нас запуск на портах типа 4059 — совсем не редкость.
Я бы сказал, что для упрощения отладки MapReduce надо для начала перестать писать на MapReduce. И перейти на что-то более пригодное для целей тестирования, где маппер — это чистая функция, без примесей Hadoop API, которую можно протестировать автономно.
Apache Crunch тот же — намного удобнее уже, особенно с учетом того, что есть локальный режим запуска — один из трех штатных (включая Yarn и еще Spark), в котором как раз можно подцепиться отладчиком (конечно же, со всеми ограничениями такого режима). Ну и сам спарк в общем-то, в режиме --master local.
Из чистого любопытства — большими это сколько?
>suspend=y,address=6000
Я-я (нем). С большой вероятностью просто не запустится, скажет что порт занят. Или у вас недостаточно большой и нагруженный кластер ;) Например, Spark UI по умолчанию стартует с портом 4040, и если он занят — увеличивает номер порта на единицу. Так вот, у нас запуск на портах типа 4059 — совсем не редкость.
Я бы сказал, что для упрощения отладки MapReduce надо для начала перестать писать на MapReduce. И перейти на что-то более пригодное для целей тестирования, где маппер — это чистая функция, без примесей Hadoop API, которую можно протестировать автономно.
Apache Crunch тот же — намного удобнее уже, особенно с учетом того, что есть локальный режим запуска — один из трех штатных (включая Yarn и еще Spark), в котором как раз можно подцепиться отладчиком (конечно же, со всеми ограничениями такого режима). Ну и сам спарк в общем-то, в режиме --master local.
Я-я (нем). С большой вероятностью просто не запустится, скажет что порт занят. Или у вас недостаточно большой и нагруженный кластер ;) Например, Spark UI по умолчанию стартует с портом 4040, и если он занят — увеличивает номер порта на единицу. Так вот, у нас запуск на портах типа 4059 — совсем не редкость.
В конкретном примере я использовал sandbox на виртуальной машине и у меня был настроен порт 6000, на живом кластере это будет скорее всего другой порт.
Я бы сказал, что для упрощения отладки MapReduce надо для начала перестать писать на MapReduce. И перейти на что-то более пригодное для целей тестирования, где маппер — это чистая функция, без примесей Hadoop API, которую можно протестировать автономно.
Что на ваш взгляд более пригодное для тестирования?
Сменить вектор направления в большой копании не так просто, есть старый код который требует поддержки а переписовать на что то новое порой не хватает времени.
Хотя мысли попробовать spark посещают.
>на живом кластере это будет скорее всего другой порт.
И к сожалению, возможно занятый. Так что выбор свободного порта (и способ донести знание о нем до отладчика) — это отдельная интересная тема. Я давно подумываю о том, чтобы научиться доставать это как-то через Yarn.
>Что на ваш взгляд более пригодное для тестирования?
Если вы хотите похожее на MapReduce? Я думаю что все-таки Crunch тут максимально близок. Spark — это уже более сильное изменение.
Но по сути… в общем-то там и там вы просто меняете класс mapper на экземпляр объекта, реализующий интерфейс типа mapper с одним методом T map(S source). Самое главное что в итоге вы эти экземпляры можете создавать и тестировать без фреймворка, потому что они к нему уже не привязаны совсем (максимум — будут Writable). В Spark в этой же роли например UDF, которые от Spark API тоже отвязаны, и тестируемы.
И к сожалению, возможно занятый. Так что выбор свободного порта (и способ донести знание о нем до отладчика) — это отдельная интересная тема. Я давно подумываю о том, чтобы научиться доставать это как-то через Yarn.
>Что на ваш взгляд более пригодное для тестирования?
Если вы хотите похожее на MapReduce? Я думаю что все-таки Crunch тут максимально близок. Spark — это уже более сильное изменение.
Но по сути… в общем-то там и там вы просто меняете класс mapper на экземпляр объекта, реализующий интерфейс типа mapper с одним методом T map(S source). Самое главное что в итоге вы эти экземпляры можете создавать и тестировать без фреймворка, потому что они к нему уже не привязаны совсем (максимум — будут Writable). В Spark в этой же роли например UDF, которые от Spark API тоже отвязаны, и тестируемы.
На много более простой способ написания больший и сложных job: github.com/twitter/scalding
Я давно подумываю о том, чтобы научиться доставать это как-то через Yarn.
Было-бы интересно почитать про порты. Так то обычно я использую порт который мне дал администратор: )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование и отладка MapReduce