HBase Prestandatestning med YCSB

När du kör ett prestandabenchmarkingverktyg på ditt kluster är ett avgörande beslut alltid vilken datamängdsstorlek som ska användas för ett prestandatest, och här visar vi varför det är viktigt att välja en datauppsättningsstorlek "bra passform" när du kör en HBase-prestanda testa på ditt kluster.

HBase-klusterkonfigurationerna och storleken på datamängden kan variera prestandan för din arbetsbelastning och testresultaten på samma kluster. Du bör välja denna datamängdsstorlek baserat på vad du försöker förstå om ditt klusters prestanda. För att visa skillnaden mellan en arbetsuppsättning som passar i tillgängligt minnescache och en som måste läsas från underliggande lagring körde vi 2 YCSB arbetsbelastningstester med lämpligt valda datamängdsstorlekar på samma CDP Private Cloud Base 7.2.2 Operation Database-kluster. Vi använde datamängdsstorlekar på 40 GB vs 1 TB och genomströmningen för de olika YCSB-arbetsbelastningarna jämförs nedan, i diagrammet högre stapeln desto bättre genomströmning.

Obs:Genomströmning =Operationer per sekund

När en applikation försöker göra en läsning från ett HBase-kluster, kontrollerar regionservern som hanterar begäran först om de nödvändiga resultaten finns i ett datablock som redan är lokalt för dess process via dess blockcache. Om datablocket finns kan klientförfrågan betjänas direkt från cachen och detta räknas som en cacheträff. Men om blocket för närvarande inte är lokalt för regionserverprocessen så räknas det som en cachemiss och det måste läsas från HF-filen i HDFS-lagring. Beroende på cache-användning kommer det blocket sedan att sparas i cachen för framtida förfrågningar.

Som förväntat och ses i sammanfattningsdiagrammet har en arbetsbelastning där de flesta datamängder passar i cachen fördröjningar som är lägre och genomströmningen är mycket högre jämfört med en arbetsbelastningskörning där data nås från HFiles i hdfs-lagring.

För att välja storlek på våra arbetsbelastningsdatauppsättningar för att uppfylla våra testmål väl, är det viktigt att kontrollera storleken på RegionServer-högar, L1- och L2-cacher, OS-buffertcacher och sedan ställa in en lämplig datamängdsstorlek. Efter att en YCSB-arbetsbelastningskörning har slutförts en bra parameter att kontrollera som ett sätt att verifiera att saker och ting fungerade som förväntat är hur mycket av datan som betjänades från cachen (en cacheträff) och hur mycket som nåddes från hdfs-lagring. Detta förhållande mellan regionserverns cacheträffar och det totala antalet läsbegäranden är cacheträffförhållandet.

Du kan hitta denna information från L1-cacheträffförhållandet "l1CacheHitRatio"-konfigurationen. Om du har både L1- och L2-cacher inställda i ditt kluster så betjänar L1-cachen indexblocken och L2-cachen betjänar datablocken, och du kan spela in både L1 "l1CacheHitRatio" och L2 "l2CacheHitRatio"-konfigurationer som referens.

Resten av det här blogginlägget kommer att gå igenom detaljer om vår testinställning, välja datauppsättningsstorlek och sedan köra YCSB med dessa datauppsättningsstorlekar.

HBase-klusterkonfiguration som används för detta test:

• Använt kluster: 6 nodkluster (1 master + 5 regionservrar)
• Beskrivning: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2,2Ghz, 128GB RAM, 4-2TB diskar
• Säkerhet: Ingen konfigurerad (ingen Kerberos)
• CDP-version: CDP Private Cloud Base 7.2.2 6 nods HBase-kluster med 1 master + 5 regionservrar
• JDK använde jdk1.8_232
• HBase Region-servrar konfigurerades med 32 GB heap 
• HBase master konfigurerades med 4 GB heap
• L1-cache med LruBlockCache användes med 12,3 GB cachestorlek
• Totalt L1-cache i klustret är 61 GB (12,3 * 5 =61 GB)
• L2 off heap-cache konfigurerades inte i klustret

Storleksfall 1:Data passar helt in i tillgänglig cache på klustret

I vårt HBase-kluster konfigurerade vi totalt 61 GB (12,3 GB *5) över de 5 regionservrarna som tilldelats för L1-blockcache. För en datauppsättning som helt passar in i cachen valde vi en datauppsättning som var 40 GB i storlek.

Storleksfall 2:Datauppsättningen är större än den tillgängliga cachen i klustret

