Sistemul de Gestiune pentru Baze de Date Distribuite HBase

HBase este o bază de date distribuită, orientată pe coloane, construită peste HDFS, fiind utilizată în cazul aplicaţiilor Hadoop care necesită operaţii de citire / scriere aleatoare în seturi de date foarte mari. Este scris în Java şi poate fi accesat atât prin intermediul unui client propriu cât şi prin intermediul unui API foarte simplu.

Cu toate că există nenumărate strategii şi implementări pentru stocarea bazelor de date şi obţinerea informaţiilor din cadrul acestora, cele mai multe (în special derivate din categoria bazelor de date relaţionale) nu sunt scalabile în cazul în care dimensiunea datelor este foarte mare (scalabilitatea se referă la faptul că problema nu poate fi rezolvată doar prin adăugarea de alte resurse, cum ar fi discuri sau unităţi de procesare). Deşi au fost găsite soluţii pentru partiţionare şi replicare, acestea sunt extensii ale unui produs care nu a fost proiectat iniţial pentru astfel de operaţii, astfel încât sunt dificil de întreţinut. Totodată, toate restricţiile pe care le presupune modelul de date relaţional (interogări complexe conţinând joncţiuni, constrângeri de integritate de tip cheie străină, triggere şi vizualizări) – inclusiv cele 12 reguli ale lui Codd - vor implica resurse extrem de costisitoare pentru a putea fi întrunite.

Din acest punct de vedere, HBase a fost creat pentru a preîntimpina problema scalabilităţii în situaţia creşterii dimensiunii informaţiilor care trebuie stocate prin adăugarea de noduri. Nefiind o bază de date relaţională şi nefiind bazată pe SQL, este capabilă să ofere găzduirea unor tabele de dimensiuni mari, populate în mod inegal, pe clustere formate din maşini larg disponibile în comerţ, fără performanţe deosebite.

Un principiu de la care s-a pornit în proiectarea acestui tip de bază de date este Denormalizare, Duplicare şi Chei Inteligente (presucrtat DDI – eng. Denormalization, Duplication and Intelligent Keys). Astfel, denormalizarea este realizată prin duplicarea datelor, astfel încât pentru operaţiile de citire să nu fie necesară agregarea, acestea realizându-se într-un timp acceptabil fără a se mai realiza şi alte procesări. Totodată, utilizarea cheilor inteligente oferă control asupra nivelului de granularitate cu privire la modul şi locul în care sunt stocate datele. O astfel de proiectare a schemei conduce la scalabilitate în privinţa cantităţii de informaţie ce poate fi stocată cu păstrarea performanţelor legate de operaţiile de scriere şi de citire. Comparativ cu sistemele de baze de date relaţionale, API-ul pe care îl pune la dispoziţie HBase este foarte simplu şi prin urmare, limitat. Astfel, nu trebuie folosit pentru aplicaţii tranzacţionale care utilizează analize relaţionale (de tipul group by, join). De asemenea, nu funcţionează optim pentrul accesul bazat pe căutare de text.

HBase reprezintă însă o soluţie pentru seturi de informaţii de dimensiuni foarte mari (de ordinul milioanelor şi miliardelor de înregistrări) sau pentru aplicaţii ce utilizează date care sunt accesate de foarte mulţi clienţi (cererile şi răspunsurile generate ca urmare a acestei interacţiuni implică un volum de date foarte mare). Totodată, funcţionează optim în cazul unor scheme variabile, unde structura înregistrărilor diferă (datorită unor atribute care pot să existe sau nu).

Pentru a implementa toate aceste funcţionalităţi, suportul hardware trebuie să fie corespunzător, acest sistem de baze de date distribuit solicitând cel puţin cinci noduri corespunzătoare proceselor ce rulează în fundal. Altfel, configuraţia implicită (folosind un nivel de replicare 3) va avea performanţe destul de reduse. Ca regulă, HBase utilizează în mod intensiv capacitatea de procesare a nodurilor şi memoria acestora.

Proiectul HBase a fost pornit în 2006 de Chad Walters şi Jim Kellerman ca urmare a publicării articolului Bigtable: un sistem de stocare distribuit pentru date structurate, scris de mai mulţi cercetători de la Google. În 2007, Mike Cafarella avea deja o versiune funcţională, care a fost ulterior dezvoltată de Jim Kellerman. În acelaşi an, distribuţia HBase era integrată ca parte a Hadoop 0.15.0. În 2010, acesta a devenit un proiect de sine stătător al Apache, având clienţi precum Adobe, Facebook, Twitter, Meetup, Netflix precum şi unele grupuri ale Yahoo!.

În ceea ce priveşte arhitectura, există unele similitudini cu sistemele de baze de date tradiţionale, unitatea de bază fiind reprezentată de coloană, mai multe formând un rând care poate fi adresat în mod unic prin intermediul unei chei.

