Regio's in HBase - dummies

RegioServers zijn één ding, maar u moet ook kijken naar hoe individuele regio's werken. In HBase is een tabel zowel verspreid over een aantal RegionServers als samengesteld uit afzonderlijke regio's. Naarmate tabellen worden gesplitst, worden de splitsingen regio's. Regio's slaan een reeks sleutel / waarde-paren op en elke RegionServer beheert een configureerbaar aantal regio's.

Maar hoe zien de afzonderlijke regio's eruit? HBase is een kolomgezinsgeoriënteerde gegevensopslag, dus hoe slaan de afzonderlijke regio's sleutel / waarde-paren op gebaseerd op de kolomfamilies waartoe ze behoren? De volgende figuur begint deze vragen te beantwoorden en helpt u meer essentiële informatie over de architectuur van HBase te verteren.

HBase is geschreven in Java - zoals de overgrote meerderheid van Hadoop-technologieën. Java is een objectgeoriënteerde programmeertaal en een elegante technologie voor gedistribueerd computergebruik. Dus, terwijl je steeds meer te weten komt over HBase, onthoud dat alle componenten in de architectuur uiteindelijk Java-objecten zijn.

Ten eerste geeft de voorgaande figuur een vrij goed beeld van hoe regio-objecten er in het algemeen eigenlijk uitzien. Het maakt ook duidelijk dat regio's gegevens scheiden in kolomfamilies en de gegevens opslaan in de HDFS met behulp van HFile-objecten.

Wanneer clients sleutel / waarde-paren in het systeem plaatsen, worden de sleutels verwerkt zodat gegevens worden opgeslagen op basis van de kolomfamilie waartoe het paar behoort. Zoals in de figuur wordt getoond, heeft elk kolomarchiefobject een leescache die de BlockCache wordt genoemd en een schrijfcache die de MemStore wordt genoemd. De BlockCache helpt bij willekeurige leesprestaties.

Gegevens worden in blokken van de HDFS gelezen en opgeslagen in de BlockCache. Latere uitlezingen voor de gegevens - of gegevens die dicht bij elkaar zijn opgeslagen - zullen worden gelezen uit het RAM in plaats van de schijf, waardoor de algehele prestaties verbeteren. Het Write Ahead Log (kortweg WAL) zorgt ervoor dat uw HBase-publicaties betrouwbaar zijn. Er is één WAL per RegionServer.

Houd altijd rekening met de Iron Law of Distributed Computing: een fout is geen uitzondering - het is de norm, vooral wanneer honderden of zelfs duizenden servers worden gebundeld. Google volgde de Iron Law bij het ontwerpen van BigTable en HBase volgde.

Wanneer u gegevens in HBase schrijft of wijzigt, worden de gegevens eerst bewaard in de WAL, die is opgeslagen in de HDFS, en vervolgens worden de gegevens weggeschreven naar de MemStore-cache. Met configureerbare intervallen worden sleutel / waarde-paren die zijn opgeslagen in de MemStore naar HFiles in de HDFS geschreven en worden WAL-vermeldingen daarna gewist.

Als er een fout optreedt na de oorspronkelijke WAL-schrijf maar vóór de definitieve MemStore-schijf, kan de WAL opnieuw worden afgespeeld om gegevensverlies te voorkomen.

Drie HFile-objecten bevinden zich in de ene kolomfamilie en twee in de andere. Het ontwerp van HBase is om kolomfamiliegegevens die zijn opgeslagen in de MemStore te spoelen tot één HFile per flush. Vervolgens worden op configureerbare intervallen HFiles gecombineerd tot grotere HFiles. Met deze strategie wordt de kritische verdichtingsbewerking in HBase in de wachtrij geplaatst.