Teori og praksis for bruk av HBase

God ettermiddag Mitt navn er Danil Lipovoy, teamet vårt hos Sbertech begynte å bruke HBase som lagring for driftsdata. I løpet av studiet har det samlet seg erfaringer som jeg ønsket å systematisere og beskrive (vi håper at det vil være nyttig for mange). Alle eksperimentene nedenfor ble utført med HBase versjoner 1.2.0-cdh5.14.2 og 2.0.0-cdh6.0.0-beta1.

1. Generell arkitektur
2. Skrive data til HBASE
3. Leser data fra HBASE
4. Databufring
5. Batch databehandling MultiGet/MultiPut
6. Strategi for å dele tabeller i regioner (deling)
7. Feiltoleranse, komprimering og datalokalitet
8. Innstillinger og ytelse
9. Stresstesting
10. Funn

1. Generell arkitektur

Backup-masteren lytter til hjerteslagene til den aktive på ZooKeeper-noden og, i tilfelle forsvinning, overtar funksjonene til masteren.

2. Skriv data til HBASE

La oss først se på det enkleste tilfellet - å skrive et nøkkelverdiobjekt til en tabell ved å bruke put(radtast). Klienten må først finne ut hvor Root Region Server (RRS), som lagrer hbase:meta-tabellen, befinner seg. Han mottar denne informasjonen fra ZooKeeper. Deretter får den tilgang til RRS og leser hbase:meta-tabellen, hvorfra den henter ut informasjon om hvilken RegionServer (RS) som er ansvarlig for å lagre data for en gitt radtast i interessetabellen. For fremtidig bruk bufres metatabellen av klienten og derfor går påfølgende anrop raskere, direkte til RS.

Deretter skriver RS, etter å ha mottatt en forespørsel, den først og fremst til WriteAheadLog (WAL), som er nødvendig for gjenoppretting i tilfelle krasj. Lagrer deretter dataene til MemStore. Dette er en buffer i minnet som inneholder et sortert sett med nøkler for en gitt region. En tabell kan deles inn i regioner (partisjoner), som hver inneholder et usammenhengende sett med nøkler. Dette lar deg plassere regioner på forskjellige servere for å oppnå høyere ytelse. Men til tross for at denne uttalelsen er åpenbar, vil vi senere se at dette ikke fungerer i alle tilfeller.

Etter å ha plassert en oppføring i MemStore, returneres et svar til klienten om at oppføringen ble lagret. Imidlertid lagres den i virkeligheten bare i en buffer og kommer til disken først etter at en viss tid har gått eller når den er fylt med nye data.

Når du utfører "Slett"-operasjonen, slettes ikke data fysisk. De er ganske enkelt merket som slettet, og selve ødeleggelsen skjer i det øyeblikket den store kompaktfunksjonen kalles, som er beskrevet mer detaljert i avsnitt 7.

Filer i HFile-format akkumuleres i HDFS og fra tid til annen startes den mindre kompakte prosessen, som ganske enkelt slår sammen små filer til større uten å slette noe. Over tid blir dette et problem som først dukker opp ved lesing av data (vi kommer tilbake til dette litt senere).

I tillegg til lasteprosessen beskrevet ovenfor, er det en mye mer effektiv prosedyre, som kanskje er den sterkeste siden av denne databasen - BulkLoad. Det ligger i det faktum at vi uavhengig danner HFiles og legger dem på disk, noe som lar oss skalere perfekt og oppnå svært anstendige hastigheter. Faktisk er begrensningen her ikke HBase, men egenskapene til maskinvaren. Nedenfor er oppstartsresultatene på en klynge bestående av 16 RegionServers og 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråder), HBase versjon 1.2.0-cdh5.14.2.

Her kan du se at ved å øke antall partisjoner (regioner) i tabellen, samt Spark-utførere, får vi en økning i nedlastingshastighet. Hastigheten avhenger også av opptaksvolumet. Store blokker gir en økning i MB/sek, små blokker i antall innsatte poster per tidsenhet, alt annet likt.

