Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Database)

HMIN313 : 2ème Cours
Les bases de données orientées colonnes
HBase
Hatim CHAHDI
UMR Espace-DEV
Université de Montpellier
28 Septembre 2016
Hatim CHAHDI (Espace Dev - UM) BD Colonnes, HBase 28 Septembre 2016 1 / 47

Objectifs du cours
Comprendre la problématique de stockage de données
Étude approfondie des bases de données orientées colonnes
Présentation de HBase comme exemple d’une BD orientée colonnes

Rappels : No-SQL, des alternatives !
Des besoins différents. Des structures de
stockage différentes
Les différents types des SGBD No-SQL:
Clé/Valeur
Colonne
Document
Graphe
No-SQL = Not Only SQL

Base de données orientée Clé/Valeur
Principes: Représentation des données sous forme de clé/valeur .
Les valeurs peuvent être de simple chaˆınes de caractères ou des objets
sérialisés complexes.
Utilisation: dépôt de données avec besoins de requêtage simples
(préférences d’utilisateur, données de panier, les logs . . . )
Figure : modèle clé/valeur

Base de données orientée Clé/Valeur
Principes: Représentation des données sous forme de clé/valeur .
Les valeurs peuvent être de simple chaˆınes de caractères ou des objets
sérialisés complexes.
Utilisation: dépôt de données avec besoins de requêtage simples
(préférences d’utilisateur, données de panier, les logs . . . )
Figure : modèle clé/valeur
Exploitation basée sur 4
opérations (CRUD): Accès par
la clé
Create: Création d’un objet.
Read: Lecture d’un objet.
Update: Mise à jour d’un
objet.
Delete: Suppression un objet.

Base de données orientée document
Principes: C’est une variante des SGBD clé/valeur, où la valeur est
un document de type XML ou JSON.
Les documents ont une structure arborescente, ils sont composés de
champs et des valeurs associées
Ce type de SGBD permet d’effectuer des requêtes sur le contenu des
documents.
Utilisation: Enregistrements d’événements, gestion de contenu . . .
Figure : modèle document

Base de données orientée document
Principes: C’est une variante des SGBD clé/valeur, où la valeur est
un document de type XML ou JSON.
Les documents ont une structure arborescente, ils sont composés de
champs et des valeurs associées
Ce type de SGBD permet d’effectuer des requêtes sur le contenu des
documents.
Utilisation: Enregistrements d’événements, gestion de contenu . . .
Figure : modèle document
Implémentations connues
CouchDB (fondation
apache)
MangoDB

Base de données orientée graphe
Principes
Les données sont représentées sous-forme de graphe : Des noeuds pour
les entités, des arcs pour les relations entre les entités
Ce type de SGBD est adapté à la manipulation de données fortement
connectées
Utilisation: Systèmes de recommandations, Réseaux sociaux,
Systèmes de transport . . .
Figure : modèle graphe

Base de données orientée graphe
Principes
Les données sont représentées sous-forme de graphe : Des noeuds pour
les entités, des arcs pour les relations entre les entités
Ce type de SGBD est adapté à la manipulation de données fortement
connectées
Utilisation: Systèmes de recommandations, Réseaux sociaux,
Systèmes de transport . . .
Figure : modèle graphe
Implémentations connues
Neo4J
AllegroGraph

Base de données orientée colonnes
Principes: Proche du relationnel. Mais le stockage des donnés se fait
par colonne et non par ligne.
Ajout de colonnes facile et dynamique
Possibilité de compression des données
Utilisation: Optimisation de la recherche, traitement et analyse de
données structurées (BI) . . .
Figure : modèle colonne

Base de données orientée colonnes
Principes: Proche du relationnel. Mais le stockage des donnés se fait
par colonne et non par ligne.
Ajout de colonnes facile et dynamique
Possibilité de compression des données
Utilisation: Optimisation de la recherche, traitement et analyse de
données structurées (BI) . . .
Figure : modèle colonne
Implémentation à étudier dans
ce cours

