Apache HBase-Empfehlungen in Azure HDInsight

Artikel
09/15/2023

Dieser Artikel enthält einige Empfehlungen, die Ihnen bei der Optimierung der Leistung von Apache HBase in Azure HDInsight helfen.

Optimieren von HBase zum Lesen der zuletzt geschriebenen Daten

Wenn Ihr Anwendungsfall das Lesen der zuletzt geschriebenen Daten aus HBase umfasst, kann Ihnen diese Empfehlung helfen. Zum Erzielen einer hohen Leistung sollten HBase-Lesevorgänge nach Möglichkeit über memstore statt über den Remotespeicher erfolgen.

Laut Abfrageempfehlung sollten für eine Spaltenfamilie in einer Tabelle mehr als 75 % der Lesevorgänge über memstore erfolgen. Gemäß dieser Empfehlung muss auch im Falle einer Leerung in memstore auf die zuletzt verwendete Datei zugegriffen werden, und diese muss sich im Cache befinden. Die Daten werden zunächst in memstore geschrieben, und das System greift dort auf die aktuellen Daten zu. Möglicherweise erkennen die internen HBase-Speicherleerungsthreads, dass ein bestimmter Bereich eine Größe von 128 MB (Standard) erreicht hat, und sie können eine Leerung auslösen. Dieses Szenario gilt auch für die neuesten Daten, die geschrieben wurden, als die Größe von memstore ungefähr 128 MB betrug. Daher erfordert ein späterer Lesevorgang der aktuellen Datensätze möglicherweise das Lesen aus einer Datei statt aus memstore. Deshalb empfiehlt es sich, die Leistung so zu optimieren, dass auch aktuelle Daten, die kürzlich geleert wurden, im Cache verbleiben können.

Um die aktuellen Daten im Cache zu optimieren, sollten Sie die folgenden Konfigurationseinstellungen beachten:

Legen Sie hbase.rs.cacheblocksonwrite auf true fest. Die Standardkonfiguration in HDInsight HBase lautet true. Vergewissern Sie sich daher, dass sie nicht auf false festgelegt ist.
Erhöhen Sie den Wert für hbase.hstore.compactionThreshold, damit keine Komprimierung gestartet wird. Der Standardwert beträgt 3. Sie können den Wert z. B. auf 10 erhöhen.
Wenn Sie Schritt 2 ausführen und „compactionThreshold“ festlegen, ändern Sie hbase.hstore.compaction.max in einen höheren Wert, z. B. in 100, und erhöhen Sie außerdem den Wert für hbase.hstore.blockingStoreFiles, z. B. auf 300.
Wenn Sie sicher sind, dass nur in den aktuellen Daten gelesen werden muss, legen Sie hbase.rs.cachecompactedblocksonwrite auf EIN fest. Diese Konfiguration bewirkt, dass die Daten auch im Falle einer Komprimierung im Cache verbleiben. Diese Konfigurationen können auch auf Familienebene festgelegt werden.

Führen Sie in der HBase-Shell den folgenden Befehl aus, um hbase.rs.cachecompactedblocksonwrite festzulegen:
```
alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
```
Der Blockcache kann für eine bestimmte Familie in einer Tabelle deaktiviert werden. Stellen Sie sicher, dass er für Familien mit den neuesten Datenlesevorgängen auf EIN festgelegt ist. Standardmäßig ist der Blockcache für alle Familien in einer Tabelle aktiviert. Falls Sie den Blockcache für eine Familie deaktiviert haben und ihn aktivieren müssen, verwenden Sie den alter-Befehl in der HBase-Shell.

Diese Konfigurationen helfen sicherzustellen, dass die Daten im Cache verfügbar sind und keine Komprimierung der aktuellen Daten erfolgt. Wenn in Ihrem Szenario eine TTL möglich ist, sollten Sie eine nach Datum gestaffelte Komprimierung in Betracht ziehen. Weitere Informationen finden Sie im Referenzleitfaden zu Apache HBase: Date Tiered Compaction (in englischer Sprache).

Optimieren der Leerungswarteschlange

Laut dieser Empfehlung müssen HBase-Leerungen möglicherweise optimiert werden. Die aktuelle Konfiguration für Leerungshandler ist möglicherweise nicht hoch genug, um den Schreibdatenverkehr zu verarbeiten. Dies kann zu einer Verlangsamung der Leerung führen.

Überprüfen Sie auf der Benutzeroberfläche des Regionsservers, ob die Leerungswarteschlange den Wert 100 überschreitet. Dieser Schwellenwert gibt an, dass die Leerungen langsam erfolgen, und möglicherweise müssen Sie die Konfiguration von hbase.hstore.flusher.count optimieren. Der Standardwert lautet 2. Stellen Sie sicher, dass die maximale Anzahl der Leerungsthreads nicht höher als 6 ist.

