HBase-arkitektur: HBase-datamodel og HBase læse / skrive-mekanisme

HBase-arkitektur

I min tidligere blog på HBase-vejledning , Jeg forklarede, hvad der er HBase og dets funktioner. Jeg nævnte også Facebook messenger's case study for at hjælpe dig med at oprette forbindelse bedre. Nu går vi videre i vores , Jeg vil forklare dig datamodellen for HBase og HBase Architecture.Før du går videre, skal du også vide, at HBase er et vigtigt koncept, der udgør en integreret del af til Big Data Hadoop-certificering.

De vigtige emner, som jeg vil tage dig igennem i denne HBase-arkitekturblog, er:

• HBase-datamodel
• HBase Architecture and It's Components
• HBase-skrivemekanisme
• HBase-læsemekanisme
• HBase Performance Optimization Mechanisms

Lad os først forstå datamodellen for HBase. Det hjælper HBase med hurtigere læsning / skrivning og søgning.

HBase-arkitektur: HBase-datamodel

Som vi ved, er HBase en kolonneorienteret NoSQL-database. Selvom det ligner en relationsdatabase, der indeholder rækker og kolonner, men det er ikke en relationsdatabase. Relationsdatabaser er rækkeorienterede, mens HBase er kolonneorienterede. Så lad os først forstå forskellen mellem kolonneorienterede og rækkeorienterede databaser:

Rækkeorienterede vs søjleorienterede databaser:

• Rækkeorienterede databaser gemmer tabeloptegnelser i en række af rækker. Mens kolonneorienterede databasergemme tabeloptegnelser i en række kolonner, dvs. posterne i en kolonne lagres sammenhængende placeringer på diske.

For bedre at forstå det, lad os tage et eksempel og overveje nedenstående tabel.

Hvis denne tabel er gemt i en rækkeorienteret database. Det gemmer optegnelserne som vist nedenfor:

en,Paul Walker,OS,231,Galant,

2, Vin Diesel,Brasilien,520,Mustang

I rækkeorienterede databaser lagres data på basis af rækker eller tupler som du kan se ovenfor.

Mens de kolonneorienterede databaser gemmer disse data som:

en,2, Paul Walker,Vin Diesel, OS,Brasilien, 231,520, Galant,Mustang

I en søjleorienteret database lagres alle søjleværdierne sammen, ligesom de første søjleværdier vil blive gemt sammen, derefter lagres de anden søjleværdier sammen, og data i andre søjler gemmes på en lignende måde.

• Når datamængden er meget enorm, ligesom med hensyn til petabyte eller exabyte, bruger vi kolonneorienteret tilgang, fordi dataene i en enkelt kolonne er gemt sammen og kan tilgås hurtigere.
• Mens rækkeorienteret tilgang håndterer mindre antal rækker og kolonner effektivt, er rækkeorienteret database lagret data et struktureret format.
• Når vi har brug for at behandle og analysere et stort sæt semistrukturerede eller ustrukturerede data, bruger vi søjleorienteret tilgang. Såsom applikationer, der beskæftiger sig med Online analytisk behandling som data mining, data warehousing, applikationer inklusive analyser osv.
• Der henviser til, Online transaktionsbehandling såsom bank- og finansdomæner, der håndterer strukturerede data og kræver transaktionsegenskaber (ACID-egenskaber), bruger rækkeorienteret tilgang.

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

• Tabeller : Data gemmes i et tabelformat i HBase. Men her er tabeller i kolonneorienteret format.
• Række Nøgle : Radetaster bruges til at søge poster, der gør søgninger hurtigt. Du ville være nysgerrig efter at vide hvordan? Jeg vil forklare det i arkitekturdelen, der går videre i denne blog.
• Kolonne Familier : Forskellige kolonner kombineres i en kolonnefamilie. Disse kolonnefamilier gemmes sammen, hvilket gør søgningsprocessen hurtigere, fordi data, der tilhører samme kolonnefamilie, kan tilgås sammen i et enkelt søgning.
• Kolonne Kvalifikationer : Hver søjles navn er kendt som dens søjlekvalifikator.
• Celle : Data gemmes i celler. Dataene dumpes i celler, der specifikt identificeres ved hjælp af række- og kolonnekvalifikatorer.
• Tidsstempel : Tidsstempel er en kombination af dato og klokkeslæt. Hver gang data er gemt, gemmes det med dets tidsstempel. Dette gør det let at søge efter en bestemt version af data.

