Big data architectures

Architectures Big Data
Lambda et Kappa
Mariem Khalfaoui

5
Introduction
4
3
2
1
Composants logiques
Data Lake
Architecture Lambda
Architecture Kappa
Plan

 Une architecture Big Data est conçue pour gérer l’ingestion, le traitement et l’analyse de données
trop volumineuses ou complexes pour les systèmes de base de données traditionnels
 Le coût du stockage a considérablement diminué, tandis que les méthodes de collecte de ces
données ne cessent de se multiplier.
Données affluent à un
rythme très soutenu et
nécessitent une collecte et
une observation
permanentes.
Données affluent plus
lentement, mais sont très
volumineuses, et se présentent
souvent sous la forme d’un
historique couvrant plusieurs
dizaines d’années de données.
3

1. Traitement par lots
des sources Big Data
au repos.
2. Traitement en temps
réel des Big Data en
mouvement
3. Exploration interactive
des Big Data
4. Analyse prédictive et
apprentissage machine
Enjeux
4

2. Composant logiques
Le diagramme suivant montre les composants logiques qui constituent une architecture Big Data.
Certaines solutions individuelles ne contiennent pas tous les éléments de ce diagramme.
5

2.1. Sources de données (1/2)
6

 Magasins de données d’application, tels que des
bases de données relationnelles.
 Fichiers statiques produits par les applications, tels
que les fichiers journaux de serveur web.
 Sources de données en temps réel, tels que les
appareils IoT.
 Toutes les solutions Big Data reposent sur une ou plusieurs sources de
données:
2.1. Sources de données (2/2)
7

2.2. Stockage des données (1/2)
8

 Les données destinées aux opérations de traitement par lots sont généralement stockées dans
un magasin de fichiers distribués, qui peut contenir de vastes volumes de fichiers volumineux
dans divers formats. Ce type de magasin est souvent appelé « lac de données ».
 Les options pour l’implémentation de ce stockage incluent des conteneurs Azure Data Lake
Store ou les conteneurs blob dans le stockage Azure.
2.2. Stockage des données (2/2)
Fichiers Blocs Objet 9

2.3. Traitement par lots (1/2)
10

 Etant donné que les jeux de données sont trop lourds, une
solution Big Data doit souvent traiter les fichiers de données à
l’aide de traitements par lots à longue durée d’exécution pour
filtrer, agréger et préparer les données en vue de l’analyse.
 Généralement, ces travaux impliquent la lecture des fichiers
source, leur traitement et l’écriture de la sortie dans de
nouveaux fichiers.
 Les options incluent:
o l’exécution de travaux U-SQL dans Azure Data Lake
Analytics
o à l’aide de travaux personnalisés de mappage/réduction,
Pig ou Hive dans un cluster HDInsight Hadoop
o à l’aide des programmes Java, Scala ou Python dans un
cluster HDInsight Spark
2.3. Traitement par lots (2/2)
11

2.4. Ingestion de messages en temps réel (1/2)
12

 Si la solution inclut des sources en temps réel, l’architecture doit inclure un moyen pour capturer et stocker
des messages en temps réel pour le traitement de flux de données. Il peut s’agir d’un simple magasin de
données, où les messages entrants sont déposés dans un dossier en vue du traitement.
 Toutefois, de nombreuses solutions besoin d’un magasin d’ingestion des messages qui agit comme une
mémoire tampon pour les messages et qui prend en charge un traitement de montée en puissance, une
remise fiable et d’autres sémantiques de files d’attente de message. Cette partie d’une architecture de
diffusion est communément appelée mise en mémoire tampon du flux. (Azure Event Hubs, Azure IoT Hub
et Kafka)
2.4. Ingestion de messages en temps réel (2/2)
13

2.5. Traitement de flux (1/2)
14

 Après avoir capturé les messages en temps réel, la solution doit les traiter en filtrant, en agrégeant et,
plus généralement, en préparant les données pour l’analyse. Les données de flux traitées sont ensuite
écrites dans un récepteur de sortie.
 Azure Stream Analytics fournit un service de traitement de flux managé reposant sur des
requêtes SQL à l’exécution permanente qui fonctionnent sur les flux de données indépendants. Vous
pouvez également utiliser des technologies de flux Apache open source comme Storm et Spark dans
un cluster HDInsight.
2.5. Traitement de flux (2/2)
15

