HBase-arkitektur: HBase-datamodell och HBase läs- / skrivmekanism

HBase-arkitektur

I min tidigare blogg på HBase-handledning , Jag förklarade vad som är HBase och dess funktioner. Jag nämnde också Facebook messengers fallstudie för att hjälpa dig att ansluta bättre. Nu går vi vidare i vår , Jag kommer att förklara dig datamodellen för HBase och HBase Architecture.Innan du går vidare bör du också veta att HBase är ett viktigt koncept som utgör en integrerad del av för Big Data Hadoop-certifiering.

De viktiga ämnen som jag kommer att ta dig igenom i denna HBase-arkitekturblogg är:

• HBase-datamodell
• HBase Architecture and It's Components
• HBase-skrivmekanism
• HBase-läsmekanism
• HBase-prestandaoptimeringsmekanismer

Låt oss först förstå datamodellen för HBase. Det hjälper HBase i snabbare läsning / skrivning och sökning.

HBase Architecture: HBase Data Model

Som vi vet är HBase en kolumnorienterad NoSQL-databas. Även om det liknar en relationsdatabas som innehåller rader och kolumner, men det är inte en relationsdatabas. Relationsdatabaser är radorienterade medan HBase är kolumnorienterade. Så låt oss först förstå skillnaden mellan kolumnorienterade och radorienterade databaser:

Radorienterade vs kolumnorienterade databaser:

• Radorienterade databaser lagrar tabellposter i en sekvens av rader. Medan kolumnorienterade databaserlagra tabellposter i en sekvens av kolumner, dvs. posterna i en kolumn lagras på angränsande platser på diskar.

För att bättre förstå det, låt oss ta ett exempel och överväga tabellen nedan.

Om den här tabellen lagras i en radorienterad databas. Det kommer att lagra posterna enligt nedan:

ett,Paul Walker,USA,231,Galant,

2, Vin Diesel,Brasilien,520,Mustang

I radorienterade databaser lagras data baserat på rader eller tuplar som du kan se ovan.

Medan de kolumnorienterade databaser lagrar dessa data som:

ett,2, Paul Walker,Vin Diesel, USA,Brasilien, 231,520, Galant,Mustang

I en kolumnorienterad databas lagras alla kolumnvärden tillsammans som första kolumnvärden kommer att lagras tillsammans, sedan lagras de andra kolumnvärdena tillsammans och data i andra kolumner lagras på liknande sätt.

• När datamängden är väldigt enorm, som när det gäller petabyte eller exabyte, använder vi kolumnorienterat tillvägagångssätt, eftersom data i en enda kolumn lagras tillsammans och kan nås snabbare.
• Medan radorienterat tillvägagångssätt effektivt hanterar mindre antal rader och kolumner effektivt, eftersom radorienterad databas lagrar data är ett strukturerat format.
• När vi behöver bearbeta och analysera en stor uppsättning halvstrukturerad eller ostrukturerad data använder vi kolumnorienterad strategi. Såsom applikationer som hanterar Online analytisk bearbetning som data mining, datalagring, applikationer inklusive analys, etc.
• Med beaktande av att Online transaktionsbehandling som bank- och finansdomäner som hanterar strukturerad data och kräver transaktionsegenskaper (ACID-egenskaper) använder radorienterad metod.

HBase-tabeller har följande komponenter, som visas i bilden nedan:

• Tabeller : Data lagras i tabellformat i HBase. Men här är tabellerna i kolumnorienterat format.
• Rad Nyckel : Radknappar används för att söka poster som gör sökningar snabba. Du skulle vara nyfiken på att veta hur? Jag kommer att förklara det i arkitekturdelen framåt i den här bloggen.
• Kolumn Familjer : Olika kolumner kombineras i en kolumnfamilj. Dessa kolumnfamiljer lagras tillsammans vilket gör sökprocessen snabbare eftersom data som tillhör samma kolumnfamilj kan nås tillsammans i en enda sökning.
• Kolumn Kval : Varje kolumns namn är känt som dess kolumnkvalificering.
• Cell : Data lagras i celler. Uppgifterna dumpas i celler som specifikt identifieras av radnyckel- och kolumngrunder.
• Tidsstämpel : Tidsstämpel är en kombination av datum och tid. När data lagras lagras den med sin tidsstämpel. Detta gör det enkelt att söka efter en viss version av data.

