Data Lake

mounir.benayed@fss.usf.tn
 Data Lake vs Data Warehouse vs Base de données
Tous conçus pour stocker des données
.
Les Bases de données
Les bases de données sont devenues « populaires » dans les années 1970-1980, avec l'essor de
la BDR.
Une BD est une collection organisée de données.
Les BD sont classées en fonction de la façon dont elles stockent ces données (BDR / BDOO / BDOR).
Elles sont conçues pour stocker et mettre à jour les données structurées en temps réel. (OLTP)
Elles ne contiennent souvent que les données les plus récentes.
 Data Lake vs Data Warehouse vs Base de données

Le Data Warehouse (Entrepôt de Données ED)

Un ED recueille des données de diverses sources, internes ou externes, et optimise la récupération des D.
Il permet de stocker des D historiques, structurées, non volatiles, orientées sujets. Il est conçu pour
l’analyse de données dans le cadre de la prise de décision.
Avec l’ED, la valeur n’est ni annulée ni remplacée. Ce qui permet de garder l’ensemble des valeurs que la
donnée a pu prendre durant son existence.
L’ED est un modèle pour soutenir le flux de données des syst. opérationnels vers les syst. décisionnels.
Ex : carte de fidélité. la BD peut contenir les achats les plus récents. L’entreprise peut ainsi les analyser et
en déduire les tendances actuelles des consommateurs.
L’ED, quant à lui, peut contenir un enregistrement de tous les articles achetés. Ce qui permet une analyse
plus étendue de son évolution et facilite le processus d’aide à la décision.
Une BD est un fournisseur de données en temps réel, tandis qu’un ED est davantage une source d'analyse
des données à mesure qu'elles sont enregistrées.
 Data Lake vs Data Warehouse vs Base de données

Le Data Lake
Un Data Lake ou lac de données est un référentiel de données permettant de stocker des
données brutes provenant de sources diverses. Ces données peuvent être structurées, non-
structurées ou semi-structurées pour une utilisation ultérieure.
Les données « chargées » dans les BD et les ED doivent être nettoyées et préparées avant d'être
stockées.
Les D non structurées peuvent être du texte, des données de médias sociaux ,des données
machine (fichiers journaux) et les données de capteurs (IoT).
 Lac de données
Un lac de données est une méthode de stockage de données massives
utilisée par le big data. Ces données sont gardées dans leurs formats
originaux (brut et granulaire) ou sont très peu transformées. Le lac de
données donne la priorité au stockage rapide et volumineux de données
hétérogènes en adoptant une architecture en cluster
Les Data Lakes sont configurés sur un cluster de serveurs standard,

Ce type de configuration permet de stocker des données dans le Data

Lake (au cas où elles seraient nécessaires plus tard) sans avoir à se
préoccuper de la capacité de stockage disponible.

Les clusters peuvent être déployés sur site ou dans le cloud.

Qu’est ce qu’un data lake
• Lorsqu'il importe les données, le
data lake les associe à des
identificateurs et des balises de
métadonnées pour une
récupération plus rapide.
(Référentiel pour DWH)

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019

Avantages du data lake

• Un data lake fonctionne selon le principe du « schéma en lecture », ce qui signifie

qu'il n'existe pas de schéma prédéfini dans lequel les données doivent être
importées avant leur stockage.
C'est lorsque les données sont lues pour leur traitement qu'elles sont analysées et
adaptées dans un schéma si nécessaire.
Cette fonctionnalité permet d'économiser le temps (généralement très long)
nécessaire à la définition d'un schéma. Elle permet également de stocker les
données telles qu'elles se présentent.

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019

Avantages du data lake

• Avec les data lakes, les data scientists peuvent accéder aux données, les
préparer et les analyser plus rapidement et avec une plus grande précision.

• Pour les experts en analyse, cette vaste piscine de données disponibles

dans des formats non traditionnels leur donne la possibilité d'accéder aux
données pour différents cas d'usage tels que l'analyse des sentiments des
consommateurs ou la détection des fraudes.

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019

Data lake vs data warehouse
• Un data lake et un data warehouse ont le même objet de base, ils sont souvent confondus :
• Il s'agit dans les deux cas d'un référentiel de stockage qui consolide les différents gisements de
données d'une entreprise.
• Dans les deux cas, l'objectif consiste à créer un gisement de données centralisé prêt à alimenter
différentes applications.
• Schéma en lecture vs schéma en écriture –
• Le schéma d'un data warehouse est défini et structuré avant le stockage (il est appliqué pendant l'écriture des
données).
• Un data lake n'applique pas de schéma prédéfini, ce qui lui permet de stocker les données dans leur format
natif.

• Pour un data warehouse, l'essentiel de la préparation des données a généralement lieu avant le traitement ;
• dans un data lake, la préparation des données se produit plus tard (seulement lorsque les données sont
réellement utilisées).

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019

