Quando si esegue uno strumento di benchmarking delle prestazioni sul cluster, una decisione fondamentale è sempre la dimensione del set di dati da utilizzare per un test delle prestazioni e qui dimostriamo perché è importante selezionare una dimensione del set di dati "adattabile" quando si esegue una performance HBase prova sul tuo cluster.
Le configurazioni del cluster HBase e le dimensioni del set di dati possono variare le prestazioni del carico di lavoro e i risultati dei test sullo stesso cluster. Dovresti scegliere questa dimensione del set di dati in base a ciò che stai cercando di capire sulle prestazioni del tuo cluster. Per mostrare la differenza tra un working set che si adatta alla cache di memoria disponibile e uno che deve essere letto dallo storage sottostante, abbiamo eseguito 2 test del carico di lavoro YCSB con dimensioni del set di dati opportunamente scelte sullo stesso cluster di database operativo CDP Private Cloud Base 7.2.2. Abbiamo utilizzato dimensioni del set di dati di 40 GB rispetto a 1 TB e il throughput per i diversi carichi di lavoro YCSB viene confrontato di seguito, nel grafico più alta è la barra, migliore è il throughput.
Nota:throughput =operazioni al secondo
Quando un'applicazione tenta di eseguire una lettura da un cluster HBase, il server della regione che gestisce la richiesta verifica prima se i risultati necessari si trovano in un blocco di dati che è già locale al suo processo tramite la sua cache dei blocchi. Se il blocco di dati è presente, la richiesta del client può essere gestita direttamente dalla cache e questo conta come un hit della cache. Tuttavia, se il blocco non è attualmente locale nel processo del server della regione, viene conteggiato come un errore di cache e deve essere letto dall'HFile nell'archiviazione HDFS. A seconda dell'utilizzo della cache, quel blocco verrà quindi salvato nella cache per richieste future.
Come previsto e visualizzato nel grafico di riepilogo, un carico di lavoro in cui la maggior parte dei set di dati si adatta alla cache ha latenze inferiori e il throughput è molto più elevato rispetto a un carico di lavoro eseguito in cui si accede ai dati da HFile nell'archiviazione hdfs.
Per scegliere le dimensioni del nostro set di dati del carico di lavoro per soddisfare bene i nostri obiettivi di test, è importante controllare le dimensioni degli heap di RegionServer, cache L1 e L2, cache del buffer del sistema operativo e quindi impostare una dimensione del set di dati appropriata. Dopo che l'esecuzione di un carico di lavoro YCSB ha completato, un buon parametro da verificare per verificare che le cose siano state eseguite come previsto è la quantità di dati servita dalla cache (un hit della cache) e la quantità di accesso dall'archiviazione hdfs. Questo rapporto tra gli accessi alla cache del server regionale e le richieste di lettura totali è il rapporto degli accessi alla cache.
Puoi trovare queste informazioni dalla configurazione "l1CacheHitRatio" del rapporto di hit della cache L1. Se hai entrambe le cache L1 e L2 impostate nel tuo cluster, la cache L1 serve i blocchi di indice e la cache L2 serve i blocchi di dati e puoi registrare entrambe le configurazioni L1 "l1CacheHitRatio" e L2 "l2CacheHitRatio" come riferimento.
Il resto di questo post del blog analizzerà i dettagli della nostra configurazione di test, scegliendo la dimensione del set di dati e quindi eseguendo YCSB con quelle dimensioni del set di dati.
Configurazione del cluster HBase utilizzata per questo test:
- Cluster utilizzato : Cluster a 6 nodi (1 master + 5 server regionali)
- Descrizione: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 a 2,2 Ghz, 128 GB di RAM, dischi da 4-2 TB
- Sicurezza: Nessuno configurato (nessun Kerberos)
- Versione CDP: CDP Private Cloud Base 7.2.2 Cluster HBase a 6 nodi con 1 server master + 5 regioni
- JDK ha utilizzato jdk1.8_232
- I server HBase Region sono stati configurati con 32 GB di heap
- HBase master è stato configurato con 4 GB di heap
- La cache L1 con LruBlockCache è stata utilizzata con una dimensione della cache di 12,3 GB
- La cache L1 totale nel cluster è 61 GB (12,3 * 5 =61 GB)
- L2 off heap cache non è stato configurato sul cluster
Caso di dimensionamento 1:i dati si adattano completamente alla cache disponibile sul cluster
Nel nostro cluster HBase, abbiamo configurato un totale di 61 GB (12,3 GB * 5) nei 5 server regionali allocati per la cache a blocchi L1. Per un set di dati che si adatta completamente alla cache, abbiamo scelto un set di dati da 40 GB in misura.
Caso di dimensionamento 2:set di dati più grande della cache disponibile sul cluster
Per il secondo scenario vogliamo che i dati siano molto più grandi della cache disponibile. Per scegliere una dimensione del set di dati appropriata, abbiamo esaminato sia la cache del blocco HBase configurata che la cache del buffer del sistema operativo nel cluster. Nel nostro cluster HBase, la cache a blocchi L1 configurata è 61G se aggregata tra i RegionServer. I nodi del server avevano un totale di 128 GB di RAM ciascuno e qualsiasi memoria non dedicata a un processo server può essere utilizzata dal sistema operativo per memorizzare efficacemente nella cache i blocchi HDFS sottostanti e aumentare il throughput complessivo. Nella nostra configurazione di prova sono disponibili circa 96 GB di cache del sistema operativo su ciascun nodo del server della regione per questo scopo (ignorando la memoria utilizzata dai processi DataNode o OS per semplificare le cose). Aggregando questo tra i server di 5 regioni, avevamo un potenziale di quasi 500 G per i buffer (server di 96 G * 5 regioni). Pertanto abbiamo scelto una dimensione del set di dati di 1 TB, superando sia la cache dei blocchi configurata che la cache del buffer del sistema operativo disponibile.
Trasformare le dimensioni dei dati target in parametri YCSB
In YCSB, una riga è 1 KB per impostazione predefinita, quindi a seconda di quante righe carichi nella "tabella utente" YCSB puoi facilmente stimare la dimensione dei dati della tabella "tabella utente" YCSB. Quindi, se carichi 1 milione di righe, hai caricato 1.000.000 * 1 KB =1 GB di dati nella "tabella utente" di YCSB.
Le dimensioni del set di dati utilizzate per i nostri due test erano:
- 40 GB di dati con 40 milioni di righe
- 1 TB di dati con 1 miliardo di righe
Metodologia di prova
CDP Private Cloud Base 7.2.2 è stato installato sul cluster a 6 nodi e sono stati generati dati di carico di lavoro con 40 milioni di righe (dimensione totale del set di dati => 40 GB ) e sono stati eseguiti carichi di lavoro YCSB. Dopo il caricamento, abbiamo atteso il completamento di tutte le operazioni di compattazione prima di avviare il test del carico di lavoro.
I carichi di lavoro YCSB eseguiti su HBase erano
- Carico di lavoro A:50% di lettura e 50% di aggiornamento
- Carico di lavoro C:100% letto
- Carico di lavoro F:50%Lettura e 50% Rapporto aggiornamento/lettura-modifica-scrittura:50/50
- Carico di lavoro solo aggiornamento personalizzato:aggiornamento 100%
Ciascun carico di lavoro YCSB (A, C, F e UpdateOnly) è stato eseguito per 15 minuti ciascuno e l'esecuzione completa è stata ripetuta 5 volte senza riavvii tra le corse per misurare il throughput YCSB*. I risultati mostrati sono medie prese per le ultime 3 esecuzioni dalle 5 esecuzioni. I primi 2 test run sono stati ignorati per evitare la prima e la seconda run di penalità.
Una volta completate le esecuzioni di 40 GB, abbiamo eliminato la tabella utente e rigenerato 1 miliardo di righe per creare una dimensione del set di dati di 1 TB e rieseguito i test con la stessa metodologia sullo stesso cluster.
Risultati del test
Risultati YCSB con 40 GB
Nel caso di 40 GB i dati possono essere inseriti completamente nella cache L1 da 61 GB del cluster. Il tasso di hit della cache L1 osservato nel cluster durante il test è stato vicino al 99%.
Suggerimento: Per set di dati più piccoli in cui i dati possono essere inseriti nella cache, possiamo anche utilizzare l'opzione cache al caricamento e preriscaldare la cache per ottenere il 100% di hit ratio della cache utilizzando l'opzione tabella PREFETCH_BLOCKS_ON_OPEN
Abbiamo eseguito ogni carico di lavoro YCSB per 15 minuti ogni 5 volte e abbiamo preso le medie degli ultimi 3 run per evitare la penalità del primo run.
Risultati visti con percentuale hit cache 40G L1 99% sui server della regione sono mostrati di seguito nella tabella:
| Operazione | Numero operazioni | Produttività | Latenza media | 95 latenza | 99 latenza |
| (Num operazioni/sec) | (ms) | (ms) | (ms) | ||
| Carico di lavoro C | 148558364 | 165063 | 0,24 | 0,30 | 0,48 |
| Solo aggiornamento | 56727908 | 63030 | 0,63 | 0,78 | 1.57 |
| Carico di lavoro A | 35745710 | 79439 | 0,40 | 0,54 | 0,66 |
| Carico di lavoro F | 24823285 | 55157 | 0,58 | 0,70 | 0,96 |
Risultati YCSB con set di dati da 1 TB
Nel caso da 1 TB, i dati non rientrano nella cache L1 da 61 GB sul cluster o nella cache del buffer del sistema operativo da 500 GB. Il tasso di hit della cache L1 nel cluster osservato durante il test è stato dell'82-84%.
Abbiamo eseguito ogni carico di lavoro per 15 minuti ciascuno 5 volte e abbiamo preso le medie degli ultimi 3 run per evitare la penalità del primo run.
Risultati visti con 1 TB Percentuale hit cache L1 82-84% sui server della regione sono mostrati di seguito nella tabella:
| Operazione | Numero operazioni | Produttività | Latenza media | 95 latenza | 99 latenza |
| (Num operazioni/sec) | (ms) | (ms) | (ms) | ||
| Carico di lavoro C | 2727037 | 3030 | 13:19 | 55.50 | 110,85 |
| Solo aggiornamento | 56345498 | 62605 | 0,64 | 0,78 | 1.58 |
| Carico di lavoro A | 3085135 | 6855 | 10.88 | 48.34 | 97.70 |
| Carico di lavoro F | 3333982 | 3704 | 10:45 | 47.78 | 98.62 |
*Throughput (operazioni/sec) =N. di operazioni al secondo
Analisi:
Confrontando i risultati dei test per le due diverse dimensioni del set di dati sopra, possiamo vedere come lo stesso throughput del carico di lavoro può variare da 3.000 operazioni al secondo a 165.000 operazioni al secondo quando si accede più rapidamente ai dati dal set di dati 40G con cache riscaldata rispetto allo storage hdfs.
Il grafico seguente mostra la velocità effettiva e confronta il modo in cui la velocità effettiva è cambiata per carichi di lavoro diversi quando vengono eseguiti con i 2 set di dati di dimensioni diverse. Nel grafico più alta è la barra, migliore è il throughput.
Nota:throughput =operazioni al secondo
Come si vede nel grafico, i carichi di lavoro YCSB che leggono dati come Carico di lavoro A, Carico di lavoro C e Carico di lavoro F hanno avuto un throughput molto migliore nel caso 40G in cui i dati si inseriscono facilmente nella cache rispetto al caso della dimensione dei dati da 1 TB in cui i dati HFile dovevano essere accessibile da HDFS
Osservando i rapporti di accesso alla cache, il set di dati 40G aveva un rapporto di accesso alla cache vicino al 99% e il set di dati da 1 TB aveva un rapporto di accesso alla cache di circa l'85%, quindi il 15% dei dati nel caso da 1 TB era accessibile dall'archiviazione hdfs .
Il carico di lavoro di solo aggiornamento personalizzato YCSB che abbiamo eseguito ha avuto la stessa velocità effettiva in entrambi i casi poiché ha eseguito solo aggiornamenti e nessuna lettura.
Durante le prestazioni di HBase esaminiamo da vicino le latenze del 95° e 99° percentile. La latenza media è solo il throughput totale diviso per il tempo totale, tuttavia il 95° percentile e il 99° percentile mostrano i valori anomali reali che influiscono sul throughput totale del carico di lavoro. Nel caso di 1 TB, i valori anomali di latenza elevata nel 95° e 99° percentile causano un rallentamento del throughput e nel caso di 40 GB i colpi di cache a bassa latenza nel 99° percentile portano a un aumento del throughput totale.
Il grafico seguente mostra il confronto della latenza per la latenza media, la latenza del 95° percentile e la latenza del 99° percentile e le differenze per carichi di lavoro diversi quando vengono eseguiti con set di dati di dimensioni diverse.
Nel grafico sopra, è difficile vedere le barre che rappresentano la latenza per il set di dati da 40 GB poiché sono estremamente basse rispetto alla latenza osservata per il set di dati da 1 TB che accede ai dati da hdfs.
Abbiamo tracciato il grafico della latenza utilizzando il registro dei valori di latenza per mostrare la differenza nel grafico sottostante
Come visto sopra, le latenze sono molto più basse nel caso di 40 GB in cui la percentuale di hit della cache è vicina al 99% e la maggior parte dei dati del carico di lavoro è disponibile nella cache. In confronto al set di dati da 1 TB, il tasso di riscontro della cache era di circa l'85% poiché era necessario accedere ai dati HFile dallo storage HDFS.
La latenza media e 99 per il carico di lavoro C nel caso 40G in cui il 99% dei dati viene restituito dalla cache riscaldata era di circa 2-4 ms. La latenza del 99° percentile per lo stesso carico di lavoro C nel caso da 1 TB era di circa 100 ms per il carico di lavoro C (carico di lavoro di sola lettura).
Ciò mostra che un hit della cache dalla cache a blocchi dell'heap restituisce una lettura in circa 2 ms e un errore di cache e l'acquisizione di un record da HDFS potrebbe richiedere circa 100 ms su questo cluster.
Raccomandamento:
Quando si esegue un test di benchmarking YCSB, la dimensione del set di dati fa una differenza sostanziale nei risultati delle prestazioni, quindi è molto importante dimensionare il test in modo appropriato. Allo stesso tempo, esaminare il rapporto di hit della cache e le differenze di latenza tra la latenza minima e la 99a ti aiuterà a trovare la latenza di un hit della cache rispetto a quando si accede ai dati dallo storage sottostante nel cluster.
Suggerimento:
Per controllare i rapporti di hit della cache del tuo carico di lavoro su un server regionale puoi utilizzare il comando seguente
curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio
Puoi anche visualizzare il rapporto cache hit dall'interfaccia utente Web HBase seguendo i passaggi seguenti:
- Dall'interfaccia utente Web di HBase, fai clic sul server della regione
- Nella sezione Blocca cache, seleziona L1 (e L2 se L2 è configurato) per rivedere i rapporti di hit della cache.
Di seguito è mostrato uno screenshot che mostra il rapporto di hit della cache dalla cache dei blocchi L1:
Ecco un collegamento a ulteriori informazioni sullo screenshot di HBase mostrato sopra e sulla cache dei blocchi https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
Informazioni su YCSB
YCSB è una specifica open source e una suite di programmi per valutare le capacità di recupero e manutenzione dei programmi per computer. È uno strumento molto popolare utilizzato per confrontare le prestazioni relative dei sistemi di gestione di database NoSQL.
Per utilizzare YCSB per testare le prestazioni del database operativo, dai un'occhiata al blog How to Run YCSB for HBase
