Architecture Lambda vs Kappa : quelle structure pour le streaming de données en 2026 ?

1. Contexte : pourquoi deux architectures pour le streaming ?

Le traitement des données en temps réel a longtemps souffert d’une tension : les moteurs batch (Hadoop, Spark batch) sont précis, robustes, mais lents (plusieurs minutes/heures). Les moteurs streaming (Storm, premières versions de Spark Streaming) sont rapides (quelques secondes), mais moins tolérants aux pannes et moins exacts (au moins une fois).

L’architecture Lambda (2011) a proposé un compromis : faire les deux. L’architecture Kappa (2014) a osé : et si on ne faisait que du streaming, avec assez de rétention pour recalculer ?

2. Architecture Lambda : le compromis batch + speed

Lambda segmente le pipeline en trois couches :

• Batch layer : stocke l’intégralité des données brutes (HDFS, S3). Lance périodiquement des jobs batch (Spark, Hive) pour précalculer des vues (résultats exacts sur tout l’historique).
• Speed layer : traite les données récentes en streaming (Storm, Flink, Kafka Streams, Spark Streaming) pour compenser la latence du batch. Ces résultats sont approximatifs ou incomplets.
• Serving layer : fusionne les résultats des deux couches à la requête, renvoyant soit la vue batch (quand disponible), soit la vue speed, soit une combinaison.

✅ Avantages de Lambda

• Robustesse : le batch garantit l’exactitude sur l’historique complet.
• Latence maîtrisée : le speed assure des réponses rapides sur les données récentes.
• Tolérance aux pannes : si le speed échoue, on peut attendre le prochain batch.

❌ Inconvénients de Lambda

• Double code : la même logique métier doit être implémentée deux fois (batch et speed). Risque d’incohérence.
• Complexité opérationnelle : deux pipelines, deux SLA, deux jeux de monitoring.
• Décalage possible : les résultats entre batch et speed peuvent diverger (notamment dans les fenêtres glissantes).

3. Architecture Kappa : le streaming unifié

Kappa simplifie : tout est stream. Une seule couche de traitement lit le flux d’événements depuis une file (Kafka, Pulsar). Pour recalculer un résultat (nouvelle logique, correction d’erreur), on rejoue le flux depuis un offset antérieur.

• Message bus central : Kafka (ou Pulsar, Redpanda) avec rétention longue (jours, mois).
• Processing engine : Kafka Streams, Flink, Spark Structured Streaming, ou toute bibliothèque stream native.
• Sink : base de données de service (Elasticsearch, Cassandra, Druid, ClickHouse) pour les résultats.

✅ Avantages de Kappa

• Code unique : une seule logique métier, plus simple à maintenir.
• Pas de fusion : pas de risque d’incohérence entre batch et speed.
• Reprocessing à la demande : correction possible a posteriori.

❌ Inconvénients de Kappa

• Coût du reprocessing : pour recalculer sur des mois de données, il faut le temps et les ressources.
• Rétention longue : conserver des téraoctets dans Kafka peut être cher (mais des solutions comme tiered storage atténuent).
• Exactitude dépend du moteur : tous les moteurs streaming ne garantissent pas la sémantique exactly‑once (mais Flink, Kafka Streams et Spark Structured Streaming le font bien).

4. Comparatif Lambda vs Kappa

5. Quand choisir Lambda ? Quand choisir Kappa ?

Choisir Lambda si…

• Vous avez déjà un lourd patrimoine batch (Hive, Spark batch) et ne pouvez pas le remplacer.
• Les calculs batch sont très complexes, et les réécrire en streaming serait un effort disproportionné.
• Vos volumes sont si énormes que le streaming ne peut pas traiter l’intégralité de l’historique (mais les progrès de Flink/Spark atténuent ce point).
• Vous travaillez dans un secteur très régulé où l’exactitude absolue sur tout l’historique est une obligation (finance, assurance).

Choisir Kappa si…

• Vous commencez un nouveau projet de streaming.
• Vous pouvez conserver les événements bruts longtemps (Kafka tiered storage).
• Vous acceptez que le reprocessing occasionnel prenne du temps (il n’est pas fait à chaque requête).
• Vous voulez minimiser la dette technique (code unique).
• Votre besoin de latence est homogène (pas de distinction nette entre « historique batch » et « récent speed »).

6. Mise en œuvre : exemples concrets

Lambda-type avec Spark

• Batch : Spark SQL quotidien sur les données en S3/Delta Lake.
• Speed : Spark Structured Streaming (micro‑batch) sur Kafka pour les dernières minutes.
• Serving : base de données (Druid, ClickHouse) qui interroge les deux ensembles.

Kappa-type avec Kafka + Flink

• Source : événements dans Kafka (rétention 30 jours).
• Traitement : Flink job unique qui applique la fenestration, agrégations, jointures.
• Sink : résultats dans Elasticsearch ou CockroachDB.
• Reprocessing : pour modifier la logique, on lance un nouveau Flink job à partir d’un offset Kafka antérieur.

DataStream<Event> stream = env
    .addSource(new FlinkKafkaConsumer<>("topic", schema, props))
    .keyBy(Event::getUserId)
    .window(SlidingProcessingTimeWindows.of(Time.minutes(5), Time.minutes(1)))
    .aggregate(new CountAggregate());

stream.addSink(new ElasticsearchSink<>());

7. Tendances 2026 : vers la convergence ?

• Streaming-first avec batch opportuniste : Spark Structured Streaming et Flink peuvent exécuter des requêtes batch sur des données historiques en utilisant le même moteur. La distinction s’estompe.
• Tiered storage dans Kafka (Kafka 3.5+, 2024) : stocker les anciennes données sur S3/HDFS rend la rétention longue abordable.
• Matérialized views sur streams : des bases comme RisingWave ou Materialize transforment des flux en vues actualisées en continu, mélangeant idéalement stream et batch.
• Déclin de Lambda : les nouveaux projets en 2026 adoptent massivement Kappa, sauf contrainte particulière.

Articles connexes

Pour approfondir les sujets abordés dans cet article :