Если другое - просьба указать что.
* работает только с Hive без плясок с бубном

мигель1Чтобы не создавать новую тему.Вообще надо было создать. Правда тогда бы я ее не увидел. :)) мигель1идет война Spark +hive vs impalaДавай разберемся с терминами и что к чему. Разные движки Как правильно было замечено, spark, hive, impala используют hive metastore, НО... Выполнение запроса даже если его выполнять из Spark используя Hive Context это не то же самое что выполнять запрос из Hive использую Spark engine. Детальнее можно начать отсюда: Query Engines for Hive: MR, Spark, Tez with LLAP – Considerations! . Существуют и функциональные различия - но это уже для весьма экзотических случаев https://spark.apache.org/docs/latest/sql-programming-guide.html#compatibility-with-apache-hive Чтоб прояснить ситуацию: в Hive (если все нормально сконфигурировано) движок можно элементарно менять с помощью set hive.execution.engine=spark/tez/mr (map reduce - default). И ключевой момент здесь, что путем изменения движка и подкручиванием параметров типа

Код: plaintext

1.
2.
3.
4.

set hive.exec.parallel;
set hive.exec.parallel.thread.number;
set mapreduce.map.cpu.vcores;
set mapreduce.reduce.cpu.vcores;
set mapred.reduce.tasks;

Можно без каких либо изменений запросов добиться ускорения в 10 раз и больше. Естественно помня о том, что значения должны быть адекватными и на кластере может выполняться множество запросов одновременно. В сети можно найти разнообразные сравнения Hive vs Impala авторства Hortonworks, которое показывает что Hive чуть ли не лучше импалы и возвращает результат за секунды. В реальности это конечно не так, а все дело в том, что для hadoop существует три основных вендора Cloudera/Hortonworks/MapR и импала эксклюзивный продукт Cloudera, поэтому Hortonworks старается всячески его "придавить". С технической стороны наиболее важно, что все движки для Hive написаны на java, а Impala - на С. Отсюда Impala очевидный лидер по скорости и в теории и для реальных задач. Но вместе со скоростью импала унаследовала и главную проблему сишных программ - утечки памяти. Периодически возникающие "Memory limit exceeded" не позволяют использовать импалу для критических запросов и лечатся только рестартом Impala daemon. Кроме того, подобное не всегда легко воспроизвести, потому что зависит не только от выделенной памяти, но и от числа одновременно выполняющихся запросов и их специфики. Конкуренты? Почему Impala и Hive нельзя считать полноценными конкурентами на данном этапе.

Hive начал поддерживать DML (update/insert/delete) с многочисленными "если", но все же. Отсутствие (по очевидным причинам) интеграции Impala и Spark не позволяет задействовать импалу при работе с Data Frames, соответственно единственным путь при программировании, скажем, на scala - соединиться, например, по jdbc и выполнить запрос.

И наиболее раздражающее, что одни и те же действия выполняются по разному, что может делать SQL код несовместимым. Например получение дня (Sunday, Monday etc) для Impala будет выглядеть dayname(column), а для Hive - date_format(column, 'EEEE'). И это один из примеров, которых сотни. Можно использовать UDF, но их надо отдельно подключать в Hive и Impala и в Impala могут возникнуть трудности с правами. Хотя опять таки плюсом является, что UDF можно программировать на C. Касательно возможностей SQL - у Impala они богаче, то есть, если запрос выполняется в Hive, то скорее всего выполнится и в Impala, но не всегда. :) Тут можно приводить еще вагон и тележку деталей (включая особенности и ограничения при работе с разными типами данных и прочее), но по сути это просто текущие проблемы с совместимостью, что не означает отсутствие конкуренции. Data loading into HDFS Ключевые вендоры реляционных СУБД держат руку на пульсе и, например, и Oracle и MSSQL уже добавили возможность offload таблиц в кластер. В идеальном случае было бы чтоб и перфоманс для Hive (mr/tez/spart) или Impala улучшался и функциональные возможности развивались и сближались при этом можно было бы выбирать любой движок, который может быть использован чтоб вытянуть данные из кластера. Но импала сейчас идет несколько по иному пути и позиционируется больше для ad-hoc запросов.

Создавая тему, мне, имело смысл указать только для выполнения запросов.

DDL без вариантов должно выполняться через командную строку во избежание проблем с правами.

В то же время в хадуп данные часто денормализованы и работать с таблицами по пару сотен колонок через командную строку это полный ад.

Из универсальных SQL клиентов стоит добавить еще этот: DBeaver .

dbms_photoshop Data offloading into HDFS Fixed.

мигель1Спасибо за ответ. у меня более глобальная проблема.Это уже совсем оффтоп. Если интересно - создай отдельную тему, я там поделюсь опытом.
NePZА действительно, почему hue не включили в список?Второй пункт - Web UI.

Yo.!а вот это, это из собственного опыта ?Да. Кластер используется достаточно интенсивно и если оно начало валиться, то потом даже если все запросы прибить и оставить одного пользователя, то до рестарта демона ошибка не уходит.

Нашел у себя в заметках, что более детально формулировка может звучать так
Но после "Memory limit exceeded" вроде могут идти и другие причины.