För det andra scenariot vill vi att data ska vara mycket större än den tillgängliga cachen. För att välja en lämplig datamängdsstorlek tittade vi på både den konfigurerade HBase-blockcachen och OS-buffertcachen i klustret. I vårt givna HBase-kluster är den konfigurerade L1-blockcachen 61G när den är aggregerad över RegionServers. Servernoderna hade totalt 128G RAM var och allt minne som inte är dedikerat till en serverprocess kan användas av operativsystemet för att effektivt cache de underliggande HDFS-blocken och öka den totala genomströmningen. I vår testkonfiguration finns det cirka 96G OS-cache tillgängligt på varje regionservernod för detta ändamål (ignorering av minnet som används av DataNode eller OS-processer för att förenkla saker och ting). Genom att aggregera detta över de 5 regionservrarna hade vi en potential på nästan 500G för buffertar (96G * 5 regionservrar). Därför valde vi en datamängdsstorlek på 1 TB, vilket överskred både den konfigurerade blockcachen och den tillgängliga OS-buffertcachen.

Omvandla måldatastorlekar till YCSB-parametrar

I YCSB är en rad 1KB som standard så beroende på hur många rader du laddar in i YCSB "användarbara" kan du enkelt uppskatta din YCSB "användbara" tabelldatastorlek. Så om du laddar upp 1 miljon rader har du laddat upp 1 000 000 * 1KB =1 GB data till YCSB  'användbar'.

Datauppsättningsstorlekarna som användes för våra två tester var:

• 40 GB data med 40 miljoner rader
• 1 TB data med 1 miljard rader 

Testmetod

CDP Private Cloud Base 7.2.2 installerades på klustret med 6 noder och arbetsbelastningsdata med 40 miljoner rader (total datamängdsstorlek => 40 GB) genererades och YCSB-arbetsbelastningar kördes. Efter laddningen väntade vi på att alla komprimeringsoperationer skulle slutföras innan vi startade arbetsbelastningstestet.

YCSB-arbetsbelastningar som kördes på HBase var

1. Arbetsbelastning A:50 % läst och 50 % uppdatering
2. Arbetsbelastning C:100 % läst 
3. Arbetsbelastning F:50 % Läs- och 50 % uppdatering/läs-ändra-skrivförhållande:50/50
4. Arbetsbelastning endast för anpassad uppdatering:100 % uppdatering
   

Varje YCSB-arbetsbelastning (A,C,F och UpdateOnly) kördes i 15 minuter vardera, och hela körningen upprepades 5 gånger utan omstarter mellan körningarna för att mäta YCSB-genomströmningen*. Resultaten som visas är medelvärden tagna för de senaste 3 körningarna från de 5 körningarna. De två första testkörningarna ignorerades för att undvika den första och andra körningen.

När 40 GB körningar var klara, släppte vi användartabellen och genererade om 1 miljard rader för att skapa en datauppsättningsstorlek på 1 TB och körde om testerna med samma metod på samma kluster.

Testresultat

YCSB-resultat med 40 GB

I 40GB-fallet kan data helt passa in i 61GB L1-cachen på klustret. L1-cacheträffförhållandet som observerades i klustret under testet var nära 99 %.

Tips: För mindre datauppsättningar där data kan passa in i cachen, kan vi också använda alternativet cache vid laddning och förvärma cachen för att få 100 % cacheträffförhållande med hjälp av tabellalternativet PREFETCH_BLOCKS_ON_OPEN

Vi körde varje YCSB-arbetsbelastning i 15 minuter var 5:e gång och tog medelvärden från de senaste 3 körningarna för att undvika det första loppet.

Resultat sett med 40G L1 cacheträffförhållande 99 % på regionservrarna visas nedan i tabellen: 

YCSB-resultat med 1 TB datamängd

I 1TB-fallet passar data inte in i 61GB L1-cachen på klustret eller 500GB OS-buffertcachen. L1-cacheträffförhållandet i klustret som observerades under testet var 82–84 %.

Vi körde varje arbetsbelastning i 15 minuter var 5 gånger, och tog medelvärden från de senaste 3 körningarna för att undvika det första loppet.

Resultat sett med 1 TB L1-cacheträffförhållande 82–84 % på regionservrarna visas nedan i tabellen: 

*Genomströmning (ops/sek) =antal operationer per sekund

Analys:

Genom att jämföra testresultaten för de två olika datamängdsstorlekarna ovan kan vi se hur samma arbetsbelastning kan variera från 3K operationer per sekund till 165K operationer per sekund när data nås snabbare från 40G-datauppsättningen med uppvärmd cache jämfört med hdfs-lagring.

