HBase-architectuur: HBase-gegevensmodel en HBase-lees- / schrijfmechanisme

HBase-architectuur

In mijn vorige blog over HBase-zelfstudie , Heb ik uitgelegd wat HBase is en wat de mogelijkheden ervan zijn. Ik noemde ook de casestudy van Facebook Messenger om u te helpen beter verbinding te maken. Nu verder vooruit in onze , Zal ik je het datamodel van HBase en HBase Architecture uitleggen.Voordat u verder gaat, moet u ook weten dat HBase een belangrijk concept is dat een integraal onderdeel vormt van het voor Big Data Hadoop-certificering.

De belangrijke onderwerpen die ik in dit HBase-architectuurblog met u zal bespreken, zijn:

• HBase-gegevensmodel
• HBase-architectuur en zijn componenten
• HBase-schrijfmechanisme
• HBase-leesmechanisme
• Mechanismen voor HBase-prestatieoptimalisatie

Laten we eerst het datamodel van HBase begrijpen. Het helpt HBase bij sneller lezen / schrijven en zoeken.

HBase-architectuur: HBase-gegevensmodel

Zoals we weten, is HBase een kolomgeoriënteerde NoSQL-database. Hoewel het lijkt op een relationele database die rijen en kolommen bevat, is het geen relationele database. Relationele databases zijn rijgericht, terwijl HBase kolomgericht is. Laten we dus eerst het verschil begrijpen tussen kolomgeoriënteerde en rijgeoriënteerde databases:

Rijgeoriënteerde versus kolomgeoriënteerde databases:

• Rijgeoriënteerde databases slaan tabelrecords op in een reeks rijen. Terwijl kolomgeoriënteerde databasessla tabelrecords op in een reeks kolommen, d.w.z. de items in een kolom worden opgeslagen op aangrenzende locaties op schijven.

Laten we voor een beter begrip een voorbeeld nemen en de onderstaande tabel bekijken.

Als deze tabel is opgeslagen in een rijgeoriënteerde database. Het zal de records opslaan zoals hieronder getoond:

een,Paul Walker,ONS,231,Gallant,

2, Vin Diesel,Brazilië,520,Mustang

In rijgeoriënteerde databases worden gegevens opgeslagen op basis van rijen of tupels zoals u hierboven kunt zien.

Terwijl de kolomgeoriënteerde databases deze gegevens opslaan als:

een,2, Paul Walker,Vin Diesel, ONS,Brazilië, 231,520, Gallant,Mustang

In kolomgeoriënteerde databases worden alle kolomwaarden samen opgeslagen zoals eerste kolomwaarden samen worden opgeslagen, vervolgens worden de tweede kolomwaarden samen opgeslagen en worden gegevens in andere kolommen op een vergelijkbare manier opgeslagen.

• Wanneer de hoeveelheid gegevens erg groot is, zoals in termen van petabytes of exabytes, gebruiken we een kolomgeoriënteerde benadering, omdat de gegevens van een enkele kolom samen worden opgeslagen en sneller toegankelijk zijn.
• Terwijl een rijgeoriënteerde benadering relatief minder rijen en kolommen efficiënt verwerkt, aangezien de rijgeoriënteerde database gegevens een gestructureerd formaat heeft.
• Wanneer we een grote set semi-gestructureerde of ongestructureerde gegevens moeten verwerken en analyseren, gebruiken we een kolomgeoriënteerde benadering. Zoals applicaties die omgaan met Online analytische verwerking zoals datamining, datawarehousing, applicaties inclusief analyse, etc.
• Terwijl, Online transactieverwerking zoals bank- en financiële domeinen die gestructureerde gegevens verwerken en transactionele eigenschappen (ACID-eigenschappen) vereisen, gebruiken een rijgeoriënteerde benadering.

HBase-tabellen hebben de volgende componenten, weergegeven in de onderstaande afbeelding:

