HBase Architecture: HBase Data Model & HBase Read / Write Mechanism



Denne bloggen på HBase Architecture forklarer HBase Data Model & gir innsikt i HBase Architecture. Det forklarer også forskjellige mekanismer i HBase.

HBase Arkitektur

I min forrige blogg på HBase-veiledning , Jeg forklarte hva som er HBase og dets funksjoner. Jeg nevnte også Facebook messenger's case study for å hjelpe deg med å koble deg bedre. Nå videre i vår , Jeg vil forklare deg datamodellen til HBase og HBase Architecture.Før du går videre, bør du også vite at HBase er et viktig konsept som utgjør en integrert del av for Big Data Hadoop-sertifisering.

De viktige emnene jeg skal ta deg gjennom i denne HBase-arkitekturbloggen er:





La oss først forstå datamodellen til HBase. Det hjelper HBase med raskere lese / skrive og søk.



HBase Architecture: HBase Data Model

Som vi vet er HBase en kolonneorientert NoSQL-database. Selv om det ser ut som en relasjonsdatabase som inneholder rader og kolonner, men det er ikke en relasjonsdatabase. Relasjonsdatabaser er radorienterte mens HBase er kolonneorientert. Så la oss først forstå forskjellen mellom kolonneorienterte og radorienterte databaser:

Radorienterte vs kolonneorienterte databaser:

  • Radorienterte databaser lagrer tabellposter i en sekvens av rader. Mens kolonneorienterte databaserlagre tabellposter i en sekvens av kolonner, dvs. oppføringene i en kolonne lagres sammenhengende steder på disker.

For å forstå det bedre, la oss ta et eksempel og vurdere tabellen nedenfor.



Tabell - HBase-arkitektur - Edureka

Hvis denne tabellen er lagret i en rekkeorientert database. Den lagrer postene som vist nedenfor:

en,Paul Walker,OSS,231,Galant,

2, Vin Diesel,Brasil,520,Mustang

I radorienterte databaser lagres data på grunnlag av rader eller tupler som du kan se ovenfor.

Mens de kolonneorienterte databasene lagrer disse dataene som:

system.exit (1) java

en,2, Paul Walker,Vin Diesel, OSS,Brasil, 231,520, Galant,Mustang

I en kolonneorientert database lagres alle kolonneverdiene sammen, slik at første kolonneverdier blir lagret sammen, deretter lagres de andre kolonneverdiene sammen og data i andre kolonner lagres på lignende måte.

  • Når datamengden er veldig stor, som når det gjelder petabyte eller exabyte, bruker vi kolonneorientert tilnærming, fordi dataene til en enkelt kolonne lagres sammen og kan nås raskere.
  • Mens radorientert tilnærming forholdsvis håndterer mindre antall rader og kolonner effektivt, da radorientert database lagrer data er et strukturert format.
  • Når vi trenger å behandle og analysere et stort sett med semistrukturerte eller ustrukturerte data, bruker vi kolonneorientert tilnærming. Slik som applikasjoner som håndterer Online analytisk behandling som data mining, datalagring, applikasjoner inkludert analyser, etc.
  • Mens, Online transaksjonsbehandling som bank- og finansdomener som håndterer strukturerte data og krever transaksjonsegenskaper (ACID-egenskaper), bruker radorientert tilnærming.

HBase-tabeller har følgende komponenter, vist på bildet nedenfor:

  • Tabeller : Data lagres i tabellformat i HBase. Men her er tabeller i kolonneorientert format.
  • Rad Nøkkel : Radnøkler brukes til å søke i poster som gjør søk raskt. Du ville være nysgjerrig på å vite hvordan? Jeg vil forklare det i arkitekturdelen som går videre i denne bloggen.
  • Kolonne Familier : Ulike kolonner kombineres i en kolonnefamilie. Disse kolonnefamiliene lagres sammen, noe som gjør søkeprosessen raskere fordi data som tilhører samme kolonnefamilie, kan nås sammen i ett enkelt søk.
  • Kolonne Kvalifiseringer : Navnet på hver kolonne er kjent som kolonnekvalifiseringen.
  • Celle : Data lagres i celler. Dataene blir dumpet i celler som er spesifikt identifisert av radnøkkel og kolonnekvalifiserende.
  • Tidsstempel : Tidsstempel er en kombinasjon av dato og klokkeslett. Hver gang data lagres, lagres de med tidsstempelet. Dette gjør det enkelt å søke etter en bestemt versjon av data.