2.6. Magasin de données analytique (1/2)
16

 Les données peuvent également être présentées via une technologie NoSQL à faible
latence, telle que HBase, ou via une base de données Hive interactif qui fournit une
abstraction de métadonnées sur les fichiers de données dans le magasin de données
distribuées.
 Azure Synapse Analytics fournit un service managé pour l’entreposage cloud des
données à grande échelle. HDInsight prend en charge les formats Hive interactif, HBase
et Spark SQL, qui peuvent également servir à préparer les données en vue de l’analyse.
2.6. Magasin de données analytique (2/2)
 De nombreuses solutions Big Data préparent les données pour l’analyse, puis fournissent les
données traitées dans un format structuré qui peut être interrogé à l’aide des outils
d’analyse. Le magasin de données analytique utilisé pour répondre à ces requêtes peut être
un entrepôt de données relationnelles, comme indiqué dans les solutions décisionnelles (BI)
plus traditionnelles.
17

2.7. Analyse et rapports (1/2)
18

 La plupart des solutions Big Data ont pour but de fournir des informations sur les données par le biais de
l’analyse et des rapports.
 Pour permettre aux utilisateurs d’analyser les données, l’architecture peut inclure une couche de modélisation
des données, comme un cube OLAP multidimensionnel ou un modèle de données tabulaire dans Azure Analysis
Services.
2.7. Analyse et rapports (2/2)
19

20
 Elle peut également prendre en charge le décisionnel libre-service, en
utilisant les technologies de modélisation et de visualisation de
Microsoft Power BI ou Microsoft Excel.
 L’analyse et les rapports peuvent aussi prendre la forme d’une exploration interactive des données par les
scientifiques de données ou les analystes de données.
 Pour ces scénarios, plusieurs services Azure prennent en charge les blocs-notes analytiques, tels que
Jupyter, ce qui permet à ces utilisateurs de tirer parti de leurs connaissances avec Python ou R. Pour
l’exploration de données à grande échelle, vous pouvez utiliser Microsoft R Server seul ou avec Spark.

 La plupart des solutions Big Data consistent en des opérations de
traitement de données répétées, encapsulées dans des workflows, qui
o transforment les données source
o déplacent les données entre plusieurs sources et récepteurs
o chargent les données traitées dans un magasin de données
analytique
o envoient les résultats directement à un rapport ou à un tableau de
bord.
 Pour automatiser ces workflows, vous pouvez utiliser une technologie
d’orchestration telle qu’Azure Data Factory ou Apache Oozie avec Sqoop.
2.8. Orchestration (2/2)
22

23
3. Data lake:
Transformation
et raffinement des données

3. Le Datalake (1/4)
 Le Datalake (ou lac de données) est une architecture apparue avec les technologies Big Data, permettant
le stockage de gros volumes de données.
 Le Datalake offre aux entreprises un système de stockage permettant d’accueillir tous types de
données (brutes ou non) qu’elles soient structurées, semi-structurées et/ou non structurées. Cette
architecture big data permet ainsi une transformation et un raffinement rapide des données
stockées, que le volume traité soit important ou non.
24

26
 Bien que n’étant pas le seul, Hadoop reste le framework de référence le plus utilisé pour la construction
d’un Datalake.
 Pour rappel Hadoop est composé de quatre modules : HDFS, common, YARN, MapReduce
 Les données peuvent provenir de multiples sources comme des logs, des services web, etc. Les
différents systèmes d’ingestion consommeront les données pour ensuite les insérer dans le Datalake
(HDFS). Une fois que les données sont enregistrées, les systèmes d’interrogations pourront alors
interroger le Datalake

 Jeux de données très volumineux: l'exécution des requêtes des clients peut prendre beaucoup de temps.
 Requêtes ne peuvent pas être effectuées en temps réeldes algorithmes comme MapReduce (En parallèle)
27

 L’inconvénient de cette approche est qu’elle entraîne une latence — si le traitement dure quelques heures,
une requête peut donc retourner des résultats datant de plusieurs heures.
 Dans l’idéal, vous devez obtenir des résultats en temps réel (malgré une certaine perte de précision) et