Du kan også begynne å laste inn i to bord samtidig og få dobbel hastighet. Nedenfor kan du se at skriving av 10 KB blokker til to tabeller samtidig skjer med en hastighet på ca. 600 MB/sek i hver (totalt 1275 MB/sek), som sammenfaller med skrivehastigheten til en tabell 623 MB/sek (se nr. 11 ovenfor)

Men den andre kjøringen med rekorder på 50 KB viser at nedlastingshastigheten øker noe, noe som tyder på at den nærmer seg grenseverdiene. Samtidig må du huske på at det praktisk talt ikke er noen belastning opprettet på selve HBASE, alt som kreves av det er først å gi data fra hbase:meta, og etter å ha lagt hFiles, tilbakestill BlockCache-dataene og lagre MemStore buffer til disk, hvis den ikke er tom.

3. Lese data fra HBASE

Hvis vi antar at klienten allerede har all informasjon fra hbase:meta (se punkt 2), så går forespørselen direkte til RS hvor den nødvendige nøkkelen er lagret. Først utføres søket i MemCache. Uansett om det er data der eller ikke, utføres søket også i BlockCache-bufferen og om nødvendig i HFiles. Hvis data ble funnet i filen, plasseres den i BlockCache og vil bli returnert raskere ved neste forespørsel. Søking i HFile går relativt raskt takket være bruken av Bloom-filteret, dvs. etter å ha lest en liten mengde data, avgjør den umiddelbart om denne filen inneholder den nødvendige nøkkelen, og hvis ikke, går den videre til neste.

Etter å ha mottatt data fra disse tre kildene, genererer RS ​​et svar. Spesielt kan den overføre flere funnet versjoner av et objekt på en gang hvis klienten ba om versjonskontroll.

4. Databufring

MemStore- og BlockCache-bufferne opptar opptil 80 % av det tildelte RS-minnet på heapen (resten er reservert for RS-tjenesteoppgaver). Hvis den typiske bruksmodusen er slik at prosesser skriver og umiddelbart leser de samme dataene, er det fornuftig å redusere BlockCache og øke MemStore, fordi Når skriving av data ikke kommer inn i hurtigbufferen for lesing, vil BlockCache bli brukt sjeldnere. BlockCache-bufferen består av to deler: LruBlockCache (alltid on-heap) og BucketCache (vanligvis off-heap eller på en SSD). BucketCache bør brukes når det er mange leseforespørsler og de ikke passer inn i LruBlockCache, noe som fører til aktivt arbeid av Garbage Collector. Samtidig bør du ikke forvente en radikal ytelsesøkning ved å bruke lesebufferen, men vi kommer tilbake til dette i avsnitt 8

Det er én BlockCache for hele RS, og det er én MemStore for hvert bord (en for hver kolonnefamilie).

Som beskrevet i teorien, når du skriver, går ikke data inn i hurtigbufferen, og faktisk er slike parametere CACHE_DATA_ON_WRITE for tabellen og "Cache DATA ved skriving" for RS satt til usann. Men i praksis, hvis vi skriver data til MemStore, tømmer vi dem til disken (og sletter dem), og sletter deretter den resulterende filen, og ved å utføre en get-forespørsel vil vi motta dataene. Dessuten, selv om du deaktiverer BlockCache fullstendig og fyller tabellen med nye data, og deretter tilbakestiller MemStore til disk, sletter dem og ber om dem fra en annen økt, vil de fortsatt bli hentet fra et sted. Så HBase lagrer ikke bare 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 on Read" er satt til false. Hvis du har noen ideer, velkommen til å diskutere det i kommentarene.

5. Batchdatabehandling MultiGet/MultiPut