På en mer enkel og forståelsesfull måte kan vi si at HBase består av:

  • Sett med bord
  • Hver tabell med kolonnefamilier og rader
  • Radnøkkel fungerer som en primærnøkkel i HBase.
  • All tilgang til HBase-tabeller bruker denne primære nøkkelen
  • Hver kolonnekvalifikator som er til stede i HBase, betegner attributt som tilsvarer objektet som ligger i cellen.

Nå som du vet om HBase Data Model, la oss se hvordan denne datamodellen faller i tråd med HBase Architecture og gjør den egnet for stor lagring og raskere behandling.

HBase Architecture: Komponenter av HBase Architecture

HBase har tre hovedkomponenter, dvs. HMaster Server , HBase Region Server, Regioner og Dyrepasser .

Figuren nedenfor forklarer hierarkiet til HBase Architecture. Vi vil snakke om hver enkelt av dem individuelt.


Nå før vi går til HMaster, vil vi forstå regioner da alle disse serverne (HMaster, Region Server, Zookeeper) er plassert for å koordinere og administrere regioner og utføre forskjellige operasjoner i regionene. Så du ville være nysgjerrig på å vite hva som er regioner og hvorfor er de så viktige?

HBase Arkitektur: Region

En region inneholder alle radene mellom startnøkkelen og sluttnøkkelen som er tilordnet regionen. HBase-tabeller kan deles inn i et antall regioner på en slik måte at alle kolonnene i en kolonnefamilie er lagret i en region. Hver region inneholder radene i en sortert rekkefølge.

Mange regioner er tildelt en Region Server , som er ansvarlig for å håndtere, administrere, utføre lese- og skriveoperasjoner på det settet med regioner.

Så, avslutter på en enklere måte:

  • En tabell kan deles inn i en rekke regioner. En region er et sortert utvalg av rader som lagrer data mellom en startnøkkel og en sluttnøkkel.
  • En region har en standardstørrelse på 256 MB som kan konfigureres etter behov.
  • En gruppe regioner serveres til klientene av en regionserver.
  • En regionserver kan betjene omtrent 1000 regioner til klienten.

Nå fra toppen av hierarkiet, vil jeg først forklare deg om HMaster Server som fungerer på samme måte som en NameNode i HDFS . Så når jeg beveger meg ned i hierarkiet, tar jeg deg gjennom ZooKeeper og Region Server.

HBase Arkitektur: HMaster

Som i bildet nedenfor, kan du se HMaster håndterer en samling av Region Server som ligger på DataNode. La oss forstå hvordan HMaster gjør det.

  • HBase HMaster utfører DDL-operasjoner (opprett og slett tabeller) og tildeler regioner til Region-serverne som du kan se i bildet ovenfor.
  • Den koordinerer og administrerer regionserveren (på samme måte som NameNode administrerer DataNode i HDFS).
  • Den tildeler regioner til Region-serverne ved oppstart og tilordner regioner til Region-servere på nytt under gjenoppretting og lastbalansering.
  • Den overvåker alle Region Server-forekomster i klyngen (ved hjelp av Zookeeper) og utfører gjenopprettingsaktiviteter når noen Region Server er nede.
  • Det gir et grensesnitt for å lage, slette og oppdatere tabeller.

HBase har et distribuert og stort miljø der HMaster alene ikke er tilstrekkelig til å klare alt. Så du lurer på hva som hjelper HMaster med å håndtere dette enorme miljøet? Det er der ZooKeeper kommer inn i bildet. Etter at vi forsto hvordan HMaster administrerer HBase-miljø, vil vi forstå hvordan Zookeeper hjelper HMaster med å administrere miljøet.

HBase Arkitektur: ZooKeeper - Koordinatoren