Fiecare coloană poate avea mai multe versiuni, valorile distincte fiind conţinute într-o celulă distinctă. Rândurile sunt sortate lexicografic în funcţie de cheia rândului, comparaţiile realizându-se în acest caz în mod binar, octet cu octet, de la stânga la dreapta. Coloanele sunt grupate în familii, ceea ce permite crearea de limite (semantice sau tematice) între date, aplicându-se şi anumite caracteristici, cum ar fi compresia sau stocarea în memorie. Familiile de coloane trebuie specificate la crearea tabelei şi nu ar trebui schimbate prea frecvent, numărul lor trebuind să fie redus. Numele unei familii de coloane trebuie să constea din caractere care pot fi afişate, caracteristică distinctă faţă de alte nume sau valori.

O coloană este referită ca familie:identificator, unde identificator este un şir arbitrar de octeţi. O familie poate avea oricât de multe coloane, neimpunându-se restricţii nici cu privire la valorile reţinute. Fiecare celulă poate avea o amprentă de timp care va fi inclusă implicit de sistem sau poate fi specificată explicit de utilizator, dacă doreşte să reţină mai multe versiuni ale unei valori, pe măsură ce se schimbă de-a lungul timpului. Vesiunile sunt ordonate descrescător în funcţie de amprenta de timp, permiţând obţinerea celei mai recente valori. Aceasta reprezintă o optimizare menită să favorizeze versiunile curente în detrimentul versiunilor istorice. Utilizatorul poate indica câte versiuni ale unei valori trebuie să fie reţinute. În plus, există suport pentru ştergerea predicatelor, permiţând reţinerea doar a valorilor dintr-o anumită perioadă. Valorile sunt şiruri de octeţi neinterpretaţi pe care îi va gestiona utilizatorul aplicaţiei.

Având în vedere faptul că modelul Bigtable (implementat de HBase) este definit ca o asociere multidimensională, pesistentă, distribuită şi împrăştiată, mecanismul de acces la o anumită valoare este dat de perechea mai multor caracteristici:

(Table, RowKey, Family, Column, Timestamp) → Value

sau, exprimată într-un stil mai asemănator limbajului de programare Java:

SortedMap<
    RowKey, List<
        SortedMap<
            Column, List<
                Value, Timestamp
            >
        >
    >
>

Aşadar, o tabela din HBase este o asociere ordonată pe baza cheii de rând (RowKey) a unei liste reprezentând familiile de coloane. La rândul ei, aceasta este tot o asociere ordonată pe baza numelui coloanei (Column), care conţine o listă a valorilor corespunzătoare (Value) în funcţie de amprenta de timp (Timestamp). Interesant este faptul că valorile din celule există în versiuni multiple şi unele coloane pot să fie scrise la momente diferite de timp. Prin intermediul API-ului se oferă o viziune coerentă a întregii tabele, fiind oferită cea mai recentă valoare a unei celule. Deşi datele sunt adăugate la momente diferite şi dispun de mai multe versiuni, utilizatorul va putea vedea o înregistrare ca o combinaţie a tuturor coloanelor, pentru fiecare selectându-se valoarea care asociază amprenta de timp cea mai recentă.

În exemplu, este prezentată o tabelă HBase cu două familii de coloane: data (având coloanele name şi address) şi meta (având coloanele mimetype şi size). Deşi pentru înregistrarea (rândul) identificat de cheia row1 atributele (coloanele) au fost precizate la momente diferite de timp (t3, t6, t8, t9), pentru unele dintre ele existând mai multe versiuni, reprezentarea înregistrării este dată de valorile cele mai recente pentru fiecare dintre coloane (marcate corespunzător).

Accesul la un rând este realizat atomic şi include orice număr de coloane citite sau scrise. Nu se oferă nici un fel de garanţii cu privire la tranzacţiile care implică mai multe rânduri sau mai multe tabele. Această proprietate reprezintă un factor care contribuie la faptul că arhitectura HBase este strict consistentă, astfel că fiecare utilizator care citeşte sau scrie poate face presupuneri legate de siguranţa stării rândului respectiv. Un alt factor care contribuie la consistenţa arhitecturii este reprezentat de posibilitatea stocării mai multor versiuni identificate prin intermediul unor amprente de timp.

În HBase, unitatea de bază ce asigură scalabilitatea şi echilibrul încărcării este denumită regiune. O regiune este reprezentată de o colecţie contiguă de rânduri stocate împreună. În momentul când devin prea mari, sunt împărţite în mod automat de sistem (eng. auto-sharding). Alternativ, ele pot fi de asemenea concatenate pentru a le reduce numărul precum şi fişierele de stocare necesare. Regiunile sunt echivalentul partiţiilor pe baza intervalelor de valori folosite în cazul bazelor de date. Acestea pot fi repartizate pe mai multe maşini fizice, distribuind încărcarea şi astfel oferind scalabilitate.

Fiecare regiune este gestionată de un server de regiune (eng. regionserver), fiecare dintre aceste servere putând opera asupra mai multor regiuni concomitent. Numărul de regiuni care pot fi gestionate de un server de regiune este cuprins între 10 şi 1000, fiecare regiune putând avea o dimensiune cuprinsă între 1GB şi 2GB. Aceste valori pot fi modificate cu timpul, principiul de distribuire a regiunilor pe serverele aferente fiind determinat de posibilităţile de stocare şi de capacităţile de procesare ale acestora. Implementarea unui astfel de mecanism permite recuperarea în caz de eroare în momentul în care un server se opreşte din funcţionare din cauza unei erori şi asigură echilibrarea încărcării. Procesul de împărţire este de asemenea foarte rapid (aproape instantaneu) de vreme ce regiunile sunt citite din fişierele de stocare originale până la momentul în care sunt rescrise în alte fişiere de stocare în mod asincron.

În HBase, datele sunt reţinute în fişiere de stocare, denumite HFile, implementate ca asocieri persistente şi ordonate invariabil de la chei la valori. Acestea oferă un API pentru a accesa valori specifice şi pentru a scana o gamă de valori, dându-se o cheie de început şi o cheie de sfârşit. Intern, ele sunt reprezentate ca secvenţe de blocuri sufixate de un index. Dimensiunea implicită a unui bloc este de 64KB, dar aceasta poate fi configurată diferit în cazul în care este necesar. El este încărcat atunci când fişierul e deschis şi reţinut în memorie. Întrucât fiecare HFile dispune de un index de bloc, căutările pot fi realizate printr-o singură parcurgere a datelor pe disc. Astfel, blocul care ar putea conţine cheia solicitată este identificat printr-o căutare binară în indecşii aflaţi în memorie, după care este citit de pe disc pentru a se determina cheia propriu-zisă. De regulă, fişierele de stocare sunt reţinute în sistemul de fişiere distribuit HDFS, caracterizat prin scalabilitate, persistenţă şi replicabilitate, garantând că datele nu sunt niciodată pierdute prin reţinerea modificărilor în cadrul unui număr de maşini fizice.

În momentul în care informaţiile sunt actualizate, acestea sunt stocate într-un jurnal de date transmise (eng. commit log), denumit în HBase jurnal de scriere anticipată (WAL – eng. write-ahead log), după care sunt transferate în memorie. Odată ce datele din memorie au depăşit o valoare maximă, acestea sunt reţinute pe disc sub forma unui fişier HFile. Ulterior, intrările reţinute în jurnal pot fi şterse până la valorile care nu au fost încă stocate persistent. Concomitent cu stocarea informaţiilor pe disc, sistemul poate gestiona operaţiile de citire şi de scriere fără a fi constrâns să le blocheze. Acest comportament este obţinut prin faptul că datele din memorie sunt stocate pe disc în timp ce informaţiile care se doresc actualizate sunt transmise la o nouă zonă de memorie care este goală. Datele din aceste zone tampon sunt deja sortate prin cheile corespunzătoare fişierelor HFile de pe disc, astfel încât nu mai trebuie realizate şi alte procesări, optimizându-se astfel transferul unui volum mare de date. Fiind utilizate pentru a reţine împreună datele între care există o anumită legătură, aceste chei sunt de fapt proprietăţi de localizare. Fişierele conţin perechi ordonate (cheie, valoare) fiind optimizate pentru operaţii de bloc cum ar fi citirea şi scrierea secvenţială a acestor valori. Întrucât fişierele de stocare sunt imuabile, valorile nu pot fi şterse doar prin eliminarea unei perechi (cheie, valoare) din cadrul acestora. De aceea, va fi utilizat un indicator de ştergere “piatră funerară” (eng. tombstone marker) pentru a indica faptul că informaţia respectivă nu mai există. În timpul procesului de obţinere a datelor, aceste marcaje maschează valorile reţinute, ascunzându-le de clienţii care interoghează baza de date.

Procesul de citire a datelor implică concatenarea informaţiilor din memorie (a datelor care nu au fost încă scrise pe disc) şi a fişierelor de stocare rezidente pe disc. În cadrul acestui proces, jurnalul de scriere anticipată nu este folosit deloc, el fiind interogat doar în situaţia în care un server s-a oprit din funcţionare înainte ca datele aflate în memorie să fie transferate pe disc.

