Тем не менее Hive перестал болеть недугом Hadoop-based систем, когда надо ждать минуты для выполнения самого элементарного запроса на маленьком наборе данных. Hive теперь приблизился по скорости к Impala на небольших запросах, но Impala по-прежнему недоступны долгие запросы (я про fault-tolerance)
Ничего не мешает использовать Parquet в Hive, ORC я привел как одну из альтернатив plain text формату.
Я плохо знаком c Impala, посему не сочтите за холивар)
Если одна нода падает во время запроса — запрос падает целиком.
На самом деле это не большая проблема, потому что Impala обычно не используется для долгих запросов.
Надо заметить что Impala не использует Hadoop как средство вычисления, она использует тольео HDFS,
а вычислительный процесс организует сама.
На последних демо Hortonworks Hive летал быстрее Impala даже на мелких запросах (спасибо TEZ и реизпользованию контейнеров), не говоря уже о крупных.
Так же Impala совсем не fault-tolerance
Мне кажется в статье упущен важный фактор — скорость, а кластеры стоят достаточно дорого.
Я не фанат Hive и в целом не специалист в Hadoop environment, но вот мои доводы в пользу Hive:
— В Hadoop с версии 2.4.0 используется механизм TEZ, который представляет процесс вычисление как ацикличный граф.
Hive 13+ умеет пользоваться TEZ, Pig пока нет.
— Hive поддерживает бинарный формат хранения данных Orc, котороый дает огромный прирост данных в сравнении с CSV.
— Hive из коробки поддерживает partition-механизм, на сколько мне известно Pig без HCatalog этого не умеет.
У Hive раньше были большие проблемы со скоростью, как и у Pig,
но по заявлениям ребят из Hortonworks им удалось разогнать его в 100 раз (The Stinger initiative).
Также надо понимать что Hadoop environment развивается очень быстро и все меняется,
каждый Hadoop-провайдер (AWS EMR, Hortonworks, Cloudera) предоставляет разный набор компонент и версий.
Получилось сумбурно, но надеюсь, что основную мысль я выразил.
Я вобще-то уже писал вам feedback, очень понравился, но есть такой недочет, что если слово уже было добавленно то об этом нигде не упоминаеться, получаеться так, что я добавил 5 мин назад слово и выбрал для него перевод с наибольшим кол-вом голосов, дальше я добавлю опять это слово, то мне предложат остальные переводы и ни где нет упоминания о том что я уже выбрал лучший перевод для этого слова.
Все та же статья говорит что робот состоит из четырех слоев:
Из этой статьи видно что клетки не запакованы в оболочку.
Popular Mechanics пишет:
Even after 6 weeks, the stingray bot was still swimming with over 80 percent of its cells still alive and well.
Шесть недель прошло а они еще живы.
Ничего не мешает использовать Parquet в Hive, ORC я привел как одну из альтернатив plain text формату.
Я плохо знаком c Impala, посему не сочтите за холивар)
На самом деле это не большая проблема, потому что Impala обычно не используется для долгих запросов.
Надо заметить что Impala не использует Hadoop как средство вычисления, она использует тольео HDFS,
а вычислительный процесс организует сама.
Так же Impala совсем не fault-tolerance
Я не фанат Hive и в целом не специалист в Hadoop environment, но вот мои доводы в пользу Hive:
— В Hadoop с версии 2.4.0 используется механизм TEZ, который представляет процесс вычисление как ацикличный граф.
Hive 13+ умеет пользоваться TEZ, Pig пока нет.
— Hive поддерживает бинарный формат хранения данных Orc, котороый дает огромный прирост данных в сравнении с CSV.
— Hive из коробки поддерживает partition-механизм, на сколько мне известно Pig без HCatalog этого не умеет.
У Hive раньше были большие проблемы со скоростью, как и у Pig,
но по заявлениям ребят из Hortonworks им удалось разогнать его в 100 раз (The Stinger initiative).
Также надо понимать что Hadoop environment развивается очень быстро и все меняется,
каждый Hadoop-провайдер (AWS EMR, Hortonworks, Cloudera) предоставляет разный набор компонент и версий.
Получилось сумбурно, но надеюсь, что основную мысль я выразил.
Теперь и такой хард не купишь, тоже скажут что не смогут контролировать данные)