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

                         ┌──────────────────────────────┐
  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 et alertes : Kappa. Kafka → Structured Streaming, watermark court pour la réactivité.
• Facturation mensuelle : un job batch sur les données archivées (Parquet ou Delta), pour l’exactitude et les retardataires. C’est la couche batch de Lambda, mais écrite avec la même API que le flux.

Une architecture hybride, 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.