Big Data / Business Intelligence

« Pilotage de la performance pour une bonne gouvernance des entreprises »

CHAPITRE 4 :
NoSQL & HBase

2BA
Ecosystème Hadoop

2
Hadoop Framework Tools

3
 Introduction

• Avec l'explosion de la taille des données à gérer que connaissent certaines

sociétés, les bases de données traditionnelles n'arrivent pas à fournir un temps
de réponse satisfaisant, alors deux solutions sont envisageables :
• Augmenter les ressources de la machine (la puissance du processeur, la mémoire, etc.) 
scalabilité verticale
• Cette solution a ses limites (on ne peut pas augmenter la puissance du processeur à l'infini).

• Utiliser un cluster de machines  scalabilité horizontale

• En théorie, permet une augmentation illimitée des capacités avec un coût de revient moindre,
car il suffit d'ajouter d'autres machines au cluster.

4
 Qu’est ce que NoSQL ?

• NoSQL est un système de gestion de base de données non relationnel, très différent des
systèmes de gestion de base de données relationnels traditionnels,

• Il est conçu pour les magasins de données distribués nécessitant des besoins de stockage
de données à très grande échelle
• par exemple Google ou Facebook, qui collecte chaque jour des térabits de données pour leurs utilisateurs,

• Ce type de stockage de données peut ne pas nécessiter de schéma fixe, éviter les
opérations de jointure et assurer une scalabilité horizontale.

5
 Pourquoi NoSQL ?

• De nos jours, il est de plus en plus facile d’accéder aux données et de les saisir via des tiers tels
que Facebook, Google+ et autres.
• Les informations utilisateur personnelles, les graphiques sociaux, les données de géolocalisation, le contenu
généré par l'utilisateur et les données log machine ne sont que quelques exemples où les données ont
augmenté de façon exponentielle.

• Pour bénéficier correctement de ce service, il est nécessaire de traiter une énorme quantité de
données.
• Les bases de données SQL n'ont pas été conçues pour gérer ce service.

 L'évolution des bases de données NoSQL consiste à gérer correctement cette masse énorme
de données.

6
RDBMS Vs. NoSQL

• RDBMS : • NoSQL (Not Only SQL) :

• Données structurées et organisées • Pas de langage de requête déclaratif
• Langage d'interrogation structuré • Pas de schéma prédéfini
(Structured Query Language - SQL) • Stockage de paires clé-valeur, magasin de colonnes,
• Les données et leurs relations sont magasin de documents, bases de données
stockées dans des tables séparées. graphiques
• Langage de manipulation de données • Cohérence éventuelle plutôt que propriétés ACID
(DML), Langage de définition de • Données non structurées et imprévisibles
données (DDL)
• Priorise les hautes performances, la haute
• Cohérence constante
disponibilité et l’évolutivité
7
NoSQL : Avantages / Inconvénients

• Avantages : • Inconvénients :
• Grande évolutivité • Pas de standardisation
• Calcul distribuée
• Capacité de requête limitée
• Moindre coût
• Pas intuitive à programmer
• Flexibilité, données semi-structurées

• Pas de relations compliquées

8
Familles NoSQL

• Il existe différentes familles de bases NoSQL :

• Clé/Valeur,

• Colonnes,

• Documents,

• Graphes.

• Chacune de ces familles répond à des besoins très spécifiques.

9
Familles NoSQL
• Famille Clé/Valeur :
• Le but de la famille clé-valeur est l'efficacité et la simplicité.
• Un système clé-valeur agit comme une énorme table de hashage distribuée sur le réseau.
• Tout repose sur le couple Clé/Valeur :
• La clé identifie la donnée de manière unique et permet de la gérer.
• La valeur contient n'importe quel type de données.
• Les seules opérations de type CRUD peuvent être utilisées :
• Create (key,value), Read (key), Update (key,value), Delete (key) 

10
 Familles NoSQL

• Famille Clé/Valeur :
• Quels types d'applications pourraient correspondre à cette solution ?
• Détection de fraude en temps réel, IoT, e-commerce, gestion de cache, transactions rapides, fichiers de logs, chat.

11
 Familles NoSQL

• Des lignes vers les colonnes

• Traditionnellement, les données sont représentées en ligne, représentant l'ensemble des attributs.

• Le stockage orienté colonne change ce paradigme en se focalisant sur chaque attribut et en les
distribuant.

• Il est possible de focaliser les requêtes sur une ou plusieurs colonnes, sans avoir à traiter les
informations inutiles (les autres colonnes).

• Cette solution est très adaptée pour effectuer des traitements sur des colonnes comme les
agrégats (comptage, moyennes, co-occurences...).  adaptée à de gros calculs analytiques.

12
Familles NoSQL

• Des lignes vers les colonnes

13
Familles NoSQL

• Des lignes vers les colonnes

• Quels types d'applications pourraient correspondre à cette solution ?
• Comptage (vote en ligne, compteur, etc), journalisation, recherche de produits dans une catégorie,
reporting à large échelle.

14
Familles NoSQL

• La gestion de documents
• Le but de ce stockage est de manipuler des documents contenant des informations avec une
structure complexe (types, listes, imbrications).
• Il repose sur le principe du clé/valeur, mais avec une extension sur les champs qui composent
ce document.
• L'avantage de cette solution est d'avoir une approche structurée de chaque valeur, formant
ainsi un document.
• Ces solutions proposent des langages d'interrogation riches permettant de faire des
manipulations complexes sur chaque attribut du document (et sous-documents) comme dans
une base de données traditionnelles, tout en passant à l'échelle dans un contexte distribué.

15
Familles NoSQL

• La gestion de documents

16
Familles NoSQL

• La gestion de documents
• Quels types d'applications pourraient correspondre à cette solution ?
• Gestion de contenu (bibliothèques numériques, collections de produits, dépôts de logiciels,
collections multimédia, etc.), framework stockant des objets, collection d’événements complexes,
gestion des historiques d’utilisateurs sur réseaux sociaux.

17
 Familles NoSQL

• Les graphes
• Les trois premières familles NoSQL n'adressent pas le problème de corrélations entre les éléments.

• Dans la base orientée graphe, les données stockées sont : les nœuds, les liens et des propriétés sur
ces nœuds et ces liens.
• Les requêtes que l'on peut exprimer sont basées sur la gestion de chemins, de propagations,
d'agrégations, voire de recommandations.
• Contrairement aux solutions précédentes la distribution des nœuds sur le réseau n'est pas triviale.

18
Familles NoSQL
• Les graphes

19
Familles NoSQL

• Les graphes
• Quels types d'applications pourraient correspondre à cette solution ?
• Réseaux sociaux (recommandation, plus court chemin, cluster...), réseaux SIG (routes, réseau
électrique, fret...), web social (Linked Data).

20
 Dénormalisation
• Dans une relation entre deux tables A et B, la dénormalisation consiste à dupliquer certaines

données de la table B dans la table A afin d'optimiser les requêtes qui pourront se contenter

d'interroger la table A sans avoir à faire de jointures entre A et B.

• Il existe trois stratégies de dénormalisation des données :

• Imbrication de documents :

• Pour une relation entre deux documents A et B, cela consiste à avoir le document B imbriqué dans le document A,

21
 Dénormalisation
• Dans une relation entre deux tables A et B, la dénormalisation consiste à dupliquer certaines

données de la table B dans la table A afin d'optimiser les requêtes qui pourront se contenter

d'interroger la table A sans avoir à faire de jointures entre A et B.

• Il existe trois stratégies de dénormalisation des données :

• Duplication d'un sous ensemble de champs :

• L'idée est de dupliquer le minimum de données du document B dans A et de préférence, celles qui ne

changent pas souvent, car lors de leur mise à jour, nous devrions faire un update sur l'ensemble des

documents qui les contiennent, plutôt qu'à un seul endroit dans une base de données normalisée.

22
 Dénormalisation
• Dans une relation entre deux tables A et B, la dénormalisation consiste à dupliquer certaines

données de la table B dans la table A afin d'optimiser les requêtes qui pourront se contenter

d'interroger la table A sans avoir à faire de jointures entre A et B.

• Il existe trois stratégies de dénormalisation des données :

• Duplication de la clé primaire :

• on ne duplique que la clé primaire du document B dans le document A. Pour récupérer les données,

l'application doit faire deux requêtes : une pour récupérer la clé primaire et une seconde pour récupérer

les données de l'autre côté de la relation.

23
Apache HBase

24
 HBase, c’est quoi ?
• HBase est un SGBD non relationnel, orienté colonne adapté au stockage et à l’accès rapide à des mégadonnées.

• HBase est un système de stockage efficace pour des données très volumineuses. Il permet d’accéder aux données

très rapidement même quand elles sont gigantesques.

• Une variante de HBase est notamment utilisée par Facebook pour stocker tous les messages, email, chat, …

• HBase mémorise des n-uplets constitués de colonnes (champs) :

• Les n-uplets sont identifiés par une clé.
• À l’affichage, les colonnes d’un même n-uplet sont affichées successivement.

25
 HBase, c’est quoi ?
• HBase est un SGBD distribué, orienté colonne qui fournit l'accès en temps réel, aussi bien en lecture qu'en écriture, aux

données stockées sur le HDFS.

• HBase est perçu par HDFS comme un client à qui il fournit les données. HBase a été conçu pour :

• Ne fonctionner que sur un cluster Hadoop,

• Être linéairement scalable, c'est-à-dire supporte l'ajout de nœuds au cluster,

• Stocker de très grosses volumétries de données épaves, c'est-à-dire des données à structure irrégulière, avec plein

de valeurs nulles,

• Fournir un accès en temps réel à cette grosse volumétrie de données aussi bien pour les opérations de lecture que

d'écriture sur le HDFS,

• S'appuyer sur des modèles de calculs distribués tels que le MapReduce (et donc tous ses langages d'abstraction tels

que Hive, Pig,…) pour l'exploitation de ses données.