combiner ces résultats avec ceux de l’analyse en mode batch.
28
Figure: Traitements en lots par MapReduce

 La Lambda Architecture est un patron d’architecture logicielle décrit par Nathan Marz
Elle vise à traiter les données massives en temps réel, tout en assurant un résultat exact à l’issue de ces
traitements. Pour cela, la Lambda est composée de trois couches (layers) : la Batch layer, la Serving layer et la
Speed layer
4.1. Principe:
-Le principe général est le suivant : la Batch layer permet de fournir périodiquement une vue exacte sur les
données, mais avec un temps de traitement ou de transformation important.
-La Serving layer met ensuite ces vues à disposition des utilisateurs, avec pour objectif d’optimiser l’accès aux
données. La Speed layer sert à compenser le temps de traitement de la Batch layer, en proposant un traitement
des données en temps réel, mais sans garantir l’exactitude des résultats.
Contrairement au Datalake qui sert essentiellement au stockage, l’architecture Lambda permet de
fusionner le traitement par bloc de données (batch) et les nouvelles données entrées (temps réel).
4. Architecture Lambda :
30

4.2. Composant:
Couche batch (Batch Layer) :
 La Batch layer a deux rôles principaux :
1) stocker les nouvelles données sous un format brut
2) réaliser des calculs, des transformations de modèles sur ces données.
 Le stockage des données brutes ne se fait pas sous la forme d’états mais sous la forme d’une
suite d’événements ou de messages qui permettent d’obtenir un état actualisé des différents
éléments lorsque ces évènements sont traités dans leur ensemble.
 Stockage: le master dataset (un entrepôt permanent de données brutes)
 Les calculs et les transformations de modèles sont opérés à partir du master dataset, souvent
de manière distribuée afin de garantir le passage à l’echelle
32
4. Architecture Lambda:

Couche temps réel (Speed Layer) :
 Traite tout type de donnée reçu en temps réel
 Calcul des vues incrémentales qui vont compléter les vues batch afin de fournir des données plus
récentes
 Suppression des vues temps réel obsolètes (postérieures à un traitement batch)
Couche de service (Serving Layer) :
 La Serving layer se charge ensuite de récupérer les résultats de ces traitements et les met à la disposition
des utilisateurs.
 Le but étant d’optimiser le temps d’accès, la modélisation des données est réalisée dans ce sens (utilisation
des index, schéma non normalisé, etc.)
 Adapté à tous types de bases NoSQL
33
4. Architecture Lambda:

34
4.3. Le processing (1/2)
 Stream processing:
 paradigme de programmation utile lorsque les résultats de l'analyse sont nécessaires en temps réel.
 Fait référence à l'interrogation des données en continu
 détecte rapidement les
conditions dans un petit
intervalle de temps à partir
du moment de la réception
des données. C'est la
méthode de traitement des
données en mouvement.
 permet d'alimenter les
données dans les outils
d'analyse dès qu’elles sont
générées et donc obtenir des
résultats d'analyse
instantanés Stream processing

35
4.3. Le processing (2/2)
 Batch processing:
 moyen efficace de traiter un grand volume de données, où un groupe de transactions est
collecté sur une période de temps.
 Une approche d'exploration de données (data mining).
 Les données sont collectés, saisies, traitées puis les résultats des lots sont produits.
 Cela fonctionne bien dans les cas où vous n'avez pas besoin de résultats d'analyse en
temps réel, et quand il est plus important de traiter de gros volumes de données pour
obtenir plus d’informations détaillées que pour obtenir des résultats d'analyse rapides.
 Il génère des résultats avec des prédictions statiques

37
4.5. Avantages de l'architecture Lambda (1/2)
 Équilibré et flexible : cette architecture maintient un équilibre entre le temps réel et la fiabilité: la garantie
d’un résultat correct avec la Batch layer et la faible latence avec la Speed layer.
 C'est une architecture simple à comprendre et suffisamment flexible à maintenir.
 Données immuables : les données transmises à la couche de traitement par lots proviennent souvent d'une
source de données immuable, ce qui signifie que les données transmises ne peuvent pas être mises à jour ou
supprimées.
 Idéal pour l'analyse commerciale : en raison de l'immuabilité des données, les données stockées dans les