På ett mer enkelt och förståeligt sätt kan vi säga att HBase består av:

• Uppsättning av bord
• Varje tabell med kolumnfamiljer och rader
• Radnyckel fungerar som en primärnyckel i HBase.
• All tillgång till HBase-tabeller använder denna primära nyckel
• Varje kolumnkvalificering som finns i HBase betecknar attribut som motsvarar objektet som finns i cellen.

Nu när du känner till HBase Data Model, låt oss se hur denna datamodell överensstämmer med HBase Architecture och gör den lämplig för stor lagring och snabbare bearbetning.

HBase Architecture: Komponenter i HBase Architecture

HBase har tre huvudkomponenter, dvs. HMaster Server , HBase Region Server, Regioner och Djurvakt .

Nedanstående figur förklarar hierarkin för HBase Architecture. Vi kommer att prata om var och en av dem individuellt.

Nu innan vi går till HMaster kommer vi att förstå regioner eftersom alla dessa servrar (HMaster, Region Server, Zookeeper) är placerade för att samordna och hantera regioner och utföra olika operationer inom regionerna. Så du skulle vara nyfiken på att veta vad som är regioner och varför är de så viktiga?

HBase Architecture: Område

En region innehåller alla raderna mellan startknappen och slutknappen som tilldelats den regionen. HBase-tabeller kan delas in i ett antal regioner på ett sådant sätt att alla kolumner i en kolumnfamilj lagras i en region. Varje region innehåller raderna i en sorterad ordning.

Många regioner tilldelas en Regionserver , som är ansvarig för hantering, hantering, körning av läs- och skrivoperationer på den uppsättningen regioner.

Så, avslutar på ett enklare sätt:

• En tabell kan delas in i ett antal regioner. En region är ett sorterat intervall av rader som lagrar data mellan en startnyckel och en slutnyckel.
• En region har en standardstorlek på 256 MB som kan konfigureras efter behov.
• En grupp regioner serveras till klienterna av en regionserver.
• En regionserver kan betjäna cirka 1000 regioner till klienten.

Nu från början av hierarkin vill jag först förklara dig om HMaster Server som fungerar på samma sätt som en NameNode i HDFS . Sedan flyttar jag ner i hierarkin och tar dig genom ZooKeeper och Region Server.

HBase Architecture: HMaster

Som i bilden nedan kan du se att HMaster hanterar en samling Region Server som finns på DataNode. Låt oss förstå hur HMaster gör det.

• HBase HMaster utför DDL-operationer (skapa och ta bort tabeller) och tilldelar regioner till regionservrarna som du kan se i bilden ovan.
• Den samordnar och hanterar regionservern (liknande NameNode hanterar DataNode i HDFS).
• Det tilldelar regioner till Region Servers vid start och tilldelar regioner till Region Servers under återställning och belastningsbalansering.
• Den övervakar alla Region Servers instanser i klustret (med hjälp av Zookeeper) och utför återställningsaktiviteter när någon Region Server är nere.
• Det ger ett gränssnitt för att skapa, ta bort och uppdatera tabeller.

HBase har en distribuerad och enorm miljö där HMaster ensam inte räcker för att hantera allt. Så du undrar vad som hjälper HMaster att hantera denna enorma miljö? Det är där ZooKeeper kommer in i bilden. Efter att vi förstått hur HMaster hanterar HBase-miljön kommer vi att förstå hur Zookeeper hjälper HMaster att hantera miljön.

HBase Architecture: ZooKeeper - Koordinator

Den här bilden nedan förklarar ZooKeepers koordineringsmekanism.

