В комментарии к прошлому посту был вопрос: __В ETL-процессе на стадии Transform имеем много DAG’ов с большой Python-логикой, основанной на Pandas, внутри от аналитиков данных. В итоге такой типичный DAG занимает 30–50 ГБ RAM в Airflow и может отрабатывать несколько часов. Как такие DAG’и с Python внутри переносить на dbt?__ Паттерн использования Airflow, чтобы выполнять Python (Pandas и т.п.), очень понятен и удобен, особенно если вы делаете пет-проекты, изучаете Airflow или Python. Возможно, это хороший вариант для небольшого MVP, но в продакшн лучше такое не тащить. У нас получается монолит, который трещит по швам, и из-за плохого запроса может всё упасть. То есть, первое, что нужно сделать - признать проблему и признать факт, что данное решение не оптимально. Уже не важно, кто и почему хочет его использовать. Вопрос в том, какие есть альтернативы и как смигрировать с номинальным downtime для конечных пользователей. На всякий случай для читателей - Airflow - это инструмент оркестрации. Он создан для того, чтобы запускать наши data pipelines (jobs) по расписанию. Это очень популярный инструмент в мире, и прям number one в РФ среди open-source инструментов. Его назначения - запускать задачи по расписанию. Из-за того, что DAGs (jobs) мы пишем на Python, так и хочется сразу всё сделать внутри одного job. Но лучше так не делать. Какие есть альтернативы? Конечно, среди них есть и dbt, но мы же не хотим на том же самом инстансе запускать dbt, где только что был Pandas. 1. Вместо Pandas можно попробовать PyArrow, Polars или DuckDB (pyduck) — просто ради интереса сравнить потребление памяти. Но в любом случае, мы не хотим запускать вычисления там же. 2. Вопрос про то, как мы хостим Airflow? Мы же можем использовать Managed Airflow в отечественном облаке, можем хостить на виртуальной машине, в контейнере или в поде (Kubernetes). 3. Например, если мы хотим дать возможность запускать Python/Pandas/DuckDB-скрипты, то нам всё равно нужно место, где это делать. Один из вариантов — использовать паттерн, в котором каждая программа (job/DAG) будет выполняться в своём контейнере. Например, мы запускаем DAG, а в нём task запускает Pod/Container с нашей логикой. Если не хватит памяти, то на Airflow это никак не повлияет. Точно так же и dbt. Самый главный вопрос — где будет compute, который будет запускать dbt? В случае контейнеров и подов, можно просто запустить Airflow DAG, который возьмёт образ с dbt из регистра и запустит его. А сама миграция с Pandas на dbt — это по сути миграция Pandas DataFrames на SQL. В dbt будет легче организовать модели (SQL-файлы), установить naming standards, добавить тесты и документацию. Появится lineage и зависимости. Я, конечно, могу ошибаться, но когда я слышу про Pandas в проде - это мне напоминает «куяк-куяк — и в продакшн, потом починим» А как у вас с custom Python, где вы его выполняете и что делаете, когда не хватает памяти?