каков вывод команды host 'ip of n50656.compute.internal'?

ёлки-палки

там по 2 интерфейса на серер, хадупы бегают по bogon'ам

вместо "ip of n50656.compute.internal" имею в виду, что здесь должен быть ip адрес ноды с именем n50656.compute.internal

PING n50656.compute.internal (172.31.0.109) 56(84) bytes of data.

теперь host 172.31.0.109

109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal.

и на всякий случай - это команды были выполнены на ноде, с которой ошибка?

да

за одну джобу 2-3 ошибки стабильно

а ОС-то какая?

и ещё раз поподробнее про то, как проверяется отсутствие ООМ

Ubuntu 16.04.5 LTS dmesg | egrep -i 'killed proces' например)

На всех нодах прогнал: 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal. 109.0.31.172.in-addr.arpa domain name pointer n50656.compute.internal.

grep "Killed process" /var/log/syslog так тоже нет

а grep -i oom /var/log/syslog ну так, на всякий случай

тоже чисто

syslog актуальный на момент ошибки?

посл. ошибка рано утром, по идее, актуальный

по journalctl -r | grep … тоже не видно ничего

есть ещё предположение - ipv6 вкл/выкл?

есть ещё предположение - ipv6 вкл/выкл?

ipv6 вообще чаще всего зло

Ловите олдфага

Ловите олдфага

ловите человека у которого postgres от его наличия ошибки ловил, хотя в pg_hba даже слова про ipv6 нет

9к коннектов и записей в сек, периодически ошибки подключения, вырутаешь ipv6 через sysctl.conf, всё, ошибок нет

Это печально конечно

есть ещё предположение - ipv6 вкл/выкл?

выключен везде через sysctl

выключен везде через sysctl

?у меня программист убил hbase

дай ему по шее

?у меня программист убил hbase

Как будто это сложно. Присматривай за ним (хбейз) внимательнее

Как будто это сложно. Присматривай за ним (хбейз) внимательнее

какой query history лучше смотреть

@ZeratulZ /var/lib/ambari-agent/data/errors-274.txt вот как пример, ссылается на такой лог, а его нет

скорее всего вывода вообще не было

еще возможно он удалился после завершения операции

Здравстуйте коллеги, хочу спросить у тех кто пользуется SparkStreaming (который Structured) как у вас устроен деплой и мониторинг над приложениями? На сколько стабильно он бежит? Мир стриминга для меня пока еще нов и полон сюрпризов) буду благодарен за любые советы о возможных граблях

Всем привет) Может кто-нибудь может помочь немного начинающему? У меня тут проблемы с пониманием вещей) Смотрите Допустим у меня есть кластер, на нем хадуп + спарк Есть БД, которая лежит на другой машине, вне кластера Я стартую спарк джобу - она конектится к этой базе (jdbc, какой-то нативный коннектор - не суть) создает из данных RDD, что-нибудь фильтрует, мапает и сохраняет обратно В этом случае где будут проходить все вычисления? RDD же, насколько я понимаю, это о распределенных/удаленных данных

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

Спасибо) Ну я имею ввиду - а где именно она будет выполняться? Если данные вне кластера, то они будут загружаться в кластер со спарком и там распределяться? или как-нибудь по-другому

если загрузил в память спарка - значит будет в памяти кластера спарка все выполняться

вроде понятнее, спасибо)

Только если мне память не изменяет, то если на кластере запускаешь jdbc, то надо чтобы у всех нод кластера был доступ к базюке.

ну в общем да, но есть нюансы. чтобы вычитка jdbc также пареллелилась, а не только последующая обработка, надо руками описать, как пратицировать данные, задать числовую колонку, min/max значения и количество партиций. без этого данные будут тянуться в один поток, подозреваю что на драйвере, но это не на 100% уверен

Вроде все же по экзекуторам распределятся таски, поэтому если поставишь какой-нить пацанский numPartitions, то можно заддосить базу потенциально

это да, просто главное не забыть его поставить, чтобы не тащить как лох в один поток )) ну еще можно fetchSize поиграться, на медленных соединениях его увеличение радикально улучшало производительность. но там свои приколы начинаются

Как-то раз тянул большие куски из оракла с fetchSize 0 (как оказалось) и сетовал админам, что у них крайне медленная база.

а можете, плз, рассказать чуть подробнее как это распаралелить? что, где, как нужно настроить

или где об этом можно почитать)

Вообще довольно просто гуглится: https://docs.databricks.com/spark/latest/data-sources/sql-databases.html#manage-parallelism На датабриксе в целом можно получить какую-то первичную инфу по вопросу. Ну а так чтобы параллелить, помимо опций jdbc , тебе нужно запускать на кластере и удостовериться что на всех нодах кластера есть нужный тебе jdbc драйвер

Спасибо)

Всем привет. Перехожу на новый проект, там активно юзается хайв. На днях будет много времени почитать литературу, в интернетах советуют "Programming Hive: Data Warehouse and Query Language for Hadoop", но у этой книги вроде как Release Date: September 2012. Подскажите плиз, есть ли смысл начать с нее или информация совсем устарела?

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

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

