Das Verdichtungsmodell ändert sich drastisch mit CDH 5/HBase 0.96. Folgendes müssen Sie wissen.
Apache HBase ist ein verteilter Datenspeicher, der auf einem protokollstrukturierten Zusammenführungsbaum basiert, sodass eine optimale Leseleistung erzielt werden würde, wenn nur eine Datei pro Speicher vorhanden wäre (Spaltenfamilie). Dieses Ideal ist jedoch in Zeiten mit vielen eingehenden Schreibvorgängen nicht möglich. Stattdessen versucht HBase, HFiles zu kombinieren, um die maximale Anzahl von Festplattensuchen zu reduzieren, die für einen Lesevorgang erforderlich sind. Dieser Vorgang wird als Komprimierung bezeichnet .
Komprimierungen wählen einige Dateien aus einem einzelnen Speicher in einer Region aus und kombinieren sie. Dieser Prozess beinhaltet das Lesen von Schlüsselwerten in den Eingabedateien und das Schreiben aller Schlüsselwerte, die nicht gelöscht werden, innerhalb der Gültigkeitsdauer (TTL) liegen und die Anzahl der Versionen nicht verletzen. Die neu erstellte kombinierte Datei ersetzt dann die Eingabedateien in der Region.
Wann immer ein Client nach Daten fragt, weiß HBase jetzt, dass die Daten aus den Eingabedateien in einer zusammenhängenden Datei auf der Festplatte gespeichert sind – daher ist nur eine Suche erforderlich, während früher eine für jede Datei erforderlich sein konnte. Aber Festplatten-IO ist nicht kostenlos, und ohne sorgfältige Aufmerksamkeit kann das wiederholte Neuschreiben von Daten zu einer ernsthaften Überbelegung des Netzwerks und der Festplatte führen. Mit anderen Worten, bei der Komprimierung geht es darum, einige Festplatten-IO jetzt gegen weniger Suchvorgänge später einzutauschen.
In diesem Beitrag erfahren Sie mehr über die Verwendung und Auswirkungen von Komprimierungen in CDH 4 sowie über Änderungen am Komprimierungsmodell in CDH 5 (das auf HBase 0.96 neu basiert).
Verdichtung in CDH 4
Die ideale Komprimierung würde die Dateien auswählen, die die meisten Suchvorgänge in bevorstehenden Lesevorgängen reduzieren, während gleichzeitig Dateien ausgewählt werden, die die geringste Menge an E / A benötigen. Leider ist dieses Problem nicht ohne Kenntnis der Zukunft lösbar. Als solches ist es nur ein Ideal, das HBase anstreben sollte, und nicht etwas, das jemals wirklich erreichbar ist.
Anstelle des unmöglichen Ideals verwendet HBase eine Heuristik, um zu versuchen, auszuwählen, welche Dateien in einem Geschäft wahrscheinlich gute Kandidaten sind. Die Dateien werden aufgrund der Intuition ausgewählt, dass gleiche Dateien mit gleichen Dateien kombiniert werden sollten – das heißt, Dateien, die ungefähr die gleiche Größe haben, sollten kombiniert werden.
Die Standardrichtlinie in HBase 0.94 (Lieferumfang CDH 4) durchsucht die Liste der HFiles und versucht, die erste Datei zu finden, deren Größe kleiner ist als die Gesamtgröße aller Dateien multipliziert mit hbase.store.compaction.ratio. Sobald diese Datei gefunden ist, werden die HFile und alle Dateien mit kleineren Sequenz-IDs zum Komprimieren ausgewählt.
Für den Standardfall, dass die größten Dateien die ältesten sind, funktioniert dieser Ansatz gut:
Diese Annahme über den Zusammenhang zwischen Alter und Größe von Dateien ist jedoch in einigen Fällen fehlerhaft, was dazu führt, dass der aktuelle Algorithmus suboptimal wählt. Vielmehr können massengeladene Dateien ganz anders sortiert werden als die normalerweise geleerten HFiles und tun dies manchmal auch, sodass sie großartige Beispiele abgeben:
Verdichtungsänderungen in CDH 5
Die Verdichtungen haben sich in letzter Zeit erheblich verändert. Für HBase 0.96 und CDH 5 wurde der Dateiauswahlalgorithmus über HBASE-7516 konfigurierbar gemacht – daher ist es jetzt möglich, vom Benutzer bereitgestellte Komprimierungsrichtlinien zu haben. Diese Änderung ermöglicht es erfahreneren Benutzern zu testen und zu iterieren, wie sie Komprimierungen ausführen möchten.
Der standardmäßige Komprimierungsauswahlalgorithmus wurde ebenfalls in ExploringCompactionPolicy geändert. Diese Richtlinie unterscheidet sich von der alten Standardeinstellung darin, dass sichergestellt wird, dass jede einzelne Datei in einer vorgeschlagenen Komprimierung innerhalb des angegebenen Verhältnisses liegt. Außerdem wird nicht nur der erste Satz von Dateien ausgewählt, deren Größe innerhalb des Komprimierungsverhältnisses liegt; Stattdessen betrachtet es alle möglichen Sets, die keine Regeln verletzen, und wählt dann etwas aus, das für die geringste erwartete Menge an IO am wirkungsvollsten zu sein scheint. Dazu wählt die ExploringCompactionPolicy eine Komprimierung aus, die die meisten Dateien innerhalb des Verhältnisses entfernt, und wenn es ein Unentschieden gibt, wird der Gruppe von Dateien mit der kleineren Größe der Vorzug gegeben:
Weitere Änderungen sind für zukünftige Versionen geplant, einschließlich abgestufter Komprimierung, gestreifter Komprimierung und ebenenbasierter Komprimierung.
Schlussfolgerung
Für einige Anwendungsfälle hat diese Arbeit überhaupt keine Auswirkungen. Das ist eine gute Sache, da Verdichtungen bereits ziemlich gut untersucht wurden. Für Benutzer mit großen Verkehrsspitzen oder Massenlasten kann diese Arbeit jedoch zu erheblichen Verbesserungen der E/A-Wartezeiten und der Anforderungslatenz führen. Für einen bestimmten Massenlade-Anwendungsfall haben wir aufgrund von Komprimierungen eine 90 %ige Reduzierung der Datenträger-E/A festgestellt.
Hier sind die Ergebnisse eines Testfalls in den PerfTestCompactionPolicies von HBase:
Sehen Sie sich diese Arbeit in CDH 5 (zum Zeitpunkt des Schreibens in der Beta-Version) an, wenn es um einen Cluster in Ihrer Nähe geht.
Weiterführende Literatur:
- Erkunden der Komprimierungsrichtlinie
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