• Tabellen : Gegevens worden opgeslagen in een tabelindeling in HBase. Maar hier zijn tabellen in kolomgericht formaat.
• Rij Sleutel : Rijtoetsen worden gebruikt om records te doorzoeken, waardoor zoekopdrachten snel worden uitgevoerd. Benieuwd hoe? Ik zal het uitleggen in het architectuurgedeelte dat verder gaat in deze blog.
• Kolom Gezinnen : Verschillende kolommen worden gecombineerd in een kolomfamilie. Deze kolomfamilies worden bij elkaar opgeslagen, wat het zoekproces versnelt omdat gegevens die tot dezelfde kolomfamilie behoren samen in één zoekopdracht kunnen worden benaderd.
• Kolom Kwalificaties : De naam van elke kolom staat bekend als de kolomkwalificatie.
• Cel : Gegevens worden opgeslagen in cellen. De gegevens worden gedumpt in cellen die specifiek worden geïdentificeerd door rowkey- en kolomkwalificaties.
• Tijdstempel : Tijdstempel is een combinatie van datum en tijd. Telkens wanneer gegevens worden opgeslagen, worden deze opgeslagen met hun tijdstempel. Dit maakt het zoeken naar een bepaalde gegevensversie gemakkelijk.

Op een meer eenvoudige en begrijpelijke manier kunnen we zeggen dat HBase bestaat uit:

• Set tafels
• Elke tabel met kolomfamilies en rijen
• Rijsleutel fungeert als een primaire sleutel in HBase.
• Elke toegang tot HBase-tabellen gebruikt deze primaire sleutel
• Elke kolomkwalificatie die in HBase aanwezig is, geeft een attribuut aan dat overeenkomt met het object dat zich in de cel bevindt.

Nu u HBase Data Model kent, laten we eens kijken hoe dit datamodel in lijn is met HBase Architecture en geschikt maakt voor grote opslag en snellere verwerking.

HBase-architectuur: componenten van HBase-architectuur

HBase heeft drie hoofdcomponenten, d.w.z. HMaster Server , HBase-regioserver, regio's en Dierentuinmedewerker .

De onderstaande afbeelding legt de hiërarchie van de HBase-architectuur uit. We zullen over elk van hen afzonderlijk praten.

Voordat we naar de HMaster gaan, zullen we de regio's begrijpen, aangezien al deze servers (HMaster, Region Server, Zookeeper) geplaatst zijn om regio's te coördineren en te beheren en om verschillende bewerkingen uit te voeren binnen de regio's. Dus je zou benieuwd zijn wat regio's zijn en waarom ze zo belangrijk zijn?

HBase-architectuur: Regio

Een regio bevat alle rijen tussen de starttoets en de eindtoets die aan die regio is toegewezen. HBase-tabellen kunnen worden onderverdeeld in een aantal regio's, zodat alle kolommen van een kolomfamilie in één regio worden opgeslagen. Elke regio bevat de rijen in een gesorteerde volgorde.

Veel regio's zijn toegewezen aan een Regio Server , die verantwoordelijk is voor het afhandelen, beheren en uitvoeren van lees- en schrijfbewerkingen op die set regio's.

Dus op een eenvoudiger manier concluderen:

• Een tabel kan worden onderverdeeld in een aantal regio's. Een regio is een gesorteerde reeks rijen waarin gegevens tussen een startsleutel en een eindtoets worden opgeslagen.
• Een regio heeft een standaardgrootte van 256 MB die naar behoefte kan worden geconfigureerd.
• Een groep regio's wordt door een regioserver aan de klanten bediend.
• Een regioserver kan ongeveer 1000 regio's aan de client bedienen.

Nu beginnend vanaf de top van de hiërarchie, zou ik u eerst willen uitleggen over HMaster Server die op dezelfde manier werkt als een NameNode in HDFS . Vervolgens ga ik naar beneden in de hiërarchie en leid ik u door ZooKeeper en Region Server.

HBase-architectuur: HMaster

Zoals in de onderstaande afbeelding, kunt u zien dat de HMaster een verzameling Region Server afhandelt die zich op DataNode bevindt. Laten we begrijpen hoe HMaster dat doet.

