SlideShare une entreprise Scribd logo
1  sur  62
Introduction à HADOOP-HBASE
Blandine LARBRET
2015
Blandine LARBRET
Ingénieur biologiste reconvertie en informatique, je suis à ce jour
étudiante en alternance pour obtenir un Master2 Software Development.
Au cours de mes 2 ans d'alternance, j'ai découvert le monde pas si
simple de HBase que j'ai voulu partager.
Cette présentation est donc juste une introduction aux différentes Big
Data et plus précisément à Hadoop et HBase. Les schémas que j'ai
réalisé traduisent ma propre compréhension de ce modèle de base de
données, acquise à partir de toute la littérature que j'ai pu explorer.
En espérant que ça puisse vous éclairer...
larbret.blandine@gmail.com
Plan
Les différentes Big Data
Hadoop
HBase
BIG DATA
Historique
1 Go
1 To
= 103 Go
1 Po
= 106 Go
1 Eo
= 109 Go
1 Zo
= 1012 Go
1982
1970
BD relationnelle
1997
notion de Big Data
1999
Big Analytics
1996
explosion du web
2010
1 Yo
= 1015 Go
www.winshuttle.fr/chronologie-big-data/
Besoin croissant en capacité
de stockage numérique
Futur
Contexte
Contexte
Exemples
Données mondiales => 1,8 Zo en 2011
Emails => 250 milliards / jour (80% de spams)
Vidéos => 72h déposées / min sur Youtube
Boeing => 20 To / heure de données
www.santepublique-editions.fr/objects/cyres-big-data-pre-769-sentation
-tables-rondes-ingensi.pdf
Domaines d’application
Entreprises du web
Google, Facebook, Twitter, Amazon, Ebay ...
Grands groupes
Sécurité Sociale, INPI, banques...
Analyses de données
statistiques pour les entreprises privées,
sondages d’opinion, études marketing...
Recherche scientifique
séquençage du génome humain, astronomie...
Définition des Big Data
Une Big Data est une base de données distribuée sur plusieurs
machines d'un même réseau.
Du fait de sa configuration, les jointures connues sous les SGBDR
n'existent plus, rendant le langage SQL sans intérêt. C'est pourquoi
les Big Data étaient initialement appelées Bases de Données
NoSQL, pour "Not Only SQL", sous-entendues "non relationnelles".
Mais le terme de NoSQL sonnant comme un affront aux
administrateurs de BD classiques, il a cédé la place à celui de Big
Data.
La notion de Big Data est apparue en 1997, mais la technologie fut
développée à partir de 2003 par Google.
http://www.stechfrites.com/content/le-mouvement-nosql
Définition des Big Data
Nœud : serveur appartenant au réseau d'une Big Data
Cluster : ensemble des serveurs d'un même réseau Big Data
Les nœuds peuvent être physiquement hétérogènes (configuration
hardware différente). Les systèmes de gestion des Big Data gèrent
cette hétérogénéité.
Définition des Big Data
base de données
relationnelle
= stockage modéré
base de données
distribuée
= stockage illimité
BIG DATA
cluster
nœud
Dénormalisation
Le stockage illimité sur un réseau distribué permet la réplication des
données, ce qui optimise leur lecture et assure leur sauvegarde même
en cas de panne matérielle. C'est la dénormalisation.
En BD classique, la maintenance d'un tel système est compliquée en cas
de modification. Mais les systèmes de gestion des Big Data gèrent
totalement les réplications.
data
http://www.thecodingmachine.com/fr/d%C3%A9normalisation-du-mod%C3%A8le
-de-donn%C3%A9es
Les 3 V
Volume
gros volume de données à stocker > 1 Petaoctet
Variété
différents type de données => brutes, texte, images...
Vélocité
rapidité de traitement en écriture et lecture
Laney D. - 2001 - "3D Data Management: Controlling Data Volume, Velocity, and Variety"
META group Inc.
Propriétés ACID
Les BD relationnelles doivent respecter toutes les propriétés ACID :
- Atomicité : les requêtes reçues par la base doivent être complètes
sous peine d'être non traitées
- Cohérence : les requêtes doivent respecter l'état de validité de la base
(respect des contraintes, des mises à jour...)
- Isolation : les requêtes sont indépendantes les unes des autres lors
d'un envoi simultané
- Durabilité : les modifications de la base doivent être effectuées en
priorité avant toute autre action pour permettre la sauvegarde de ces
changements
Les Big Data ne répondent pas à ces propriétés. Mais elles respectent
le théorème CAP.
Théorème CAP
Il est impossible pour tout système de garantir en même temps les
trois contraintes suivantes, seules 2 peuvent être respectées
simultanément :
- Cohérence (= Consistency) : tous les nœuds du système voient
exactement les mêmes données au même moment
- Disponibilité (= Availability) : garantie que toutes les requêtes
reçoivent une réponse
- Résistance au morcellement (= Partition Tolerance) : aucune
panne moins importante qu'une coupure totale du réseau ne doit
empêcher le système de répondre correctement (ou encore : en cas de
morcellement en sous-réseaux, chacun doit pouvoir fonctionner de
manière autonome).
A. Fox, E.A. Brewer - 1999 - "Harvest, Yield and Scalable Tolerant Systems"
Proc. 7th Workshop Hot Topics in Operating Systems - p.174-178
Propriétés ACID vs Théorème CAP
Availability Partition
tolerance
Consistency
CA
AP
CP
Big Data
Atomicité
Cohérence
Isolation
Durabilité
BD relationnelle
4 / 4
2 / 3
Les plus connues
Availability Partition
tolerance
Consistency
CA
AP
CP
http://nosql-database.org/
Modèle orienté Objet
Ce modèle permet de stocker des objets, avec leurs attributs, leurs
relations d'héritage et leurs références vers d'autres objets, de manière
persistante. Certains systèmes permettent même d'exécuter les
méthodes des objets directement dans la base de données.
Ce modèle est, en pratique, plutôt proche du modèle relationnel et n'est
pas exclusif aux Big Data. D'ailleurs, certaines SGBDR permettent de
choisir entre relationnel et orienté objet.
Modèle orienté Objet
relationnel orienté Objet
Modèle orienté Clé-Valeur
Ce modèle est une simple correspondance entre une clé et une
valeur, comme une table de hachage à la différence qu'en Big Data, le
stockage se fait sur un réseau distribué.
Il est essentiellement utilisé en tant que cache, pour stocker des
données semi-persistantes qui ne doivent être conservées qu'un
temps donné.
Modèle orienté Colonne
Il s'agit d'un modèle structuré où l'équivalent de plusieurs tables d'une
base de données relationnelle est réuni dans une seule grande table
sous forme de colonnes, éliminant ainsi les jointures.
Ce modèle permet d'enregistrer des volumes très importants de
données simples, généralement sur des clusters de quelques dizaines
à quelques centaines de serveurs, souvent répartis sur plusieurs
datacentres. Il est donc destiné pour de très gros stockages comme
Google ou Facebook.
Modèle orienté Document
Une clé primaire est associée à une structure de plusieurs valeurs de
types différents, appelée document. Chaque clé peut être associée à
une structure différente. Les données sont alors organisées dans des
fichiers au format XML ou JSON.
Ce modèle est utile pour le stockage de données hétérogènes.
document
type A
type B
type A
Modèle orienté Graphe
Ces systèmes sont prévus pour stocker des graphes (au sens de la
théorie des graphes), avec des nœuds comportant des attributs et des
liens entre les différents nœuds.
L'exemple type est le stockage d'un réseau social où il est possible de
parcourir les relations entre utilisateurs.
A
BC
D
FlockDB
HADOOP
Historique
En 2004, Google publie un article de recherche présentant son nouvel
algorithme MapReduce, conçu pour réaliser des opérations analytiques
à grande échelle sur un grand cluster de serveurs via son système de
fichier Google Filesystem (GFS).
Doug Cutting, qui travaillait alors sur le développement du moteur de
recherche libre Apache Lucene, s’est alors emparé des concepts décrits
dans l’article et a décidé de répliquer les outils développés par Google
en version open source, ce qui est devenu le projet Hadoop en 2006.
Hadoop est le nom de l’éléphant qui servait de doudou à son fils.
J. Dean, S. Ghemawat (Google Inc.) - 2004
"MapReduce : Simplified data processing on large clusters"
Sixth Symposium on Operating System Design and Implementation - San Francisco, CA
MapReduce
Utilisé pour réduire les temps de lecture dans une base de données
distribuée, cet algorithme repose sur la parallélisation du travail de
recherche à travers plusieurs serveurs via deux fonctions
principales : Map et Reduce, qui sont des méthodes bloquantes
(bloquent le processus tant que leur exécution n'est pas terminée).
La recherche est en fait coupée en morceaux répartis sur plusieurs
serveurs qui travaillent en même temps. Le résultat final est donc
obtenu plus rapidement ; et plus il y a de serveurs, plus le résultat est
rapide.
Bien qu'Hadoop soit sa première implémentation, le MapReduce est
aujourd'hui utilisé dans de nombreux autres frameworks.
MapReduce
Architecture
Son organisation s'appuie sur un système de serveurs maître-esclaves.
Ainsi, lors d'une requête, le serveur-maître, appelé JobTracker,
procède à l'analyse de toutes les données de la base et les scinde en
plus petits blocs de données (= splitting) pour les répartir à plusieurs
serveurs-esclaves, appelés TaskTrackers.
Par défaut, la taille des blocs distribués est de 64 Mo.
Un serveur-maître secondaire sert de secours en cas de défaillance du
serveur-maître principal. Le JobTracker y réalise alors régulièrement
des copies des blocks et de leur attribution aux différents Tasktrackers.
MapReduce
Architecture
Le temps de réponse des TaskTrackers donne le Ration Performance
(RP) collecté par le JobTracker. Ce ratio est important en milieu
distribué hétérogène. Il permet au JobTracker d'adapter la quantité de
blocs de données fournie à un TaskTracker. Ainsi sur les machines
performantes travailleront plus que les machines moins performantes,
car dès qu'un bloc a fini d'être analysé, le JobTracker en fournit un
nouveau.
Le JobTracker réalise en continu une mesure des RP des chaque
serveurs-esclaves. Dès que le RP d'un TaskTracker baisse, sa charge
de travail est allégée et répartie sur des TaskTrackers plus performants
jusqu'à ce que son RP retrouve sa valeur normale.
Le JobTracker peut ainsi remplacer un serveur-esclave défaillant par un
autre en assignant à ce dernier le bloc de données qui n'a pas retourné
de résultat, donc celui du TaskTracker défaillant.
MapReduce
Architecture
2 modes de lecture peuvent être utilisés pour lire les données stockées
dans la base :
- mode direct où les données sont directement lues depuis le
disque local, avec transfert depuis la mémoire cache vers la mémoire
du lecteur en utilisant l'accès direct à la mémoire ;
- mode streaming où le lecteur lit les données depuis un autre
processus en cours d'exécution à l'aide de moyen de communication
comme TCP/IP ou JDBC.
D'après certains tests, la différence de performance entre ces deux
modes est faible (10%).
http://fr.wikipedia.org/wiki/MapReduce
copie des blocs de
données et de leur
attribution
JobTracker
(serveur-maître)
TaskTracker
(serveur esclave)
serveur-maître
secondaire
parsing (Map)
en direct
en streaming
splitting (Map)
64 Mo
RESULTAT
DATA
MapReduce
Architecture
MapReduce
Principe
La fonction Map commence par un décodage des blocs de données
reçus. C'est le parsing, qui peut être alors de deux types :
- décodage immuable :
n données instancient n objets de programmation (donc 1
objet/donnée). Ces objets sont non modifiables, donc immuables.
- décodage mutable :
n données instancient 1 seul objet qui est réutilisé pour toutes les
instanciations. Il s'agit donc d'un objet mutable.
Le décodage immuable est plus lent que le décodage mutable car il
produit un grand nombre d'objets immuables durant le processus de
décodage. La création de tous ces objets augmentent la charge de
travail des processeurs.
Jiang D, Ooi BC, Shi L, Wu S - 2010 - "The performance of MapReduce : an in-depth study"
Proceedings of the VLDB Endowment 3 (1-2), 472-483
MapReduce
Principe
Les données décodées sont réorganisées en couples clé-valeur (=
shuffle). Ces couples sont ensuite triés selon leur clé (= sort). Le
résultat de la fonction Map donne donc un regroupement de plusieurs
valeurs pour une même clé.
La fonction Reduce compressent ces groupes clé-valeurs de sorte
qu'une clé soit de nouveau associée à une seule valeur. Cette
compression est alors renvoyée au JobTracker en guise de résultat qui
centralise tous les résultats des différents bloc pour constituer la
réponse à la requête.
MapReduce
Principe
Data Splitting Shuffle Sort Reduce Result
Map
http://blog.inovia-conseil.fr/?p=46
MapReduce
Configuration
MapReduce est configurable presque à tous les niveaux :
- choix du JobTracker, des TaskTrackers et du serveur-maître
secondaire
- mode de parsing
- taille des blocks lors du splitting (64 Mo par défaut)
- espace mémoire utilisé pour fonctionner
- fonctions map et reduce
http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-
core/MapReduceTutorial.html
http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-
core/MapredCommands.html
Architecture Hadoop
Hadoop est un framework développé en Java. Son HDFS (Hadoop
File System) est un système de fichiers en cluster conçu pour stocker
de très gros volumes de données sur un grand nombre de machines.
On trouve :
- un serveur-maître, appelé NameNode, qui enregistre dans un fichier
la localisation des données réparties en blocs dans le cluster. Ce
fichier de métadonnées a une taille configurée par défaut à 256 Mo.
- un serveur-maître secondaire, qui gère l'historique des modifications
faites dans le fichier de métadonnées (WAL : Write Ahead Log). Ce
NameNode secondaire permet la continuité du fonctionnement du
cluster Hadoop en cas de panne du NameNode principal.
- des serveurs-esclaves, appelés DataNodes, qui stockent les
données scindées en petits blocs de 64 Mo par défaut. Ces blocs
sont des fichiers de données stockées en bytes, appelés DataFiles.
Architecture Hadoop
L'HDFS est conçu pour assurer la sauvegarde des données en
répliquant l’ensemble des données écrites sur le cluster.
Par défaut, chaque donnée est écrite sur 3 DataNodes différents.
Hadoop peut être lancé selon 3 modes :
- mode standalone, pour tourner sur un seul serveur
- mode pseudo-distribué où le principe HDFS est contenu sur une
seule machine et donne l'illusion d'un mode distribué
- mode distribué, où l'HDFS est réparti sur un réel cluster physique.
Architecture Hadoop
NameNode
(serveur maître)
NameNode
secondaire
Metadonnées
256 Mo max
par défaut
WAL
archivage de
l'historique
DataFiles
64 Mo max
par défaut
3 réplications
des données
par défaut
DataNode
(serveur esclave)
HDFS
Hadoop
File
System
Configuration Hadoop
Hadoop est conçu pour des serveurs Linux.
Pour des tests, il est possible d'utiliser Windows avec Cygwin.
http://ebiquity.umbc.edu/Tutorials/Hadoop/00%20-%20Intro.html
Hadoop est configurable pour :
- le choix du NameNode et de son serveur-maître secondaire
- la quantité et le choix des DataNodes
- la taille des DataFiles
- la taille du fichier de métadonnées dans le NameNode
- le nombre de réplication par serveur-esclave
Configuration Hadoop
configuration du cluster
variables d'environnement
configuration des fichiers
http://hadoop.apache.org/docs/r1.1.2/cluster_setup.html
configuration du MapReduce
identification des NameNodes
identification des DataNodes
https://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml
http://hadoop.apache.org/docs/r1.1.1/mapred-default.html
HBASE
Historique
- 2004 -
Google publie le MapReduce (algorithme pour les sytèmes distribués)
- 2006 -
Doug Cutting crée Hadoop (framework de stockage en cluster)
- 2006 -
Google utilise Hadoop pour créer BigTable (SGBD BigData propriétaire)
- 2007 -
création de HBase (= BigTable en version open source)
par Powerset qui contribue au developpement de Hadoop
F. Chang, R.E. Gruber et al. (Google Inc.) - 2006
"Bigtable: A Distributed Storage System for Structured Data"
Seventh Symposium on Operating System Design and Implementation - Seattle, WA
Historique
- 2008 -
Powerset se fait racheter par Microsoft qui abandonne le développement
de HBase (car open source)
- 2008 -
Hadoop devient le projet principal de la fondation Apache
- 2010 -
HBase devient le projet principal de la fondation Apache
L. George - 2011
"HBase the Definitive Guide" - O'Reilly
Architecture
HBase est un système de gestion des données pour un
environnement distribué qui doit être couplé au gestionnaire de fichiers
Hadoop.
Hbase gère la partie logique, tandis qu'Hadoop gère la partie physique.
C'est un modèle de stockage BigData orienté colonne, basé sur le
principe de BigTable de Google.
Architecture
Aspect logique
Les données sont gérées au sein de grandes tables (appelées HTable)
composées de lignes (nommées row) et de familles de colonnes
(family). Les familles de colonnes sont sous-divisées en colonnes
(qualifier). Les lignes sont des identifiants dont la valeur est unique, soit
l'équivalent de la clé primaire dans le mode relationnel.
Comparaison avec un SGBDR :
HTable => ensemble de toutes les tables de la base
family => une table
qualifier => un attribut
row => clé primaire
Du fait que toutes les données sont logiquement placées dans la même
table, les jointures sont inutiles.
http://hbase.apache.org/book.html#datamodel
Architecture
Aspect logique
Les données (dites value) sont stockées pour une ligne et une colonne
précises. Mais plusieurs écritures peuvent être effectuées pour un même
emplacement. On parle alors de version de données à des temps
différents (timestamp).
Par défaut, le timestamp est configuré à 3 versions. Il peut être
modifiable, mais il est déconseillé d'enregistrer au-delà de 100 versions.
L'ensemble des informations (ou coordonnées) d'une donnée est
appelée keyValue et correspond donc à :
KeyValue = row + family + qualifier + timestamp + value
Les données sont toujours enregistrées sous la forme de keyValue, donc
avec leurs coordonnées complètes.
Architecture
Aspect logique
Configuration
Peuvent être configurés :
- les rôles des serveurs (master, slaves)
- le zookeeper (nb d'instances, temps de session)
- le memstore
- la compression des storefiles
...
http://hbase.apache.org/book.html#important_configurations
Architecture
Aspect physique
HBase est basé sur la même architecture physique qu'Hadoop puisque
ce dernier gère le stockage physique. On retrouve donc une
configuration distribuée en cluster de plusieurs nœuds qui peuvent être
hétérogènes au niveau hardware.
Le principe est donc le même que celui d'Hadoop. Seuls les noms
diffèrent. Ainsi :
Architecture HADOOP HBASE
serveur-maître namenode regionserver
serveur-esclave datanode region
fichier de stockage datafile storefile
Architecture
Aspect physique
Avant d'être stockées à travers le cluster, les données à stocker
transitent par un framework fourni avec HBase : le zookeeper.
Il coordonne la destination d'archivage des données dans un système
distribué.
Ces données sont ensuite réparties sur les différents serveurs (Region)
du cluster, où elles sont triées et compactées par le memstore de
HBase.
Pour une meilleure gestion de l'espace mémoire, les données sont
toujours sauvegardées sous forme de bytes. Elles sont stockées dans
les regionservers sous forme de blocs de données (les storefiles)
d'une taille configurée par défaut de 64 Mo (configuration faite via
Hadoop).
Architecture
Aspect physique
La répartition des données sur les regionserveurs se fait en 2 étapes :
- les lignes d'une HTable sont scindées en paquets réguliers par le
regionserveur,
- chaque paquet est dirigé chacun vers un serveur-esclave où il est de
nouveau divisé par le memstore selon les colonnes de la HTable.
Les données issues de la même famille de colonne sont alors stockées
dans un même storefile (ou datafile pour Hadoop) dans la limite de taille
configurée (64 Mo par défaut selon Hadoop). Si la taille d'un paquet
produit par le memstore venait à avoir une taille trop importante, le
dépassement formerait un nouveau storefile. De même, si un datanode
venait à être surchargé, il serait également redivisé à travers d'autres
datanodes afin de répartir la charge.
Architecture
Aspect physique
Design
Eléments critiques
Les performances de HBase sont plutôt tournées sur la lecture des
données, via le MapReduce et la dénormalisation. D'après la façon de
HBase de stocker les données, 2 éléments influent sur la vitesse de
lecture :
- choix des colonnes :
si une requête trouve son résultat dans 2 colonnes issues de 2
familles différentes, la recherche se fera sur 2 storefiles
différents, augmentant ainsi le temps de lecture.
- choix des lignes :
les noms des lignes représentant la clé primaire, leur choix doit
être le plus judicieux possible pour un accès rapide aux données
selon les requêtes estimées.
exemple :
temps de lecture différent selon une row structurée
nom+date ou date+nom
http://hbase.apache.org/book.html#schema
Design
Colonnes
Les données sont enregistrées par leur keyValue, donc avec toutes leurs
coordonnées. De ce fait pour toutes les valeurs d'une même ligne, le
nom des families, qui représente le nom du fichier HDFS au format
string, et celui des qualifiers, stocké en bytes[ ] dans le fichier, seront
systématiquement répétés. Pour optimiser la place mémoire, il est donc
recommandé d'employer des noms de familles de colonnes les plus
petits possible (donc en un seul caractère) et de rentabiliser ceux des
colonnes en les utilisant comme un complément d'information.
Exemple :
ligne (ou row) = date arrondie à l'heure
familles de colonnes = t (température d'un composant),
e (état activé ou non du composant)
colonne (ou qualifier) = temps en minutes
N. Dimiduk, A. Khurana- 2012
"HBase in action" - Manning
Design
Colonnes
Le nombre de colonnes (qualifiers) peut être considéré comme illimité,
bien qu'il soit plus ou moins lié à la taille des fichiers HDFS.
Mais il n'est pas conseillé de créer trop de familles de colonnes :
HBase a du mal à gérer plus de 3 families pour une même table.
http://hbase.apache.org/book/book.html
Design
Lignes (= clé primaire)
Les enregistrements des lignes dans les fichiers HDFS se font de
manière séquentielle. Il faut donc penser à ce qu'ils produisent un
stockage ordonné. Par exemple, un tri sur le nom des lignes par ordre
alphabétique après stockage n'est pas possible.
Il faut aussi tenir compte de la répartition des lignes dans l'HDFS.
Hadoop stockant des blocs de lignes sur un même DataNode, il peut être
intéressant de regrouper les données selon certaines requêtes et donc
choisir des noms de lignes en conséquence.
Enfin, comme pour les colonnes, les rows sont répétées dans la
keyValue de chaque donnée. Elles doivent donc être utilisées comme un
moyen supplémentaire de stocker de l'information.
Communication
HBase est écrit en Java. Il y a donc une API Java. Mais d'autres moyens
de communication avec cet outil ont été mis en place :
- HBase shell
- Hive
- Pig
- API JRuby
- API Cascading
Communication
Hive
Initialement développé par Facebook, Hive est aujourd'hui un projet open
source Apache qui offre un langage similaire au SQL, le HiveQL, pour
effectuer des requêtes au sein d'un système distribué.
Hive emploie un gestionnaire de stockage qui peut donc intervenir sur les
données stockées dans le HDFS, mais également dans d'autres
sources. De ce fait il est capable d'effectuer des travaux de MapReduce.
Ainsi Hive permet aux utilisateurs peu à l'aise avec la manipulation du
MapReduce de pouvoir tout de même utiliser ce modèle de recherche au
travers de requêtes pseudo-SQL.
Depuis la version 0.6.0, Hive est également livré avec un gestionnaire
pour HBase. Il est alors possible de définir des HiveTables dans le
langage HiveQL qui seront fidèlement converties en HTables.
Communication
Pig
Développé au départ par Yahoo, Pig est devenu lui aussi un projet
Apache. Il est employé pour analyser les données d'une Big Data à
travers le langage de requêtes Pig Latin. Comme Hive, il cache
l'éventuelle complexité du modèle MapReduce derrière un langage de
haut-niveau plus intuitif pour l'utilisateur. Le Pig Latin est en effet un
langage de programmation orienté flux de données qui permet de
représenter les résultats sous forme de graphes, mettant alors en
évidence un certain nombre de propriétés comme le parallélisme
disponible ou la localité des données. Ce langage est donc l'un des
avantages principal de Pig.
Un autre avantage est l'optimisation des tâches que cet outil propose en
automatisant leur exécution. Enfin, les utilisateurs peuvent créer leurs
propres fonctions pour gérer un traitement de données particulier.
Communication
HBase Shell
C'est l'interface système (shell) qui permet d'administrer la base.
Elle est activée par la commande hbase shell et quittée par la commande
exit.
Ce shell est basé sur JRuby qui est une implémentation du langage
Ruby en Java. Il utilise donc le shell Ruby, IRB (Interactive Ruby Shell),
auquel sont ajoutées des commandes spécifiques basées sur l'API Java.
HBase Shell
Commandes principales
créer une table T avec ses familles de colonnes F1 et F2
create 'T', 'F1', 'F2'
déverrouiller une table disable 'T' ,
déverrouiller toutes les tables  disable_all '*.*'
ajouter une famille de colonnes à une table alter 'T', NAME =>'F3'
reverrouiller une table  enable 'T'
ajouter ou remplacer une valeur à certaines coordonnées
 put 'T', 'R1', 'F1:C1', 'V1'
savoir si une table existe  exist 'T'
compter le nombre de valeurs dans des colonnes
 count 'T', {COLUMNS => [F1:C2, F1:C3]}
HBase Shell
Commandes principales
lister toutes les tables  list
décrire une table  describe 'T'
lire toutes les lignes d'une table  scan 'T'
lire des familles de colonnes  scan 'T', {COLUMNS => ['F1', 'F2']}
lire des colonnes  scan 'T', { COLUMNS => [F1:C3', F2:C1']}
lire des colonnes au départ d'une ligne précise
 scan 'T', { COLUMNS => [F1:C3', F2:C1'], STARTROW => 'R2'}
lire des colonnes jusqu'à une ligne précise
 scan 'T', { COLUMNS => [F1:C3', F2:C1'], STOPROW => 'R6'}
HBase Shell
Commandes principales
lire une ligne avec toutes ses valeurs  get 'T', 'R3'
lire les valeurs d'une ligne et d'une famille de colonnes
 get 'T', 'R2', 'F1'
lire les valeurs d'une ligne et d'une colonne  get 'T', 'R1', 'F2:C3'
vider une table  truncate 'T'
supprimer une table  drop 'T'
supprimer une famille de colonnes  alter 'T', delete => 'F1'
supprimer une ligne entière  deleteall 'T', 'R1'
supprimer une valeur via ses coordonnées  delete 'T', 'R1', 'F1:C2'

Contenu connexe

Tendances

Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1Amal Abid
 
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...Hatim CHAHDI
 
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-ReduceLilia Sfaxi
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQLLilia Sfaxi
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceLilia Sfaxi
 
DataWarehouse
DataWarehouseDataWarehouse
DataWarehousenzuguem
 
Cours data warehouse
Cours data warehouseCours data warehouse
Cours data warehousekhlifi z
 
Chapitre1 introduction
Chapitre1 introductionChapitre1 introduction
Chapitre1 introductionMouna Torjmen
 
Big Data, Hadoop & Spark
Big Data, Hadoop & SparkBig Data, Hadoop & Spark
Big Data, Hadoop & SparkAlexia Audevart
 
Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture Lilia Sfaxi
 
Business Intelligence : introduction to datawarehouse
Business Intelligence : introduction to datawarehouseBusiness Intelligence : introduction to datawarehouse
Business Intelligence : introduction to datawarehouseAlexandre Equoy
 
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 coursHatim CHAHDI
 

Tendances (20)

Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1
 
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...
 
Technologies pour le Big Data
Technologies pour le Big DataTechnologies pour le Big Data
Technologies pour le Big Data
 
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
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQL
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-Reduce
 
Une introduction à Hive
Une introduction à HiveUne introduction à Hive
Une introduction à Hive
 
Cours Big Data Part I
Cours Big Data Part ICours Big Data Part I
Cours Big Data Part I
 
DataWarehouse
DataWarehouseDataWarehouse
DataWarehouse
 
Hadoop
HadoopHadoop
Hadoop
 
Cours data warehouse
Cours data warehouseCours data warehouse
Cours data warehouse
 
Chapitre1 introduction
Chapitre1 introductionChapitre1 introduction
Chapitre1 introduction
 
Les BD NoSQL
Les BD NoSQLLes BD NoSQL
Les BD NoSQL
 
Hive ppt (1)
Hive ppt (1)Hive ppt (1)
Hive ppt (1)
 
Big Data, Hadoop & Spark
Big Data, Hadoop & SparkBig Data, Hadoop & Spark
Big Data, Hadoop & Spark
 
Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture
 
Business Intelligence : introduction to datawarehouse
Business Intelligence : introduction to datawarehouseBusiness Intelligence : introduction to datawarehouse
Business Intelligence : introduction to datawarehouse
 
Une Introduction à Hadoop
Une Introduction à HadoopUne Introduction à Hadoop
Une Introduction à Hadoop
 
Hadoop
HadoopHadoop
Hadoop
 
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
 

En vedette

NoSQL at Twitter (NoSQL EU 2010)
NoSQL at Twitter (NoSQL EU 2010)NoSQL at Twitter (NoSQL EU 2010)
NoSQL at Twitter (NoSQL EU 2010)Kevin Weil
 
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache SparkPlateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache SparkALTIC Altic
 
Présentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopPrésentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopJoseph Glorieux
 
NoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationNoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationMicrosoft Technet France
 
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à HadoopCasablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à HadoopBenoît de CHATEAUVIEUX
 
Big Data Analytics for connected home
Big Data Analytics for connected homeBig Data Analytics for connected home
Big Data Analytics for connected homeHéloïse Nonne
 
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième éditionEnquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième éditionHelloWork
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQLSamy Dindane
 
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDIPrésentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDIHaShem Selmi
 
Architectures techniques NoSQL
Architectures techniques NoSQLArchitectures techniques NoSQL
Architectures techniques NoSQLOCTO Technology
 
Valtech - Du BI au Big Data, une révolution dans l’entreprise
Valtech - Du BI au Big Data, une révolution dans l’entrepriseValtech - Du BI au Big Data, une révolution dans l’entreprise
Valtech - Du BI au Big Data, une révolution dans l’entrepriseValtech
 
Big Data : concepts, cas d'usage et tendances
Big Data : concepts, cas d'usage et tendancesBig Data : concepts, cas d'usage et tendances
Big Data : concepts, cas d'usage et tendancesJean-Michel Franco
 
Big data - Cours d'introduction l Data-business
Big data - Cours d'introduction l Data-businessBig data - Cours d'introduction l Data-business
Big data - Cours d'introduction l Data-businessVincent de Stoecklin
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherLilia Sfaxi
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingLilia Sfaxi
 

En vedette (20)

NoSQL at Twitter (NoSQL EU 2010)
NoSQL at Twitter (NoSQL EU 2010)NoSQL at Twitter (NoSQL EU 2010)
NoSQL at Twitter (NoSQL EU 2010)
 
Une introduction à MapReduce
Une introduction à MapReduceUne introduction à MapReduce
Une introduction à MapReduce
 
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache SparkPlateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
 
Présentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopPrésentation Big Data et REX Hadoop
Présentation Big Data et REX Hadoop
 
NoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationNoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisation
 
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à HadoopCasablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
 
Big Data Analytics for connected home
Big Data Analytics for connected homeBig Data Analytics for connected home
Big Data Analytics for connected home
 
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième éditionEnquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
Hadopp Vue d'ensemble
Hadopp Vue d'ensembleHadopp Vue d'ensemble
Hadopp Vue d'ensemble
 
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDIPrésentation pfe Big Data Hachem SELMI et Ahmed DRIDI
Présentation pfe Big Data Hachem SELMI et Ahmed DRIDI
 
Introduction à HDFS
Introduction à HDFSIntroduction à HDFS
Introduction à HDFS
 
Un introduction à Pig
Un introduction à PigUn introduction à Pig
Un introduction à Pig
 
Architectures techniques NoSQL
Architectures techniques NoSQLArchitectures techniques NoSQL
Architectures techniques NoSQL
 
Valtech - Du BI au Big Data, une révolution dans l’entreprise
Valtech - Du BI au Big Data, une révolution dans l’entrepriseValtech - Du BI au Big Data, une révolution dans l’entreprise
Valtech - Du BI au Big Data, une révolution dans l’entreprise
 
Big Data : concepts, cas d'usage et tendances
Big Data : concepts, cas d'usage et tendancesBig Data : concepts, cas d'usage et tendances
Big Data : concepts, cas d'usage et tendances
 
Big data - Cours d'introduction l Data-business
Big data - Cours d'introduction l Data-businessBig data - Cours d'introduction l Data-business
Big data - Cours d'introduction l Data-business
 
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
 
Introduction à Hadoop
Introduction à HadoopIntroduction à Hadoop
Introduction à Hadoop
 

Similaire à Hadoop Hbase - Introduction

NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxNOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxEddySHANGA
 
Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solutionJEMLI Fathi
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTCHAKER ALLAOUI
 
Distributed programing (hadoop && java) version finale.pptx
Distributed programing  (hadoop && java) version finale.pptxDistributed programing  (hadoop && java) version finale.pptx
Distributed programing (hadoop && java) version finale.pptxAhmed rebai
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdfZkSadrati
 
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...AZUG FR
 
SAS Forum Soft Computing Théâtre
SAS Forum Soft Computing ThéâtreSAS Forum Soft Computing Théâtre
SAS Forum Soft Computing ThéâtreSoft Computing
 
ch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdfch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdfsalmanakbi
 
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBSGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBRomain Cambien
 
Spad big data - sfds - 2016
Spad   big data - sfds - 2016Spad   big data - sfds - 2016
Spad big data - sfds - 2016Julien BLAIZE
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010JUG Lausanne
 
Aqui hadoop draft
Aqui hadoop draftAqui hadoop draft
Aqui hadoop draftEric Papet
 
Big Data Visualization PowerPoint Templates.pptx
Big Data Visualization PowerPoint Templates.pptxBig Data Visualization PowerPoint Templates.pptx
Big Data Visualization PowerPoint Templates.pptxKhadijaHaddaoui
 
Hibernate vs le_cloud_computing
Hibernate vs le_cloud_computingHibernate vs le_cloud_computing
Hibernate vs le_cloud_computingIppon
 
Hibernate vs le Cloud computing
Hibernate vs le Cloud computingHibernate vs le Cloud computing
Hibernate vs le Cloud computingJulien Dubois
 
Hibernate vs le_cloud_computing
Hibernate vs le_cloud_computingHibernate vs le_cloud_computing
Hibernate vs le_cloud_computingNormandy JUG
 

Similaire à Hadoop Hbase - Introduction (20)

NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxNOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
 
Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
 
Big data architectures
Big data architecturesBig data architectures
Big data architectures
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
 
Distributed programing (hadoop && java) version finale.pptx
Distributed programing  (hadoop && java) version finale.pptxDistributed programing  (hadoop && java) version finale.pptx
Distributed programing (hadoop && java) version finale.pptx
 
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
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdf
 
Cache
CacheCache
Cache
 
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...
 
SAS Forum Soft Computing Théâtre
SAS Forum Soft Computing ThéâtreSAS Forum Soft Computing Théâtre
SAS Forum Soft Computing Théâtre
 
ch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdfch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdf
 
Intro SQL
Intro SQL Intro SQL
Intro SQL
 
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBSGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
 
Spad big data - sfds - 2016
Spad   big data - sfds - 2016Spad   big data - sfds - 2016
Spad big data - sfds - 2016
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
 
Aqui hadoop draft
Aqui hadoop draftAqui hadoop draft
Aqui hadoop draft
 
Big Data Visualization PowerPoint Templates.pptx
Big Data Visualization PowerPoint Templates.pptxBig Data Visualization PowerPoint Templates.pptx
Big Data Visualization PowerPoint Templates.pptx
 
Hibernate vs le_cloud_computing
Hibernate vs le_cloud_computingHibernate vs le_cloud_computing
Hibernate vs le_cloud_computing
 
Hibernate vs le Cloud computing
Hibernate vs le Cloud computingHibernate vs le Cloud computing
Hibernate vs le Cloud computing
 
Hibernate vs le_cloud_computing
Hibernate vs le_cloud_computingHibernate vs le_cloud_computing
Hibernate vs le_cloud_computing
 

Hadoop Hbase - Introduction

  • 2. Blandine LARBRET Ingénieur biologiste reconvertie en informatique, je suis à ce jour étudiante en alternance pour obtenir un Master2 Software Development. Au cours de mes 2 ans d'alternance, j'ai découvert le monde pas si simple de HBase que j'ai voulu partager. Cette présentation est donc juste une introduction aux différentes Big Data et plus précisément à Hadoop et HBase. Les schémas que j'ai réalisé traduisent ma propre compréhension de ce modèle de base de données, acquise à partir de toute la littérature que j'ai pu explorer. En espérant que ça puisse vous éclairer... larbret.blandine@gmail.com
  • 3. Plan Les différentes Big Data Hadoop HBase
  • 5. Historique 1 Go 1 To = 103 Go 1 Po = 106 Go 1 Eo = 109 Go 1 Zo = 1012 Go 1982 1970 BD relationnelle 1997 notion de Big Data 1999 Big Analytics 1996 explosion du web 2010 1 Yo = 1015 Go www.winshuttle.fr/chronologie-big-data/ Besoin croissant en capacité de stockage numérique Futur
  • 7. Contexte Exemples Données mondiales => 1,8 Zo en 2011 Emails => 250 milliards / jour (80% de spams) Vidéos => 72h déposées / min sur Youtube Boeing => 20 To / heure de données www.santepublique-editions.fr/objects/cyres-big-data-pre-769-sentation -tables-rondes-ingensi.pdf
  • 8. Domaines d’application Entreprises du web Google, Facebook, Twitter, Amazon, Ebay ... Grands groupes Sécurité Sociale, INPI, banques... Analyses de données statistiques pour les entreprises privées, sondages d’opinion, études marketing... Recherche scientifique séquençage du génome humain, astronomie...
  • 9. Définition des Big Data Une Big Data est une base de données distribuée sur plusieurs machines d'un même réseau. Du fait de sa configuration, les jointures connues sous les SGBDR n'existent plus, rendant le langage SQL sans intérêt. C'est pourquoi les Big Data étaient initialement appelées Bases de Données NoSQL, pour "Not Only SQL", sous-entendues "non relationnelles". Mais le terme de NoSQL sonnant comme un affront aux administrateurs de BD classiques, il a cédé la place à celui de Big Data. La notion de Big Data est apparue en 1997, mais la technologie fut développée à partir de 2003 par Google. http://www.stechfrites.com/content/le-mouvement-nosql
  • 10. Définition des Big Data Nœud : serveur appartenant au réseau d'une Big Data Cluster : ensemble des serveurs d'un même réseau Big Data Les nœuds peuvent être physiquement hétérogènes (configuration hardware différente). Les systèmes de gestion des Big Data gèrent cette hétérogénéité.
  • 11. Définition des Big Data base de données relationnelle = stockage modéré base de données distribuée = stockage illimité BIG DATA cluster nœud
  • 12. Dénormalisation Le stockage illimité sur un réseau distribué permet la réplication des données, ce qui optimise leur lecture et assure leur sauvegarde même en cas de panne matérielle. C'est la dénormalisation. En BD classique, la maintenance d'un tel système est compliquée en cas de modification. Mais les systèmes de gestion des Big Data gèrent totalement les réplications. data http://www.thecodingmachine.com/fr/d%C3%A9normalisation-du-mod%C3%A8le -de-donn%C3%A9es
  • 13. Les 3 V Volume gros volume de données à stocker > 1 Petaoctet Variété différents type de données => brutes, texte, images... Vélocité rapidité de traitement en écriture et lecture Laney D. - 2001 - "3D Data Management: Controlling Data Volume, Velocity, and Variety" META group Inc.
  • 14. Propriétés ACID Les BD relationnelles doivent respecter toutes les propriétés ACID : - Atomicité : les requêtes reçues par la base doivent être complètes sous peine d'être non traitées - Cohérence : les requêtes doivent respecter l'état de validité de la base (respect des contraintes, des mises à jour...) - Isolation : les requêtes sont indépendantes les unes des autres lors d'un envoi simultané - Durabilité : les modifications de la base doivent être effectuées en priorité avant toute autre action pour permettre la sauvegarde de ces changements Les Big Data ne répondent pas à ces propriétés. Mais elles respectent le théorème CAP.
  • 15. Théorème CAP Il est impossible pour tout système de garantir en même temps les trois contraintes suivantes, seules 2 peuvent être respectées simultanément : - Cohérence (= Consistency) : tous les nœuds du système voient exactement les mêmes données au même moment - Disponibilité (= Availability) : garantie que toutes les requêtes reçoivent une réponse - Résistance au morcellement (= Partition Tolerance) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome). A. Fox, E.A. Brewer - 1999 - "Harvest, Yield and Scalable Tolerant Systems" Proc. 7th Workshop Hot Topics in Operating Systems - p.174-178
  • 16. Propriétés ACID vs Théorème CAP Availability Partition tolerance Consistency CA AP CP Big Data Atomicité Cohérence Isolation Durabilité BD relationnelle 4 / 4 2 / 3
  • 17. Les plus connues Availability Partition tolerance Consistency CA AP CP http://nosql-database.org/
  • 18. Modèle orienté Objet Ce modèle permet de stocker des objets, avec leurs attributs, leurs relations d'héritage et leurs références vers d'autres objets, de manière persistante. Certains systèmes permettent même d'exécuter les méthodes des objets directement dans la base de données. Ce modèle est, en pratique, plutôt proche du modèle relationnel et n'est pas exclusif aux Big Data. D'ailleurs, certaines SGBDR permettent de choisir entre relationnel et orienté objet.
  • 20. Modèle orienté Clé-Valeur Ce modèle est une simple correspondance entre une clé et une valeur, comme une table de hachage à la différence qu'en Big Data, le stockage se fait sur un réseau distribué. Il est essentiellement utilisé en tant que cache, pour stocker des données semi-persistantes qui ne doivent être conservées qu'un temps donné.
  • 21. Modèle orienté Colonne Il s'agit d'un modèle structuré où l'équivalent de plusieurs tables d'une base de données relationnelle est réuni dans une seule grande table sous forme de colonnes, éliminant ainsi les jointures. Ce modèle permet d'enregistrer des volumes très importants de données simples, généralement sur des clusters de quelques dizaines à quelques centaines de serveurs, souvent répartis sur plusieurs datacentres. Il est donc destiné pour de très gros stockages comme Google ou Facebook.
  • 22. Modèle orienté Document Une clé primaire est associée à une structure de plusieurs valeurs de types différents, appelée document. Chaque clé peut être associée à une structure différente. Les données sont alors organisées dans des fichiers au format XML ou JSON. Ce modèle est utile pour le stockage de données hétérogènes. document type A type B type A
  • 23. Modèle orienté Graphe Ces systèmes sont prévus pour stocker des graphes (au sens de la théorie des graphes), avec des nœuds comportant des attributs et des liens entre les différents nœuds. L'exemple type est le stockage d'un réseau social où il est possible de parcourir les relations entre utilisateurs. A BC D FlockDB
  • 25. Historique En 2004, Google publie un article de recherche présentant son nouvel algorithme MapReduce, conçu pour réaliser des opérations analytiques à grande échelle sur un grand cluster de serveurs via son système de fichier Google Filesystem (GFS). Doug Cutting, qui travaillait alors sur le développement du moteur de recherche libre Apache Lucene, s’est alors emparé des concepts décrits dans l’article et a décidé de répliquer les outils développés par Google en version open source, ce qui est devenu le projet Hadoop en 2006. Hadoop est le nom de l’éléphant qui servait de doudou à son fils. J. Dean, S. Ghemawat (Google Inc.) - 2004 "MapReduce : Simplified data processing on large clusters" Sixth Symposium on Operating System Design and Implementation - San Francisco, CA
  • 26. MapReduce Utilisé pour réduire les temps de lecture dans une base de données distribuée, cet algorithme repose sur la parallélisation du travail de recherche à travers plusieurs serveurs via deux fonctions principales : Map et Reduce, qui sont des méthodes bloquantes (bloquent le processus tant que leur exécution n'est pas terminée). La recherche est en fait coupée en morceaux répartis sur plusieurs serveurs qui travaillent en même temps. Le résultat final est donc obtenu plus rapidement ; et plus il y a de serveurs, plus le résultat est rapide. Bien qu'Hadoop soit sa première implémentation, le MapReduce est aujourd'hui utilisé dans de nombreux autres frameworks.
  • 27. MapReduce Architecture Son organisation s'appuie sur un système de serveurs maître-esclaves. Ainsi, lors d'une requête, le serveur-maître, appelé JobTracker, procède à l'analyse de toutes les données de la base et les scinde en plus petits blocs de données (= splitting) pour les répartir à plusieurs serveurs-esclaves, appelés TaskTrackers. Par défaut, la taille des blocs distribués est de 64 Mo. Un serveur-maître secondaire sert de secours en cas de défaillance du serveur-maître principal. Le JobTracker y réalise alors régulièrement des copies des blocks et de leur attribution aux différents Tasktrackers.
  • 28. MapReduce Architecture Le temps de réponse des TaskTrackers donne le Ration Performance (RP) collecté par le JobTracker. Ce ratio est important en milieu distribué hétérogène. Il permet au JobTracker d'adapter la quantité de blocs de données fournie à un TaskTracker. Ainsi sur les machines performantes travailleront plus que les machines moins performantes, car dès qu'un bloc a fini d'être analysé, le JobTracker en fournit un nouveau. Le JobTracker réalise en continu une mesure des RP des chaque serveurs-esclaves. Dès que le RP d'un TaskTracker baisse, sa charge de travail est allégée et répartie sur des TaskTrackers plus performants jusqu'à ce que son RP retrouve sa valeur normale. Le JobTracker peut ainsi remplacer un serveur-esclave défaillant par un autre en assignant à ce dernier le bloc de données qui n'a pas retourné de résultat, donc celui du TaskTracker défaillant.
  • 29. MapReduce Architecture 2 modes de lecture peuvent être utilisés pour lire les données stockées dans la base : - mode direct où les données sont directement lues depuis le disque local, avec transfert depuis la mémoire cache vers la mémoire du lecteur en utilisant l'accès direct à la mémoire ; - mode streaming où le lecteur lit les données depuis un autre processus en cours d'exécution à l'aide de moyen de communication comme TCP/IP ou JDBC. D'après certains tests, la différence de performance entre ces deux modes est faible (10%). http://fr.wikipedia.org/wiki/MapReduce
  • 30. copie des blocs de données et de leur attribution JobTracker (serveur-maître) TaskTracker (serveur esclave) serveur-maître secondaire parsing (Map) en direct en streaming splitting (Map) 64 Mo RESULTAT DATA MapReduce Architecture
  • 31. MapReduce Principe La fonction Map commence par un décodage des blocs de données reçus. C'est le parsing, qui peut être alors de deux types : - décodage immuable : n données instancient n objets de programmation (donc 1 objet/donnée). Ces objets sont non modifiables, donc immuables. - décodage mutable : n données instancient 1 seul objet qui est réutilisé pour toutes les instanciations. Il s'agit donc d'un objet mutable. Le décodage immuable est plus lent que le décodage mutable car il produit un grand nombre d'objets immuables durant le processus de décodage. La création de tous ces objets augmentent la charge de travail des processeurs. Jiang D, Ooi BC, Shi L, Wu S - 2010 - "The performance of MapReduce : an in-depth study" Proceedings of the VLDB Endowment 3 (1-2), 472-483
  • 32. MapReduce Principe Les données décodées sont réorganisées en couples clé-valeur (= shuffle). Ces couples sont ensuite triés selon leur clé (= sort). Le résultat de la fonction Map donne donc un regroupement de plusieurs valeurs pour une même clé. La fonction Reduce compressent ces groupes clé-valeurs de sorte qu'une clé soit de nouveau associée à une seule valeur. Cette compression est alors renvoyée au JobTracker en guise de résultat qui centralise tous les résultats des différents bloc pour constituer la réponse à la requête.
  • 33. MapReduce Principe Data Splitting Shuffle Sort Reduce Result Map http://blog.inovia-conseil.fr/?p=46
  • 34. MapReduce Configuration MapReduce est configurable presque à tous les niveaux : - choix du JobTracker, des TaskTrackers et du serveur-maître secondaire - mode de parsing - taille des blocks lors du splitting (64 Mo par défaut) - espace mémoire utilisé pour fonctionner - fonctions map et reduce http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client- core/MapReduceTutorial.html http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client- core/MapredCommands.html
  • 35. Architecture Hadoop Hadoop est un framework développé en Java. Son HDFS (Hadoop File System) est un système de fichiers en cluster conçu pour stocker de très gros volumes de données sur un grand nombre de machines. On trouve : - un serveur-maître, appelé NameNode, qui enregistre dans un fichier la localisation des données réparties en blocs dans le cluster. Ce fichier de métadonnées a une taille configurée par défaut à 256 Mo. - un serveur-maître secondaire, qui gère l'historique des modifications faites dans le fichier de métadonnées (WAL : Write Ahead Log). Ce NameNode secondaire permet la continuité du fonctionnement du cluster Hadoop en cas de panne du NameNode principal. - des serveurs-esclaves, appelés DataNodes, qui stockent les données scindées en petits blocs de 64 Mo par défaut. Ces blocs sont des fichiers de données stockées en bytes, appelés DataFiles.
  • 36. Architecture Hadoop L'HDFS est conçu pour assurer la sauvegarde des données en répliquant l’ensemble des données écrites sur le cluster. Par défaut, chaque donnée est écrite sur 3 DataNodes différents. Hadoop peut être lancé selon 3 modes : - mode standalone, pour tourner sur un seul serveur - mode pseudo-distribué où le principe HDFS est contenu sur une seule machine et donne l'illusion d'un mode distribué - mode distribué, où l'HDFS est réparti sur un réel cluster physique.
  • 37. Architecture Hadoop NameNode (serveur maître) NameNode secondaire Metadonnées 256 Mo max par défaut WAL archivage de l'historique DataFiles 64 Mo max par défaut 3 réplications des données par défaut DataNode (serveur esclave) HDFS Hadoop File System
  • 38. Configuration Hadoop Hadoop est conçu pour des serveurs Linux. Pour des tests, il est possible d'utiliser Windows avec Cygwin. http://ebiquity.umbc.edu/Tutorials/Hadoop/00%20-%20Intro.html Hadoop est configurable pour : - le choix du NameNode et de son serveur-maître secondaire - la quantité et le choix des DataNodes - la taille des DataFiles - la taille du fichier de métadonnées dans le NameNode - le nombre de réplication par serveur-esclave
  • 39. Configuration Hadoop configuration du cluster variables d'environnement configuration des fichiers http://hadoop.apache.org/docs/r1.1.2/cluster_setup.html configuration du MapReduce identification des NameNodes identification des DataNodes https://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml http://hadoop.apache.org/docs/r1.1.1/mapred-default.html
  • 40. HBASE
  • 41. Historique - 2004 - Google publie le MapReduce (algorithme pour les sytèmes distribués) - 2006 - Doug Cutting crée Hadoop (framework de stockage en cluster) - 2006 - Google utilise Hadoop pour créer BigTable (SGBD BigData propriétaire) - 2007 - création de HBase (= BigTable en version open source) par Powerset qui contribue au developpement de Hadoop F. Chang, R.E. Gruber et al. (Google Inc.) - 2006 "Bigtable: A Distributed Storage System for Structured Data" Seventh Symposium on Operating System Design and Implementation - Seattle, WA
  • 42. Historique - 2008 - Powerset se fait racheter par Microsoft qui abandonne le développement de HBase (car open source) - 2008 - Hadoop devient le projet principal de la fondation Apache - 2010 - HBase devient le projet principal de la fondation Apache L. George - 2011 "HBase the Definitive Guide" - O'Reilly
  • 43. Architecture HBase est un système de gestion des données pour un environnement distribué qui doit être couplé au gestionnaire de fichiers Hadoop. Hbase gère la partie logique, tandis qu'Hadoop gère la partie physique. C'est un modèle de stockage BigData orienté colonne, basé sur le principe de BigTable de Google.
  • 44. Architecture Aspect logique Les données sont gérées au sein de grandes tables (appelées HTable) composées de lignes (nommées row) et de familles de colonnes (family). Les familles de colonnes sont sous-divisées en colonnes (qualifier). Les lignes sont des identifiants dont la valeur est unique, soit l'équivalent de la clé primaire dans le mode relationnel. Comparaison avec un SGBDR : HTable => ensemble de toutes les tables de la base family => une table qualifier => un attribut row => clé primaire Du fait que toutes les données sont logiquement placées dans la même table, les jointures sont inutiles. http://hbase.apache.org/book.html#datamodel
  • 45. Architecture Aspect logique Les données (dites value) sont stockées pour une ligne et une colonne précises. Mais plusieurs écritures peuvent être effectuées pour un même emplacement. On parle alors de version de données à des temps différents (timestamp). Par défaut, le timestamp est configuré à 3 versions. Il peut être modifiable, mais il est déconseillé d'enregistrer au-delà de 100 versions. L'ensemble des informations (ou coordonnées) d'une donnée est appelée keyValue et correspond donc à : KeyValue = row + family + qualifier + timestamp + value Les données sont toujours enregistrées sous la forme de keyValue, donc avec leurs coordonnées complètes.
  • 47. Configuration Peuvent être configurés : - les rôles des serveurs (master, slaves) - le zookeeper (nb d'instances, temps de session) - le memstore - la compression des storefiles ... http://hbase.apache.org/book.html#important_configurations
  • 48. Architecture Aspect physique HBase est basé sur la même architecture physique qu'Hadoop puisque ce dernier gère le stockage physique. On retrouve donc une configuration distribuée en cluster de plusieurs nœuds qui peuvent être hétérogènes au niveau hardware. Le principe est donc le même que celui d'Hadoop. Seuls les noms diffèrent. Ainsi : Architecture HADOOP HBASE serveur-maître namenode regionserver serveur-esclave datanode region fichier de stockage datafile storefile
  • 49. Architecture Aspect physique Avant d'être stockées à travers le cluster, les données à stocker transitent par un framework fourni avec HBase : le zookeeper. Il coordonne la destination d'archivage des données dans un système distribué. Ces données sont ensuite réparties sur les différents serveurs (Region) du cluster, où elles sont triées et compactées par le memstore de HBase. Pour une meilleure gestion de l'espace mémoire, les données sont toujours sauvegardées sous forme de bytes. Elles sont stockées dans les regionservers sous forme de blocs de données (les storefiles) d'une taille configurée par défaut de 64 Mo (configuration faite via Hadoop).
  • 50. Architecture Aspect physique La répartition des données sur les regionserveurs se fait en 2 étapes : - les lignes d'une HTable sont scindées en paquets réguliers par le regionserveur, - chaque paquet est dirigé chacun vers un serveur-esclave où il est de nouveau divisé par le memstore selon les colonnes de la HTable. Les données issues de la même famille de colonne sont alors stockées dans un même storefile (ou datafile pour Hadoop) dans la limite de taille configurée (64 Mo par défaut selon Hadoop). Si la taille d'un paquet produit par le memstore venait à avoir une taille trop importante, le dépassement formerait un nouveau storefile. De même, si un datanode venait à être surchargé, il serait également redivisé à travers d'autres datanodes afin de répartir la charge.
  • 52. Design Eléments critiques Les performances de HBase sont plutôt tournées sur la lecture des données, via le MapReduce et la dénormalisation. D'après la façon de HBase de stocker les données, 2 éléments influent sur la vitesse de lecture : - choix des colonnes : si une requête trouve son résultat dans 2 colonnes issues de 2 familles différentes, la recherche se fera sur 2 storefiles différents, augmentant ainsi le temps de lecture. - choix des lignes : les noms des lignes représentant la clé primaire, leur choix doit être le plus judicieux possible pour un accès rapide aux données selon les requêtes estimées. exemple : temps de lecture différent selon une row structurée nom+date ou date+nom http://hbase.apache.org/book.html#schema
  • 53. Design Colonnes Les données sont enregistrées par leur keyValue, donc avec toutes leurs coordonnées. De ce fait pour toutes les valeurs d'une même ligne, le nom des families, qui représente le nom du fichier HDFS au format string, et celui des qualifiers, stocké en bytes[ ] dans le fichier, seront systématiquement répétés. Pour optimiser la place mémoire, il est donc recommandé d'employer des noms de familles de colonnes les plus petits possible (donc en un seul caractère) et de rentabiliser ceux des colonnes en les utilisant comme un complément d'information. Exemple : ligne (ou row) = date arrondie à l'heure familles de colonnes = t (température d'un composant), e (état activé ou non du composant) colonne (ou qualifier) = temps en minutes N. Dimiduk, A. Khurana- 2012 "HBase in action" - Manning
  • 54. Design Colonnes Le nombre de colonnes (qualifiers) peut être considéré comme illimité, bien qu'il soit plus ou moins lié à la taille des fichiers HDFS. Mais il n'est pas conseillé de créer trop de familles de colonnes : HBase a du mal à gérer plus de 3 families pour une même table. http://hbase.apache.org/book/book.html
  • 55. Design Lignes (= clé primaire) Les enregistrements des lignes dans les fichiers HDFS se font de manière séquentielle. Il faut donc penser à ce qu'ils produisent un stockage ordonné. Par exemple, un tri sur le nom des lignes par ordre alphabétique après stockage n'est pas possible. Il faut aussi tenir compte de la répartition des lignes dans l'HDFS. Hadoop stockant des blocs de lignes sur un même DataNode, il peut être intéressant de regrouper les données selon certaines requêtes et donc choisir des noms de lignes en conséquence. Enfin, comme pour les colonnes, les rows sont répétées dans la keyValue de chaque donnée. Elles doivent donc être utilisées comme un moyen supplémentaire de stocker de l'information.
  • 56. Communication HBase est écrit en Java. Il y a donc une API Java. Mais d'autres moyens de communication avec cet outil ont été mis en place : - HBase shell - Hive - Pig - API JRuby - API Cascading
  • 57. Communication Hive Initialement développé par Facebook, Hive est aujourd'hui un projet open source Apache qui offre un langage similaire au SQL, le HiveQL, pour effectuer des requêtes au sein d'un système distribué. Hive emploie un gestionnaire de stockage qui peut donc intervenir sur les données stockées dans le HDFS, mais également dans d'autres sources. De ce fait il est capable d'effectuer des travaux de MapReduce. Ainsi Hive permet aux utilisateurs peu à l'aise avec la manipulation du MapReduce de pouvoir tout de même utiliser ce modèle de recherche au travers de requêtes pseudo-SQL. Depuis la version 0.6.0, Hive est également livré avec un gestionnaire pour HBase. Il est alors possible de définir des HiveTables dans le langage HiveQL qui seront fidèlement converties en HTables.
  • 58. Communication Pig Développé au départ par Yahoo, Pig est devenu lui aussi un projet Apache. Il est employé pour analyser les données d'une Big Data à travers le langage de requêtes Pig Latin. Comme Hive, il cache l'éventuelle complexité du modèle MapReduce derrière un langage de haut-niveau plus intuitif pour l'utilisateur. Le Pig Latin est en effet un langage de programmation orienté flux de données qui permet de représenter les résultats sous forme de graphes, mettant alors en évidence un certain nombre de propriétés comme le parallélisme disponible ou la localité des données. Ce langage est donc l'un des avantages principal de Pig. Un autre avantage est l'optimisation des tâches que cet outil propose en automatisant leur exécution. Enfin, les utilisateurs peuvent créer leurs propres fonctions pour gérer un traitement de données particulier.
  • 59. Communication HBase Shell C'est l'interface système (shell) qui permet d'administrer la base. Elle est activée par la commande hbase shell et quittée par la commande exit. Ce shell est basé sur JRuby qui est une implémentation du langage Ruby en Java. Il utilise donc le shell Ruby, IRB (Interactive Ruby Shell), auquel sont ajoutées des commandes spécifiques basées sur l'API Java.
  • 60. HBase Shell Commandes principales créer une table T avec ses familles de colonnes F1 et F2 create 'T', 'F1', 'F2' déverrouiller une table disable 'T' , déverrouiller toutes les tables  disable_all '*.*' ajouter une famille de colonnes à une table alter 'T', NAME =>'F3' reverrouiller une table  enable 'T' ajouter ou remplacer une valeur à certaines coordonnées  put 'T', 'R1', 'F1:C1', 'V1' savoir si une table existe  exist 'T' compter le nombre de valeurs dans des colonnes  count 'T', {COLUMNS => [F1:C2, F1:C3]}
  • 61. HBase Shell Commandes principales lister toutes les tables  list décrire une table  describe 'T' lire toutes les lignes d'une table  scan 'T' lire des familles de colonnes  scan 'T', {COLUMNS => ['F1', 'F2']} lire des colonnes  scan 'T', { COLUMNS => [F1:C3', F2:C1']} lire des colonnes au départ d'une ligne précise  scan 'T', { COLUMNS => [F1:C3', F2:C1'], STARTROW => 'R2'} lire des colonnes jusqu'à une ligne précise  scan 'T', { COLUMNS => [F1:C3', F2:C1'], STOPROW => 'R6'}
  • 62. HBase Shell Commandes principales lire une ligne avec toutes ses valeurs  get 'T', 'R3' lire les valeurs d'une ligne et d'une famille de colonnes  get 'T', 'R2', 'F1' lire les valeurs d'une ligne et d'une colonne  get 'T', 'R1', 'F2:C3' vider une table  truncate 'T' supprimer une table  drop 'T' supprimer une famille de colonnes  alter 'T', delete => 'F1' supprimer une ligne entière  deleteall 'T', 'R1' supprimer une valeur via ses coordonnées  delete 'T', 'R1', 'F1:C2'