Big data &

Environnement Cloud
Sellami Mokhtar
les 5 piliers d'un cadre d'architecture cloud
robuste
Azure Well-Architected Framework
Piliers communs
• Azure Well-Architected Framework est un ensemble de principes
directeurs qui peuvent être utilisés pour améliorer la qualité
d’une charge de travail. Les cadres d'architecture cloud des trois
fournisseurs reposent sur cinq piliers communs :
• Fiabilité
• Sécurité
• Optimisation des coûts
• Excellence opérationnelle
• Efficacité des performances
Pourquoi mettre en place une architecture
Big Data ?
• Les systèmes de bases de données traditionnels ne permettent plus
de répondre aux exigences imposées par le Big Data.
• Ils ne sont pas en mesure de traiter des volumes de données aussi
massifs et assez rapidement.
• il faut adapter la structure son ecosystème informatique traditionnel
et mettre en place une architecture Big Data.
Pourquoi mettre en place une architecture
Big Data ?
• En mettant en place une architecture Big Data adaptée dans son
entreprise, une organisation va pourvoir effectuer :
• Un traitement en batch des sources de Big Data
• Un traitement en temps réel des Big Data en mouvement
• Une exploration des données volumineuses
• Une transformation des données complexes
• Une centralisation des data issues de différentes sources et existantes sous
différents formats
• Des analyses prédictives
• Des tâches basées sur les technologies de l’intelligence artificielle
Les composantes d’une architecture Big Data
• La plupart des architectures de données volumineuses incluent tout
ou partie des éléments suivants :
• Source de données (data mart, data warehouse, cloud, base de données
hybride)
• Stockage (data warehouse, data lake, data lake house)
• Batch processing (traitement par lots)
• Stream processing (traitement de flux de data)
• Préparation de données
• Data catalog
• Modélisation de données
• Technologie d’orchestration
Composants d’une architecture Big Data
Les principaux types d’architecture Big Data
• Architecture Lambda
• Architecture Kappa
Transformation et raffinement des données
le Datalake
Lambda
Architecture Kappa
Big Cloud
Service
Providers
Compute Services
SERVICE AWS AZURE GCP

VM (Compute EC2 (Elastic Azure Virtual Google Compute

Instance) Compute) Machine Engine

AWS Elastic
PaaS App Service Google App Engine
Beanstalk

AWS Elastic
Azure Kubernetes Google Kubernetes
Container Container/Kuberne
Service (AKS) Engine
tes Service

Serverless Google Cloud

AWS Lambda Azure Function
Functions Functions
Database & Storage Services
SERVICE AWS AZURE GCP
RDBMS (Multiple
Azure SQL/ Database
Database Types – SQL, AWS RDS Cloud SQL
for MySQL/PostgreSQL
MySQL, etc..)

Azure Cosmos DB, BigTable, Cloud

NoSQL DynamoDB, Simple DB
Table Storage Datastore
S3 (Simple Storage
Object Storage Blob Storage Google Cloud Storage
Service)
File Storage Elastic File System Azure File Storage Google Filestore
Google Storage
Archive Storage Amazon Glacier Azure Archive Storage
(Archive Storage)

Data Warehouse/Data Azure Synapse

Amazon Redshift Google BigQuery
Lake Analytics
Networking
SERVICE AWS AZURE GCP

Virtual Network Virtual Private Cloud (VPC) Virtual Network (Vnet) Virtual Private Cloud (VPC)

Load Balancing Elastic Load Balancer Azure Load Balancer Google Cloud Load Balancing

AWS Firewall / Web Application

Firewall Azure Firewall Google Cloud firewalls
Firewall

DNS Route 53 Azure DNS Google Cloud DNS

Azure Content Delivery

CDN Amazon CloudFront Cl
Network (CDN)
Specialized services

• When it comes to specialized services, we notice significant

differences in the services available with AWS and Azure, far
surpassing GCP.
 SERVICE AWS AZURE GCP
