HBase Performance-testen met YCSB

Wanneer u een prestatiebenchmark-tool op uw cluster uitvoert, is het altijd een cruciale beslissing welke gegevenssetgrootte moet worden gebruikt voor een prestatietest, en hier laten we zien waarom het belangrijk is om een ​​"goed passende" gegevenssetgrootte te selecteren bij het uitvoeren van een HBase-prestatie test op uw cluster.

De HBase-clusterconfiguraties en de grootte van de gegevensset kunnen de prestaties van uw werkbelasting en de testresultaten op hetzelfde cluster variëren. U moet deze gegevenssetgrootte kiezen op basis van wat u probeert te begrijpen over de prestaties van uw cluster. Om het verschil te laten zien tussen een werkset die in de beschikbare geheugencache past en een werkset die moet worden gelezen uit de onderliggende opslag, hebben we 2 YCSB-workloadtests uitgevoerd met de juiste datasetgroottes op hetzelfde CDP Private Cloud Base 7.2.2 Operation Database-cluster. We gebruikten datasets van 40 GB versus 1 TB en de doorvoer voor de verschillende YCSB-workloads wordt hieronder vergeleken, in de grafiek staat hoe hoger de balk, hoe beter de doorvoer.

Opmerking:doorvoer =bewerkingen per seconde

Wanneer een toepassing probeert een leesbewerking uit te voeren van een HBase-cluster, controleert de Region Server die het verzoek afhandelt eerst of de benodigde resultaten zich in een gegevensblok bevinden dat al lokaal is voor het proces via de blokcache. Als het datablok aanwezig is, kan het clientverzoek rechtstreeks vanuit de cache worden afgehandeld en dit telt als een cachehit. Als het blok momenteel echter niet lokaal is voor het Region Server-proces, wordt dat geteld als een cache-misser en moet het worden gelezen van de HFile in HDFS-opslag. Afhankelijk van het cachegebruik wordt dat blok vervolgens in de cache opgeslagen voor toekomstige verzoeken.

Zoals verwacht en te zien in het overzichtsdiagram, heeft een werkbelasting waarbij de meeste gegevensset in de cache past, lagere latenties en is de doorvoer veel hoger dan een werkbelasting waarbij gegevens worden geopend vanuit HFiles in hdfs-opslag.

Om de grootte van onze workloaddatasets zo te kiezen dat ze goed voldoen aan onze testdoelen, is het belangrijk om de grootte van RegionServer-heaps, L1- en L2-caches, OS-buffercaches te controleren en vervolgens een geschikte datasetgrootte in te stellen. Nadat een YCSB-workload-run een goede parameter heeft voltooid om te controleren of de dingen liepen zoals verwacht, is hoeveel van de gegevens uit de cache zijn gehaald (een cache-hit) en hoeveel er is benaderd vanuit hdfs-opslag. Deze verhouding van Region Server-cachehits tot het totale aantal leesverzoeken is de cachehitratio.

Je kunt deze informatie vinden in de L1 cache hit ratio "l1CacheHitRatio" config. Als u zowel L1- als L2-caches in uw cluster hebt ingesteld, bedient de L1-cache de indexblokken en de L2-cache de gegevensblokken, en kunt u zowel L1 "l1CacheHitRatio" als L2 "l2CacheHitRatio" -configuraties opnemen ter referentie.

De rest van deze blogpost zal de details van onze testopstelling doornemen, de datasetgrootte kiezen en vervolgens YCSB uitvoeren met die datasetgroottes.

HBase-clusterconfiguratie gebruikt voor deze test:

• Gebruikt cluster: 6 node cluster (1 master + 5 regioservers)
• Beschrijving: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2,2 Ghz, 128 GB RAM, 4-2 TB schijven
• Beveiliging: Niet geconfigureerd (geen Kerberos)
• CDP-versie: CDP Private Cloud Base 7.2.2 HBase-cluster met 6 knooppunten met 1 master + 5 regioservers
• JDK gebruikte jdk1.8_232
• HBase Region-servers zijn geconfigureerd met 32 ​​GB heap 
• HBase-master is geconfigureerd met een heap van 4 GB
• L1-cache met LruBlockCache werd gebruikt met een cachegrootte van 12,3 GB
• Totale L1-cache in cluster is 61 GB (12,3 * 5 =61 GB)
• L2 off heap cache is niet geconfigureerd op het cluster

Sizing Case 1:Gegevens passen volledig in de beschikbare cache op het cluster

In ons HBase-cluster hebben we in totaal 61 GB (12,3 GB * 5) geconfigureerd voor de 5 regioservers die zijn toegewezen voor L1-blokcache. Voor een dataset die volledig in de cache past, kozen we voor een dataset van 40 GB qua grootte.

Sizing Case 2:Dataset groter dan de beschikbare cache op het cluster