vues par lots peuvent être utilisées pour l'analyse commerciale car elles peuvent donner de meilleures
informations. À mesure que de nouvelles mises à jour par lots sont disponibles, les utilisateurs pourront
afficher à la fois les anciennes données et les nouvelles. Cela permet une meilleure analyse des données.

38
 Possibilité d’améliorer l'algorithme d'extraction : nous pouvons améliorer l'algorithme
d'extraction de données et l'appliquer sur l'ancien ensemble de données. Ceci est extrêmement
utile dans les environnements agiles et de démarrage.
 Tolérance aux pannes : les données qui entrent pour le traitement en temps réel sont
modifiables et il existe des risques de corruption ou de perte de données en raison d'erreurs
humaines ou d'application ; cependant, étant donné que les données sont également traitées par
lots, elles sont toujours conservées à la fin. Nous pouvons perdre l'analyse en temps réel, mais
le traitement par lots peut aider à récupérer les données et à effectuer une analyse à l'avenir.
4.5. Avantages de l'architecture Lambda (2/2)

Project Promotion Mechanism
Keyword
Dénormalisation
des données
Immuabilité des
données
Vues
précalculées
La capacité du modèle d'architecture lambda à concevoir des systèmes hautement évolutifs et capables
d’offrir des temps de réponse courts sur un grand volume de données repose sur les concepts suivants
4.6. Caractéristiques et fonctionnement de l’architecture LAMBDA

40
1. L’immuabilité des données
 Les données sont traitées de manière que les enregistrements ne puissent jamais être modifiés ou
supprimés
 Le concept permet seulement de créer et lire des enregistrements (CR) au lieu de pouvoir en plus
mettre à jour et supprimer des enregistrements (CRUD) comme dans les bases de données
relationnelles.
 Ainsi, les opérations d'écriture ne font qu'ajouter de nouvelles unités de données.
 « Scalability »: Donneés très facile à distribuer et répliquer
 Le système de données lui-même devient une sorte de système de journalisation: A l’apparition de
nouvelles données, ajoute un horodatage (timestamp) et un identifiant unique à cet enregistrement
de données qui est puis enregistré dans le magasin de données.
 Inconvénient: Plus des données sont générées et plus la réponse aux requêtes devient difficile.

41
Détection d’une nouvelle entrée dans un modèle de data « mutable »
Détection d’une nouvelle entrée dans un modèle de data « immutable »

42
2. Dénormalisation des données
 La manière normalisée de stockage des données est la cause principale de la capacité limitée des systèmes de
bases de données traditionnels à adapter leurs performances de lecture à d'énormes quantités de données
 Afin de faciliter la cohérence, les schémas sont conçus de telle sorte que les informations ne soient pas
dupliquées. De cette façon, le problème qu'une même information doit être mise à jour à plusieurs endroits
n'apparaît pas.
 Cependant, afin de rassembler les informations nécessaires pour répondre à des requêtes complexes, des
opérations de jointure coûteuses doivent être calculées la plupart du temps.
 Pour des raisons de performances, les systèmes de Big Data acceptent une dénormalisation du schéma de
données de telle sorte que les données soient stockées dans une représentation équivalente à celle après
avoir effectué des jointures sur des tables normalisées.
C'est fondamentalement plus simple que d'utiliser des jointures, aucune connaissance du schéma n'est
nécessaire et c'est beaucoup plus rapide car toutes les informations associées sont déjà en place.

43
3. Vues précalculées:
 Afin d'être en mesure de donner des réponses rapides et cohérentes aux requêtes portant sur d'énormes
quantités de données, les vues précalculées sont préparées à la fois dans la couche batch et dans la couche
speed.
 Application de la fonction batch à toutes les données  une transformation des données sous une forme plus
compacte adaptée pour répondre à un ensemble prédéfini de requêtes.
Traitement rapide grâce aux vues précalculées

44
Exemple: Aggrégation de données pour une plage de temps donnée

45
 La vue batch calculée par la fonction batch n'est mise à jour qu'après chaque nouvelle
exécution du traitement par lots ce qui peut prendre plus de temps.
 L'écart pour inclure les dernières l'information est comblé par une seconde vue précalculée, la
« speed view » qui est préparée dans la couche de vitesse. Les requêtes sont ensuite résolues en
combinant les deux précalculés vues.