Caractérisation des systèmes No-SQL: CAP
Consistency, Availability, Partition tolerance
Consistency ou cohérence des données : toute modification de
donnée est suivie d’effet pour tous les noeuds du système
Availability ou disponibilité des données : toute requête émise et
traitée par un noeud du système, re¸coit une réponse (même en
situation d’échec à produire une réponse)
Partition tolerance ou recouvrement des noeuds assurer une
continuité du fonctionnement en cas d’ajout/suppression de noeud
(ou partition) du système distribué
Constat de Brewer : aucun des systèmes distribués n’est à même de
satisfaire en même temps les principes C, A et P

Théorème CAP : un choix à faire !
Un système distribué va satisfaire deux des trois points CAP
Considérations SGBDR / Systèmes NoSQL
SGBDR : Cohérence et haute disponibilité (pas ou peu de P : de
différents noeuds système)
Systèmes NoSQL : Choix du P (système naturellement distribué) et
sélection soit du C, soit du A
abandon du A ⇐ Accepte d’attendre que les données soient cohérentes
abandon du C ⇐ Accepte de recevoir des données parfois incohérentes

Exemple d’implémentations adoptées par des systèmes
No-SQL
Table : Quelques systèmes et leurs modes de représentation
Nom Type Catégorisation CAP
CouchDB Document AP
MongoDB Document CP
Neo4j Graph CA
Hbase Column CP
Cassandra Column AP
Riak Key-Value CP
Project Voldemort Key-Value AP

Exemple d’applications existantes
Nom de l’entreprise Syst`eme No-SQL Type
Google BigTable, LevelDB Column
LinkedIn Voldemort Key-Value
Facebook Cassandra Column
Twitter Hadoop/Hbase, Cassandra Column
Netﬂix SimpleDB, Hadoop/HBase, Cassandra Column
CERN CouchDB Document
Amazon Dynamo Key-Value

Les Bases de Donn´ees orient´ees
Colonnes

Systèmes No-SQL à colonnes
Confusion possible : le modèle physique est à colonnes mais pas le modèle
de données
paradigmes clé/valeur avec ”clé d’adressage” composite
Colonne : triplet : adresse de colonne / valeur de colonne /
estampille (gérer les versions et les conflits)
Famille de colonnes : regrouper les colonnes qui sont partagées par
un ensemble d’individus
Familles de super colonnes : extension du modèle avec la notion de
”super colonnes” qui sont des collections de colonnes (poser des index
à différents niveaux)

Illustration colonnes (qualifier)
...
...
...
row_key_x
...
...
...timestamp_1
column_name_n
column_value_n
column_name_1
column_value_1
timestamp_n
row_key_x => {
column_name_1: column_value_1,
...
column_name_n: column_value_n,
}
Figure : Vision g´en´erale

Illustration colonnes et ”taille” variable d’un tuple
PatientCode Firstname
1256953732
LastName
1256953732
Marie Martin
PatientCode
B_A_0001
1256953732
Firstname
Jean
1256953732
LastName
Dupont
1256953732
Address
Montpellier
1256953732
B_A_0001
B_A_0002 B_A_0002
1256953732
Function
Commercial
1256953732 1256953732
OfficeNumber
17−03
Figure : Exemple de deux tuples d’une famille

´Ecriture inspir´ee de la notation JSON
B A 0001 => {
G a l I n f o s : PatientCode :” B A 0001 ” ,
G a l I n f o s : Firstname : ”Jean ” ,
G a l I n f o s : LastName : ”Dupont ” ,
G a l I n f o s : Address : ” M on t p e l l i e r ” ,
A l l e r g y I n f o s : Sneezing : ” mild ” ,
A l l e r g y I n f o s : I t c h y T r oa t : ” s e v e r e ” ,
A l l e r g y I n f o s : Snuffy Nose : ”moderate ” ,
A l l e r g y I n f o s : Watery Eyes : ” mild ” ,
A l l e r g y I n f o s : Itchy Nose : ” s e v e r e ”
}
Listing 1: Un tuple

Illustration famille de colonnes
PatientCode
B_A_0001
1256953732
Firstname
Jean
1256953732
LastName
Dupont
1256953732
Address
Montpellier
1256953732
B_A_0001
CF:Gal_Infos
CF:Allergy_Infos
B_A_0001
Sneezing
mild
1256953666
severe
Itchy_Troat
1256953666
Snuffy_Nose
moderate
1256953666
Watery_Eyes
mild
1256953666
Itchy_Nose
severe
1256953666
Figure : Exemple de deux familles de colonnes

HBase et Cassandra
Deux solutions populaires inspir´ees largement de Google BigTable(1)
Cassandra
Hbase
(1) BigTable - A distributed storage system for distributed data - Chang et
al, 2006

HBase
Distribué, privilégie la cohérence et la disponibilité des données sans oublier
les performances
S’appuie sur Hadoop ( Apache) qui facilite le traitement distribué de
larges jeux de données et ses composants
Hadoop Core =
HDFS pour le stockage
MasterServer : namenode (mode master/slave)
RegionServer : datanode
Zookeeper : infrastructure centralisée et services pour gérer un
”cluster” de serveurs : parmi les activités : synchronization, choix du
serveur maˆıtre et vérification de la disponibilité des serveurs
MapReduce : modèle de programmation distribuée

Architecture de HBase
Figure : Vision g´en´erale

Structurellement parlant :
Unité de base : table (keyspace) fragmentée en parties égales = régions
(intervalles de valeurs de clés)
Tables triées sur la valeur de la clé
Familles : nombre quelconque de colonnes
Colonne (qualifier) : dont les valeurs peuvent être en nombre
quelconque de versions (horodatage)
(table, row, column family, column qualifier, timestamp) -> value (la
valeur de la donnée est stockée avec l’ensemble de ses coordonnées)
à noter : pas de super colonne avec HBase

Organisation de la donn´ee
Figure : Organisation sous-jacente `a tout tuple

Aspects internes à l’architecture de Hbase
Structures mises en jeu
1 familles de colonnes (CF) dont les colonnes sont stockées dans les
mêmes fichiers bas niveau = HFile
2 une table est associée à une ou à plusieurs régions (partition de
valeurs) selon les besoins en matière de place
3 HStore : une zone tampon par région associée à une table :
4 MemStore : une mémoire assignée au tri des tuples et à l’écriture
séquentielle du flux de données dans les fichiers de données (HFile) -
Sort & Flush
5 CachingBlock : tampon de données en mémoire vive
6 HFile : 1 à plusieurs fichiers de données par région
7 HLog : 1 fichier journal par RegionServer
8 Block : unité d’échange entre les mémoires vive et de masse (64 Ko à
l’ordinaire)

Orchestration de diﬀ´erents composants
HFile
1
1
stores
1
LogFile (WAL)
RegionServerRegion
CachingBlock
HStore
Column
+ name : byte[]
+ value : byte[]
+ time : timestamp
Table
+ name : string
locatedOn
1*
*
1..*1
associatedTo
1
1
MemStore
ColumnFamily
+ name : byte[]
Figure : Diagramme de classes : structures internes

Orchestration de diﬀ´erents composants
Figure : Extrait de HBase internals and schema design presentation

Mécanisme de reprise
Figure : Ecriture dans fichier journal pour restauration éventuelle

Fichiers de données
Structure d’index : Log Structured Merge (LSM) Tree optimisée pour les
accès séquentiels
Figure : Ordonnancement des valeurs des colonnes sur la base de la clé du tuple

Page d’accueil (WebApp)
Figure : Tables du métaschéma : .META. (infos sur toutes les régions) et
-ROOT- (localisation .META.)

Accès et traitement des données
Accès plus impératif que déclaratif
1 pas de langage DSL à l’exemple de SQL pour requêter les données
2 accès imperatif au travers d’API clientes : Java mais recours possible
à d’autres langages JRuby, Clojure, Scala, Jython, . . .
3 notion de coprocessor (procédure stockée) pour traiter directement
les données au niveau d’un noeud de données (RegionServer)
4 complémentarité avec le framework MapReduce qui fournit des
wrappers pour convertir les tables en collection de paires clé/valeur en
entrée comme en sortie de diverses tâches d’analyse

En pratique
Clients HBase
API Java
Shell HBase (JRuby)
Clients non-java
serveurs Thrifts (Ruby, C++, Erlang, . . . )
serveurs Rest (Stargate)

Construire une table et deux familles de colonnes avec
JRuby
c r e a t e ’ v i l l e ’ , ’ iG ’ , ’ ip10 ’
put ’ v i l l e ’ , ’01024 ’ , ’ iG : codeInsee ’ , ’01024 ’
put ’ v i l l e ’ , ’01024 ’ , ’ iG : nom ’ , ’ Attignat ’
put ’ v i l l e ’ , ’01024 ’ , ’ iG : popMun ’ , ’2850 ’
put ’ v i l l e ’ , ’34172 ’ , ’ iG : codeInsee ’ , ’34172 ’
put ’ v i l l e ’ , ’34172 ’ , ’ iG : nom ’ , ’ Montpellier ’
scan ’ v i l l e ’
ROW COLUMN+CELL
01024 column=iG : codeInsee , timestamp =1354564480805 ,
value =01024
01024 column=iG : nom , timestamp =1354564480902 ,
value=Attignat
. . .
Listing 2: shell JRuby

Exemples API Java
Opérations élémentaires
1 opérations sur une table : create, scan, disable, drop
2 opérations sur un tuple : put, delete, get
3 notions de filtre à partir du parcours des tuples d’une table

