Airflow vs dbt¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.
Критерии выбора¶
| Критерий | Airflow3.1 | dbtCore1.10 |
|---|---|---|
| Workload / architecture | Workflow dependencies across systems/jobs | SQL transformation DAG/models/tests/adapter |
| Consistency / transaction boundary | Task-level status/retry; effects external | Adapter/materialization transaction scope; whole model DAG не ACID |
| Latency path | Scheduler/task/query orchestration delay | Target query planning/execution/selection cost |
| Throughput / scalability | Executor/pools/concurrency/metadata DB | Threads + target DB/warehouse capacity |
| Operational complexity / cost | Runtime platform, metadata/logs/operators | Artifacts, SQL testing, adapter/target costs |
flowchart TB
Airflow[Cross-system orchestration] --> Extract[Source extraction]
Extract --> Data[Fixed input cut]
Airflow --> Dbt[dbt model DAG and tests]
Data --> Dbt
Dbt --> Models[Adapter-specific models]
Models --> Publish[Airflow publication dependency]Конкретные сценарии¶
Airflow extracts fixed interval, triggers dbt build and publishes validated report generation. dbt manages model lineage/incremental SQL/tests. Для одного SQL project внешнее scheduling может быть проще, но Core не становится ingestion runtime.
Ограничения и восстановление¶
Не универсальные конкуренты: model ref DAG и cross-system orchestration DAG описывают разные уровни. Neither successful run nor unique_key alone proves financial completeness.
Как проверить выбор¶
Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.
Типичные ошибки проектирования¶
Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.
Вопросы на собеседовании¶
Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.
Практические упражнения¶
Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.