Teori og praksis i brugen af ​​HBase

God eftermiddag Mit navn er Danil Lipovoy, vores team hos Sbertech begyndte at bruge HBase som lager for driftsdata. I løbet af studiet er der ophobet erfaringer, som jeg ønskede at systematisere og beskrive (vi håber, at det vil være nyttigt for mange). Alle eksperimenter nedenfor blev udført med HBase version 1.2.0-cdh5.14.2 og 2.0.0-cdh6.0.0-beta1.

1. Generel arkitektur
2. Skrivning af data til HBASE
3. Læser data fra HBASE
4. Datacaching
5. Batch databehandling MultiGet/MultiPut
6. Strategi for opdeling af tabeller i regioner (opdeling)
7. Fejltolerance, komprimering og datalokalitet
8. Indstillinger og ydeevne
9. Stresstest
10. Fund

1. Generel arkitektur

Backup-masteren lytter til hjerteslag fra den aktive på ZooKeeper-knuden og, i tilfælde af forsvinden, overtager masterens funktioner.

2. Skriv data til HBASE

Lad os først se på det enkleste tilfælde - at skrive et nøgleværdiobjekt til en tabel ved hjælp af put(rowkey). Klienten skal først finde ud af, hvor Root Region Server (RRS), som gemmer hbase:meta-tabellen, er placeret. Han modtager denne information fra ZooKeeper. Hvorefter den tilgår RRS og læser hbase:meta-tabellen, hvorfra den udtrækker information om, hvilken RegionServer (RS) der er ansvarlig for at gemme data for en given rækketast i interessetabellen. Til fremtidig brug cachelagres metatabellen af ​​klienten og derfor går efterfølgende opkald hurtigere, direkte til RS.

Dernæst skriver RS, efter at have modtaget en anmodning, først og fremmest den til WriteAheadLog (WAL), som er nødvendig for genopretning i tilfælde af et nedbrud. Gemmer derefter dataene i MemStore. Dette er en buffer i hukommelsen, der indeholder et sorteret sæt nøgler for en given region. En tabel kan opdeles i områder (partitioner), som hver indeholder et usammenhængende sæt nøgler. Dette giver dig mulighed for at placere regioner på forskellige servere for at opnå højere ydeevne. Men på trods af det indlysende i denne udtalelse, vil vi senere se, at dette ikke virker i alle tilfælde.

Efter at have placeret en post i MemStore, returneres et svar til klienten om, at posten blev gemt. Men i virkeligheden er det kun gemt i en buffer og kommer først til disken efter en vis periode er gået, eller når den er fyldt med nye data.

Når du udfører "Slet"-handlingen, slettes data ikke fysisk. De markeres blot som slettede, og selve ødelæggelsen sker i det øjeblik, man kalder den store kompakte funktion, som er beskrevet mere detaljeret i afsnit 7.

Filer i HFile-format akkumuleres i HDFS, og fra tid til anden lanceres den mindre kompakte proces, som blot slår små filer sammen til større uden at slette noget. Med tiden bliver dette til et problem, der kun opstår ved læsning af data (det vender vi tilbage til lidt senere).

Ud over indlæsningsprocessen beskrevet ovenfor, er der en meget mere effektiv procedure, som måske er den stærkeste side af denne database - BulkLoad. Det ligger i det faktum, at vi selvstændigt danner HFiles og lægger dem på disk, hvilket giver os mulighed for at skalere perfekt og opnå meget anstændige hastigheder. Faktisk er begrænsningen her ikke HBase, men hardwarens muligheder. Nedenfor er opstartsresultaterne på en klynge bestående af 16 RegionServers og 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråde), HBase version 1.2.0-cdh5.14.2.

Her kan du se, at ved at øge antallet af partitioner (regioner) i tabellen, samt Spark executors, får vi en stigning i downloadhastigheden. Hastigheden afhænger også af optagelydstyrken. Store blokke giver en stigning i MB/sek, små blokke i antallet af indsatte poster pr. tidsenhed, alt andet lige.