På en mere enkel og forståelig måde kan vi sige, at HBase består af:

• Sæt med borde
• Hver tabel med kolonnefamilier og rækker
• Rækketast fungerer som en primær nøgle i HBase.
• Enhver adgang til HBase-tabeller bruger denne primære nøgle
• Hver søjlekvalifikator, der er til stede i HBase, betegner attribut svarende til det objekt, der er i cellen.

Nu hvor du kender til HBase Data Model, så lad os se, hvordan denne datamodel falder i tråd med HBase Architecture og gør den velegnet til stor opbevaring og hurtigere behandling.

HBase Architecture: Komponenter af HBase Architecture

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

Nedenstående figur forklarer hierarkiet i HBase Architecture. Vi vil tale om hver enkelt af dem individuelt.

Nu inden vi går til HMaster, vil vi forstå regioner, da alle disse servere (HMaster, Region Server, Zookeeper) er placeret til at koordinere og administrere regioner og udføre forskellige operationer inden for regionerne. Så du ville være nysgerrig efter at vide, hvad der er regioner, og hvorfor er de så vigtige?

HBase-arkitektur: Område

En region indeholder alle rækkerne mellem starttasten og den endetast, der er tildelt den pågældende region. HBase-tabeller kan opdeles i et antal regioner på en sådan måde, at alle kolonnerne i en kolonnefamilie er gemt i en region. Hver region indeholder rækkerne i en sorteret rækkefølge.

Mange regioner er tildelt en Region Server , som er ansvarlig for håndtering, styring, udførelse af læsning og skrivning af operationer på det sæt regioner.

Så konkluderet på en enklere måde:

• En tabel kan opdeles i et antal regioner. En region er et sorteret række af rækker, der lagrer data mellem en startnøgle og en slutnøgle.
• En region har en standardstørrelse på 256 MB, som kan konfigureres efter behov.
• En gruppe af regioner serveres til klienterne af en regionserver.
• En regionserver kan betjene ca. 1000 regioner til klienten.

Startende fra toppen af ​​hierarkiet vil jeg først gerne forklare dig om HMaster Server, der fungerer på samme måde som en NameNode i HDFS . Så når jeg bevæger mig ned i hierarkiet, tager jeg dig gennem ZooKeeper og Region Server.

HBase-arkitektur: HMaster

Som i nedenstående billede kan du se, at HMaster håndterer en samling af Region Server, der findes på DataNode. Lad os forstå, hvordan HMaster gør det.

• HBase HMaster udfører DDL-operationer (opret og slet tabeller) og tildeler regioner til regionsserverne, som du kan se i ovenstående billede.
• Det koordinerer og administrerer regionserveren (svarende til NameNode administrerer DataNode i HDFS).
• Det tildeler regioner til Region Servers ved opstart og tildeler regioner til Region Servers igen under gendannelse og belastningsbalancering.
• Den overvåger alle Region Servers forekomster i klyngen (ved hjælp af Zookeeper) og udfører gendannelsesaktiviteter, når en hvilken som helst Region Server er nede.
• Det giver en grænseflade til oprettelse, sletning og opdatering af tabeller.

HBase har et distribueret og stort miljø, hvor HMaster alene ikke er tilstrækkelig til at styre alt. Så du vil undre dig over, hvad der hjælper HMaster med at styre dette enorme miljø? Det er her ZooKeeper kommer ind i billedet. Når vi har forstået, hvordan HMaster styrer HBase-miljøet, vil vi forstå, hvordan Zookeeper hjælper HMaster med at styre miljøet.

HBase-arkitektur: ZooKeeper - Koordinatoren

Dette billede nedenfor forklarer ZooKeepers koordineringsmekanisme.

hvordan man konverterer streng til dato