Întrucât transferul datelor din zonele de memorie tampon pe disc face ca tot mai multe fişiere HFile să fie scrise, HBase implementează un sistem de întreţinere prin care fişierele HFile sunt concatenate în fişiere mai mari folosind un mecanism de compactare. Compactarea este minoră sau majoră. Compactarea minoră reduce numărul de fişiere de stocare prin rescrierea unor fişiere de dimensiuni mai mici în mai puţine fişiere de dimensiuni mai mari. De vreme ce datele sunt sortate în fiecare fişier HFile, procesul de concatenare este rapid, nefiind limitat decât de performanţele de intrare/ieşire ale discului. Compactarea majoră rescrie toate fişierele dintr-o familie de coloane din cadrul unei regiuni într-un singur fişier. Altă caracteristică distinctivă constă în faptul că procesul implică scanarea tuturor perechilor (cheie, valoare), astfel că intrările care sunt marcate ca fiind şterse pot fi ignorate. Tot acum este gestionată şi ştergerea predicatelor, eliminându-se valorile ce au expirat sau cele pentru care există prea multe versiuni.

HBase are trei componente principale:

1. biblioteca clientului;
2. un server de tip master;
3. mai multe servere de regiune.

Dacă serverele de regiune pot fi adăugate sau şterse în timpul funcţionării sistemului de gestiune pentru baze de date distribuite în funcţie de încărcarea acestuia, serverul de tip master este responsabil pentru repartizarea regiunilor către serverele aferente, folosind în acest sens un produs denumit Apache ZooKeeper, un serviciu de coordonare sigur, persistent, care oferă tuturor utilizatorilor un nivel înalt de disponibilitate.

Totodată, serverul de tip master este responsabil pentru gestiunea încărcării serverelor de regiune, distribuind regiunile către noduri mai puţin ocupate, realizându-se astfel echilibrarea acestora. El nu se ocupă cu stocarea datelor şi nu este implicat în procesul de obţinere a informaţiilor din baza de date. Rolul său este doar de a realiza încărcarea uniformă, gestionând starea clusterului, fără a oferi însă servicii de date nici serverelor de regiune şi nici clienţilor, astfel încât gradul său de ocupare este destul de redus. Serverul de tip master gestionează şi modificările la nivelul schemei de date precum şi alte operaţii legate de metadate (cum ar fi crearea de tabele sau de familii de coloane). Responsabilitatea serverelor de regiune constă în tratarea cererilor de citire şi de scriere pentru toate regiunile pe care le gestionează şi totodată pentru împărţirea regiunilor care depăşesc pragul configurat pentru dimensiunea maximă a acestora. Clienţii comunică direct cu serverele de regiune atunci când doresc să realizeze orice fel de operaţii care implică date.

Intern, HBase foloseşte tabele speciale denumite -ROOT- şi .META., în cadrul cărora menţine lista curentă, starea şi locaţia tuturor regiunilor din cluster. Tabela -ROOT- reţine lista tabelelor de regiune .META.. Tabela .META. conţine lista tuturor regiunilor din spaţiul utilizatorilor. Intrările din această tabelă sunt ordonate după denumirea regiunii, aceasta fiind formată din numele tabelei corespunzătoare regiunii din care face parte, rândul de început al regiunii, momentul de timp la care a fost creată şi un rezumat MD5 al acestor informaţii. Întrucât cheile de rând sunt sortate, identificarea unei regiuni care găzduieşte o anumită înregistrare este o problemă de determinarea unei intrări a cărei cheie este mai mare sau egală cu cea a cheii solicitate. Aceste tabele sunt actualizate pe măsură ce sunt realizate tranziţii în cadrul regiunilor, astfel încât starea tuturor regiunilor din cluster să reflecte starea lor curentă. Astfel de operaţii sunt împărţirea unei regiuni, activarea sau dezactivarea acesteia, ştergerea, relansarea unei regiuni de către procesul de echilibrare a încărcării sau în cazul opririi serverului de regiune din cauza unei erori.

Noii clienţi care se conectează la clusterul ZooKeeper obţin locaţia tabelei -ROOT- consultând-o pentru a determina locaţia regiunii .META. care conţine rândul solicitat. Ulterior, va fi realizată o căutare în această tabelă pentru a obţine spaţiul de utilizator al regiunii care găzduieşte informaţiile necesare precum şi locaţia acestuia. Numai după aceasta va interacţiona direct cu serverul de regiune identificat. Pentru a evita realizarea tuturor acestor operaţii de fiecare dată când trebuie să utilizeze informaţii din baza de date, locaţiile obţinute din interogarea tabelelor -ROOT- / .META. vor fi reţinute în zone de memorie tampon (eng. cache). De asemenea, pentru fiecare spaţiu de utilizator al regiunii, vor fi reţinute intervalele pentru cheia de rând (început şi sfârşit), astfel încât să poată determina serverele de regiune care găzduiesc informaţiile solicitate fără a fi necesar să interogheze tabela .META.. Acestea vor continua să fie folosite până în momentul în care se produce o eroare, situaţie în care tabela .META. este consultată din nou pentru a se obţine adresa serverului de regiune. Dacă şi regiunea .META. nu mai este actuală, se recurge la consultarea tabelei -ROOT-.