Du kan også begynde at indlæse i to borde på samme tid og få dobbelt hastighed. Nedenfor kan du se, at skrivning af 10 KB blokke til to tabeller på én gang sker med en hastighed på omkring 600 MB/sek i hver (i alt 1275 MB/sek), hvilket falder sammen med skrivehastigheden til en tabel 623 MB/sek (se nr. 11 ovenfor)

Men anden kørsel med rekorder på 50 KB viser, at downloadhastigheden vokser lidt, hvilket indikerer, at den nærmer sig grænseværdierne. Samtidig skal du huske på, at der praktisk talt ikke er oprettet nogen belastning på selve HBASE, det eneste, der kræves af det, er først at give data fra hbase:meta, og efter at have linet HFiles, nulstille BlockCache-dataene og gemme MemStore buffer til disk, hvis den ikke er tom.

3. Aflæsning af data fra HBASE

Hvis vi antager, at klienten allerede har alle informationer fra hbase:meta (se punkt 2), så går anmodningen direkte til RS, hvor den nødvendige nøgle er gemt. Først udføres søgningen i MemCache. Uanset om der er data der eller ej, udføres søgningen også i BlockCache-bufferen og om nødvendigt i HFiles. Hvis data blev fundet i filen, placeres de i BlockCache og returneres hurtigere ved næste anmodning. Søgning i HFile er relativt hurtig takket være brugen af ​​Bloom-filteret, dvs. efter at have læst en lille mængde data, afgør den straks, om denne fil indeholder den nødvendige nøgle, og hvis ikke, går den videre til den næste.

Efter at have modtaget data fra disse tre kilder, genererer RS ​​et svar. Især kan den overføre flere fundne versioner af et objekt på én gang, hvis klienten anmodede om versionering.

4. Datacaching

MemStore- og BlockCache-bufferne optager op til 80 % af den allokerede on-heap RS-hukommelse (resten er reserveret til RS-serviceopgaver). Hvis den typiske brugstilstand er sådan, at processer skriver og straks læser de samme data, så giver det mening at reducere BlockCache og øge MemStore, fordi Når skrivning af data ikke kommer ind i cachen til læsning, vil BlockCache blive brugt sjældnere. BlockCache-bufferen består af to dele: LruBlockCache (altid on-heap) og BucketCache (normalt off-heap eller på en SSD). BucketCache skal bruges, når der er mange læseforespørgsler, og de ikke passer ind i LruBlockCache, hvilket fører til aktivt arbejde af Garbage Collector. Samtidig skal du ikke forvente en radikal stigning i ydeevnen ved at bruge læsecachen, men det vender vi tilbage til i afsnit 8

Der er én BlockCache for hele RS, og der er én MemStore for hvert bord (én for hver kolonnefamilie).

Som beskrevet i teorien, når der skrives, går data ikke ind i cachen, og faktisk er sådanne parametre CACHE_DATA_ON_WRITE for tabellen og "Cache DATA ved skrivning" for RS sat til falsk. Men i praksis, hvis vi skriver data til MemStore, så tømmer vi dem til disken (således rydder dem), og slet derefter den resulterende fil, og ved at udføre en get-anmodning vil vi modtage dataene. Desuden, selvom du helt deaktiverer BlockCache og fylder tabellen med nye data, så nulstiller MemStore til disk, sletter dem og anmoder om dem fra en anden session, vil de stadig blive hentet et sted fra. Så HBase gemmer ikke kun data, men også mystiske mysterier.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

Parameteren "Cache DATA ved læsning" er indstillet til falsk. Hvis du har nogle ideer, er du velkommen til at diskutere det i kommentarerne.

5. Batch databehandling MultiGet/MultiPut

Behandling af enkeltforespørgsler (Get/Put/Delete) er en ret dyr operation, så hvis det er muligt, bør du kombinere dem til en liste eller liste, som giver dig mulighed for at få et markant ydelsesboost. Dette gælder især for skriveoperationen, men ved læsning er der følgende faldgrube. Grafen nedenfor viser tiden til at læse 50 poster fra MemStore. Aflæsningen blev udført i én tråd, og den vandrette akse viser antallet af nøgler i anmodningen. Her kan man se, at når man øger til tusinde nøgler i én anmodning, falder eksekveringstiden, dvs. hastigheden stiger. Men med MSLAB-tilstand aktiveret som standard efter denne tærskel begynder et radikalt fald i ydeevnen, og jo større mængde data i posten er, desto længere er driftstiden.

Testene blev udført på en virtuel maskine, 8 kerner, version HBase 2.0.0-cdh6.0.0-beta1.

MSLAB-tilstanden er designet til at reducere heap-fragmentering, som opstår på grund af blanding af nye og gamle generationsdata. Som en løsning, når MSLAB er aktiveret, placeres dataene i relativt små celler (chunks) og behandles i bidder. Som et resultat, når volumen i den anmodede datapakke overstiger den tildelte størrelse, falder ydeevnen kraftigt. På den anden side er det heller ikke tilrådeligt at slukke for denne tilstand, da det vil føre til stop på grund af GC i øjeblikke med intensiv databehandling. En god løsning er at øge cellevolumen ved aktiv skrivning via put samtidig med læsning. Det er værd at bemærke, at problemet ikke opstår, hvis du efter optagelse kører flush-kommandoen, som nulstiller MemStore til disk, eller hvis du indlæser ved hjælp af BulkLoad. Tabellen nedenfor viser, at forespørgsler fra MemStore for større (og samme mængde) data resulterer i opbremsninger. Men ved at øge chunksize, vender vi behandlingstiden tilbage til det normale.

Ud over at øge chunksize, hjælper det at opdele dataene efter region, dvs. bordopdeling. Dette resulterer i, at der kommer færre anmodninger til hver region, og hvis de passer ind i en celle, forbliver svaret godt.

6. Strategi for opdeling af tabeller i regioner (opdeling)

Da HBase er et nøgleværdilager og partitionering udføres af nøgle, er det ekstremt vigtigt at dele dataene ligeligt på tværs af alle regioner. For eksempel vil opdeling af en sådan tabel i tre dele resultere i, at dataene bliver opdelt i tre områder:

Det sker, at dette fører til en kraftig opbremsning, hvis de data, der indlæses senere, ser ud som for eksempel lange værdier, de fleste af dem starter med det samme ciffer, for eksempel:

1000001
1000002
...
1100003

Da nøglerne er gemt som et byte-array, vil de alle starte på samme måde og tilhøre den samme region #1, der lagrer denne række af nøgler. Der er flere opdelingsstrategier:

HexStringSplit – Gør nøglen til en hexadecimal kodet streng i området "00000000" => "FFFFFFFF" og udfyldning til venstre med nuller.

UniformSplit – Forvandler nøglen til et byte-array med hexadecimal kodning i området "00" => "FF" og udfyldning til højre med nuller.

Derudover kan du angive et hvilket som helst område eller sæt af taster til opdeling og konfigurere automatisk opdeling. En af de enkleste og mest effektive tilgange er imidlertid UniformSplit og brugen af ​​hash-sammenkædning, for eksempel det mest betydningsfulde par af bytes fra at køre nøglen gennem CRC32(rowkey)-funktionen og selve rækketasten:

hash + rækketast

Så vil alle data blive fordelt jævnt på tværs af regioner. Ved læsning kasseres de første to bytes simpelthen, og den originale nøgle forbliver. RS kontrollerer også mængden af ​​data og nøgler i regionen og, hvis grænserne overskrides, opdeler den automatisk i dele.

7. Fejltolerance og datalokalitet

Da kun én region er ansvarlig for hvert sæt nøgler, er løsningen på problemer forbundet med RS-nedbrud eller dekommissionering at gemme alle nødvendige data i HDFS. Når RS falder, registrerer masteren dette gennem fraværet af et hjerteslag på ZooKeeper-knuden. Derefter tildeler den den serverede region til en anden RS og da hFiles er gemt i et distribueret filsystem, læser den nye ejer dem og fortsætter med at betjene dataene. Men da nogle af dataene kan være i MemStore og ikke havde tid til at komme ind i HFiles, bruges WAL, som også er gemt i HDFS, til at gendanne operationshistorikken. Efter ændringerne er implementeret, er RS ​​i stand til at reagere på anmodninger, men flytningen fører til, at nogle af dataene og processerne, der servicerer dem, ender på forskellige noder, dvs. lokaliteten er faldende.

