Questo post è stato originariamente pubblicato tramite blogs.apache.org, lo ripubblichiamo qui in una forma leggermente modificata per comodità:
A prima vista, l'architettura Apache HBase sembra seguire un modello master/slave in cui il master riceve tutte le richieste ma il vero lavoro è svolto dagli slave. In realtà non è così, e in questo articolo descriverò quali compiti sono effettivamente gestiti dal padrone e dagli schiavi.
Regioni e server regionali
HBase è il gestore di archiviazione Hadoop che fornisce letture e scritture casuali a bassa latenza su HDFS e può gestire petabyte di dati. Una delle funzionalità interessanti di HBase è il partizionamento automatico, il che significa semplicemente che le tabelle vengono distribuite dinamicamente dal sistema quando diventano troppo grandi.
L'unità di base della scalabilità orizzontale in HBase è chiamata Regione . Le regioni sono un sottoinsieme dei dati della tabella e sono essenzialmente un intervallo ordinato e contiguo di righe archiviate insieme.
Inizialmente, esiste una sola regione per una tabella. Come mostrato di seguito, quando le regioni diventano troppo grandi dopo aver aggiunto più righe, la regione viene divisa in due nella chiave centrale, creando due metà più o meno uguali.
In HBase gli slave sono chiamati Region Servers . Ciascun server regionale è responsabile di servire un insieme di regioni e una regione (ovvero un intervallo di righe) può essere servita solo da un server regionale.
L'architettura HBase ha due servizi principali:HMaster responsabile del coordinamento del cluster e dell'esecuzione delle operazioni amministrative e di HRegionServer responsabile della gestione di un sottoinsieme di dati della tabella.
HMaster, assegnazione della regione e bilanciamento
Come accennato in precedenza, il Master HBase coordina il Cluster HBase ed è responsabile delle operazioni amministrative.
Un server regionale può servire una o più regioni. Ogni regione viene assegnata a un server di regione all'avvio e il master può decidere di spostare una regione da un server di regione a un altro come risultato di un'operazione di bilanciamento del carico. Il master gestisce anche gli errori del server regionale assegnando la regione a un altro server regionale.
La mappatura delle Regioni e dei Region Server è conservata in una tabella di sistema denominata META. Leggendo META, puoi identificare quale regione è responsabile della tua chiave. Ciò significa che per le operazioni di lettura e scrittura, il master non è affatto coinvolto e i client possono andare direttamente al Region Server responsabile per servire i dati richiesti.
Individuazione di una chiave di riga:quale regione server è responsabile?
Per mettere o ottenere una riga i client non devono contattare il master, i client possono contattare direttamente il Region Server che gestisce la riga specificata o, in caso di scansione client, possono contattare direttamente l'insieme di Region Server responsabili della gestione dell'insieme di chiavi:
Per identificare il server della regione, il client esegue una query sulla tabella META.
META è una tabella di sistema utilizzata per tenere traccia delle regioni. Contiene il nome del server e un identificatore di regione che comprende un nome di tabella e la chiave di riga iniziale. Osservando la chiave di avvio e la chiave di avvio della regione successiva, i client sono in grado di identificare l'intervallo di righe contenute in una determinata regione.
Il client mantiene una cache per le posizioni della regione. Ciò evita che i clienti raggiungano la tabella META ogni volta che viene emessa un'operazione sulla stessa regione. In caso di divisione di una regione o spostamento in un'altra regione Server (a causa di criteri di bilanciamento o assegnazione), il client riceverà un'eccezione come risposta e la cache verrà aggiornata recuperando le informazioni aggiornate dalla tabella META:
Poiché META è una tabella come le altre, il client deve identificare su quale server si trova META. Le posizioni META sono archiviate in un nodo ZooKeeper su assegnazione da parte del Master e il client legge direttamente il nodo per ottenere l'indirizzo del server della regione che contiene META.
Il design originale di HBase era basato su BigTable, con un'altra tabella chiamata -ROOT- contenente le posizioni META e Apache ZooKeeper che puntava ad essa. HBase 0.96 ha rimosso tale disposizione a favore solo di ZooKeeper, poiché META non può essere suddiviso e quindi consiste in un'unica regione.
API client:responsabilità principali e regionali
L'API client Java HBase ha due interfacce principali:
- Amministratore HBase consente l'interazione con lo "schema della tabella" creando/cancellando/modificando tabelle e consente l'interazione con il cluster assegnando/annullando regioni, unendo regioni insieme, richiedendo uno svuotamento e così via. Questa interfaccia comunica con il Master.
- HTable consente al client di manipolare i dati di una tabella specificata utilizzando get, put, delete e tutte le altre operazioni sui dati. Questa interfaccia comunica direttamente con i Region Server responsabili della gestione del set di chiavi richiesto.
Queste due interfacce hanno responsabilità separate:HBaseAdmin viene utilizzato solo per eseguire operazioni di amministrazione e comunicare con il Master mentre HTable viene utilizzato per manipolare i dati e comunicare con le regioni.
Conclusione
Come abbiamo visto qui, avere un'architettura Master/Slave non significa che ogni operazione passi attraverso il master. Per leggere e scrivere i dati, il client HBase, infatti, va direttamente allo specifico Region Server preposto alla gestione delle chiavi di riga per tutte le operazioni sui dati (HTable). Il Master viene utilizzato dal client solo per le operazioni di creazione, modifica e cancellazione delle tabelle (HBaseAdmin).
Sebbene esista un concetto di master, il client HBase non dipende da esso per le operazioni sui dati e il cluster può continuare a fornire dati anche se il master si interrompe.
Matteo Bertozzi è Software Engineer nel team Platform e un HBase Committer.
Se sei interessato a HBase, assicurati di registrarti a HBaseCon 2013 (13 giugno, San Francisco) – L'evento della community per contributori, sviluppatori, amministratori e utenti di HBase. Lo spazio è limitato!
