Architecture Lambda

Deux hommes discutent de l'Architecture Lambda en regardant un ordinateur portable.

Architecture Lambda combine le traitement des données par lots et par flux pour fournir une faible latence et une vue précise des données opérationnelles basées sur le temps.

Origine de l'Architecture Lambda

En 2011, Nathan Marz a introduit dans son blog l'idée d'Architecture Lambda pour réduire les latences inhérentes à MapReduce. Le concept original a été élargi au Big Data dans l'article de Nathan et James Warren, Big Data : Principles and Best Practices of évolutif Realtime Data Systems, publié en 2013 par Nathan et James Warren. En 2014, Jay Kreps a écrit un article sur la remise en question de l'Architecture Lambda dans Rader, soulignant certains inconvénients qu'il a découverts chez LinkedIn et proposant des alternatives. Jay a proposé l'architecture kappa, plus simple, parce qu'elle n'utilise qu'une approche de streaming .

Pourquoi l'Architecture Lambda est-elle importante ?

Une approche purement basée sur le traitement par lots pour l'extraction de données doit attendre la fin d'un lot avant que les données extraites puissent être interrogées. Le traitement par lots présente l'avantage d'être efficace en termes de ressources et d'offrir un débit élevé.

Le traitement en flux est moins efficace que le traitement par lots, mais offre moins de latence car les enregistrements sont récupérés dès qu'ils sont créés. L'Architecture Lambda offre l'immédiateté des données de flux avec le débit du traitement par lots et ajoute un niveau de tolérance aux pannes en supprimant un point unique de défaillance de la transmission. Les données sources sont inchangées et font donc toujours autorité.

Les composants d'une Architecture Lambda

Vous trouverez ci-dessous une vue d'ensemble des principaux composants de l'Architecture Lambda.

Les données sources

La source de données brutes ne change pas. Les transformations sont appliquées à une copie de l'original afin de maintenir l'auditabilité. Les chemins d'accès par lots et en streaming utilisent le même jeu de données base.

Le calque de lot

La couche de traitement par lots génère des vues au fur et à mesure qu'elle transforme un jeu de données complet. Ces vues peuvent être recalculées en cas d'erreurs ou de modifications du code.

La couche de vitesse

La couche de vitesse utilise le traitement en continu pour combler les intervalles de temps pendant l'exécution d'une mise à jour par lots. Lorsque le lot suivant est terminé, les données antérieures peuvent être effacées. En cas de défaillance, l'ensemble du jeu de données peut être transmis en continu afin d'accroître la disponibilité des données.

La couche de service

La couche de service est généralement une base de données qui prend en charge les requêtes conjointes sur les tables de sortie par lot et en continu afin de fournir une vue unique et cohérente du jeu de données transformé. L'architecture n'impose pas de base de données ou de système de fichiers spécifique, pour autant qu'elle prenne en charge de manière transparente un ensemble de résultats unifié qui fait référence à la fois aux tables créées par lots et aux tables créées par flux.

Les avantages de l'Architecture Lambda

Les principaux avantages de l'Architecture Lambda sont les suivants :

  • L'utilisateur voit toujours un jeu de données complet et transformé.
  • Les données sources sont immuables, de sorte que les ensembles de résultats peuvent toujours être recréés à partir de la source.
  • Aucun retard dans les enregistrements, contrairement à une approche par lots uniquement.
  • Les résultats intermédiaires peuvent être stockés, ce qui facilite le débogage du code en les utilisant comme piste d'audit.
  • L'utilisation de deux chemins pour obtenir les données brutes crée une haute disponibilité, car le chemin batch ou le chemin streamed peut créer un jeu de données cible complet en cas de besoin.

Les inconvénients de l'Architecture Lambda

Le principal problème de l'Architecture Lambda est sa complexité. Deux mécanismes différents, chacun avec sa propre base de code, déplacent les données d'une source vers une destination qui prend en charge les requêtes. Une table est dédiée aux données par lot, et l'autre aux données à la vapeur. Les requêtes doivent joindre ces tables, en filtrant les doublons, ce qui les rend plus lentes. Les chemins de code batch et streaming doivent appliquer toute transformation de données.

Actian et la plate-forme d'intelligence des données

Actian Data Intelligence Platform est conçue pour aider les entreprises à unifier, gérer et comprendre leurs données dans des environnements hybrides. Elle rassemble la gestion des métadonnées , la gouvernance, le lignage, le contrôle de la qualité et l'automatisation en une seule plateforme. Les équipes peuvent ainsi savoir d'où viennent les données, comment elles sont utilisées et si elles répondent aux exigences internes et externes.

Grâce à son interface centralisée, Actian offre une insight en temps réel des structures et des flux de données, ce qui facilite l'application des politiques, la résolution des problèmes et la collaboration entre les services. La plateforme aide également à relier les données au contexte commercial, ce qui permet aux équipes d'utiliser les données de manière plus efficace et plus responsable. La plateforme d'Actian est conçue pour s'adapter à l'évolution des écosystèmes de données, favorisant une utilisation cohérente, intelligente et sécurisée des données dans l'ensemble de l'entreprise. Demandez votre démo personnalisée.

FAQ

Architecture Lambda le traitement des données par lots et en continu afin d'offrir une faible latence une vision précise des données opérationnelles temporelles.

Nathan Marz a présenté Architecture Lambda 2011 afin de réduire les temps de latence inhérents à MapReduce, puis a étendu ce concept au Big Data avec James Warren dans leur article publié en 2013.

Parmi les avantages, on peut citer le fait que les utilisateurs voient toujours un jeu de données entièrement transformé, l'absence totale de retard au niveau des enregistrements, la possibilité de recréer les résultats à partir de données sources immuables, un débogage facilité grâce aux résultats intermédiaires enregistrés, ainsi qu'une haute disponibilité assurée par des chemins de données doubles.

La source des données brutes reste inchangée afin de garantir la traçabilité ; les transformations sont appliquées à une copie de l'original, de sorte que les ensembles de résultats puissent toujours être recréés à partir de la source.

Le principal problème réside dans la complexité du système, qui nécessite deux bases de code distinctes pour le transfert des données, des tables séparées pour les données traitées par lots et les données en flux continu, ainsi que des requêtes qui doivent joindre des tables tout en filtrant les doublons.

Architecture Lambda à la fois streaming par lots et streaming , tandis que l'architecture Kappa, proposée par Jay Kreps en 2014, est plus simple et ne recourt qu'à une streaming .

 

La couche de vitesse utilise le traitement en continu pour combler les lacunes temporelles pendant l'exécution d'une mise à jour par lots ; une fois le lot suivant terminé, les données antérieures peuvent être effacées.

Ces trois couches sont la couche de traitement par lots (qui génère des vues en transformant jeux de données complets), la couche de vitesse (qui utilise le traitement en continu pour combler les lacunes temporelles lors des mises à jour par lots) et la couche de diffusion (qui joint les tables de sortie issues du traitement par lots et du traitement en continu afin de fournir une vue unifiée).