Løsningen på problemet er stor komprimering - denne procedure flytter filer til de noder, der er ansvarlige for dem (hvor deres regioner er placeret), som et resultat af, at belastningen på netværket og diskene under denne procedure øges kraftigt. Men i fremtiden accelereres adgangen til data mærkbart. Derudover udfører major_compaction fletning af alle HFiles til én fil inden for en region og rydder også op i data afhængigt af tabelindstillingerne. Du kan f.eks. angive antallet af versioner af et objekt, der skal bibeholdes, eller den levetid, hvorefter objektet fysisk slettes.

Denne procedure kan have en meget positiv effekt på driften af ​​HBase. Billedet nedenfor viser, hvordan ydeevnen forringes som følge af aktiv dataregistrering. Her kan du se, hvordan 40 tråde skrev til en tabel og 40 tråde læste data samtidigt. Skrivetråde genererer flere og flere HFiles, som læses af andre tråde. Som følge heraf skal flere og flere data fjernes fra hukommelsen, og til sidst begynder GC'en at fungere, hvilket praktisk talt lammer alt arbejde. Lanceringen af ​​større komprimering førte til rydning af det resulterende affald og genoprettelse af produktiviteten.

Testen blev udført på 3 DataNodes og 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråde). HBase version 1.2.0-cdh5.14.2

Det er værd at bemærke, at større komprimering blev lanceret på en "live" tabel, hvori data aktivt blev skrevet og læst. Der var en erklæring på nettet om, at dette kunne føre til et forkert svar ved læsning af data. For at kontrollere blev der startet en proces, der genererede nye data og skrev dem til en tabel. Hvorefter jeg straks læste og tjekkede, om den resulterende værdi faldt sammen med det nedskrevne. Mens denne proces kørte, blev større komprimering kørt omkring 200 gange, og der blev ikke registreret en eneste fejl. Måske opstår problemet sjældent og kun under høj belastning, så det er mere sikkert at stoppe skrive- og læseprocesserne som planlagt og udføre rengøring for at forhindre sådanne GC-nedtrækninger.

Desuden påvirker større komprimering ikke status for MemStore; for at tømme den til disken og komprimere den, skal du bruge flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Indstillinger og ydeevne

Som allerede nævnt viser HBase sin største succes, hvor den ikke behøver at gøre noget, når den udfører BulkLoad. Dette gælder dog for de fleste systemer og mennesker. Dette værktøj er dog mere velegnet til at lagre data i bulk i store blokke, hvorimod hvis processen kræver flere konkurrerende læse- og skriveanmodninger, bruges Get og Put-kommandoerne beskrevet ovenfor. For at bestemme de optimale parametre blev lanceringer udført med forskellige kombinationer af tabelparametre og indstillinger:

• 10 tråde blev lanceret samtidigt 3 gange i træk (lad os kalde dette en blok af tråde).
• Driftstiden for alle tråde i en blok blev gennemsnittet og var det endelige resultat af blokkens drift.
• Alle tråde arbejdede med den samme tabel.
• Før hver start af gevindblokeringen blev der udført en større komprimering.
• Hver blok udførte kun én af følgende operationer:

-Sætte
-Få
—Get+Put

• Hver blok udførte 50 gentagelser af sin operation.
• Blokstørrelsen af ​​en post er 100 bytes, 1000 bytes eller 10000 bytes (tilfældig).
• Blokke blev lanceret med forskellige antal ønskede nøgler (enten én nøgle eller 10).
• Blokkene blev kørt under forskellige bordopstillinger. Ændrede parametre:

— BlockCache = slået til eller fra
— Blokstørrelse = 65 KB eller 16 KB
— Partitioner = 1, 5 eller 30
— MSLAB = aktiveret eller deaktiveret

