Что я могу ожидать от производительности Hive и Hadoop?

На самом деле я пытаюсь реализовать решение с помощью Hadoop, используя Hive на CDH 5.0 с Yarn. Итак, моя архитектура: 1 Namenode 3 DataNode Я запрашиваю ~ 123 миллиона строк с 21 столбцом.

Моя нода виртуализирована с 2vCPU @2.27 и 8 GO RAM

Итак, я попробовал какой-то запрос и получил некоторый результат, а после этого я попробовал те же запросы в базовом MySQL с тем же набором данных, чтобы сравнить результаты.

И на самом деле MySQL намного быстрее, чем Hive. Вот я и пытаюсь понять почему. Я знаю, что у меня плохие результаты из-за моих хостов. Мой главный вопрос: правильно ли подобран мой кластер?

Нужно ли мне добавлять тот же DataNode для этого объема данных (который, на мой взгляд, не очень велик)?

И если кто-то попробует запрос с примерно такой же архитектурой, поделитесь со мной своими результатами.

Спасибо !


hadoop hive cloudera-cdh
person Junayy    schedule 28.04.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я запрашиваю ~ 123 миллиона строк с 21 столбцом [...], что, на мой взгляд, не очень много.

Вот именно проблема, она не огромная. Hive — это решение для больших данных, которое не предназначено для работы с небольшими наборами данных, такими как тот, который вы используете. Это как пытаться использовать вилочный погрузчик, чтобы вывезти кухонный мусор. Конечно, это сработает, но, вероятно, быстрее просто вынуть его вручную.

Теперь, сказав все это, у вас есть несколько вариантов, если вы хотите, чтобы производительность в реальном времени была ближе к производительности традиционной СУБД.

  • Hive 0.13+, использующий TEZ, ORC и ряд других оптимизаций, значительно улучшающих время отклика
  • Impala (часть дистрибутива CDH) который полностью обходит MapReduce, но более ограничен в поддержке формата файла.

Изменить:

Я говорю, что с двумя узлами данных я получаю ту же производительность, что и с тремя.

Это совсем не удивительно. Поскольку Hive использует MapReduce для обработки операторов запросов (объединение, группировка и т. д.), на него ложатся все затраты, связанные с MapReduce. Эта стоимость более или менее постоянна независимо от размера данных и количества узлов данных.

Допустим, у вас есть набор данных со 100 строками. Вы можете увидеть 98% времени обработки при инициализации MapReduce и 2% при фактической обработке данных. По мере увеличения размера ваших данных затраты, связанные с MapReduce, становятся незначительными по сравнению с общим временем.

person Mike Park    schedule 28.04.2014
comment
Хорошо, спасибо за ваш ответ, поэтому мой набор данных слишком мал. Сегодня я провел другие тесты и обнаружил, что если я отключу узел данных (так что только 2 вместо 3), у меня будет аналогичный результат производительности. Это тоже из-за моего набора данных? - person Junayy; 29.04.2014
comment
Имеет ли значение, какой узел данных вы отключаете? - person Mike Park; 29.04.2014
comment
Нет, на самом деле у меня есть 3 узла данных, и я проверил это: 01+02, 02+03, 01+03, 01+02+03. Каждый раз у меня очень похожий результат по затраченному процессорному времени. Так что я не думаю, что один узел данных замедляет процесс... - person Junayy; 29.04.2014
comment
Итак, вы имеете в виду, что 2 узла данных работают так же, как 3 узла данных, или что 2 узла данных работают так же, как MySQL? - person Mike Park; 29.04.2014
comment
Я говорю, что с двумя узлами данных я получаю ту же производительность, что и с тремя. - person Junayy; 29.04.2014
comment
Хорошо, спасибо за вашу помощь. Hadoop выглядит очень универсальной системой! - person Junayy; 29.04.2014