CineData ETL Azure

Cos'è il progetto

CineData ETL Azure è una pipeline ETL parametrica su Azure Data Factory per trasformare un catalogo cinematografico grezzo in un dataset Parquet filtrato, arricchito e pronto per analisi. Il progetto mostra ingestion su Blob Storage, preprocessing Pandas e Mapping Data Flow con parametri configurabili.

Contesto tecnico

Un catalogo cinematografico con 9.125 film era disponibile come file CSV, ma il formato grezzo non era ancora adatto a un utilizzo analitico ripetibile. Le colonne dovevano essere controllate, i tipi uniformati e i record filtrati secondo criteri modificabili senza riscrivere ogni volta la logica di trasformazione.

Il problema non consisteva soltanto nel selezionare i film con valutazioni più alte. Era necessario separare la pulizia iniziale dal flusso cloud, conservare un formato intermedio efficiente e produrre un output tracciabile con informazioni sull'esecuzione.

Obiettivo

L'obiettivo era costruire una pipeline ETL dimostrativa su Azure capace di accompagnare il dataset dal file sorgente a un output pronto per analisi:

• esplorare e ripulire il CSV con Python e Pandas;
• convertire il risultato intermedio in Parquet;
• separare input e output in container Azure Blob Storage dedicati;
• rendere configurabili soglia di rating e intervallo temporale;
• aggiungere metadati utili alla tracciabilità;
• produrre un dataset finale compatto e coerente.

La pipeline trasforma così un'operazione manuale di filtro in un processo cloud dichiarativo, riproducibile e adattabile a criteri diversi.

Architettura

Il flusso è organizzato in cinque passaggi:

1. moviesDB.csv rappresenta il catalogo sorgente con titolo, genere, anno e valutazione;
2. il notebook Analisi_Film.ipynb esegue analisi esplorativa, pulizia e conversione in MoviesDB2_clean.parquet;
3. il file pulito viene caricato nel container input di Azure Blob Storage;
4. la pipeline CineData-ETL esegue il Mapping Data Flow movies_etl_df;
5. il risultato viene scritto nel container output come MoviesDB2_processed.parquet.

Il notebook gestisce la preparazione iniziale del dato, mentre Azure Data Factory concentra la logica riutilizzabile di filtro, arricchimento e pubblicazione dell'output.

Dataset e preprocessing

Il dataset iniziale contiene cinque campi principali: identificativo del film, titolo, generi, anno di uscita e rating. Pandas viene usato per ispezionare la struttura, mantenere le colonne necessarie e produrre un file Parquet con schema coerente.

Questa separazione evita di affidare al Data Flow operazioni esplorative tipiche di un notebook. Azure riceve invece un input già strutturato sul quale applicare trasformazioni configurabili e ripetibili.

Mapping Data Flow parametrico

Il Data Flow espone tre parametri:

• rating_threshold, con valore predefinito 7;
• year_min, con valore predefinito 1890;
• year_max, con valore predefinito 2024.

La trasformazione conserva i record con rating superiore alla soglia e anno compreso nell'intervallo. I valori possono essere modificati al momento dell'esecuzione, evitando di cambiare la definizione della pipeline per ogni nuova selezione.

Trasformazioni e tracciabilità

Dopo il filtro, il flusso aggiunge quattro elementi di contesto:

• processing_timestamp per indicare il momento di elaborazione;
• pipeline_name per identificare il processo;
• source_file per conservare la provenienza del dato;
• data_version per associare una versione temporale all'output.

La selezione finale rinomina inoltre Title, genres e Rating in film, genere e valutazione. L'output presenta quindi uno schema più vicino al consumo finale e include i metadati necessari per ricostruire l'esecuzione.

Scelte tecniche

Perché separare Pandas e Azure Data Factory?

Pandas è adatto alla fase esplorativa e alla pulizia iniziale, mentre Azure Data Factory rende il filtro operativo parametrico e ripetibile. La separazione mantiene il notebook leggibile e impedisce che la pipeline cloud dipenda da passaggi manuali dopo il caricamento.

Perché usare Parquet?

Parquet conserva lo schema, supporta letture colonnari e riduce lo spazio rispetto a un CSV equivalente. Il sink utilizza inoltre compressione Snappy, adatta a bilanciare dimensione e velocità di elaborazione.

Perché due container Blob?

I container input e output rendono esplicito lo stato del dato prima e dopo la trasformazione. Questa distinzione riduce il rischio di sovrascrivere la sorgente e rende più semplice controllare gli artefatti prodotti.

Risultati

• 9.125 film nel catalogo iniziale;
• 2.726 film nell'output con rating 8-10 e anni compresi tra 1890 e 2024;
• 3 parametri permettono di riutilizzare il Data Flow con criteri differenti;
• 7 colonne compongono lo schema finale, incluse 4 informazioni di tracciabilità;
• input e output vengono salvati in Parquet con compressione Snappy.

Il risultato è un dataset analytics-ready e una pipeline Azure importabile attraverso definizioni JSON versionate nel repository.

Evoluzioni future

Le evoluzioni più naturali riguardano l'industrializzazione della pipeline e l'integrazione con strumenti analytics a valle.

• portare il preprocessing dentro un flusso Azure completamente orchestrato;
• estendere le regole di data quality su null, duplicati e domini attesi;
• rafforzare resilienza e osservabilità con retry, alert e log di esecuzione;
• attivare trigger schedulati o event-driven per esecuzioni ricorrenti;
• centralizzare linked service e segreti con Azure Key Vault;
• automatizzare controlli su conteggi, schema e formato dell'output;
• pubblicare il dataset finale verso un motore SQL o una dashboard BI.

FAQ tecniche

Il filtro è fisso?

No. Rating minimo, anno iniziale e anno finale sono parametri del Mapping Data Flow e possono essere sovrascritti a ogni esecuzione.

Perché il valore predefinito 7 produce rating da 8 a 10?

La condizione applicata è Rating > rating_threshold. Con soglia 7 vengono quindi conservati soltanto i rating superiori a 7.

La pipeline esegue anche il notebook Pandas?

No. Nel progetto attuale il notebook viene eseguito separatamente e produce il Parquet caricato nel container di input. Automatizzare questo passaggio è uno dei miglioramenti previsti.

Quali parti sono versionate nel repository?

Il repository include notebook, dataset di esempio, definizioni JSON di pipeline, Data Flow e dataset ADF, documentazione progettuale e stima dei costi Azure.