Så blokken ser sådan ud:

en. MSLAB-tilstand blev slået til/fra.
b. Der blev oprettet en tabel, for hvilken følgende parametre blev indstillet: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Kompression blev indstillet til GZ.
d. 10 tråde blev lanceret samtidigt med 1/10 put/get/get+put operationer i denne tabel med poster på 100/1000/10000 bytes, der udfører 50 forespørgsler i træk (tilfældige nøgler).
e. Punkt d blev gentaget tre gange.
f. Driftstiden for alle tråde blev beregnet som gennemsnit.

Alle mulige kombinationer blev testet. Det er forudsigeligt, at hastigheden vil falde, efterhånden som poststørrelsen øges, eller at deaktivering af caching vil forårsage afmatning. Målet var dog at forstå graden og signifikansen af ​​hver parameters indflydelse, så de indsamlede data blev ført ind i input af en lineær regressionsfunktion, som gør det muligt at vurdere signifikansen ved hjælp af t-statistik. Nedenfor er resultaterne af de blokke, der udfører Put-operationer. Komplet sæt af kombinationer 2*2*3*2*3 = 144 muligheder + 72 tk. nogle blev gjort to gange. Derfor er der 216 kørsler i alt:

Test blev udført på en mini-cluster bestående af 3 DataNodes og 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråde). HBase version 1.2.0-cdh5.14.2.

Den højeste indsættelseshastighed på 3.7 sekunder blev opnået med MSLAB-tilstand slået fra, på et bord med én partition, med BlockCache aktiveret, BlockSize = 16, poster på 100 bytes, 10 stykker pr. pakke.
Den laveste indsættelseshastighed på 82.8 sek. blev opnået med MSLAB-tilstand aktiveret, på en tabel med én partition, med BlockCache aktiveret, BlockSize = 16, poster på 10000 bytes, 1 hver.

Lad os nu se på modellen. Vi ser den gode kvalitet af modellen baseret på R2, men det er helt klart, at ekstrapolering er kontraindiceret her. Den faktiske opførsel af systemet, når parametre ændres, vil ikke være lineær; denne model er ikke nødvendig for forudsigelser, men for at forstå, hvad der skete inden for de givne parametre. For eksempel ser vi her fra Elevens kriterium, at BlockSize og BlockCache-parametrene ikke har betydning for Put-operationen (som generelt er ret forudsigelig):

Men det faktum, at en stigning i antallet af partitioner fører til et fald i ydeevnen, er noget uventet (vi har allerede set den positive virkning af at øge antallet af partitioner med BulkLoad), selvom det er forståeligt. For det første skal du til behandling generere anmodninger til 30 regioner i stedet for én, og mængden af ​​data er ikke sådan, at dette vil give en gevinst. For det andet bestemmes den samlede driftstid af den langsomste RS, og da antallet af DataNodes er mindre end antallet af RS'er, har nogle regioner nul lokalitet. Nå, lad os se på top fem:

Lad os nu evaluere resultaterne af at udføre Get-blokke:

Antallet af partitioner har mistet betydning, hvilket formentlig kan forklares med, at dataene cachedes godt og læsecachen er den mest signifikante (statistisk) parameter. Det er naturligvis også meget nyttigt at øge antallet af meddelelser i en anmodning. Topscore:

Nå, endelig, lad os se på modellen af ​​blokken, der først udførte get og derefter satte:

Alle parametre er væsentlige her. Og ledernes resultater:

9. Belastningstest

Nå, endelig lancerer vi en mere eller mindre anstændig belastning, men det er altid mere interessant, når du har noget at sammenligne med. På hjemmesiden for DataStax, nøgleudvikleren af ​​Cassandra, er der resultaterne NT af en række NoSQL-lager, inklusive HBase version 0.98.6-1. Indlæsning blev udført af 40 tråde, datastørrelse 100 bytes, SSD-diske. Resultatet af test af Read-Modify-Write-operationerne viste følgende resultater.

Så vidt jeg forstår, blev læsning udført i blokke med 100 poster, og for 16 HBase-noder viste DataStax-testen en ydeevne på 10 tusinde operationer i sekundet.

