NYC Taxi Analytics

Le projet utilise les TLC Trip Record Data, qui recensent les courses des taxis jaunes de New York. Ces taxis, aussi appelés « medallion taxis », peuvent prendre des passagers dans les cinq arrondissements mais circulent surtout à Manhattan.

J'ai téléchargé les données disponibles pour 2024 et je les ai chargées dans un lakehouse Fabric, qui sert de couche de stockage où ces fichiers atterrissent.

• →Les courses des taxis jaunes sont stockées au format Parquet, un fichier par mois.
• →Une table de correspondance des zones est stockée en CSV et contient les données de référence statiques des zones de taxi.

2.png3.png

Une fois les fichiers dans le lakehouse, une activité de copie Data Factory les ingère dans une table de staging du data warehouse. La table des zones est elle aussi chargée en staging comme table statique, traitée une seule fois puis laissée telle quelle.

4.1.png4.2.png

Le chemin du fichier est généré dynamiquement à partir de la variable v_date, ce qui permet au pipeline de traiter automatiquement chaque nouveau mois de données :

@concat('yellow_tripdata_', variables('v_date'), '.parquet')

15.1.png15.2.png

• →La couche de staging contient la table principale stg.nyctaxi_yellow, qui stocke les courses.
• →Elle inclut aussi la table de référence statique stg.taxi_zone_lookup, qui décrit les zones de taxi de New York.

6.3.png6.2.png

À cette étape, je nettoie et traite les données avant de les déplacer vers la couche de présentation.

Suppression des données hors période

1. 01Une procédure stockée supprime dynamiquement les données hors de la période traitée. Elle prend deux paramètres : @start_date (début de période) et @end_date (fin de période).
2. 02Une activité Set Variable définit v_end_date comme v_date plus un mois, afin que le pipeline traite la bonne fenêtre temporelle.
3. 03Une activité Stored Procedure appelle stg.data_cleaning_stg, en associant v_date à @start_date et v_end_date à @end_date.
4. 04Par cohérence, l'activité Copy to Staging vide stg.nyctaxi_yellow avant chaque exécution, pour ne traiter que les données de la période en cours.

Journalisation des métadonnées

J'ai créé un schéma metadata avec une table processing_log qui trace chaque exécution du pipeline. Après le nettoyage et la transformation, un enregistrement est inséré avec :

• →pipeline_run_id — identifiant unique de l'exécution.
• →table_processed — nom de la table traitée.
• →rows_processed — nombre de lignes traitées.
• →latest_processed_pickup — date de prise en charge la plus récente du lot.
• →processed_datetime — horodatage de l'exécution.

La logique d'insertion est encapsulée dans une procédure stockée afin que la journalisation s'exécute systématiquement dans le pipeline.

8.1.png8.2.png

Fenêtre de traitement auto-incrémentée

Pour toujours traiter le mois suivant disponible, v_date est mise à jour à partir des dernières données traitées. Une activité Script, Latest_Processed_Data, récupère le tpep_pickup_datetime le plus récent (moment où le compteur est enclenché) dans metadata.processing_log, puis une activité Set Variable y ajoute un mois.

9.1.png9.2.png

Le pipeline obtenu, pl_stg_processing_nyctaxi, automatise l'ingestion, le nettoyage et le suivi : il ajuste la période de traitement, alimente le staging, supprime les enregistrements hors période et met à jour la table de métadonnées pour une traçabilité complète.

10.png

Enrichissement avec Dataflow Gen2

Un Dataflow Gen2 déplace les données nettoyées du staging vers la couche de présentation. Il effectue des jointures gauches entre nyctaxi_yellow et taxi_zone_lookup pour ajouter l'arrondissement et la zone de prise en charge et de dépose, supprime les colonnes inutiles, catégorise les valeurs et charge le résultat dans dbo.nyctaxi_yellow.

11.3.png11.2-1.png11.1.png

Le pipeline pl_processing_nyctaxi exécute ce dataflow, puis appelle la procédure stockée insert_presentation_metadata pour journaliser le nombre de lignes, la dernière date de prise en charge et l'heure d'exécution de dbo.nyctaxi_yellow.

16.png12.1.png12.2.png

Pipeline maître

Enfin, un pipeline maître orchestre séquentiellement pl_stg_processing_nyctaxi puis pl_processing_nyctaxi : le staging s'exécute d'abord, suivi de la transformation et du chargement dans la couche de présentation. Cela garantit la cohérence des données et une automatisation de bout en bout.

13.png

Une fois dbo.nyctaxi_yellow finalisée, j'ai construit un modèle sémantique qui structure et optimise les données pour Power BI, avec des relations et des mesures calculées pour des requêtes efficaces.

14.1.png14.2.png

Le rapport analyse la performance des taxis jaunes avec des indicateurs clés : revenu total, nombre de courses et de passagers. Des filtres interactifs permettent d'explorer les tendances par moyen de paiement, opérateur et arrondissement de prise en charge ou de dépose.

ff.png