• HBase HMaster voert DDL-bewerkingen uit (tabellen maken en verwijderen) en wijst regio's toe aan de regioservers, zoals u kunt zien in de bovenstaande afbeelding.
• Het coördineert en beheert de Region Server (vergelijkbaar met NameNode beheert DataNode in HDFS).
• Het wijst regio's toe aan de regioservers bij het opstarten en wijst regio's opnieuw toe aan regioservers tijdens herstel en taakverdeling.
• Het controleert alle instanties van de regioserver in het cluster (met de hulp van Zookeeper) en voert herstelactiviteiten uit wanneer een regioserver niet actief is.
• Het biedt een interface voor het maken, verwijderen en bijwerken van tabellen.

wat zijn tokens in java

HBase heeft een gedistribueerde en enorme omgeving waarin HMaster alleen niet voldoende is om alles te beheren. Dus je zou je afvragen wat HMaster helpt om deze enorme omgeving te beheren? Dat is waar ZooKeeper in beeld komt. Nadat we begrepen hoe HMaster de HBase-omgeving beheert, zullen we begrijpen hoe Zookeeper HMaster helpt bij het beheren van de omgeving.

HBase-architectuur: ZooKeeper - De coördinator

In onderstaande afbeelding wordt het coördinatiemechanisme van ZooKeeper uitgelegd.

• Zookeeper fungeert als een coördinator binnen de gedistribueerde HBase-omgeving. Het helpt bij het handhaven van de serverstatus binnen het cluster door te communiceren via sessies.
• Elke Region Server, samen met HMaster Server, stuurt een continue hartslag met regelmatige tussenpozen naar Zookeeper en het controleert welke server actief en beschikbaar is, zoals vermeld in bovenstaande afbeelding. Het biedt ook serverstoringsmeldingen zodat herstelmaatregelen kunnen worden uitgevoerd.
• Verwijzend naar de bovenstaande afbeelding die u kunt zien, is er een inactieve server die fungeert als een back-up voor een actieve server. Als de actieve server uitvalt, komt deze voor de redding.
• De actieve HMaster stuurt hartslagen naar de dierenverzorger terwijl de inactieve HMaster luistert naar de melding die door de actieve HMaster wordt verzonden. Als de actieve HMaster geen hartslag verzendt, wordt de sessie verwijderd en wordt de inactieve HMaster actief.
• Als een regioserver geen hartslag verzendt, is de sessie verlopen en worden alle luisteraars hiervan op de hoogte gesteld. Vervolgens voert HMaster geschikte herstelacties uit die we later in deze blog zullen bespreken.
• Zookeeper onderhoudt ook het pad van de .META-server, dat elke klant helpt bij het zoeken naar een regio. De Client moet eerst bij .META Server nagaan in welke Region Server een regio thuishoort, en hij krijgt het pad van die Region Server.

Terwijl ik het had over .META Server, wil ik je eerst uitleggen wat is .META server? U kunt dus gemakkelijk het werk van ZooKeeper en .META Server met elkaar in verband brengen. Later, wanneer ik je in deze blog het HBase-zoekmechanisme zal uitleggen, zal ik uitleggen hoe deze twee samenwerken.

HBase-architectuur: Meta-tabel

• De META-tafel is een speciale HBase-catalogustafel. Het houdt een lijst bij van alle regioservers in het HBase-opslagsysteem, zoals u kunt zien in de bovenstaande afbeelding.
• Kijkend naar de figuur die je kunt zien, .META -bestand onderhoudt de tabel in de vorm van sleutels en waarden. Sleutel vertegenwoordigt de startsleutel van de regio en zijn id, terwijl de waarde het pad van de regioserver bevat.

Zoals ik al heb besproken, Regio Server en zijn functies terwijl ik u Regio's aan het uitleggen was, gaan we nu naar beneden in de hiërarchie en zal ik me concentreren op de component van de Regio Server en hun functies. Later zal ik het mechanisme van zoeken, lezen, schrijven bespreken en begrijpen hoe al deze componenten samenwerken.

HBase-architectuur: Componenten van Region Server

Deze onderstaande afbeelding toont de componenten van een regioserver. Nu zal ik ze afzonderlijk bespreken.

Een regioserver onderhoudt verschillende regio's die bovenop . Onderdelen van een regioserver zijn:

• WAL: Zoals je kunt concluderen uit de bovenstaande afbeelding, is Write Ahead Log (WAL) een bestand dat aan elke regioserver binnen de gedistribueerde omgeving is gekoppeld. De WAL slaat de nieuwe gegevens op die niet zijn bewaard of vastgelegd voor de permanente opslag. Het wordt gebruikt in het geval dat de gegevenssets niet kunnen worden hersteld.
• Cache blokkeren: Uit de bovenstaande afbeelding is duidelijk te zien dat Block Cache zich bovenaan de Region Server bevindt. Het slaat de vaak gelezen gegevens op in het geheugen. Als de gegevens in BlockCache het minst recent zijn gebruikt, worden die gegevens verwijderd uit BlockCache.
• MemStore: Het is de schrijfcache. Het slaat alle inkomende gegevens op voordat deze op de schijf of in het permanente geheugen worden vastgelegd. Er is één MemStore voor elke kolomfamilie in een regio. Zoals je in de afbeelding kunt zien, zijn er meerdere MemStores voor een regio omdat elke regio meerdere kolomfamilies bevat. De gegevens worden in lexicografische volgorde gesorteerd voordat ze op de schijf worden vastgelegd.
• H-bestand: Uit de bovenstaande afbeelding kunt u zien dat HFile is opgeslagen op HDFS. Het slaat dus de feitelijke cellen op de schijf op. MemStore legt de gegevens vast aan HFile wanneer de grootte van MemStore groter wordt.

Nu we de belangrijkste en kleine componenten van HBase Architecture kennen, zal ik het mechanisme en hun gezamenlijke inspanning hierin uitleggen. Of het nu gaat om lezen of schrijven, we moeten eerst zoeken waar we een bestand kunnen lezen of schrijven. Laten we dit zoekproces dus eens gaan bekijken, aangezien dit een van de mechanismen is die HBase erg populair maken.

HBase-architectuur: Hoe wordt zoeken geïnitialiseerd in HBase?

Zoals u weet, slaat Zookeeper de META-tafellocatie op. Wanneer een client nadert met een lees- of schrijfverzoek naar HBase, vindt de volgende bewerking plaats:

1. De client haalt de locatie van de META-tabel op uit de ZooKeeper.
2. De cliënt vraagt ​​vervolgens om de locatie van de regioserver van de corresponderende rijsleutel uit de META-tabel om deze te openen. De client slaat deze informatie op in het cachegeheugen met de locatie van de META-tabel.
3. Vervolgens krijgt het de rijlocatie door de bijbehorende regioserver op te vragen.

Voor toekomstige referenties gebruikt de client zijn cache om de locatie van de META-tabel en de eerder gelezen regioserver van de rijsleutel op te halen. De cliënt zal dan niet naar de META-tabel verwijzen, totdat en tenzij er een misser is omdat de regio is verschoven of verplaatst. Daarna zal het opnieuw naar de META-server vragen en de cache bijwerken.

Zoals elke keer verspillen klanten geen tijd met het ophalen van de locatie van de Region Server van META Server, dus dit bespaart tijd en maakt het zoekproces sneller. Laat me je nu vertellen hoe schrijven plaatsvindt in HBase. Wat zijn de componenten die erbij betrokken zijn en hoe zijn ze betrokken?

HBase-architectuur: HBase schrijven Mechanisme

In onderstaande afbeelding wordt het schrijfmechanisme in HBase uitgelegd.

Het schrijfmechanisme doorloopt achtereenvolgens het volgende proces (zie bovenstaande afbeelding):

Stap 1: Elke keer dat de client een schrijfverzoek heeft, schrijft de client de gegevens naar de WAL (Write Ahead Log).

• De bewerkingen worden vervolgens aan het einde van het WAL-bestand toegevoegd.
• Dit WAL-bestand wordt in elke regioserver onderhouden en regioserver gebruikt het om gegevens te herstellen die niet op de schijf zijn vastgelegd.

Stap 2: Zodra de gegevens naar de WAL zijn geschreven, worden ze naar de MemStore gekopieerd.

Stap 3: Zodra de gegevens in MemStore zijn geplaatst, ontvangt de klant de bevestiging.

Stap 4: Wanneer de MemStore de drempel bereikt, worden de gegevens gedumpt of vastgelegd in een HFile.