Voor het tweede scenario willen we dat de gegevens veel groter zijn dan de beschikbare cache. Om een ​​geschikte datasetgrootte te kiezen, hebben we gekeken naar zowel de geconfigureerde HBase-blokcache als de OS-buffercache in het cluster. In ons gegeven HBase-cluster is de geconfigureerde L1-blokcache 61G wanneer deze wordt geaggregeerd over de RegionServers. De serverknooppunten hadden elk in totaal 128G RAM en elk geheugen dat niet aan een serverproces is toegewezen, kan door het besturingssysteem worden gebruikt om de onderliggende HDFS-blokken effectief te cachen en de algehele doorvoer te verhogen. In onze testconfiguratie is voor dit doel ongeveer 96G OS-cache beschikbaar op elk regioserverknooppunt (waarbij het geheugen dat wordt gebruikt door de DataNode- of OS-processen wordt genegeerd om dingen te vereenvoudigen). Als we dit samenvoegden over de 5 regioservers, hadden we een potentieel van bijna 500G voor buffers (96G * 5 regioservers). Daarom kozen we voor een datasetgrootte van 1 TB, wat zowel de geconfigureerde blokcache als de beschikbare OS-buffercache overschrijdt.

Doelgegevensgroottes omzetten in YCSB-parameters

In YCSB is een rij standaard 1 KB, dus afhankelijk van het aantal rijen dat u in de YCSB 'usertable' laadt, kunt u eenvoudig de gegevensgrootte van uw YCSB 'usertable'-tabel schatten. Dus als u 1 miljoen rijen uploadt, heeft u 1.000.000 * 1 KB =1 GB aan gegevens geüpload naar de YCSB 'gebruikerstabel'.

De grootte van de datasets die voor onze twee tests werden gebruikt, waren:

• 40 GB gegevens met 40 miljoen rijen
• 1 TB gegevens met 1 miljard rijen 

Testmethodologie

CDP Private Cloud Base 7.2.2 werd geïnstalleerd op het cluster met 6 knooppunten en er werden workloadgegevens met 40 miljoen rijen (totale grootte van de gegevensset => 40 GB) gegenereerd en YCSB-workloads werden uitgevoerd. Na het laden wachtten we tot alle verdichtingsbewerkingen waren voltooid voordat we met de werkbelastingstest begonnen.

YCSB-werkbelastingen die op HBase werden uitgevoerd, waren

1. Werklast A:50% lezen en 50% bijwerken
2. Werklast C:100% gelezen 
3. Werklast F:50% lees- en 50% update/lees-wijzig-schrijfverhouding:50/50
4. Werklast alleen aangepaste update:100% update
   

Elke YCSB-workload (A,C,F en UpdateOnly) werd elk gedurende 15 minuten uitgevoerd en de volledige run werd 5 keer herhaald zonder herstart tussen runs om de YCSB-doorvoer* te meten. De getoonde resultaten zijn gemiddelden van de laatste 3 runs van de 5 runs. De eerste 2 testruns werden genegeerd om de eerste en tweede run penalty te vermijden.

Nadat de runs van 40 GB waren voltooid, hebben we de gebruikerstabel verwijderd en 1 miljard rijen opnieuw gegenereerd om een ​​dataset van 1 TB te creëren en de tests opnieuw uitgevoerd met dezelfde methodologie op hetzelfde cluster.

Testresultaten

YCSB-resultaten met 40 GB

In het geval van 40 GB passen de gegevens volledig in de 61 GB L1-cache op het cluster. De L1-cachehitratio die tijdens de test in het cluster werd waargenomen, was bijna 99%.

Tip: Voor kleinere datasets waar gegevens in de cache passen, kunnen we ook de optie cache on load gebruiken en de cache voorverwarmen om 100% cache hit ratio te krijgen met behulp van tabeloptie PREFETCH_BLOCKS_ON_OPEN

We hebben elke YCSB-workload elke 5 keer 15 minuten uitgevoerd en hebben gemiddelden genomen van de laatste 3 runs om de eerste run penalty te vermijden.

Resultaten gezien met 40G L1 cache hit ratio 99% op de regioservers worden hieronder in de tabel weergegeven: 

YCSB-resultaten met dataset van 1 TB

In het geval van 1 TB passen de gegevens niet in de 61 GB L1-cache op het cluster of de 500 GB OS-buffercache. De tijdens de test waargenomen L1-cachehitratio in het cluster was 82-84%.

We voerden elke workload elke 5 keer 15 minuten uit en namen de gemiddelden van de laatste 3 runs om de penalty voor de eerste run te vermijden.

Resultaten gezien met 1TB L1 cache hit ratio 82-84% op de regioservers worden hieronder in de tabel weergegeven: 

*Doorvoer (ops/sec) =aantal bewerkingen per seconde

Analyse:

Als we de testresultaten voor de twee verschillende datasets hierboven vergelijken, kunnen we zien hoe dezelfde werkbelasting kan variëren van 3K bewerkingen per seconde tot 165K bewerkingen per seconde wanneer gegevens sneller worden benaderd vanuit de 40G-dataset met opgewarmde cache versus vanuit hdfs-opslag.