Det er heldigt, at vores klynge også har 16 noder, men det er ikke særlig “heldigt” at hver har 64 kerner (tråde), mens der i DataStax testen kun er 4. Til gengæld har de SSD-drev, mens vi har HDD’er eller mere steg den nye version af HBase og CPU-udnyttelse under belastning praktisk talt ikke væsentligt (visuelt med 5-10 procent). Lad os dog prøve at begynde at bruge denne konfiguration. Standard tabelindstillinger, læsning udføres i nøgleområdet fra 0 til 50 millioner tilfældigt (dvs. i det væsentlige nyt hver gang). Tabellen indeholder 50 millioner poster, opdelt i 64 partitioner. Nøglerne hash ved hjælp af crc32. Tabelindstillinger er standard, MSLAB er aktiveret. Ved at starte 40 tråde, læser hver tråd et sæt på 100 tilfældige nøgler og skriver straks de genererede 100 bytes tilbage til disse nøgler.

Stander: 16 DataNode og 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråde). HBase version 1.2.0-cdh5.14.2.

Det gennemsnitlige resultat er tættere på 40 tusinde operationer i sekundet, hvilket er markant bedre end i DataStax-testen. Men af ​​eksperimentelle formål kan du ændre betingelserne lidt. Det er ret usandsynligt, at alt arbejde udelukkende vil blive udført på ét bord, og også kun på unikke nøgler. Lad os antage, at der er et bestemt "hot" sæt nøgler, der genererer hovedbelastningen. Lad os derfor prøve at skabe en belastning med større poster (10 KB), også i batches af 100, i 4 forskellige tabeller og begrænse rækken af ​​anmodede nøgler til 50 40. Grafen nedenfor viser lanceringen af ​​100 tråde, hver tråd læser et sæt på 10 nøgler og skriver straks tilfældige XNUMX KB på disse nøgler tilbage.

Stander: 16 DataNode og 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråde). HBase version 1.2.0-cdh5.14.2.

Under belastningen blev større komprimering iværksat flere gange, som vist ovenfor, uden denne procedure vil ydeevnen gradvist forringes, dog opstår der også yderligere belastning under udførelsen. Nedskrivninger er forårsaget af forskellige årsager. Nogle gange var trådene færdige med at fungere, og der var en pause, mens de blev genstartet, nogle gange skabte tredjepartsapplikationer en belastning på klyngen.

At læse og skrive med det samme er et af de sværeste arbejdsscenarier for HBase. Hvis du kun laver små put-anmodninger, for eksempel 100 bytes, og kombinerer dem i pakker med 10-50 tusinde stykker, kan du få hundredtusindvis af operationer i sekundet, og situationen er den samme med skrivebeskyttede anmodninger. Det er værd at bemærke, at resultaterne er radikalt bedre end dem, der opnås af DataStax, mest af alt på grund af anmodninger i blokke på 50 tusind.

Stander: 16 DataNode og 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråde). HBase version 1.2.0-cdh5.14.2.

10 konklusioner

Dette system er ret fleksibelt konfigureret, men indflydelsen af ​​et stort antal parametre er stadig ukendt. Nogle af dem blev testet, men var ikke inkluderet i det resulterende testsæt. For eksempel viste foreløbige eksperimenter ubetydelig betydning af en sådan parameter som DATA_BLOCK_ENCODING, som koder information ved hjælp af værdier fra naboceller, hvilket er forståeligt for tilfældigt genererede data. Hvis du bruger et stort antal duplikerede objekter, kan gevinsten være betydelig. Generelt kan vi sige, at HBase giver indtryk af en ret seriøs og gennemtænkt database, som kan være ret produktiv, når man udfører operationer med store datablokke. Især hvis det er muligt at adskille læse- og skriveprocesserne i tid.

Hvis der efter din mening er noget, der ikke er afsløret nok, er jeg klar til at fortælle dig mere detaljeret. Vi inviterer dig til at dele din oplevelse eller diskutere, hvis du er uenig i noget.

Kilde: www.habr.com