ProjetsComplémentaire

NYC Taxi ELT with Bruin

ELT sur DuckDB et MotherDuck : ingestion PyArrow par lots, déduplication, contrôles qualité, 6 405 008 lignes cloud et tests SQL en CI.

Code sur GitHub

Vue d'ensemble

Pipeline ELT NYC taxi sur Bruin. Les assets Python récupèrent le parquet TLC, cèdent des lots PyArrow de 150 000 lignes, et atterrissent dans DuckDB ou MotherDuck. Les assets SQL filtrent, joignent le lookup paiement, dédupliquent, puis agrègent trips_report. Même code, deux environnements. Module 05 du Zoomcamp.

Problème

Un unique payload Arrow dépasse la limite IPC ~256 Mo de Bruin sur les gros mois (janvier 2020 yellow : 6,4 M de lignes). Retrélécharger le parquet à chaque run est du gaspillage. Les tarifs invalides et les clés composites dupliquées ne doivent pas arriver au rapport.

Solution technique

trips.py est un générateur : cache parquet local, colonnes réduites, lots, append à l'ingestion. Le staging est incrémental (time_interval), écarte les lignes invalides, ROW_NUMBER() sur une clé composite. Production : base MotherDuck nyc_taxi. Requête du 8 sept. 2026 : 6 405 008 lignes ingérées, 6 370 784 en staging, 312 agrégats. bruin validate en local : 4 assets, aucun problème.

Ce que contient le dépôt

Quatre assets : ingestion.trips, ingestion.payment_lookup, staging.trips, reports.trips_report
Lots PyArrow de 150 000 lignes sous la limite IPC Bruin
Contrôles de colonnes et d'unicité en staging
DuckDB local et MotherDuck avec le même SQL d'assets

Choix techniques

Append brut, dédup en staging: La zone d'atterrissage reste simple. Dédup et qualité là où on peut les tester.
Un pipeline, deux backends: La connexion duckdb-default pointe un fichier local en default et MotherDuck en production.