26
Dans le NoSQL, le schéma de « base de données » à concevoir a pour but d'assurer la distribution

du stockage et faciliter l'accès des données dans un cluster pour les traitements parallèles

27
 Concepts HBase
• Le concept de base de données en HBase est la table HBase.
• Développer et modéliser une base de données en HBase revient à implémenter une ou plusieurs tables HBase.
• Une table HBase est un tableau multidimensionnel de données distribué et persisté sur le HDFS sous forme de fichiers
spécifiques appelés HFiles.
• Les concepts qui forment une table HBase sont :
• Row key / clé de ligne : chaque ligne du tableau HBase est identifiée de façon unique par une clé qui représente une
colonne interne à la structure de la table HBase,
• Column family / famille de colonne : les valeurs d'un ensemble de colonnes physiquement colocataires,
stockées dans le même fichier. Chaque famille de colonnes est persistée dans un HFile séparé, et chaque
HFile possède son propre jeu de paramètres de configuration. Cette dimension est très importante, car elle
définit la façon dont les données sont persistées et accédées.
• Column qualifier / colonne : c'est l'adresse d'une série de données dans une famille de colonnes (comme les
colonnes d'un tableau)
28
 Concepts HBase
• Les concepts qui forment une table HBase sont :
• Cell / cellule ou valeur : Les données sont stockées dans les cellules. Les cellules HBase ne stockent pas
uniquement les données textuelles ou des nombres. Vous pouvez stocker dans chaque cellule, un PDF, une
vidéo, une image, un texte, … sous forme de type générique Byte[]. Vous n'avez pas à typer les colonnes en
Hbase,
• TimeStamp : HBase ne fait pas de différence entre les ajouts de lignes dans la table (opération d'écriture) et
leur mise à jour (opération de modification d'une ligne). Tout comme dans le HDFS et dans un Data
Warehouse, chaque opération de mise à jour est un ajout d'une nouvelle version de la même ligne de
données. Le TimeStamp c'est la date et l'heure, à la milliseconde près, auquelle la mise à jour a été
effectuée. Par défaut, HBase stocke les trois dernières versions d'une valeur de colonne (tout en
supprimant automatiquement les anciennes versions). La profondeur du "Versioning" peut être contrôlée
lors de la création de la table.

29
Concepts HBase

30
Concepts HBase

31
Exemple Table HBase

32
 Schéma multidimensionnel
{
"00001":
{ "Contact":
"Personnel": {
{ "Téléphone":
"Prénom": {
{ "10/09/2011 13:05:17:09": "06 90 98 76 52"
"10/09/2011 13:05:17:09": "Juvénal" }
}
"ville d'habitation":
{
"Âge": "10/09/2011 13:05:17:09": "Douala",
{ "20/09/2013 15:00:05:09": "Lille",
"10/09/2011 13:05:17:09": "22", "30/10/2016 16:18:50:10": "Paris"
"20/09/2013 15:00:05:09": "25" }
} }
} ………..
}

33
 Structure interne

• Pour obtenir une grande efficacité, les données des tables HBase sont séparées en régions.

• Une région contient un certain nombre de n-uplets contigus (un intervalle de clés successives).

• Une nouvelle table est mise initialement dans une seule région. Lorsqu’elle dépasse une certaine

limite, elle se fait couper en deux régions au milieu de ses clés.

• Chaque région est gérée par un « Serveur de Région »

• Ces serveurs sont distribués sur le cluster (un par machine par exemple)

• Un même serveur de région peut s’occuper de plusieurs régions de la même table.

• Au final, les données sont stockées sur HDFS.

34
Régions HBase

35
 Architecture d’un cluster HBase
• HBase est un SGBD distribué. Il s'installe sur un cluster d'ordinateurs.
• Comme Hadoop, HBase s'installe sur un cluster en architecture
Maître/Esclave.
• Le nœud maître s'appelle le HMaster, et les nœuds esclaves s'appellent
les RegionsServers.
• Le stockage des données est distribué sur les RegionsServers qui sont
gérés par le HMaster.
• Le HMaster gère les métadonnées des tables HBase et coordonne
l'exécution des activités des RegionsServers,
• RegionsServers effectuent les opérations de lecture/écriture de
données dans le cluster.
• La gestion du volume de données se fait par l'ajout des RegionsServers
supplémentaires dans le cluster.
36
 Architecture d’un cluster HBase
Physiquement, HBase est composé de trois types de
serveurs de type Master/Slave.
• Region Servers : permettent de fournir les données
pour lectures et écritures. Pour accéder aux données,
les clients communiquent avec les RegionServers
directement.
• HBase HMaster : gère l'affectation des régions, les
opérations de création et suppression de tables.
• Zookeeper : permet de maintenir le cluster en état.

Le DataNode de Hadoop permet de stocker les données que le Region Server gère. Toutes les données de
HBase sont stockées dans des fichiers HDFS. Les RegionServers sont colocalisés avec les DataNodes.
Le NameNode permet de maintenir les métadonnées sur tous les blocs physiques qui forment les fichiers.

37
 Caractéristiques de HBase
• Les n-uplets sont classés selon leur clé, dans l’ordre alphabétique.

• Cette particularité est extrêmement importante pour la recherche d’informations.

• On est amené à définir les clés de façon à rapprocher les données connexes.

• Les n-uplets de HBase peuvent être incomplets.

• Les colonnes ne sont pas forcément remplies pour chaque n-uplet, au point qu’on peut même avoir des colonnes

différentes pour les n-uplets.

• Ce ne sont pas des valeurs null, mais des colonnes carrément absentes.

• On qualifie ça de « matrice creuse » (sparse data).

• Les colonnes appelées qualifiers sont groupées en familles.

• Les valeurs, appelées cellules sont enregistrées en un certain nombre de versions, avec une date appelée timestamp.

38