E-commerce Data Pipeline

Contesto

Progetto personale di Data Engineering su dati e-commerce interamente sintetici, distinto dal tirocinio Spindox. La pipeline e la dashboard sono documentate in un repository locale.

Problema

Ordini in ritardo, correzioni successive e colonne introdotte in un run più recente possono produrre duplicati o indicatori economici incoerenti se l’ingestion e le trasformazioni non condividono regole precise.

Obiettivo

Costruire caricamenti ripetibili, un modello dimensionale con grain esplicito e controlli che rendano verificabili le correzioni e le metriche consultate nella dashboard.

Responsabilità personali

Ho realizzato nel repository la generazione sintetica, il caricamento raw, i modelli dbt, i test e la dashboard Streamlit. La logica economica viene calcolata e verificata nei mart, non ricalcolata nell’interfaccia.

Implementazione documentata

Python genera CSV riproducibili e li carica in DuckDB con un manifest transazionale. dbt organizza staging, selezione della versione corrente e mart dimensionali. La fact delle righe d’ordine si collega alle dimensioni cliente, prodotto e data; Streamlit legge uno snapshot in sola lettura.

Decisioni e compromessi

• Upsert deterministico

  La chiave stabile è order_line_id. La versione corrente usa updated_at e, in caso di parità, un confronto canonico del payload. La regola aggiunge complessità, ma rende replay e ordine di arrivo indipendenti dal risultato finale.

• Anomalie osservabili

  Le righe economicamente non valide restano nella fact ma non contribuiscono al fatturato. Le chiavi dimensionali mancanti puntano a membri tecnici Unknown: si conserva il fatto senza fingere che il dato sia completo.

Controlli e verifiche

I test del progetto documentano unicità del grain, regole economiche, replay idempotente e parità tra il risultato incrementale e un full refresh di fact e dimensioni.

Evidenze e risultati documentati

• Caricamento incrementale

  Nel dataset sintetico documentato, 10 nuove righe tardive e 5 correzioni portano a 5.010 order_line_id distinti, senza duplicati finali.

• Verifiche

  I test documentano replay idempotente e corrispondenza tra risultato incrementale e full refresh per fact e dimensioni.

Limiti e miglioramenti

Il workload è sintetico e locale. Non dimostra comportamento su sorgenti reali, volumi di produzione o piattaforme cloud; la dashboard consulta uno snapshot e non esegue ingestion all’avvio.

Tecnologie

• Python
• DuckDB
• dbt Core e dbt-duckdb
• SQL
• Streamlit