48
5. Architecture Kappa
5.1. Composants
 C’est autre patron qui adopte une vision différente de la Lambda Architecture.
 Elle peut être vue comme une simplification dans le sens où elle considère que tous les traitements opèrent sur
des flux (everything is a stream).
 Ne permettant pas le stockage de manière permanente, cette architecture est faite pour le traitement de donnée.

49
 plutôt que d’avoir une couche Batch et une couche Speed, il est possible de conserver uniquement une
seule couche Speed et d’organiser les flux.
 Pour ce faire, les données doivent être conservées sous la forme d’une suite de messages (logs).

50
Les journaux unifiés sont des entrées des journaux de trafic, de menace, de filtrage d'URL, de
soumissions WildFire et de filtrage de données affichées dans une seule vue
La vue unifiée du journal vous permet d'étudier et de filtrer les dernières entrées de différents
types de journaux en un seul endroit, au lieu de rechercher séparément chaque type de journal.
La vue du journal unifié affiche uniquement les entrées des journaux que vous êtes autorisé à
consulter.
Un administrateur qui n'a pas l'autorisation
d'afficher les journaux des soumissions WildFire ne
verra pas les entrées du journal des soumissions
WildFire lors de l'affichage des journaux unifiés. Les
types de rôles administratifs définissent ces
autorisations.

Cooperation for a Win-Win Future
Traitements
• Storm, Spark
Stockage/temps réel
•Kafka permet la sauvegarde des messages
pour pouvoir ensuite les retraiter
Couche de service
• Cassandra, Hive, HBase, Outil
maison, etc
5.2. Implémentation

52
 La Kappa permet d’éviter la complexité de la Lambda
 la couche de traitement par lots de l’architecture lambda, dans la mesure où les données des
événements restent immuables et sont collectées dans leur totalité et non comme un sous-
ensemble
5.3. Avantages et inconvénients de l'architecture Kappa
 Comme pour la couche vitesse de l’architecture lambda: vue en temps réel.
 Si vous avez besoin de recalculer la totalité du jeu de données (comparable à ce que fait la
couche de traitement par lots dans l’architecture lambda), il vous suffit de relancer le flux,
généralement en utilisant un parallélisme pour effectuer le calcul en temps opportun.
 Mais ne conserve pas sa capacité de résistance aux pannes
 Ne permet pas non plus d’élargir les cas d’utilisation possibles et d’inclure les analyses exploratoires.

53
• Data traffic controller : ordonne et
réalise des transformations légères
sur les flux de données sources
• Master dataset : conserve les
données brutes, et les rend
accessibles en cas de besoin
• Streaming ETL : insère les données
qu’il reçoit en flux dans le storage
component
• Real-time insights : calcul des indicateurs prédéfinis en temps réel directement sur le flux de données Storage
component : conserve et met à disposition les données pour les analyses exploratoires
Solution: Architecture Lambda+

54
Le composant storage
L’implémentation de ce composant peut se faire
différemment en fonction des besoins
conduisant à l’architecture, par exemple avec un
data warehouse ou un data lake.
Alimenté par le composant streaming ETL, et
éventuellement par le composant real-time
insights.
Son rôle est de mettre les données à disposition
des utilisateurs, dans un modèle favorisant les
analyses exploratoires.

55
 Conservation de la capacité de résistance aux pannes de la Lambda Architecture, tout en
supprimant la duplication des traitements :
 le master dataset conserve les données brutes l’extraction permettant de relancer le
traitement en cas de besoin renvoie les données vers le composant de streaming ETL
 Gain de flexibilité : les analyses exploratoires permettent de trouver de nouveaux traitements
pour extraire des indicateurs pertinent en temps réel

57
http://index-of.co.uk/Big-Data-
Technologies/Big%20Data%20Principles%20and%20Best%20Practices%20
of%20Scalable%20Realtime%20Data%20Systems%20by%20Nathan%20Ma
rz%20%20WITH%20%20James%20Warren(pradyutvam2)%5BCPU.pdf

