Небольшой тест производительности Hadoop/Mapreduce

    Давным давно задался себе вопросом «На сколько эфективно работает MapReduce ?»

    Появилась такая возможность и на кластере состоящим из 4 нодов в такой вот конфигурации я решил потестить:
    — 3 ноды: Intel Xeon CPU W3530 @ 2.80GHz 12GB RAM
    — 1 нода: Intel Xeon CPU X5450 @ 3.00GHz. 8GB RAM

    Операционка debian, hadoop 1.2 (с офф.сайта), java 7 (От ORACLE).

    Исходные данные:
    — ХМЛ файл: dumps.wikimedia.org/enwiki/20130904/enwiki-20130904-stub-meta-current.xml.gz
    — в распакованом состоянии файл занимает 18ГБ места.
    — 31М записей о страничках в вики.
    — Bzip2 сжимает этот файл в 2ГБ
    — 593.045.627 строк в файле


    Пример одной записи:
    <page>
        <title>AfghanistanHistory</title>
        <ns>0</ns>
        <id>13</id>
        <redirect title="History of Afghanistan" />
        <revision>
          <id>74466652</id>
          <parentid>15898948</parentid>
          <timestamp>2006-09-08T04:15:52Z</timestamp>
          <contributor>
            <username>Rory096</username>
            <id>750223</id>
          </contributor>
          <comment>cat rd</comment>
          <text id="74089594" bytes="57" />
          <sha1>d4tdz2eojqzamnuockahzcbrgd1t9oi</sha1>
          <model>wikitext</model>
          <format>text/x-wiki</format>
        </revision>
    </page>
    


    В качестве теста взял простую задачку которую можно решить как в консоле традиционным средством так и с помощу MapReduce. И задачка в двух словах выражается в таком вот виде:

    time bunzip2 -c /mnt/hadoop/data_hadoop/test.xml.bz2 | grep "<title>" |wc
    31127663 84114856 1382659030
    
    real 9m32.953s
    user 10m16.779s
    sys 0m12.737s
    


    Подобная задача решена на всём hadoop кластере за 3 минуты и 40 секунд. (да с паралельной распаковкой, распаковка делалась джавой, а не нативно).

    В случае если файл был в распакованом состоянии (18ГБ) то обработка заканчивалась на hadoop кластере за 2м и 30с. (быстрее всего за 2мин и 12 секунд). и в данном случае диски нагружены под 100%

    ну и на подумать )) файл был предварительно пережат pbzip2… на Intel Xeon CPU W3530 @ 2.80GHz

    time pbzip2 -d -c -p8 /mnt/hadoop/data_hadoop/testpbzip.xml.bz2 | grep "<title>" |wc
    31127663 84114856 1382659030
    
    real 2m44.507s
    user 21m28.493s
    sys 0m19.833s
    


    Я не собираюсь делать какой либо вывод ..., но где то в интернете встречал что hadoop кластер начинает себя показывать от 4 нодов… наверное у них были на то основания.
    • –5
    • 3,8k
    • 9
    Поделиться публикацией

    Похожие публикации

    Комментарии 9

      +6
      нет, ну если уж беретесь троллить 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 не является идеальным алгоритмом, но если уж начинать какую-то технологию троллить, то надо для начала в ней разобраться хорошенько, иначе могут помидорами закидать на простейших
        0
        xhumanoid, я не пытался тролить hadoop, а даже напротив.

        Меня интересовало насколько он медленнее обычного
        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 да… наверное это было бы лудше
        0
        Hadoop не предназначен для быстрых запросов. Это больше для batch processing, когда задачи на часы, или даже дни.
        Тогда и проявляется его мощь.

        Если же нужны небольшие запросы в реальном времени, советую обратить внимание на spark.apache.org/
          0
          Handoop создавался для предоставления возможности увеличить скорость ответа за счет распараллеливания плана выполнения запроса, и именно так применяется в большинстве проектов.
            +1
            Это не так. 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.
              +1
              Ну не совсем. В первую очередь Hadoop всё-таки создавался для распараллеливания работы Nutch-а, т.е. как раз для многочасовой пакетной работы. Поэтому, например, оверхед на запуск джобов и тасков не считался большим (подумаешь, 15 секунд в контексте нескольких часов вычислений). На этом фоне бенчмарк со временем выполнения в 2-3 минуты, конечно, выглядит смешным.
                0
                На этом фоне бенчмарк со временем выполнения в 2-3 минуты, конечно, выглядит смешным.

                Да, наверное это было не правельно
            0
            3 ноды на 18 гбайт? я 10 лет назад веник в комп брал на 80гбайт, а термином «big data» никто не козырял :)
            раз у вас есть кластер то поэкспериментируйте и определите сколько данных нужно закинуть в hadoop чтобы поиметь профит
              +1
              Я бы все-таки четко разграничил алгоритм (MapReduce) и инструмент (Hadoop). На сравнительно небольших данных Хадуп оказывается далеко не самым быстрым MR-фреймворком — есть целая вереница всяческих Спарков, ДПарков, Диско и прочих, которые запросто могут оказаться быстрее (и съесть при этом меньше компьютерных ресурсов, что немаловажно). Хотя бы даже «классика» — bashreduce.

              Я говорил много раз и не устану повторять, что Хадуп — отличный инструмент для действительно больших данных (скажем, от нескольких терабайт). На небольших данных иногда проще\быстрее\дешевле запустить какой-нибудь другой MR-фреймворк или вообще применить другой алгоритм.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое