Comments 9
нет, ну если уж беретесь троллить hadoop, то хоть подойдите правильно:
1) почему bunzip2, а не какой snappy
2) pbzip2 — а где тесты для хадупа с данным кодеком
3) а почему только wc прогнали, который к cpu совсем не требователен, давайте уже что-то действительно интересно и побольше
4) а какие настройки у хадуп кластера и код для MapReduce (получили стандатную конфигурацию с 2мя мэперами на ноду и 512mb по памяти)?
a) компресия вывода map перед reduce снижает нагрузку на диск
б) reuse jvm позволяет избавится от необходимости поднимать на каждый task по новому процессу
в) простейший work count из примеров для того и служит, чтобы показать пример кода, но уж никак не может служить бенчмарком, так как не оптимален по самое немогу, добавляем в пример этап combine и резко получаем неплохой буст, так как практически под ноль снижаем запись на диск после мэперов и трафик между мэпером и редьюсером тоже минимален
p.s. пихать хадуп везде смысла нету, так же и map-reduce не является идеальным алгоритмом, но если уж начинать какую-то технологию троллить, то надо для начала в ней разобраться хорошенько, иначе могут помидорами закидать на простейших
1) почему bunzip2, а не какой snappy
2) pbzip2 — а где тесты для хадупа с данным кодеком
3) а почему только wc прогнали, который к cpu совсем не требователен, давайте уже что-то действительно интересно и побольше
4) а какие настройки у хадуп кластера и код для MapReduce (получили стандатную конфигурацию с 2мя мэперами на ноду и 512mb по памяти)?
a) компресия вывода map перед reduce снижает нагрузку на диск
б) reuse jvm позволяет избавится от необходимости поднимать на каждый task по новому процессу
в) простейший work count из примеров для того и служит, чтобы показать пример кода, но уж никак не может служить бенчмарком, так как не оптимален по самое немогу, добавляем в пример этап combine и резко получаем неплохой буст, так как практически под ноль снижаем запись на диск после мэперов и трафик между мэпером и редьюсером тоже минимален
p.s. пихать хадуп везде смысла нету, так же и map-reduce не является идеальным алгоритмом, но если уж начинать какую-то технологию троллить, то надо для начала в ней разобраться хорошенько, иначе могут помидорами закидать на простейших
xhumanoid, я не пытался тролить hadoop, а даже напротив.
Меня интересовало насколько он медленнее обычного
Я опять сказал слово «медленнее»? Не обращай внимания на это… тут больше имеется введу что на посчитать «2+2» hadoop потребует больше ресурсов, но для пересчёта 1 миллиарда «2+2» сможет распаралелить это всё дело. Что кстати этот маленький и возможно не совсем правельный тест показал.
PS 1 snappy не позволяет «сплитить» файл и декодирвать отдельные его части. comphadoop.weebly.com/
PS 2 pbzip2 это паралельный bzip2… использует сразу несколько CPU
PS 3 там не только wc был а ещо и grep
PS 4 точно не помню… скорее всего было 4 маппера на каждую ноду
PS 4.1 вывода не было, я просто счотчик использовал (не было редюсеров)
PS 4.2 было включено ))
PS 4.3 да… наверное это было бы лудше
Меня интересовало насколько он медленнее обычного
grep "<title>" |wc
Я опять сказал слово «медленнее»? Не обращай внимания на это… тут больше имеется введу что на посчитать «2+2» hadoop потребует больше ресурсов, но для пересчёта 1 миллиарда «2+2» сможет распаралелить это всё дело. Что кстати этот маленький и возможно не совсем правельный тест показал.
PS 1 snappy не позволяет «сплитить» файл и декодирвать отдельные его части. comphadoop.weebly.com/
PS 2 pbzip2 это паралельный bzip2… использует сразу несколько CPU
PS 3 там не только wc был а ещо и grep
PS 4 точно не помню… скорее всего было 4 маппера на каждую ноду
PS 4.1 вывода не было, я просто счотчик использовал (не было редюсеров)
PS 4.2 было включено ))
PS 4.3 да… наверное это было бы лудше
Hadoop не предназначен для быстрых запросов. Это больше для batch processing, когда задачи на часы, или даже дни.
Тогда и проявляется его мощь.
Если же нужны небольшие запросы в реальном времени, советую обратить внимание на spark.apache.org/
Тогда и проявляется его мощь.
Если же нужны небольшие запросы в реальном времени, советую обратить внимание на spark.apache.org/
Handoop создавался для предоставления возможности увеличить скорость ответа за счет распараллеливания плана выполнения запроса, и именно так применяется в большинстве проектов.
Это не так. stackoverflow.com/questions/19627795/why-hadoop-is-not-a-real-time-platform
Если в этом «большинстве проектов» Hadoop используется для real-time запросов, то он используется не по назначению.
Для этих целей существуют другие проекты. incubator.apache.org/drill/ или Spark. Еще есть shark.cs.berkeley.edu/ — real-time Hive.
Если в этом «большинстве проектов» Hadoop используется для real-time запросов, то он используется не по назначению.
Для этих целей существуют другие проекты. incubator.apache.org/drill/ или Spark. Еще есть shark.cs.berkeley.edu/ — real-time Hive.
Ну не совсем. В первую очередь Hadoop всё-таки создавался для распараллеливания работы Nutch-а, т.е. как раз для многочасовой пакетной работы. Поэтому, например, оверхед на запуск джобов и тасков не считался большим (подумаешь, 15 секунд в контексте нескольких часов вычислений). На этом фоне бенчмарк со временем выполнения в 2-3 минуты, конечно, выглядит смешным.
UFO just landed and posted this here
Я бы все-таки четко разграничил алгоритм (MapReduce) и инструмент (Hadoop). На сравнительно небольших данных Хадуп оказывается далеко не самым быстрым MR-фреймворком — есть целая вереница всяческих Спарков, ДПарков, Диско и прочих, которые запросто могут оказаться быстрее (и съесть при этом меньше компьютерных ресурсов, что немаловажно). Хотя бы даже «классика» — bashreduce.
Я говорил много раз и не устану повторять, что Хадуп — отличный инструмент для действительно больших данных (скажем, от нескольких терабайт). На небольших данных иногда проще\быстрее\дешевле запустить какой-нибудь другой MR-фреймворк или вообще применить другой алгоритм.
Я говорил много раз и не устану повторять, что Хадуп — отличный инструмент для действительно больших данных (скажем, от нескольких терабайт). На небольших данных иногда проще\быстрее\дешевле запустить какой-нибудь другой MR-фреймворк или вообще применить другой алгоритм.
Sign up to leave a comment.
Небольшой тест производительности Hadoop/Mapreduce