»Да, это Python, тут можно делать что угодно

Звучит классно

Но ведь так незаконно писать?)

почему незаконно?)

Airflow это не ETL инструмент, это инструмент по запуску задач плюс умеет хранить какие-то метаданные. Просто все операторы которые есть в стандартной поставке икапсулируют возможные варианты как можно было бы реалзиовать ту или иную задачу на Python, и не обязательно эффективно

schedule_interval - если его менять динамически, то airflow плохо будет. Это же шедулер и он вычисляет план запусков и хранит это в базе. Если известно как частно надо запускать лучше сразу задать и при необходимости руками запускать или просто перезапускать последний

Я хотела переопределять только схемы и таблицы)

Ну, то есть это по сути универсальный даг, если в него подставить нужные параметры, потому что все выглядит как:
Удали это
Добавь это
Теперь переложи это

И вот эти "это" хочется переопределять

Например, подкладывать ссылки на разные фалы с параметрами

Так обычно файлы схемы и прочее переопределяется на уровне тасков. А так да, никто не мешает создать фабрику дагов, что бы перед генерацией объекта DAG он сверялся с файлом каким-нибудь

Господи, зачем такие сложности. Это же в рамках одного скрипта , ресурсы же общие , неужели передать нельзя дальше без всяких икскомов, дополнительных баз и тд. Все равно же в памяти находится . Это получается , что вы считали файл , записали его в бд, что-то с ним нужно сделать - вы читаете/записываете . Это же сколько лишних операций . Как же так аирфлоу проектировали. Вообще , что у человека должно быть в голове, что решить о достаточности передачи только  мелких данных между операторами .

Это же не дата пайплайны, наверное, где надо передавать артефакты между тасками

Мне вот больше интересно: если создаю класс, там одна из переменных класса - датафрейм. А в нескольких пайтон операторах обращаюсь к методам класса, которые его модифицируют . Так вот, после выполнения этих операторов тот датафрейм не изменяется . Как будто постоянно копию передают.

xcom передается через метабазу (pg, например). Представим случай, что у тебя есть ежедневный даг, в котором 100 тасок, которые выкачивают данные из многих источников, например, за день и обрабатывают их. 53-я таска у тебя падает. Какие твои действия? запускать все заного?

Я не хочу вообще завязываться на икском, тем более на бэкэнд. Ещё раз - в самом начале файла .py , до объявления with Dag (..) as dag  создаю объект класса.  Obj = etl(). В init этого класса есть self.dataframe , который изначально пустой. В первый питон оператор передаю метод класса obj.readfile , в котором после успешного чтения присваивается self.dataframe = data. Дальше, уже во втором операторе , мне было хотелось провести какие-то манипуляции с этими данными , они же уже считаны и находятся в переменоой . Во втором операторе вызываю obj.do_something. но в нем self.dataframe так и остался None. Последовательность op1 >> op2. У меня изначально условия, что все выполняется последовательно и  одним вокером. Зачем мне в такой архитектуре вообще использовать xcom?

Мне не принципиально упадет или нет - начну сначало проблем нет.

Airflow выполняет instance Операторов заранее. А уже вызывает метод execute - scheduler. Т.е. на момент init - self.dataframe - None. А выполнение каждого execute происходит независимо друг от друга.

Ну вот что я и увидел на практике , но казалось, что все -таки где-то у меня ошибка.

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

если этот функционал не нужен, зачем вообще airflow? напишите скрипт на питоне и выполняйте через cron

Если у тебя все выполняется на одной машине - можешь теоретически передать ссылку на блок памяти и ходить по ней.

прошу прощения за "ты" - привычка на работе =(