Laten we nu eens diep duiken en begrijpen hoe MemStore bijdraagt ​​aan het schrijfproces en wat zijn functies zijn?

HBase schrijven Mechanisme- MemStore

• De MemStore werkt de gegevens die erin zijn opgeslagen altijd bij, in lexicografische volgorde (opeenvolgend in een woordenboek) als gesorteerde KeyValues. Er is één MemStore voor elke kolomfamilie, en dus worden de updates op een gesorteerde manier opgeslagen voor elke kolomfamilie.
• Wanneer de MemStore de drempel bereikt, worden alle gegevens op een gesorteerde manier in een nieuw HFile gedumpt. Dit HFile wordt opgeslagen in HDFS. HBase bevat meerdere HFiles voor elke Column Family.
• Na verloop van tijd groeit het aantal HFile naarmate MemStore de gegevens dumpt.
• MemStore slaat ook het laatst geschreven volgnummer op, zodat Master Server en MemStore allebei weten wat er tot dusver is vastgelegd en waar ze moeten beginnen. Wanneer de regio opstart, wordt het laatste volgnummer gelezen en vanaf dat nummer beginnen nieuwe bewerkingen.

Zoals ik verschillende keren heb besproken, is dat HFile de belangrijkste permanente opslag in een HBase-architectuur. Eindelijk worden alle gegevens vastgelegd in HFile, de permanente opslag van HBase. Laten we daarom eens kijken naar de eigenschappen van HFile die het zoeken tijdens het lezen en schrijven sneller maken.

HBase-architectuur: HBase schrijven Mechanisme- HFile

• De schrijfbewerkingen worden opeenvolgend op de schijf geplaatst. Daarom is de beweging van de lees- / schrijfkop van de schijf zeer gering. Dit maakt het schrijf- en zoekmechanisme erg snel.
• De HFile-indexen worden in het geheugen geladen wanneer een HFile wordt geopend. Dit helpt bij het vinden van een record in een enkele zoekopdracht.
• De trailer is een aanwijzer die naar het metablok van de HFile verwijst. Het wordt aan het einde van het vastgelegde bestand geschreven. Het bevat informatie over tijdstempel en bloeifilters.
• Bloom Filter helpt bij het zoeken naar sleutelwaardeparen, het slaat het bestand over dat niet de vereiste rowkey bevat. Tijdstempel helpt ook bij het zoeken naar een versie van het bestand, het helpt bij het overslaan van de gegevens.

Na kennis te hebben genomen van het schrijfmechanisme en de rol van verschillende componenten bij het sneller maken van schrijven en zoeken. Ik zal je uitleggen hoe het leesmechanisme werkt binnen een HBase-architectuur? Daarna gaan we naar de mechanismen die de HBase-prestaties verhogen, zoals verdichting, regio-opsplitsing en herstel.

HBase-architectuur: Lees Mechanism

Zoals besproken in ons zoekmechanisme, haalt de client eerst de locatie van de Region Server op van .META Server als de client deze niet in zijn cachegeheugen heeft. Vervolgens doorloopt het de opeenvolgende stappen als volgt:

• Voor het lezen van de gegevens zoekt de scanner eerst naar de rijcel in de blokcache. Hier worden alle recent gelezen sleutelwaardeparen opgeslagen.
• Als Scanner het vereiste resultaat niet kan vinden, gaat het naar de MemStore, omdat we weten dat dit het schrijfcachegeheugen is. Daar zoekt het naar de meest recent geschreven bestanden, die nog niet in HFile zijn gedumpt.
• Eindelijk zal het bloeifilters en blokcache gebruiken om de gegevens uit HFile te laden.

Tot dusver heb ik het zoek-, lees- en schrijfmechanisme van HBase besproken. Nu gaan we kijken naar het HBase-mechanisme dat zoeken, lezen en schrijven in HBase snel maakt. Ten eerste zullen we het begrijpen Verdichting , wat een van die mechanismen is.

HBase-architectuur: Verdichting

