Dieser Beitrag wurde ursprünglich über blogs.apache.org veröffentlicht, wir veröffentlichen ihn hier in einer leicht modifizierten Form für Ihre Bequemlichkeit:
Auf den ersten Blick scheint die Apache HBase-Architektur einem Master/Slave-Modell zu folgen, bei dem der Master alle Anfragen erhält, die eigentliche Arbeit jedoch von den Slaves erledigt wird. Dies ist nicht der Fall, und in diesem Artikel werde ich beschreiben, welche Aufgaben der Master und die Slaves tatsächlich übernehmen.
Regionen und Regionsserver
HBase ist der Hadoop-Speichermanager, der neben HDFS zufällige Lese- und Schreibvorgänge mit geringer Latenz bietet und Petabytes an Daten verarbeiten kann. Eine der interessanten Funktionen in HBase ist Auto-Sharding, was einfach bedeutet, dass Tabellen vom System dynamisch verteilt werden, wenn sie zu groß werden.
Die grundlegende Einheit der horizontalen Skalierbarkeit in HBase wird als Region bezeichnet . Regionen sind eine Teilmenge der Tabellendaten und im Wesentlichen ein zusammenhängender, sortierter Bereich von Zeilen, die zusammen gespeichert werden.
Anfänglich gibt es nur eine Region für eine Tabelle. Wie unten gezeigt, werden Regionen, die nach dem Hinzufügen weiterer Zeilen zu groß werden, an der mittleren Taste in zwei Teile geteilt, wodurch zwei ungefähr gleiche Hälften entstehen.
In HBase heißen die Slaves Regionsserver . Jeder Regionsserver ist dafür verantwortlich, eine Reihe von Regionen zu bedienen, und eine Region (d. h. ein Zeilenbereich) kann nur von einem Regionsserver bedient werden.
Die HBase-Architektur hat zwei Hauptdienste:HMaster der dafür verantwortlich ist, den Cluster zu koordinieren und Verwaltungsvorgänge auszuführen, und der HRegionServer verantwortlich für die Handhabung einer Teilmenge der Tabellendaten.
HMaster, Regionszuweisung und Ausgleich
Wie bereits erwähnt, koordiniert der HBase-Master den HBase-Cluster und ist für den administrativen Betrieb verantwortlich.
Ein Regionsserver kann eine oder mehrere Regionen bedienen. Jede Region wird beim Start einem Regionsserver zugewiesen, und der Master kann als Ergebnis eines Lastausgleichsvorgangs entscheiden, eine Region von einem Regionsserver auf einen anderen zu verschieben. Der Master behandelt auch Regionsserverausfälle, indem er die Region einem anderen Regionsserver zuweist.
Die Zuordnung von Regionen und Regionsservern wird in einer Systemtabelle namens META gespeichert. Durch Lesen von META können Sie feststellen, welche Region für Ihren Schlüssel verantwortlich ist. Das bedeutet, dass bei Lese- und Schreiboperationen der Master überhaupt nicht involviert ist und Clients direkt zu dem Regionsserver gehen können, der für die Bereitstellung der angeforderten Daten verantwortlich ist.
Auffinden eines Zeilenschlüssels:Welcher Regionsserver ist zuständig?
Um eine Zeile zu platzieren oder abzurufen, müssen Clients nicht den Master kontaktieren, Clients können direkt den Regionsserver kontaktieren, der die angegebene Zeile verarbeitet, oder im Falle eines Client-Scans direkt die Gruppe von Regionsservern kontaktieren, die für die Verarbeitung der Gruppe verantwortlich sind der Tasten:
Um den Region Server zu identifizieren, führt der Client eine Abfrage in der META-Tabelle durch.
META ist eine Systemtabelle, die verwendet wird, um Regionen zu verfolgen. Es enthält den Servernamen und eine Regionskennung, die aus einem Tabellennamen und dem Startzeilenschlüssel besteht. Durch Betrachten des Startschlüssels und des Startschlüssels der nächsten Region können Clients den Zeilenbereich identifizieren, der in einer bestimmten Region enthalten ist.
Der Client behält einen Cache für die Regionsstandorte. Dadurch wird vermieden, dass Clients jedes Mal auf die META-Tabelle zugreifen, wenn eine Operation für dieselbe Region ausgegeben wird. Im Falle einer Regionsaufteilung oder Verschiebung auf einen anderen Regionsserver (aufgrund von Ausgleichs- oder Zuweisungsrichtlinien) erhält der Client eine Ausnahme als Antwort und der Cache wird aktualisiert, indem die aktualisierten Informationen aus der META-Tabelle abgerufen werden:
Da META eine Tabelle wie die anderen ist, muss der Client erkennen, auf welchem Server sich META befindet. Die META-Standorte werden nach Zuweisung durch den Master in einem ZooKeeper-Knoten gespeichert, und der Client liest direkt den Knoten, um die Adresse des Regionsservers zu erhalten, der META enthält.
Das ursprüngliche Design von HBase basierte auf BigTable, wobei eine andere Tabelle namens -ROOT- die META-Speicherorte enthielt und Apache ZooKeeper darauf zeigte. HBase 0.96 entfernte diese Anordnung zugunsten von ZooKeeper, da META nicht geteilt werden kann und daher aus einer einzigen Region besteht.
Client-API:Verantwortlichkeiten von Master und Regionen
Die HBase-Java-Client-API hat zwei Hauptschnittstellen:
- HBaseAdmin ermöglicht die Interaktion mit dem „Tabellenschema“ durch das Erstellen/Löschen/Ändern von Tabellen, und es ermöglicht die Interaktion mit dem Cluster durch das Zuweisen/Aufheben der Zuweisung von Regionen, das Zusammenführen von Regionen, das Aufrufen eines Flush und so weiter. Diese Schnittstelle kommuniziert mit dem Master.
- HTable ermöglicht dem Client, die Daten einer angegebenen Tabelle zu manipulieren, indem er get, put, delete und alle anderen Datenoperationen verwendet. Diese Schnittstelle kommuniziert direkt mit den Regionsservern, die für die Handhabung des angeforderten Schlüsselsatzes verantwortlich sind.
Diese beiden Schnittstellen haben unterschiedliche Verantwortlichkeiten:HBaseAdmin wird nur verwendet, um Verwaltungsoperationen auszuführen und mit dem Master zu kommunizieren, während HTable verwendet wird, um Daten zu manipulieren und mit den Regionen zu kommunizieren.
Schlussfolgerung
Wie wir hier gesehen haben, bedeutet eine Master/Slave-Architektur nicht, dass jede Operation den Master durchläuft. Um Daten zu lesen und zu schreiben, geht der HBase-Client tatsächlich direkt zu dem spezifischen Regionsserver, der für die Handhabung der Zeilenschlüssel für alle Datenoperationen (HTable) verantwortlich ist. Der Master wird vom Client nur zum Erstellen, Ändern und Löschen von Tabellen verwendet (HBaseAdmin).
Obwohl das Konzept eines Masters existiert, ist der HBase-Client für Datenoperationen nicht darauf angewiesen, und der Cluster kann weiterhin Daten bereitstellen, selbst wenn der Master ausfällt.
Matteo Bertozzi ist Software Engineer im Platform-Team und HBase-Committer.
Wenn Sie an HBase interessiert sind, melden Sie sich auf jeden Fall für die HBaseCon 2013 (13. Juni, San Francisco) an – DIE Community-Veranstaltung für HBase-Mitwirkende, Entwickler, Administratoren und Benutzer. Der Platz ist begrenzt!
