Dit bericht is oorspronkelijk gepubliceerd via blogs.apache.org, we publiceren het hier voor uw gemak opnieuw in een enigszins aangepaste vorm:
Op het eerste gezicht lijkt de Apache HBase-architectuur een master/slave-model te volgen waarbij de master alle verzoeken ontvangt, maar het echte werk wordt gedaan door de slaves. Dit is niet het geval, en in dit artikel zal ik beschrijven welke taken in feite door de master en de slaves worden uitgevoerd.
Regio's en regioservers
HBase is de Hadoop-opslagmanager die willekeurige lees- en schrijfbewerkingen met lage latentie biedt bovenop HDFS en petabytes aan gegevens aankan. Een van de interessante mogelijkheden in HBase is auto-sharding, wat simpelweg betekent dat tabellen dynamisch door het systeem worden gedistribueerd wanneer ze te groot worden.
De basiseenheid van horizontale schaalbaarheid in HBase wordt een Regio . genoemd . Regio's zijn een subset van de tabelgegevens en zijn in wezen een aaneengesloten, gesorteerde reeks rijen die samen worden opgeslagen.
Aanvankelijk is er slechts één regio voor een tafel. Zoals hieronder wordt getoond, wanneer regio's te groot worden na het toevoegen van meer rijen, wordt de regio in tweeën gesplitst bij de middelste toets, waardoor twee ongeveer gelijke helften ontstaan.
In HBase heten de slaves Regioservers . Elke regioserver is verantwoordelijk voor het bedienen van een reeks regio's, en één regio (d.w.z. een reeks rijen) kan slechts door één regioserver worden bediend.
De HBase-architectuur heeft twee hoofdservices:HMaster die verantwoordelijk is voor het coördineren van het cluster en het uitvoeren van administratieve handelingen, en de HRegionServer verantwoordelijk voor het verwerken van een subset van de tabelgegevens.
HMaster, regiotoewijzing en balanceren
Zoals eerder vermeld coördineert de HBase Master het HBase Cluster en is hij verantwoordelijk voor de administratieve bedrijfsvoering.
Een regioserver kan een of meer regio's bedienen. Elke regio wordt bij het opstarten toegewezen aan een regioserver en de master kan besluiten om een regio van de ene regioserver naar de andere te verplaatsen als gevolg van een taakverdelingsbewerking. De Master handelt ook Region Server-storingen af door de regio aan een andere Region Server toe te wijzen.
De toewijzing van regio's en regioservers wordt bijgehouden in een systeemtabel met de naam META. Door META te lezen, kunt u identificeren welke regio verantwoordelijk is voor uw sleutel. Dit betekent dat voor lees- en schrijfbewerkingen de master helemaal niet betrokken is en clients rechtstreeks naar de verantwoordelijke Region Server kunnen gaan om de gevraagde gegevens te leveren.
Een rijsleutel zoeken:welke regioserver is verantwoordelijk?
Om een rij te plaatsen of te krijgen, hoeven clients geen contact op te nemen met de master, kunnen clients rechtstreeks contact opnemen met de regioserver die de opgegeven rij afhandelt, of in het geval van een clientscan kunnen ze rechtstreeks contact opnemen met de set regioservers die verantwoordelijk is voor het afhandelen van de set aantal toetsen:
Om de regioserver te identificeren, voert de client een query uit op de META-tabel.
META is een systeemtabel die wordt gebruikt om regio's bij te houden. Het bevat de servernaam en een regio-ID bestaande uit een tabelnaam en de startrijsleutel. Door naar de startsleutel en de startsleutel van de volgende regio te kijken, kunnen clients het bereik van rijen in een bepaalde regio identificeren.
De client houdt een cache bij voor de regiolocaties. Dit voorkomt dat klanten de META-tabel raken telkens wanneer een bewerking in dezelfde regio wordt uitgevoerd. In het geval van een regiosplitsing of verplaatsing naar een andere regioserver (vanwege balancering of toewijzingsbeleid), ontvangt de klant een uitzondering als reactie en wordt de cache vernieuwd door de bijgewerkte informatie uit de META-tabel op te halen:
Aangezien META een tabel is zoals de andere, moet de klant identificeren op welke server META zich bevindt. De META-locaties worden in opdracht van de Master opgeslagen in een ZooKeeper-node en de client leest de node rechtstreeks uit om het adres te krijgen van de Region Server die META bevat.
Het oorspronkelijke ontwerp van HBase was gebaseerd op BigTable, met een andere tabel genaamd -ROOT- die de META-locaties bevat en Apache ZooKeeper ernaar verwijst. HBase 0.96 heeft die regeling verwijderd ten gunste van alleen ZooKeeper, aangezien META niet kan worden opgesplitst en daarom uit één regio bestaat.
Client API:hoofd- en regioverantwoordelijkheden
De HBase Java-client-API heeft twee hoofdinterfaces:
- HBaseAdmin maakt interactie met het "tabelschema" mogelijk door tabellen te maken/verwijderen/wijzigen, en het maakt interactie met het cluster mogelijk door regio's toe te wijzen/verwijderen, regio's samen te voegen, een flush aan te roepen, enzovoort. Deze interface communiceert met de Master.
- HTable stelt de client in staat om de gegevens van een opgegeven tabel te manipuleren met behulp van get, put, delete en alle andere gegevensbewerkingen. Deze interface communiceert rechtstreeks met de regioservers die verantwoordelijk zijn voor het afhandelen van de gevraagde set sleutels.
Die twee interfaces hebben afzonderlijke verantwoordelijkheden:HBaseAdmin wordt alleen gebruikt om beheerdersbewerkingen uit te voeren en te communiceren met de master, terwijl de HTable wordt gebruikt om gegevens te manipuleren en te communiceren met de regio's.
Conclusie
Zoals we hier hebben gezien, betekent het hebben van een Master/Slave-architectuur niet dat elke bewerking door de master gaat. Om gegevens te lezen en te schrijven, gaat de HBase-client in feite rechtstreeks naar de specifieke regioserver die verantwoordelijk is voor het afhandelen van de rijsleutels voor alle gegevensbewerkingen (HTable). De Master wordt door de client alleen gebruikt voor het maken, wijzigen en verwijderen van tabellen (HBaseAdmin).
Hoewel het concept van een master bestaat, is de HBase-client er niet van afhankelijk voor gegevensbewerkingen en kan het cluster gegevens blijven leveren, zelfs als de master uitvalt.
Matteo Bertozzi is Software Engineer in het Platform-team en een HBase Committer.
Als u geïnteresseerd bent in HBase, moet u zich registreren voor HBaseCon 2013 (13 juni San Francisco) - HET community-evenement voor HBase-bijdragers, ontwikkelaars, beheerders en gebruikers. De ruimte is beperkt!