Ребята, привет!👋🏼 Меня зовут Дарина, я из Wrike. Влезу к вам с небольшой рекламой, т.к. мы активно юзаем airflow в DE, возможно, инфа будет для кого-то актуальна!

Мы ищем крутого дата-инженера к нам в команду. У нас 3 направления, можно делать всякие разные вещи:
·      В команде BI – писать сервисы/пайплайны для прокачки данных через основные бизнес-интеграции.
·     Marketing Data Engineering занимаются разработкой платформы для интеграции с разными сервисами (отличная возможность «потрогать» стриминг) и созданием базы мета-данных.
·      Выстраивание процессов работы с данными с командами разработки, работа со сложными системами мониторинга и алертинга – это главные челленджи нашего Product Data Engineering'a.

Позиция уровня мидл+/сеньор, вилка 150-250к, локация в Петербурге (помогаем комфортно релоцироваться и все делаем по красоте, пока что работаем из дома до конца года).
Все инфо я подробно расписала в телеграфе, смогу скинуть ссылку всем заинтересовавшимся – остальными подробностями решила не засорять эфир. Спасибо!🙃

Использовать airflow operator, который в альфе и с декабря без коммитов чёт такая себе история.
Даже если у тебя кубы есть.
Да и если инстанс для сотен-тысяч задач, это какой размером под под шедулер просить надо.
Девопсы там пальцем у виска покрутят.

а для чего использовать AirflowOperator?

Чтобы документацию не читать и манифесты не писать.

да ну... на гитхабе и так  куча примеров деплоймента Airflow под k8s, можно и без AirflowOperator обойтись

раз он в альфе

и слабо развивается

вообще ни разу не видел проблем в airflow с celery. Redis там вообще один из наименее нагруженных сервисов. Там таски в очередь ставит шедулер и он будет узким местом, но от оператора это вообще не зависит.

Единственное, что нужно - это либо делать DAG pickle, либо на всех нодах держать актуальную версию дагов.

ну вот стримы в airflow я бы не рекомендовал…

в самом Airflow - согласен. Но в поде созданном Airflow почему нет? - На Go написать микросервис для чтения из кафки, например, и запускать его из Airflow через KubernetesPodOperator с различными параметрами

но зачем так сложно, если есть kafka connect?

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

запускать и останавливать стримы?

по какому принципу?

- запускать по принципу ensure sarted (если не запущен, то запускаем, иначе ничего не делаем)
- останавливать при выключении дага

тут есть проблема, что если в airflow что-то пошло не так, его можно без проблем рестартануть, а все батчёвые джобы просто перезапустятся. А вот со стримами, чтобы не было проблем, надо перед рестартами вручную (или через апи) их остановить, а потом рестартовать airflow.
Плюс это занимает воркер, хартбиты там всякие. Ну это первое, что вспомнилось.

хм, а разве KubernetesPodOperator не поднимает под на время задачи, а потом убивает?

есть параметр is_delete_operator_pod для управления этим поведением