BigData: HBase

6.1 Chi ha inventato HBase e perché

In questa conferenza parleremo di uno strumento così meraviglioso come Hbase, che ha recentemente guadagnato una grande popolarità: ad esempio, Facebook lo utilizza come base del suo sistema di messaggistica, e questo la dice già lunga.

La conferenza parlerà del concetto di Big Table e della sua implementazione gratuita, delle caratteristiche del lavoro e della differenza sia rispetto ai classici database relazionali (come MySQL e Oracle) sia agli archivi di valori-chiave come Redis, Aerospike e memcached. Come al solito, iniziamo con la storia del problema. Come molti altri progetti BigData, Hbase è nato da un concetto sviluppato da Google. I principi alla base di Hbase sono stati descritti nell'articolo Bigtable: A Distributed Storage System for Structured Data .

Come abbiamo discusso nelle lezioni precedenti, i file ordinari sono abbastanza adatti per l'elaborazione di dati in batch utilizzando il paradigma MapReduce. D'altra parte, le informazioni memorizzate nei file sono piuttosto scomode da aggiornare; I file sono inoltre privati ​​​​della possibilità di accesso casuale. Per un lavoro rapido e conveniente con accesso casuale, esiste una classe di sistemi nosql come l'archiviazione di valori chiave, come Aerospike, Redis, Couchbase, Memcached. Tuttavia, l'elaborazione in batch è solitamente molto scomoda in questi sistemi. Hbase è un tentativo di combinare la comodità dell'elaborazione batch con la comodità dell'aggiornamento e dell'accesso casuale.

6.2 Modello dati

HBase è un database di valori-chiave distribuito, orientato alle colonne e multiversione.

• I dati sono organizzati in tabelle indicizzate da una chiave primaria chiamata RowKey in Hbase.
• Per ogni chiave RowKey, è possibile archiviare un set illimitato di attributi (o colonne).
• Le colonne sono organizzate in gruppi di colonne denominati Famiglia di colonne. Di norma, le colonne che hanno lo stesso modello di utilizzo e archiviazione vengono combinate in un'unica famiglia di colonne.
• Per ogni attributo possono essere memorizzate diverse versioni. Versioni diverse hanno timestamp diversi.

I record vengono archiviati fisicamente nell'ordine RowKey. In questo caso, i dati corrispondenti a diverse famiglie di colonne vengono memorizzati separatamente, il che consente, se necessario, di leggere i dati solo dalla famiglia di colonne desiderata.

Quando un determinato attributo viene eliminato, non viene eliminato fisicamente immediatamente, ma viene solo contrassegnato con uno speciale contrassegno di rimozione definitiva. L'eliminazione fisica dei dati avverrà successivamente, quando verrà eseguita l'operazione di Major Compaction.

Gli attributi appartenenti allo stesso gruppo di colonne e corrispondenti alla stessa chiave vengono archiviati fisicamente come un elenco ordinato. Qualsiasi attributo può essere assente o presente per ogni chiave e, se l'attributo è assente, ciò non causa il sovraccarico dovuto all'archiviazione di valori vuoti.

I nomi degli elenchi e dei gruppi di colonne sono fissi e hanno un layout chiaro. A livello di gruppo di colonne, vengono impostati parametri come il tempo di vita (TTL) e il numero massimo di versioni archiviate. Se la differenza tra il timestamp di una particolare versione e l'ora corrente è maggiore di TTL, la voce viene contrassegnata per l'eliminazione. Se il numero di versioni per un determinato attributo supera il numero massimo di versioni, anche il record viene contrassegnato per l'eliminazione.

Il modello di dati Hbase può essere ricordato come una corrispondenza valore-chiave:

<table, RowKey, Column Family, Column, timestamp> -> Value

6.3 Operazioni supportate

L'elenco delle operazioni supportate in hbase è abbastanza semplice. Sono supportate 4 operazioni principali:

• Put : aggiunge una nuova voce a hbase. Il timestamp di questa voce può essere impostato manualmente, altrimenti verrà impostato automaticamente sull'ora corrente.
• Get : recupera i dati per una RowKey specifica. Puoi specificare la famiglia di colonne da cui prenderemo i dati e il numero di versioni che vogliamo leggere.
• Scan : legge i record uno per uno. È possibile specificare il record da cui iniziare la lettura, il record a cui leggere, il numero di record da leggere, la famiglia di colonne da cui verrà eseguita la lettura e il numero massimo di versioni per ogni record.
• Elimina : contrassegna una versione specifica per l'eliminazione. Non ci sarà alcuna cancellazione fisica, sarà rinviata alla prossima Grande Compattazione (vedi sotto).

6.4 Architettura

HBase è un database distribuito che può essere eseguito su dozzine o centinaia di server fisici, garantendo un funzionamento ininterrotto anche in caso di guasto di alcuni di essi. Pertanto, l'architettura di HBase è piuttosto complessa rispetto ai classici database relazionali.

HBase utilizza due processi principali per il suo lavoro:

1. Region Server : serve una o più regioni. Una regione è un intervallo di record corrispondente a un intervallo specifico di RowKey consecutivi. Ogni regione contiene:

• L'archiviazione persistente è l'archiviazione dati principale in HBase. I dati sono archiviati fisicamente su HDFS, in uno speciale formato HFile. I dati in HFile sono archiviati nell'ordine RowKey. Una coppia (regione, famiglia di colonne) corrisponde ad almeno un HFIle.
• MemStore - buffer di scrittura. Poiché i dati vengono archiviati in HFile d in ordine ordinato, è piuttosto costoso aggiornare l'HFile per record. Invece, durante la scrittura, i dati entrano in una speciale area di memoria MemStore, dove si accumulano per un certo tempo. Quando il MemStore viene riempito a un valore critico, i dati vengono scritti in un nuovo HFile.
• BlockCache - cache per la lettura. Consente di risparmiare notevolmente tempo sui dati letti di frequente.
• Registro di scrittura in anticipo (WAL) . Poiché i dati vengono scritti nel memstore, esiste il rischio di perdita di dati a causa di un arresto anomalo. Per evitare che ciò accada, tutte le operazioni prima dell'effettiva implementazione delle manipolazioni rientrano in un apposito file di registro. Ciò consente di recuperare i dati dopo qualsiasi errore.

2. Master Server : il server principale nel cluster HBase. Il Master gestisce la distribuzione delle regioni tra i Region Server, mantiene un registro delle regioni, gestisce l'avvio di attività regolari e svolge altre attività utili.

Per coordinare le azioni tra i servizi, HBase utilizza Apache ZooKeeper, un servizio speciale progettato per gestire le configurazioni e sincronizzare i servizi.

Quando la quantità di dati nella regione aumenta e raggiunge una certa dimensione, Hbase avvia la suddivisione, un'operazione che divide la regione per 2. Per evitare continue divisioni di regioni, è possibile preimpostare i confini delle regioni e aumentarne il massimo misurare.

Poiché i dati per una regione possono essere archiviati in diversi HFile, Hbase li unisce periodicamente per velocizzare il lavoro. Questa operazione è chiamata compattazione in Hbase. Le compattazioni sono di due tipi:

• Compattazione minore . Si avvia automaticamente, viene eseguito in background. Ha una priorità bassa rispetto ad altre operazioni Hbase.
• Maggiore compattazione . Viene lanciato manualmente o al verificarsi di determinati trigger (ad esempio, da un timer). Ha una priorità elevata e può rallentare notevolmente il cluster. Le principali compattazioni vengono eseguite meglio in un momento in cui il carico sul cluster è ridotto. Major Compaction elimina anche fisicamente i dati precedentemente contrassegnati con la rimozione definitiva.

6.5 Modi per lavorare con HBase

Guscio HBase

Il modo più semplice per iniziare con Hbase è utilizzare l'utility shell hbase. È disponibile immediatamente dopo l'installazione di hbase su qualsiasi nodo del cluster hbase.

Hbase shell è una console jruby con supporto integrato per tutte le operazioni Hbase di base. Di seguito è riportato un esempio di creazione di una tabella utenti con due famiglie di colonne, esecuzione di alcune manipolazioni su di essa e rilascio della tabella alla fine nella shell hbase:

create 'users', {NAME => 'user_profile', VERSIONS => 5}, {NAME => 'user_posts', VERSIONS => 1231231231} 
put 'users', 'id1', 'user_profile:name', 'alexander' 
put 'users', 'id1', 'user_profile:second_name', 'alexander' 
get 'users', 'id1' 
put 'users', 'id1', 'user_profile:second_name', 'kuznetsov' 
get 'users', 'id1' 
get 'users', 'id1', {COLUMN => 'user_profile:second_name', VERSIONS => 5} 
put 'users', 'id2', 'user_profile:name', 'vasiliy' 
put 'users', 'id2', 'user_profile:second_name', 'ivanov' 
scan 'users', {COLUMN => 'user_profile:second_name', VERSIONS => 5} 
delete 'users', 'id1', 'user_profile:second_name' 
get 'users', 'id1' 
disable 'users' 
drop 'users'

API nativa

Come la maggior parte degli altri progetti relativi ad Hadoop, hbase è implementato in Java, quindi l'API nativa è disponibile in Java. L'API nativa è abbastanza ben documentata sul sito Web ufficiale. Ecco un esempio di utilizzo dell'API Hbase presa da lì:

import java.io.IOException;

import org.apache.hadoop.hbase.*;
import org.apache.hadoop.hbase.client.*;
import org.apache.hadoop.hbase.util.Bytes;