Dette bildet nedenfor forklarer ZooKeepers koordineringsmekanisme.

  • Zookeeper fungerer som en koordinator i HBase-distribuerte miljø. Det hjelper med å opprettholde servertilstand inne i klyngen ved å kommunisere gjennom økter.
  • Hver regionserver sammen med HMaster Server sender kontinuerlig hjerterytme med jevne mellomrom til Zookeeper, og den sjekker hvilken server som er i live og tilgjengelig som nevnt i bildet ovenfor. Det gir også varslinger om serverfeil, slik at gjenopprettingstiltak kan utføres.
  • Med henvisning fra ovenstående bilde kan du se, det er en inaktiv server, som fungerer som en sikkerhetskopi for aktiv server. Hvis den aktive serveren mislykkes, kommer den til redning.
  • Den aktive HMaster sender hjerterytme til Zookeeper mens den inaktive HMaster lytter til varselet som sendes av aktiv HMaster. Hvis den aktive HMaster ikke sender hjerterytme, økes økten og den inaktive HMaster blir aktiv.
  • Mens en regionserver ikke klarer å sende hjerterytme, er økten utløpt, og alle lyttere får beskjed om det. Deretter utfører HMaster egnede gjenopprettingshandlinger som vi vil diskutere senere i denne bloggen.
  • Zookeeper opprettholder også .META Server-banen, som hjelper enhver klient med å søke etter hvilken som helst region. Klienten må først sjekke med .META Server hvor Region Server en region tilhører, og den får banen til den Region Server.

Når jeg snakket om .META Server, la meg først forklare deg hva som er .META-server? Så du kan enkelt relatere arbeidet til ZooKeeper og .META Server sammen. Senere, når jeg vil forklare deg HBase-søkemekanismen i denne bloggen, vil jeg forklare hvordan disse to fungerer i samarbeid.

HBase Arkitektur: Metatabell

  • META-tabellen er en spesiell HBase-katalogtabell. Den opprettholder en liste over alle regionens servere i HBase-lagringssystemet, som du kan se på bildet ovenfor.
  • Ser på figuren du kan se, .META filen vedlikeholder tabellen i form av nøkler og verdier. Nøkkel representerer startnøkkelen til regionen og dens id, mens verdien inneholder banen til Region Server.

aktiv og passiv transformasjon i informatica

Som jeg allerede har diskutert, har vi nå beveget oss nedover i hierarkiet, og jeg vil fokusere på komponenten av regionen og deres funksjoner mens jeg forklarte deg. Senere vil jeg diskutere mekanismen for å søke, lese, skrive og forstå hvordan alle disse komponentene fungerer sammen.

HBase Arkitektur: Komponenter av Region Server

Dette bildet nedenfor viser komponentene til en regionserver. Nå skal jeg diskutere dem hver for seg.

En regionserver opprettholder forskjellige regioner som kjører på toppen av . Komponentene til en regionserver er:

  • WAL: Som du kan konkludere med fra ovenstående bilde, er WAL (Write Ahead Log) en fil som er knyttet til hver regionserver i det distribuerte miljøet. WAL lagrer de nye dataene som ikke er vedvarende eller forpliktet til permanent lagring. Den brukes i tilfelle manglende gjenoppretting av datasettene.
  • Blokker cache: Fra bildet ovenfor er det tydelig at Block Cache ligger øverst på Region Server. Den lagrer ofte leste data i minnet. Hvis dataene i BlockCache er nylig brukt, blir disse dataene fjernet fra BlockCache.
  • MemStore: Det er skrivebufferen. Den lagrer alle innkommende data før den overføres til disken eller permanent minne. Det er en MemStore for hver kolonnefamilie i en region. Som du kan se på bildet, er det flere MemStores for en region fordi hver region inneholder flere kolonnefamilier. Dataene sorteres i leksikografisk rekkefølge før de overføres til disken.
  • HFil: Fra figuren ovenfor kan du se at HFile er lagret på HDFS. Dermed lagrer den de faktiske cellene på disken. MemStore forplikter dataene til HFile når størrelsen på MemStore overstiger.

Nå som vi kjenner hoved- og mindre komponenter i HBase Architecture, vil jeg forklare mekanismen og deres samarbeidsinnsats i dette. Uansett om det er å lese eller skrive, må vi først søke hvor vi skal lese eller hvor vi skal skrive en fil. Så la oss forstå denne søkeprosessen, da dette er en av mekanismene som gjør HBase veldig populær.

HBase Arkitektur: Hvordan søk initialiseres i HBase?

Som du vet lagrer Zookeeper META-tabellplasseringen. Når en klient nærmer seg med en lese eller skriver forespørsler til HBase, skjer følgende operasjon:

  1. Klienten henter plasseringen av META-tabellen fra ZooKeeper.
  2. Klienten ber deretter om plasseringen av Region Server for tilsvarende radnøkkel fra META-tabellen for å få tilgang til den. Klienten cacher denne informasjonen med plasseringen av META-tabellen.
  3. Deretter vil den få radplasseringen ved å be om fra den aktuelle Region Server.

