Video: HDInsight: Fast Interactive Queries with Hive on LLAP | Azure Friday 2025
RegionServers sind eine Sache, aber Sie müssen auch einen Blick darauf werfen, wie einzelne Regionen funktionieren. In HBase ist eine Tabelle sowohl auf eine Anzahl von RegionServern verteilt als auch aus einzelnen Regionen zusammengesetzt. Wenn Tabellen aufgeteilt werden, werden die Teilungen zu Regionen. Regionen speichern eine Reihe von Schlüssel-Wert-Paaren und jeder RegionServer verwaltet eine konfigurierbare Anzahl von Regionen.
Wie aber sehen die einzelnen Regionen aus? HBase ist ein spaltenfamilienorientierter Datenspeicher, also wie speichern die einzelnen Regionen Schlüssel-Wert-Paare basierend auf den Spaltenfamilien, zu denen sie gehören? Die folgende Abbildung fängt an, diese Fragen zu beantworten und hilft Ihnen, wichtige Informationen über die Architektur von HBase zu verdauen.
HBase ist in Java geschrieben - wie die große Mehrheit der Hadoop-Technologien. Java ist eine objektorientierte Programmiersprache und eine elegante Technologie für verteiltes Rechnen. Wenn Sie also weiterhin mehr über HBase erfahren, denken Sie daran, dass alle Komponenten in der Architektur letztendlich Java-Objekte sind.
Zunächst einmal gibt die obige Abbildung eine ziemlich gute Vorstellung davon, wie die Objekte im Allgemeinen aussehen. Es wird auch deutlich, dass Regionen Daten in Spaltenfamilien trennen und die Daten mithilfe von HFile-Objekten im HDFS speichern.
Wenn Clients Schlüsselwertpaare in das System eingeben, werden die Schlüssel so verarbeitet, dass die Daten auf der Grundlage der Spaltenfamilie gespeichert werden, zu der das Paar gehört. Wie in der Abbildung gezeigt, hat jedes Spaltenfamilienspeicherobjekt einen Lesecache, der als BlockCache bezeichnet wird, und einen Schreibcache, der als MemStore bezeichnet wird. Der BlockCache hilft bei der zufälligen Leseleistung.
Daten werden in Blöcken aus dem HDFS gelesen und im BlockCache gespeichert. Nachfolgende Lesevorgänge für die Daten - oder Daten, die in unmittelbarer Nähe gespeichert sind - werden anstelle der Festplatte aus dem RAM gelesen, wodurch die Gesamtleistung verbessert wird. Das Write Ahead Log (kurz WAL) stellt sicher, dass Ihre HBase-Schreibvorgänge zuverlässig sind. Es gibt eine WAL pro RegionServer.
Beachten Sie immer das eiserne Gesetz des verteilten Rechnens: Ein Fehler ist nicht die Ausnahme - er ist die Regel, besonders wenn Hunderte oder sogar Tausende von Servern geclustert werden. Google folgte dem Eisernen Gesetz bei der Entwicklung von BigTable und HBase folgten.
Wenn Sie Daten in HBase schreiben oder ändern, werden die Daten zuerst in der WAL gespeichert, die im HDFS gespeichert ist. Anschließend werden die Daten in den MemStore-Cache geschrieben. In konfigurierbaren Intervallen werden im MemStore gespeicherte Schlüssel / Wert-Paare in HFiles im HDFS geschrieben und anschließend werden WAL-Einträge gelöscht.
Wenn ein Fehler auftritt, nachdem der anfängliche WAL-Schreibvorgang aber vor der endgültige MemStore-Schreibzugriff erfolgt ist, kann die WAL erneut abgespielt werden, um Datenverlust zu vermeiden.
Drei HFile-Objekte befinden sich in einer Spaltenfamilie und zwei in der anderen Spalte. Das Design von HBase besteht darin, Spaltenfamiliendaten, die im MemStore gespeichert sind, zu einem HFile pro Flush zu löschen. In konfigurierbaren Intervallen werden dann HFiles zu größeren HFiles zusammengefasst. Diese Strategie reiht die kritische Verdichtungsoperation in HBase in eine Warteschlange ein.