Å behandle enkeltforespørsler (Get/Put/Delete) er en ganske kostbar operasjon, så hvis mulig bør du kombinere dem til en liste eller liste, som lar deg få et betydelig ytelsesløft. Dette gjelder spesielt for skriveoperasjonen, men ved lesing er det følgende fallgruve. Grafen nedenfor viser tiden for å lese 50 000 poster fra MemStore. Avlesningen ble utført i én tråd og den horisontale aksen viser antall nøkler i forespørselen. Her kan du se at når du øker til tusen nøkler i en forespørsel, synker utførelsestiden, dvs. hastigheten øker. Men med MSLAB-modus aktivert som standard, etter denne terskelen begynner et radikalt fall i ytelsen, og jo større datamengde i posten, desto lengre blir driftstiden.

Tester ble utført på en virtuell maskin, 8 kjerner, versjon HBase 2.0.0-cdh6.0.0-beta1.

MSLAB-modusen er designet for å redusere heap-fragmentering, som oppstår på grunn av blanding av nye og gamle generasjonsdata. Som en løsning, når MSLAB er aktivert, blir dataene plassert i relativt små celler (biter) og behandlet i biter. Som et resultat, når volumet i den forespurte datapakken overstiger den tildelte størrelsen, synker ytelsen kraftig. På den annen side er det heller ikke tilrådelig å slå av denne modusen, siden det vil føre til stopp på grunn av GC i øyeblikk med intensiv databehandling. En god løsning er å øke cellevolumet ved aktiv skriving via put samtidig med lesing. Det er verdt å merke seg at problemet ikke oppstår hvis du etter opptak kjører flush-kommandoen, som tilbakestiller MemStore til disk, eller hvis du laster med BulkLoad. Tabellen nedenfor viser at forespørsler fra MemStore for større (og samme mengde) data resulterer i nedganger. Men ved å øke chunksize, returnerer vi behandlingstiden til det normale.

I tillegg til å øke bitstørrelsen, hjelper det å dele dataene etter region, dvs. borddeling. Dette resulterer i at færre forespørsler kommer til hver region, og hvis de passer inn i en celle, forblir responsen god.

6. Strategi for å dele tabeller i regioner (deling)

Siden HBase er en nøkkelverdilagring og partisjonering utføres av nøkkel, er det ekstremt viktig å dele dataene jevnt på tvers av alle regioner. For eksempel vil partisjonering av en slik tabell i tre deler resultere i at dataene blir delt inn i tre regioner:

Det hender at dette fører til en kraftig nedgang hvis dataene som lastes inn senere ser ut som for eksempel lange verdier, de fleste starter med samme siffer, for eksempel:

1000001
1000002
...
1100003

Siden nøklene er lagret som en byte-array, vil de alle starte på samme måte og tilhøre samme region #1 som lagrer denne rekkevidden av nøkler. Det er flere partisjoneringsstrategier:

HexStringSplit – Gjør om nøkkelen til en heksadesimal kodet streng i området "00000000" => "FFFFFFFF" og utfylling til venstre med nuller.

UniformSplit – Gjør om nøkkelen til en byte-array med heksadesimal koding i området "00" => "FF" og utfylling til høyre med nuller.

I tillegg kan du spesifisere et hvilket som helst område eller sett med nøkler for deling og konfigurere automatisk deling. En av de enkleste og mest effektive tilnærmingene er imidlertid UniformSplit og bruk av hash-sammenkobling, for eksempel det viktigste paret med byte fra å kjøre nøkkelen gjennom funksjonen CRC32(radtast) og selve radtasten:

hash + radtast

Da vil alle data fordeles jevnt på tvers av regioner. Ved lesing blir de to første bytene ganske enkelt forkastet og den opprinnelige nøkkelen forblir. RS kontrollerer også mengden data og nøkler i regionen, og hvis grensene overskrides, deler den automatisk opp i deler.

7. Feiltoleranse og datalokalitet

Siden bare én region er ansvarlig for hvert sett med nøkler, er løsningen på problemer knyttet til RS-krasj eller dekommisjonering å lagre alle nødvendige data i HDFS. Når RS faller, oppdager masteren dette gjennom fraværet av et hjerteslag på ZooKeeper-noden. Deretter tildeler den den serverte regionen til en annen RS og siden hFilene er lagret i et distribuert filsystem, leser den nye eieren dem og fortsetter å betjene dataene. Men siden noen av dataene kan være i MemStore og ikke hadde tid til å komme inn i HFiles, brukes WAL, som også er lagret i HDFS, til å gjenopprette operasjonshistorikken. Etter at endringene er tatt i bruk, er RS ​​i stand til å svare på forespørsler, men flyttingen fører til at noen av dataene og prosessene som betjener dem havner på forskjellige noder, dvs. lokaliteten minker.