Ca şi Bigtable, HBase nu oferă un model de date relaţional complet, punând la dispoziţia utilizatorilor un model de date simplu, ce implementează controlul dinamic asupra dispunerii datelor şi asupra formatului acestora. Astfel, API-ul conţine operaţii pentru a crea şi a şterge tabele şi familii de coloane. Totodată, are funcţii pentru a modifica metadatele referitoare la tabele, respectiv familii de coloane, cum ar fi compresia sau dimensiunile blocurilor. Mai mult, există operaţii uzuale pentru clienţi pentru a crea sau a şterge valori precum şi pentru a le obţine, dându-se cheia de rând.

Un API pentru scanare permite iterarea eficientă pentru anumite limite ale rândurilor, specificând şi care coloane vor fi întoarse, respectiv numărul de versiuni pentru fiecare celulă. Coloanele pot fi identificate prin intermediul unor filtre, iar versiunile sunt determinate de intervalele de timp specificate (început şi sfârşit). În plus, sunt implementate şi funcţionalităţi mai avansate. Sistemul HBase oferă suport pentru tranzacţii ce includ un singur rând, implementând secvenţe de tip citeşte-modifică-scrie realizate în mod atomic pentru datele identificate printr-o unică cheie de rând. Deşi nu există tranzacţii pentru operaţii ce implică mai multe rânduri sau mai multe tabele, aceste operaţii pot fi realizate de utilizator în mod secvenţial, prin intermediul unui script, obţinându-se aceleaşi performanţe cu siguranţa accesului la date. Valorile celulelor pot fi interpretate drept contoare, actualizate în mod atomic printr-o singură operaţie astfel că, în ciuda naturii distribuite a arhitecturii, utilizatorii pot folosi acest mecanism pentru a implementa contoare globale, secvenţiale, strict consistente.

De asemenea, există posibilitatea de a rula cod oferit de utilizator în cadrul spaţiului de adrese al serverului. Contextul care suportă aceste operaţii la nivelul serverului este numit coprocesor, codul având acces la datele locale aflate pe server, el putând fi utilizat pentru a implementa sarcini pe seturi de date sau pentru a folosi expresii spre a sumariza datele pe baza diverşilor operatori. Această funcționalitate a fost implementată începând cu versiune 0.91.0 a HBase.

Sistemul HBase este de asemenea integrat cu paradigma MapReduce, oferind metode care convertesc tabelele în surse de date şi în locaţii pentru stocarea datelor de ieşire, specifice sarcinilor de acest tip.

Spre diferenţă de sistemele de baze de date tradiţionale (relaţionale), nu există un limbaj specific (cum ar fi SQL) pentru a interoga datele. Accesul nu este realizat declarativ ci mai degrabă imperativ prin intermediul API-ului de la nivelul utilizatorului. Acestea pot fi accesate printr-un shell specific sau prin limbajul de programare Java.

Shell-ul HBase este o interfaţă în linie de comandă către cluster, care poate fi folosită spre a realiza conexiunea către un server local sau la distanţă şi pentru a interacţiona cu acesta. Sunt oferite atât opţiuni corespunzătoare unui utilizator de tip administrator cât şi opţiuni corespunzătoare unui utilizator de tip client. Toate comenzile disponibile prin intermediul acestuia pot fi accesate şi folosind API-ul corespunzător limbajului de programare Java. Shell-ul HBase este bazat pe JRuby, o implementare a Ruby bazată pe maşina virtuală Java. Acesta foloseşte shell-ul interactiv Ruby (IRB – eng. Interactive Ruby Shell), utilizat pentru a rula comenzi Ruby şi pentru a primi răspuns imediat, moştenind suportul pentru istoria comenzilor şi pentru auto-completare.

Pornirea shell-ului HBase se face prin comanda hbase (din directorul $HBASE_HOME/bin), care primeşte argumentul shell:

student@aipi2015:/usr/local/hbase/bin$ ./hbase shell

Oprirea shell-ului HBase se face prin comenzile exit sau quit.

O listă a tuturor comenzilor disponibile poate fi obţinută prin intermediul comenzii help, aceasta putând fi de asemenea invocată pentru un grup de comenzi sau pentru o comandă specifică, precizate ca parametri între ghilimele:

hbase(main):001:0> help
hbase(main):002:0> help "COMMAND_GROUP"
hbase(main):003:0> help "COMMAND"

unde COMMAND_GROUP reprezintă un grup de comenzi (situaţie în care sunt afişate toate comenzile din grupul respectiv), iar COMMAND reprezintă o anumită comandă.

Shell-ul HBase poate fi apelat cu o serie de parametrii în linia de comandă, care pot fi obţinuţi dacă se specifică parametrii -h sau –help:

