HBase-Leistungstests mit YCSB

Wenn Sie ein Performance-Benchmarking-Tool auf Ihrem Cluster ausführen, ist es immer eine wichtige Entscheidung, welche Datensatzgröße für einen Leistungstest verwendet werden sollte, und hier zeigen wir, warum es wichtig ist, eine „gut passende“ Datensatzgröße auszuwählen, wenn Sie eine HBase-Leistung ausführen auf Ihrem Cluster testen.

Die HBase-Clusterkonfigurationen und die Größe des Datensatzes können die Leistung Ihres Workloads und die Testergebnisse auf demselben Cluster variieren. Sie sollten diese Datensatzgröße basierend auf dem auswählen, was Sie über die Leistung Ihres Clusters verstehen möchten. Um den Unterschied zwischen einem Arbeitssatz, der in den verfügbaren Arbeitsspeicher-Cache passt, und einem, der aus dem zugrunde liegenden Speicher gelesen werden muss, zu zeigen, haben wir zwei YCSB-Workload-Tests mit entsprechend ausgewählten Datensatzgrößen auf demselben CDP Private Cloud Base 7.2.2 Operation Database-Cluster durchgeführt. Wir haben Datensatzgrößen von 40 GB gegenüber 1 TB verwendet, und der Durchsatz für die verschiedenen YCSB-Arbeitslasten wird unten verglichen. Je höher der Balken im Diagramm, desto besser der Durchsatz.

Hinweis:Durchsatz =Operationen pro Sekunde

Wenn eine Anwendung versucht, einen Lesevorgang aus einem HBase-Cluster durchzuführen, prüft der Regionsserver, der die Anfrage bearbeitet, zunächst, ob sich die erforderlichen Ergebnisse in einem Datenblock befinden, der bereits über seinen Block-Cache für seinen Prozess lokal ist. Wenn der Datenblock vorhanden ist, kann die Clientanforderung direkt aus dem Cache bedient werden, und dies zählt als Cache-Treffer. Wenn der Block jedoch derzeit nicht lokal für den Region Server-Prozess ist, wird dies als Cache-Mißerfolg gezählt und muss aus der HFile im HDFS-Speicher gelesen werden. Abhängig von der Cache-Auslastung wird dieser Block dann für zukünftige Anfragen im Cache gespeichert.

Wie erwartet und im zusammenfassenden Diagramm zu sehen, hat eine Arbeitslast, bei der die meisten Datensätze in den Cache passen, niedrigere Latenzen und einen viel höheren Durchsatz als eine Arbeitslast, bei der auf Daten von HFiles im hdfs-Speicher zugegriffen wird.

Um unsere Workload-Dataset-Größen so auszuwählen, dass sie unsere Testziele gut erreichen, ist es wichtig, die Größe der RegionServer-Heaps, L1- und L2-Caches, OS-Puffer-Caches zu überprüfen und dann eine geeignete Dataset-Größe festzulegen. Nachdem ein YCSB-Workload-Lauf abgeschlossen ist, ist ein guter Parameter, um zu überprüfen, ob die Dinge wie erwartet gelaufen sind, wie viele der Daten aus dem Cache bedient wurden (ein Cache-Hit) und auf wie viele vom hdfs-Speicher zugegriffen wurde. Dieses Verhältnis von Regionsserver-Cache-Treffern zu den gesamten Leseanforderungen ist das Cache-Trefferverhältnis.

Sie finden diese Informationen in der L1-Cache-Trefferquote „l1CacheHitRatio“-Konfiguration. Wenn Sie in Ihrem Cluster sowohl L1- als auch L2-Caches eingerichtet haben, dient der L1-Cache den Indexblöcken und der L2-Cache den Datenblöcken, und Sie können sowohl die L1-„l1CacheHitRatio“- als auch die L2-„l2CacheHitRatio“-Konfigurationen als Referenz aufzeichnen.

Der Rest dieses Blogbeitrags führt Sie durch Details unseres Testaufbaus, die Auswahl der Datensatzgröße und die anschließende Ausführung von YCSB mit diesen Datensatzgrößen.

Für diesen Test verwendete HBase-Clusterkonfiguration:

• Verwendeter Cluster: 6-Knoten-Cluster (1 Master + 5 Regionsserver)
• Beschreibung: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 bei 2,2 GHz, 128 GB RAM, 4–2 TB Festplatten
• Sicherheit: Nichts konfiguriert (Kein Kerberos)
• CDP-Version: CDP Private Cloud Base 7.2.2 HBase-Cluster mit 6 Knoten und 1 Master + 5 Regionsservern
• JDK verwendet jdk1.8_232
• Server der HBase-Region wurden mit 32-GB-Heap konfiguriert 
• HBase-Master wurde mit 4 GB Heap konfiguriert
• L1-Cache mit LruBlockCache wurde mit 12,3 GB Cachegröße verwendet
• Der gesamte L1-Cache im Cluster beträgt 61 GB (12,3 * 5 =61 GB)
• L2 Off-Heap-Cache wurde nicht auf dem Cluster konfiguriert

Sizing Case 1:Daten passen vollständig in den verfügbaren Cache auf dem Cluster

In unserem HBase-Cluster haben wir insgesamt 61 GB (12,3 GB * 5) auf den 5 Regionsservern konfiguriert, die dem L1-Block-Cache zugeordnet sind. Für einen Datensatz, der vollständig in den Cache passt, haben wir einen Datensatz mit 40 GB ausgewählt in Größe.

Sizing Case 2:Datensatz größer als der verfügbare Cache auf dem Cluster

Für das zweite Szenario möchten wir, dass die Daten viel größer sind als der verfügbare Cache. Um eine geeignete Datensatzgröße auszuwählen, haben wir uns sowohl den konfigurierten HBase-Block-Cache als auch den OS-Puffer-Cache im Cluster angesehen. In unserem gegebenen HBase-Cluster beträgt der konfigurierte L1-Blockcache 61 GB, wenn er über die RegionServer aggregiert wird. Die Serverknoten hatten jeweils insgesamt 128 GB RAM, und jeder Speicher, der nicht für einen Serverprozess reserviert ist, kann vom Betriebssystem verwendet werden, um die zugrunde liegenden HDFS-Blöcke effektiv zwischenzuspeichern und den Gesamtdurchsatz zu erhöhen. In unserer Testkonfiguration steht zu diesem Zweck auf jedem Serverknoten der Region etwa 96 GB OS-Cache zur Verfügung (wobei der von den DataNode- oder OS-Prozessen verwendete Speicher zur Vereinfachung ignoriert wird). Wenn wir dies über die 5 Regionsserver aggregieren, hatten wir ein Potenzial von fast 500 GB für Puffer (96 GB * 5 Regionsserver). Daher haben wir eine Datensatzgröße von 1 TB gewählt, was sowohl den konfigurierten Block-Cache als auch den verfügbaren Puffer-Cache des Betriebssystems übersteigt.

Zieldatengrößen in YCSB-Parameter umwandeln

In YCSB ist eine Zeile standardmäßig 1 KB groß. Je nachdem, wie viele Zeilen Sie in die YCSB-„Benutzertabelle“ laden, können Sie die Datengröße Ihrer YCSB-„Benutzertabelle“ leicht abschätzen. Wenn Sie also 1 Million Zeilen hochladen, haben Sie 1.000.000 * 1 KB =1 GB an Daten in die YCSB-„Benutzertabelle“ hochgeladen.

Die für unsere beiden Tests verwendeten Datensatzgrößen waren:

• 40 GB Datenvolumen mit 40 Millionen Zeilen
• 1 TB Daten mit 1 Milliarde Zeilen 

Testmethodik

CDP Private Cloud Base 7.2.2 wurde auf dem 6-Knoten-Cluster installiert und Workload-Daten mit 40 Millionen Zeilen (Gesamtgröße des Datensatzes => 40 GB) wurden generiert und YCSB-Workloads wurden ausgeführt. Nach dem Laden haben wir gewartet, bis alle Komprimierungsvorgänge abgeschlossen waren, bevor wir mit dem Workload-Test begonnen haben.

YCSB-Workloads, die auf HBase ausgeführt wurden, waren

1. Arbeitslast A:50 % Lesen und 50 % Aktualisieren
2. Workload C:100 % gelesen 
3. Arbeitslast F:50 % Lesen und 50 % Update/Lesen-Ändern-Schreiben-Verhältnis:50/50
4. Workload „Nur benutzerdefinierte Aktualisierung“:100 % Aktualisierung
   

