очень похоже что ребут неймноды решил проблему

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

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

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

спасибо

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

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

Неймнода хранит чексумму и видит битый файл

Станислав, спасибо, что подключились к проблеме.

Станислав, спасибо, что подключились к проблеме.

+

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

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

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

Спасибо

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

ну если данных и процессов на пару человек то можно и найфай

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

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

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

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

Это все меркнет на фоне медленной работы и отсутствия приоритезаций заданий

про планировщик я написал, хотя там и менеджмент ресурсов тогда уже надо

Ну и раскидывание нагрузки по кластера только на уровне рут ?‍♂

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

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

Интересно, они сами это знают в обоих компаниях

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

А что может быть?

А что может быть?

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

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

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

кстати такой вопрос, а что кроме тулчейна вокруг критично нужно от клаудерры или от хдп? например тебе; и чего нет в ваниле

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

С минусами обоих и без плюсов)

кстати такой вопрос, а что кроме тулчейна вокруг критично нужно от клаудерры или от хдп? например тебе; и чего нет в ваниле

+

кстати такой вопрос, а что кроме тулчейна вокруг критично нужно от клаудерры или от хдп? например тебе; и чего нет в ваниле

Ну лично мне ничего не нужно, но тут у каждого свой ответ на такой вопрос:)

Мы вообще хотим свалить с них и собрать все сами. Уже так с кассандрой сделали

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

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

Все на mapr

тогда кого волнует так исльно что компании там сливаются?

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

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

А все начиналось с заталкивания lzo

оч тяжело конечно с ними

В сферическом тыпрайзе в вакууме, да

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

Там метрики есть встроенные , исмпала, мониторинг и версирование конфига

Там метрики есть встроенные , исмпала, мониторинг и версирование конфига

В том же объеме, что и амбари?

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

elastic search ?:)

elastic search ?:)

А какие у него преимущества? В плане скорости?

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

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

elastic search разве не заточен на семантический поиск? Нам это не нужно. У нас тупо логи достаются по timestamp. И хотелось бы ускорить именно чтение оттуда. Возможно как-то кэшировать заранее выборки...

elastic search разве не заточен на семантический поиск? Нам это не нужно. У нас тупо логи достаются по timestamp. И хотелось бы ускорить именно чтение оттуда. Возможно как-то кэшировать заранее выборки...

Ну тогда где угодно можно хранить, что предоставляет удобный отсортированный key-value. Так с монгой в чем проблемы?

Ну тогда где угодно можно хранить, что предоставляет удобный отсортированный key-value. Так с монгой в чем проблемы?

В том, что чтение больших объемов данных оттуда занимает слишком много времени

Если полнотекстовый поиск не нужен, попробуйте сливать в кликхаус

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

Редис?

Редис?

Хранить там всё, или какие-то выборки?

Редис?

редис и чтение с диска?

редис и чтение с диска?

В памяти же.

В памяти же.

им то надо на дисках

Хранить там всё, или какие-то выборки?

инфлюкс

им то надо на дисках

Нет, не надо на дисках)

Нет, не надо на дисках)

?у вас оперативы тб и на сохранность пофиг?

Если полнотекстовый поиск не нужен, попробуйте сливать в кликхаус

А как он воспринимает одновременное чтение и запись в себя?

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

А много логов? Нужно долго их хранить? Все поля нужны ?

А как он воспринимает одновременное чтение и запись в себя?

Вставка большими пачками, маленькие выборки могут быть неэффективны

?у вас оперативы тб и на сохранность пофиг?

К сожалению не так. Отказаться совсем от хранения на диске мы не можем. Скорее нужен симбиоз диска и ОЗУ, то есть кэширование

А как он воспринимает одновременное чтение и запись в себя?

А сколько машин и сколько пишите?

К сожалению не так. Отказаться совсем от хранения на диске мы не можем. Скорее нужен симбиоз диска и ОЗУ, то есть кэширование

инфлюкс берите

А много логов? Нужно долго их хранить? Все поля нужны ?

Логов много, они сыпятся в реалтайме. Хранить надо месяц

Логов много, они сыпятся в реалтайме. Хранить надо месяц

ssd?

ssd?

Не одарили, и это боль(

Мы храним евенты пользователей, 5тб в кликхауз пихаем в месяц он их мило жмет

Не одарили, и это боль(

ну тогда ребят, не ваши проблемы

ну тогда ребят, не ваши проблемы

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

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

оптимизировать надо под разное железоп о своему

Мы храним евенты пользователей, 5тб в кликхауз пихаем в месяц он их мило жмет

Ого) Но нам надо иногда вытащить логи за 24 часа, при этом продолжая запись

Ого) Но нам надо иногда вытащить логи за 24 часа, при этом продолжая запись

Просто выгрузить подряд без сложных выборок?

Просто выгрузить подряд без сложных выборок?

Да, просто по timestamp интервал

Лучше самому руками померять. У нас пока пизда просели запросы со средней скорости работы 0.7 секунд до 5-6

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

Ого) Но нам надо иногда вытащить логи за 24 часа, при этом продолжая запись

ну так это iops и пропускная способность а не база

у вас мониторинг то вообще есть

на сколько диски загружены на монге

у вас мониторинг то вообще есть

Сегодня прикрутили)

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

Уходите с монги на эластик

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

В том же объеме, что и амбари?

даже лучше я бы сказал

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

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

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

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