Løsningen på problemet er stor komprimering - denne prosedyren flytter filer til de nodene som er ansvarlige for dem (hvor regionene deres er plassert), som et resultat av at belastningen på nettverket og diskene øker kraftig under denne prosedyren. Men i fremtiden blir tilgangen til data merkbart akselerert. I tillegg utfører major_compaction sammenslåing av alle HFiles til én fil innenfor en region, og rydder også opp data avhengig av tabellinnstillingene. Du kan for eksempel spesifisere antall versjoner av et objekt som må beholdes eller levetiden som objektet fysisk slettes etter.

Denne prosedyren kan ha en svært positiv effekt på driften av HBase. Bildet nedenfor viser hvordan ytelsen ble forringet som følge av aktiv dataregistrering. Her kan du se hvordan 40 tråder skrev til en tabell og 40 tråder leste data samtidig. Skrivetråder genererer flere og flere HFiler, som leses av andre tråder. Som et resultat må mer og mer data fjernes fra minnet og til slutt begynner GC å fungere, noe som praktisk talt lammer alt arbeid. Lanseringen av større komprimering førte til fjerning av det resulterende rusk og gjenoppretting av produktivitet.

Testen ble utført på 3 DataNodes og 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråder). HBase versjon 1.2.0-cdh5.14.2

Det er verdt å merke seg at større komprimering ble lansert på en "live" tabell, der data aktivt ble skrevet og lest. Det var en uttalelse på nettet om at dette kunne føre til feil respons ved lesing av data. For å sjekke ble det startet en prosess som genererte nye data og skrev dem til en tabell. Deretter leste jeg umiddelbart og sjekket om den resulterende verdien falt sammen med det som ble skrevet ned. Mens denne prosessen pågikk, ble større komprimering kjørt rundt 200 ganger og ikke en eneste feil ble registrert. Kanskje oppstår problemet sjelden og bare under høy belastning, så det er tryggere å stoppe skrive- og leseprosessene som planlagt og utføre rengjøring for å forhindre slike GC-nedtrekk.

Stor komprimering påvirker heller ikke statusen til MemStore; for å tømme den til disk og komprimere den, må du bruke flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Innstillinger og ytelse

Som allerede nevnt viser HBase sin største suksess der den ikke trenger å gjøre noe, når den kjører BulkLoad. Dette gjelder imidlertid de fleste systemer og mennesker. Imidlertid er dette verktøyet mer egnet for å lagre data i bulk i store blokker, mens hvis prosessen krever flere konkurrerende lese- og skriveforespørsler, brukes Get og Put-kommandoene beskrevet ovenfor. For å bestemme de optimale parameterne ble lanseringer utført med ulike kombinasjoner av tabellparametere og innstillinger:

• 10 tråder ble lansert samtidig 3 ganger på rad (la oss kalle dette en trådblokk).
• Driftstiden for alle tråder i en blokk ble beregnet som gjennomsnitt og var det endelige resultatet av blokkens operasjon.
• Alle trådene fungerte med samme tabell.
• Før hver start av gjengeblokken ble det utført en større komprimering.
• Hver blokk utførte bare én av følgende operasjoner:

-Sette
-Få
—Get+Put

• Hver blokk utførte 50 000 iterasjoner av operasjonen.
• Blokkstørrelsen til en post er 100 byte, 1000 byte eller 10000 byte (tilfeldig).
• Blokker ble lansert med forskjellige antall forespurte nøkler (enten én nøkkel eller 10).
• Blokkene ble kjørt under forskjellige bordsettinger. Parametre endret:

— BlockCache = slått på eller av
— BlockSize = 65 KB eller 16 KB
— Partisjoner = 1, 5 eller 30
— MSLAB = aktivert eller deaktivert

Så blokken ser slik ut:

en. MSLAB-modus ble slått på/av.
b. En tabell ble opprettet som følgende parametere ble satt for: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Komprimering ble satt til GZ.
d. 10 tråder ble lansert samtidig som gjorde 1/10 put/get/get+put operasjoner i denne tabellen med poster på 100/1000/10000 byte, og utførte 50 000 spørringer på rad (tilfeldige nøkler).
e. Punkt d ble gjentatt tre ganger.
f. Driftstiden for alle tråder ble beregnet som gjennomsnitt.

Alle mulige kombinasjoner ble testet. Det er forutsigbart at hastigheten vil synke når poststørrelsen øker, eller at deaktivering av caching vil føre til nedgang. Målet var imidlertid å forstå graden og signifikansen av påvirkningen av hver parameter, så de innsamlede dataene ble matet inn i input til en lineær regresjonsfunksjon, som gjør det mulig å vurdere signifikansen ved hjelp av t-statistikk. Nedenfor er resultatene av blokkene som utfører Put-operasjoner. Komplett sett med kombinasjoner 2*2*3*2*3 = 144 alternativer + 72 tk. noen ble gjort to ganger. Derfor er det 216 løp totalt:

Testing ble utført på en mini-klynge bestående av 3 DataNodes og 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 tråder). HBase versjon 1.2.0-cdh5.14.2.

Den høyeste innsettingshastigheten på 3.7 sekunder ble oppnådd med MSLAB-modus slått av, på et bord med én partisjon, med BlockCache aktivert, BlockSize = 16, poster på 100 byte, 10 stykker per pakke.
Den laveste innsettingshastigheten på 82.8 sek ble oppnådd med MSLAB-modus aktivert, på en tabell med én partisjon, med BlockCache aktivert, BlockSize = 16, poster på 10000 1 byte, XNUMX hver.

La oss nå se på modellen. Vi ser den gode kvaliteten på modellen basert på R2, men det er helt klart at ekstrapolering er kontraindisert her. Den faktiske oppførselen til systemet når parametere endres vil ikke være lineær; denne modellen er ikke nødvendig for spådommer, men for å forstå hva som skjedde innenfor de gitte parameterne. For eksempel, her ser vi fra studentens kriterium at BlockSize- og BlockCache-parametrene ikke betyr noe for Put-operasjonen (som generelt er ganske forutsigbar):

Men det faktum at å øke antall partisjoner fører til en reduksjon i ytelse er noe uventet (vi har allerede sett den positive effekten av å øke antall partisjoner med BulkLoad), selv om det er forståelig. For det første, for behandling, må du generere forespørsler til 30 regioner i stedet for én, og datavolumet er ikke slik at dette vil gi en gevinst. For det andre bestemmes den totale driftstiden av den tregeste RS, og siden antallet DataNodes er mindre enn antall RS, har noen regioner null lokalitet. Vel, la oss se på de fem beste:

La oss nå evaluere resultatene av å utføre Get-blokker:

Antall partisjoner har mistet betydning, noe som sannsynligvis forklares med at dataene er godt bufret og lesebufferen er den mest signifikante (statistisk) parameteren. Å øke antall meldinger i en forespørsel er naturligvis også veldig nyttig for ytelsen. Toppscore:

Vel, til slutt, la oss se på modellen av blokken som først utførte get og deretter satt:

Alle parametere er viktige her. Og resultatene til lederne:

9. Lasttesting

Vel, endelig lanserer vi en mer eller mindre anstendig last, men det er alltid mer interessant når du har noe å sammenligne med. På nettstedet til DataStax, nøkkelutvikleren av Cassandra, er det funn NT av en rekke NoSQL-lagringer, inkludert HBase versjon 0.98.6-1. Lasting ble utført av 40 tråder, datastørrelse 100 byte, SSD-disker. Resultatet av testing av Read-Modify-Write-operasjonene viste følgende resultater.