Всем привет. Перехожу на новый проект, там активно юзается хайв. На днях будет много времени почитать литературу, в интернетах советуют "Programming Hive: Data Warehouse and Query Language for Hadoop", но у этой книги вроде как Release Date: September 2012. Подскажите плиз, есть ли смысл начать с нее или информация совсем устарела?

Посмотри оф доку хайва, она достаточно маленькая. Хайв до какого то момента быстро прогрессировал, вот только по годам хз - после 2012 или нет.

если не брать во внимание последние нововведения - типа Hive LLAP и ACID Transactions, то с точки зрения самой архитектуры все более менее стабильно. есть куча нюансов, которая еще будет зависеть от конкретного дистрибутива и версии Hive на ней. В качестве забавного примера - изначально в Hive ввели индексы, а с версии 3.0 - выпиливают нафиг ))

если не брать во внимание последние нововведения - типа Hive LLAP и ACID Transactions, то с точки зрения самой архитектуры все более менее стабильно. есть куча нюансов, которая еще будет зависеть от конкретного дистрибутива и версии Hive на ней. В качестве забавного примера - изначально в Hive ввели индексы, а с версии 3.0 - выпиливают нафиг ))

Индексы - Вот и умерла последняя надежда сделать у себя хайв чуточку побыстрее. Похоже хорошо, что руки не дошли :)

Хотя ллап хорошо справляется с мелкими запросами

обоснование у них конечное любопытное для этого ) https://issues.apache.org/jira/browse/HIVE-18448?src=confmacro

а кто-то кстати рассматривал связку HBase+Phoenix как альтернативу Hive?

хотя все эти попытки напоминают конструктор "собери СУБД сам"...

Ахха. , if they need fast retrieval of larger sets of data, or fast joins, aggregations, they can use Apache Impala.

Вопрос, зачем тогда нужен хайв

Всем спасибо ?

Ахха. , if they need fast retrieval of larger sets of data, or fast joins, aggregations, they can use Apache Impala.

Забавно, т.е. даже не пытаются конкурировать?%)

Забавно что это сделал товарищ из Hortonworks

Забавно, т.е. даже не пытаются конкурировать?%)

Не понятно, в чем тогда Пойнт использования хайва, если все признают его неудобным и медленным для всех видов нагрузки

Не понятно, в чем тогда Пойнт использования хайва, если все признают его неудобным и медленным для всех видов нагрузки

он бесплатный

impala платная вроде как

ну получается что единственная полезная вещь от него - Hive metastore )

импала же не отказоустойчива по идее

и нужна скорее для аналитических запросов

impala платная вроде как

А как же апач импала?

Impala is open source (Apache License).

ну получается что единственная полезная вещь от него - Hive metastore )

Ну можно использовать hive metastore + impala / presto

Импала под аппачем. Она не платная. Просто инструмент для другого...

ну тут скорее про то, что она штатно идет с CDH, а не с HDP, а у CDH немного более строгая политика лицензирования

а так ваниллу можно и самому раскатать, как обычно ))

Hive - ворочать сложные большие джобы не оглядываясь на память и ядра. Impala - быстро поработать с готовой витринной, которая к тому же ещё и кешируется при повторных запросах :)

Не понятно, в чем тогда Пойнт использования хайва, если все признают его неудобным и медленным для всех видов нагрузки

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

Hive - ворочать сложные большие джобы не оглядываясь на память и ядра. Impala - быстро поработать с готовой витринной, которая к тому же ещё и кешируется при повторных запросах :)

+1, по факту обе нужны, видимо потому и оторвали, как описал Золтан в тикете:(

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

А там внутри архитектура не как у ллап, когда тяжёлые запросы отдаются на откуп движку хайва?

Но упаси вас бог начать применять Импалу на проде :) Если заменить слово геморрой на слово опыт. То вы получите кучу опыта. При том опыт будет на столько глубокий, что вплоть до работы с исходниками и специфических настроек jvm’ки :)

Но упаси вас бог начать применять Импалу на проде :) Если заменить слово геморрой на слово опыт. То вы получите кучу опыта. При том опыт будет на столько глубокий, что вплоть до работы с исходниками и специфических настроек jvm’ки :)

Имеется ввиду встраивание в production workflows ?

Имеется ввиду встраивание в production workflows ?

Имеется ввиду поставить джобы на продуктивную среду под SLA.

Оно не работает из коробки стабильно :(

Hive - ворочать сложные большие джобы не оглядываясь на память и ядра. Impala - быстро поработать с готовой витринной, которая к тому же ещё и кешируется при повторных запросах :)

У меня Hive даже на нескольких джоинах падал, Impala и Phoenix те же запросы орабатывал нормально и даже за приемлемое время

У меня Hive даже на нескольких джоинах падал, Impala и Phoenix те же запросы орабатывал нормально и даже за приемлемое время

Сомнительное достижение :) Чего ты джойнил то?

И что жило под хайвом? Tez, MR, Spark?

На MR Hive как трактор. Нужно время, но прожует все.

Tez и Spark более чувствительные, но и им далеко до Impal’ы.