HBase combineert HFiles om de opslag te verminderen en het aantal schijfzoekopdrachten dat nodig is voor het lezen te verminderen. Dit proces heet verdichting . Verdichting kiest enkele HFiles uit een regio en combineert ze. Er zijn twee soorten verdichting, zoals u kunt zien in de bovenstaande afbeelding.

1. Kleine verdichting : HBase kiest automatisch kleinere HFiles en plaatst ze opnieuw in grotere HFiles, zoals weergegeven in de bovenstaande afbeelding. Dit wordt kleine verdichting genoemd. Het voert een samenvoegsortering uit voor het vastleggen van kleinere HFiles naar grotere HFiles. Dit helpt bij het optimaliseren van opslagruimte.
2. Grote verdichting: Zoals geïllustreerd in de bovenstaande afbeelding, voegt HBase bij Grote verdichting de kleinere HFiles van een regio samen en voegt ze opnieuw toe aan een nieuwe HFile. In dit proces worden dezelfde kolomfamilies bij elkaar geplaatst in de nieuwe HFile. In dit proces worden verwijderde en verlopen cellen verwijderd. Het verhoogt de leesprestaties.

Maar tijdens dit proces kunnen invoer-uitvoerschijven en netwerkverkeer overbelast raken. Dit staat bekend als schrijf versterking . Het is dus over het algemeen gepland tijdens lage piekbelastingtijden.

Nu is een ander prestatie-optimalisatieproces dat ik zal bespreken Regio Split . Dit is erg belangrijk voor taakverdeling.

HBase-architectuur: Regio Split

De onderstaande afbeelding illustreert het mechanisme voor regiosplitsing.

Elke keer dat een regio groot wordt, wordt deze verdeeld in twee onderliggende regio's, zoals weergegeven in de bovenstaande afbeelding. Elke regio vertegenwoordigt precies de helft van de bovenliggende regio. Vervolgens wordt deze splitsing gerapporteerd aan de HMaster. Dit wordt afgehandeld door dezelfde Region Server totdat de HMaster ze toewijst aan een nieuwe Region Server voor taakverdeling.

Verderop, last but not least, zal ik u uitleggen hoe HBase gegevens herstelt na een storing. Zoals we dat weten Herstel van fouten is een zeer belangrijke functie van HBase, dus laat ons weten hoe HBase gegevens herstelt na een storing.

HBase-architectuur: HBase-crash en gegevensherstel

• Elke keer dat een regioserver uitvalt, brengt ZooKeeper de HMaster op de hoogte van de storing.
• Vervolgens verdeelt HMaster de regio's van de vastgelopen regioserver en wijst deze toe aan vele actieve regioservers. Om de gegevens van de MemStore van de defecte regioserver te herstellen, distribueert de HMaster de WAL naar alle regioservers.
• Elke regioserver voert de WAL opnieuw uit om de MemStore te bouwen voor de kolomfamilie van die mislukte regio.
• De gegevens worden in chronologische volgorde (in een tijdige volgorde) in WAL geschreven. Daarom betekent het opnieuw uitvoeren van die WAL het aanbrengen van alle wijzigingen die zijn aangebracht en opgeslagen in het MemStore-bestand.
• Dus nadat alle regioservers de WAL hebben uitgevoerd, worden de MemStore-gegevens voor alle kolomfamilies hersteld.

Ik hoop dat deze blog je zou hebben geholpen bij het onderschatten van het HBase Data Model & HBase Architecture. Ik hoop dat je ervan genoten hebt. Nu kunt u zich verhouden tot de kenmerken van HBase (die ik in mijn vorige HBase-zelfstudie blog) met HBase Architecture en begrijp hoe het intern werkt. Nu u het theoretische deel van HBase kent, moet u naar het praktische deel gaan. Met dit in gedachten houden onze volgende blog van zal een voorbeeld toelichten HBase POC .

hoe classpath in windows in te stellen

Nu je de HBase-architectuur hebt begrepen, kun je het door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. De Edureka Big Data Hadoop-certificeringstraining helpt leerlingen expert te worden in HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume en Sqoop met behulp van real-time use cases op het gebied van Retail, Social Media, Aviation, Tourism, Finance.

Heeft u een vraag voor ons? Vermeld het in het opmerkingengedeelte en we nemen contact met u op.