Apache Airflow per pipeline dati B2B

Quando i DAG battono il cron per sync B2B

Usa un orchestratore a DAG quando i job hanno dipendenze, fan-out/fan-in, SLA diversi per step, o devono saltare il lavoro downstream quando i dati upstream sono vuoti o in ritardo. Casi B2B classici: ERP → staging → validazione → upsert OLTP → load warehouse; merge multi-source di customer master; extract di fine mese che non devono sovrapporsi; backfill che riproducono un range di date in sicurezza. Il cron resta adeguato per un singolo task idempotente senza dipendenti: invio digest email, refresh di una cache materializzata, ping di health check.

• Vittoria DAG: pipeline ERP/warehouse multi-step con ownership chiara
• Vittoria DAG: retry e alerting per task, non solo per riga di crontab
• Vittoria cron: un job, uno schedule, failure mode banale
• Né l'uno né l'altro: lavoro sul request-path che appartiene a una coda applicativa

In cosa Airflow è bravo (in pratica)

Airflow schedula e monitora DAG batch/workflow. Non è il runtime applicativo per i click utente, e non è un motore streaming. Trattalo come control plane per workflow di dati e integrazione. Punti di forza: dipendenze esplicite, retry con backoff, SLA/alert, backfill e una UI che gli operatori possono aprire durante un incident. Le offering managed (MWAA, Composer, Astro, ecc.) riducono il carico ops rispetto al self-host. Debolezze: peso operativo per team piccoli, sprawl di DAG Python, e la tentazione di mettere business logic dentro gli operator invece che in servizi applicativi versionati.

Pattern di pipeline ERP e warehouse

Separa extract, validate, load-to-app e load-to-warehouse. I fallimenti di validazione devono far fallire il DAG in modo rumoroso con artifact (conteggi righe, sample di reject), non caricare in silenzio verità parziali nelle tabelle customer-facing. Load idempotenti chiavati su ID naturali ERP proteggono i retry. Allinea a design di integrazione ERP e disciplina di cutover quando il backfill storico è in scope. Gli step warehouse spesso parlano dialetti diversi (Teradata, BigQuery, Snowflake, Redshift). Tieni l'SQL in file rivisti; vedi lavorare con warehouse enterprise per i confini di ownership tra product e data team.

Retry, idempotenza e dati poison

I retry senza idempotenza creano ordini duplicati, fatture duplicate o ticket duplicati. Ogni task che scrive deve definire la sua upsert key e il comportamento di fallimento parziale. Quarantena le righe poison: parcheggia i record cattivi, alert agli owner, continua o fallisci in base alle business rule. Il 'retry 5 volte' cieco su master data sbagliati ritarda solo l'incident. Usa correlation ID dal DAG run fino ai log applicativi così il support può rispondere a 'il sync di ieri notte per il tenant X è finito?'

• Documenta le upsert key per entità
• Dead-letter o tabelle di quarantena per i reject
• Limita run concorrenti che toccano lo stesso tenant
• Rendi i backfill un DAG first-class, non uno script SSH one-off

Ownership, on-call e change control

Airflow fallisce socialmente quando nessuno possiede la rottura del DAG dopo un cambio di schema. Assegna ownership product-engineering per i load app-facing e ownership data-platform per le transform warehouse quando esistono entrambe. Deploya i DAG come codice: PR review, CI parse/test, rollout staged. Un import rotto il lunedì mattina è un incident cliente, non un 'ticket del data team'. Collega gli alert a standard di observability: success/failure, durata, righe processate, lag vs sistema sorgente. Metti in dashboard lo SLA di business (dati freschi entro le 07:00 ora plant), non solo i quadratini verdi dei task.

Quando NON usare Airflow

Salta Airflow per API request/response, job interattivi per utente, o una manciata di cron semplici su cui un team piccolo può ragionare nel worker dell'app. Saltalo quando la tua 'pipeline' è davvero un flusso event-driven meglio servito da una coda e consumer (ordine piazzato → enrich → notify). Airflow può triggerare su sensor, ma piattaforme streaming/event fittono meglio i flussi continui. Salta Airflow self-hosted se ti manca capacità per metadata DB, executor e upgrade. L'orchestratore non deve diventare più fragile dei job che esegue. Per sync MVP early, un worker ben testato + schedule nello stack app può bastare—vedi prioritizzazione MVP e scelta dello stack.

Alternative da confrontare

Code e scheduler applicativi (Sidekiq, BullMQ, Celery beat, cloud scheduler + worker): ideali quando la logica vive già nel prodotto e gli step sono pochi. Orchestrator cloud-native (Step Functions, Cloud Workflows, Azure Logic/Durable Functions): buoni quando vuoi state machine managed e integrazione IAM cloud più stretta. Tool ELT-focused (dbt + scheduler, ingestion managed) brillano per transform analytics dopo i landing raw; non sostituiscono i writeback ERP nell'OLTP. Scegli in base a chi fa on-call e dove devono vivere le business rule—non sulla popolarità da conference.

Security, secret e tenancy

I worker di pipeline spesso tengono credenziali ERP e DWH. Usa secret manager, credenziali short-lived dove possibile, e least privilege per connessione—non un superuser per tutti i DAG. Il sync SaaS multi-tenant deve isolare i run per tenant o forzare tenant_id in ogni write. Un job 'globale' che dimentica il filtro è un incident di data-leak; allinea a architettura multi-tenant e audit logging. Logga cosa è corso, per quale tenant, con quale versione di codice. Auditor e buyer enterprise lo chiederanno.

Rischio di delivery e handoff contractor

I contractor possono shippare DAG impressionanti che solo loro capiscono. L'acceptance deve includere runbook, test di idempotenza, failure injection e ownership documentata—vedi assunzione contractor B2B. Metti a budget tempo ops in pianificazione costi: Airflow non è gratis dopo la prima demo verde. Includi sandbox ERP di staging in technical discovery.

Prossimi passi

Disegna il sync attuale come box e frecce. Se hai più di due step dipendenti o fallimenti parziali regolari, valuta un orchestratore a DAG. Se hai un solo box, indurisci prima cron/worker. Correlati: Postgres vs MongoDB, production readiness, altre risorse, case study, prenota una call o contatti.

Domande frequenti