Architecture Lambda
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 restent 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 Architecture Lambda
La plateforme de données Actian peut fournir des capacités Architecture Lambda en utilisant une combinaison de pipelines en flux et par lots à partir du jeu de données source. La base de données en colonnes Vector intégrée inclut le stockage des tables chargées en flux et en lots, qui peuvent être interrogées à l'aide de jointures en langage de requête structuré (SQL) pour fournir une vue des enregistrements uniques des deux tables. La beauté de l'approche d'Actian réside dans le fait que les données chargées par lots et en continu utilisent le même code de transformation, ce qui garantit des résultats cohérents.
