HBase Performance test ved hjælp af YCSB

Når du kører et performance benchmarking-værktøj på din klynge, er en kritisk beslutning altid, hvilken datasætstørrelse der skal bruges til en præstationstest, og her demonstrerer vi, hvorfor det er vigtigt at vælge en "god pasform" datasætstørrelse, når du kører en HBase-performance test på din klynge.

HBase-klyngekonfigurationerne og størrelsen af ​​datasættet kan variere ydelsen af ​​din arbejdsbyrde og testresultaterne på den samme klynge. Du bør vælge denne datasætstørrelse baseret på, hvad du forsøger at forstå om din klynges ydeevne. For at vise forskellen mellem et arbejdssæt, der passer i tilgængelig hukommelsescache, og et, der skal læses fra underliggende lager, kørte vi 2 YCSB arbejdsbelastningstests med passende valgte datasætstørrelser på den samme CDP Private Cloud Base 7.2.2 Operation Database-klynge. Vi brugte datasætstørrelser på 40 GB vs. 1 TB, og gennemløbet for de forskellige YCSB-arbejdsbelastninger sammenlignes nedenfor. I diagrammet er bjælken højere, jo bedre gennemløbet er.

Bemærk:Gennemløb =Operationer pr. sekund

Når en applikation forsøger at foretage en læsning fra en HBase-klynge, kontrollerer den regionsserver, der håndterer anmodningen, først, om de nødvendige resultater er i en datablok, der allerede er lokal for dens proces via dens blokcache. Hvis datablokken er til stede, kan klientanmodningen betjenes direkte fra cachen, og dette tæller som et cache-hit. Men hvis blokken i øjeblikket ikke er lokal for Region Server-processen, tælles det som en cache-miss, og den skal læses fra HF-filen i HDFS-lageret. Afhængigt af cache-udnyttelse vil denne blok så blive gemt i cachen til fremtidige anmodninger.

Som forventet og set i oversigtsdiagrammet, har en arbejdsbelastning, hvor de fleste datasæt passer i cachen, latenser, der er lavere, og gennemløbet er meget højere sammenlignet med en arbejdsbelastning, hvor der tilgås data fra HFiles i hdfs-lager.

For at vælge størrelser på vores arbejdsbelastningsdatasæt, så de opfylder vores testmål godt, er det vigtigt at kontrollere størrelserne på RegionServer-dynger, L1- og L2-caches, OS-buffercaches og derefter indstille en passende datasætstørrelse. Efter en YCSB-arbejdsbelastningskørsel har gennemført en god parameter til at kontrollere, som en måde at verificere, at tingene kørte som forventet, er, hvor meget af dataene der blev serviceret fra cachen (et cache-hit), og hvor meget der blev tilgået fra hdfs-lageret. Dette forhold mellem regionsserver-cache-hits og det samlede antal læseanmodninger er cache-hit-forholdet.

Du kan finde denne information fra L1 cache hit ratio "l1CacheHitRatio" config. Hvis du har både L1- og L2-caches indstillet i din klynge, tjener L1-cachen indeksblokkene, og L2-cachen betjener datablokkene, og du kan optage både L1 "l1CacheHitRatio" og L2 "l2CacheHitRatio"-konfigurationer til reference.

Resten af ​​dette blogindlæg vil gennemgå detaljerne i vores testopsætning, vælge datasætstørrelsen og derefter køre YCSB med disse datasætstørrelser.

HBase-klyngekonfiguration brugt til denne test:

• Anvendt klynge: 6 node-klynge (1 master + 5 regionsservere)
• Beskrivelse: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2,2Ghz, 128GB ram, 4-2TB diske
• Sikkerhed: Ingen konfigureret (ingen Kerberos)
• CDP-version: CDP Private Cloud Base 7.2.2 6 node HBase-klynge med 1 master + 5 regionsservere
• JDK brugte jdk1.8_232
• HBase Region-servere blev konfigureret med 32 GB heap 
• HBase master blev konfigureret med 4 GB heap
• L1-cache med LruBlockCache blev brugt med 12,3 GB cachestørrelse
• Samlet L1-cache i klyngen er 61 GB (12,3 * 5 =61 GB)
• L2 off heap cache blev ikke konfigureret på klyngen

Størrelsestilfælde 1:Data passer fuldstændig ind i den tilgængelige cache på klyngen

I vores HBase-klynge konfigurerede vi i alt 61 GB (12,3 GB *5) på tværs af de 5 regionsservere, der er allokeret til L1-blokcache. For et datasæt, der passer fuldstændig ind i cachen, valgte vi et datasæt på 40 GB i størrelse.

Størrelsestilfælde 2:Datasæt større end den tilgængelige cache på klyngen

