Airflow vs NiFi¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.
Критерии выбора¶
| Критерий | Airflow3.1 | NiFi2.5 |
|---|---|---|
| Workload / architecture | Orchestration bounded interval jobs/dependencies | Continuous flow ingestion/routing/provenance |
| Consistency / transaction boundary | Task retries не atomic whole pipeline | ProcessSession local boundary не external sink transaction |
| Latency path | Scheduling/queue/execution delay, не streaming latency | Processor/queue/backpressure path |
| Throughput / scalability | Executor/pools/mapping/scheduler DB | Nodes/processors/concurrency/repositories |
| Operational complexity / cost | Metadata DB/executor/logs/DAG code | Repository disks/provenance/flow config/processors |
flowchart TB
Airflow[Interval DAG scheduler] --> Bounded[Bounded extract compute checks]
Provider --> NiFi[Continuous FlowFile routing]
NiFi --> Outputs[Validated data outputs]
Outputs --> Bounded
Bounded --> Publish[Generation publication]Конкретные сценарии¶
Daily financial closing/backfill с checks → Airflow orchestrates extraction/Spark/dbt. Multi-protocol provider files/events routing → NiFi. Airflow может запускать bounded checks над outputs NiFi, если generation/cutoff согласованы.
Ограничения и восстановление¶
Airflow не stream engine, NiFi не автоматически event-time processing/scheduler эквивалент. Не сравнивать их по общей рекламной throughput цифре; сравнивать разные роли и operational ownership.
Как проверить выбор¶
Зафиксировать 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.