sql >> Databasteknik >  >> NoSQL >> HBase

Vad är HBase-znoder?

Apache ZooKeeper är ett klient/serversystem för distribuerad koordination som exponerar ett gränssnitt som liknar ett filsystem, där varje nod (kallad en znod ) kan innehålla data och en uppsättning barn. Varje znod har ett namn och kan identifieras med en filsystemliknande sökväg (till exempel /root-znode/sub-znode/my-znode).

I Apache HBase koordinerar, kommunicerar och delar ZooKeeper tillstånd mellan Masters och RegionServers. HBase har en designpolicy att använda ZooKeeper endast för transienta data (det vill säga för koordinering och tillståndskommunikation). Om HBases ZooKeeper-data tas bort så påverkas endast de övergående operationerna – data kan fortsätta att skrivas och läsas till/från HBase.

I det här blogginlägget får du en kort rundtur i HBase-znodes användning. Den version av HBase som används som referens här är 0,94 (levereras inuti CDH 4.2 och CDH 4.3), men de flesta znoderna finns i tidigare versioner och kommer sannolikt också att vara det i framtida versioner.

HBase rotznode-sökväg kan konfigureras med hbase-site.xml, och som standard är platsen "/hbase". Alla znoder som hänvisas till nedan kommer att ha prefix med standardplatsen /hbase, och konfigurationsegenskapen som låter dig byta namn på den specifika znoden kommer att listas bredvid standard znodnamnet och markeras med fet stil.

ZooKeeper tillhandahåller ett interaktivt skal som låter dig utforska ZooKeeper-tillståndet – kör det med hbase zkcli och gå igenom znoden via ls , som i ett typiskt filsystem. Du kan också få lite information om znodens innehåll genom att använda get kommando.

$ hbase zkcli
[zk: localhost:2181(CONNECTED) 0] ls /
[hbase, zookeeper]
[zk: localhost:2181(CONNECTED) 1] ls /hbase
[splitlog, online-snapshot, unassigned, root-region-server, rs, backup-masters, draining, table, master, shutdown, hbaseid]
[zk: localhost:2181(CONNECTED) 2] get /hbase/root-region-server
3008@u1310localhost,60020,1382107614265
dataLength = 44
numChildren = 0
...

Verksamhet

Znoderna som du oftast ser är de som koordinerar operationer som Region Assignment, Log Splitting och Master Failover, eller håller reda på klustertillståndet som ROOT-tabellens plats, lista över online-regionservrar och lista över otilldelade regioner .

/hbase (zookeeper.znode.parent) Rot-znoden som kommer att innehålla alla znoder som skapats/används av HBase
/hbase/hbaseid (zookeeper.znode.clusterId) Initialiserad av mastern med UUID som identifierar klustret. ID:t lagras också på HDFS i hdfs:/:/hbase/hbase.id.
/hbase/root-region-server (zookeeper.znode.rootserver) Innehåller platsen för servern som är värd för ROOT-regionen. Den frågas av klienten att identifiera den RegionServer som är ansvarig för ROOT och fråga efter META-platserna. (I 0.96 togs ROOT-tabellen bort som en del av HBASE-3171, och denna znod ersätts av /hbase/meta-region-server [zookeeper.znode.metaserver] som innehåller platsen för servern som är värd META.)
/hbase/rs (zookeeper.znode.rs) Vid uppstart kommer varje RegionServer att skapa en sub-znod (t.ex. /hbase/rs/m1.host) som är tänkt att beskriva "online"-tillståndet för RegionServer. Mastern övervakar denna znod för att få "online" RegionServer-listan och använda den under tilldelning/balansering.
/hbase/ej tilldelad (zookeeper.znode.unassigned) Innehåller en sub-znod för varje otilldelad region (t.ex. /hbase/unassigned/). Denna znod används av tilldelningshanteraren för att upptäcka de regioner som ska tilldelas. (Läs detta för att lära dig mer om uppdragshanteraren.)
/hbase/master (zookeeper.znode.master) Den "aktiva" mastern kommer att registrera sin egen adress i denna znod vid start, vilket gör denna znod till sanningskällan för att identifiera vilken server som är mastern.
/hbase/backup-masters (zookeeper.znode.backup.masters) Varje inaktiv Master kommer att registrera sig som backup Master genom att skapa en sub-znod (hbase/backup-master/m1.host). Denna znod används huvudsakligen för att spåra vilka maskiner som är tillgängliga för att ersätta Mastern i händelse av fel.
/hbase/avstängning (zookeeper.znode.state) Beskriver klustertillståndet, "Är klustret uppe?" Den skapas av mastern vid uppstart och raderas av mastern vid avstängning. Den bevakas av RegionServers.
/hbase/tömning (zookeeper.znode.draining.rs) Används för att avveckla mer än en RegionServer åt gången genom att skapa sub-znoder med formen serverName,port,startCode (till exempel /hbase/draining/m1.host,60020,1338936306752). Detta låter dig avveckla flera RegionServers utan att riskera att regioner tillfälligt flyttas till en RegionServer som kommer att avvecklas senare. Läs detta för att lära dig mer om /hbase/draining.
/hbase/tabell (zookeeper.znode.masterTableEnableDisable) Används av mastern för att spåra tabelltillståndet under tilldelningar (till exempel inaktivera/aktivera tillstånd).
/hbase/splitlog (zookeeper.znode.splitlog) Används av loggdelaren för att spåra den väntande loggen som ska spelas om och dess tilldelning. (Läs detta för att lära dig mer om stockklyvning).