• Zookeeper fungerer som en koordinator inden for HBase-distribueret miljø. Det hjælper med at opretholde servertilstand inde i klyngen ved at kommunikere gennem sessioner.
• Hver regionserver sammen med HMaster Server sender kontinuerligt hjerterytme med jævne mellemrum til Zookeeper, og den kontrollerer, hvilken server der er i live og tilgængelig som nævnt i ovenstående billede. Det giver også meddelelser om serverfejl, så gendannelsesforanstaltninger kan udføres.
• Med henvisning til ovenstående billede kan du se, der er en inaktiv server, der fungerer som en backup til den aktive server. Hvis den aktive server fejler, kommer den til redning.
• Den aktive HMaster sender hjerterytme til Zookeeper, mens den inaktive HMaster lytter til den meddelelse, der sendes af den aktive HMaster. Hvis den aktive HMaster ikke sender et hjerteslag, slettes sessionen, og den inaktive HMaster bliver aktiv.
• Mens en regionsserver ikke sender et hjerteslag, er sessionen udløbet, og alle lyttere får besked om det. Derefter udfører HMaster passende genopretningshandlinger, som vi vil diskutere senere i denne blog.
• Zookeeper vedligeholder også .META-serverens sti, som hjælper enhver klient med at søge efter en hvilken som helst region. Kunden skal først kontrollere med .META Server, i hvilken regionserver en region hører, og den får stien til den pågældende regionserver.

Som jeg talte om .META Server, lad mig først forklare dig, hvad der er .META-server? Så du kan nemt relatere arbejdet fra ZooKeeper og .META Server sammen. Senere, når jeg vil forklare dig HBase-søgemekanismen i denne blog, vil jeg forklare, hvordan disse to fungerer i samarbejde.

HBase-arkitektur: Metatabel

• META-tabellen er en speciel HBase-katalogtabel. Den opretholder en liste over alle regionens servere i HBase-lagringssystemet, som du kan se i ovenstående billede.
• Ser man på figuren, kan du se, .META filen vedligeholder tabellen i form af nøgler og værdier. Nøgle repræsenterer startnøglen for regionen og dens id, mens værdien indeholder stien til Region Server.

Som jeg allerede diskuterede, er Region Server og dens funktioner, mens jeg forklarede dig Regioner, nu bevæger vi os ned i hierarkiet, og jeg vil fokusere på Region Server's komponent og deres funktioner. Senere vil jeg diskutere mekanismen til søgning, læsning, skrivning og forstå, hvordan alle disse komponenter fungerer sammen.

HBase-arkitektur: Komponenter i Region Server

Dette nedenstående billede viser komponenterne i en regionserver. Nu vil jeg diskutere dem separat.

En regionserver opretholder forskellige regioner, der kører øverst på . Komponenterne i en regionserver er:

• WAL: Som du kan konkludere med ovenstående billede, er WAL (Write Ahead Log) en fil, der er knyttet til hver regionserver i det distribuerede miljø. WAL gemmer de nye data, der ikke er vedvarende eller forpligtet til permanent lagring. Det bruges i tilfælde af manglende gendannelse af datasættene.
• Bloker cache: Fra ovenstående billede er det tydeligt synligt, at Block Cache ligger i toppen af ​​Region Server. Den gemmer de ofte læste data i hukommelsen. Hvis dataene i BlockCache mindst er brugt, fjernes disse data fra BlockCache.
• MemStore: Det er skrivecache. Den gemmer alle indgående data, inden den overføres til disken eller permanent hukommelse. Der er en MemStore for hver kolonnefamilie i en region. Som du kan se på billedet, er der flere MemStores for en region, fordi hver region indeholder flere kolonnefamilier. Dataene sorteres i leksikografisk rækkefølge, inden de overføres til disken.
• HFil: Fra ovenstående figur kan du se, at HFile er gemt på HDFS. Således gemmer den de faktiske celler på disken. MemStore forpligter dataene til HFile, når størrelsen på MemStore overstiger.

Nu hvor vi kender store og mindre komponenter i HBase Architecture, vil jeg forklare mekanismen og deres samarbejdsindsats i dette. Uanset om det er læsning eller skrivning, skal vi først søge fra, hvor vi skal læse, eller hvor vi skal skrive en fil. Så lad os forstå denne søgningsproces, da dette er en af ​​de mekanismer, der gør HBase meget populær.

HBase-arkitektur: Hvordan initialisering af søgning i HBase?

Som du ved, gemmer Zookeeper META-tabelplaceringen. Når en klient nærmer sig med en læsning eller skriver anmodninger til HBase, opstår følgende operation:

1. Klienten henter placeringen af ​​META-tabellen fra ZooKeeper.
2. Klienten anmoder derefter om placeringen af ​​Region Server for den tilsvarende række-nøgle fra META-tabellen for at få adgang til den. Klienten cachelagrer disse oplysninger med placeringen af ​​META-tabellen.
3. Derefter får den rækkeplaceringen ved at anmode om det fra den tilsvarende regionserver.