For det andet scenarie ønsker vi, at dataene skal være meget større end den tilgængelige cache. For at vælge en passende datasætstørrelse så vi på både den konfigurerede HBase-blokcache og OS-buffercachen i klyngen. I vores givne HBase-klynge er den konfigurerede L1-blokcache 61G, når den er aggregeret på tværs af RegionServers. Servernoderne havde i alt 128G RAM hver, og enhver hukommelse, der ikke er dedikeret til en serverproces, kan bruges af OS til effektivt at cache de underliggende HDFS-blokke og øge den samlede gennemstrømning. I vores testkonfiguration er der omkring 96G OS-cache tilgængelig på hver regionsservernode til dette formål (ignorerer den hukommelse, der bruges af DataNode- eller OS-processerne for at forenkle tingene). Ved at aggregere dette på tværs af de 5 regionsservere havde vi et potentiale på næsten 500G for buffere (96G * 5 regionsservere). Derfor valgte vi en datasætstørrelse på 1TB, hvilket oversteg både den konfigurerede blokcache og den tilgængelige OS-buffercache.

Forvandling af måldatastørrelser til YCSB-parametre

I YCSB er en række 1KB som standard, så afhængigt af hvor mange rækker du indlæser i YCSB 'brugerbare', kan du nemt estimere din YCSB 'brugerbare' tabeldatastørrelse. Så hvis du uploader 1 million rækker, har du uploadet 1.000.000 * 1KB =1 GB data til YCSB'en 'brugerbar'.

Datasætstørrelserne, der blev brugt til vores to tests, var:

• 40 GB data med 40 millioner rækker
• 1 TB data med 1 milliard rækker 

Testmetode

CDP Private Cloud Base 7.2.2 blev installeret på 6 node-klyngen, og arbejdsbelastningsdata med 40 millioner rækker (samlet datasætstørrelse => 40 GB) blev genereret, og YCSB-arbejdsbelastninger blev kørt. Efter indlæsning ventede vi på, at alle komprimeringsoperationer var færdige, før vi startede arbejdsbelastningstesten.

YCSB-arbejdsbelastninger, der blev kørt på HBase, var

1. Arbejdsbelastning A:50 % læst og 50 % opdatering
2. Arbejdsbelastning C:100 % læst 
3. Arbejdsbelastning F:50 % Læse og 50 % Opdatering/Læse-Rediger-Skriveforhold:50/50
4. Kun tilpasset opdatering arbejdsbelastning:100 % opdatering
   

Hver YCSB-arbejdsbelastning (A,C,F og UpdateOnly) blev kørt i 15 minutter hver, og hele kørslen blev gentaget 5 gange uden genstart mellem kørsler for at måle YCSB-gennemløb*. De viste resultater er gennemsnit taget for de sidste 3 kørsler fra de 5 kørsler. De første 2 testkørsler blev ignoreret for at undgå den første og anden kørselsstraf.

Da 40 GB-kørsler var afsluttet, droppede vi brugertabellen og gengenererede 1 milliard rækker for at skabe 1 TB datasætstørrelse og genkørte testene med den samme metode på den samme klynge.

Testresultater

YCSB-resultater med 40 GB

I tilfældet med 40 GB kan dataene helt passe ind i 61 GB L1-cachen på klyngen. L1 cache hit ratio observeret i klyngen under testen var tæt på 99 %.

Tip: For mindre datasæt, hvor data kan passe ind i cachen, kan vi også bruge indstillingen cache ved indlæsning og forvarme cachen for at få 100 % cache hit-forhold ved hjælp af tabelindstillingen PREFETCH_BLOCKS_ON_OPEN

Vi kørte hver YCSB-arbejdsbelastning i 15 minutter hver 5 gange og tog gennemsnit fra de sidste 3 løb for at undgå den første løbsstraf.

Resultater set med 40G L1 cache hit ratio 99 % på regionsserverne er vist nedenfor i tabel: 

YCSB-resultater med 1 TB datasæt

I 1TB-tilfældet passer dataene ikke ind i 61GB L1-cachen på klyngen eller 500GB OS-buffercachen. L1 cache hit ratio i klyngen observeret under testen var 82-84%.

Vi kørte hver arbejdsbelastning i 15 minutter hver 5 gange og tog gennemsnit fra de sidste 3 løb for at undgå den første løbsstraf.

Resultater set med 1 TB L1 cache hit ratio 82-84 % på regionsserverne er vist nedenfor i tabel: 

*Throughput (ops/sek) =antal operationer pr. sekund

Analyse:

Ved at sammenligne testresultaterne for de to forskellige datasætstørrelser ovenfor kan vi se, hvordan den samme arbejdsbyrdegennemstrømning kan variere fra 3K operationer pr. sekund til 165K operationer pr. sekund når data tilgås hurtigere fra 40G-datasættet med opvarmet cache i forhold til fra hdfs-lager.

