K
Size: a a a
2020 March 24
DZ
Кривда вылезает из хадупа
2020 March 25
PR
А подскажите, вот есть кластер cloudera хадуп, и при определённом количество джобов в узях, они начинают дико медленно работать, растёт очередь и всё такое. В какую сторону стоит копать? Не получается найти нигде инфу как определять "потолок" производительности узей.
R
Я б не стал сейчас в хадуп лезть
Все зависит от контекста. В России и около странах минио + кубер + спарк. И не думаю, что в ближайшую пару лет сильно изменится ситуация.
Свое мнение я строю на основе спроса на рынке труда и информации об устройстве стека Bigdata во многих крупных компаниях Москвы.
Свое мнение я строю на основе спроса на рынке труда и информации об устройстве стека Bigdata во многих крупных компаниях Москвы.
R
А подскажите, вот есть кластер cloudera хадуп, и при определённом количество джобов в узях, они начинают дико медленно работать, растёт очередь и всё такое. В какую сторону стоит копать? Не получается найти нигде инфу как определять "потолок" производительности узей.
Как бы очередей в oozie нет, скорее всего упираетесь в ресурсы кластера.
Ещё бывает кейс, когда одновременно стартует очень много oozie тасков, и количество ресурсов , которое занимают application Masterа этих тасков, отъедает много ресурсов кластера, что может приводить к некоторой деградации. Но такое может быть, когда у вас не очень большой кластер, а на am выделено много ресурсов.
Ещё бывает кейс, когда одновременно стартует очень много oozie тасков, и количество ресурсов , которое занимают application Masterа этих тасков, отъедает много ресурсов кластера, что может приводить к некоторой деградации. Но такое может быть, когда у вас не очень большой кластер, а на am выделено много ресурсов.
PR
Как бы очередей в oozie нет, скорее всего упираетесь в ресурсы кластера.
Ещё бывает кейс, когда одновременно стартует очень много oozie тасков, и количество ресурсов , которое занимают application Masterа этих тасков, отъедает много ресурсов кластера, что может приводить к некоторой деградации. Но такое может быть, когда у вас не очень большой кластер, а на am выделено много ресурсов.
Ещё бывает кейс, когда одновременно стартует очень много oozie тасков, и количество ресурсов , которое занимают application Masterа этих тасков, отъедает много ресурсов кластера, что может приводить к некоторой деградации. Но такое может быть, когда у вас не очень большой кластер, а на am выделено много ресурсов.
Растёт параметр callable queue size. В очереди в ярне ресурсов сильно больше, чем потребляют запускаемые джобы. И пока callable queue size не уходит ниже ~3000, даже тестовая джоба, запущенная в очереди, где есть ресурсы, может висеть минут 5-10.
R
Растёт параметр callable queue size. В очереди в ярне ресурсов сильно больше, чем потребляют запускаемые джобы. И пока callable queue size не уходит ниже ~3000, даже тестовая джоба, запущенная в очереди, где есть ресурсы, может висеть минут 5-10.
Типа в статусе prepare висят таски?
Если так, то можешь попробовать потюнить oozie.service.callablequeueservice.queue.size
oozie.service.callablequeueservice.threads
У меня была недавно такая проблема, в итоге я списал все на то, что у меня oozie не привязан к внешней базе данных.
Если так, то можешь попробовать потюнить oozie.service.callablequeueservice.queue.size
oozie.service.callablequeueservice.threads
У меня была недавно такая проблема, в итоге я списал все на то, что у меня oozie не привязан к внешней базе данных.
АБ
Я возможно оффтоп.
Пытаюсь сообразить каунтеры.
Юзеры делают какие то действия. Потом нужно апи которое будет всегда возвращать реальные данные счётчиков действий.
Сам факт события я бы не хранил. Первое что пришло в голову это mysql какой то и табличка со счётчиками. Один счётчик на событие и юзера. Инсерт ор апдейт.
Но мне кажется есть и другой вариант. Редису не доверяю. Хотя с ним все было бы проще.
Пытаюсь сообразить каунтеры.
Юзеры делают какие то действия. Потом нужно апи которое будет всегда возвращать реальные данные счётчиков действий.
Сам факт события я бы не хранил. Первое что пришло в голову это mysql какой то и табличка со счётчиками. Один счётчик на событие и юзера. Инсерт ор апдейт.
Но мне кажется есть и другой вариант. Редису не доверяю. Хотя с ним все было бы проще.
DM
Добрый день, никто не сталкивался с тем, как в apache beam sql делать что-то типа explode/unnest. Я как понимаю сам по себе unnest beam sql не поддерживает в диалекте Calcite. Неужели никак array нельзя на уровне sql разбить?
AZ
Добрый день, никто не сталкивался с тем, как в apache beam sql делать что-то типа explode/unnest. Я как понимаю сам по себе unnest beam sql не поддерживает в диалекте Calcite. Неужели никак array нельзя на уровне sql разбить?
через UDF попробуйте сделать https://beam.apache.org/documentation/dsls/sql/extensions/user-defined-functions/
AZ
Я возможно оффтоп.
Пытаюсь сообразить каунтеры.
Юзеры делают какие то действия. Потом нужно апи которое будет всегда возвращать реальные данные счётчиков действий.
Сам факт события я бы не хранил. Первое что пришло в голову это mysql какой то и табличка со счётчиками. Один счётчик на событие и юзера. Инсерт ор апдейт.
Но мне кажется есть и другой вариант. Редису не доверяю. Хотя с ним все было бы проще.
Пытаюсь сообразить каунтеры.
Юзеры делают какие то действия. Потом нужно апи которое будет всегда возвращать реальные данные счётчиков действий.
Сам факт события я бы не хранил. Первое что пришло в голову это mysql какой то и табличка со счётчиками. Один счётчик на событие и юзера. Инсерт ор апдейт.
Но мне кажется есть и другой вариант. Редису не доверяю. Хотя с ним все было бы проще.
да можно на любом движке сделать, если у вас много писателей то будет нужен атомарный инкремент счетчика (есть во многих СУБД)
АБ
да можно на любом движке сделать, если у вас много писателей то будет нужен атомарный инкремент счетчика (есть во многих СУБД)
Что то типа tsdb не подойдёт же?
DM
@dartov спасибо, я этот вариант тоже рассматриваю если подтвердится что действительно никак нельзя разбить)
AZ
Что то типа tsdb не подойдёт же?
все зависит от числа пользователей и нагрузки, для маленького числа пользователей наверное можно сделать и во временных рядах (каждый пользователь это отдельная метрика)
АБ
все зависит от числа пользователей и нагрузки, для маленького числа пользователей наверное можно сделать и во временных рядах (каждый пользователь это отдельная метрика)
Около 5млн
AZ
это такой простой кусочек логики что я бы сделал на том что есть сейчас и для текущих показателей нагрузки, это всегда можно переделать
АБ
это такой простой кусочек логики что я бы сделал на том что есть сейчас и для текущих показателей нагрузки, это всегда можно переделать
Вот я тоже думаю что городить дополнительный стек ради пары счётчиков не очень эффективно
DM
@dartov Unnest это же UDTF, а я не уверен кстати что apache beam поддерживает UDTF
AZ
@dartov Unnest это же UDTF, а я не уверен кстати что apache beam поддерживает UDTF
не поддерживает, только агрегаты и скаляры
DM
@dartov выходит так, что unnest/explode невозможно сделать в beam sql?