Если погуглить по "Query did not have enough memory to get the minimum required buffers in the block manager", то первая ссылка у меня
https://community.cloudera.com/t5/Interactive-Short-cycle-SQL/Impala-memory-issue-Query-did-not-have-enough-memory-to-get-the/m-p/41101 This is almost certainly one of the known issues with Impala's previous YARN integration (via Llama). There were some fixes to that code in Impala 2.4 but you could still get this sort of unexpected failure. It's recommended that you do not use Impala on YARN, and instead to statically allocate resources to Impala for the time being. Cloudera Manager has a feature called "Static Service Pools" that can help with that, but it's not necessary. The CM documentation has more information.

We are working on improving Impala resource management, but it's going to take some time and we don't yet have a target release yet.Но этот ответ больше года назад и у нас ошибка валится и на Impala2.3.0-cdh5.5.6 и на Impala2.7.0-cdh5.10.1 и "statically allocate resources to Impala".
Более того мы обращались в Cloudera и они пока не могут предложить решение.

Так что пока пришлось отключить Impala in production и используем в других environment для ad-hoc запросов.

Хотя для ETL она тоже хороша, но из-за нестабильности пока увы применить не можем.

Еще один клиент, поддерживающий кастомные JDBC drivers.

Rapid SQL

Надо будет как-нибудь написать сравнение их всех как будет время...

Yo.!dbms_photoshop,

у нас на кластере 300+ гб и подозреваю импала просто не натыкается на что либо, где не хватает памяти. я на игровой виртуалке натыкался на Out of memory: Kill process 6439 (impalad) score 464 or sacrifice child, но там я спецом насиловал. имхо потому они и не позиционируют импалу по тяжелые ETL или джобы, я понял они позиционируют импалу как интерфейс внешним пользователям, типа отчетики, дата анлитики с нехитрыми квери и т.п.
а что у вас делает ETL, spark ? как у него с надежностью ?Ни Impala ни Hive не особо friendly to multiple joins.
Число соединений имеет смысл минимизировать в том числе и из-за дизайна.
То есть, если скажем в Оракле есть таблица фактов и 10 измерений, то в HDFS имеет смысл создать одну таблицу с 400 колонками.
Хотя все определяют детали. Пока в основном используем колоночный формат parquet и широкие таблицы, хотя у OCR есть свои фишки и я его пока особо не гонял.

ETL бывает весьма мудреный с граппировками, аналитическими функциями и даже несколькими десятками соединений.
Я однозначно рекомендовал бы использовать Spark 2.x (у нас 2.1) вместо Spark 1.x (пользовали 1.6), потому что 1.6 во-первых медлеенее, во-вторых имел проблемы со стабильностью и в третьих код не совсестимый. В 2.1 никаких проблем со стабильностью не наблюдал.

Объемы данных кластера 550+ТБ, дневной прирост 700ГБ.
Получается дневной прирост более чем в два раза превышает объем твоего кластера.

Yo.!,

Как я уже писал выше, сильно напрягает что в разных движках разные функции делают одно и то же и иногда невозможно написать код работающий и в Hive и в Impala.

Я в прошлом году пытался решить проблему путем инкапсуляции логики в UDF, но были проблемы
1) Hive. Там есть перманентные и временные UDF, но даже перманентные не видны при выполнении запросов через Hue/JDBC.
То есть можно создать функцию и использовать ее в Hive shell и всё.
2) Impala. Для создания функции нужны server wide admin privileges!
http://www.cloudera.com/documentation/enterprise/5-5-x/topics/cm_sg_sentry_service.html
3) Spark. Тоже были проблемы с видимостью функций. Уже не помню деталей.

Главная причина почему я это временно забросил - вторая. У себя на ноуте я импаловские UDF немного погонял в виртуалке Oracle Big Data Lite, но на работе каждый раз когда надо пересоздать функцию создавать задание админам требующее обоснования и прочей бюрократии - это не вариант.

PS. Я это все делал на более старой версии кластера, может в CDH5.10 что-то поменялось в лучшую сторону.

Yo.!на спарке ETL у вас java/scala api или sqlContext ?А зачем разделять?

https://amplab.cs.berkeley.edu/wp-content/uploads/2015/03/SparkSQLSigmod2015.pdf Rather
than forcing users to pick between a relational or a procedural API,
however, Spark SQL lets users seamlessly intermix the two.
Вообще рекомендую прочитать указанную pdf целиком.

Мой подход - реализовывать по возможности на SQL там где этот инструмент уместен и эффективен.
В иных случаях помогает "a bit of scala coding".

Конкретный пример вот Пятничная задачка. Смотрим назад. .
В итоге та задача была решена в Spark как раз с применением обоих подходов.

PS. А почему ты сидишь по серым ником?

Yo.!мы пришли к тому, что пишем sql под импалу, что бы проверять map-reduce кодПри чем здесь вообще map-reduce?
Это другой уровень абстракции. Безусловно надо понимать как работает движок, но как было замечено даже для Hive можно активировать три разных движка.
Ну и вы везучие если у вас логика достаточно проста, что можно писать запросы совместимые в Hive и Impala.
Yo.!честно говоря я не фанат "элегантных" sql, которые может прочесть лишь суровый ораклойдДело не столько во владении SQL сколько в отличной приспособленности SQL движков биг дейты для аналитики.
Ну и лаконичность записи упрощает поддерживаемость (если прокачать свою суровость).
Плюс логику можно вынести во view in Impala и аналитики могут играться с этим набором по своему усморению.
Yo.!лет 15 назад были зачотные баталии в "сравнения субд" и модератор был дурковатый. зато серые ники он забанить не смог :)
модератора сменили, но на всякий ...Текущего модератора SergSuper тоже адекватным и объективным я никак не назвал бы.