Di recente ho tenuto un discorso al LA Hadoop User Group su Apache HBase Cosa fare e cosa non fare. Il pubblico era eccellente e aveva domande molto informate e ben articolate. Jody di Shopzilla è stato un ospite eccellente e gli devo un grande ringraziamento per avermi dato l'opportunità di parlare con oltre 60 Hadoopers di Los Angeles. Dal momento che non tutti vivono a Los Angeles o potrebbero arrivare al meetup, ho riassunto qui alcuni dei punti salienti. Per quelli di voi con una giornata impegnativa, ecco il tl;dr:
- HBase è buono, ma non è un sostituto di RDBMS o HDFS
- Una buona configurazione significa un buon funzionamento
- Monitor monitor monitor monitor monitor
Noi di Cloudera siamo grandi fan di HBase. Amiamo la tecnologia, amiamo la community e abbiamo scoperto che si adatta perfettamente a molte applicazioni. Gli usi di successo di HBase sono stati ben documentati e, di conseguenza, molte organizzazioni stanno valutando se HBase sia adatto per alcune delle loro applicazioni. L'impulso per il mio intervento e per questo post di follow-up sul blog è di chiarire alcune delle buone applicazioni per HBase, mettere in guardia contro alcune applicazioni scadenti ed evidenziare passaggi importanti per una distribuzione di HBase di successo.
Quando usare HBase
La considerazione più importante quando si esamina HBase è che, sebbene sia un'ottima soluzione a molti problemi, non è un proiettile d'argento. HBase non è ottimizzato per le classiche applicazioni transazionali o anche per l'analisi relazionale. Inoltre, non è un sostituto completo di HDFS quando si esegue MapReduce in batch di grandi dimensioni. Dai un'occhiata ad alcuni dei casi d'uso in questo post per avere un'idea di quali applicazioni sono adatte per HBase e se hai domande, vai avanti e pubblica negli elenchi. Ho già detto che la community è fantastica?
Con questo avvertimento, perché dovresti usare HBase? Se la tua applicazione ha uno schema variabile in cui ogni riga è leggermente diversa, dovresti guardare HBase. Ad esempio, eseguire un esercizio di modellazione utilizzando uno schema relazionale standard; Quando non puoi aggiungere colonne abbastanza velocemente e la maggior parte di esse è NULL in ogni riga, dovresti considerare HBase. Se trovi che i tuoi dati sono archiviati in raccolte, ad esempio alcuni metadati, dati di messaggi o dati binari che sono tutti codificati sullo stesso valore, dovresti considerare HBase. Se hai bisogno di un accesso ai dati basato su chiavi durante l'archiviazione o il recupero, dovresti prendere in considerazione HBase.
Servizi di supporto
Supponendo che tu sia convinto che HBase sia adatto alla tua applicazione, ecco alcuni suggerimenti che devi considerare quando lo distribuisci. Ci sono alcuni servizi di supporto che sono importanti e uno che è richiesto. Se non hai mai guardato ZooKeeper prima, ora è il momento. HBase utilizza ZooKeeper per vari servizi di coordinamento distribuito come l'elezione principale. Man mano che HBase si sviluppa e cresce, continua a fare affidamento su ZooKeeper per funzionalità aggiuntive, rendendolo una parte fondamentale del sistema. Inoltre, dovresti disporre di servizi di rete adeguati come NTP e DNS. HBase dipende dal fatto che tutti i nodi del cluster abbiano orologi strettamente sincronizzati e facciano riferimento l'uno all'altro in modo coerente. L'uso di NTP e DNS assicura di non incorrere in comportamenti strani quando un nodo A pensa che l'ora sia domani e il nodo B pensa che sia ieri. Eviterai anche situazioni in cui il nodo master dice al nodo C di servire una regione ma il nodo C non conosce il proprio nome e non risponde. L'utilizzo di NTP e DNS ti farà risparmiare un sacco di mal di testa all'inizio.
Ho detto che la considerazione più importante quando si seleziona HBase è assicurarsi di avere un caso d'uso adatto. La cosa più importante da fare quando si utilizza HBase è monitorare il sistema. Il monitoraggio è fondamentale per il successo delle operazioni di HBase. Come nel caso di molti sistemi distribuiti, HBase è soggetto a guasti a cascata. Se un nodo inizia a scambiarsi, può perdere il contatto con il master, facendo sì che un altro server raccolga il carico e venga sovraccaricato. Quel secondo server fallirà e l'errore si verificherà a cascata. È necessario monitorare la memoria, la CPU, l'I/O e la latenza di rete e la larghezza di banda su ciascuno dei nodi HBase per assicurarsi che funzionino entro parametri integri. Il monitoraggio è la pratica più importante per il funzionamento di un cluster HBase integro.
Buone pratiche per l'architettura HBase
Avanti veloce al tuo cluster HBase ben monitorato che esegue un caso d'uso perfetto, ecco alcune buone pratiche. Usa un prefisso chiave che si distribuisca bene in base al tuo caso d'uso. Se si antepone alla chiave il timestamp o qualsiasi valore simile che, una volta ordinato, viene archiviato o sottoposto a query in un batch, è probabile che sovraccaricare ogni server della regione a sua volta invece di distribuire uniformemente il carico. Dovresti anche mantenere il numero di regioni a un numero ragionevole in base alle dimensioni del memstore e alla quantità di RAM e la JVM RegionServer dovrebbe essere limitata a 12 GB di heap java per ridurre al minimo le lunghe pause GC. Ad esempio, una macchina con 36 GB di RAM che esegue anche un demone DataNode potrebbe gestire circa 100 regioni con scritture attive e un memstore di 48 MB ciascuna. Ciò consente un margine sufficiente per i requisiti di memoria di DataNode e RegionServer, spazio nel buffer dei file Linux e una dimensione di svuotamento ragionevole per ciascun RegionServer.
Alcuni consigli per la configurazione includono la disabilitazione della compattazione automatica (per impostazione predefinita, avviene ogni 24 ore dal momento dell'avvio HBase) e pianificarne l'esecuzione ogni giorno in un'ora non di punta. Dovresti anche configurare la compressione (come LZO) e inserire esplicitamente la directory conf HBase configurata correttamente nel tuo CLASSPATH.
HBase NON FARE
Abbiamo coperto un'ampia gamma di buone pratiche per HBase. Ci sono anche alcuni schemi di utilizzo da evitare. Ad esempio, non aspettarti di utilizzare HBase come sostituto all'ingrosso di tutti i tuoi database relazionali. HBase è ottimo in molte cose ma non sostituisce i database relazionali. Per cominciare, non parla SQL, non ha un ottimizzatore, supporta transazioni o join incrociati. Se non usi nessuno di questi nella tua applicazione di database, HBase potrebbe benissimo essere la soluzione perfetta.
Prestare attenzione quando si eseguono carichi di lavoro misti su un cluster HBase. Quando si dispone di SLA sull'accesso HBase indipendentemente da qualsiasi lavoro MapReduce (ad esempio, una trasformazione in Pig e la fornitura di dati da HBase), eseguirli su cluster separati. HBase è ad alta intensità di CPU e memoria con accesso sporadico di I/O sequenziale di grandi dimensioni, mentre i lavori MapReduce sono principalmente associati a I/O con memoria fissa e CPU sporadica. Combinati questi possono portare a latenze imprevedibili per HBase e contesa CPU tra i due. Un cluster condiviso richiede anche un minor numero di slot attività per nodo per soddisfare i requisiti della CPU HBase (in genere metà degli slot su ciascun nodo che allocheresti senza HBase). Tieni d'occhio anche lo scambio di memoria. Se HBase inizia a scambiare, ci sono buone probabilità che manchi un battito cardiaco e venga eliminato dal cluster. In un cluster occupato, ciò potrebbe sovraccaricare un'altra regione, causandone lo scambio e una cascata di errori.
Pensieri finali
Un ultimo consiglio prima di riassumere. Quando si carica HBase, utilizzare HFileOututFormat se si esegue il caricamento tramite un processo MapReduce o una raccolta di server che utilizzano put in batch. Il caricamento con un singolo client creerà un collo di bottiglia su quel client e non sfrutterà la scalabilità offerta da HBase.
In sintesi, prendi in considerazione HBase quando carichi dati per chiave, cerchi dati per chiave (o intervallo), fornisci dati per chiave, esegui query sui dati per chiave o quando archivi dati per riga che non sono conformi a uno schema.
Casi d'uso
- Apache HBase:basato su HBase Wiki
- Mozilla:spostamento di Socorro in HBase
- Facebook:il nuovo sistema di messaggistica in tempo reale di Facebook:HBase
- StumbleUpon:HBase su StumbleUpon