Jeder YCSB-Workload (A, C, F und UpdateOnly) wurde jeweils 15 Minuten lang ausgeführt, und der vollständige Lauf wurde fünfmal ohne Neustarts zwischen den Läufen wiederholt, um den YCSB-Durchsatz* zu messen. Die gezeigten Ergebnisse sind Durchschnittswerte für die letzten 3 Läufe der 5 Läufe. Die ersten beiden Testläufe wurden ignoriert, um die Strafe für den ersten und zweiten Lauf zu vermeiden.

Nachdem 40-GB-Läufe abgeschlossen waren, haben wir die Benutzertabelle gelöscht und 1 Milliarde Zeilen neu generiert, um eine Datensatzgröße von 1 TB zu erstellen, und die Tests mit derselben Methodik auf demselben Cluster erneut ausgeführt.

Testergebnisse

YCSB-Ergebnisse mit 40 GB

Im 40-GB-Fall passen die Daten vollständig in den 61-GB-L1-Cache auf dem Cluster. Die während des Tests im Cluster beobachtete L1-Cache-Trefferquote lag bei fast 99 %.

Tipp: Für kleinere Datasets, bei denen Daten in den Cache passen, können wir auch die Option „Cache beim Laden“ verwenden und den Cache mit der Tabellenoption PREFETCH_BLOCKS_ON_OPEN vorwärmen, um eine Cache-Trefferquote von 100 % zu erhalten

Wir haben jede YCSB-Arbeitslast fünfmal für jeweils 15 Minuten ausgeführt und Durchschnittswerte aus den letzten drei Durchläufen genommen, um die Strafe für den ersten Durchlauf zu vermeiden.

Ergebnisse mit 40G L1-Cache-Trefferquote 99 % auf den Regionsservern sind unten in der Tabelle aufgeführt: 

YCSB-Ergebnisse mit 1-TB-Datensatz

Im 1-TB-Fall passen die Daten nicht in den 61-GB-L1-Cache auf dem Cluster oder den 500-GB-OS-Puffer-Cache. Die während des Tests beobachtete L1-Cache-Trefferquote im Cluster betrug 82–84 %.

Wir haben jede Workload fünfmal für jeweils 15 Minuten ausgeführt und Durchschnittswerte aus den letzten drei Durchläufen genommen, um die Strafe für den ersten Durchlauf zu vermeiden.

Ergebnisse mit 1 TB L1-Cache-Trefferquote 82–84 % auf den Regionsservern sind unten in der Tabelle aufgeführt: 

*Durchsatz (Operationen/Sek.) =Anzahl der Operationen pro Sekunde

Analyse:

Wenn wir die Testergebnisse für die beiden oben genannten unterschiedlichen Datensatzgrößen vergleichen, sehen wir, wie der Durchsatz der gleichen Workload von 3.000 Vorgängen pro Sekunde bis 165.000 Vorgängen pro Sekunde variieren kann wenn schneller auf Daten aus dem 40G-Datensatz mit aufgewärmtem Cache im Vergleich zum HDFS-Speicher zugegriffen wird.

Das folgende Diagramm zeigt den Durchsatz und vergleicht, wie sich der Durchsatz für unterschiedliche Workloads geändert hat, wenn er mit den Datensätzen mit zwei unterschiedlichen Größen ausgeführt wurde. Je höher der Balken im Diagramm, desto besser der Durchsatz.

Hinweis:Durchsatz =Operationen pro Sekunde

Wie im Diagramm zu sehen ist, hatten die YCSB-Workloads, die Daten wie Workload A, Workload C und Workload F lesen, einen viel besseren Durchsatz im 40-G-Fall, wo die Daten problemlos in den Cache passen, im Vergleich zu dem Fall mit einer Datengröße von 1 TB, in dem die HFile-Daten gespeichert werden mussten Zugriff über HDFS

Betrachtet man die Cache-Trefferquoten, so hatte der 40G-Datensatz eine Cache-Trefferquote von fast 99 % und der 1-TB-Datensatz eine Cache-Trefferquote von etwa 85 %, sodass auf 15 % der Daten im 1-TB-Fall vom hdfs-Speicher zugegriffen wurde .

Die von uns ausgeführte benutzerdefinierte YCSB-Arbeitslast, die nur Aktualisierungen durchführte, hatte in beiden Fällen denselben Durchsatz, da sie nur Aktualisierungen und keine Lesevorgänge ausführte.