student@aipi2015:/usr/local/hbase/bin$ ./hbase shell [-h | --help]
Usage: shell [OPTIONS] [SCRIPTFILE [ARGUMENTS]]

 --format=OPTION                Formatter for outputting results.
                                Valid options are: console, html.
                                (Default: console)

 -d | --debug                   Set DEBUG log levels.
 -h | --help                    This help.

Opţiunea format specifică modul în care vor fi afişate rezultatele (variantele posibile fiind console – implicit, respectiv html), în timp ce opţiunile -d sau –debug permit ca shell-ul să fie rulat în modul DEBUG, afişându-se toate informaţiile de pe stivă, în caz că se produce o eroare.

Comenzie sunt grupate în 6 categorii diferite, în funcţie de relaţiile lor semnatice. La scrierea lor, trebuie să se ţină cont de următoarele reguli:

1. toate denumirile (coloane sau tabele) trebuie specificate între apostroafe;
2. toate valorile trebuie specificate între ghilimele (folosind reprezentarea octală – precedate de \0 sau hexazecimală – precedate de \x), în caz contrar fiind interpretate ca literali; textul aflat între apostroafe este interpretat ca fiind un literal, în timp ce textul aflat între ghilimele este interpolat, transformând valorile octale sau hexazecimale în octeţi;
3. parametrii unei comenzi vor fi separaţi folosind virgule;
4. în cazul în care pentru unele comenzi sunt necesare precizarea unor asocieri de tip (cheie, valoare), acestea trebuie realizate folosind hash-uri Ruby:
   { 'key1' ⇒ 'value1', 'key2' ⇒ 'value2', …, 'keyn' ⇒ 'valuen' }
   astfel că perechile (cheie, valoare) sunt specificate între acolade { }, separarea dintre cheie şi valoare făcându-se prin ⇒, iar între mai multe elemente prin virgulă. De regulă, acestea sunt folosite pentru constante predefinite cum ar fi VERSIONS, TTL, COMPRESSION, BLOCKCACHE, MAXLENGTH, situaţie în care valorile nu mai trebuie incluse între apostroafe.

Categoriile de comenzi suportate de HBase sunt:

1. comenzi generale;
2. comenzi pentru definirea datelor (DDL);
3. comenzi pentru manipularea datelor (DML);
4. comenzi pentru apelul diferitelor utilitare;
5. comenzi pentru replicare;
6. comenzi legate de securitate.

Funcţionalitatea comenzilor generale constă în posibilitatea de a obţine detalii cu privire la starea clusterului, a versiunii HBase utilizate precum şi a utilizatorului curent:

hbase> status
hbase> status 'summary'
1 servers, 0 dead, 2.0000 average load
hbase> status 'simple'
hbase> status 'detailed'

hbase> version
0.98.8-hadoop2, r6cfc8d064754251365e070a10a82eb169956d5fe, Fri Nov 14 18:26:29 PST 2015

hbase> whoami
aipi2015 (auth:SIMPLE)
    groups: aipi2015, adm, cdrom, sudo, dip, plugdev, lpadmin, sambashare

Comenzile pentru definirea datelor (DDL) dau utilizatorilor posibilitatea de a gestiona tabele, în structura cărora nu pot fi însă specificate decât familiile de coloane.

hbase> alter 't1', {NAME => 'f1', IN_MEMORY => true}, {NAME => 'f2', VERSIONS => 5}

hbase> alter 't1', NAME => 'f1', METHOD => 'delete'
hbase> alter 't1', 'delete' => 'f1'

hbase> alter 't1', MAX_FILESIZE => '134217728'
hbase> alter 't1', METHOD => 'table_att_unset', NAME => 'MAX_FILESIZE'

hbase> alter 't1', 'coprocessor'=>'hdfs:///foo.jar|com.foo.FooRegionObserver|1001|arg1=1,arg2=2'
hbase> alter 't1', METHOD => 'table_att_unset', NAME => 'coprocessor$1'

hbase> alter 't1', CONFIGURATION => {'hbase.hregion.scan.loadColumnFamiliesOnDemand' => 'true'}
hbase> alter 't1', {NAME => 'f2', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '10'}}

hbase> alter 't1', { NAME => 'f1', VERSIONS => 3 }, 
    { MAX_FILESIZE => '134217728' }, { METHOD => 'delete', NAME => 'f2' },
    OWNER => 'johndoe', METADATA => { 'mykey' => 'myvalue' }

