Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Wenn Sie HBase Amazon EMR Version 5.2.0 oder höher verwenden, können Sie es HBase auf Amazon S3 aktivieren, was die folgenden Vorteile bietet:
Das HBase Stammverzeichnis wird in Amazon S3 gespeichert, einschließlich HBase Speicherdateien und Tabellenmetadaten. Diese Daten sind außerhalb des Clusters persistent und in allen Amazon EC2 Availability Zones verfügbar, und Sie müssen sie nicht mithilfe von Snapshots oder anderen Methoden wiederherstellen.
Mit Speicherdateien in Amazon S3 können Sie mit dreifacher Replikation in HDFS die Größe Ihres Amazon-EMR-Clusters an Ihre EDV-Anforderungen anpassen, nicht an die Datenanforderungen.
Wenn Sie Amazon EMR ab Version 5.7.0 verwenden, können Sie einen Lesereplikat-Cluster einrichten. So können Sie schreibgeschützte Kopien der Daten in Amazon S3 pflegen. Sie können auf die Daten vom Read Replica-Cluster zugreifen, um gleichzeitig Lesevorgänge auszuführen und wenn der primäre Cluster nicht mehr verfügbar ist.
In den Amazon EMR-Versionen 6.2.0 bis 7.3.0 verwendet persistentes HFile Tracking eine HBase Systemtabelle, die aufgerufen wird,
hbase:storefileum die für Lesevorgänge verwendeten HFile Pfade direkt zu verfolgen. Dieses Feature ist standardmäßig aktiviert und erfordert keine manuelle Migration. In Versionen höher als 7.3.0 werden HFile Pfade mithilfe eines Datei-Trackers verfolgt, wobei HFile Pfade direkt in einer Metadatei innerhalb des Speicherverzeichnisses gespeichert werden.
Anmerkung
Benutzer, die eine Version von Amazon EMR vor 7.4.0 verwenden und auf EMR-7.4.0 und höher migrieren, finden weitere Informationen unter Migration von früheren HBase Versionen und folgen der verfügbaren Upgrade-Dokumentation, um einen reibungslosen Übergang zu gewährleisten.
Die folgende Abbildung zeigt die HBase Komponenten, die für HBase Amazon S3 relevant sind.
Aktivierung HBase auf Amazon S3
Sie können die Aktivierung HBase auf Amazon S3 mithilfe der Amazon EMR-Konsole AWS CLI, der oder der Amazon EMR-API durchführen. Die Konfiguration wird während der Cluster-Erstellung als Option angeboten. Wenn Sie die Konsole verwenden, wählen Sie die Einstellung über Advanced options (Erweiterte Optionen) aus. In der AWS CLI verwenden Sie die Option--configurations , um ein JSON-Konfigurationsobjekt bereitzustellen. Die Eigenschaften des Konfigurationsobjekts geben den Speichermodus und das Stammverzeichnis in Amazon S3 an. Der Amazon-S3-Speicherort, den Sie angeben, sollte sich in derselben Region befinden wie Ihr Amazon-EMR-Cluster. In Amazon S3 kann jeweils nur ein aktiver Cluster dasselbe HBase Stammverzeichnis verwenden. Anweisungen zur Konsole und ein detailliertes Beispiel zum Erstellen eines Clusters mithilfe von finden Sie unter AWS CLI. Einen Cluster erstellen mit HBase Der folgende JSON-Codeausschnitt zeigt ein Beispiel für ein Konfigurationsobjekt.
{ "Classification": "hbase-site", "Properties": { "hbase.rootdir": "s3://amzn-s3-demo-bucket/my-hbase-rootdir"} }, { "Classification": "hbase", "Properties": { "hbase.emr.storageMode":"s3" } }
Anmerkung
Wenn Sie einen Amazon S3 S3-Bucket als rootdir for verwenden HBase, müssen Sie am Ende der Amazon S3 S3-URI einen Schrägstrich hinzufügen. Zum Beispiel müssen Sie statt "hbase.rootdir: s3://amzn-s3-demo-bucket/" "hbase.rootdir: s3://amzn-s3-demo-bucket" verwenden, um Probleme zu vermeiden.
Verwenden eines Lesereplikat-Clusters
Nachdem Sie HBase auf Amazon S3 einen primären Cluster eingerichtet haben, können Sie einen Read-Replica-Cluster erstellen und konfigurieren, der schreibgeschützten Zugriff auf dieselben Daten wie der primäre Cluster bietet. Dies ist hilfreich, wenn Sie gleichzeitigen Zugriff auf Abfragedaten brauchen oder einen unterbrechungsfreien Zugriff benötigen, wenn der primäre Cluster nicht mehr verfügbar ist. Das Lesereplikat-Feature ist ab Version 5.7.0 von Amazon EMR verfügbar.
Der primäre Cluster sowie der Read Replica-Cluster werden auf die gleiche Weise eingerichtet, mit einem wichtigen Unterschied. Beide verweisen auf denselben hbase.rootdir-Speicherort. Die hbase-Klassifizierung für den Read Replica-Cluster enthält jedoch die Eigenschaft "hbase.emr.readreplica.enabled":"true".
Der Read-Replica-Cluster ist für schreibgeschützte Operationen konzipiert und es sollten keine manuellen Komprimierungs- oder Schreibaktionen darauf ausgeführt werden. Für Amazon EMR-Versionen vor 7.4.0 wird empfohlen, die Komprimierung auf dem Read-Replica-Cluster zu deaktivieren, wenn Sie die Read-Replica-Funktion aktivieren. Diese Vorsichtsmaßnahme ist erforderlich, da es bei aktivierter persistenter HFile Tracking-Funktion auf dem primären Cluster möglich ist, dass der Read-Replica-Cluster Systemtabellen komprimiert, was möglicherweise zu einer Störung auf dem primären Cluster führen kann. FileNotFoundException Durch die Deaktivierung der Komprimierung auf dem Read-Replica-Cluster werden Dateninkonsistenzen zwischen dem primären und dem Read-Replica-Cluster verhindert.
Ausgehend von der JSON-Klassifizierung für den primären Cluster, wie weiter oben in diesem Thema gezeigt, sieht die Konfiguration für einen Read-Replica-Cluster für EMR-Versionen vor 7.4.0 beispielsweise wie folgt aus:
{ "Classification": "hbase-site", "Properties": { "hbase.rootdir": "s3://amzn-s3-demo-bucket/my-hbase-rootdir", "hbase.regionserver.compaction.enabled": "false" } }, { "Classification": "hbase", "Properties": { "hbase.emr.storageMode":"s3", "hbase.emr.readreplica.enabled":"true" } }
Für Amazon EMR-Versionen nach 7.3.0 verwenden wir diese Dateiverfolgung speichern Funktion jetzt, sodass die Komprimierung nicht deaktiviert werden muss.
Synchronisieren des Lesereplikats beim Hinzufügen von Daten
Da die Read-Replica Metadaten verwendet HBase StoreFiles , die der primäre Cluster in Amazon S3 schreibt, ist die Read-Replica nur so aktuell wie der Amazon S3 S3-Datenspeicher. Die folgenden Anleitungen können Ihnen dabei helfen, die Zeitverzögerung beim Schreiben von Daten zwischen dem primären Cluster und dem Read Replica zu minimieren.
Sie sollten nach Möglichkeit Massenladevorgänge für den primären Cluster durchführen. Weitere Informationen finden Sie unter Bulk Loading in der Apache-Dokumentation.
HBase Möglichst bald nach dem Hinzufügen der Daten sollte eine Auslagerung erfolgen, bei der Speicherdateien in Amazon S3 geschrieben werden. Führen Sie entweder eine manuelle Auslagerung durch oder optimieren Sie die Auslagerungseinstellungen, um Verzögerungen zu minimieren.
Wenn Verdichtungen möglicherweise automatisch ausgeführt werden, führen Sie eine manuelle Verdichtung durch, um Inkonsistenzen bei der Auslösung von Verdichtungen zu vermeiden.
Führen Sie auf dem Read-Replica-Cluster den Befehl aus, wenn sich Metadaten geändert haben, z. B. wenn HBase Regionen aufgeteilt oder komprimiert werden oder wenn Tabellen hinzugefügt oder entfernt werden.
refresh_metaFühren Sie den Befehl
refresh_hfilesauf dem Read Replica-Cluster aus, wenn Datensätze zu einer Tabelle hinzugefügt oder in einer Tabelle geändert werden.
HFile Persistentes Tracking
Persistentes HFile Tracking verwendet eine HBase Systemtabelle, die aufgerufen wirdhbase:storefile, um die für Lesevorgänge verwendeten HFile Pfade direkt nachzuverfolgen. Neue HFile Pfade werden der Tabelle hinzugefügt, wenn zusätzliche Daten hinzugefügt werden HBase. Dadurch werden Umbenennungsvorgänge als Festschreibungsmechanismus bei kritischen HBase Schreibpfadvorgängen entfernt und die Wiederherstellungszeit beim Öffnen einer HBase Region verbessert, indem aus der hbase:storefile Systemtabelle statt aus der Verzeichnisliste des Dateisystems gelesen wird. Diese Funktion ist in Amazon EMR Version 6.2.0 bis 7.3.0 standardmäßig aktiviert und erfordert keine manuellen Migrationsschritte.
Anmerkung
Die persistente HFile Nachverfolgung mithilfe der HBase Storefile-Systemtabelle unterstützt die Funktion zur Regionsreplikation nicht. HBase Weitere Informationen zur HBase Regionsreplikation finden Sie unter Timeline-consistent
Persistentes Tracking deaktivieren HFile
Persistentes HFile Tracking ist ab Amazon EMR Version 6.2.0 standardmäßig aktiviert. Um persistentes HFile Tracking zu deaktivieren, geben Sie beim Starten eines Clusters die folgende Konfigurationsüberschreibung an:
{
"Classification": "hbase-site",
"Properties": {
"hbase.storefile.tracking.persist.enabled":"false",
"hbase.hstore.engine.class":"org.apache.hadoop.hbase.regionserver.DefaultStoreEngine"
}
}Anmerkung
Bei der Neukonfiguration des Amazon-EMR-Clusters müssen alle Instance-Gruppen aktualisiert werden.
Manuelles Synchronisieren der Storefile-Tabelle
Die Storefile-Tabelle wird auf dem neuesten Stand gehalten, wenn neue HFile Instanzen erstellt werden. Wenn die Storefile-Tabelle jedoch aus irgendeinem Grund nicht mehr mit den Datendateien synchron ist, können die folgenden Befehle verwendet werden, um die Daten manuell zu synchronisieren:
Synchronisieren der Storefile-Tabelle in einer Online-Region:
hbase org.apache.hadoop.hbase.client.example.RefreshHFilesClient <table>
Synchronisieren der Storefile-Tabelle in einer Offline-Region:
Entfernen Sie die Storefile-Tabelle znode.
echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [<tableName>, hbase:namespace] # The TableName exists in the list echo "delete /hbase/storefile/loaded/<tableName>" | sudo -u hbase hbase zkcli # Delete the Table ZNode echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli [hbase:namespace]Weisen Sie die Region zu (in 'hbase shell' ausführen).
hbase cli> assign '<region name>'Wenn die Zuweisung fehlschlägt.
hbase cli> disable '<table name>' hbase cli> enable '<table name>'
Skalierung der Storefile-Tabelle
Die Storefile-Tabelle ist standardmäßig in vier Regionen aufgeteilt. Wenn die Storefile-Tabelle immer noch unter starker Schreiblast steht, kann die Tabelle manuell weiter aufgeteilt werden.
Um eine bestimmte Hot-Region aufzuteilen, verwenden Sie den folgenden Befehl (in 'hbase shell' ausführen).
hbase cli> split '<region name>'Um die Tabelle zu teilen, verwenden Sie den folgenden Befehl (in der „hbase-Shell“ ausführen).
hbase cli> split 'hbase:storefile'Dateiverfolgung speichern
Standardmäßig verwenden wir die FileBasedStoreFileTrackerImplementierung. Diese Implementierung erstellt neue Dateien direkt im Speicherverzeichnis, sodass keine Umbenennungsvorgänge erforderlich sind. Sie führt eine Liste der festgeschriebenen hfile-Instanzen im Speicher, die durch Metadaten in jedem Speicherverzeichnis unterstützt wird. Immer wenn eine neue H-Datei festgeschrieben wird, wird die Liste der verfolgten Dateien im angegebenen Speicher aktualisiert und es wird eine neue Metadatei mit dem Inhalt der Liste geschrieben, wobei die vorherige Metadatei, die eine veraltete Liste enthält, verworfen wird. Weitere Informationen zu Store File Tracking finden Sie unter Store File Tracking
Die FileBasedStoreFile Tracker-Implementierung ist ab Amazon EMR Version 7.4.0 standardmäßig aktiviert:
{
"Classification": "hbase-site",
"Properties": {
hbase.store.file-tracker.impl: "org.apache.hadoop.hbase.regionserver.storefiletracker.FileBasedStoreFileTracker"
}Um die FileBasedStoreFileTracker Implementierung zu deaktivieren, geben Sie beim Starten eines Clusters die folgende Konfigurationsüberschreibung an:
{
"Classification": "hbase-site",
"Properties": {
hbase.store.file-tracker.impl: "org.apache.hadoop.hbase.regionserver.storefiletracker.DefaultStoreFileTracker"
}Anmerkung
Bei der Neukonfiguration des Amazon-EMR-Clusters müssen alle Instance-Gruppen aktualisiert werden.
Betriebliche Überlegungen
HBase Regionalserver werden verwendet BlockCache , um Datenlesevorgänge im Arbeitsspeicher und Datenlesevorgänge auf der lokalen Festplatte BucketCache zu speichern. Darüber hinaus speichern Regionalserver Datenschreibvorgänge im Arbeitsspeicher und verwenden MemStore Write-Ahead-Protokolle, um Datenschreibvorgänge in HDFS zu speichern, bevor die Daten in Amazon S3 geschrieben werden. HBase StoreFiles Die Leseleistung Ihres Clusters hängt davon ab, wie oft ein Datensatz vom In-Memory-Cache oder Cache auf dem Datenträger abgerufen werden kann. Ein Cache-Fehler führt dazu, dass der Datensatz aus Amazon S3 gelesen wird, was eine deutlich höhere Latenz und eine höhere Standardabweichung als das Lesen aus HDFS aufweist. StoreFile Darüber hinaus sind die maximalen Anforderungsraten für Amazon S3 geringer als das, was vom lokalen Cache erreicht werden kann. Also kann die Zwischenspeicherung von Daten für leseintensive Workloads sehr wichtig sein. Weitere Informationen zu Amazon-S3-Leistung finden Sie unter Optimieren der Leistung im Benutzerhandbuch zu Amazon Simple Storage Service.
Um die Leistung zu verbessern, empfehlen wir, so viel wie möglich von Ihrem Datensatz im EC2 Instance-Speicher zwischenzuspeichern. Da der den EC2 Instance-Speicher des Regionsservers BucketCache verwendet, können Sie einen EC2 Instance-Typ mit ausreichend Instance-Speicher wählen und Amazon EBS-Speicher hinzufügen, um die erforderliche Cache-Größe zu erreichen. Mithilfe der Eigenschaft können Sie auch die BucketCache Größe der angehängten Instance-Speicher und EBS-Volumes erhöhen. hbase.bucketcache.size Die Standardeinstellung lautet 8 192 MB.
Bei Schreibvorgängen können die Häufigkeit von MemStore Flushes und die Anzahl der bei kleineren und größeren Komprimierungen StoreFiles vorhandenen Flushes erheblich zu einer Verlängerung der Antwortzeiten der Server in der Region beitragen. Um eine optimale Leistung zu erzielen, sollten Sie erwägen, die Größe des MemStore Flush- und HRegion Blockmultiplikators zu erhöhen, wodurch die Zeit zwischen größeren Verdichtungen verlängert wird, aber auch die Verzögerung bei der Konsistenz zunimmt, wenn Sie eine Read-Replica verwenden. Manchmal können Sie eine bessere Leistung erzielen, wenn Sie eine größere Dateiblockgröße verwenden (jedoch weniger als 5 GB), um einen mehrteiligen Amazon-S3-Upload in EMRFS auszulösen. Die Blockgröße von Amazon EMR ist standardmäßig 128 MB. Weitere Informationen finden Sie unter HDFS-Konfiguration. Während dem Benchmarking der Leistung durch Bereinigungen und Verdichtungen sind selten Kunden anzutreffen, die die 1 GB-Blockgröße überschreiten. Außerdem funktionieren HBase Komprimierungen und Regionalserver optimal, wenn weniger komprimiert werden müssen. StoreFiles
Es kann recht lange dauern, bis Tabellen in Amazon S3 gelöscht sind, da große Verzeichnisse umbenannt werden müssen. Erwägen Sie, Tabellen zu deaktivieren, anstatt sie zu entfernen.
Es gibt einen HBase saubereren Prozess, der alte WAL-Dateien und Speicherdateien bereinigt. Bei Amazon-EMR-Version 5.17.0 und höher ist die Bereinigungsfunktion global aktiviert, und die folgenden Konfigurationseigenschaften können verwendet werden, um ein saubereres Verhalten zu steuern.
| Konfigurationseigenschaft | Standardwert | Beschreibung |
|---|---|---|
|
|
1 |
Die Anzahl der zum Säubern zugewiesenen Threads ist groß HFiles abgelaufen. |
|
|
1 |
Die Anzahl der zum Säubern zugewiesenen Threads ist gering abgelaufen HFiles. |
|
|
Setzen Sie diesen Wert auf ein Viertel aller verfügbaren Kerne. |
Die Anzahl der Threads zum Scannen der alten WALs Verzeichnisse. |
|
|
2 |
Die Anzahl der Threads, die WALs unter dem alten WALs Verzeichnis gesäubert werden sollen. |
Bei Amazon EMR 5.17.0 und früher kann sich der Bereinigungsvorgang bei hohen Workloads auf die Abfrageleistung auswirken. Deshalb wird empfohlen, die Bereinigung nur außerhalb von Spitzenzeiten durchzuführen. Der Cleaner hat die folgenden HBase Shell-Befehle:
cleaner_chore_enabledfragt ab, ob die Bereinigungsfunktion aktiviert ist.cleaner_chore_runführt die Bereinigungsfunktion manuell aus, um Dateien zu entfernen.cleaner_chore_switchaktiviert oder deaktiviert die Bereinigungsfunktion und gibt den vorherigen Zustand der Bereinigungsfunktion zurück. Durchcleaner_chore_switch truewird die Bereinigungsfunktion beispielsweise aktiviert.
Eigenschaften für die Leistungsoptimierung HBase auf Amazon S3
Die folgenden Parameter können angepasst werden, um die Leistung Ihres Workloads zu optimieren, wenn Sie ihn HBase auf Amazon S3 verwenden.
| Konfigurationseigenschaft | Standardwert | Beschreibung |
|---|---|---|
|
|
8,192 |
Die Menge an Festplattenspeicher in MB, die auf regionalen Servern reserviert ist, die Amazon EC2 Instance speichert, und auf EBS-Volumes für die BucketCache Speicherung. Die Einstellung gilt für alle Regionsserver-Instances. Größere BucketCache Größen entsprechen in der Regel einer verbesserten Leistung |
|
|
134217728 |
Das Datenlimit in Byte, bei dem eine MemStore-Auslagerung nach Amazon S3 ausgelöst wird. |
|
|
4 |
Ein Multiplikator, der die MemStore Obergrenze bestimmt, ab der Updates blockiert werden. Wenn die MemStore |
|
|
10 |
Die maximale Anzahl StoreFiles davon kann in einem Store existieren, bevor Updates blockiert werden. |
|
|
10737418240 |
Die maximale Größe einer Region, bevor die Region aufgeteilt wird. |
Herunterfahren und Wiederherstellen eines Clusters ohne Datenverlust
Um einen Amazon EMR-Cluster herunterzufahren, ohne Daten zu verlieren, die nicht in Amazon S3 geschrieben wurden, sollten Sie Ihren MemStore Cache auf Amazon S3 leeren, um neue Speicherdateien zu schreiben. Zunächst müssen Sie alle Tabellen deaktivieren. Die folgende Schrittkonfiguration kann verwendet werden, wenn Sie dem Cluster einen Schritt hinzufügen. Weitere Informationen finden Sie unter Arbeiten mit Schritten unter Verwendung der AWS CLI und Konsole im Verwaltungshandbuch für Amazon EMR.
Name="Disable all tables",Jar="command-runner.jar",Args=["/bin/bash","/usr/lib/hbase/bin/disable_all_tables.sh"] Alternativ können Sie auch den folgenden Bash-Befehl direkt ausführen.
bash /usr/lib/hbase/bin/disable_all_tables.shNachdem Sie alle Tabellen deaktiviert haben, leeren Sie die hbase:meta Tabelle mit der HBase Shell und dem folgenden Befehl.
flush 'hbase:meta'Anschließend können Sie ein auf dem Amazon EMR-Cluster bereitgestelltes Shell-Skript ausführen, um den MemStore Cache zu leeren. Sie können es als einen Schritt hinzufügen oder direkt auf dem Cluster AWS CLI ausführen. Das Skript deaktiviert alle HBase Tabellen, was dazu führt, dass der Server MemStore in jeder Region zu Amazon S3 flusht. Wenn das Skript erfolgreich abgeschlossen wurde, verbleiben die Daten in Amazon S3 und der Cluster kann beendet werden.
Um einen Cluster mit denselben HBase Daten neu zu starten, geben Sie denselben Amazon S3 S3-Standort wie der vorherige Cluster entweder in der AWS Management Console oder mithilfe der hbase.rootdir Konfigurationseigenschaft an.
