Серриализацию xcom сейчас имеет смысл использовать только как временное решение:

Retrieve an XCom value, optionally meeting certain criteria.
        TODO: "pickling" has been deprecated and JSON is preferred.
        "pickling" will be removed in Airflow 2.0.

Версию 2.0 обещают уже года три как минимум и неизвестно, когда она появится, но если в какой-то момент всё-таки уберут pickle из xcom, всё развалится.
https://airflow.apache.org/docs/stable/_modules/airflow/models/xcom.html

Нет, сессии между операторами лучше не прокидывать, имхо.

Делайте свой оператор, где внутри все действия в одной сессии.

Retrieve an XCom value, optionally meeting certain criteria.
        TODO: "pickling" has been deprecated and JSON is preferred.
        "pickling" will be removed in Airflow 2.0.

да, про это тоже почитал
но если будет работать, по-факту кишки пикла можно самостоятельно в json отправить?

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

ну например надо чтоб в рамках операции посчитались параллельнно t1 и t2, а их ждало t3 и запустилось как только они готовы будут?

вы не можете запускать t1 и t2 параллельно в одной сессии.

Если же это и не нужно то, самый простой способ: https://docs.python.org/3/library/multiprocessing.html
Заупскаете t1, t2. Ждете завершения. Запускаете t3

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

а если мне это не нужно, то мне и темповые таблицы не нужны тогда)

спасибо, пойду дальше думать тогда как организовать таблицы

в догонку еще вопрос про настройки шедулера
есть ли какие-то бест практисы настроек части конфинга [scheduler]?

в статейке https://eng.lyft.com/running-apache-airflow-at-lyft-6e53bb8fccff
господин пишет что :
scheduler_heartbeat_sec: User should consider increasing scheduler_heartbeat_sec config to a higher value (e.g. 60 secs) which controls how frequently the Airflow scheduler gets the heartbeat and updates the job’s entry in the Airflow metastore.

я так понял что этот параметр должен реже реагировать на запуск таски, типо когда в даге подошла очередь следующей таски, то она запускается только по наступлению heartbeat, но раз ничего не изменилось, то это что-то другое означает)

и очень смущает вот эта штука : processor_poll_interval = 1
это он раз в секунду файл парсит чтоли? частенько как-то

Я ставлю такие параметры на тестовые инстансы:

job_heartbeat_sec = 20
scheduler_heartbeat_sec = 60
max_threads = 2

судя по графику cpu это помогает (скачки реже)

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

top level код вроде максимально простой, только парсинг конфига
спасибо, попробую

Добрый день! Два раза пытаюсь отправить сообщение в чат, но безуспешно. Тут есть какие то особые ограничения?

У меня вопрос по задачам решаемым в один шаг, для них ведь не рекоммендуется использовать airflow?

Могу ли обойтись стандартными средствами RQ+ Redis?

Для новых пользователей есть,чтобы спама не было в группе

Понял, извиняюсь, видимо проблема была в большом тексте и ссылке на Мигеля Гринберга ( Flask + RQ и Redis для вызываемого процесса).
В этом и был вопрос: если задача в один шаг, airflow - не трогать? Даже если он будет в проекте?

У меня есть процессы в один шаг
Вопрос для чего тебе airflow ?
Только для одной задачи ?

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

Извините, не сдержался