Molti tutorial di data engineering si fermano alla logica ETL: chiami una API, trasformi i dati, li salvi. Ibrahim Salami, su Towards Data Science, racconta il suo secondo progetto (una pipeline di ingestion da un feed RSS con Python, Docker, PostgreSQL e Kestra) partendo da un’osservazione: scrivere la logica ETL è la parte facile. Le domande difficili arrivano quando lo script deve girare da solo, ripetutamente, senza qualcuno che guarda. Come schedularlo? Cosa succede se fallisce a metà? Dove vive la retry logic? Come lo impacchetti perché giri ovunque allo stesso modo?
È un pezzo utile per chi sta passando da analista a data engineer, perché il valore non è il dataset ma il modo di pensare: la scelta di un feed RSS è deliberata proprio perché l’estrazione occupa poche righe, lasciando spazio all’architettura.
Costruire a strati, validando ognuno
La lezione centrale è procedere per layer, validando ciascuno prima di introdurre il successivo: prima l’ETL in Python (fetch del feed, parsing in oggetti Article, salvataggio su PostgreSQL), poi la persistenza resa idempotente con ON CONFLICT DO NOTHING così che eseguire la pipeline più volte non crei duplicati, poi Docker e solo infine Kestra. Con questo ordine, quando arriva l’orchestratore non si sta debuggando Python, Docker, PostgreSQL e orchestrazione insieme, ma un problema alla volta.
Il cambio di prospettiva più importante riguarda Docker: da semplice modo di impacchettare l’applicazione a unità di esecuzione. Invece di chiedere a Kestra di capire il progetto Python, gli si chiede di lanciare un container che sa già eseguire la pipeline. Il container, validato in autonomia, diventa il deployment artifact di cui fidarsi.
Esecuzione contro orchestrazione
L’assunzione sbagliata di partenza era che Kestra avrebbe eseguito lo script Python come dalla riga di comando. Ma Kestra è un orchestratore: non costruisce ambienti Python né gestisce dipendenze, decide quando e come i workload girano. Da qui l’architettura pulita: l’ETL è l’applicazione self-contained, Docker il deployment artifact, Kestra l’orchestratore, ognuno con una responsabilità chiara.
Una volta automatizzata (uno schedule orario via cron), tutto cambia: la rete di sicurezza di stare davanti allo schermo sparisce. La resilienza si sposta nell’orchestratore: retry configurati in Kestra (per esempio 3 tentativi a intervalli di 30 secondi) mentre l’applicazione Python resta focalizzata sul suo unico compito. L’idempotenza a livello database protegge dai duplicati, e log che raccontano l’esecuzione invece di riversare oggetti grezzi migliorano l’osservabilità.
In sintesi
- La difficoltà dell’engineering inizia dopo che lo script funziona: schedulazione, recovery dai fallimenti, no duplicati, log leggibili.
- Dare a ogni layer una sola responsabilità (Python la business logic, Kestra il quando/dove/come, Docker l’ambiente, PostgreSQL la persistenza) rende il sistema più semplice, non più complesso.
- Costruire in modo incrementale, validando ogni pezzo prima di aggiungere il successivo, riduce gli sconosciuti a ogni passo.
Fonte: I Built My Second ETL Pipeline. This Time, I Started Thinking Like a Data Engineer — https://towardsdatascience.com/i-built-my-second-etl-pipeline-this-time-i-started-thinking-like-a-data-engineer/
Hai qualcosa da aggiungere? Unisciti alla discussione.