Diagrammet nedenfor viser gennemløbet og sammenligner, hvordan gennemløbet ændrede sig for forskellige arbejdsbelastninger, når det blev kørt med de 2 forskellige størrelsesdatasæt. I diagrammet højere søjle jo bedre gennemløb.

Bemærk:Gennemløb =Operationer pr. sekund

Som det ses i diagrammet, havde YCSB-arbejdsbelastningerne, der læste data som Workload A, Workload C og Workload F, en meget bedre gennemstrømning i 40G-tilfældet, hvor dataene nemt passede ind i cachen sammenlignet med 1TB-datastørrelsessagen, hvor HFile-dataene skulle være tilgås fra HDFS

Ser man på cache-hit-forholdet, havde 40G-datasættet et cache-hit-forhold på tæt på 99 %, og 1 TB-datasættet havde et cache-hit-forhold på omkring 85 %, så 15 % af dataene i 1 TB tilfælde blev tilgået fra hdfs-lager .

YCSB brugerdefinerede kun-opdaterings-arbejdsbelastning, vi kørte, havde samme gennemløb i begge tilfælde, da den kun foretog opdateringer og ingen læser.

Under HBase-performance ser vi nøje på 95. og 99. percentil-latenserne. Den gennemsnitlige latenstid er kun den samlede gennemstrømning divideret med den samlede tid, men 95. percentilen og 99. percentilen viser de reelle outliers, der påvirker den samlede arbejdsbyrdegennemstrømning. I 1 TB-tilfældet forårsager de høje latens-outliers i 95. og 99. percentil, at gennemløbet bliver langsommere, og i 40GB-tilfælde fører cachen med lav forsinkelse i 99. percentil til øget total gennemløb.

Nedenstående diagram viser latenssammenligningen for gennemsnitlig latens, 95. percentil latency og 99. percentil latens, og hvordan den adskiller sig for forskellige arbejdsbelastninger, når den køres med datasæt af forskellig størrelse.

I ovenstående diagram er det svært at se søjlerne, der repræsenterer latens for 40 GB-datasættet, da de er ekstremt lave sammenlignet med latens observeret for 1TB-datasættet, der får adgang til data fra hdfs.

Vi plottede latensgrafen ved hjælp af log over latensværdierne for at vise forskellen i diagrammet nedenfor

Som det ses ovenfor, er forsinkelserne meget lavere i tilfældet med 40 GB, hvor cache-hitforholdet er tæt på 99%, og de fleste arbejdsbelastningsdata er tilgængelige i cachen. Til sammenligning for 1TB-datasættet var cache-hitforholdet omkring 85 %, da HF-fildata skulle tilgås fra HDFS-lager.

Gennemsnittet og 99 latens for Workload C i 40G-tilfældet, hvor 99 % data returneres fra den opvarmede cache, var omkring 2 – 4 ms. 99. percentil-latenstiden for den samme Workload C i 1TB-tilfældet var omkring 100ms for Workload C (skrivebeskyttet arbejdsbelastning).

Dette viser, at et cache-hit fra on-heap-blokcachen returnerer en læsning på omkring 2 ms, og en cache-miss og at få en rekord fra HDFS kan tage omkring 100 ms på denne klynge.

Anbefaling: 

Når du kører en YCSB benchmarking-test, gør datasættets størrelse en væsentlig forskel i præstationsresultaterne, og derfor er det meget vigtigt at dimensionere testen korrekt. På samme tid vil se på cache-hit-forholdet og latensforskelle mellem min og 99. latency hjælpe dig med at finde latensen af ​​et cache-hit sammenlignet med, når der tilgås data fra underliggende lager i klyngen.

Tip:

For at kontrollere cache-hitforholdet for din arbejdsbelastning på en regionsserver kan du bruge nedenstående kommando

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

Du kan også se Cache Hit ratio fra HBase Web UI ved at følge nedenstående trin:

1. Fra HBase Web UI, klik på regionsserveren 
2. Vælg L1 (og L2, hvis L2 er konfigureret) under Blok-cache-sektionen for at gennemgå cachens hitforhold.

Et skærmbillede, der viser cache-hitforholdet fra L1-blokcachen, er vist nedenfor:

Her er et link til mere info omkring HBase-skærmbillede vist ovenfor og blokcache https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

Om YCSB

YCSB er en open source-specifikation og programpakke til evaluering af computerprogrammers genfindings- og vedligeholdelsesmuligheder. Det er et meget populært værktøj, der bruges til at sammenligne den relative ydeevne af NoSQL-databasestyringssystemer.

For at bruge YCSB til at teste ydeevnen af ​​Operational Database, tjek bloggen Sådan kører du YCSB for HBase