Ох, тогда докер оператор и запускать докер контейнеры только

ммм, мб ещё с venv можно придумать

в теории обработку лучше делать на системе источнике. а даги airflow будут вызывать скрипты в этой системе.

вот таким можно пускать

там как раз есть

requirements=["colorama==0.4.0"],

Не всегда, если источник это АБС банка, как у меня, то это делать запрещено

ясно, спасибо)

Да, видимо самое логичное использовать ресурсы существующего сервера хаба и максимум возможный в sql выносить все таки. Спасибо. Хочу чтобы наши расчёты на стабильных данных строились, сейчас все логи и регулярные расчёты и рассылки стоят на кронах. На полученных данных строим уже прогнозы спроса и тд. Решили перевезти на airflow, но опыта нет и не совсем понятно та ли это технология и как организовать для максимальной стабильности данных лучше

Если честно не было попыток максимального выноса логики в sql. И тут мне уже надо уточнять у команды. Могу сказать только, что часто сбор для расчёта идёт и из клика и из мускула , и складывается в другой клик. Для реализации в бд как я поняла ,получается нужно практически полностью эти базы реплицировать в нашу, а их «хозяева» против реплицирования именно

Тогда, вам ещё бы добавить дата кволити. Например, great expectations, который нормально дружит с airflow ( у нас так)

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

Чекну, спасибо, а у вас вычисления в airflow происходят ?

У нас расчеты проходят в  k8s екзекюторах,  спарк кластере, скоро будет ещё кластере престо и внутри БД.
Мы не очень простой пример, потому что это часть дата платформы холдинга приличного размера.

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

А, понятно)

Всем привет. Может кто подскажет как реализовать выполнение динамически сформированного sql кода в python operator , чтобы результат герерации отображался в разделе Rendered Template, но при этом процесс генерации выполнялся только при работе таска,  а не при каждом вызове шедулера.
Сейчас динамический код генерируется процедурой, и ее результат передается джинжой в основной шаблон PostgresOperator,  и в итоге каждый раз шедулер дергает процедуру при опросе директории с дагами, так как даги и таски перестраиваются динамически.
Возможно кто-то сталкивался.

Прятать весь sql код в PythonOperator не хочется, та как в итоге сгенерированный  шаблон sql кода не доступен для быстрого просмотра в Rendered Template

Господа, как быть если даг не видит папку plugins и не хочет выполнить импорт модуля?

Как один из вариантов добавить ссылку на plugins в папку к дагам)