Projet intégrateur — StreamCity Analytics
La TLC (Taxi & Limousine Commission) de New York publie chaque mois les données de tous les trajets de taxi de la ville. Votre mission : construire un pipeline data end-to-end — ingestion distribuée avec Spark, indexation dans Elasticsearch, visualisation dans Kibana — et confronter Spark à MapReduce/YARN sur une même agrégation pour en mesurer l'écart de performance.
| Technologie | Rôle dans ce projet | Pourquoi ce choix |
|---|---|---|
| ⚡ Apache Spark | ETL distribué — lecture, nettoyage, enrichissement, agrégations des fichiers Parquet | Volume de données justifiant la distribution. Spark SQL, DataFrames, optimisation des jobs. Cœur du projet. |
| 🔍 Elasticsearch | Index de recherche et d'analyse — stockage des données agrégées et brutes pour Kibana | Complémentarité naturelle avec Spark (connector officiel). Permet le full-text search + analytics sur les données géospatiales NYC. |
| 📊 Kibana | Dashboard de visualisation temps réel alimenté par Elasticsearch | Couplage natif avec ES. Visualisations géospatiales, time series, histogrammes — idéaux pour les données de taxi. |
| 🗺️ MapReduce / YARN | Implémentation Java d'une agrégation de référence — comparaison de performance avec Spark | Pédagogique : faire tourner le même calcul en MR Java puis en Spark et mesurer l'écart. Rend concret l'apport de Spark. |
Parquet NYC TLC
~20 M lignes/mois
Stockage HDFS / local
Agrégation Java
Reference benchmark
YARN resource manager
Nettoyage, enrichissement
Agrégations optimisées
Spark SQL + DataFrames
Index structuré
Mapping géospatial
Indexation Spark→ES
Dashboard live
Geo heatmap
Time series + KPIs
Les données sont publiées mensuellement par la Taxi & Limousine Commission de New York. Format Parquet, disponibles sans inscription depuis 2009. Pour ce projet, utiliser 3 mois consécutifs de 2023 (janvier à mars), soit environ 60 millions de trajets.
| Colonne | Type | Enjeu data engineering |
|---|---|---|
tpep_pickup_datetime | Timestamp | Extraction heure/jour/semaine/mois. Filtrage des dates aberrantes (> 2023 ou < 2020). Clé de partitionnement. |
tpep_dropoff_datetime | Timestamp | Calcul de la durée du trajet. Détection des durées impossibles (< 30s ou > 6h). |
trip_distance | Double | Valeurs négatives ou nulles à filtrer. Outliers (distance > 100 miles = probable erreur GPS). |
PULocationID / DOLocationID | Integer | Join avec taxi_zone_lookup.csv pour enrichir Borough et Zone. Clé pour les analyses géospatiales. |
fare_amount | Double | Valeurs négatives (anomalies), zéros, outliers. Nettoyage strict nécessaire avant agrégation. |
payment_type | Integer (1–6) | Encodage à mapper (1=Card, 2=Cash, 3=No charge, 4=Dispute…). Analyse de la préférence de paiement. |
passenger_count | Double (nullable) | Valeurs nulles fréquentes depuis 2022 (enregistrement automatisé). Imputation ou exclusion à justifier. |
congestion_surcharge | Double | Données manquantes pré-2019. Indicateur de zone congestionnée (Manhattan core). |
Implémenter l'agrégation de référence en Java MapReduce, la soumettre sur YARN, mesurer les performances.
PULocationID) et chaque heure de la journée, calculer le nombre de trajets, le montant moyen et la distance moyenne. Cette même agrégation sera réimplémentée en Spark le Jour 2 — la comparaison sera directe.
Configurer Hadoop (HDFS + YARN) en mode pseudo-distribué ou utiliser un cluster fourni. Copier les données sur HDFS. Vérifier le ResourceManager et le NodeManager.
Écrire les 3 classes Java : Mapper (lit chaque ligne CSV, émet <zone_heure, tarif,distance,1>), Reducer (agrège par clé), Driver (configure le job). Compiler et packager en JAR.
Soumettre le job avec hadoop jar. Monitorer via l'interface YARN ResourceManager (port 8088). Mesurer : durée totale, temps Map, temps Reduce, octets lus/écrits.
Capturer toutes les métriques YARN (elapsed time, map time, reduce time, bytes read). Ces chiffres seront comparés aux résultats Spark Jour 2. Exporter les résultats en CSV pour validation croisée.
Réimplémenter la même agrégation en Spark, puis étendre le pipeline à un ETL complet avec enrichissement et partitionnement.
Reproduire exactement la même agrégation (zone × heure → count, avg_fare, avg_distance) en Spark DataFrame API. Mesurer le temps d'exécution. Comparer les résultats ligne à ligne pour valider la cohérence.
Enregistrer le DataFrame en vue temporaire et écrire 5 requêtes SQL complexes : zones les plus rentables par heure, corrélation distance/tarif par borough, impact des jours fériés sur le volume, détection des heures creuses.
Analyser les plans d'exécution (explain()). Tester l'impact du partitionnement, du cache et du broadcast join. Documenter les optimisations appliquées et leur impact mesuré sur le Spark UI.
Définir le mapping ES, indexer les données via Spark, construire le dashboard Kibana.
Créer 2 index avec leurs mappings : nyc_trips (données brutes échantillonnées) et nyc_agg_zone_hour (agrégations). Typer correctement les champs géospatiaux, temporels et numériques.
geo_point permettront les visualisations cartographiques dans Kibana. Le champ @timestamp active les fonctionnalités time-series natives.Utiliser le connector officiel Elasticsearch-Hadoop pour écrire directement depuis Spark vers ES sans passer par un script intermédiaire. Configurer le batch size et la parallélisation.
Construire le dashboard Kibana en connectant les deux index créés. Utiliser les visualisations cartographiques, time series, et histogrammes pour répondre aux questions business.
Densité des départs par zone géographique. Filtrable par heure, borough, type de paiement.
Évolution heure par heure sur 3 mois. Détection des pics (rush hours, weekends, événements).
Comparaison Manhattan vs Brooklyn vs Queens. Décomposition par heure de la journée.
Card vs Cash par borough. Évolution dans le temps (adoption du paiement carte).
Classement des zones par volume de trajets, tarif moyen, durée moyenne. Drill-down disponible.
Total trajets indexés, tarif moyen global, % rush hour, durée médiane. Vue temps réel.
ndjson) + captures d'écran des 6 visualisations. Le dashboard doit fonctionner avec des filtres dynamiques.
Synthétiser l'architecture, analyser les résultats, rédiger les recommandations et défendre le projet.
Schéma d'architecture complet, justification des choix techniques, rapport de qualité des données (anomalies trouvées, traitements appliqués), tableau de comparaison MapReduce/Spark commenté.
3 insights business concrets sur le marché du taxi NYC : patterns de rush hour, zones sous-exploitées, évolution du cashless, impact météo (si enrichissement données météo intégré en bonus).
15 slides max. Structure : contexte data engineering → architecture → MR benchmark → Spark ETL + résultats → ES/Kibana démo live → recommandations d'amélioration. Démo live du dashboard Kibana obligatoire.
writeStreamtext — absence de compréhension des types ES (keyword, integer, geo_point) empêchant les agrégations KibanaQuestions posées individuellement à chaque membre. Les deux membres doivent maîtriser l'intégralité du pipeline.
sample(0.05) avant d'indexer dans ES ? Quels sont les trade-offs ?keyword et un champ text dans le mapping ES ? Pourquoi PUBorough est-il en keyword et non en text ?@timestamp est votre champ temporel ? Que se passe-t-il si vous l'oubliez dans le mapping ?| MR / YARN | Code Java correct et fonctionnel · Soumission YARN réussie · Métriques documentées · Servir de référence comparative |
| Spark | Pipeline ETL robuste · Feature engineering pertinent · Optimisations mesurées · Résultats cohérents avec MapReduce |
| Elasticsearch | Mapping typé correctement · Indexation via connector Spark · Requêtes DSL maîtrisées · Index cohérent avec Kibana |
| Kibana | 6 visualisations pertinentes · Interactivité réelle · Démo live maîtrisée · Réponse aux questions business |
| Cohérence | Pipeline end-to-end fonctionnel · MR et Spark produisent les mêmes résultats · ES alimente réellement Kibana |
Dataset : NYC TLC Trip Record Data · ~60M trajets · 3 mois 2023 · Données publiques — aucune inscription requise