Architecture Lambda

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

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.

Origine de Architecture Lambda

En 2011, dans son blog, Nathan Marz a présenté le concept Architecture Lambda réduire les latences inhérentes à MapReduce. Ce concept initial a été étendu au domaine du Big Data dans l’article de Nathan et James Warren, intitulé « Big Data : Principles and Best Practices of évolutif Data Systems », publié en 2013. En 2014, Jay Kreps a rédigé un article intitulé « Questioning the Architecture Lambda Rader, soulignant certains inconvénients qu’il avait mis en évidence chez LinkedIn et proposant des alternatives. Jay a proposé l’architecture kappa, plus simple, car elle utilise uniquement une streaming .

Pourquoi Architecture Lambda est-elle Architecture Lambda ?

Une approche purement par lots pour la récupération de données implique d'attendre la fin d'un lot avant de pouvoir interroger les données récupérées. Le traitement par lots présente avantage efficace en termes d'utilisation des ressources et d'offrir un débit élevé.

Le traitement en continu est moins efficace que le traitement par lots, mais offre une latence moindre, car les enregistrements sont récupérés dès leur création. Architecture Lambda l'instantanéité des données en continu avec le débit du traitement par lots, tout en renforçant la tolérance aux pannes en éliminant tout point de défaillance unique au niveau de la transmission. Les données sources restent inchangées et conservent donc leur caractère faisant autorité.

Les composants d'une Architecture Lambda

Vous trouverez ci-dessous un aperçu des principaux composants de Architecture Lambda.

Les données sources

La source des données brutes reste inchangée. Les transformations sont appliquées à une copie de l'original afin de garantir la traçabilité. Les streaming de traitement par lots et streaming utilisent le même jeu de données de base.

La couche de traitement par lots

La couche de traitement par lots génère des vues au fur et à mesure qu'elle traite l'intégralité d'un jeu de données. 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 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. En cas de défaillance, l'ensemble jeu de données être transmis en continu afin d'améliorer la disponibilité des données.

La couche de service

La couche de présentation est généralement une base de données qui prend en charge les requêtes de jointure entre les tables de sortie par lots 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, à condition que celui-ci prenne en charge de manière transparente un ensemble de résultats unifié faisant référence à la fois aux tables créées en continu et à celles créées par lots.

Les avantages de l'Architecture Lambda

Les principaux avantages de l'Architecture Lambda :

  • utilisateur voit utilisateur un jeu de données complet et transformé.
  • Les données sources sont immuables ; les ensembles de résultats peuvent donc toujours être recréés à partir de la source.
  • Aucun retard dans le traitement des dossiers, contrairement à une approche exclusivement par lots.
  • Les résultats intermédiaires peuvent être enregistrés, ce qui facilite le débogage du code en les utilisant comme piste d'audit.
  • L'utilisation de deux voies pour récupérer les données brutes garantit une haute disponibilité, car tant la voie par lots que la voie en continu permettent de générer un jeu de données cible complet jeu de données nécessaire.

Les inconvénients de Architecture Lambda

Le principal problème de Architecture Lambda sa complexité. Deux mécanismes distincts, chacun disposant de sa propre base de code, transfèrent les données d'une source vers une destination permettant d'effectuer des requêtes. Une table est dédiée aux données par lots, tandis que l'autre est réservée aux données en flux continu. Les requêtes doivent joindre ces tables, ce qui implique de filtrer les doublons et ralentit leur exécution. Les chemins streaming pour les données par lots et streaming doivent prendre en charge toute transformation des données.

Actian et la plateforme d'intelligence des données

La plateformeActianData Intelligencea été spécialement conçue pour aider les organisations à unifier, gérer et comprendre leurs données dans des environnements hybrides. Elle regroupe métadonnées , gouvernance, la traçabilité, le contrôle de la qualité et l'automatisation au sein d'une seule et même plateforme. Cela permet aux équipes de savoir d'où proviennent 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 insight en temps réel insight les structures et les 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 à replacer les données dans leur contexte métier, permettant ainsi aux équipes de les exploiter de manière plus efficace et responsable. La plateforme Actian est conçue pour s'adapter à l'évolution des écosystèmes de données, garantissant une utilisation cohérente, intelligente et sécurisée des données à l'échelle de l'entreprise.Demandez votre démonstration 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).