58
Références bibliographiques
Big Data. (s. d.). Manning Publications. Consulté 25 octobre 2021, à l’adresse https://www.manning.com/books/big-data
Architecture Big Data Lambda : Une approche agnostique | agileDSS. (s. d.). Consulté 19 octobre 2021, à l’adresse
https://agiledss.com/blogue/architecture-big-data-lambda-une-approche-agnostique
Architecture Lambda, Kappa ou Datalake : Comment les exploiter ? (2018, octobre 16). Cyrès.
https://www.cyres.fr/blog/architecture-lambda-big-data/
Bâtir un datalake sur AWS : Quelles solutions ? – Gekko. (s. d.). Consulté 23 octobre 2021, à l’adresse
https://www.gekko.fr/batir-un-datalake-sur-aws-quelles-solutions/
Cazton. (s. d.). Lambda Architecture—Spark & Hadoop | Cazton. Consulté 19 octobre 2021, à l’adresse
https://cazton.com/consulting/enterprise/lambda-architecture
Data Lake vs Data Warehouse vs Data Mart. (2018, février 6). The Holistics Blog. https://www.holistics.io/blog/data-
lake-vs-data-warehouse-vs-data-mart/

59
Fig 2.Lambda Architecture in Big Data. (s. d.). ResearchGate. Consulté 19 octobre 2021, à l’adresse
https://www.researchgate.net/figure/Lambda-Architecture-in-Big-Data_fig2_340619604
Fineberg, S. (2013). Big DaPtRaESSEtNoTArTaIOgNeTOITLpEtGioOEnSsHEfoREr Hadoop. 44.
Gillet, A., Leclercq, É., & Cullot, N. (s. d.). Lambda+ Architecture—Un patron d’architecture haute performance pour le
traitement des Big Data. 22.
Gillet, A., Leclercq, É., & Cullot, N. (2021). Évolution et formalisation de la Lambda Architecture pour des analyses à hautes
performances—Application aux données de Twitter. Revue ouverte d’ingénierie des systèmes d’information, 2(1).
https://doi.org/10.21494/ISTE.OP.2021.0606
Gupta, R. (2021, février 10). An overview of Azure Data Lake Analytics and U-SQL. SQL Shack - Articles about Database
Auditing, Server Performance, Data Recovery, and More. https://www.sqlshack.com/an-overview-of-azure-data-lake-
analytics-and-u-sql/
Kundu, A., & Solanki, A. (2020). Big Data Report Big Data Architecture in Healthcare : A Scalable, Fault-Tolerant Approach.
https://doi.org/10.13140/RG.2.2.26388.86401

60
Marz, N., & Warren, J. (2015). Big data : Principles and best practices of scalable real-time data systems. Manning.
Mikroyannidis, A. (s. d.). The Lambda Architecture.
(PDF) Big Data Analytics for Real Time Systems. (s. d.). Consulté 19 octobre 2021, à l’adresse
https://www.researchgate.net/publication/304078196_Big_Data_Analytics_for_Real_Time_Systems
Ph.D, I. S. (2021, juin 16). A brief introduction to two data processing architectures—Lambda and Kappa for Big Data.
Medium. https://towardsdatascience.com/a-brief-introduction-to-two-data-processing-architectures-lambda-and-
kappa-for-big-data-4f35c28005bb
Real-Time Big Data Analytics : A Comprehensive Guide. (s. d.). Consulté 19 octobre 2021, à l’adresse
https://www.scnsoft.com/blog/real-time-big-data-analytics-comprehensive-guide
Stockage en mode fichier, bloc ou objet ? (s. d.). Consulté 20 octobre 2021, à l’adresse
https://www.redhat.com/fr/topics/data-storage/file-block-object-storage
tamram. (s. d.). Introduction au Stockage (d’objets) Blob—Azure Storage. Consulté 20 octobre 2021, à l’adresse
https://docs.microsoft.com/fr-fr/azure/storage/blobs/storage-blobs-introduction

61
Taras Matyashovsky. (12:58:17 UTC). Lambda Architecture with Apache Spark.
https://www.slideshare.net/tmatyashovsky/lambda-architecture-with-apache-spark
Unified Logs. (s. d.). Consulté 19 octobre 2021, à l’adresse https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-
admin/monitoring/view-and-manage-logs/log-types-and-severity-levels/unified-logs.html

Merci pour votre
Attention
Architectures
Big Data

Big data architectures

Contenu connexe

Tendances

Similaire à Big data architectures

Big data architectures

Notes de l'éditeur