Wir haben HDInsight Hbase-Cluster installiert und beobachten, dass das Hbase für die Client-Anwendungen nicht erreichbar ist, während größere Komprimierungen ausgeführt werden.Wie behandelt man HDInsight Hbase Hauptkomprimierungen? Hbase ist nicht erreichbar, wenn die Hauptkomprimierung stattfindet
Bitte schlagen Sie vor, welche Best Practices für dieses Szenario gelten.
Es hängt von Ihrem Anwendungsfall ab.
Standardmäßig wird die Hauptverdichtung alle 24 Stunden gestartet.
Wenn Sie wissen, wann Ihr Cluster nicht verwendet wird, können Sie die Hauptverdichtung deaktivieren und zu diesem Zeitpunkt ausführen (normalerweise die Nacht). Ein Skript, das von cron aufgerufen wird und eine große Komprimierung mit HBAS Shell startet, kann diese Aufgabe übernehmen.
Seit HBase 0.98.11 und HBase 1.1.0 können Sie den Verdichtungsdurchsatz begrenzen, mehr Informationen unter Limit compaction speed JIRA.
Es ist wichtig, Haupt Verdichtung zu starten, weil es durch die Zusammenlegung StoreFile HBase Plattenzugriff verbessert (Entfernen von gelöschten Daten auf der Festplatte, Sortieren von Daten von RowKey, ...)
hbase-site.xml:
<!-- Disable major compaction -->
<property>
<name>hbase.hregion.majorcompaction</name>
<value>0</value>
</property>
Run Haupt Verdichtung manuell:
# Launch major compaction on all regions of table t1
$ echo "major_compact 't1'" | hbase shell
# Launch major compaction on region r1
$ major_compact 'r1'
In Bezug auf HDInsight HBase, würde Ich mag hier ein paar Ideen teilen.
1) Zeit gestütztes Verdichten von deafult deaktiviert ist, hbase.hregion.majorcompaction=0
2) In Bezug auf Größe auf Basis der Verdichtung sehen, ist die Standard-Verdichtungspolitik ExploringCompactionPolicy während hbase.hstore.compaction.max.size zu 10GB gesetzt, so dass keine Verdichtungen größer als 10 GB passieren werden.
hbase.hregion.max.filesize ist auf 3GB eingestellt, sobald die HFiles einer Region diesen Wert überschritten haben, wird die Region aufgeteilt. Der Grund für diese Einstellungen ist, dass die maximale BLOB-HBase in Azure Storage bis zu 12 GB erstellen kann. Wenn Sie also mehr als 12 GB komprimieren, schlägt die Komprimierung schließlich fehl. Sie können die maximale Blob-Größe definitiv erhöhen (bis zu 200 GB pro dokumentiertem Azure Storage, aber das erhöht auch die Lese-/Schreib-Latenz und die Komprimierungszeit).
Mehr Kontext hier,
Obwohl Azure Blob Speicher 200 GB Grenze für einen einzelnen Blob hat, (4MB * 50k-Blöcke), sondern um die beste Leistung zu erhalten, in hadoop core-site.xml beschränken wir fs.azure.read.request.size und fs.azure.write.request.size zu 256kb, Daher wird der maximale Blob im HBase-Cluster 256KB * 50k um 12GB betragen. Wenn Sie auf 4 MB setzen, wird es jedoch 200 GB sein. Aber 4MB wird die Latenz jedes Lese-/Schreibvorgangs erhöhen, und Sie werden HBase erlauben, bis zu 200GB Daten zu komprimieren, die für Stunden dauern werden.
3) Eine starke Verdichtung ist besonders für Cloud-basierte HBase teuer. Weil die Latenz höher ist als bei lokalen Festplatten/SSDs. Für die Leseleistung können Sie den Bucket-Cache einrichten, der auf der lokalen VM-SSD bereitgestellt wird, die standardmäßig im neuesten HBInsight-HBase-Cluster aktiviert sein sollte.
Es kann definitiv mehr Tuning durchgeführt werden wie VM-Größe, Clustergröße, Memstore-Größe usw.