Data lake vs data warehouse

Accessibilité complexe ou simple –

• Comme les données ne sont pas organisées sous forme simplifiée avant leur
stockage, un data lake a souvent besoin d'un expert ayant une compréhension
approfondie des différents types de données existants (et de leurs relations) pour
pouvoir les lire et les analyser. (un admin du Data Lake)

• En revanche, un data warehouse est facilement accessible aux utilisateurs techniques

et non techniques grâce à son schéma clairement défini et documenté. .

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019

• Flexibilité vs rigidité –
• Avec un data warehouse, Il est possible de prévoir non seulement du temps pour définir le schéma
initial, mais aussi des ressources considérables pour modifier ce schéma à l'avenir chaque fois que
les besoins de l'entreprise évoluent.
• De leur côté, les data lakes s'adaptent très facilement aux changements. Enfin, lorsque les besoins
en capacité de stockage augmentent, il est plus facile de faire évoluer les serveurs d'un cluster.

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019

Mounir Ben Ayed - UPHF - LAMIH - Valenciennes - 20 juin 2019
Bases de Données NoSQL
• Le terme« NoSQL »a été inventé en 2009 lors d'un événement sur les bases
de données distribuées.

• Le terme est vague, incorrect (certains moteurs NoSQL utilisent des

variantes du langage SQL, par exemple Cassandra), mais présente
l'avantage d'avoir un effet marketing et polémique certain.

• Dans cette présentation, nous allons aborder les caractéristiques générales

des moteurs NoSQL.
Caractéristiques générales des BD NoSQL
Adoptent une représentation de données non relationnelle

Ne remplacent pas les BD R mais sont une alternative, un complément apportant des solutions plus
intéressantes dans certains contextes

Apportent une plus grande performance dans le contexte des applications Web avec des volumétries de
données importantes

Utilisent une très forte distribution de ces données et des traitements associés sur de nombreux serveurs

Font un compromis sur le caractère « ACID » des SGBDR.

Adoption croissante des bases NoSQL par des grands acteurs du Web (Google, Facebook, …) => multiplication
des offres de systèmes NoSQL
Caractéristiques générales des BD NoSQL

Pas de schéma pour les données (schéma dynamique)

Données distribuées : partitionnement horizontal des données sur

plusieurs nœuds (serveurs)

Réplication des données sur plusieurs nœuds

Privilégient la Disponibilité (A) à la Cohérence (C)

Mode d'utilisation : peu d'écritures, beaucoup de lectures

Typologies des BD NoSQL
« Clé-valeur / Key-value » : basique, chaque objet est identifié par une clé unique

Voldemort, Redis, Riak,,,

« Colonne / Column » : permet de disposer d'un très grand nb de valeurs sur une même ligne, d’effectuer

des requêtes par clé (stockage de listes : messages, posts, commentaires, ...)

HBase, Cassandra, Hypertable, …

« Document » : pour la gestion de collections de documents, composés chacun de champs et de valeurs

associées, valeurs pouvant être requêtées (stockage de profils utilisateur)

MongoDBn CouchDB, Couchbase, …

« Graphe » : pour gérer des relations multiples entre les objets (données issues de réseaux sociaux, …)

Neo4j, OrientDB, …
BD NoSQL : Clé-valeur
Elles fonctionnent comme un grand tableau associatif et retourne une valeur dont elle ne connaît pas la structure

leur modèle peut être assimilé à une table de hachage (hashmap) distribuée

les données sont représentées par un couple clé/valeur

la valeur peut être une simple chaîne de caractères, ou un objet sérialisé…

L’absence de structure ou de typage ont un impact important sur le requêtage : toute l’intelligence portée
auparavant par les requêtes SQL devra être portée par l’applicatif qui interroge la BD.

