Architecture Lambda

L'architecture Lambda est une architecture de traitement de données conçue pour traiter des quantités énormes de données en tirant parti des méthodes de traitement par lots et de traitement de flux. Cette approche de l'architecture tente d'équilibrer la latence, le débit et la tolérance aux pannes en utilisant le traitement par lots pour fournir des vues complètes et précises des données par lots, tout en utilisant simultanément le traitement de flux en temps réel pour fournir des vues des données en ligne. Les deux sorties de vue peuvent être jointes avant la présentation. La montée en puissance de l'architecture lambda est corrélée à la croissance du big data, à l'analyse en temps réel et à la volonté d'atténuer les latences de MapReduce.

Flux de données à travers les couches de traitement et de traitement d'une architecture lambda générique

L'architecture Lambda repose sur un modèle de données avec une source de données immuable, en ajout uniquement, qui sert de système d'enregistrement. Il est destiné à l'acquisition et au traitement d'événements horodatés qui sont ajoutés aux événements existants au lieu de les écraser. L'état est déterminé à partir de l'ordre naturel des données basé sur le temps.

Vue d'ensemble

L'architecture Lambda est un système composé de trois couches: le traitement par lots, le traitement rapide (ou en temps réel) et une couche serveur pour répondre aux requêtes. Les couches de traitement acquièrent à partir d'une copie maîtresse immuable l'intégralité du jeu de données.

Couche batch

La couche de traitement par lots précalcule les résultats à l'aide d'un système de traitement distribué capable de traiter de très grandes quantités de données. La couche de traitement par lots vise une précision parfaite en permettant de traiter toutes les données disponibles lors de la génération de vues. Cela signifie qu’il peut corriger les erreurs en recalculant l’ensemble des données, puis en mettant à jour les vues existantes. La sortie est généralement stockée dans une base de données en lecture seule, les mises à jour remplaçant complètement les vues précalculées existantes.

Apache Hadoop est le système de traitement par lots standard de facto utilisé dans la plupart des architectures à haut débit.

Couche temps réel

Schéma montrant le flux de données à travers les couches de traitement et de desserte de l'architecture lambda. Des exemples de composants nommés sont montrés.

La couche temps réel traite les flux de données en temps réel et sans les exigences de correction ni de complétude. Cette couche sacrifie le débit car elle vise à minimiser le temps de latence en fournissant des vues en temps réel des données les plus récentes. Essentiellement, la couche temps réel est chargée de combler le "vide" causé par le retard de la couche de traitement par lot dans la fourniture de vues basées sur les données les plus récentes. Les vues de cette couche peuvent ne pas être aussi précises ni complètes que celles éventuellement produites par la couche de traitement par lot, mais elles sont disponibles presque immédiatement après la réception des données et peuvent être remplacées lorsque les vues de la couche batch deviennent disponibles.

Les technologies de traitement de flux généralement utilisées dans cette couche incluent Apache Storm, SQLstream, Apache Spark ou Apache Flink. La sortie est généralement stockée sur des bases de données NoSQL rapides.

Couche service

Diagramme illustrant une architecture lambda avec un magasin de données Druid.

La sortie des couches batch et couches temps réel est stockée dans la couche services, qui répond aux requêtes ad hoc en renvoyant des vues précalculées ou en construisant des vues à partir des données traitées.

Comme exemple de technologie utilisée dans la couche services on peut citer Apache Druid, qui fournit un seul cluster pour gérer la sortie des deux couches. Parmi les autres technologies pour la couche de service on pourra citer Apache Cassandra, Apache HBase, MongoDB, VoltDB ou Elasticsearch pour la sortie de la couche temps réel, et Elephant DB, Apache Impala, SAP HANA ou Apache Hive pour la sortie de couche Batch.

Optimisations

Pour optimiser l'ensemble de données et améliorer l'efficacité des requêtes, différentes techniques de cumul et d'agrégation sont exécutées sur des données brutes tandis que des techniques d'estimation sont utilisées pour réduire davantage les coûts de calcul. Et bien qu'un recalcul complet et coûteux soit nécessaire pour la tolérance aux pannes, des algorithmes de calcul incrémentaux peuvent être ajoutés de manière sélective pour augmenter l'efficacité, et des techniques telles que le calcul partiel et l'optimisation de l'utilisation des ressources peuvent efficacement aider à réduire le temps de latence.

Critique

La critique de l'architecture lambda s'est concentrée sur sa complexité inhérente et son influence limitante. Les côtés batch et streaming nécessitent chacun une base de code différente qui doit être gérée et synchronisée afin que les données traitées produisent le même résultat dans les deux chemins. Cependant, tenter de s'abstraire des bases de code dans un framework unique met hors de portée de nombreux outils spécialisés dans les écosystèmes batch et temps réel.

Lors d’une discussion technique sur les avantages de l’utilisation d’une approche de streaming pur, il a été noté que l’utilisation d’un framework de streaming flexible tel que Apache Samza pourrait offrir les mêmes avantages que le traitement par lots sans latence. Une telle structure de diffusion en continu pourrait permettre de collecter et de traiter des fenêtres de données de taille arbitraire, d’adapter le blocage et de gérer l’état.

Voir également

• Traitement du flux d'événements

Liens externes

• Dépôt d'informations sur Lambda d'architecture