Så vidt jeg forstår ble lesingen utført i blokker med 100 poster og for 16 HBase-noder viste DataStax-testen en ytelse på 10 tusen operasjoner per sekund.

Det er heldig at klyngen vår også har 16 noder, men det er ikke særlig "heldig" at hver har 64 kjerner (tråder), mens det i DataStax-testen kun er 4. På den annen side har de SSD-stasjoner, mens vi har HDD-er eller mer økte den nye versjonen av HBase og CPU-utnyttelsen under belastning praktisk talt ikke nevneverdig (visuelt med 5-10 prosent). La oss imidlertid prøve å begynne å bruke denne konfigurasjonen. Standard tabellinnstillinger, lesing utføres i nøkkelområdet fra 0 til 50 millioner tilfeldig (dvs. i hovedsak nytt hver gang). Tabellen inneholder 50 millioner poster, fordelt på 64 partisjoner. Nøklene hashes ved hjelp av crc32. Tabellinnstillinger er standard, MSLAB er aktivert. Ved å starte 40 tråder, leser hver tråd et sett med 100 tilfeldige nøkler og skriver umiddelbart de genererte 100 bytene tilbake til disse nøklene.

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

Gjennomsnittsresultatet er nærmere 40 tusen operasjoner per sekund, noe som er betydelig bedre enn i DataStax-testen. For eksperimentelle formål kan du imidlertid endre forholdene litt. Det er ganske usannsynlig at alt arbeid vil bli utført utelukkende på ett bord, og også bare på unike nøkler. La oss anta at det er et visst "varmt" sett med nøkler som genererer hovedbelastningen. La oss derfor prøve å lage en belastning med større poster (10 KB), også i batcher på 100, i 4 forskjellige tabeller og begrense utvalget av forespurte nøkler til 50 40. Grafen nedenfor viser lanseringen av 100 tråder, hver tråd leser et sett med 10 nøkler og skriver umiddelbart tilfeldig XNUMX KB på disse nøklene tilbake.

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

Under belastningen ble det satt i gang større komprimering flere ganger, som vist ovenfor, uten denne prosedyren vil ytelsen gradvis forringes, men det oppstår også ekstra belastning under utførelse. Drawdowns er forårsaket av ulike årsaker. Noen ganger sluttet trådene å virke og det ble en pause mens de ble startet på nytt, noen ganger skapte tredjepartsapplikasjoner en belastning på klyngen.

Lesing og umiddelbart skriving er et av de vanskeligste arbeidsscenarioene for HBase. Hvis du bare lager små put-forespørsler, for eksempel 100 byte, og kombinerer dem til pakker på 10-50 tusen stykker, kan du få hundretusenvis av operasjoner per sekund, og situasjonen er lik med skrivebeskyttede forespørsler. Det er verdt å merke seg at resultatene er radikalt bedre enn de oppnådd av DataStax, mest av alt på grunn av forespørsler i blokker på 50 tusen.

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

10. Konklusjoner

Dette systemet er ganske fleksibelt konfigurert, men påvirkningen av et stort antall parametere er fortsatt ukjent. Noen av dem ble testet, men ble ikke inkludert i det resulterende testsettet. For eksempel viste foreløpige eksperimenter ubetydelig betydning av en slik parameter som DATA_BLOCK_ENCODING, som koder informasjon ved hjelp av verdier fra naboceller, noe som er forståelig for tilfeldig genererte data. Hvis du bruker et stort antall dupliserte objekter, kan gevinsten bli betydelig. Generelt kan vi si at HBase gir inntrykk av en ganske seriøs og gjennomtenkt database, som kan være ganske produktiv når man utfører operasjoner med store datablokker. Spesielt hvis det er mulig å skille lese- og skriveprosessene i tid.

Hvis det er noe etter din mening som ikke er avslørt nok, er jeg klar til å fortelle deg mer detaljert. Vi inviterer deg til å dele din erfaring eller diskutere hvis du er uenig i noe.

Kilde: www.habr.com