Während der HBase-Leistung sehen wir uns die 95. und 99. Perzentil-Latenzen genau an. Die durchschnittliche Latenz ist nur der Gesamtdurchsatz dividiert durch die Gesamtzeit, jedoch zeigen das 95. Perzentil und das 99. Perzentil die tatsächlichen Ausreißer, die sich auf den gesamten Workload-Durchsatz auswirken. Im 1-TB-Fall führen die Ausreißer mit hoher Latenz im 95. und 99. Perzentil zu einer Verlangsamung des Durchsatzes, und im 40-GB-Fall führen die Cache-Treffer mit niedriger Latenz im 99. Perzentil zu einem erhöhten Gesamtdurchsatz.

Das folgende Diagramm zeigt den Latenzvergleich für die durchschnittliche Latenz, die 95. Perzentil-Latenz und die 99. Perzentil-Latenz und wie sie sich für verschiedene Workloads unterscheidet, wenn sie mit Datensätzen unterschiedlicher Größe ausgeführt werden.

Im obigen Diagramm sind die Balken, die die Latenz für den 40-GB-Datensatz darstellen, schwer zu erkennen, da sie im Vergleich zur Latenz, die für den 1-TB-Datensatz beobachtet wurde, der auf Daten von hdfs zugreift, extrem niedrig sind.

Wir haben das Latenzdiagramm mithilfe des Protokolls der Latenzwerte gezeichnet, um den Unterschied im Diagramm unten zu zeigen

Wie oben zu sehen ist, sind die Latenzen im 40-GB-Fall viel niedriger, wo die Cache-Trefferquote nahe bei 99 % liegt und die meisten Workload-Daten im Cache verfügbar sind. Im Vergleich zum 1-TB-Datensatz lag die Cache-Trefferquote bei etwa 85 %, da auf HFile-Daten aus dem HDFS-Speicher zugegriffen werden musste.

Die durchschnittliche Latenz von 99 für Workload C im 40G-Fall, bei dem 99 % der Daten aus dem aufgewärmten Cache zurückgegeben werden, betrug etwa 2 bis 4 ms. Die Latenz des 99. Perzentils für denselben Workload C im 1-TB-Fall betrug etwa 100 ms für Workload C (Nur-Lese-Workload).

Dies zeigt, dass ein Cache-Treffer aus dem On-Heap-Block-Cache einen Lesevorgang in etwa 2 ms zurückgibt und ein Cache-Miss und das Abrufen eines Datensatzes von HDFS auf diesem Cluster etwa 100 ms dauern kann.

Empfehlung: 

Bei der Durchführung eines YCSB-Benchmarking-Tests macht die Größe des Datensatzes einen wesentlichen Unterschied in den Leistungsergebnissen, und daher ist es sehr wichtig, den Test angemessen zu dimensionieren. Gleichzeitig hilft Ihnen die Betrachtung der Cache-Trefferquote und der Latenzunterschiede zwischen der minimalen und der 99. Latenz, die Latenz eines Cache-Treffers im Vergleich zum Zugriff auf Daten aus dem zugrunde liegenden Speicher im Cluster zu ermitteln.

Tipp:

Um die Cache-Trefferquoten Ihrer Workload auf einem Regionsserver zu überprüfen, können Sie den folgenden Befehl verwenden

curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio

Sie können die Cache-Trefferquote auch über die HBase-Webbenutzeroberfläche anzeigen, indem Sie die folgenden Schritte ausführen:

1. Klicken Sie in der HBase-Webbenutzeroberfläche auf den Regionsserver 
2. Wählen Sie im Block-Cache-Abschnitt L1 (und L2, wenn L2 konfiguriert ist) aus, um die Cache-Trefferquoten zu überprüfen.

Ein Screenshot, der die Cache-Trefferquote aus dem L1-Block-Cache zeigt, ist unten dargestellt:

Hier ist ein Link zu weiteren Informationen zum oben gezeigten HBase-Screenshot und Block-Cache https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

Über YCSB

YCSB ist eine Open-Source-Spezifikation und Programmsuite zur Bewertung der Abruf- und Wartungsfähigkeiten von Computerprogrammen. Es ist ein sehr beliebtes Tool zum Vergleich der relativen Leistung von NoSQL-Datenbankverwaltungssystemen.

Um YCSB zum Testen der Leistung von Operational Database zu verwenden, lesen Sie den Blog How to Run YCSB for HBase