For fremtidige referanser bruker klienten cachen sin til å hente plasseringen til META-tabellen og tidligere lest radnøkkelen til Region Server. Da vil ikke klienten henvise til META-tabellen, før og med mindre det er en glipp fordi regionen er forskjøvet eller flyttet. Deretter vil den igjen be om til META-serveren og oppdatere hurtigbufferen.

Som hver gang kaster ikke klienter bort tid på å hente plasseringen til Region Server fra META Server. Dette sparer tid og gjør søkeprosessen raskere. La meg fortelle deg hvordan skriving foregår i HBase. Hva er komponentene involvert i det, og hvordan er de involvert?

HBase Arkitektur: HBase Skriv Mekanisme

Dette bildet nedenfor forklarer skrivemekanismen i HBase.

Skrivemekanismen går gjennom følgende prosess sekvensielt (se bildet ovenfor):

Trinn 1: Hver gang klienten har en skriveforespørsel, skriver klienten dataene til WAL (Write Ahead Log).

  • Endringene legges til på slutten av WAL-filen.
  • Denne WAL-filen vedlikeholdes i hver Region Server og Region Server bruker den til å gjenopprette data som ikke er forpliktet til disken.

Steg 2: Når data er skrevet til WAL, blir de kopiert til MemStore.

Trinn 3: Når dataene er plassert i MemStore, mottar klienten bekreftelsen.

Trinn 4: Når MemStore når terskelen, dumper den eller forplikter dataene til en HFile.

La oss nå ta et dypdykk og forstå hvordan MemStore bidrar i skriveprosessen, og hva er dens funksjoner?

konverter streng til dato java

HBase Skriv Mekanisme- MemStore

  • MemStore oppdaterer alltid dataene som er lagret i den, i en leksikografisk rekkefølge (sekvensielt ordboksmessig) som sorterte KeyValues. Det er en MemStore for hver kolonnefamilie, og dermed lagres oppdateringene sortert for hver kolonnefamilie.
  • Når MemStore når terskelen, dumper den alle dataene til en ny HFile på en sortert måte. Denne HFilen er lagret i HDFS. HBase inneholder flere HFiles for hver kolonnefamilie.
  • Over tid vokser antall HFile når MemStore dumper dataene.
  • MemStore lagrer også det siste skrevne sekvensnummeret, så Master Server og MemStore vet begge at hva som er begått så langt og hvor du skal starte fra. Når region starter, leses det siste sekvensnummeret, og fra det nummeret begynner nye redigeringer.

Som jeg diskuterte flere ganger, er HFile den viktigste vedvarende lagringen i en HBase-arkitektur. Endelig er alle dataene forpliktet til HFile, som er permanent lagring av HBase. La oss derfor se på egenskapene til HFile som gjør det raskere for søk mens du leser og skriver.

HBase Arkitektur: HBase Skriv Mekanisme- HFil

  • Skriftene plasseres sekvensielt på disken. Derfor er bevegelsen av diskens lese-skrivehode veldig mindre. Dette gjør skrive- og søkemekanismen veldig rask.
  • HFile-indeksene lastes inn i minnet hver gang en HFile åpnes. Dette hjelper deg med å finne en plate i et enkelt søk.
  • Tilhengeren er en peker som peker mot HFiles metakloss. Det er skrevet på slutten av den forpliktede filen. Den inneholder informasjon om tidsstempel og blomstringsfiltre.
  • Bloom Filter hjelper deg med å søke på nøkkelverdipar, den hopper over filen som ikke inneholder den nødvendige radetasten. Tidsstempel hjelper også med å søke i en versjon av filen, det hjelper med å hoppe over dataene.

Etter å ha kjent skrivemekanismen og rollen til ulike komponenter i å gjøre skrive og søke raskere. Jeg skal forklare deg hvordan lesemekanismen fungerer i en HBase-arkitektur? Deretter vil vi gå til mekanismene som øker HBase-ytelse som komprimering, regiondeling og utvinning.

HBase Arkitektur: Les Mekanisme