hbase> alter_async 't1', {NAME => 'f1', IN_MEMORY => true}, {NAME => 'f2', VERSIONS => 5}
hbase> alter_async 't1', NAME => 'f1', METHOD => 'delete'
hbase> alter_async 't1', 'delete' => 'f1'
hbase> alter_async 't1', MAX_FILESIZE => '134217728'
hbase> alter_async 't1', METHOD => 'table_att_unset', NAME => 'MAX_FILESIZE'
hbase> alter_async 't1', 'coprocessor'=>'hdfs:///foo.jar|com.foo.FooRegionObserver|1001|arg1=1,arg2=2'
hbase> alter_async 't1', METHOD => 'table_att_unset', NAME => 'coprocessor$1'

hbase> alter_status 't1'

hbase> create 't1', 'f1', 'f2'
hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}
hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000, BLOCKCACHE => true}
hbase> create 't1', {NAME => 'f1', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '10'}}

hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'

hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit', 
              CONFIGURATION => {'hbase.hregion.scan.loadColumnFamiliesOnDemand' => 'true'}}

hbase> t1 = create 't1', 'f1'

hbase> describe 't1'

hbase> disable 't1'

hbase> disable_all 't.*'

hbase> drop 't1'

hbase> drop_all 't.*'

hbase> enable 't1'

hbase> enable_all 't.*'

hbase> exists 't1'

hbase> is_disabled 't1'

hbase> is_enabled 't1'

hbase> list

hbase> list 't.*'

hbase> show_filters

Comenzile pentru manipularea datelor (DML) implementează funcţionalităţile legate de transferul datelor de la utilizator spre baza de date, respectiv dinspre baza de date la utilizator.

hbase> count 't1'
hbase> count 't1', INTERVAL => 100000
hbase> count 't1', CACHE => 1000
hbase> count 't1', INTERVAL => 10, CACHE => 1000

hbase> t.count
hbase> t.count INTERVAL => 100000
hbase> t.count CACHE => 1000
hbase> t.count INTERVAL => 10, CACHE => 1000

student@aipi2015:/usr/local/hadoop/bin/hadoop$ jar hbase.jar rowcount

hbase> delete 't1', 'r1', 'c1', ts1

hbase> t.delete 'r1', 'c1', ts1

hbase> deleteall 't1', 'r1'
hbase> deleteall 't1', 'r1', 'c1'
hbase> deleteall 't1', 'r1', 'c1', ts1

hbase> t.deleteall 'r1'
hbase> t.deleteall 'r1', 'c1'
hbase> t.deleteall 'r1', 'c1', ts1

hbase> get 't1', 'r1'
hbase> get 't1', 'r1', {TIMERANGE => [ts1, ts2]}
hbase> get 't1', 'r1', {COLUMN => 'c1'}
hbase> get 't1', 'r1', 'c1'
hbase> get 't1', 'r1', {COLUMN => ['c1', 'c2']}
hbase> get 't1', 'r1', 'c1', 'c2'
hbase> get 't1', 'r1', ['c1', 'c2']
hbase> get 't1', 'r1', {COLUMN => 'c1', TIMESTAMP => ts1}
hbase> get 't1', 'r1', {COLUMN => 'c1', TIMERANGE => [ts1, ts2], VERSIONS => 4}
hbase> get 't1', 'r1', {COLUMN => 'c1', TIMESTAMP => ts1, VERSIONS => 4}
hbase> get 't1', 'r1', {FILTER => "ValueFilter(=, 'binary:abc')"}

hbase> t.get 'r1'
hbase> t.get 'r1', {TIMERANGE => [ts1, ts2]}
hbase> t.get 'r1', {COLUMN => 'c1'}
hbase> t.get 'r1', {COLUMN => ['c1', 'c2', 'c3']}
hbase> t.get 'r1', {COLUMN => 'c1', TIMESTAMP => ts1}
hbase> t.get 'r1', {COLUMN => 'c1', TIMERANGE => [ts1, ts2], VERSIONS => 4}
hbase> t.get 'r1', {COLUMN => 'c1', TIMESTAMP => ts1, VERSIONS => 4}
hbase> t.get 'r1', {FILTER => "ValueFilter(=, 'binary:abc')"}
hbase> t.get 'r1', 'c1'
hbase> t.get 'r1', 'c1', 'c2'
hbase> t.get 'r1', ['c1', 'c2']

hbase> get 't1', 'r1' {COLUMN => ['cf:qualifier1:toInt',   
    'cf:qualifier2:c(org.apache.hadoop.hbase.util.Bytes).toInt'] }

hbase> get_counter 't1', 'r1', 'c1'

hbase> t.get_counter 'r1', 'c1'

hbase> incr 't1', 'r1', 'c1'
hbase> incr 't1', 'r1', 'c1', 1
hbase> incr 't1', 'r1', 'c1', 10

hbase> t.incr 'r1', 'c1'
hbase> t.incr 'r1', 'c1', 1
hbase> t.incr 'r1', 'c1', 10

hbase> put 't1', 'r1', 'c1', 'value', ts1

hbase> t.put 'r1', 'c1', 'value', ts1

