{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teoria e pratica dell'uso di HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Buongiorno! Mi chiamo Danil Lipovoy e il nostro team in Sbertech ha iniziato a utilizzare HBase come archivio per i dati operativi. Durante i nostri studi, abbiamo accumulato esperienza che desideriamo sistematizzare e descrivere (speriamo sia utile a molti). Tutti gli esperimenti riportati di seguito sono stati condotti con le versioni HBase 1.2.0-cdh5.14.2 e 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Architettura generale <\/li>\n
  2. Scrittura dei dati in HBASE<\/li>\n
  3. Lettura dei dati da HBASE<\/li>\n
  4. Caching dei dati<\/li>\n
  5. Elaborazione batch dei dati MultiGet\/MultiPut<\/li>\n
  6. Strategia di suddivisione delle tabelle in regioni (sharding)<\/li>\n
  7. Resilienza, compattazione e localizzazione dei dati<\/li>\n
  8. Impostazioni e prestazioni<\/li>\n
  9. Test di carico<\/li>\n
  10. Conclusioni<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. Architettura generale<\/h2>\n

    \n\"Teoria
    \nIl Master di riserva ascolta il heartbeat del Master attivo sul nodo ZooKeeper e, in caso di scomparsa, assume le funzioni del Master. <\/p>\n

    2. Scrittura dei dati in HBASE<\/h2>\n

    \nIniziamo esaminando il caso pi\u00f9 semplice: la scrittura di un oggetto chiave-valore in una certa tabella tramite put(rowkey). Il client deve prima determinare dove si trova il server della regione radice (Root Region Server - RRS), che memorizza la tabella hbase:meta. Questa informazione viene ottenuta da ZooKeeper. Dopodich\u00e9, si rivolge al RRS e legge la tabella hbase:meta, da cui estrae le informazioni su quale RegionServer (RS) \u00e8 responsabile della memorizzazione dei dati per la chiave rowkey nella tabella di interesse. Per utilizzi futuri, la tabella meta viene memorizzata nella cache dal client, e cos\u00ec i successivi accessi avvengono pi\u00f9 velocemente, direttamente al RS.<\/p>\n

    Successivamente, il RS, ricevuto il comando, prima di tutto lo scrive nel WriteAheadLog (WAL), necessario per il ripristino in caso di crash. Poi salva i dati in MemStore. Questo \u00e8 un buffer in memoria che contiene un insieme ordinato di chiavi di questa regione. La tabella pu\u00f2 essere suddivisa in regioni (partizioni), ciascuna delle quali contiene un insieme di chiavi non sovrapposto. Questo consente, posizionando le regioni su server diversi, di ottenere prestazioni pi\u00f9 elevate. Tuttavia, nonostante l'evidenza di questa affermazione, vedremo in seguito che non sempre funziona.<\/p>\n

    Dopo aver posizionato la registrazione in MemStore, al client viene restituita una risposta che indica che la registrazione \u00e8 stata salvata con successo. In realt\u00e0, viene memorizzata solo nel buffer e finir\u00e0 su disco solo dopo che sar\u00e0 trascorso un certo intervallo di tempo o quando sar\u00e0 piena di nuovi dati. <\/p>\n

    \"Teoria
    \nNell'operazione \u00abDelete\u00bb, i dati non vengono fisicamente rimossi. Vengono semplicemente contrassegnati come eliminati, e la loro vera eliminazione avviene al momento della chiamata della funzione major compact, di cui si parla pi\u00f9 dettagliatamente nel paragrafo 7.<\/p>\n

    I file in formato HFile si accumulano in HDFS e di tanto in tanto viene avviato il processo minor compact, che unisce semplicemente file piccoli in file pi\u00f9 grandi, senza eliminare nulla. Col tempo, questo diventa un problema che si manifesta solo durante la lettura dei dati (ci torneremo pi\u00f9 tardi). <\/p>\n

    Oltre al processo di caricamento descritto sopra, esiste una procedura molto pi\u00f9 efficiente, che rappresenta probabilmente il punto di forza di questo database: il BulkLoad. Si tratta del caricamento autonomo degli HFiles direttamente su disco, il che consente di scalare in modo eccellente e raggiungere velocit\u00e0 molto soddisfacenti. In sostanza, il limite non \u00e8 HBase, ma le capacit\u00e0 hardware. Di seguito sono riportati i risultati di caricamento su un cluster composto da 16 RegionServer e 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread), versione HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teoria
    \n
    \nQui si pu\u00f2 vedere che aumentando il numero di partizioni (regioni) nella tabella, cos\u00ec come gli executor Spark, otteniamo un incremento della velocit\u00e0 di caricamento. Anche la velocit\u00e0 dipende dalla quantit\u00e0 di scrittura. Blocchi grandi offrono un aumento in termini di MB\/sec, mentre i blocchi piccoli in termini di numero di record inseriti in unit\u00e0 di tempo, a parit\u00e0 di altre condizioni. <\/p>\n

    \u00c8 anche possibile avviare il caricamento in due tabelle contemporaneamente e ottenere un raddoppio della velocit\u00e0. Qui si osserva che la scrittura di blocchi da 10 KB simultaneamente in due tabelle avviene a una velocit\u00e0 di circa 600 MB\/sec ciascuna (complessivamente 1275 MB\/sec), che corrisponde alla velocit\u00e0 di scrittura in una tabella di 623 MB\/sec (vedi n. 11 sopra).<\/p>\n

    \"Teoria
    \nTuttavia, il secondo avvio con scritture di 50 KB mostra che la velocit\u00e0 di caricamento cresce gi\u00e0 in modo marginale, il che indica che ci si sta avvicinando ai valori limite. \u00c8 importante notare che non viene praticamente generato alcun carico su HBase; tutto ci\u00f2 che gli \u00e8 richiesto \u00e8 prima fornire i dati da hbase:meta, e dopo il caricamento di HFiles, svuotare i dati di BlockCache e salvare il buffer MemStore su disco, se non \u00e8 vuoto.<\/p>\n

    3. Lettura dei dati da HBASE<\/h2>\n

    \nSe consideriamo che tutte le informazioni da hbase:meta sono gi\u00e0 disponibili per il cliente (vedi punto 2), la richiesta viene inviata direttamente al RS che conserva la chiave necessaria. Inizialmente, la ricerca avviene in MemCache. Indipendentemente dal fatto che ci siano dati o meno, la ricerca avviene anche nel buffer BlockCache e, se necessario, negli HFiles. Se i dati vengono trovati nel file, vengono collocati in BlockCache e nella richiesta successiva verranno restituiti pi\u00f9 rapidamente. La ricerca in HFile avviene abbastanza rapidamente grazie all'uso del filtro di Bloom, cio\u00e8, leggendo un piccolo volume di dati, determina immediatamente se quel file contiene la chiave richiesta e, se non la contiene, passa al successivo.<\/p>\n

    \"Teoria
    \nRicevuti i dati da queste tre fonti, il RS forma la risposta. In particolare, pu\u00f2 restituire pi\u00f9 versioni trovate dell'oggetto se il cliente richiede la versioning.<\/p>\n

    4. Caching dei dati<\/h2>\n

    \nI buffer MemStore e BlockCache occupano fino all'80% della memoria on-heap dedicata del RS (il resto \u00e8 riservato per le attivit\u00e0 di servizio del RS). Se il modo tipico di utilizzo \u00e8 tale che i processi scrivono e leggono immediatamente questi stessi dati, ha senso ridurre BlockCache e aumentare MemStore, poich\u00e9 durante la scrittura i dati non vengono memorizzati nel cache di lettura, quindi l'uso di BlockCache avverr\u00e0 meno frequentemente. Il buffer BlockCache \u00e8 composto da due parti: LruBlockCache (sempre on-heap) e BucketCache (di solito off-heap o su SSD). \u00c8 consigliabile utilizzare BucketCache quando ci sono molte richieste di lettura e non possono essere memorizzate in LruBlockCache, il che porta a un'attivit\u00e0 intensa del Garbage Collector. Tuttavia, non ci si aspetti un aumento radicale delle prestazioni dall'uso del cache di lettura, ma ne parleremo pi\u00f9 avanti nel punto 8.<\/p>\n

    \"Teoria
    \nBlockCache \u00e8 uno per tutto il RS, mentre MemStore \u00e8 unico per ogni tabella (uno per ogni Column Family).<\/p>\n

    Come \u00e8 descritto<\/a><\/noindex> In teoria, durante la scrittura i dati non vengono memorizzati nel cache e, in effetti, tali parametri CACHE_DATA_ON_WRITE per la tabella e 'Cache DATA on Write' per il RS sono impostati su false. Tuttavia, in pratica, se si scrivono dati in MemStore, poi si effettua un flush su disco (pulendo in questo modo), quindi si elimina il file risultante, eseguendo una richiesta get otteniamo comunque i dati. Inoltre, anche se si disattiva completamente BlockCache e si riempie la tabella con nuovi dati, poi si provoca un flush di MemStore su disco, si eliminano e si richiedono da un'altra sessione, i dati verranno comunque estratti da qualche parte. Quindi HBase conserva non solo i dati, ma anche misteri enigmatici.<\/p>\n

    hbase(main):001:0> crea 'ns:magic', 'cf'\nTabella ns:magic creata\nTempo impiegato 1.1533 secondi\nhbase(main):002:0> metti 'ns:magic', 'key1', 'cf:c', 'provami_a_eliminare'\nTempo impiegato 0.2610 secondi\nhbase(main):003:0> flush 'ns:magic'\nTempo impiegato 0.6161 secondi\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> ottieni 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, valore=provami_a_eliminare\n<\/code><\/pre>\n
    \nIl parametro \"Cache DATA on Read\" \u00e8 impostato su false. Se hai idee, sei il benvenuto a discuterne nei commenti.<\/p>\n
    5. Elaborazione batch di dati MultiGet\/MultiPut<\/h2>\n
    \nL'elaborazione delle richieste singole (Get\/Put\/Delete) \u00e8 un'operazione piuttosto costosa, quindi \u00e8 consigliabile unirle in un List o List, il che consente di ottenere un notevole miglioramento delle prestazioni. Questo \u00e8 particolarmente vero per l'operazione di scrittura, ma quando si legge c'\u00e8 il seguente problema. Nel grafico qui sotto \u00e8 mostrato il tempo di lettura di 50.000 record da MemStore. La lettura \u00e8 stata eseguita in un singolo thread e sull'asse orizzontale \u00e8 mostrato il numero di chiavi nella richiesta. Qui si vede che aumentando fino a mille chiavi in una sola richiesta, il tempo di esecuzione diminuisce, cio\u00e8 la velocit\u00e0 aumenta. Tuttavia, con la modalit\u00e0 MSLAB abilitata per impostazione predefinita, dopo questa soglia si verifica un drastico calo delle prestazioni, e pi\u00f9 grande \u00e8 il volume dei dati nel record, pi\u00f9 lungo \u00e8 il tempo di lavoro. <\/p>\n
    \"Teoria
    \n
    \nI test sono stati eseguiti su una macchina virtuale, 8 core, versione HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    La modalit\u00e0 MSLAB \u00e8 progettata per ridurre la frammentazione dell'heap, che si verifica a causa della mescolanza di dati di nuove e vecchie generazioni. Come soluzione al problema, quando MSLAB \u00e8 abilitato, i dati vengono collocati in celle (chunk) relativamente piccole e vengono elaborati a porzioni. Di conseguenza, quando il volume nel pacchetto dati richiesto supera la dimensione assegnata, le prestazioni diminuiscono drasticamente. D'altro canto, disabilitare questa modalit\u00e0 non \u00e8 desiderabile, poich\u00e9 porter\u00e0 a interruzioni a causa di GC nei momenti di intenso lavoro con i dati. Una buona soluzione \u00e8 aumentare la dimensione delle celle, nel caso di scritture attive tramite put contemporaneamente alla lettura. \u00c8 importante notare che il problema non si verifica se dopo la scrittura viene eseguito il comando flush, che scarica MemStore su disco, o se si esegue il caricamento tramite BulkLoad. Nella tabella sottostante \u00e8 mostrato che le richieste da MemStore di dati di dimensioni maggiori (e numero uguale) portano a un rallentamento. Tuttavia, aumentando la chunksize, riportiamo il tempo di elaborazione alla normalit\u00e0.<\/p>\n
    \"Teoria
    \nOltre all'aumento del chunksize, aiuta anche la suddivisione dei dati per regioni, ovvero il partizionamento delle tabelle. Questo porta a una minore quantit\u00e0 di richieste per ogni regione e, se inserite in una cella, la risposta rimane buona.<\/p>\n
    6. Strategia di partizionamento delle tabelle per regioni (partitioning)<\/h2>\n
    \nPoich\u00e9 HBase \u00e8 un archivio key-value e la partizione avviene per chiave, \u00e8 fondamentale distribuire i dati uniformemente su tutte le regioni. Ad esempio, la partizione di una tabella in tre parti porter\u00e0 a una divisione dei dati in tre regioni:<\/p>\n
    \"Teoria
    \nA volte, ci\u00f2 pu\u00f2 portare a un rallentamento significativo, se i dati caricati in seguito sono per esempio valori long che iniziano nella maggior parte dei casi con la stessa cifra, ad esempio:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Poich\u00e9 le chiavi sono memorizzate come array di byte, tutte inizieranno allo stesso modo e si riferiranno a una regione #1 che memorizza questo intervallo di chiavi. Esistono diverse strategie di partizionamento:<\/p>\n
    HexStringSplit \u2013 Trasforma la chiave in una stringa con codifica esadecimale nell'intervallo \"00000000\" => \"FFFFFFFF\" riempiendo a sinistra con zeri.<\/p>\n
    UniformSplit \u2013 Trasforma la chiave in un array di byte con codifica esadecimale nell'intervallo \"00\" => \"FF\" riempiendo a destra con zeri.<\/p>\n
    Inoltre, \u00e8 possibile specificare qualsiasi intervallo o insieme di chiavi per la partizione e configurare l'auto-partizionamento. Tuttavia, uno degli approcci pi\u00f9 semplici ed efficaci \u00e8 UniformSplit e l'uso della concatenazione dell'hash, ad esempio la coppia di byte pi\u00f9 significativa derivante dall'elaborazione della chiave tramite la funzione CRC32(rowkey) e la chiave stessa:<\/p>\n
    hash + rowkey<\/p>\n
    In questo modo, tutti i dati saranno distribuiti uniformemente su tutte le regioni. Durante la lettura, i primi due byte vengono semplicemente scartati e rimane la chiave originale. Inoltre, il RS controlla la quantit\u00e0 di dati e chiavi nella regione e, al superamento dei limiti, la suddivide automaticamente. <\/p>\n
    7. Tolleranza ai guasti e localit\u00e0 dei dati<\/h2>\n
    \nPoich\u00e9 ogni set di chiavi \u00e8 gestito solo da una regione, la soluzione ai problemi legati alle cadute di RS o all'uscita di esercizio \u00e8 conservare tutti i dati necessari in HDFS. Quando un RS cade, il master lo rileva tramite l'assenza del segnale di heartbeat sul nodo ZooKeeper. Allora assegna la regione a un altro RS e, poich\u00e9 gli HFiles sono conservati nel file system distribuito, il nuovo proprietario li legge e continua a gestire i dati. Tuttavia, poich\u00e9 parte dei dati potrebbe trovarsi in MemStore e non \u00e8 ancora stata trasferita in HFiles, per recuperare la storia delle operazioni si utilizza WAL, che \u00e8 anch'esso conservato in HDFS. Dopo aver applicato le modifiche, l'RS \u00e8 in grado di rispondere alle richieste, ma il trasferimento comporta che parte dei dati e i processi che li gestiscono si trovino su nodi diversi, riducendo cos\u00ec la locality. <\/p>\n
    La soluzione al problema \u00e8 la major compaction: questa procedura sposta i file sui nodi a cui sono assegnati (dove si trovano le loro regioni), il che provoca un aumento drastico del carico sulla rete e sui dischi durante questa procedura. Tuttavia, in seguito, l'accesso ai dati \u00e8 notevolmente accelerato. Inoltre, la major_compaction unisce tutti gli HFiles in un unico file all'interno della regione e pulisce i dati in base alle impostazioni della tabella. Ad esempio, \u00e8 possibile impostare il numero di versioni dell'oggetto da mantenere o il tempo di vita dopo il quale l'oggetto viene fisicamente eliminato.<\/p>\n
    Questa procedura pu\u00f2 avere un impatto molto positivo sul funzionamento di HBase. Nella figura sottostante si pu\u00f2 vedere come la performance sia degradata a causa di scritture attive di dati. Qui si nota come 40 thread stessero scrivendo in una tabella e 40 thread leggessero simultaneamente i dati. I thread di scrittura generano sempre pi\u00f9 HFiles, che vengono letti da altri thread. Di conseguenza, occorre eliminare sempre pi\u00f9 dati dalla memoria e alla fine inizia a funzionare il GC, che paralizza praticamente tutto il lavoro. L'avvio della major compaction ha portato alla pulizia dei cumuli formatisi e al ripristino della performance.<\/p>\n
    \"Teoria
    \nIl test \u00e8 stato eseguito su 3 DataNode e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). Versione di HBase 1.2.0-cdh5.14.2<\/p>\n
    \u00c8 importante notare che l'esecuzione della major compaction \u00e8 avvenuta su una tabella \"live\", in cui venivano scritti e letti dati attivamente. Si \u00e8 affermato in rete che questo potrebbe portare a risposte errate durante la lettura dei dati. Per verificare, \u00e8 stato avviato un processo che generava nuovi dati e li scriveva nella tabella. Dopodich\u00e9, venivano subito letti e confrontati per vedere se il valore ottenuto corrispondeva a quello registrato. Durante il funzionamento di questo processo, la major compaction \u00e8 stata eseguita circa 200 volte senza che si registrassero errori. \u00c8 possibile che il problema si manifesti raramente e solo durante un carico elevato, quindi \u00e8 pi\u00f9 sicuro interrompere pianificatamente i processi di scrittura e lettura e eseguire la pulizia evitando tali cali del GC.<\/p>\n
    Inoltre, la major compaction non influisce sullo stato di MemStore; per il suo svuotamento su disco e la compattazione \u00e8 necessario utilizzare flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Impostazioni e prestazioni<\/h2>\n
    \nCome gi\u00e0 detto, HBase ha il maggiore successo dove non deve fare nulla durante l'esecuzione di BulkLoad. In effetti, questo vale per la maggior parte dei sistemi e delle persone. Tuttavia, questo strumento \u00e8 pi\u00f9 adatto per la disposizione massiva di dati in grandi blocchi, mentre se il processo richiede l'esecuzione di molte richieste concorrenti di lettura e scrittura, si utilizzano i comandi Get e Put descritti sopra. Per determinare i parametri ottimali, sono stati effettuati avvii con diverse combinazioni di parametri delle tabelle e impostazioni:<\/p>\n