public class MyLittleHBaseClient {
  public static void main(String[] args) throws IOException {
	Configuration config = HBaseConfiguration.create();
	Connection connection = ConnectionFactory.createConnection(config);
	try {
  	Table table = connection.getTable(TableName.valueOf("myLittleHBaseTable"));
  	try {
    	Put p = new Put(Bytes.toBytes("myLittleRow"));
    	p.add(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"),
    	Bytes.toBytes("Some Value"));
    	table.put(p);

    	Get g = new Get(Bytes.toBytes("myLittleRow"));
    	Result r = table.get(g);
    	byte [] value = r.getValue(Bytes.toBytes("myLittleFamily"),
      	Bytes.toBytes("someQualifier"));

    	String valueStr = Bytes.toString(value);
    	System.out.println("GET: " + valueStr);

    	Scan s = new Scan();
    	s.addColumn(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"));
    	ResultScanner scanner = table.getScanner(s);
    	try {
       	for (Result rr = scanner.next(); rr != null; rr = scanner.next()) {
         	System.out.println("Found row: " + rr);
       	}
     	} finally {
       	scanner.close();
     	}
   	} finally {
     	if (table != null) table.close();
   	}
 	} finally {
   	connection.close();
 	}
  }
}

Risparmio, REST e supporto per altri linguaggi di programmazione

Per lavorare con altri linguaggi di programmazione, Hbase fornisce Thrift API e Rest API. Sulla base di essi, i client vengono creati per tutti i principali linguaggi di programmazione: Python, PHP, Java Script, ecc.

6.6 Alcune caratteristiche del lavoro con HBase

1. Hbase si integra immediatamente con MapReduce e può essere utilizzato come input e output utilizzando gli speciali TableInputFormat e TableOutputFormat.

2. È molto importante scegliere il RowKey corretto. RowKey deve fornire una buona distribuzione uniforme tra le regioni, altrimenti c'è il rischio delle cosiddette "aree calde" - regioni che vengono utilizzate molto più spesso di altre, il che porta a un uso inefficiente delle risorse di sistema.

3. Se i dati non vengono caricati singolarmente, ma immediatamente in grandi batch, Hbase supporta uno speciale meccanismo di BulkLoad che consente di caricare i dati molto più velocemente rispetto all'utilizzo di singoli Put. BulkLoad è essenzialmente un'operazione in due fasi:

   • Formazione di HFile senza la partecipazione di put utilizzando uno speciale lavoro MapReduce
   • Inserimento di questi file direttamente in Hbase

4. Hbase supporta l'invio delle sue metriche al server di monitoraggio Ganglia. Questo può essere molto utile durante l'amministrazione di Hbase per andare a fondo dei problemi di Hbase.

chiave di riga

RowKey è l'ID utente, che è un GUUID, una stringa generata appositamente per essere univoca in tutto il mondo. I GUUID sono distribuiti uniformemente, il che offre una buona distribuzione dei dati tra i server.

Famiglia di colonne

Il nostro storage utilizza due famiglie di colonne:

• dati. Questo gruppo di colonne memorizza i dati che non sono più rilevanti per scopi pubblicitari, come il fatto che un utente abbia visitato determinati URL. Il TTL per questa famiglia di colonne è impostato su 2 mesi, il limite del numero di versioni è 2000.
• longdata. Questo gruppo di colonne memorizza i dati che non perdono la loro rilevanza nel tempo, come il sesso, la data di nascita e altre caratteristiche dell'utente "eterne".

Altoparlanti

Ogni tipo di fatti utente è archiviato in una colonna separata. Ad esempio, la colonna Data:_v memorizza gli URL visitati dall'utente e la colonna LongData:gender memorizza il sesso dell'utente.

Il timestamp di questo fatto viene memorizzato come timestamp. Ad esempio, nella colonna Dati:_v, il timestamp è l'ora in cui l'utente ha visitato un URL specifico.

Questa struttura di archiviazione dei dati utente si adatta molto bene al nostro modello di utilizzo e consente di aggiornare rapidamente i dati utente, ottenere rapidamente tutte le informazioni necessarie sugli utenti e, utilizzando MapReduce, elaborare rapidamente i dati su tutti gli utenti contemporaneamente.

6.7 Alternative

HBase è piuttosto complesso da amministrare e utilizzare, quindi prima di utilizzare HBase ha senso esaminare le alternative:

• Database relazionali . Un'ottima alternativa, specialmente nel caso in cui i dati stiano su una macchina. Inoltre, prima di tutto, dovresti pensare ai database relazionali nel caso in cui le transazioni di indici diversi dal primario siano importanti.

• Archiviazione di valori-chiave . Archivi come Redis e Aerospike sono più adatti quando è necessaria la latenza e l'elaborazione in batch è meno importante.

• File e loro elaborazione con MapReduce . Se i dati vengono solo aggiunti e raramente aggiornati/modificati, è meglio non utilizzare HBase, ma semplicemente archiviare i dati nei file. Per semplificare il lavoro con i file, puoi utilizzare strumenti come Hive, Pig e Impala.

L'uso di HBase è giustificato quando:

• Ci sono molti dati e non si adattano a un computer / server
• I dati vengono frequentemente aggiornati ed eliminati
• C'è una “chiave” esplicita nei dati, a cui conviene legare tutto il resto
• Hai bisogno di elaborazione in batch
• È necessario l'accesso casuale ai dati tramite chiavi specifiche