Atelier – Lambda ou Kappa pour notre application de taxis ?

• 30 min · 15h15 – 15h45
• Présentation 5 min · atelier en groupes de 3 : 20 min · restitution 5 min
• Sans ordinateur : tableau blanc, papier ou outil de dessin partagé

📁 Dans le dépôt

• Pas de notebook : atelier d’architecture, uniquement un schéma à produire.
• Référence batch : jour1/TP4_spark_sql.ipynb (écriture Parquet partitionnée).
• Référence streaming : jour3/TP11_ml_streaming_catalyst.ipynb (foreachBatch + modèle).
• Correction schématisée : section « Atelier Lambda / Kappa – une correction possible » de quiz/quiz_jour3.md, à consulter après la restitution.

Objectif : assembler batch et streaming dans une architecture, et justifier le choix.

Réussi si : un schéma dessiné, chaque besoin métier rattaché à une couche, et une justification.

L’énoncé

Notre application de taxis a besoin :

1. d’un tableau de bord du chiffre d’affaires par zone, rafraîchi toutes les 5 secondes ;
2. d’alertes de panne en temps réel (comme au TP 10) ;
3. d’une facturation mensuelle exacte aux chauffeurs.

Lambda ou Kappa ? Dessinez l’architecture : sources, journal, traitements, stockages, consommateurs. Pour chaque besoin, indiquez la couche qui le sert et pourquoi.

Vous avez déjà construit les deux couches : le batch du jour 1 (TP 4, écriture Parquet partitionnée) et le streaming du jour 3 (TP 9 à 11), avec la même API.

Rappel des deux modèles

	Lambda	Kappa
Chemins	Batch (exact, périodique) + Speed (temps réel) + Service (fusion)	Un seul : journal rejouable → streaming → service
Code	2 versions à maintenir	1 seul code
Recalcul	Batch complet, simple	Rejouer le journal avec le nouveau code
Idéal pour	Rapports exacts + temps réel	Événements, temps réel d’abord

Questions pour guider le groupe

• Quelle source d’événements ? Un dossier de fichiers comme en TP, ou Kafka ?
• La facturation doit-elle être recalculable des mois plus tard ? Avec quelle tolérance aux retards ?
• Un watermark de 2 minutes convient-il aux alertes ? À la facturation ?
• Où archiver les événements bruts ? Parquet, Delta, le journal Kafka lui-même ?
• Si le code change, comment recalculer le passé ?
• Combien de codes différents votre équipe peut-elle maintenir ?

Restitution

Un groupe présente son schéma en 2 minutes ; les autres complètent ou contestent. Si le TP 11 a débordé : une seule restitution.

Une correction possible

🏗️ À consulter après la restitution : Schéma d'architecture et justification besoin par besoin

                         ┌──────────────────────────────┐
  Courses, logs ──► Kafka│  journal rejouable           │
  (événements)           └───────┬──────────────┬───────┘
                                 │              │
               Structured Streaming          Archivage brut
               fenêtres, watermark court     Parquet / Delta partitionné par jour
                      │          │                     │
             Tableau de bord   Alertes          Job batch mensuel
             CA par zone, 5 s  /payment         facturation exacte
                                                (availableNow ou spark.read)

• Tableau de bord (5 s) et alertes /payment : Kappa. Kafka → Structured Streaming, avec un watermark court (2 minutes) pour privilégier la réactivité opérationnelle.
• Facturation mensuelle exacte aux chauffeurs : un job batch sur les données archivées (Parquet ou Delta Lake), pour garantir l’exactitude comptable au centime près et inclure les courses arrivées avec 24 h de retard (terminal hors réseau dans un tunnel). C’est la couche batch de Lambda, mais écrite avec la même API DataFrame que le flux !

Besoin métier	Latence cible	Tolérance aux retards	Couche choisie
1. Tableau de bord CA par zone	5 secondes	Faible (si une course arrive 1 h après, ce n’est pas grave pour la carte météo du trafic)	Speed / Streaming (outputMode="update", watermark 2 min)
2. Alertes de panne /payment	< 1 minute	Faible (on veut biper l’astreinte tout de suite)	Speed / Streaming (fenêtre glissante 1 min / 30 s)
3. Facturation mensuelle chauffeurs	Mensuelle (J+2)	Zéro perte tolérée (obligation légale et comptable)	Batch sur archive Delta / Parquet (ou trigger(availableNow=True))

Une architecture hybride (Lakehouse) est très fréquente en pratique. Il n’y a pas une seule bonne réponse : valorisez la justification. Avec Spark, la frontière entre les deux modèles s’estompe : availableNow permet de lancer un « streaming » comme un batch planifié, et un seul code peut servir les deux couches.

À retenir

• Choisir par besoin (fraîcheur, exactitude, recalcul), pas par mode.
• Le watermark arbitre réactivité et exhaustivité : court pour alerter, long ou batch pour facturer.
• Une seule API pour le batch, le ML et le streaming : c’est le fil des 3 jours.