hoe scannerklasse te gebruiken
Laten we in de post van vandaag ingaan op de HBase-architectuur. Laten we onze basisprincipes van HBase opfrissen voordat we dieper ingaan op HBase-architectuur.
HBase - De basis:
HBase is een open-source, NoSQL, gedistribueerde, niet-relationele, versienummer, multidimensionale, kolomgeoriënteerde winkel die is gemodelleerd naar Google BigTable die bovenop HDFS draait. 'NoSQL' is een brede term die betekent dat de database geen RDBMS is dat SQL ondersteunt als de primaire toegangstaal. Er zijn echter veel soorten NoSQL-databases en Berkeley DB is een goed voorbeeld van een lokale NoSQL-database, terwijl HBase dat wel is. in feite een gedistribueerde database.
HBase biedt alle functies van Google BigTable. Het begon als een project van Powerset om enorme hoeveelheden gegevens te verwerken voor het zoeken in natuurlijke taal. Het is ontwikkeld als onderdeel van het Hadoop-project van Apache en draait op HDFS (Hadoop Distributed File System). Het biedt fouttolerante manieren om grote hoeveelheden schaarse gegevens op te slaan. HBase is eigenlijk meer een 'Data Store' dan 'Data Base' omdat het veel van de functies mist die beschikbaar zijn in RDBMS, zoals getypte kolommen, secundaire indexen, triggers en geavanceerde querytalen, enz.
In de Kolomgeoriënteerde databases wordt de gegevenstabel opgeslagen als secties van kolommen met gegevens in plaats van als rijen met gegevens. Het datamodel van een kolomgeoriënteerde database bestaat uit tabelnaam, rijsleutel, kolomfamilie, kolommen, tijdstempel. Bij het maken van tabellen in HBase, worden de rijen uniek geïdentificeerd met behulp van rijsleutels en tijdstempel. In dit datamodel is de kolomfamilie statisch, terwijl kolommen dynamisch zijn. Laten we nu eens kijken naar de HBase-architectuur.
Wanneer ga je voor HBase?
HBase is alleen een goede optie als er honderden miljoenen of miljarden rijen zijn. HBase kan ook worden gebruikt op plaatsen waar wordt overwogen om van een RDBMS naar HBase over te stappen als een volledig herontwerp in plaats van een poort. Met andere woorden, HBase is niet geoptimaliseerd voor klassieke transactionele toepassingen of zelfs relationele analyses. Het is ook geen volledige vervanging voor HDFS bij het uitvoeren van grote batches MapReduce. Waarom zou je dan voor HBase gaan ?? Als uw toepassing een variabel schema heeft waarbij elke rij enigszins verschilt, moet u HBase bekijken.
HBase-architectuur:
In de volgende afbeelding wordt de HBase-architectuur duidelijk uitgelegd.
cross-browser testen met behulp van selenium
In HBase zijn er drie hoofdcomponenten: Master, Region server en Zoo keeper . De andere componenten zijn Memstore, HFile en WAL.
Omdat HBase bovenop HDFS draait, maakt het gebruik van de Master-Slave-architectuur waarin de HMaster het masterknooppunt is en de Region Servers de slaafknooppunten. Wanneer de client een schrijfverzoek verzendt, ontvangt HMaster dat verzoek en stuurt het door naar de respectieve regioserver.
Regio Server:
Het is een systeem dat op dezelfde manier werkt als een dataknooppunt. Wanneer Region Server (RS) een schrijfverzoek ontvangt, stuurt het het verzoek naar een specifieke regio. Elke regio slaat een reeks rijen op. Gegevens van rijen kunnen worden gescheiden in meerdere kolomfamilies (CF's). Gegevens van een bepaalde CF worden opgeslagen in HStore, die bestaat uit Memstore en een set HFiles.
Wat doet Memstore?
Memstore houdt alle logboeken bij voor de lees- en schrijfbewerkingen die zijn uitgevoerd binnen die specifieke regioserver. Hieruit kunnen we zeggen dat het vergelijkbaar is met een naamknooppunt in Hadoop. Memstore is een opslag in het geheugen, daarom gebruikt de Memstore de opslag in het geheugen van elk dataknooppunt om de logboeken op te slaan. Wanneer aan bepaalde drempels is voldaan, worden Memstore-gegevens in HFile gespoeld.
Het belangrijkste doel van het gebruik van Memstore is de noodzaak om gegevens op te slaan op DFS, gerangschikt op rijsleutel. Aangezien HDFS is ontworpen voor opeenvolgende lees- / schrijfbewerkingen, zonder dat bestandswijzigingen zijn toegestaan, kan HBase gegevens niet efficiënt naar de schijf schrijven terwijl deze wordt ontvangen: de geschreven gegevens worden niet gesorteerd (wanneer de invoer niet is gesorteerd), wat betekent dat ze niet zijn geoptimaliseerd voor toekomstig ophalen. Om dit probleem op te lossen, buffert HBase de laatst ontvangen gegevens in het geheugen (in Memstore), 'sorteert' ze deze voordat ze worden leeggemaakt en schrijft ze vervolgens naar HDFS met behulp van snelle sequentiële schrijfbewerkingen. Daarom bevat HFile een lijst met gesorteerde rijen.
Elke keer dat Memstore-flush plaatsvindt, wordt er één HFile gemaakt voor elke CF en frequente flushes kunnen tonnen HFiles creëren. Aangezien HBase tijdens het lezen naar veel HFiles zal moeten kijken, kan de leessnelheid eronder lijden. Om te voorkomen dat te veel HFiles worden geopend en verslechtering van de leesprestaties te voorkomen, wordt het HFiles-verdichtingsproces gebruikt. HBase zal periodiek (wanneer aan bepaalde configureerbare drempels is voldaan) meerdere kleinere HFiles comprimeren tot een grote. Het is duidelijk dat hoe meer bestanden worden gemaakt door Memstore-flushes, hoe meer werk (extra belasting) voor het systeem zal zijn. Daar komt nog bij dat, terwijl het verdichtingsproces gewoonlijk parallel wordt uitgevoerd met het dienen van andere verzoeken en wanneer HBase het verdichten van HFiles niet kan bijhouden (ja, daar zijn ook geconfigureerde drempels voor), zal het schrijfbewerkingen op RS weer blokkeren. Zoals we hierboven hebben besproken, is dit hoogst ongewenst.
We kunnen er niet zeker van zijn dat de gegevens in Memstore blijvend zijn. Stel dat een bepaalde datanode niet werkt. Dan gaan de gegevens die zich in het geheugen van dat gegevensknooppunt bevinden, verloren.
Om dit probleem op te lossen, wordt het verzoek, wanneer het van de master komt, ook naar WAL geschreven. WAL is niets anders dan Schrijf vooruit Logs die zich op de HDFS bevindt, een permanente opslag. Nu kunnen we ervoor zorgen dat zelfs als het gegevensknooppunt niet beschikbaar is, de gegevens niet verloren gaan, d.w.z. we hebben de kopie van alle acties die u zou moeten doen in de WAL. Als het dataknooppunt actief is, zal het alle activiteiten opnieuw uitvoeren. Zodra de bewerking is voltooid, wordt alles uit Memstore en WAL verwijderd en in HFile geschreven om ervoor te zorgen dat het geheugen niet vol raakt.
Laten we een eenvoudig voorbeeld nemen dat ik rij 10 wil toevoegen, dan komt dat schrijfverzoek binnen, het zegt dat het alle metagegevens aan de Memstore en WAL geeft. Zodra die specifieke rij in HFile is geschreven, wordt alles in Memstore en WAL weggespoeld.
Dierentuinmedewerker:
HBase is geïntegreerd met Zoo keeper. Wanneer ik HBase start, wordt ook de Zoo Keeper-instantie gestart. De reden is dat de Zoo keeper ons helpt bij het bijhouden van alle regioservers die er voor HBase zijn. Zoo keeper houdt bij hoeveel regioservers er zijn, welke regioservers van welk dataknooppunt naar welk dataknooppunt houden. Het houdt kleinere datasets bij waar Hadoop misloopt. Het verlaagt de overhead bovenop Hadoop, die de meeste van uw metagegevens bijhoudt. Daarom verkrijgt HMaster de details van regioservers door daadwerkelijk contact op te nemen met Zoo keeper.
Heeft u een vraag voor ons? Noem ze in het opmerkingengedeelte en we nemen contact met u op.
php maak een array van string
Gerelateerde berichten: