Hadoop Hbase - Introduction

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

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
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

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é.

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

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

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.

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.

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
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
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'

Hadoop Hbase - Introduction

Contenu connexe

Tendances (20)

En vedette (20)

Similaire à Hadoop Hbase - Introduction (20)

Hadoop Hbase - Introduction