Amazon Dynamo (Riak en est l'implémentation Open Source)

Redis (projet sponsorisé par VMWare)

Voldemort (Linkedln, open source).

Type de Base de données NoSQL
• 4 grandes familles
• Clé-valeur
La plus simple et flexibles des BD NOSQL
Associe des clés à des valeurs
Solution aux limitations des BD relationnelles
Les valeurs sont identifiées et accédées via la clé
Exemples
Réseau social : à partir d’un utilisateur (la clé), je veux obtenir une liste de ses amis
(la Catalogue de livres : le numéro ISBN (la clé) donne accès à tous les détails sur le
livre (la valeur).
Journal d’activités : la date d’un événement (la clé) indexe les détails de ce qui s’est
passé à ce moment (la valeur).
Pas de schéma : La valeur stockée est gérée au niveau applicatif. Elle peut être Entier, Chaine de
caractère, JSON, XML, HTML, Image, vidéo, etc.
Forces et faiblesses
• Forces :

modèle de données simple

bonne mise à l ’échelle horizontale pour les lectures et écritures :

• évolutivité (scalable)

• disponibilité

• pas de maintenances requises lors d'ajout/suppression de colonnes

• Faiblesses :

modèle de données trop simple

pauvre pour les données complexes

déporte une grande partie de la complexité de l'application sur la couche appication elle-même
BD NoSQL : colonne

• Les données sont stockées par colonne, non par ligne

Il est possible d’ajouter des colonnes aux tables - l'insertion d'une ligne est plus coûteuse

Modèle proche d’une table dans un SGBDR mais le nombre de colonnes est dynamique et peut varier
d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des valeurs NULL.
HBase (Open Source de BigTable de Google utilisé pour l'indexation des pages web, Google Earth,
Google analytics, ...)
Cassandra (fondation Apache qui respecte l’architecture distribuée de Dynamo d’Amazon, Facebook)
SimpleDB (Amazon).
BD NoSQL : colonne

Ces bases de données NoSQL sont celles se rapprochant le plus des bases de données R (SGBDR).
On y retrouve le principe de “table” avec des lignes et des colonnes, mais elles ont deux principales
grosses différences :
Les colonnes sont dynamiques. Au sein d’une même table deux individus peuvent ne pas avoir le même
nombre de colonnes car les valeurs nulles ne sont pas stockées (# SGBDR). => libérer de la place de
stockage et améliorer les performances de traitement
Il suffit de ne créer qu’une seule table contenant toutes les données (# SGBDR) => absence de ‘jointure’
entre les tables.
L’historisation des données se fait à la valeur et non pas à la ligne comme dans les SGBDR cela empêche
le stockage d’informations en doublon => allège la base de données et diminue les temps de calcul.
• Les principaux concepts associés :
Colonne :
entité de base représentant un champ de donnée
chaque colonne est définie par un couple clé / valeur
une colonne contenant d’autres colonnes est nommée supercolonne.
Famille de colonnes :
permettent de regrouper plusieurs colonnes (ou supercolonnes)
les colonnes sont regroupées par ligne
chaque ligne est identifiée par un identifiant unique (assimilées aux tables dans le modèle relationnel) et
sont identifiées par un nom unique
Supercolonnes
situées dans les familles de colonnes sont souvent utilisées comme les lignes d’une table de jointure dans
le modèle relationnel.
Forces et faiblesses
Forces :

Modèle de données supportant des données semi -structurées

Naturellement indexé (colonnes)

On peut voir les résultats de requêtes en temps réel

Faiblesses :

Ne convient pas pour des données interconnectés

Ne convient pas pour les lectures de données complexes

Exige de la maintenance - lors de l'ajout / suppression de colonnes et leur regroupements

 BD NoSQL : Documents
Elles stockent une collection de "documents"

Basées sur le modèle « clé-valeur » mais la valeur est un document en format semi -structuré hiérarchique de
type JSON ou XML (possible aussi de stocker n'importe quel objet, via une sérialisation)

Les documents n'ont pas de schéma, mais une structure arborescente : ils contiennent une liste de champs, un
champ a une valeur qui peut être une liste de champs, ...

CouchDB

RavenDB

MongoDB, Terrastore, …
Un document est composé de champs et des valeurs associées

Les valeurs :

peuvent être requêtées

sont soit d’un type simple (entier, chaine de caractère, date, ...) soit elles mêmes composées
de plusieurs couples clé/valeur.

Bien que les documents soient structurés, ces BD sont dites “schemaless” : il n’est pas nécessaire de
définir au préalable les champs utilisés dans un document

Les documents peuvent être très hétérogènes au sein de la BD

Forces et faiblesses

• Forces :

Modèle de données simple mais puissant (expression de structures imbriquées)

Pas de maintenance de la BD requise pour ajouter/supprimer des «colonnes»

Expressivité de requêtage (requêtes assez complexes sur des structures imbriquées)

• Faiblesses :

Inadaptée pour les données interconnectées

Modèle de requête limité à des clés

BD NoSQL orientés Graph

Permettent la modélisation, le stockage et la manipulation de données complexes liées par des

relations non-triviales ou variables

Modèle de représentation des données basé sur la théorie des graphes

S’appuie sur les notions de nœuds, de relations et de propriétés qui leur sont rattachées.

Neo4J

OrientDB
Les BD NoSQL orientés graph utilisent :

Moteur de stockage pour les objets (similaire à une base documentaire, chaque entité de cette base
étant nommée nœud)

Mécanisme de description d’arcs (relations entre les objets), arcs orientés et avec propriétés (nom,
date, ...)

Plus efficaces que les BDR pour traiter les problématiques liées aux réseaux (cartographie, relations
entre personnes, ...)

Sont adaptées à la manipulation d'objets complexes organisés en réseaux : cartographie, réseaux

sociaux, ..