Pipeline de données e-commerce

Contexte

Projet personnel d’ingénierie des données fondé sur des données e-commerce entièrement synthétiques, distinct du stage chez Spindox. La pipeline et le tableau de bord sont documentés dans un dépôt local.

Problème

Les commandes tardives, les corrections ultérieures et les colonnes introduites dans un nouveau chargement peuvent créer des doublons ou des indicateurs incohérents sans règles communes pour l’ingestion et les transformations.

Objectif

Construire des chargements reproductibles, un modèle dimensionnel au grain explicite et des contrôles permettant de vérifier les corrections et les indicateurs du tableau de bord.

Mes responsabilités

J’ai réalisé dans le dépôt la génération synthétique, l’ingestion brute, les modèles dbt, les tests et le tableau de bord Streamlit. Les mesures économiques sont calculées et vérifiées dans les marts, sans nouveau calcul dans l’interface.

Mise en œuvre documentée

Python génère des CSV reproductibles et les charge dans DuckDB avec un manifeste transactionnel. dbt organise staging, sélection de la version courante et marts dimensionnels. Une table de faits par ligne de commande rejoint les dimensions client, produit et date ; Streamlit lit un instantané en lecture seule.

Décisions techniques et compromis

• Mise à jour déterministe

  order_line_id est la clé stable. La version courante est choisie selon updated_at puis, en cas d’égalité, par comparaison canonique du contenu. Cette règle ajoute de la complexité mais rend le résultat indépendant des rejeux et de l’ordre d’arrivée.

• Anomalies visibles

  Les lignes économiquement invalides restent dans la table de faits sans contribuer au chiffre d’affaires. Les clés dimensionnelles absentes pointent vers des membres techniques Unknown : le fait est conservé sans prétendre que la donnée est complète.

Contrôles et vérifications

Les tests du projet documentent l’unicité du grain, les règles métier, le rejeu idempotent et la correspondance des résultats incrémentaux avec un recalcul complet de la table de faits et des dimensions.

Éléments et résultats documentés

• Chargement incrémental

  Dans le jeu synthétique documenté, 10 nouvelles lignes tardives et 5 corrections produisent 5 010 valeurs order_line_id distinctes, sans doublons finaux.

• Vérifications

  Les tests documentés montrent un rejeu idempotent et une correspondance entre les résultats incrémentaux et le recalcul complet pour la table de faits et les dimensions.

Limites et améliorations

Le jeu est synthétique et local. Il ne démontre pas le comportement sur des sources réelles, à l’échelle de production ou dans le cloud ; le tableau de bord lit un instantané et ne lance pas l’ingestion au démarrage.

Technologies

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