@hadoopusers

Страница 167 из 182
Рамиль
11.10.2018
13:35:31
очень похоже что ребут неймноды решил проблему

и проблема была именно в том о чем я и писал

Stanislav
11.10.2018
13:36:20
Про диск чекер в жире хдфс: hdfs-7722, hdfs-8617, hadoop-13738

http://blog.cloudera.com/blog/2016/12/hdfs-datanode-scanners-and-disk-checker-explained/

Google
Рамиль
11.10.2018
13:39:49
спасибо

но ребут реально решил траблу

Evgeny
11.10.2018
14:57:34
День добрый, а подскажите, есть hue и есть релизы на guthub. В чем различие release/cdh-release ? cdh-release совместима только с соответствующей cloudera-версией?

Nikolay
11.10.2018
19:38:24
Неймнода хранит чексумму и видит битый файл
Станислав, спасибо, что подключились к проблеме.

Евгений
11.10.2018
19:53:45
День добрый, а подскажите, есть hue и есть релизы на guthub. В чем различие release/cdh-release ? cdh-release совместима только с соответствующей cloudera-версией?
это релизы, которые готовятся под конкретную версию клаудеры, и встроены в неё. Сам хью может забежать вперёд и выкатиться дальше, независимо от всей сборки

Stanislav
12.10.2018
11:00:50
Коллеги, я смотрю группа по эйрфлоу достаточно активно кипит вопросами, и здесь часто пролетают вопросы по найфаю - предлагаю отдельную группу для него: @nifiusers Тем более экспертиза в плане найфая все больше растет, и достаточно много российских компаний выбирают его как основу для etl (не знаю, трезво ли оценивая риски и имея ли опыт работы с этим инструментом под нагрузкой :)

Daniel
12.10.2018
11:02:00
ну если данных и процессов на пару человек то можно и найфай

Stanislav
12.10.2018
11:03:04
Вот тот же вопрос возникает, когда слышу о его использовании как основном инструменте в компаниях 50-100 тысяч человек

Daniel
12.10.2018
11:04:41
там нет нормального планировщика, он требует ресурсы вычислительные для себя (т.е. прибивает гвоздями стэк и очень специфичный), и морда хоть и красивая (мне понравилась) но менеджить тонну процессов там я не представляю как

ну и не такой тривиальный как пропогандируется

Google
Daniel
12.10.2018
11:06:56
про планировщик я написал, хотя там и менеджмент ресурсов тогда уже надо

Stanislav
12.10.2018
11:07:09
Ну и раскидывание нагрузки по кластера только на уровне рут ?‍♂

С другой стороны аналоги...

Fedor
12.10.2018
15:28:04
Господа инженеры, а есть понимание, что будет с HDP после вливания Hortonworks в Cloudera?

Stanislav
12.10.2018
16:27:25
Интересно, они сами это знают в обоих компаниях

Mikhail
12.10.2018
16:38:22
А что может быть?
Ну несколько вариантов: 1. Закопают CDH и инженеры будут пилить HDP 2. Закопабт HDP и инженеры будут пилить CDH 3. Закопают оба и будут делать новый крутой с плюсами обоих и без минусов. Существующие будут поддерживать.

Сейчас очень интересный момент для выбора дистрибутива, потому что можно ошибиться, а вот переход может быть очень болезненным:) Надо ждать и смотреть:)

Grigory
12.10.2018
16:42:48
Сейчас очень интересный момент для выбора дистрибутива, потому что можно ошибиться, а вот переход может быть очень болезненным:) Надо ждать и смотреть:)
кстати такой вопрос, а что кроме тулчейна вокруг критично нужно от клаудерры или от хдп? например тебе; и чего нет в ваниле

Mikhail
12.10.2018
16:44:48
Юрий
12.10.2018
16:45:05
Мы вообще хотим свалить с них и собрать все сами. Уже так с кассандрой сделали

Grigory
12.10.2018
16:45:49
выкрутился, но интересно вот услышать какие цели, зачем конкретно пользуются кладуеррой? или пользуются потому что это как редхат ток хадуповый

и поему миграция будет боль втаком случае? единсвтенная боль что они (сдх и хдп) могут странные класспасы юзать, и какието кастомные ништяки пиъать туда (может быть) а может и нет

Uncel
12.10.2018
16:56:24
Все на mapr

Grigory
12.10.2018
17:00:12
тогда кого волнует так исльно что компании там сливаются?

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

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

Uncel
12.10.2018
17:02:46
А все начиналось с заталкивания lzo

Google
Grigory
12.10.2018
17:03:36
оч тяжело конечно с ними

Uncel
12.10.2018
17:06:58
В сферическом тыпрайзе в вакууме, да