• Zookeeper fungerar som en koordinator i HBase-distribuerad miljö. Det hjälper till att upprätthålla serverstatus i klustret genom att kommunicera genom sessioner.
• Varje regionserver tillsammans med HMaster Server skickar kontinuerligt hjärtslag med jämna mellanrum till Zookeeper och den kontrollerar vilken server som finns och finns som nämns i bilden ovan. Det ger också meddelanden om serverfel så att återställningsåtgärder kan utföras.
• Med hänvisning från ovanstående bild kan du se, det finns en inaktiv server som fungerar som en säkerhetskopia för aktiv server. Om den aktiva servern misslyckas kommer den att rädda.
• Den aktiva HMaster skickar hjärtslag till Zookeeper medan den inaktiva HMaster lyssnar på meddelandet som skickas av aktiv HMaster. Om den aktiva HMaster inte skickar ett hjärtslag raderas sessionen och den inaktiva HMaster blir aktiv.
• Medan en regionserver misslyckas med att skicka hjärtslag har sessionen upphört att gälla och alla lyssnare meddelas om den. Sedan utför HMaster lämpliga återställningsåtgärder som vi kommer att diskutera senare i den här bloggen.
• Zookeeper upprätthåller också .META Server-sökvägen, vilket hjälper alla klienter att söka efter vilken region som helst. Klienten måste först kontrollera med .META Server i vilken Region Server en region tillhör, och den får sökvägen till den Region Server.

När jag pratade om .META Server, låt mig först förklara för dig vad som är .META-server? Så du kan enkelt relatera arbetet med ZooKeeper och .META Server tillsammans. Senare, när jag kommer att förklara HBase-sökmekanismen i den här bloggen, kommer jag att förklara hur dessa två fungerar i samarbete.

HBase Architecture: Metatabell

• META-tabellen är en speciell HBase-katalogtabell. Den håller en lista över alla regionens servrar i HBase-lagringssystemet, som du kan se i bilden ovan.
• Titta på figuren du kan se, .META filen underhåller tabellen i form av nycklar och värden. Nyckeln representerar regionens startnyckel och dess id medan värdet innehåller sökvägen till regionservern.

Som jag redan diskuterade flyttar vi nu Region Server och dess funktioner medan jag förklarade er Regioner, nu går vi ner i hierarkin och jag kommer att fokusera på Region Serverns komponent och deras funktioner. Senare kommer jag att diskutera mekanismen för att söka, läsa, skriva och förstå hur alla dessa komponenter fungerar tillsammans.

HBase Architecture: Komponenter i Region Server

Bilden nedan visar komponenterna i en regionserver. Nu kommer jag att diskutera dem separat.

En regionserver underhåller olika regioner som körs på toppen av . Komponenter i en regionserver är:

• WAL: Som du kan dra slutsatsen från bilden ovan är WAL (Write Ahead Log) en fil som är bifogad till varje regionserver i den distribuerade miljön. WAL lagrar de nya data som inte har bestått eller har förbundits till permanent lagring. Den används vid misslyckande med att återställa datauppsättningarna.
• Blockera cache: Från ovanstående bild är det tydligt att Block Cache finns högst upp på Region Server. Den lagrar de ofta lästa uppgifterna i minnet. Om data i BlockCache har använts minst nyligen tas dessa data bort från BlockCache.
• MemStore: Det är skrivcache. Den lagrar all inkommande data innan den överförs till disken eller permanent minne. Det finns en MemStore för varje kolumnfamilj i en region. Som du kan se på bilden finns det flera MemStores för en region eftersom varje region innehåller flera kolumnfamiljer. Uppgifterna sorteras i leksikografisk ordning innan de överförs till disken.
• HFil: Från ovanstående figur kan du se HFile lagras på HDFS. Således lagras de faktiska cellerna på disken. MemStore överför data till HFile när storleken på MemStore överstiger.

Nu när vi känner till större och mindre komponenter i HBase Architecture kommer jag att förklara mekanismen och deras samarbetsinsats i detta. Oavsett om det är läsning eller skrivning, först måste vi söka var vi ska läsa eller var vi ska skriva en fil. Så låt oss förstå den här sökprocessen, eftersom det här är en av de mekanismer som gör HBase mycket populär.

HBase Architecture: Hur sökning initialiseras i HBase?

Som du vet lagrar Zookeeper META-tabellplatsen. När en klient närmar sig en läsning eller skriver förfrågningar till HBase sker följande operation:

1. Klienten hämtar platsen för META-tabellen från ZooKeeper.
2. Klienten begär sedan platsen för Region Server för motsvarande radnyckel från META-tabellen för att komma åt den. Klienten cachar denna information med platsen för META-tabellen.
3. Sedan kommer den att få radplatsen genom att begära från motsvarande regionserver.