Säkerhet

Access Control List (ACL) och Token Provider-samprocessorerna lägger till ytterligare två znoder:en för att synkronisera åtkomst till tabell-ACL och den andra för att synkronisera token-krypteringsnycklarna över klusternoderna.

/hbase/acl (zookeeper.znode.acl.parent) acl znoden används för att synkronisera ändringarna som gjorts i tabellen _acl_ av grant/revoke-kommandona. Varje tabell kommer att ha en sub-znod (/hbase/acl/tabellnamn) som innehåller tabellens ACL:er. (Läs detta för mer information om åtkomstkontrollern och ZooKeeper-interaktionen.)
/hbase/tokenauth (zookeeper.znode.tokenauth.parent) Tokenleverantören används vanligtvis för att ge ett MapReduce-jobb åtkomst till HBase-klustret. När en användare ber om en ny token kommer informationen att lagras i en sub-znod skapad för nyckeln (/hbase/tokenauth/keys/key-id).

Replikering

Som en allmän regel är alla znoder tillfälliga, vilket betyder att de beskriver ett "tillfälligt" tillstånd - så även om du tar bort allt från ZooKeeper bör HBase kunna återskapa dem. Även om replikeringsznoderna inte beskriver ett temporärt tillstånd, är de avsedda att vara källan till sanning för replikeringstillståndet, och beskriver replikeringstillståndet för varje maskin. (Läs detta för att lära dig mer om replikering).

/hbase/replikering (zookeeper.znode.replication) Rootznod som innehåller all HBase-replikeringsstatusinformation
/hbase/replikering/peers (zookeeper.znode.replication.peers) Varje peer kommer att ha en sub-znod (t.ex. /hbase/replication/peers/) som innehåller ZK-ensemblens adresser som gör att peern kan kontaktas.
/hbase/replikering/peers//peer-state (zookeeper.znode.replication.peers.state) Spegling av /hbase/replication/peers-znoden, men här kommer varje sub-znod (/hbase/replication/peer-state/) att spåra peer-aktiverad/inaktiverad status.
/hbase/replikering/tillstånd (zookeeper.znode.replication.state) Anger om replikering är aktiverad. Replikering kan aktiveras genom att ställa in hbase.replication-konfigurationen till true, eller kan aktiveras/inaktiveras genom att använda start/stopp-kommandot i HBase-skalet. (I 0.96 togs denna znod bort och peer-state znoden ovan används som referens.)
/hbase/replikering/rs (zookeeper.znode.replication.rs) Innehåller listan över RegionServers i huvudklustret (/hbase/replikation/rs/). Och för varje RegionServer-znod finns det en sub-znod per peer som den replikerar till. Inuti peer-sub-znoden väntar hlogs på att replikeras (/hbase/replication/rs///).

Snapshotprocedurer online

Online-ögonblicksbilder koordineras av mästaren som använder ZooKeeper för att kommunicera med RegionServers med hjälp av en tvåfas-commit-liknande transaktion. (Läs detta för mer information om ögonblicksbilder.)

/hbase/online-snapshot/acquired Den förvärvade znoden beskriver det första steget i en ögonblicksbildstransaktion. Mastern kommer att skapa en sub-znod för ögonblicksbilden (/hbase/online-snapshot/acquired/). Varje RegionServer kommer att meddelas om skapande av znod och förbereda ögonblicksbilden; när de är klara kommer de att skapa en sub-znod med RegionServer-namnet som betyder "jag är klar" (/hbase/online-snapshot/acquired//m1.host).
/hbase/online-snapshot/reached När varje RegionServer har anslutit sig till den förvärvade znoden kommer Mastern att skapa den nådda znoden för ögonblicksbilden (/hbase/online-snapshot/reached/) och tala om för varje RegionServer att det är dags att slutföra/ begå ögonblicksbilden. Återigen kommer varje RegionServer att skapa en sub-znod för att meddela mastern att arbetet är klart.
/hbase/online-snapshot/abort Om något misslyckas på Master-sidan eller RegionServer-sidan, skapas avbrytningsznoden för ögonblicksbilden som talar om för alla att något gick fel med ögonblicksbilden och för att avbryta jobbet.

Slutsats

Som du kan se är ZooKeeper en grundläggande del av HBase. Alla operationer som kräver samordning, såsom regiontilldelning, Master-Failover, replikering och ögonblicksbilder, är byggda på ZooKeeper. (Du kan lära dig mer om varför/hur du skulle använda ZooKeeper i dina applikationer här.)

Även om de flesta znoder bara är användbara för HBase, kan vissa — såsom listan över RegionServers (/hbase/rs) eller listan över icke tilldelade regioner (/hbase/unassigned) — användas för felsöknings- eller övervakningsändamål. Eller, som i fallet med /hbase/draining, kan du interagera med dem för att låta HBase veta vad du gör med klustret.

Matteo Bertozzi är en mjukvaruingenjör på Cloudera och en Committer på HBase-projektet.


  1. MongoDB Database Deployment Automation

  2. Hur man använder ActionController::Lev tillsammans med Resque + Redis (för chattapplikation)

  3. Finns det ett sätt att automatiskt upptäcka ny klusternod IP i Redis Cluster med sallad

  4. Mongodb:flera samlingar eller en stor samling med index