Ton
13.10.2018
21:16:29
Ребят, нужен совет. У нас есть монга, в которую пишутся логи. Плюс время от времени они оттуда читаются, что замедляет запись. Запись идёт практически в реалтайме, из кафки. Так вот, чем можно заменить монгу для обеспечения наиболее быстрого доступа к данным? Возможно есть какие-то best practice на этот счёт?

Mikhail
13.10.2018
21:16:56
elastic search ?:)

Ton
13.10.2018
21:17:23
elastic search ?:)
А какие у него преимущества? В плане скорости?

Mikhail
13.10.2018
21:19:22
Ну технические решения надо в первую очередь принимать по функциональности, и потом по скорости. Можно конечно понять что с текущей монгой не так, и как её ускорить... Логи можно хранить вообще в чём угодно, зависит от их структуры хранения и природы запросов... Но для такой задачи как раз elastic search и делался:)

Ton
13.10.2018
21:26:14
Ну тогда где угодно можно хранить, что предоставляет удобный отсортированный key-value. Так с монгой в чем проблемы?
В том, что чтение больших объемов данных оттуда занимает слишком много времени

Uncel
13.10.2018
21:28:11
Если полнотекстовый поиск не нужен, попробуйте сливать в кликхаус

Ton
13.10.2018
21:30:51
Редис?
Хранить там всё, или какие-то выборки?

Старый
13.10.2018
21:30:55
Редис?
редис и чтение с диска?

Oleksandr
13.10.2018
21:31:12
Старый
13.10.2018
21:31:20
В памяти же.
им то надо на дисках

Ton
13.10.2018
21:31:46
им то надо на дисках
Нет, не надо на дисках)

Старый
13.10.2018
21:32:14
Нет, не надо на дисках)
?у вас оперативы тб и на сохранность пофиг?

Google
Ton
13.10.2018
21:32:29
Если полнотекстовый поиск не нужен, попробуйте сливать в кликхаус
А как он воспринимает одновременное чтение и запись в себя?

Uncel
13.10.2018
21:33:50
А как он воспринимает одновременное чтение и запись в себя?
Вставка большими пачками, маленькие выборки могут быть неэффективны

Ton
13.10.2018
21:34:05
?у вас оперативы тб и на сохранность пофиг?
К сожалению не так. Отказаться совсем от хранения на диске мы не можем. Скорее нужен симбиоз диска и ОЗУ, то есть кэширование

Александр
13.10.2018
21:34:20
Ton
13.10.2018
21:34:27
А много логов? Нужно долго их хранить? Все поля нужны ?
Логов много, они сыпятся в реалтайме. Хранить надо месяц

Ton
13.10.2018
21:34:58
ssd?
Не одарили, и это боль(

Александр
13.10.2018
21:35:13
Мы храним евенты пользователей, 5тб в кликхауз пихаем в месяц он их мило жмет

Старый
13.10.2018
21:35:20
Не одарили, и это боль(
ну тогда ребят, не ваши проблемы

Ton
13.10.2018
21:36:46
ну тогда ребят, не ваши проблемы
Мы пытаемся выжать максимум из того, что есть. Позже подъедут норм сервера, но кто знает, будет ли на них всё работать зачётно, если мы сейчас не оптимизируем по максимуму

Ton
13.10.2018
21:38:54
Мы храним евенты пользователей, 5тб в кликхауз пихаем в месяц он их мило жмет
Ого) Но нам надо иногда вытащить логи за 24 часа, при этом продолжая запись

Александр
13.10.2018
21:39:14
Ton
13.10.2018
21:39:43
Александр
13.10.2018
21:43:07
Лучше самому руками померять. У нас пока пизда просели запросы со средней скорости работы 0.7 секунд до 5-6

Roman
13.10.2018
21:45:29
А может постгря какая пережует с правильным ddl таблицы. Непонятно, сколько логов в итоге сыпется

Старый
13.10.2018
21:46:17
у вас мониторинг то вообще есть

Google
Старый
13.10.2018
21:46:29
на сколько диски загружены на монге

Ton
13.10.2018
21:53:48
Спасибо за советы, на некоторые вопросы я пока не знаю ответов, есть над чем подумать

Евгений
13.10.2018
21:54:52
Vladislav
14.10.2018
08:29:34
Уходите с монги на эластик

Вы упретесь в индексы

Рамиль
14.10.2018
12:36:36
В том же объеме, что и амбари?
даже лучше я бы сказал

Mironiken
15.10.2018
07:30:26
Был кейс с написанной на коленке прогой, которая по 1тб в день в HBase грузила

В целом туда ещё шли распределенные запросы

В плане постоянный поток небольших

Работало, но памяти жрало немало

Страница 167 из 182