SlideShare une entreprise Scribd logo
1  sur  63
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.
2.8. Orchestration (1/2)
21
 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
25
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
3. Le Datalake (2/4)
 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
3. Le Datalake (3/4)
 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
3. Le Datalake (4/4)
Figure: Traitements en lots par MapReduce
29
4. Architecture Lambda
 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
31
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
4.4. Implémentation:
36
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.
46
47
5. Architecture Kappa
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
56
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
63
Retour

Contenu connexe

Tendances

Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
ebiznext
 

Tendances (20)

BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all together
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
 
Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
 
BigData_TP4 : Cassandra
BigData_TP4 : CassandraBigData_TP4 : Cassandra
BigData_TP4 : Cassandra
 
Introduction au big data
Introduction au big dataIntroduction au big data
Introduction au big data
 
TP2 Big Data HBase
TP2 Big Data HBaseTP2 Big Data HBase
TP2 Big Data HBase
 
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er coursBases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
 
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
 
Chapitre 3 spark
Chapitre 3 sparkChapitre 3 spark
Chapitre 3 spark
 
Projet BI - 1 - Analyse des besoins
Projet BI - 1 - Analyse des besoinsProjet BI - 1 - Analyse des besoins
Projet BI - 1 - Analyse des besoins
 
Cours Big Data Chap2
Cours Big Data Chap2Cours Big Data Chap2
Cours Big Data Chap2
 
Architectures distribuées
Architectures distribuéesArchitectures distribuées
Architectures distribuées
 
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka StreamsTraitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
 
Cours Big Data Chap6
Cours Big Data Chap6Cours Big Data Chap6
Cours Big Data Chap6
 
Cours Big Data Part I
Cours Big Data Part ICours Big Data Part I
Cours Big Data Part I
 
Une introduction à Hive
Une introduction à HiveUne introduction à Hive
Une introduction à Hive
 
Chapitre 2 hadoop
Chapitre 2 hadoopChapitre 2 hadoop
Chapitre 2 hadoop
 
Bi
BiBi
Bi
 
BigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-ReduceBigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-Reduce
 
Cours Big Data Chap3
Cours Big Data Chap3Cours Big Data Chap3
Cours Big Data Chap3
 

Similaire à Big data architectures

Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
CERTyou Formation
 

Similaire à Big data architectures (20)

LP_Admin_base_données.ppt
LP_Admin_base_données.pptLP_Admin_base_données.ppt
LP_Admin_base_données.ppt
 
Delta lake - des data lake fiables a grande échelle
Delta lake - des data lake fiables a grande échelleDelta lake - des data lake fiables a grande échelle
Delta lake - des data lake fiables a grande échelle
 
Livre blanc data-lakes converteo 2018
Livre blanc data-lakes converteo 2018Livre blanc data-lakes converteo 2018
Livre blanc data-lakes converteo 2018
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 
Administration des base de donnees sous oracle 10g
Administration des base de donnees sous oracle 10g Administration des base de donnees sous oracle 10g
Administration des base de donnees sous oracle 10g
 
BlueData EPIC datasheet (en Français)
BlueData EPIC datasheet (en Français)BlueData EPIC datasheet (en Français)
BlueData EPIC datasheet (en Français)
 
Slides Edataday2021_V2.pdf
Slides Edataday2021_V2.pdfSlides Edataday2021_V2.pdf
Slides Edataday2021_V2.pdf
 
SAS Forum Soft Computing Théâtre
SAS Forum Soft Computing ThéâtreSAS Forum Soft Computing Théâtre
SAS Forum Soft Computing Théâtre
 
P8 03 presentation
P8 03 presentationP8 03 presentation
P8 03 presentation
 
Big Data Visualization PowerPoint Templates.pptx
Big Data Visualization PowerPoint Templates.pptxBig Data Visualization PowerPoint Templates.pptx
Big Data Visualization PowerPoint Templates.pptx
 
Spark SQL principes et fonctions
Spark SQL principes et fonctionsSpark SQL principes et fonctions
Spark SQL principes et fonctions
 
Distributed computing with Spark 2.x
Distributed computing with Spark 2.xDistributed computing with Spark 2.x
Distributed computing with Spark 2.x
 
Architectures bigdata
Architectures bigdataArchitectures bigdata
Architectures bigdata
 
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
 
Presentation du SGBD Oracle DATABASE.pptx
Presentation du SGBD Oracle DATABASE.pptxPresentation du SGBD Oracle DATABASE.pptx
Presentation du SGBD Oracle DATABASE.pptx
 
Petit-déjeuner OCTO : Hadoop, plateforme multi-tenant, à tout d'une grande !
Petit-déjeuner OCTO : Hadoop, plateforme multi-tenant, à tout d'une grande !Petit-déjeuner OCTO : Hadoop, plateforme multi-tenant, à tout d'une grande !
Petit-déjeuner OCTO : Hadoop, plateforme multi-tenant, à tout d'une grande !
 
Bidirectional Encoder Representations from Transformers
Bidirectional Encoder Representations from TransformersBidirectional Encoder Representations from Transformers
Bidirectional Encoder Representations from Transformers
 
11 visual basic .net - acces aux donnees avec ado .net
11 visual basic .net - acces aux donnees avec ado .net11 visual basic .net - acces aux donnees avec ado .net
11 visual basic .net - acces aux donnees avec ado .net
 
Base donnes my_sql
Base donnes my_sqlBase donnes my_sql
Base donnes my_sql
 
Discovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data VirtualizationDiscovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data Virtualization
 

Big data architectures

  • 1. Architectures Big Data Lambda et Kappa Mariem Khalfaoui
  • 3.  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
  • 4. 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
  • 5. 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
  • 6. 2.1. Sources de données (1/2) 6
  • 7.  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
  • 8. 2.2. Stockage des données (1/2) 8
  • 9.  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
  • 10. 2.3. Traitement par lots (1/2) 10
  • 11.  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
  • 12. 2.4. Ingestion de messages en temps réel (1/2) 12
  • 13.  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
  • 14. 2.5. Traitement de flux (1/2) 14
  • 15.  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
  • 16. 2.6. Magasin de données analytique (1/2) 16
  • 17.  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
  • 18. 2.7. Analyse et rapports (1/2) 18
  • 19.  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. 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.
  • 22.  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. 23 3. Data lake: Transformation et raffinement des données
  • 24. 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
  • 25. 25
  • 26. 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 3. Le Datalake (2/4)
  • 27.  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 3. Le Datalake (3/4)
  • 28.  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 3. Le Datalake (4/4) Figure: Traitements en lots par MapReduce
  • 30.  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
  • 31. 31
  • 32. 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:
  • 33. 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. 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. 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. 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. 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)
  • 39. 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. 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. 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. 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. 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. 44 Exemple: Aggrégation de données pour une plage de temps donnée
  • 45. 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.
  • 46. 46
  • 48. 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. 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. 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.
  • 51. 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. 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. 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. 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. 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
  • 56. 56
  • 58. 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. 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. 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. 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

Notes de l'éditeur

  1. La plupart des architectures Big Data incluent tout ou partie des composants suivants