För framtida referenser använder klienten sin cache för att hämta platsen för META-tabellen och tidigare lästa radnyckelns Region Server. Då kommer klienten inte att hänvisa till META-tabellen förrän och om det inte finns en miss eftersom regionen flyttas eller flyttas. Då kommer den igen att begära till META-servern och uppdatera cachen.

Som varje gång slösar inte klienter tid på att hämta platsen för Region Server från META Server, vilket sparar tid och gör sökprocessen snabbare. Låt mig berätta hur skrivning sker i HBase. Vilka komponenter är involverade i det och hur är de involverade?

c ++ stl sortera

HBase Architecture: HBase Skriv Mekanism

Den här bilden nedan förklarar skrivmekanismen i HBase.

Skrivmekanismen går igenom följande process sekventiellt (se ovanstående bild):

Steg 1: Närhelst klienten har en skrivförfrågan skriver klienten data till WAL (Write Ahead Log).

• Redigeringarna läggs sedan till i slutet av WAL-filen.
• Denna WAL-fil underhålls i varje regionserver och Region Server använder den för att återställa data som inte är förpliktade till disken.

Steg 2: När data har skrivits till WAL kopieras de till MemStore.

Steg 3: När data har placerats i MemStore får klienten bekräftelsen.

Steg 4: När MemStore når tröskeln dumpar den eller överför data till en HFile.

Låt oss nu ta ett djupt dyk och förstå hur MemStore bidrar i skrivprocessen och vilka funktioner har det?

HBase Skriv Mekanism- MemStore

• MemStore uppdaterar alltid data som lagras i den, i en lexikografisk ordning (sekventiellt ordboksvis) som sorterade KeyValues. Det finns en MemStore för varje kolumnfamilj, och uppdateringarna lagras därmed på ett sorterat sätt för varje kolumnfamilj.
• När MemStore når tröskeln, dumpar den all information till en ny HFile på ett sorterat sätt. Denna HFile lagras i HDFS. HBase innehåller flera HFiles för varje kolumnfamilj.
• Med tiden växer antalet HFile när MemStore dumpar data.
• MemStore sparar också det senast skrivna sekvensnumret, så Master Server och MemStore vet båda, att vad som hittills har begåtts och var man ska börja. När region startar upp läses det sista sekvensnumret och från det numret börjar nya ändringar.

Som jag diskuterade flera gånger är att HFile den viktigaste ihållande lagringen i en HBase-arkitektur. Äntligen är all data förbunden med HFile, som är den permanenta lagringen av HBase. Låt oss därför titta på egenskaperna hos HFile vilket gör det snabbare för sökning medan du läser och skriver.

HBase Architecture: HBase Skriv Mekanism- HFil

• Skrifterna placeras sekventiellt på disken. Därför är rörelsen för skivans läs- och skrivhuvud mycket mindre. Detta gör skriv- och sökmekanismen mycket snabb.
• HFile-index laddas i minnet när en HFile öppnas. Detta hjälper till att hitta en post i en enda sökning.
• Trailern är en pekare som pekar på HFiles metablock. Den skrivs i slutet av den förpliktade filen. Den innehåller information om tidsstämpel och blommefilter.
• Bloom Filter hjälper till att söka efter nyckelvärdepar, det hoppar över filen som inte innehåller den önskade radnyckeln. Tidsstämpel hjälper också till att söka efter en version av filen, det hjälper till att hoppa över data.

Efter att ha känt skrivmekanismen och olika komponenters roll för att göra skrivning och sökning snabbare. Jag kommer att förklara för dig hur läsmekanismen fungerar i en HBase-arkitektur? Sedan kommer vi att gå till de mekanismer som ökar HBase-prestanda som komprimering, regionuppdelning och återhämtning.

HBase Architecture: Läs Mekanism

Som diskuteras i vår sökmekanism hämtar klienten först platsen för Region Server från .META Server om klienten inte har den i sitt cacheminne. Sedan går det igenom de sekventiella stegen enligt följande:

• För att läsa data letar skannern först efter radcellen i Block cache. Här lagras alla nyckelvärde par som nyligen lästs.
• Om skannern inte hittar det önskade resultatet flyttas det till MemStore, eftersom vi vet att detta är skrivcacheminnet. Där söker den efter de senast skrivna filerna, som ännu inte har dumpats i HFile.
• Äntligen använder den blommefilter och blockerar cache för att ladda data från HFile.

Hittills har jag diskuterat sök-, läs- och skrivmekanismen för HBase. Nu ska vi titta på HBase-mekanismen som gör sökning, läs och skriv snabbt i HBase. Först kommer vi att förstå Komprimering , vilket är en av dessa mekanismer.

HBase Architecture: Komprimering

HBase kombinerar HFiles för att minska lagring och minska antalet skivsökningar som behövs för en läsning. Denna process kallas komprimering . Komprimering väljer några HFiler från en region och kombinerar dem. Det finns två typer av komprimering som du kan se i bilden ovan.

1. Mindre komprimering : HBase väljer automatiskt mindre HFiles och kopplar dem om till större HFiles som visas i bilden ovan. Detta kallas Minor Compaction. Den utför sammanslagningssortering för att begå mindre HFiles till större HFiles. Detta hjälper till vid optimering av lagringsutrymme.
2. Stor komprimering: Som illustreras i ovanstående bild, i Major komprimering, sammanfogar HBase och återansätter de mindre HFilerna i en region till en ny HFile. I denna process placeras samma kolumnfamiljer tillsammans i den nya HFilen. Det tappar borttagen och utgången cell i denna process. Det ökar läsprestandan.

Men under denna process kan input-output-diskar och nätverkstrafik bli överbelastade. Detta kallas skriv förstärkning . Så det planeras vanligtvis under låga toppbelastningstider.

Nu är en annan prestandaoptimeringsprocess som jag kommer att diskutera Region Split . Detta är mycket viktigt för lastbalansering.

HBase Architecture: Region Split

Figuren nedan illustrerar Region Split-mekanismen.

När en region blir stor delas den upp i två underregioner, som visas i figuren ovan. Varje region representerar exakt hälften av moderregionen. Sedan rapporteras denna splittring till HMaster. Detta hanteras av samma Region Server tills HMaster tilldelar dem till en ny Region Server för belastningsutjämning.

Flytta ner linjen, sist men inte minst, jag kommer att förklara dig hur HBase återställer data efter ett fel. Som vi vet det Felåterställning är ett mycket viktigt inslag i HBase, så låt oss veta hur HBase återställer data efter ett fel.

HBase Architecture: HBase Crash and Data Recovery

• När en regionserver misslyckas meddelar ZooKeeper HMaster om felet.
• Sedan distribuerar och allokerar HMaster regionerna för den kraschade regionservern till många aktiva regionservrar. För att återställa data från MemStore från den misslyckade regionservern distribuerar HMaster WAL till alla regionservrar.
• Varje regionserver kör WAL igen för att bygga MemStore för den misslyckade regionens kolumnfamilj.
• Uppgifterna skrivs i kronologisk ordning (i rätt ordning) i WAL. Därför betyder det att du utför den ändring som gjordes och lagrades i MemStore-filen om du kör den igen.
• Så efter att alla regionservrar har kört WAL återställs MemStore-data för alla kolumner.

Jag hoppas att den här bloggen skulle ha hjälpt dig att underskatta HBase Data Model & HBase Architecture. Hoppas du gillade det. Nu kan du relatera till funktionerna i HBase (som jag förklarade i min tidigare HBase-handledning blogg) med HBase Architecture och förstå hur det fungerar internt. Nu när du känner till den teoretiska delen av HBase, bör du gå till den praktiska delen. Med detta i åtanke, vår nästa blogg av kommer att förklara ett prov HBase POC .

Nu när du har förstått HBase Architecture, kolla in av Edureka, ett pålitligt online-lärande företag med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka-kursen Big Data Hadoop-certifiering hjälper eleverna att bli experter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume och Sqoop med realtidsanvändningsfall på Retail, Social Media, Aviation, Tourism, Finance.

Har du en fråga till oss? Vänligen nämna det i kommentarfältet så återkommer vi till dig.