Überprüfen Sie, ob eine Empfehlung für die Optimierung der Regionsanzahl vorhanden ist. Wenn dies der Fall ist, sollten Sie die Anzahl der Regionen optimieren, um zu überprüfen, ob die Leerungen dadurch beschleunigt werden. Andernfalls kann die Optimierung der Threads für Leerungen eventuell helfen.

Optimierung der Anzahl der Regionen

Die Empfehlung für die Optimierung der Regionsanzahl besagt, dass HBase Aktualisierungen blockiert hat, und die Anzahl der Regionen überschreitet möglicherweise die optimal unterstützte Heapgröße. Sie können die Heapgröße, die memstore-Größe und die Anzahl der Regionen optimieren.

Beispielszenario:

Angenommen, die Heapgröße für den Regionsserver beträgt 10 GB. Der Standardwert für hbase.hregion.memstore.flush.size ist 128M. Der Standardwert für hbase.regionserver.global.memstore.size ist 0.4. Das bedeutet, dass 4 der 10 GB für memstore (global) zugeordnet werden.
Angenommen, die Schreiblast ist gleichmäßig auf alle Regionen verteilt, und die Größe jeder Region erhöht sich auf 128 MB. Nur dann beträgt die maximale Anzahl der Regionen in diesem Setup 32. Wenn ein bestimmter Regionsserver mit 32 Regionen konfiguriert ist, kann das System das Blockieren von Aktualisierungen besser vermeiden.
Mit diesen Einstellungen beträgt die Anzahl der Regionen 100. Der globale memstore-Wert von 4 GB ist jetzt auf 100 Regionen aufgeteilt. Tatsächlich erhält also jede Region nur 40 MB für memstore. Wenn die Schreibvorgänge einheitlich sind, führt das System häufige Leerungen aus, und die Größe ist geringer als 40 MB. Durch eine hohe Anzahl von Leerungsthreads (hbase.hstore.flusher.count) kann die Leerung beschleunigt werden.

Die Empfehlung bedeutet, dass es sinnvoll ist, die Anzahl der Regionen pro Server, die Heapgröße und die Konfiguration der Größe des globalen memstore sowie die Optimierung der Leerungsthreads zu überdenken, damit das Blockieren der Updates vermieden werden kann.

Optimieren der Komprimierungswarteschlange

Wenn die Größe der HBase-Komprimierungswarteschlange regelmäßig 2.000 überschreitet, können Sie die Anzahl der Komprimierungsthreads erhöhen.

Wenn eine übermäßige Anzahl zu komprimierender Dateien vorhanden ist, kann dies zu einer größeren Heapauslastung im Zusammenhang mit der Interaktion der Dateien mit dem Azure-Dateisystem führen. Daher empfiehlt es sich, die Komprimierung so schnell wie möglich abzuschließen. In älteren Clustern kann es vorkommen, dass die Komprimierungskonfigurationen im Zusammenhang mit der Drosselung zu einer langsameren Komprimierung führen.

Überprüfen Sie die Konfigurationen von hbase.hstore.compaction.throughput.lower.bound und hbase.hstore.compaction.throughput.higher.bound. Wenn sie bereits auf 50 MB und 100 MB festgelegt sind, lassen Sie sie unverändert. Wenn Sie diese Einstellungen jedoch auf einen niedrigeren Wert festgelegt haben (was bei älteren Clustern der Fall war), ändern Sie die Grenzwerte in 50 MB bzw. 100 MB.

Die Konfigurationen lauten hbase.regionserver.thread.compaction.small und hbase.regionserver.thread.compaction.large (der Standardwert ist jeweils 1). Begrenzen Sie den maximalen Wert für diese Konfiguration auf einen kleineren Wert als 3.

Suche in der gesamten Tabelle

Die Empfehlung für vollständige Tabellenscans besagt, dass mehr als 75 % der ausgeführten Scans vollständige Tabellen-/Bereichsscans sein sollten. Sie können überprüfen, wie der Code die Scans aufruft, um die Abfrageleistung zu verbessern. Erwägen Sie folgende Verfahren:

Legen Sie für jeden Scan die richtige Anfangs- und Endzeile fest.
Verwenden Sie die MultiRowRangeFilter-API, damit Sie in einem Scanaufruf verschiedene Bereiche abfragen können. Weitere Informationen finden Sie in der Dokumentation zur MultiRowRangeFilter-API (in englischer Sprache).
Wenn ein vollständiger Tabellen- oder Bereichsscan erforderlich ist, überprüfen Sie, ob sich die Verwendung des Caches für diese Abfragen vermeiden lässt, damit andere Abfragen, die den Cache verwenden, nicht die Blöcke entfernen, die heiß sind. Legen Sie im Code die scan-API mit der Option setCaching(false) fest, um sicherzustellen, dass die Scans keinen Cache verwenden:
```
scan#setCaching(false)
```

Nächste Schritte

Optimieren von Apache HBasemti Ambari

Share via