dbt Analytics Engineering (AWS Redshift)
TerminéProjet dbt d'analytics engineering sur AWS Redshift Serverless, basé sur le dataset e-commerce brésilien Olist (100K commandes, 2016–2018). 18 modèles sur trois couches (staging, intermédiaire, marts), entièrement implémentés et testés : 94 tests, 3 macros personnalisées, 1 snapshot SCD Type 2 et un star schema pour analytics en self-service.
Technologies
Problème
Les données sources brutes nécessitent une transformation structurée en modèles dimensionnels prêts pour l'analytics, afin de permettre aux équipes BI et aux analystes de travailler indépendamment sans toucher aux tables brutes.
Approche
Pattern ELT avec dbt sur Redshift : couche staging (vues conformes aux sources) → couche intermédiaire (logique métier) → couche marts (modèles dimensionnels pour les schémas core et marketing).
Résultat
18 modèles dbt entièrement construits et testés : 7 vues staging, 4 vues intermédiaires, 6 tables mart (dim_customers, dim_products, dim_sellers, dim_dates, fct_orders, fct_order_items) + 1 mart marketing (valeur vie client). 94 tests exécutés — 93 passent, 1 avertissement (problème qualité connu dans les données sources). 1 seed (71 lignes traductions PT→EN), 1 snapshot SCD Type 2 (sellers), 3 macros personnalisées, documentation dbt complète générée.
Apprentissages
dbt 2.0 casse la syntaxe des tests génériques — tous les arguments (values, to, field) doivent être imbriqués sous une clé arguments:. Redshift réserve raw comme mot-clé ; les références de schéma doivent être quotées. Redshift n'a pas de DISTINCT ON — ROW_NUMBER() OVER (PARTITION BY ...) est le substitut correct. LISTAGG et COUNT(DISTINCT) ne peuvent pas être combinés dans Redshift et nécessitent des CTEs séparées. dbt docs generate a été supprimé en 2.0 — dbt compile --write-catalog avec un serveur HTTP local le remplace.
Pertinence
Démontre l'analytics engineering, la modélisation dimensionnelle et les workflows modernes de transformation SQL — une compétence clé pour les rôles orientés données.