Orchestrare l’esecuzione delle pipeline in modo affidabile è centrale nel data engineering su Azure. In Azure Data Factory (e nelle pipeline di Azure Synapse Analytics) un trigger è l’oggetto che decide quando una pipeline parte. Scegliere il tipo di trigger corretto e implementare un caricamento incrementale robusto sono competenze che l’esame verifica costantemente.

I tre tipi di trigger

Schedule trigger

Lo schedule trigger avvia una o più pipeline in base a un calendario ricorrente (ogni ora, ogni giorno alle 02:00, il primo del mese). È una relazione molti-a-molti: un trigger può lanciare più pipeline e una pipeline può avere più trigger. Il tempo di attivazione (trigger().scheduledTime) è passato alla pipeline come parametro, ma lo schedule non conserva lo stato delle finestre passate: se un’esecuzione salta, non viene recuperata automaticamente. È la scelta giusta quando l’orario di partenza conta più della finestra temporale dei dati processati.

Tumbling window trigger

Il tumbling window trigger genera una serie di finestre temporali contigue, non sovrapposte e di dimensione fissa. Ogni finestra espone WindowStart e WindowEnd, ideali per filtrare i dati di quel preciso intervallo. Caratteristiche chiave che l’esame ama:

  • Stato e affidabilità: ogni finestra ha uno stato proprio (Waiting, Running, Succeeded, Failed) con retry configurabili.
  • Backfill storico: impostando una startTime nel passato, ADF crea ed esegue automaticamente tutte le finestre pregresse: perfetto per ricaricare mesi di dati storici.
  • Dipendenze: si può dichiarare una dependsOn su un altro tumbling window (anche la stessa pipeline, per la self-dependency), così una finestra parte solo quando quelle da cui dipende sono completate. Abilita pipeline a catena e ordinamento sequenziale.
  • Concurrency: limita quante finestre girano in parallelo.

È una relazione uno-a-uno con la pipeline (un trigger → una pipeline).

Storage event trigger

Lo storage event trigger reagisce a eventi su Azure Blob Storage o ADLS Gen2 (tipicamente Blob created o Blob deleted), sfruttando Azure Event Grid. Si filtra per blobPathBeginsWith e blobPathEndsWith (es. cartella /landing/ ed estensione .parquet). È il pattern event-driven per ingestion “al momento dell’arrivo del file”, con @triggerBody().folderPath e fileName disponibili come parametri. Richiede la registrazione del provider Microsoft.EventGrid nella subscription.

Il pattern incrementale con high-watermark

Ricaricare ogni volta l’intera sorgente (full load) è semplice ma costoso e non scala. Il caricamento incrementale processa solo i dati nuovi o modificati dall’ultima esecuzione, usando una high-watermark column (una colonna monotona crescente come LastModifiedDate o un ID incrementale).

Il flusso tipico usa due Lookup activity:

  1. La prima legge il watermark corrente della sorgente (es. MAX(LastModified)).
  2. La seconda legge l’ultimo watermark salvato in una tabella di controllo.

La Copy activity filtra poi con una query parametrica:

SELECT * FROM Sales
WHERE LastModified > '@{activity('OldWatermark').output.firstRow.value}'
  AND LastModified <= '@{activity('NewWatermark').output.firstRow.value}'

Al termine, una Stored Procedure activity aggiorna il watermark salvato. Il confronto tra le tre strategie:

  • Full load: semplice, nessuno stato, ma pesante e non adatto a volumi grandi.
  • Incremental (high-watermark): efficiente, ma richiede una colonna affidabile e non cattura i delete né lo storico delle modifiche intermedie.
  • CDC (Change Data Capture): cattura insert/update/delete a livello di log del database. Su SQL Server/Azure SQL si usa la CDC nativa o change tracking; ADF offre anche il pattern native CDC / SQL CDC e la nuova risorsa CDC top-level per un flusso continuo. È la scelta corretta quando servono le cancellazioni o l’ordine delle modifiche.

Trappole tipiche d’esame

  • Serve ricaricare dati storici o rieseguire una singola finestra passata? → tumbling window trigger (backfill automatico e rerun per finestra con stato); lo schedule trigger non conosce le finestre passate e non le recupera.
  • Devi orchestrare pipeline in sequenza, dove B parte solo dopo A per lo stesso intervallo? → tumbling window con dependency (dependsOn/self-dependency), non trigger schedule indipendenti.
  • Il caricamento deve partire appena un file arriva nel container? → storage event trigger (Blob created via Event Grid), non uno schedule “ogni 5 minuti”.
  • Requisito: catturare anche i record cancellati / la storia delle modifiche → CDC, non high-watermark (che vede solo l’ultimo stato ed è cieco ai delete).
  • Il trigger schedule “many-to-many” vs tumbling “one-to-one”: se lo scenario richiede un trigger che avvii più pipeline diverse, è schedule; il tumbling window è legato a una sola pipeline.