{"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 di Sbertech ha iniziato a utilizzare HBase come archivio di dati operativi. Durante lo studio di questo strumento, abbiamo accumulato esperienze che desideravamo sistematizzare e descrivere (speriamo che possano essere utili 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 di dati in HBASE<\/li>\n
  3. Lettura di dati da HBASE<\/li>\n
  4. Caching dei dati<\/li>\n
  5. Elaborazione batch dei dati MultiGet\/MultiPut<\/li>\n
  6. Strategia di divisione delle tabelle in regioni (splitting)<\/li>\n
  7. Tolleranza ai guasti, compattazione e localit\u00e0 dei dati<\/li>\n
  8. Impostazioni e prestazioni<\/li>\n
  9. Carico di test<\/li>\n
  10. Conclusioni<\/li>\n<\/ol>\n

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

    1. Architettura generale<\/h2>\n

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

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

    \nIniziamo considerando il caso pi\u00f9 semplice: la registrazione di un oggetto chiave-valore in una tabella tramite put(rowkey). Il client deve prima determinare dove si trova il server regionale principale (Root Region Server - RRS) che ospita la tabella hbase:meta. Questa informazione viene ottenuta da ZooKeeper. Successivamente, il client si rivolge al RRS e legge la tabella hbase:meta, dalla quale estrae informazioni su quale RegionServer (RS) \u00e8 responsabile della memorizzazione dei dati per la chiave rowkey specificata nella tabella di interesse. A fini di utilizzo futuro, la tabella meta viene memorizzata nella cache dal client e pertanto le successive chiamate avvengono pi\u00f9 rapidamente, direttamente al RS.<\/p>\n

    Successivamente, RS, ricevuta la richiesta, scrive per prima cosa nel WriteAheadLog (WAL), necessario per il ripristino in caso di guasti. Poi salva i dati nel MemStore. Questo \u00e8 un buffer in memoria che contiene un insieme ordinato di chiavi per questa regione. La tabella pu\u00f2 essere suddivisa in regioni (partizioni), ciascuna delle quali contiene un insieme di chiavi non sovrapposto. Ci\u00f2 consente, distribuendo le regioni su server diversi, di ottenere prestazioni superiori. Tuttavia, nonostante l'evidenza di questa affermazione, vedremo in seguito che non funziona in tutti i casi.<\/p>\n

    Dopo aver posizionato la registrazione nel MemStore, viene restituita al cliente una risposta che indica che la registrazione \u00e8 stata salvata con successo. In realt\u00e0, per\u00f2, \u00e8 conservata solo nel buffer e sar\u00e0 trasferita su disco solo dopo un certo intervallo di tempo o quando verr\u00e0 riempita con nuovi dati. <\/p>\n

    \"Teoria
    \nDurante l'operazione 'Delete' non avviene l'eliminazione fisica dei dati. Vengono semplicemente contrassegnati come eliminati, e la loro rimozione avviene al momento della chiamata alla funzione major compact, di cui si parla pi\u00f9 dettagliatamente al punto 7.<\/p>\n

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

    Oltre al processo di caricamento descritto sopra, esiste una procedura molto pi\u00f9 efficiente, che costituisce forse il punto di forza principale di questo database: BulkLoad. Essa consiste nel creare autonomamente HFiles e scriverli su disco, il che consente di scalare in modo eccellente e di raggiungere velocit\u00e0 notevoli. In sostanza, il limite non \u00e8 HBase, ma le capacit\u00e0 dell'hardware. Di seguito sono riportati i risultati del 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. Inoltre, la velocit\u00e0 dipende dal volume di scrittura. Blocchi grandi offrono un aumento in megabyte al secondo, mentre quelli piccoli aumentano il numero di record inseriti per unit\u00e0 di tempo, a parit\u00e0 di condizioni. <\/p>\n

    \u00c8 possibile avviare il caricamento in due tabelle contemporaneamente, raddoppiando cos\u00ec la velocit\u00e0. Di seguito si pu\u00f2 vedere che la scrittura di blocchi da 10 KB in due tabelle avviene a una velocit\u00e0 di circa 600 MB\/sec per ciascuna (complessivamente 1275 MB\/sec), che corrisponde alla velocit\u00e0 di scrittura in una sola tabella di 623 MB\/sec (vedi n. 11 sopra).<\/p>\n

    \"Teoria
    \nIl secondo avvio con registrazioni da 50 KB mostra che la velocit\u00e0 di caricamento aumenta solo lievemente, il che indica che ci si sta avvicinando ai valori massimi. Occorre inoltre tenere presente che non si crea praticamente alcun carico su HBASE; tutto ci\u00f2 che \u00e8 richiesto \u00e8 prima restituire i dati da hbase:meta e, dopo l'inserimento degli HFiles, svuotare i dati BlockCache e salvare il buffer MemStore su disco, se non \u00e8 vuoto.<\/p>\n

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

    \nSe si considera che il cliente ha gi\u00e0 tutte le informazioni da hbase:meta (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, viene effettuata una ricerca anche nel buffer BlockCache e, se necessario, negli HFiles. Se vengono trovati dati nel file, vengono inseriti in BlockCache e la prossima volta saranno restituiti pi\u00f9 rapidamente. La ricerca in HFile avviene piuttosto rapidamente grazie all'uso del filtro di Bloom, che determinando un piccolo volume di dati stabilisce subito se quel file contiene la chiave necessaria e, in caso contrario, passa al successivo.<\/p>\n

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

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

    \nI buffer MemStore e BlockCache occupano fino all'80% della memoria on-heap allocata per RS (il resto \u00e8 riservato per compiti di servizio di RS). Se il modo tipico di utilizzo prevede che i processi scrivano e leggano immediatamente i medesimi dati, ha senso ridurre BlockCache e aumentare MemStore, poich\u00e9 durante la scrittura i dati non vengono memorizzati nella cache per la lettura, quindi l'utilizzo 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 si riescono a memorizzare in LruBlockCache, causando un'attiva operazione del Garbage Collector. Tuttavia, non ci si pu\u00f2 aspettare un aumento radicale delle prestazioni dall'uso della cache per la lettura, ma ne parleremo di nuovo al punto 8.<\/p>\n

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

    Come \u00e8 descritto<\/a><\/noindex> In teoria, quando i dati vengono registrati, non vengono messi nella cache e, in effetti, i parametri CACHE_DATA_ON_WRITE per la tabella e \"Cache DATA on Write\" per RS sono impostati su false. Tuttavia, nella pratica, se si scrivono dati nel MemStore, poi lo si svuota su disco (cos\u00ec facendo), successivamente si elimina il file risultante, eseguendo quindi una richiesta get, riusciremo a ottenere i dati con successo. E anche se si disattiva completamente il BlockCache e si riempie la tabella con nuovi dati, poi si effettua il flush del MemStore su disco, li si elimina e si richiede da un'altra sessione, comunque verranno recuperati da qualche parte. Quindi HBase conserva non solo i dati, ma anche misteri enigmatici.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nCreated table ns:magic\nTook 1.1533 seconds\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nTook 0.2610 seconds\nhbase(main):003:0> flush 'ns:magic'\nTook 0.6161 seconds\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, value=try_to_delete_me\n<\/code><\/pre>\n
    \nIl parametro \"Cache DATA on Read\" \u00e8 impostato su false. Se avete idee, benvenuti a discuterne nei commenti.<\/p>\n
    5. Elaborazione batch dei dati MultiGet\/MultiPut<\/h2>\n
    \nL'elaborazione di richieste singole (Get\/Put\/Delete) \u00e8 un'operazione piuttosto costosa, quindi \u00e8 consigliabile raggrupparle in List o List quando possibile, il che pu\u00f2 portare a un significativo miglioramento delle prestazioni. Questo vale in particolare per le operazioni di scrittura, mentre nella lettura c'\u00e8 un altro aspetto critico. Nel grafico sottostante \u00e8 mostrato il tempo di lettura di 50.000 registrazioni da MemStore. La lettura \u00e8 stata effettuata in un singolo thread e sull'asse orizzontale \u00e8 rappresentato il numero di chiavi nella richiesta. Si pu\u00f2 osservare che aumentando a mille chiavi in un'unica richiesta, il tempo di esecuzione diminuisce, ovvero la velocit\u00e0 aumenta. Tuttavia, con la modalit\u00e0 MSLAB attivata di default, dopo questa soglia inizia un drastico calo delle prestazioni, e pi\u00f9 \u00e8 ampio il volume dei dati nella registrazione, pi\u00f9 lungo \u00e8 il tempo di esecuzione. <\/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 attivato, i dati vengono immessi in celle (chunk) relativamente piccole e vengono elaborati a blocchi. Di conseguenza, quando il volume nel pacchetto di dati richiesto supera la dimensione allocata, le prestazioni subiscono un netto calo. D'altra parte, disattivare questa modalit\u00e0 non \u00e8 desiderabile, poich\u00e9 comporterebbe interruzioni a causa del GC nei momenti di intensa operazione con i dati. Un buon approccio potrebbe essere aumentare il volume della cella, nel caso di scrittura attiva tramite put contemporaneamente alla lettura. \u00c8 importante notare che il problema non si presenta se, dopo la scrittura, si esegue il comando flush che scarica MemStore su disco o se si utilizza il caricamento tramite BulkLoad. Nella tabella sottostante \u00e8 mostrato che le richieste da MemStore di dati di maggior volume (e quantit\u00e0 uguale) portano a un rallentamento. Tuttavia, aumentando il chunksize, si riporta il tempo di elaborazione alla normalit\u00e0.<\/p>\n
    \"Teoria
    \nOltre ad aumentare il chunksize, \u00e8 utile suddividere i dati per regioni, ossia fare lo splitting delle tabelle. Questo porta a un numero inferiore di richieste per ciascuna regione e, se vengono inserite in una cella, la risposta rimane buona.<\/p>\n
    6. Strategia di suddivisione delle tabelle in regioni (splitting)<\/h2>\n
    \nPoich\u00e9 HBase \u00e8 un archivio key-value e la partizione \u00e8 effettuata in base alla chiave, \u00e8 estremamente importante suddividere i dati uniformemente tra tutte le regioni. Ad esempio, partizionare questa tabella in tre parti porter\u00e0 a dati distribuiti su tre regioni:<\/p>\n
    \"Teoria
    \nA volte ci\u00f2 porta a un rallentamento drastico, se i dati caricati in seguito hanno valori long che iniziano per lo pi\u00f9 con la stessa cifra, per esempio:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Poich\u00e9 le chiavi sono memorizzate come array di byte, tutte inizieranno in modo identico e apparterranno a una regione #1 che memorizza questo intervallo di chiavi. Ci sono varie strategie di suddivisione:<\/p>\n
    HexStringSplit \u2013 Converte la chiave in una stringa con codifica esadecimale nell'intervallo \u00ab00000000\u00bb => \u00abFFFFFFFF\u00bb, riempiendo a sinistra con zeri.<\/p>\n
    UniformSplit \u2013 Trasforma una chiave in un array di byte con codifica esadecimale nell'intervallo \"00\" => \"FF\", riempiendo gli spazi a destra con zeri.<\/p>\n
    Inoltre, \u00e8 possibile specificare qualsiasi intervallo o insieme di chiavi per la suddivisione e configurare l'auto-split. 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 tra le regioni. Durante la lettura, i primi due byte vengono semplicemente scartati e rimane la chiave originale. Inoltre, RS controlla la quantit\u00e0 di dati e chiavi nella regione e, al superamento dei limiti, la suddivide automaticamente in parti. <\/p>\n
    7. Resilienza e localit\u00e0 dei dati<\/h2>\n
    \nPoich\u00e9 ogni insieme di chiavi \u00e8 gestito da una sola regione, la soluzione ai problemi legati ai guasti di RS o all'interruzione del servizio \u00e8 quella di memorizzare tutti i dati necessari in HDFS. In caso di guasto di un RS, il master lo rileva attraverso l'assenza di heartbeat nel nodo ZooKeeper. Allora assegna la regione a un altro RS e, poich\u00e9 gli HFiles sono archiviati nel file system distribuito, il nuovo proprietario li legge e continua a servire i dati. Tuttavia, poich\u00e9 parte dei dati potrebbe trovarsi in MemStore e non essere ancora stata trasferita in HFiles, per ripristinare la cronologia delle operazioni viene utilizzato il WAL, anch'esso archiviato in HDFS. Dopo aver applicato le modifiche, il RS \u00e8 in grado di rispondere alle richieste, ma il trasloco comporta il rischio che parte dei dati e i processi ad essi associati 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 che li gestiscono (dove sono ubicati i loro regioni), con un conseguente aumento significativo del carico sulla rete e sui dischi durante questa operazione. Tuttavia, in seguito, l'accesso ai dati risulta notevolmente pi\u00f9 veloce. Inoltre, la major_compaction unisce tutti gli HFile in un unico file all'interno della regione e pulisce i dati in base alle impostazioni della tabella. Ad esempio, \u00e8 possibile specificare il numero di versioni di un oggetto da mantenere o il tempo di vita dopo il quale l'oggetto viene eliminato fisicamente.<\/p>\n
    Questa procedura pu\u00f2 avere un impatto molto positivo sul funzionamento di HBase. Nella figura sottostante si pu\u00f2 vedere come le prestazioni siano deteriorate a causa della scrittura attiva di dati. Qui si pu\u00f2 osservare come 40 flussi scrivano in una tabella mentre 40 flussi leggono dati simultaneamente. I flussi di scrittura generano un numero crescente di HFiles, che vengono letti dagli altri flussi. Di conseguenza, sempre pi\u00f9 dati devono essere rimossi dalla memoria e alla fine inizia a funzionare il GC, che praticamente paralizza tutto il sistema. L'avvio di una major compaction ha portato alla pulizia delle congestioni accumulate e al ripristino delle prestazioni.<\/p>\n
    \"Teoria
    \nIl test \u00e8 stato eseguito su 3 DataNode e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). Versione HBase 1.2.0-cdh5.14.2<\/p>\n
    \u00c8 importante sottolineare che il processo di major compaction \u00e8 stato eseguito su una tabella \"vivente\", in cui venivano attivamente scritti e letti dati. In rete si \u00e8 sostenuto che ci\u00f2 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. Successivamente, i dati venivano immediatamente letti e confrontati per vedere se il valore ottenuto corrispondesse a quello registrato. Durante l'esecuzione di questo processo, il major compaction \u00e8 stato avviato circa 200 volte senza registrare alcun errore. \u00c8 possibile che il problema si manifesti raramente e solo durante carichi elevati, quindi \u00e8 pi\u00f9 sicuro comunque fermare in modo programmato i processi di scrittura e lettura e eseguire la pulizia senza consentire tali cali di GC.<\/p>\n
    Inoltre, il major compaction non influisce sullo stato del MemStore; per svuotarlo su disco e compattarlo, \u00e8 necessario utilizzare il flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Impostazioni e prestazioni<\/h2>\n
    \nCome gi\u00e0 detto, HBase ha un successo maggiore quando non deve eseguire operazioni, durante il BulkLoad. Tuttavia, questo vale per la maggior parte dei sistemi e delle persone. Questo strumento \u00e8 pi\u00f9 adatto per l'inserimento massivo di dati in blocchi, mentre, se il processo richiede l'esecuzione di molte richieste concorrenti di lettura e scrittura, vengono utilizzati i comandi Get e Put descritti precedentemente. Per determinare i parametri ottimali, sono stati eseguiti test con diverse combinazioni di parametri delle tabelle e impostazioni.<\/p>\n