Diagrammet nedan visar genomströmningen och jämför hur genomströmningen förändrades för olika arbetsbelastningar när de kördes med de två datauppsättningarna av olika storlek. I diagrammet högre stapel desto bättre genomströmning.

Obs:Genomströmning =Operationer per sekund

Som framgår av diagrammet hade YCSB-arbetsbelastningarna som läser data som Workload A, Workload C och Workload F en mycket bättre genomströmning i 40G-fallet där data enkelt passade in i cachen jämfört med 1TB-datastorleksfallet där HFile-datan måste vara nås från HDFS

Om man tittar på cacheträffförhållandet, hade 40G-datauppsättningen en cacheträffförhållande på nära 99 %, och 1TB-datauppsättningen hade en cacheträffförhållande på cirka 85 %, så 15 % av datan i 1TB-fallet nåddes från hdfs-lagring .

YCSB-arbetsbelastningen för anpassade uppdateringar som vi körde hade samma genomströmning i båda fallen eftersom den bara gjorde uppdateringar och inga läsningar.

Under HBase-prestanda tittar vi noga på 95:e och 99:e percentilens latenser. Den genomsnittliga latensen är bara den totala genomströmningen delat med den totala tiden, men den 95:e percentilen och den 99:e percentilen visar de verkliga extremvärdena som påverkar den totala arbetsbelastningens genomströmning. I fallet med 1 TB orsakar extrema fördröjningsvärden i 95:e och 99:e percentilen att genomströmningen saktar ner, och i fallet med 40 GB leder cachen med låg latens i 99:e percentilen till ökad total genomströmning.

Diagrammet nedan visar latensjämförelsen för genomsnittlig latens, 95:e percentilens latens och 99:e percentilens latens och hur den skiljer sig för olika arbetsbelastningar när den körs med datauppsättningar av olika storlek.

I diagrammet ovan är det svårt att se staplarna som representerar latens för 40 GB-datauppsättningen eftersom de är extremt låga jämfört med latens som observerats för 1TB-datauppsättningen som kommer åt data från hdfs.

Vi ritade latensdiagrammet med hjälp av logg över latensvärdena för att visa skillnaden i diagrammet nedan

Som framgår ovan är latenserna mycket lägre i 40 GB-fallet där cacheträffförhållandet är nära 99 % och de flesta arbetsbelastningsdata är tillgängliga i cachen. I jämförelse med 1TB-datauppsättningen var cacheträffförhållandet cirka 85 % eftersom HF-fildata måste nås från HDFS-lagring.

Genomsnittet och 99 latens för Workload C i 40G-fallet där 99 % data returneras från den uppvärmda cachen var cirka 2 – 4 ms. Den 99:e percentilfördröjningen för samma arbetsbelastning C i 1TB-fallet var cirka 100 ms för arbetsbelastning C (skrivskyddad arbetsbelastning).

Detta visar att en cacheträff från on-heap-blockcachen returnerar en läsning på cirka 2 ms och en cachemiss och att få en post från HDFS kan ta cirka 100 ms på detta kluster.

Rekommendation: 

När du kör ett YCSB benchmarking-test gör datauppsättningens storlek en väsentlig skillnad i prestandaresultaten, och därför är det mycket viktigt att dimensionera testet på rätt sätt. Att samtidigt titta på cacheträffförhållandet och latensskillnader mellan min och 99:e latensen hjälper dig att hitta latensen för en cacheträff jämfört med när data nås från underliggande lagring i klustret.

Tips:

För att kontrollera cacheträffförhållandena för din arbetsbelastning på en regionserver kan du använda kommandot nedan

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

Du kan också se Cache Hit ratio från HBase Web UI genom att följa stegen nedan:

1. Från HBase Web UI, klicka på regionservern 
2. Under avsnittet Blockera cache, välj L1 (och L2 om L2 är konfigurerat) för att granska cacheträffförhållandena.

En skärmdump som visar cacheträffförhållandet från L1-blockcachen visas nedan:

Här är en länk till mer information om HBase skärmdump som visas ovan och blockera cache https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

Om YCSB

YCSB är en öppen källkodsspecifikation och programsvit för att utvärdera hämtning och underhåll av datorprogram. Det är ett mycket populärt verktyg som används för att jämföra relativa prestanda för NoSQL-databashanteringssystem.

För att använda YCSB för att testa prestandan för Operational Database, kolla in bloggen How to Run YCSB for HBase