Som diskutert i søkemekanismen, henter klienten først plasseringen til Region Server fra .META Server hvis klienten ikke har den i hurtigbufferminnet. Deretter går det gjennom de påfølgende trinnene som følger:

  • For å lese dataene ser skanneren først etter radcellen i blokkbufferen. Her lagres alle nylig leste nøkkelverdipar.
  • Hvis skanneren ikke finner det nødvendige resultatet, flyttes det til MemStore, ettersom vi vet at dette er skrivebufferminnet. Der søker den etter de sist skrevne filene, som ikke har blitt dumpet ennå i HFile.
  • Til slutt vil den bruke blomstringsfiltre og blokkere cache for å laste inn data fra HFile.

Så langt har jeg diskutert søke-, lese- og skrivemekanismen til HBase. Nå skal vi se på HBase-mekanismen som gjør søk, lese og skrive raskt i HBase. Først vil vi forstå Komprimering , som er en av disse mekanismene.

HBase Arkitektur: Komprimering

HBase kombinerer HFiles for å redusere lagring og redusere antallet disksøk som trengs for en lesing. Denne prosessen kalles komprimering . Komprimering velger noen HFiler fra en region og kombinerer dem. Det er to typer komprimering som du kan se i bildet ovenfor.

  1. Mindre komprimering : HBase velger automatisk mindre HFiles og gir dem til større HFiles som vist på bildet ovenfor. Dette kalles Mindre komprimering. Den utfører flettesortering for å forplikte mindre HFiles til større HFiles. Dette hjelper til med optimalisering av lagringsplass.
  2. Stor komprimering: Som illustrert i bildet ovenfor, i Major komprimering, fusjonerer HBase og tildeler de mindre HFiles i en region på nytt til en ny HFile. I denne prosessen plasseres de samme kolonnefamiliene sammen i den nye HFile. Det slipper slettet og utløpt celle i denne prosessen. Det øker leseytelsen.

Men under denne prosessen kan inngangsutgangsdisker og nettverkstrafikk bli overbelastet. Dette er kjent som skrive forsterkning . Så det er vanligvis planlagt under lave toppbelastningstider.

Nå er en annen ytelsesoptimaliseringsprosess som jeg vil diskutere Region Split . Dette er veldig viktig for lastbalansering.

HBase Arkitektur: Region Split

Figuren nedenfor illustrerer Region Split-mekanismen.

Når en region blir stor, er den delt inn i to underregioner, som vist i figuren ovenfor. Hver region representerer nøyaktig halvparten av foreldreregionen. Deretter rapporteres denne splittelsen til HMaster. Dette håndteres av samme Region Server til HMaster tildeler dem til en ny Region Server for lastbalansering.

Flytter ned linjen, sist men ikke minst, vil jeg forklare deg hvordan gjenoppretter HBase data etter en feil. Som vi vet det Feilgjenoppretting er en veldig viktig funksjon i HBase, og la oss få vite hvordan HBase gjenoppretter data etter en feil.

HBase Arkitektur: HBase Crash and Data Recovery

  • Når en regionserver mislykkes, varsler ZooKeeper HMaster om feilen.
  • Deretter distribuerer og tildeler HMaster regionene til krasjregionsserveren til mange aktive regionservere. For å gjenopprette dataene fra MemStore for den mislykkede regionserveren, distribuerer HMaster WAL til alle regionserverne.
  • Hver regionserver kjører WAL på nytt for å bygge MemStore for den mislykkede regionens kolonnefamilie.
  • Dataene er skrevet i kronologisk rekkefølge (i rett tid) i WAL. Derfor, på nytt å utføre den WAL, betyr å gjøre all endringen som ble gjort og lagret i MemStore-filen.
  • Så etter at alle regionserverne har utført WAL, gjenopprettes MemStore-data for alle kolonnefamilier.

Jeg håper denne bloggen ville ha hjulpet deg med å undervurdere HBase Data Model & HBase Architecture. Håper du likte det. Nå kan du forholde deg til funksjonene i HBase (som jeg forklarte i min forrige HBase-veiledning blogg) med HBase Architecture og forstå hvordan det fungerer internt. Nå som du kjenner den teoretiske delen av HBase, bør du gå til den praktiske delen. Med dette i bakhodet, vår neste blogg av vil forklare et utvalg HBase POC .

Nå som du har forstått HBase Architecture, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Edureka Big Data Hadoop-sertifiseringstreningskurs hjelper elever å bli eksperter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved å bruke sanntidsbruk på Retail, Social Media, Aviation, Tourism, Finance.

Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.