hbase> scan 'hbase:meta'
hbase> scan 'hbase:meta', {COLUMNS => 'info:regioninfo'}
hbase> scan 't1', {COLUMNS => ['c1', 'c2'], LIMIT => 10, STARTROW => 'xyz'}
hbase> scan 't1', {COLUMNS => 'c1', TIMERANGE => [1303668804, 1303668904]}
hbase> scan 't1', {FILTER => "(PrefixFilter ('row2') AND
    (QualifierFilter (>=, 'binary:xyz'))) AND (TimestampsFilter ( 123, 456))"}
hbase> scan 't1', {FILTER =>
    org.apache.hadoop.hbase.filter.ColumnPaginationFilter.new(1, 0)}

  
hbase> scan 't1', {COLUMNS => ['c1', 'c2'], CACHE_BLOCKS => false}
hbase> scan 't1', {RAW => true, VERSIONS => 10}

hbase> t = get_table 't'
hbase> t.scan

hbase> truncate 't1'

În cazul comenzilor pentru apelul diferitelor utilitare, sunt implementate de regulă operaţii administrative.

hbase> assign 'REGIONNAME'
hbase> assign 'ENCODED_REGIONNAME'

hbase> balance_switch true
hbase> balance_switch false

hbase> balancer

hbase> close_region 'REGIONNAME'
hbase> close_region 'REGIONNAME', 'SERVER_NAME'
hbase> close_region 'ENCODED_REGIONNAME'
hbase> close_region 'ENCODED_REGIONNAME', 'SERVER_NAME'

hbase> compact 't1'
hbase> compact 'r1'
hbase> compact 'r1', 'c1'
hbase> compact 't1', 'c1'

hbase> flush 'TABLENAME'
hbase> flush 'REGIONNAME'
hbase> flush 'ENCODED_REGIONNAME'

hbase> hlog_roll

hbase> major_compact 't1'
hbase> major_compact 'r1'
hbase> major_compact 'r1', 'c1'
hbase> major_compact 't1', 'c1'

hbase> move 'ENCODED_REGIONNAME'
hbase> move 'ENCODED_REGIONNAME', 'SERVER_NAME'

hbase> split 'tableName'
hbase> split 'regionName'
hbase> split 'tableName', 'splitKey'
hbase> split 'regionName', 'splitKey'

hbase> unassign 'REGIONNAME'
hbase> unassign 'REGIONNAME', true
hbase> unassign 'ENCODED_REGIONNAME'
hbase> unassign 'ENCODED_REGIONNAME', true

hbase> zk_dump

HBase oferă utilizatorilor şi posibilitatea de a gestiona modul în care sunt replicate datele în cadrul clusterelor, prin comenzile pentru replicare.

hbase> add_peer '1', "server1.cie.com:2181:/hbase"
hbase> add_peer '2', "zk1,zk2,zk3:2182:/hbase-prod"

hbase> disable_peer '1'

hbase> enable_peer '1'

hbase> list_peers

hbase> remove_peer '1'

hbase> start_replication

hbase> stop_replication

În cadrul HBase sunt definite comenzi legate de securitate, ce stabilesc permisiunile asupra unor obiecte ale tabelelor.

grant <user> <permissions> [<table> [<column family> [<column qualifier>]]

hbase> grant 'bobsmith', 'RWXCA'
hbase> grant 'bobsmith', 'RW', 't1', 'f1', 'col1'

revoke <user> [<table> [<column family> [<column qualifier>]]

hbase> revoke 'bobsmith'
hbase> revoke 'bobsmith', 't1', 'f1', 'col1'

user_permission <table>

hbase> user_permission
hbase> user_permission 'table1'

În cazul în care se doreşte rularea unui script, acesta poate fi transmis ca parametru comenzii hbase shell, după execuţia acestuia, terminalul revenind la starea sa iniţială:

student@aipi2015:/usr/local/hbase/bin$ ./hbase shell script.rb

O alternativă este reprezentată de a executa un script folosind interpretorul JRuby, ceea ce presupune că acesta va fi rulat ca o aplicaţie Java.

student@aipi2015:/usr/local/hbase/bin$ ./hbase org.jruby.Main script.rb

Shell-ul HBase permite utilizarea în cadrul său a unor metode Java şi totodată utilizarea unor instrucţiuni repetitive pentru popularea tabelelor cu valori de test.

Există numeroase alte posibilităţi de a accesa informaţiile conţinute într-o bază de date distribuită HBase, acest fapt putând fi realizat prin aplicaţii scrise în aproape orice limbaj de programare, în care apelurile de metode încapsulează invocări ale comenzilor definite de API-ul specific, dezvoltat folosind limbajul de programare Java. Astfel, servicii web de tip REST, Thrift (folosit de Facebook) sau Avro (proiect Apache) sunt doar câteva dintre soluţiile avute la îndemână.