Til fremtidige referencer bruger klienten sin cache til at hente placeringen af ​​META-tabellen og tidligere læst række nøgles Region Server. Derefter henviser klienten ikke til META-tabellen, før og medmindre der er en glip, fordi regionen flyttes eller flyttes. Derefter beder den igen til META-serveren og opdaterer cachen.

Som hver gang spilder klienter ikke tid på at hente placeringen af ​​Region Server fra META Server, hvilket sparer tid og gør søgningsprocessen hurtigere. Lad mig fortælle dig, hvordan skrivning foregår i HBase. Hvad er komponenterne involveret i det, og hvordan er de involveret?

postgraduate diplom vs kandidatgrad

HBase-arkitektur: HBase Skriv Mekanisme

Dette billede nedenfor forklarer skrivemekanismen i HBase.

Skrivmekanismen gennemgår følgende proces sekventielt (se ovenstående billede):

Trin 1: Hver gang klienten har en skriveanmodning, skriver klienten dataene til WAL (Write Ahead Log).

• Redigeringerne tilføjes derefter i slutningen af ​​WAL-filen.
• Denne WAL-fil vedligeholdes i hver Region Server, og Region Server bruger den til at gendanne data, der ikke er forpligtet til disken.

Trin 2: Når data er skrevet til WAL, kopieres de til MemStore.

Trin 3: Når dataene er placeret i MemStore, modtager klienten bekræftelsen.

Trin 4: Når MemStore når tærsklen, dumper den eller overfører dataene til en HFile.

Lad os nu tage et dybt dyk og forstå, hvordan MemStore bidrager i skriveprocessen, og hvad er dens funktioner?

HBase Skriv Mekanisme- MemStore

• MemStore opdaterer altid de data, der er gemt i den, i en leksikografisk rækkefølge (sekventielt på en ordbog) som sorterede KeyValues. Der er en MemStore for hver kolonnefamilie, og opdateringerne lagres således sorteret for hver kolonnefamilie.
• Når MemStore når tærsklen, dumper den alle dataene i en ny HFile sorteret. Denne HFile er gemt i HDFS. HBase indeholder flere HFiles for hver kolonnefamilie.
• Over tid vokser antallet af HFile, når MemStore dumper dataene.
• MemStore gemmer også det sidst skrevne sekvensnummer, så Master Server og MemStore ved begge, at hvad der er begået hidtil, og hvor man skal starte fra. Når region starter, læses det sidste sekvensnummer, og fra dette nummer starter nye redigeringer.

Som jeg diskuterede flere gange, er HFile den vigtigste vedvarende opbevaring i en HBase-arkitektur. Endelig er alle data forpligtet til HFile, som er den permanente lagring af HBase. Lad os derfor se på egenskaberne ved HFile, som gør det hurtigere til søgning under læsning og skrivning.

HBase-arkitektur: HBase Skriv Mekanisme- HFil

• Skrifterne placeres sekventielt på disken. Derfor er bevægelsen af ​​diskens læse-skrivehoved meget mindre. Dette gør skrive- og søgemekanismen meget hurtig.
• HFile-indekserne indlæses i hukommelsen, hver gang en HFile åbnes. Dette hjælper med at finde en post i en enkelt søgning.
• Traileren er en markør, der peger på HFiles meta-blok. Den er skrevet i slutningen af ​​den forpligtede fil. Den indeholder oplysninger om tidsstempel og blomstringsfiltre.
• Bloom Filter hjælper med at søge på nøgleværdipar, det springer filen over, som ikke indeholder den krævede række. Tidsstempel hjælper også med at søge i en version af filen, det hjælper med at springe dataene over.

Efter at have kendskab til skrivemekanismen og de forskellige komponenters rolle i at gøre skrive og søge hurtigere. Jeg vil forklare dig, hvordan læsemekanismen fungerer i en HBase-arkitektur? Derefter bevæger vi os til de mekanismer, der øger HBase-ydeevne som komprimering, regionopdeling og genopretning.

HBase-arkitektur: Læs mekanisme

Som diskuteret i vores søgemekanisme henter klienten først placeringen af ​​Region Server fra .META Server, hvis klienten ikke har den i sin cachehukommelse. Derefter gennemgår de sekventielle trin som følger:

• For at læse dataene søger scanneren først efter rækken i Block cache. Her er alle de nyligt læste nøgleværdipar gemt.
• Hvis Scanner ikke finder det krævede resultat, flyttes det til MemStore, da vi ved, at dette er skrivecachehukommelsen. Der søger den efter de senest skrevne filer, som endnu ikke er dumpet i HFile.
• Endelig bruger den blomstringsfiltre og blokerer cache for at indlæse data fra HFile.

Indtil videre har jeg diskuteret søgning, læse og skrive mekanisme af HBase. Nu vil vi se på HBase-mekanismen, der gør søgning, læse og skrive hurtigt i HBase. Først vil vi forstå Komprimering , som er en af ​​disse mekanismer.

HBase-arkitektur: Komprimering

HBase kombinerer HFiles for at reducere lagring og reducere antallet af disksøgninger, der er nødvendige for en læsning. Denne proces kaldes komprimering . Komprimering vælger nogle HFiles fra en region og kombinerer dem. Der er to typer komprimering, som du kan se i ovenstående billede.

1. Mindre komprimering : HBase vælger automatisk mindre HFiles og tildeler dem igen til større HFiles som vist i ovenstående billede. Dette kaldes mindre komprimering. Det udfører flettesortering for at forpligte mindre HFiles til større HFiles. Dette hjælper med lageroptimering.
2. Større komprimering: Som illustreret i ovenstående billede fusionerer HBase i større komprimering og tildeler de mindre HFiler i en region igen til en ny HFile. I denne proces placeres de samme kolonnefamilier sammen i den nye HFile. Det dropper slettet og udløbet celle i denne proces. Det øger læseevnen.

Men under denne proces kan input-output-diske og netværkstrafik blive overbelastet. Dette er kendt som skriv forstærkning . Så det er normalt planlagt under lave spidsbelastningstider.

Nu er en anden ydeevneoptimeringsproces, som jeg vil diskutere, Region Split . Dette er meget vigtigt for belastningsafbalancering.

HBase-arkitektur: Region Split

Nedenstående figur illustrerer Region Split-mekanismen.

Når en region bliver stor, er den opdelt i to underregioner, som vist i ovenstående figur. Hver region repræsenterer nøjagtigt halvdelen af ​​moderregionen. Derefter rapporteres denne opdeling til HMaster. Dette håndteres af den samme Region Server, indtil HMaster tildeler dem til en ny Region Server til belastningsafbalancering.

Flytter ned ad linjen, sidst men ikke mindst, vil jeg forklare dig, hvordan HBase gendanner data efter en fiasko. Som vi ved det Fejlgendannelse er et meget vigtigt træk ved HBase, så lad os vide, hvordan HBase gendanner data efter en fejl.

HBase-arkitektur: HBase nedbrud og datagendannelse

• Når en regionsserver mislykkes, underretter ZooKeeper HMaster om fejlen.
• Derefter distribuerer og tildeler HMaster regionerne på den styrtede regionserver til mange aktive regionservere. For at gendanne data fra MemStore på den mislykkede regionserver distribuerer HMaster WAL til alle regionsservere.
• Hver regionserver udfører WAL igen for at opbygge MemStore til den mislykkede regions kolonnefamilie.
• Dataene skrives i kronologisk rækkefølge (i rettidig rækkefølge) i WAL. Derfor betyder genudførelse af denne WAL at foretage al den ændring, der blev foretaget og gemt i MemStore-filen.
• Så når alle regionsserverne udfører WAL, gendannes MemStore-data for alle kolonnefamilier.

Jeg håber, at denne blog ville have hjulpet dig med at undervurdere HBase Data Model & HBase Architecture. Håber du nød det. Nu kan du forholde dig til funktionerne i HBase (som jeg forklarede i min tidligere HBase-vejledning blog) med HBase Architecture og forstå, hvordan det fungerer internt. Nu hvor du kender den teoretiske del af HBase, skal du gå til den praktiske del. Med dette i tankerne, vores næste blog af vil forklare en prøve HBase POC .

Nu hvor du har forstået HBase-arkitekturen, skal du tjekke af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka Big Data Hadoop-certificeringskursus hjælper elever med at blive eksperter i HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved hjælp af realtidsanvendelsessager på Retail, Social Media, Aviation, Tourism, Finance domæne.

Har du et spørgsmål til os? Nævn det i kommentarfeltet, så vender vi tilbage til dig.