Aller au contenu

🏛️ Architecture

🏗️ Architecture Technique

GitHub Actions Snowflake Python dbt

  • Orchestration : GitHub Actions
  • Data Warehouse : Snowflake
  • Transformation : dbt
  • Langage : Python

📁 Structure du Projet

nyc-taxi-pipeline/
├── .github/
│ ├── workflows/
│  ├── nyc_taxi_pipeline.yml
│  ├── codeql.yml
│  ├── python_code_tests.yml
│  ├── release.yml
│  └── sqlfluff.yml
│ │
│ └── dependabot.yml
│
├── docs/
│
├── snowflake_ingestion/
│ ├── init_data_warehouse.py
│ ├── scrape_links.py
│ ├── upload_stage.py
│ ├── load_to_table.py
│ │
│ ├── sql/
│  ├── init/
│  ├── scraping/
│  ├── stage/
│  └── load/
│ │
│ └── tests/
│
└── dbt_transformations/
  └── NYC_Taxi_dbt/
    └── models/
      ├── staging/
      ├── final/
      └── marts/

📊 Flux de traitement

Pipeline Principal

NYC Taxi Data Pipeline
Pipeline d'ingestion exécuté mensuellement :

  1. Snowflake Infra Init
    Initialisation de l'infrastructure Snowflake (base, schémas, warehouse, rôle, utilisateur).
  2. Scrape Links
    Scraping et récupération des liens sources.
  3. Upload to Stage
    Upload des fichiers bruts dans le stage Snowflake.
  4. Load to Table
    Chargement des données dans la table du schéma RAW.
  5. Run dbt Transformations
    Transformations dbt (STAGING puis FINAL).
  6. Run dbt Tests
    Exécution des tests dbt pour valider les modèles.
  7. Backup Policy
    Configuration automatique des politiques de sauvegarde pour la base, table RAW et schéma FINAL.

Pipelines Qualité

  • CodeQL Security Scan
    Analyse statique du code Python à l’aide de CodeQL afin de détecter des vulnérabilités sur chaque push ou pull request vers dev et main.
  • Dependabot Updates
    Mises à jour automatisées des dépendances Python et GitHub Actions selon une planification trimestrielle.
  • pages-build-deployment
    Déploiement automatique de la documentation du projet via GitHub Pages.
  • Python Code Tests
    Exécution des tests unitaires Pytest sur chaque push ou pull request vers dev et main.
  • Release
    Versioning automatique, génération du changelog et publication des releases via Python Semantic Release sur chaque push ou pull request vers main.
  • SQL Code Quality
    Linting automatique du code SQL (modèles dbt et scripts Snowflake) avec SQLFluff sur chaque push ou pull request vers dev et main.

Modélisation des Données

Le tableau documente comment les données sont stockées.

Nom de la table Schéma Type de table Matérialisation
FILE_LOADING_METADATA SCHEMA_RAW Transitoire Table
YELLOW_TAXI_TRIPS_RAW SCHEMA_RAW Permanente Incremental
TAXI_ZONE_LOOKUP SCHEMA_RAW Permanente Table
TAXI_ZONE_STG SCHEMA_STAGING Transitoire Table
YELLOW_TAXI_TRIPS_STG SCHEMA_STAGING Transitoire Incremental
int_trip_metrics SCHEMA_STAGING Vue
fact_trips SCHEMA_FINAL Permanente Incremental
dim_locations SCHEMA_FINAL Permanente Table
dim_time SCHEMA_FINAL Permanente Table
dim_date SCHEMA_FINAL Permanente Table
marts SCHEMA_FINAL Vue

details disponibles dans la 📚 Documentation dbt en ligne

Schéma en étoile (ERD)

%%{init: {"themeVariables": {"fontSize": "10px"}}}%%
erDiagram
    FACT_TRIPS {
        number surrogate_key PK
        number date_id FK
        number time_id FK
        number location_id FK
        float fare_amount
        float trip_distance
    }
    DIM_DATE {
        number date_id PK
        int year
        int month
        int day_of_week
    }
    DIM_TIME {
        number time_id PK
        int hour
        string period_of_day
    }
    DIM_LOCATIONS {
        number location_id PK
        string zone
        string borough
    }
    FACT_TRIPS }o--|| DIM_DATE : "pickup / dropoff"
    FACT_TRIPS }o--|| DIM_TIME : "pickup / dropoff"
    FACT_TRIPS }o--|| DIM_LOCATIONS : "pickup / dropoff"

📐 Gestion des dimensions lentes

Les 3 dimensions sont en SCD Type 0 : aucune variation n'est attendue.

Dimension Type SCD Justification
dim_date Type 0 Les attributs d'une date ne changent jamais
dim_time Type 0 Les attributs d'une heure ne changent jamais
dim_locations Type 0 Le référentiel des zones NYC TLC est stable

Évolutions possibles :

  • Correction de nom de zone → SCD Type 1 (écrasement sans historisation)
  • Scission de zone → SCD Type 2 (nouvelle ligne avec valid_from, valid_to, is_current)