VP
burzum
DBT?
На первый взгляд выглядит оверфичей для хранения ddl. Поизучаю, спс за наводку. Может поможет попутно другие задачки решить
да когда как
смотрю сейчас на кубфлоу очень удобно как разработчику использовать
Size: a a a
2021 March 04
S
Пока еще средненько... Но после того как их завезли в гуглОблако стало юзабельно
2021 March 05
ИК
Ну пока из того что видел к ейрфлоу много вопросов:
1. Узи позволяет работать с собой чисто по ресту, эйрфлоу для скедулинша приложения с пользовательской машины требует доступ в базу. Рест с год назад был в процессе. Давать доступ на запись в базу 100+ человекам как-то стрёмно, а держать вагон мелких эйрфлоу оверхед по менеджменту
2. Оози сам умеет в локализацию, эйрфлоу нет, ожидается что код на воркерах уже есть. Если для какого кубика это норм, то для хадупа это опа (я описывал как у нас в одном хадуп кластере вагон разных спарков живёт)
3. Скедулер у эйрфлоу в единственном экземпляре, то есть на большом количестве джобов и шагов становится узким местом, так как требует регулярного пересчёта всех шагов. У узи только spawn процесса базового, дальше он сам уже разбирает и запускает шаги по форкфлоу
Про скедулер можете почитать ещё тут, мы их систему пытаемся внедрять, так что общаемся периодически и про "большие" эйрфлоу наслышаны
https://medium.com/databand-ai/improving-performance-of-apache-airflow-scheduler-507f4cb6462a
1. Узи позволяет работать с собой чисто по ресту, эйрфлоу для скедулинша приложения с пользовательской машины требует доступ в базу. Рест с год назад был в процессе. Давать доступ на запись в базу 100+ человекам как-то стрёмно, а держать вагон мелких эйрфлоу оверхед по менеджменту
2. Оози сам умеет в локализацию, эйрфлоу нет, ожидается что код на воркерах уже есть. Если для какого кубика это норм, то для хадупа это опа (я описывал как у нас в одном хадуп кластере вагон разных спарков живёт)
3. Скедулер у эйрфлоу в единственном экземпляре, то есть на большом количестве джобов и шагов становится узким местом, так как требует регулярного пересчёта всех шагов. У узи только spawn процесса базового, дальше он сам уже разбирает и запускает шаги по форкфлоу
Про скедулер можете почитать ещё тут, мы их систему пытаемся внедрять, так что общаемся периодически и про "большие" эйрфлоу наслышаны
https://medium.com/databand-ai/improving-performance-of-apache-airflow-scheduler-507f4cb6462a
Хочу поинтересоваться, oozie может в процессе получать новые джобы и не создавать для них дополнительные инстансы приложений в YARN? Можно это решить через sub-workflow, fork-join или bundle (бандл вряд ли, но вдруг)? Или это как раз эирфлоу умеет?
Или все ваши 4 тыщи джобов запускают Oozie workflow, сколько же на это уходит памяти?
Или все ваши 4 тыщи джобов запускают Oozie workflow, сколько же на это уходит памяти?
P
Ну пока из того что видел к ейрфлоу много вопросов:
1. Узи позволяет работать с собой чисто по ресту, эйрфлоу для скедулинша приложения с пользовательской машины требует доступ в базу. Рест с год назад был в процессе. Давать доступ на запись в базу 100+ человекам как-то стрёмно, а держать вагон мелких эйрфлоу оверхед по менеджменту
2. Оози сам умеет в локализацию, эйрфлоу нет, ожидается что код на воркерах уже есть. Если для какого кубика это норм, то для хадупа это опа (я описывал как у нас в одном хадуп кластере вагон разных спарков живёт)
3. Скедулер у эйрфлоу в единственном экземпляре, то есть на большом количестве джобов и шагов становится узким местом, так как требует регулярного пересчёта всех шагов. У узи только spawn процесса базового, дальше он сам уже разбирает и запускает шаги по форкфлоу
Про скедулер можете почитать ещё тут, мы их систему пытаемся внедрять, так что общаемся периодически и про "большие" эйрфлоу наслышаны
https://medium.com/databand-ai/improving-performance-of-apache-airflow-scheduler-507f4cb6462a
1. Узи позволяет работать с собой чисто по ресту, эйрфлоу для скедулинша приложения с пользовательской машины требует доступ в базу. Рест с год назад был в процессе. Давать доступ на запись в базу 100+ человекам как-то стрёмно, а держать вагон мелких эйрфлоу оверхед по менеджменту
2. Оози сам умеет в локализацию, эйрфлоу нет, ожидается что код на воркерах уже есть. Если для какого кубика это норм, то для хадупа это опа (я описывал как у нас в одном хадуп кластере вагон разных спарков живёт)
3. Скедулер у эйрфлоу в единственном экземпляре, то есть на большом количестве джобов и шагов становится узким местом, так как требует регулярного пересчёта всех шагов. У узи только spawn процесса базового, дальше он сам уже разбирает и запускает шаги по форкфлоу
Про скедулер можете почитать ещё тут, мы их систему пытаемся внедрять, так что общаемся периодически и про "большие" эйрфлоу наслышаны
https://medium.com/databand-ai/improving-performance-of-apache-airflow-scheduler-507f4cb6462a
А узи умеет работать с зависимыми тасками? Например, есть три таски А В С, С зависит от первых двух, которые параллельно идут.
V
А узи умеет работать с зависимыми тасками? Например, есть три таски А В С, С зависит от первых двух, которые параллельно идут.
Да, это будет форк внутри одного вокфлоу
Таски А и В запускаются вместе
Таски А и В запускаются вместе
P
Vol
Да, это будет форк внутри одного вокфлоу
Таски А и В запускаются вместе
Таски А и В запускаются вместе
Ок. А если таска Б, например, находится совсем в другом workflow?
V
А и С в одном?
Не уверен как
Если А и С разные воркфлоу тогда можно, oozie координатор поддерживает входные зависимости
Не уверен как
Если А и С разные воркфлоу тогда можно, oozie координатор поддерживает входные зависимости
P
Vol
А и С в одном?
Не уверен как
Если А и С разные воркфлоу тогда можно, oozie координатор поддерживает входные зависимости
Не уверен как
Если А и С разные воркфлоу тогда можно, oozie координатор поддерживает входные зависимости
Ну, да. К примеру, добавляется еще один новый датасет, от которого зависит С
T
А узи умеет работать с зависимыми тасками? Например, есть три таски А В С, С зависит от первых двух, которые параллельно идут.
Можно через флаги зависимости реализовать например или один большой wf сделать
V
Можно зависить от нескольких датасетов
У нас через флаги делают
У нас через флаги делают
P
Vol
Можно зависить от нескольких датасетов
У нас через флаги делают
У нас через флаги делают
Ладно)) каждому свое))
P
Посмотрите просто на code frequency в гите 🤓
ПБ
Доброе утро коллеги! Скажите пожалуйста бест практис по масштабированию кластера сейчас есть 10 виртуалок по 10тб ,4рам, 2ядра для hdfs
Хочется в облаке поднять временные машинки и выделять спарк ресурсы ,потом гасить. Кто - то сталкивался?
Хочется в облаке поднять временные машинки и выделять спарк ресурсы ,потом гасить. Кто - то сталкивался?
A
А не проще в облаке сразу в их блоб сторейдж запихнуть? С таким то hdfs
A
Если же машинки локально, а кластер в облаке то вопрос за сколько вы данные прокачаете в облако
У меня есть подозрение что это будет самым узким местом
У меня есть подозрение что это будет самым узким местом
e
Народ, для hive on spark какое меньшее из зол - фильтры в where на 2000 строк или такой же *подарок* в виде case в select
CM
Ahh sure
R
Народ, для hive on spark какое меньшее из зол - фильтры в where на 2000 строк или такой же *подарок* в виде case в select
hive on spark - это вообще не очень хороший путь. Почему решили его выбрать, а не hive on tez?
e
Меня не спрашивали 😔
R
Народ, для hive on spark какое меньшее из зол - фильтры в where на 2000 строк или такой же *подарок* в виде case в select
И не совсем понятен вопрос, если честно)