Cr´eation - Insertion (create, put)
C on f i gu r a t i on hc = HBaseConfiguration . c r e a t e ( ) ;
HTableDescriptor ht = new HTableDescriptor ( ” p a t i e n t ”
ht . addFamily ( new HColumnDescriptor ( ” a l l e r g y ” ) ) ;
Put p i e r r e P u t = new Put ( new S t r i n g (” P M 001 ”) .
getBytes ( ) ) ;
p i e r r e P u t . add (new S t r i n g (” a l l e r g y ”) . getBytes ( ) ,
new S t r i n g (” sneezing ”) . getBytes ( ) ,
new S t r i n g (” mild ”) . getBytes ( ) ) ;
HBaseAdmin hba = new HBaseAdmin( hc ) ;
System . out . p r i n t l n ( ” c r e a t i n g t a b l e . . . p a t i e n t ” ) ;
hba . createTable ( ht ) ;
HTable t a b l e = new HTable ( hc , ” p a t i e n t ”) ;
System . out . p r i n t l n ( ” c r e a t i n g row . . . P i e r r e ” ) ;
t a b l e . put ( p i e r r e P u t ) ;
Listing 3: table Patient et un tuple Pierre

Aﬃchage du contenu d’une table (scan)
C on f i gu r a t i on conf = HBaseConfiguration . c r e a t e ( ) ;
HTable t a b l e = new HTable ( conf , ” personne ”) ;
byte [ ] ge n e r a l = Bytes . toBytes (” ge n e r a l ”) ;
byte [ ] nom = Bytes . toBytes (”nom ”) ;
Scan scan = new Scan ( ) ;
scan . addColumn ( general , nom ) ;
ResultScanner scanner = t a b l e . getScanner ( scan ) ;
f o r ( Result r e s u l t = scanner . next ( ) ;
( r e s u l t != n u l l ) ;
r e s u l t = scanner . next ( ) ) {
f o r ( KeyValue keyValue : r e s u l t . l i s t ( ) ) {
System . out . p r i n t l n (” Q u a l i f i e r : ” + keyValue
” : Value : ” + Bytes . t oS t r i n g ( keyValue . getV
} }}}
Listing 4: Scan sur colonne

Filtre : patients âgés d’au moins 26 ans
C on f i gu r a t i on conf = HBaseConfiguration . c r e a t e ( ) ;
HTable t a b l e = new HTable ( conf , ” p a t i e n t ”) ;
List <F i l t e r > f i l t e r s = new ArrayList <F i l t e r >();
F i l t e r f a m F i l t e r = new F a m i l y F i l t e r ( CompareFilter .
CompareOp .EQUAL,
new BinaryComparator ( Bytes . toBytes (” iG ” )
f i l t e r s . add ( f a m F i l t e r ) ;
F i l t e r c o l F i l t e r = new Q u a l i f i e r F i l t e r (
CompareFilter . CompareOp .EQUAL,
new BinaryComparator ( Bytes . toBytes (” age ” ) ) ) ;
f i l t e r s . add ( c o l F i l t e r ) ;
F i l t e r v a l F i l t e r = new V a l u e F i l t e r ( CompareFilter .
CompareOp . GREATER OR EQUAL,
new BinaryComparator ( Bytes . toBytes ( ”26”)
f i l t e r s . add ( v a l F i l t e r ) ;
Listing 5: Exemple de filtre

Filtre Suite
F i l t e r L i s t f l = new F i l t e r L i s t ( F i l t e r L i s t . Operator .
MUST PASS ALL , f i l t e r s ) ;
scan . s e t F i l t e r ( f l ) ;
ResultScanner scanner = t a b l e . getScanner ( scan ) ;
System . out . p r i n t l n (” Scanning t a b l e . . . ”) ;
f o r ( Result r e s u l t : scanner ) {
f o r ( KeyValue kv : r e s u l t . raw ( ) ) {
System . out . p r i n t l n (” kv:”+kv +”, Key : ” +
Bytes . t oS t r i n g ( kv . getRow ( ) )
+ ” , Value : ” +Bytes . t oS t r i n g ( kv . getValue ( ) ) ) ;
}
}
scanner . c l o s e ( ) ;
Listing 6: Exemple de ﬁltre

Notion de ”Coprocessor”
Analogie soit avec les déclencheurs, soit avec les procédures stockées en
relationnel
Coprocesseur : fonctionnalités définies par l’usager pour étendre ou
surcharger les fonctionnalités inhérentes au système
Observer (triggers) : au niveau DML (ex. prePut/postPut), DDL (ex.
avant ou après création d’une table), journalisation
EndPoint (procédures stockées en relationnel) : ex. fonctions de
calcul liées à un regroupement (AggregationClient) sur une colonne
ou sur un tuple : count, min, max, sum, avg . . .

Rendre AggregationClient op´erationnel
Deux fa¸cons de faire
Ajout dans l e f i c h i e r hbase−s i t e . xml :
<property >
<name>hbase . c op r oc e s s or . user . r e gi on . c l a s s e s </name>
<value >
org . apache . hadoop . hbase . c op r oc e s s or . AggregateImplement
</value >
</property >
M od i f i c a t i on de l a t a b l e dans l e s h e l l HBase
1. hbase> d i s a b l e ’Commune ’
2. a j o u t e r l e programme
hbase> a l t e r ’Commune ’ , METHOD => ’ t a b l e a t t ’ ,
’ coprocessor ’=>’
| org . apache . hadoop . hbase . c op r oc e s s or . AggregateImplemen
3. hbase> enable ’Commune ’

Compter le nombre de communes avec AggregationClient
p u b l i c c l a s s AgregationCommunes {
p r i v a t e s t a t i c f i n a l byte [ ] TABLE NAME = Bytes . toB
p r i v a t e s t a t i c f i n a l byte [ ] General = Bytes . toByte
p u b l i c s t a t i c void main ( S t r i n g [ ] args ) throws Thro
C on f i gu r a t i on c o n f i g u r a t i o n = HBaseConfiguration . c
A ggr e ga t i on C l i e n t a g g r e g a t i o n C l i e n t = new A ggr e ga t
c o n f i g u r a t i o n ) ;
scan . addFamily ( General ) ;
long rowCount = a g g r e g a t i o n C l i e n t . rowCount (TABLE NA
System . out . p r i n t l n (” row count i s ” + rowCount ) ;
}}
Listing 8: Utiliser AggregationClient

Compter le nombre de communes sans AggregationClient
Ecrire votre propre code au risque d’une ineﬃcacit´e du calcul
p u b l i c s t a t i c void getCount ( S t r i n g tableName , C on f i g
t r y {
HTable t a b l e = new HTable ( conf , tableName
Scan s = new Scan ( ) ;
ResultScanner ss = t a b l e . getScanner ( s ) ;
i n t Compteur = 0;
f o r ( Result r : ss ){ Compteur++; }
System . out . p r i n t (” nombre de t u p l e s
} catch ( IOException e ){
e . printStackTrace ( ) ;
}
}
Listing 9: Dans la classe ParcoursScanCommune

Attributs multivalu´es
Avec JRuby
put ’CommuneJ ’ , ’34392 ’ , ’ population :2015 ’ , 110000
get ’CommuneJ ’ , ’34392 ’ , {COLUMN=>’population :2015 ’ ,VE

Attributs multivalu´es
Avec Java
C on f i gu r a t i on hc = HBaseConfiguration . c r e a t e ( ) ;
HTable t a b l = new HTable ( hc ,” CommuneJ ”) ;
Get get = new Get ( Bytes . toBytes (”34392”));
get . addFamily ( Bytes . toBytes (” population ” ) ) ;
get . setMaxVersions ( I n t e g e r .MAX VALUE) ;
Result r e s u l t = t a b l . get ( get ) ;
NavigableMap<byte [ ] , NavigableMap<byte [ ] ,
NavigableMap<Long , byte[]>>> map =
r e s u l t . getMap ( ) ;
. . . . p a r c o u r i r e n s u i t e l e s v a l e u r s

Combiner l’information provenant de plusieurs tables
Par exemple relevant d’une jointure
Programmation Map/Reduce des classes facilitatrices de
l’utilisation de plusieurs tables (côté Map) à l’exemple de
MultiTableInputFormat (à partir de HBase 0.94.16))
Implanter les algorithmes de jointure boucles imbriquées,
tri-fusion, jointure par hachage
Autres idées ?

Boucles imbriqu´ees : le plus simple
L’intuition : parcourir les valeurs (cl´e ou d’une colonne d’un tuple) et les
comparer
while ( r s e t 1 . next ( ) )
{
System . out . p r i n t (” value ”+r s e t 1 . get ( colX ) ) ;
while ( r s e t 2 . next ( ) )
{
i f ( r s e t 1 . get ( colX)==( r s e t 2 . get ( colY ) ) )
{
// a c t i on
}
}
}
Listing 12: Exemple Boucles

Charger des données depuis des fichiers tabulaires
Plusieurs choix possibles
Programmation Map/Reduce lorsque gros volumes de données
Migration depuis une BDR Exploiter JDBC pour insérer des tuples
dans une table HBase (exemple donné)
Définir un parseur (exemple extrait de la doc HBase)

Synthèse accès et manipulation des données
Les mêmes actions qu’avec une BD traditionnelle
Sélection, Projection avec scan, filter
Jointure avec MultiTableInputFormat, réécriture des opérateurs de
jointure en s’appuyant sur les algorithmes existants
Fonctions de calcul : notion de Coprocessor

Conclusion
Merci pour votre attention :)

Conclusion
Merci pour votre attention :)
Salle TD/TP : 5.08, puis 5.05

Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Database)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Database)

Similaire à Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Database) (20)

Dernier

Dernier (6)

Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Database)