De onderstaande grafiek toont de doorvoer en vergelijkt hoe de doorvoer is gewijzigd voor verschillende workloads wanneer deze wordt uitgevoerd met de 2 gegevenssets van verschillende grootte. Hoe hoger de balk in de grafiek, hoe beter de doorvoer.

Opmerking:doorvoer =bewerkingen per seconde

Zoals te zien is in de grafiek, hadden de YCSB-workloads die gegevens lezen zoals Workload A, Workload C en Workload F een veel betere doorvoer in het 40G-geval waar de gegevens gemakkelijk in de cache passen, versus het geval van 1TB-gegevensomvang waar de HFile-gegevens moesten zijn toegankelijk via HDFS

Kijkend naar de cache-hit-ratio's, had de 40G-dataset een cache-hit-ratio van bijna 99%, en de 1TB-dataset had een cache-hit-ratio van ongeveer 85%, dus 15% van de gegevens in 1TB-case was toegankelijk via hdfs-opslag .

De aangepaste YCSB-workload met alleen updates die we uitvoerden, had in beide gevallen dezelfde verwerkingscapaciteit, omdat er alleen updates werden uitgevoerd en geen leesbewerkingen.

Tijdens HBase-prestaties kijken we goed naar de latenties van het 95e en 99e percentiel. De gemiddelde latentie is slechts de totale doorvoer gedeeld door de totale tijd, maar het 95e percentiel en het 99e percentiel tonen de echte uitschieters die van invloed zijn op de totale doorvoer van de werklast. In het geval van 1 TB zorgen de uitschieters met hoge latentie in het 95e en 99e percentiel ervoor dat de doorvoer vertraagt, en in het geval van 40 GB leiden de cache-hits met lage latentie in het 99e percentiel tot een verhoogde totale doorvoer.

Onderstaande grafiek toont de latentievergelijking voor gemiddelde latentie, 95e percentiel latentie en 99e percentiel latentie en hoe deze verschilt voor verschillende workloads wanneer ze worden uitgevoerd met datasets van verschillende grootte.

In de bovenstaande grafiek is het moeilijk om de balken te zien die de latentie vertegenwoordigen voor de 40 GB-dataset, omdat ze extreem laag zijn in vergelijking met de latentie die wordt waargenomen voor de 1TB-dataset die toegang heeft tot gegevens van hdfs.

We hebben de latentiegrafiek geplot met behulp van log van de latentiewaarden om het verschil in de onderstaande grafiek weer te geven

Zoals hierboven te zien is, zijn de latenties veel lager in het geval van 40 GB, waar de cachehit-ratio bijna 99% is en de meeste werkbelastinggegevens beschikbaar zijn in de cache. In vergelijking met de dataset van 1 TB was de cachehit-ratio ongeveer 85% omdat HFile-gegevens moesten worden geopend vanuit HDFS-opslag.

De gemiddelde latentie van 99 voor Workload C in het geval van 40G, waarbij 99% gegevens worden geretourneerd uit de opgewarmde cache, was ongeveer 2 - 4 ms. De latentie van het 99e percentiel voor dezelfde Workload C in het geval van 1 TB was ongeveer 100 ms voor Workload C (alleen-lezen werkbelasting).

Dit laat zien dat een cache-hit van de blokcache op de heap een read in ongeveer 2 ms retourneert en een cache-misser en het verkrijgen van een record van HDFS kan ongeveer 100 ms duren op dit cluster.

Aanbeveling: 

Bij het uitvoeren van een YCSB-benchmarkingtest maakt de grootte van de dataset een aanzienlijk verschil in de prestatieresultaten, en daarom is het erg belangrijk om de test op de juiste manier te dimensioneren. Tegelijkertijd kunt u kijken naar de cachehit-ratio en latentieverschillen tussen de minimale en de 99e latentie, zodat u de latentie van een cachehit kunt vinden in vergelijking met wanneer gegevens worden benaderd vanuit de onderliggende opslag in het cluster.

Tip:

Voor het controleren van de cache-hitverhoudingen van uw werkbelasting op een regioserver kunt u het onderstaande commando gebruiken

curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio

U kunt de Cache Hit-ratio ook bekijken vanuit de HBase Web UI door de onderstaande stappen te volgen:

1. Klik in de HBase-webgebruikersinterface op de regioserver 
2. Selecteer in het gedeelte Blokcache de optie L1 (en L2 als L2 is geconfigureerd) om de cachehit-ratio's te bekijken.

Een screenshot met de cache-hit ratio van de L1-blokcache wordt hieronder getoond:

Hier is een link naar meer informatie over de hierboven getoonde HBase-screenshot en de block-cache https://docs.cloudera.com/runtime/7.2.2/configure-hbase/topics/hbase-blockcache.html

Over YCSB

YCSB is een open-source specificatie- en programmasuite voor het evalueren van de ophaal- en onderhoudsmogelijkheden van computerprogramma's. Het is een zeer populaire tool die wordt gebruikt om de relatieve prestaties van NoSQL-databasebeheersystemen te vergelijken.

Als u YCSB wilt gebruiken om de prestaties van de operationele database te testen, gaat u naar de blog YCSB uitvoeren voor HBase