dbt Analytics Engineering (AWS Redshift)
CompletatoProgetto dbt di analytics engineering su AWS Redshift Serverless, basato sul dataset e-commerce brasiliano Olist (100K ordini, 2016–2018). 18 modelli su tre layer (staging, intermediate, marts), completamente implementati e testati: 94 test, 3 macro personalizzate, 1 snapshot SCD Tipo 2 e uno star schema per analytics self-service.
Tecnologie
Problema
I dati sorgente grezzi richiedono una trasformazione strutturata in modelli dimensionali pronti per l'analytics, per consentire ai team BI e agli analisti di lavorare indipendentemente senza toccare le tabelle grezze.
Approccio
Pattern ELT con dbt su Redshift: layer staging (view conformi alle sorgenti) → layer intermedio (logica di business) → layer marts (modelli dimensionali per gli schemi core e marketing).
Risultato
18 modelli dbt completamente costruiti e testati: 7 view staging, 4 view intermediate, 6 tabelle mart (dim_customers, dim_products, dim_sellers, dim_dates, fct_orders, fct_order_items) + 1 mart marketing (customer lifetime value). 94 test eseguiti — 93 passano, 1 avviso (problema qualità dati noto nei dati sorgente). 1 seed (71 righe traduzioni PT→EN), 1 snapshot SCD Tipo 2 (sellers), 3 macro personalizzate, documentazione dbt completa generata.
Apprendimenti
dbt 2.0 rompe la sintassi dei test generici — tutti gli argomenti (values, to, field) devono essere annidati sotto una chiave arguments:. Redshift riserva raw come parola chiave; i riferimenti agli schemi devono essere quotati. Redshift non ha DISTINCT ON — ROW_NUMBER() OVER (PARTITION BY ...) è il sostituto corretto. LISTAGG e COUNT(DISTINCT) non possono essere combinati in Redshift e richiedono CTE separate. dbt docs generate è stato rimosso nella versione 2.0 — dbt compile --write-catalog con un server HTTP locale lo sostituisce.
Rilevanza
Dimostra analytics engineering, modellazione dimensionale e workflow moderni di trasformazione SQL — una competenza chiave per i ruoli orientati ai dati.