Azure Boards, Pipelines, GCP DevOps
CodePipeline, CodeBuild,
DevOps Repos, Test Plans, CloudBuild, Artifact
CodeDeploy, CodeStar
Artifacts Registry
Azure Machine Learning,
Amazon SageMaker,
Azure Databricks, Azure Vertex AI, AutoML,
Amazon Comprehend,
AI & ML Cognitive Search, Azure Dataflow CX, Cloud
Amazon Lex, Amazon
Bot Service, Cognitive Vision, Virtual Agents
Polly
Services
FreeRTOS, IoT Core, Azure IoT Hub/Central,
IoT Greengrass, IoT IoT Edge, Azure Sphere, Google Cloud IoT Core
Analytics, SiteWise Azure RTOS
Azure Mixed Reality
AR & VR Amazon Sumerian (Spatial Anchors/Remote ARCore
Rendering)
Game Development Amazon GameLift Azure PlayFab
Business Analytics Amazon Quicksight Azure Power BI Looker
End-User Computing Amazon Workspaces Azure Virtual Desktop
Robotics AWS RoboMaker
Stages in a big data pipeline.
Un pipeline de données
• Un pipeline de données comporte cinq étapes regroupées en trois
têtes:
• Ingénierie des données: collecte, ingestion, préparation (~ 50% d'effort)
• Analytics / Machine Learning: calcul (~ 25% d'effort)
• Livraison: présentation (~ 25% d'effort)
Un pipeline de données
• Ingestion:
• Les sources instrumentées pompent les données dans différents points d'entrée (HTTP, MQTT, file d'attente de messages,
etc.). Il peut également y avoir des tâches pour importer des données à partir de services comme Google Analytics. Les
données peuvent se présenter sous deux formes: les blobs et les flux. Toutes ces données sont collectées dans un Data Lake .

• Préparation:
• Il s'agit de l'opération d'extraction, de transformation, de chargement (ETL) pour nettoyer, conformer, mettre en forme,
transformer et cataloguer les blobs et les flux de données dans le lac de données; rendre les données prêtes à être
consommées pour le ML et les stocker dans un entrepôt de données .

• Calcul:
• c'est là que se déroulent l'analyse, la science des données et l'apprentissage automatique. Le calcul peut être une
combinaison de traitement par lots et par flux. Les modèles et les informations (à la fois les données structurées et les flux)
sont stockés dans l' entrepôt de données .

• Présentation:
• les informations sont fournies via des tableaux de bord, des e-mails, des SMS, des notifications push et des microservices.
Les inférences du modèle ML sont exposées sous forme de microservices.
Data Warehouse Data Lake et Data
Lake house
Data Lake et Data Warehouse

• Le Data Lake contient toutes les données sous leur forme naturelle / brute
telles qu'elles ont été reçues généralement dans des objets blob ou des
fichiers.
• L' entrepôt de données stocke les données nettoyées et transformées avec
le catalogue et le schéma. Les données du lac et de l'entrepôt peuvent être
de différents types: flux d'événements structurés (relationnels), semi-
structurés, binaires et en temps réel.
• C'est une question de choix si le lac et l'entrepôt sont physiquement conservés dans
des magasins différents, ou si l'entrepôt est matérialisé par une sorte d'interface (par
exemple les requêtes Hive ) sur le lac.
• Le choix est motivé par les exigences de vitesse et les contraintes de coût.
• Quelle que soit l'approche suivie, il est important de conserver les données brutes à
des fins d'audit, de test et de débogage.
Data Lake house
• l'architecture Lakehouse est définie comme
• "un système de gestion de données basé sur un stockage à faible
coût et directement accessible qui fournit également des
fonctionnalités de gestion et de performance de SGBD analytiques
traditionnelles telles que les transactions ACID, la gestion des
versions des données, l'audit, l'indexation, la mise en cache. , et
l'optimisation des requêtes. »
Data Warehouse
Data Lake
Data Lake house
Conceptions d'architecture de lac de données

• En général, un système de data lakehouse se compose de

cinq couches.
• Couche d'ingestion
• Couche de stockage
• Couche de métadonnées
• Couche API
• Couche de consommation
Conceptions d'architecture de lac de données
• Les Lakehouses combinent le faible coût et la flexibilité des lacs
de données avec la fiabilité et les performances des entrepôts
de données.
• L'architecture de la maison du lac offre plusieurs caractéristiques
clés, notamment :
• Stockage fiable, évolutif et économique dans un format ouvert
• ETL et traitement de flux avec transactions ACID
• Métadonnées, gestion des versions, mise en cache et indexation pour
garantir la gérabilité et les performances lors des requêtes
• API SQL pour la BI et le reporting ainsi que des API DataFrame
déclaratives pour la science des données et l'apprentissage
automatique
Big Data Architecture: Open Sources
Technologies
Les composants clés de l'architecture Big Data
et les choix technologiques
• Points de terminaison HTTP / MQTT pour l'ingestion de données, ainsi que pour la diffusion des résultats. Il
existe plusieurs cadres et technologies pour cela.
• Pub/Sub Message Queue pour l'ingestion de données de streaming à haut volume. Kafka est actuellement le
choix de facto. Il a été prouvé qu'il évoluait jusqu'à un taux d'ingestion d'événements élevé.
• Stockage de données à haut volume et à faible coût pour le lac de données (et l'entrepôt de données),
Hadoop HDFS ou le stockage d'objets blob dans le cloud comme AWS S3 .
• Infrastructure de requête et de catalogue pour convertir un lac de données en entrepôt de données, Apache
Hive est un choix de langage de requête populaire.
• Map-Reduce Batch Compute Engine pour le traitement à haut débit, par exemple Hadoop Map-Reduce ,
Apache Spark .
• Stream Compute pour le traitement sensible à la latence, par exemple Apache Storm , Apache Flink . Apache
Beam est en train de devenir le choix pour écrire le calcul du flux de données. Il peut être déployé sur un
exécuteur de lots Spark ou un exécuteur de flux Flink.
• Cadres d'apprentissage automatique pour la science des données et le ML. Scikit-Learn , TensorFlow et
PyTorch sont des choix populaires pour la mise en œuvre de l'apprentissage automatique.
• Magasins de données à faible latence pour stocker les résultats. Il existe de nombreux choix de magasins de
données SQL et NoSQL bien établis en fonction du type de données et du cas d'utilisation.
Les composants clés de l'architecture Big Data
et les choix technologiques
• Les options d'orchestration de déploiement sont Hadoop YARN ,
Kubernetes / Kubeflow .
• L'échelle et l'efficacité sont contrôlées par les leviers suivants :
• Le débit dépend de l' évolutivité de l'ingestion (c'est-à-dire des points de terminaison
REST/MQTT et de la file d'attente de messages), de la capacité de stockage du lac de
données et du traitement par lots de réduction de carte .
• La latence dépend de l' efficacité de la file d'attente de messages , du calcul de flux et
des bases de données utilisées pour stocker les résultats de calcul.
Architecture on-premise
Architecture cloud
Principes et composants de Lakehouse
Databriks
L'analyse exploratoire des données
• Le rôle de l'analyse exploratoire des données (EDA) est d'analyser et de
visualiser des ensembles de données et de formuler des hypothèses. Cela
peut révéler des lacunes dans les données collectées, conduire à de
nouvelles collectes de données et expériences, et vérifier une hypothèse.

• Vous pouvez les considérer comme des expériences ML à petite échelle

pour vous concentrer sur un petit ensemble de modèles prometteurs, qui
sont comparés et ajustés sur l'ensemble de données.

• Avoir un entrepôt de données bien entretenu avec des catalogues, un

schéma et une accessibilité via un langage de requête (au lieu d'avoir
besoin d'écrire des programmes) facilite l'EDA rapide.
Architecture Data Lake house
Architecture Data lake house
• L’architecture d’une maison de lacs de données combine les
fonctionnalités du lac de données et de l’entrepôt de données afin
d’accroître l’efficacité opérationnelle et d’offrir des capacités
améliorées permettant :
• Utilisation transparente des données et des informations, sans qu’il soit
nécessaire de les répliquer dans le lac de données et le data warehouse
• Capacité à découpler entièrement les ressources de stockage et de calcul et à
consommer uniquement les ressources nécessaires à tout moment
• Prise en charge étendue des types de données dans une architecture multi-
modèle et polyglotte améliorée
• Un ensemble diversifié de cas d’utilisation, notamment la diffusion en
continu, l’analytique, la science des données et l’apprentissage automatique
Maison du lac de données dans le Cloud
• Traiter les données d’entreprise et de diffusion en continu pour
l’analyse et l’apprentissage automatique
Big Data
Architecture:
Serverless
Serverless
• Serverless est un modèle d'exécution cloud qui offre un moyen
plus simple et plus rentable de créer et d'exploiter des
applications cloud natives.
• Serverless est un modèle d'exécution de cloud computing qui
• Provisionne automatiquement les ressources informatiques
nécessaires pour exécuter le code d'application à la demande ou en
réponse à un événement spécifique ;
• Augmente ou diminue automatiquement ces ressources en réponse à
l'augmentation ou à la diminution de la demande ;
• Redimensionne automatiquement les ressources à zéro lorsque
l'application s'arrête.
Quelle est la définition de serverless computing
?
• Le serverless computing, ou informatique sans serveur, consiste à laisser le fournisseur
de services Cloud (Cloud Public, Cloud Privé, Cloud Hybride) fournir, gérer et
dimensionner l’infrastructure nécessaire pour faire tourner vos applications. Le principal
avantage est de vous permettre de développer une application plus rapidement,
d’optimiser vos ressources et de minimiser les coûts de développement.
• Quels sont les avantages du serverless computing ?
• Les avantages du Serveless Computing sont nombreux :
• Vous n’avez pas à gérer l’infrastructure se trouvant derrière votre application. Vous déployez
seulement votre code en vous concentrant sur la logique métier qui a présidé à sa conception.
• Le serverless computing favorise la scalabilité de votre application. C’est-à-dire qu’elle peut
évoluer de manière dynamique en fonction de la demande. C’est le cas si votre outil doit faire face
à un afflux d’utilisateurs. Il n’y aura pas de rupture de services.
• Vous pouvez aussi mieux travailler en mode agile en développant les fonctionnalités plus
rapidement.
• Les ressources sont utilisées plus efficacement vous permettant de vous concentrer sur
l’innovation.
• Vous n’avez plus besoin de gérer vos propres data centers et vos bases de données.
Quels sont les inconvénients du serverless
computing ?
• Si l’informatique sans serveur paraît être la solution idéale, elle présente
tout de même des inconvénients.
• La principale étant sans doute la dépendance vis-à-vis du fournisseur de services
cloud sélectionné. C’est ce que l’on appelle le verrouillage des Cloud Providers. Vous
ne pourrez pas non plus personnaliser à 100% le serveur cloud ou la portion de
serveur cloud qui sera allouée à votre application.
• Si votre outil a besoin d’une configuration serveur très spécifique, il sera plus simple
de vous tourner vers un serveur privé hébergé dans vos locaux.
• Enfin, la sécurité est un point d’attention important, d’autant que les serverless sont
généralement mutualisés.
• Il peut aussi y avoir des soucis inhérents aux performances, à l’instar d’une durée
d’exécution limitée des fonctions, une latence de démarrage au lancement de la
fonction. Ou la difficulté de la tester et de la débuguer via le cloud. Autant de freins
qui ont tendance à s’estomper avec l’évolution de cette technologie encore jeune.
Comprendre la pile sans serveur

• Fonctions en tant que service (FaaS) : Encore une fois, le FaaS est largement compris comme le
moteur de calcul/traitement central/fondamental en mode sans serveur et se trouve au centre de
la plupart des architectures sans serveur. Voir « Qu'est-ce que le FaaS ? » pour une plongée plus
approfondie dans la technologie.
• Bases de données et stockage sans serveur : les bases de données (SQL et NoSQL) et le
stockage (en particulier le stockage d'objets ) constituent le fondement de la couche de
données. Une approche « sans serveur » de ces technologies implique une transition des
« instances » de provisionnement avec des limites de capacité, de connexion et de requête
définies, et une évolution vers des modèles qui évoluent de manière linéaire avec la demande en
termes d'infrastructure et de tarification.
• Diffusion d' événements et messagerie : les architectures sans serveur sont bien adaptées aux
charges de travail axées sur les événements et le traitement de flux, notamment la plate-forme de
diffusion d'événements open source Apache Kafka.
• Passerelles API : les passerelles API agissent comme des proxys pour les actions Web et
fournissent un routage de méthode HTTP, un ID client et des secrets, des limites de débit, CORS,
l'affichage de l'utilisation de l'API, l'affichage des journaux de réponse et des politiques de partage
d'API.
•
Demandes courantes

• Dans une récente enquête IBM, les professionnels de l'informatique ont déclaré
utiliser le sans serveur dans un large éventail d'applications, notamment la gestion
de la relation client (CRM), l'analyse et l'informatique décisionnelle, la finance, etc.
(voir Figure 2).
Big data pipelines on Amazon Web Services
 Piliers de l'architecture
de données moderne

https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/?nc1=h_ls
Big data pipelines on Microsoft Azure
Créer des solutions
d’analyse de
données adaptées
à un secteur avec
Azure Synapse
Analytics
Architecture d’analytique avancée
Système de génération d’offres personnalisées avec des
modèles de base de données Azure Synapse
Utiliser des modèles de base de données
Big data pipelines on Google Cloud
Modèles de conception
de lac de données sur le • Modèle I : Pile complète du lac de données
cloud Google (GCP)
Modèles de conception
de lac de données sur le • Modèle II : modèle unifié de traitement par lots et de
cloud Google (GCP) diffusion en continu
Modèles de
conception de lac de
données sur le cloud
Google (GCP)

Modèle 3 : architecture de
diffusion en continu Lambda
Simplifiez votre architecture Lakehouse avec
Azure Databricks, Delta Lake et Azure Data
Lake Storage
Simplifiez votre architecture Lakehouse avec
Azure Databricks, Delta Lake et Azure Data
Lake Storage
• Lors de la construction d'une architecture Lakehouse, gardez à l'esprit ces 3
principes clés et leurs composants associés :
• Un lac de données pour stocker toutes vos données, avec une couche organisée dans un
format open source. Le lac de données doit pouvoir accueillir des données de tout type,
taille et vitesse. Le format des données conservées dans le lac doit être ouvert, intégré aux
services de sécurité cloud natifs et doit prendre en charge les transactions ACID.
• Une couche de calcul fondamentale basée sur des normes ouvertes. Il devrait y avoir une
couche de calcul fondamentale qui prend en charge tous les principaux cas d'utilisation de
Lakehouse, y compris la conservation du lac de données (ETL et traitement de flux), la science
des données et l'apprentissage automatique, ainsi que l'analyse SQL sur le lac de données.
Cette couche doit également être construite sur des normes ouvertes qui garantissent une
innovation rapide et sont non verrouillables et à l'épreuve du temps.
• Intégration facile pour des cas d'utilisation supplémentaires et/ou nouveaux. Aucun service
ne peut tout faire. Il y aura toujours des cas d'utilisation nouveaux ou supplémentaires qui ne
font pas partie des cas d'utilisation principaux de Lakehouse. Ces cas d'utilisation nouveaux
ou supplémentaires nécessitent souvent des services ou des outils spécialisés. C'est pourquoi
des intégrations faciles entre le lac de données organisé, la couche de calcul fondamentale et
d'autres services et outils sont des exigences clés.
Data Lakehouse avec Databricks & AZURE
Gouvernance de données
• Qu'est-ce que la gouvernance des données ?
« La gouvernance des données est un ensemble de processus, rôles, règles,
normes et métriques permettant d'assurer une utilisation efficace et efficiente
des informations, dans le but d'aider les entreprises à atteindre leurs objectifs. »
Gouvernance de données
• Elle définit les procédures
et les responsabilités
garantissant la qualité et la
sécurité des données au
sein d'une entreprise ou
d'une organisation.
• Elle définit également qui
peut effectuer quelle
action, sur quelles
données, dans quelle
situation et selon quelle
méthode.
Gouvernance de données
• Une stratégie de gouvernance des données claire
• est fondamentale pour toute organisation traitant les big data, et
• explique comment la société peut bénéficier de procédures et de
responsabilités communes et cohérentes.
• Les moteurs opérationnels déterminent quelles données doivent être
soigneusement contrôlées dans votre stratégie de gouvernance des données
ainsi que les bénéfices attendus.
• Cette stratégie sera la base de votre cadre de gouvernance des es données
Gouvernance de
données
• Pour structurer un framework de Data Gouvernance au sein d’une
organisation, nous considérons qu’il faut tout d’abord évaluer l’état de
l’art sur les points suivants :
• La connaissance de son patrimoine de données,
• L’acculturation des différents acteurs, nécessaire à la mise en
place d’une stratégie data-driven,
• La structuration des responsabilités et de l’ownership autour de
la donnée,
• La mise en place de normes de qualité et la gestion quotidienne
de celle-ci,
• La sécurisation des données les plus sensibles de l’entreprise,
• La maîtrise du cycle de vie de ses données,
• La diffusion de la donnée dans une logique de désilotage,
• La valorisation et la création de valeur autour de la donnée.
Outils de gouvernance des données
• Ces outils doivent vous aider à :
• Collecter et comprendre vos données, grâce à des outils et des fonctionnalités de
découverte, de profilage et de comparaison. Par exemple, les outils performants
peuvent automatiquement détecter une donnée personnelle, comme un numéro
de sécurité sociale, dans un nouveau dataset et déclencher une alerte.
• Améliorer la qualité des données avec la validation, le nettoyage et
l'enrichissement des données.
• Gérer vos données grâce aux processus ETL et ELT basés sur les métadonnées, et
aux applications d'intégration de données, afin que les pipelines de données
puissent être suivis avec un historique des données de bout en bout.
• Contrôler vos données avec des outils de vérification et de surveillance actives.
• Documenter vos données afin que des métadonnées puissent leur être ajoutées,
améliorant ainsi la pertinence, la recherche, l'accès, les liaisons et la conformité.
• Responsabiliser les personnes qui connaissent le mieux les données, en leur
permettant de contribuer aux tâches de data stewardship avec des outils en libre-
service.
References
• https://towardsdatascience.com/scalable-efficient-big-data-analytics-machine-learning-pipeline-
architecture-on-cloud-4d59efc092b5
• https://www.altexsoft.com/blog/data-lakehouse/
• https://www.advancinganalytics.co.uk/blog/2020/2/4/the-data-lakehouse-dismantling-the-hype
• https://techcommunity.microsoft.com/t5/analytics-on-azure-blog/simplify-your-lakehouse-architecture-
with-azure-databricks-delta/ba-p/2027272
• https://www.tableau.com/about/blog/2021/6/how-databricks-and-tableau-customers-are-fueling-
innovation-data-lakehouse
• https://www.unifieddatascience.com/data-lake-design-patterns-on-google-cloud
• https://blog.miraclesoft.com/data-foundation-with-modernized-data-lake-data-warehouse/
• https://thenewstack.io/introducing-corps-the-five-pillars-for-a-robust-cloud-architecture-framework/
• https://www.unifieddatascience.com/data-lake-design-patterns-on-google-cloud
• https://www.alibabacloud.com/blog/data-lake-concepts-characteristics-architecture-and-case-
studies_596910