AWS Crypto ETL Pipeline
Cos'è il progetto
AWS Crypto ETL Pipeline è una pipeline data engineering end-to-end che porta dati crypto e Google Trends da file CSV a un dataset analitico interrogabile su Redshift Serverless. Il progetto mostra un flusso cloud completo: ingestion su S3, trasformazioni PySpark con AWS Glue, orchestrazione con Step Functions e visualizzazione tramite QuickSight.
Contesto tecnico
Il progetto nasce da un bisogno tipico del Data Engineering: trasformare dataset eterogenei e con granularità diverse in un flusso dati unico, pulito e interrogabile.
Nel caso specifico, i dati di partenza sono prezzi storici di Bitcoin e Monero, disponibili a granularità giornaliera, e indici Google Trends relativi agli stessi asset, disponibili a granularità settimanale. Senza una pipeline strutturata, questi dati restano difficili da confrontare: formati diversi, frequenze temporali diverse e passaggi manuali rendono l'analisi poco riproducibile.
L'obiettivo era costruire una pipeline cloud-native capace di acquisire i dati, trasformarli, validarli e renderli disponibili in un data warehouse per analisi successive.
Obiettivo
L'obiettivo del progetto era realizzare una pipeline ETL end-to-end su AWS che coprisse l'intero ciclo del dato:
caricamento dei CSV in un raw layer su S3;
preprocessing e normalizzazione con AWS Glue e PySpark;
creazione di un silver layer in formato Parquet;
costruzione di un gold layer unificato;
caricamento finale su Redshift Serverless;
visualizzazione analitica tramite QuickSight;
orchestrazione dei job con Step Functions, retry ed error handling.
Il progetto non voleva essere solo un notebook di analisi, ma una piccola architettura dati riproducibile, osservabile e vicina a un flusso di lavoro reale.
Architettura
La pipeline segue una struttura a layer:
CSV locali caricati su S3 tramite script Python e boto3.
S3 raw layer come area di atterraggio dei dati originali.
AWS Glue Job T1 per pulizia, conversione date, casting numerico e output Parquet.
S3 silver layer con dati puliti e compressi.
AWS Glue Job T2 per join, forward fill, media mobile e unificazione BTC/XMR.
S3 gold layer con dataset finale pronto per il data warehouse.
AWS Glue Load Job per caricamento JDBC/IAM su Redshift Serverless.
QuickSight come livello di visualizzazione.
I job Glue sono orchestrati in sequenza da AWS Step Functions. Ogni step ha retry automatico, backoff esponenziale e gestione degli errori verso uno stato di fail.
Dataset
La pipeline lavora su quattro sorgenti:
prezzi storici Bitcoin a granularità giornaliera;
prezzi storici Monero a granularità giornaliera;
Google Trends per la keyword "bitcoin" a granularità settimanale;
Google Trends per la keyword "Monero" a granularità settimanale.
La sfida principale non era solo pulire i dati, ma renderli confrontabili nel tempo. Per questo i valori settimanali di Google Trends vengono allineati alle date giornaliere tramite forward fill con window function.
Scelte tecniche
Perché AWS Glue e PySpark
AWS Glue permette di eseguire trasformazioni distribuite senza gestire direttamente server o cluster. Anche se il dataset del progetto è contenuto, la scelta è utile per simulare un pattern reale: ingestion su S3, trasformazioni PySpark, output Parquet e caricamento verso un warehouse.
PySpark è stato usato per gestire trasformazioni tipiche del mondo data engineering: normalizzazione dei tipi, window function, join tra dataset con granularità diverse e creazione di uno schema finale unificato.
Perché S3 raw, silver e gold
La separazione in layer rende la pipeline più leggibile e manutenibile:
raw conserva il dato originale;
silver contiene dati puliti e standardizzati;
gold espone il dataset finale pronto per analisi e dashboard.
Questa struttura evita di perdere tracciabilità e permette di rieseguire o correggere singoli passaggi senza confondere dati grezzi e dati trasformati.
Perché Parquet
Il formato Parquet è stato scelto per il layer intermedio perché è colonnare, compresso e adatto a workload analitici. In una pipeline dati è preferibile rispetto a CSV quando i dati devono essere letti più volte da job diversi o caricati verso sistemi analitici.
Perché Step Functions
Step Functions è stato usato per orchestrare la sequenza dei job Glue. Il vantaggio principale è separare la logica di orchestrazione dalla logica di trasformazione: i job si occupano dei dati, mentre la state machine gestisce ordine, retry, backoff ed errori.
Ragionamento progettuale
Il punto centrale del progetto è stato progettare una pipeline leggibile, non solo funzionante.
La prima decisione è stata separare le trasformazioni in più step invece di concentrare tutta la logica in un unico script. Questa scelta rende più semplice capire il ruolo di ogni job:
T1 prepara dati puliti e coerenti;
T2 crea feature analitiche e unifica gli asset;
Load porta il dato finale nel warehouse.
Un'altra decisione importante è stata separare il job di caricamento dal job di trasformazione. Il job Load.py legge il dataset gold, lo ordina per data e simbolo crypto, e lo scrive su Redshift tramite JDBC/IAM. In questo modo il passaggio verso il warehouse resta isolato dalla logica di cleaning e unificazione.
La trasformazione più interessante è l'allineamento tra serie giornaliere e serie settimanali. I dati Google Trends non hanno la stessa frequenza dei prezzi crypto, quindi è stato necessario applicare un forward fill per propagare il valore settimanale ai giorni successivi fino al nuovo valore disponibile.
Risultati
La pipeline produce una tabella finale public.crypto_analysis su Redshift con:
simbolo crypto;
data;
prezzo trasformato con media mobile a 10 giorni;
indice Google Trends allineato temporalmente.
Le performance documentate sono:
T1 preprocessing: circa 128 secondi;
T2 unification: circa 118 secondi;
Load su Redshift: circa 296 secondi;
runtime totale pipeline: circa 9 minuti.
Il progetto include anche una stima dei costi mensili AWS, con un costo contenuto per Glue, Step Functions, S3, Redshift Serverless e QuickSight.
FAQ tecniche
Perché hai usato AWS Glue invece di uno script Python locale?
Ho scelto AWS Glue per avvicinare il progetto a un contesto data engineering realistico: trasformazioni distribuite, integrazione nativa con S3, esecuzione serverless e orchestrazione con Step Functions. Uno script Python locale sarebbe stato più semplice, ma avrebbe mostrato meno bene il ragionamento architetturale.
A cosa servono i layer raw, silver e gold?
Li ho usati per separare le fasi del ciclo dati. Nel raw layer conservo i dati originali, nel silver layer preparo dati puliti e standardizzati, mentre nel gold layer espongo il dataset finale pronto per analisi e caricamento su Redshift.
Perché Google Trends richiede un forward fill?
Perché Google Trends è disponibile a granularità settimanale, mentre i prezzi crypto sono giornalieri. Ho usato il forward fill per allineare il valore settimanale ai giorni intermedi fino al nuovo dato disponibile, evitando buchi nel dataset finale.
Perché usare Redshift Serverless?
Ho usato Redshift Serverless per esporre il dataset finale in un data warehouse analitico senza dover gestire direttamente cluster provisioned. Mi interessava arrivare a una struttura interrogabile via SQL e pronta per QuickSight.