De Lambda à Kappa : un guide des architectures big data en temps réel

De Lambda à Kappa : un guide des architectures big data en temps réel

Plusieurs options sont désormais disponibles en matière d'architecture big data en temps réel. L'architecture Lambda n'est plus la seule possibilité. Dans cette série d'articles, je vous présente deux de ces architectures, dont Lambda, et je vous propose un comparatif s'appuyant sur des cas d'utilisation concrets. Vous souhaitez savoir comment sélectionner la bonne architecture pour votre projet en temps réel ? C'est parti.

Les exigences du traitement en temps réel

Avant d'aborder la question de l'architecture, clarifions certaines exigences des systèmes de traitement des données en temps réel dans les scénarios de big data.

Le point le plus évident est que ces données sont en mouvement : elles n'ont pas de limites fixes et sont ininterrompues. Un critère essentiel est donc le moment où vous analysez ces données. Si vous souhaitez obtenir des réponses par rapport à un instantané des données, ou que vous avez des exigences spécifiques en termes de latence, vous avez besoin de données en temps réel.

De plus, vous avez sûrement des délais imposés par les besoins de votre entreprise. Après tout, si le non-respect des délais n'avait aucune conséquence lors des analyses en temps réel, alors les analyses pourraient être effectuées par lots. D'une simple détérioration du service à un échec total, ces conséquences peuvent être variées.

Dans le cadre des big data, il faut aussi prévoir de repousser les limites en matière de volume, de vitesse et peut-être même de types de données.

Le traitement de données en temps réel doit être évolutif, tolérant aux incidents, prévisible, résilient aux imperfections de flux et extensible.

De nouvelles architectures pour une nouvelle ère

Pour répondre à ces besoins, de nouvelles architectures ont logiquement été développées.

L'architecture Lambda, attribuée à Nathan Marz, est actuellement l'une des plus couramment utilisées pour le traitement des données en temps réel. Elle est conçue pour gérer les écritures et mises à jour avec une faible latence, en étant tolérante aux incidents et évolutive de façon linéaire.

Le flux de données entrant dans le système alimente à la fois la couche lot (batch) et la couche temps réel (speed).

La couche lot enregistre les données brutes entrantes et prépare les vues par lots. Ces processus par lots sont naturellement définis à des intervalles réguliers, et à long terme. Le périmètre des données s'étend de quelques heures à des années.

La couche temps réel produit les vues en temps réel, qui complètent les vues par lots.

Il est possible de faire une requête pour obtenir une vision d'ensemble en récupérant à la fois les données des vues par lots et celles des vues en temps réel. Toute requête peut ainsi bénéficier des avantages des deux modes de traitement. Les vues par lots peuvent être traitées avec des règles plus complexes ou plus chères, pour une meilleure qualité et moins d'asymétrie, tandis que les vues en temps réel donnent accès aux toutes dernières données. Le temps passant, les données en temps réel expirent et sont remplacées par les données des vues par lots.

Un avantage supplémentaire de cette architecture est qu'elle permet de repasser des données entrantes et de produire de nouvelles vues en cas de changement de code ou de formule.

La principale critique formulée à l'encontre de cette architecture est qu'elle impose de gérer deux systèmes distincts (et parfois complexes) pour générer les couches lot et temps réel. Heureusement, grâce à Spark Streaming (couche d'abstraction) ou Talend (générateur de code Spark Batch et Streaming), le problème est moindre… mais la charge opérationnelle subsiste.

Passons maintenant à l'architecture Kappa.

L'architecture Kappa a été décrite pour la première fois par Jay Kreps. Elle se concentre uniquement sur le traitement des données dans un flux. Elle n'a pas pour vocation de remplacer l'architecture Lambda, sauf pour certains cas d'utilisation précis. Dans cette architecture, le flux de données entrantes passe dans une couche temps réel. Les résultats sont disponibles dans la couche de service (serving) pour les requêtes.

Le principe est de gérer à la fois le traitement de données en temps réel et le retraitement continu dans un seul moteur de traitement de flux. Vous avez bien compris, le retraitement a lieu à partir du flux. Pour cela, le flux de données entrantes doit pouvoir être repassé (très rapidement), dans son ensemble ou à partir d'un point spécifique. En cas de changements de code, un second traitement de flux repasse toutes les données précédentes dans le dernier moteur temps réel et remplace les données enregistrées dans la couche de service.

Cette architecture a été pensée pour simplifier l'architecture Lambda, ne conservant qu'une seule base de code plutôt qu'une base pour chaque couche lot et temps réel. De plus, les requêtes doivent récupérer les résultats dans la seule couche de service, et n'ont pas à chercher dans les vues par lots et en temps réel.

La complexité de cette architecture réside dans le fait de devoir traiter les données dans un flux. Des opérations telles que la gestion d'événements dupliqués, le référencement croisé des événements ou le maintien de l'ordre sont plus faciles à effectuer dans le cadre d'un traitement par lots.

Un choix au cas par cas

Une architecture Lambda conviendra à la plupart des cas d'utilisation en temps réel. On ne peut pas en dire autant de l'architecture Kappa. Si les analyses par lots et par flux sont identiques, Kappa est sûrement la meilleure solution. Toutefois, dans certains cas, l'accès à un jeu de données complet dans une fenêtre lot peut apporter certains avantages, rendant une architecture Lambda plus performante et peut-être même plus simple à mettre en place.

Dans certaines situations complexes utilisant des modèles de machine learning, des systèmes experts ou des opérations très chères par nature devant être effectuées différemment en temps réel, les algorithmes par lots et par flux produisent des résultats très différents. Pour ces situations, une architecture Lambda est nécessaire.

Nous avons ainsi couvert les deux architectures de traitement des données en temps réel les plus populaires. Dans le prochain article de cette série, nous les étudierons plus en détail, en présentant des cas d'utilisation concrets et les technologies souvent utilisées.

Références :

« How to beat the CAP theorem » (Comment vaincre le théorème CAP) par Nathan Marz
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

« Questioning the Lambda Architecture » (Questionner l'architecture Lambda) par Jay Kreps
https://www.oreilly.com/ideas/questioning-the-lambda-architecture

« Big Data » par Nathan Marz, James Warren
https://www.manning.com/books/big-data

Participer aux discussions

0 Comments

Laisser un commentaire

Your email address will not be published. Required fields are marked *