Über den Autor: Chen Haifeng, ein Entwickler von Apache HBase, einer mobilen Cloud-Datenbank, hat ein starkes Interesse an Apache HBase, RBF und Apache Spark.
Hintergrund
Apache HBase ist ein umfangreicher, skalierbarer, verteilter Datenspeicherdienst im Apache Hadoop-Ökosystem. Es ist auch eine NoSQL-Datenbank. Es wurde entwickelt, um zufällige, stark konsistente Echtzeitabfragen für Milliarden von Datensatzzeilen mit Millionen von Spalten bereitzustellen. Standardmäßig werden HBase-Daten auf HDFS gespeichert, und HBase hat viele Optimierungen für HDFS vorgenommen, um Stabilität und Leistung sicherzustellen. Allerdings ist die Wartung von HDFS selbst gar nicht so einfach, denn es erfordert kontinuierliche Überwachung, Betrieb und Wartung, Tuning, Kapazitätserweiterung, Disaster Recovery etc., und auch die Kosten für den Aufbau von HDFS in der Public Cloud sind recht hoch. Um Geld zu sparen und die Wartungskosten zu senken, verwenden einige Benutzer S3 (oder einen anderen Objektspeicher), um HBase-Daten zu speichern. Die Verwendung von S3 erspart die Mühe der Überwachung von Betrieb und Wartung und realisiert auch die Trennung von Speicher und Datenverarbeitung, wodurch es einfacher wird, HBase zu erweitern und zu verkleinern.
Der HBase-Datenzugriff auf den Objektspeicher ist jedoch keine leichte Aufgabe. Einerseits hat der Objektspeicher aufgrund seiner eigenen Eigenschaften eingeschränkte Funktionen und Leistungen. Sobald Daten in den Objektspeicher geschrieben wurden, kann das Datenobjekt nicht mehr geändert werden. Andererseits hat die Verwendung der Dateisystem-Semantik für den Zugriff auf den Blockspeicher natürliche Einschränkungen. Wenn Sie den nativen AWS-Client von Hadoop für den Zugriff auf den Objektspeicher verwenden, durchläuft der Verzeichnisumbenennungsvorgang das gesamte Verzeichnis zum Kopieren und Löschen von Dateien, und die Leistung ist sehr gering. Außerdem verursacht die Umbenennungsoperation auch Atomizitätsprobleme, das heißt, die ursprüngliche Umbenennungsoperation wird in zwei Kopier- und Löschoperationen zerlegt, was in extremen Fällen zu einer Inkonsistenz der Benutzerdatenansichten führt. Ebenso gibt es eine Abfrage nach der Gesamtgröße aller Dateien in einem Verzeichnis, wobei das Prinzip darin besteht, alle Dateiinformationen eines Verzeichnisses sequentiell durch Traversal-Iteration zu erhalten. Wenn das Verzeichnis viele Unterverzeichnisse und Dateien enthält, ist die Abfrage der Gesamtgröße aller Dateien im Verzeichnis komplizierter und hat eine schlechtere Leistung.
Schemaauswahl
Nach umfangreicher Lösungsrecherche und Problemverfolgung in der Community gibt es derzeit drei Lösungen für die Speicherung von Objekten für den Cloud-HBase-Datenzugriff.
Das erste ist, dass HBase den nativen Hadoop-AWS-Client verwendet, um auf den Objektspeicher zuzugreifen , nämlich S3AFileSystem. Der HBase-Kernelcode erfordert nur geringfügige Änderungen, um S3AFileSystem zu verwenden. Ein Schmerzpunkt, der in dieser HBase-Objektspeicherlösung mit direktem Docking gelöst werden muss, ist die Umbenennung des Verzeichnisses. HBase umfasst die Verzeichnisumbenennung in der Hlog-Dateiverwaltung, MemStore Flush, Tabellenerstellung, Regionskomprimierung und Regionsteilung. Die Community hat StoreFile optimiert, um einige der Probleme mit der Umbenennungsleistung zu lösen. Um das Problem der Verzeichnisoperationsleistung vollständig zu lösen, sind drastische Änderungen am HBase-Kernel-Quellcode erforderlich.
Die zweite Lösung besteht darin, Alluxio als Cache-Beschleunigung einzuführen , die nicht nur die Lese- und Schreibleistung erheblich verbessert, sondern auch eine Dateimetadatenverwaltung einführt, die das Problem der geringen Leistung von Verzeichnisoperationen vollständig löst. Das scheinbar glückliche Ende hat viele Zwänge hinter sich. Wenn Alluxio so konfiguriert ist, dass nur Speicher verwendet wird, beträgt die für Verzeichnisoperationen benötigte Zeit ms. Wenn das UFS von Alluxio konfiguriert ist, besteht die Metadatenmanipulation in Alluxio aus zwei Schritten: Der erste Schritt besteht darin, den Status des Alluxio-Masters zu ändern, und der zweite Schritt besteht darin, eine Anfrage an UFS zu senden. Wie Sie sehen können, ist die Metadatenoperation immer noch nicht atomar, und ihr Zustand ist unvorhersehbar, wenn die Operation ausgeführt wird oder ein Fehler auftritt. Alluxio verlässt sich auf UFS für Metadatenoperationen, wie das Umbenennen einer Datei, die zu einer Kopier- und Löschoperation wird. Die Daten in HBase müssen auf der Festplatte platziert werden, und Alluxio kann das Leistungsproblem von Verzeichnisoperationen nicht lösen.
Die dritte Option besteht darin, das gemeinsame JuiceFS-Dateisystem zwischen HBase und Objektspeicher einzuführen . Bei Verwendung von JuiceFS zum Speichern von Daten werden die Daten selbst im Objektspeicher (z. B. EOS für mobile Clouds) gespeichert, und die entsprechenden Metadaten können bei Bedarf in Redis, MySQL und anderen Datenbanken gespeichert werden. Bei dieser Lösung wird der Verzeichnisvorgang in der Metadaten-Engine ohne Interaktion mit dem Objektspeicher abgeschlossen, und die Vorgangszeit liegt auf ms-Ebene, wodurch der Schmerzpunkt des HBase-Datenzugriffs auf den Objektspeicher gelöst werden kann. Da der JuiceFS-Kernel jedoch in der Go-Sprache geschrieben ist, bringt er bestimmte Herausforderungen für die spätere Leistungsoptimierung und routinemäßige Wartung mit sich.
Nach dem Abwägen der Vor- und Nachteile der drei oben genannten Lösungen wird JuiceFS schließlich als Lösung für Cloud-HBase zur Unterstützung der Objektspeicherung angenommen. Das Folgende konzentriert sich auf die Praxis und Leistungsoptimierung von JuiceFS in Cloud-HBase-unterstütztem Objektspeicher.
Eine Einleitung
Lassen Sie uns zunächst die Architektur von JuiceFS vorstellen. JuiceFS besteht aus zwei Hauptteilen: JuiceFS Metadata Service und Object Storage. Das JuiceFS Java SDK ist vollständig kompatibel mit der HDFS-API und bietet auch eine FUSE-basierte Client-Bereitstellung, die vollständig POSIX-kompatibel ist. Als Dateisystem verarbeitet JuiceFS Daten und die entsprechenden Metadaten separat, die Daten werden im Objektspeicher gespeichert und die Metadaten werden in der Metadaten-Engine gespeichert. In Bezug auf die Datenspeicherung unterstützt JuiceFS fast alle öffentlichen Cloud-Objektspeicher sowie OpenStack Swift, Ceph, MinIO und andere Open-Source-Objektspeicher, die eine private Bereitstellung unterstützen. In Bezug auf die Metadatenspeicherung verwendet JuiceFS ein Multi-Engine-Design und unterstützt derzeit Redis, TiKV, MySQL/MariaDB, PostgreSQL, SQLite usw. als Metadaten-Service-Engines.
Jede in JuiceFS gespeicherte Datei wird in "Blöcke" fester Größe mit einer Standardgröße von 64 MiB aufgeteilt. Jeder Chunk besteht aus einem oder mehreren „Slices“, und die Länge der Slices ist nicht festgelegt, je nachdem, wie die Datei geschrieben ist. Jedes Slice wird weiter in "Blöcke" mit fester Größe aufgeteilt, die standardmäßig 4 MiB groß sind. Schließlich werden diese Blöcke im Objektspeicher gespeichert. Gleichzeitig speichert JuiceFS jede Datei und ihre Chunks, Slices, Blöcke und andere Metadateninformationen in der Metadaten-Engine.
Mit JuiceFS werden Dateien schließlich in Chunks, Slices und Blocks aufgeteilt, um sie im Objektspeicher zu speichern. Daher können die in JuiceFS gespeicherten Quelldateien nicht auf der Objektspeicherplattform gefunden werden, und es gibt nur ein Chunks-Verzeichnis und eine Reihe von numerisch nummerierten Verzeichnissen und Dateien im Bucket.
Die folgende Konfiguration ist erforderlich, damit HBase-Komponenten JuiceFS verwenden können. Fügen Sie zuerst das kompilierte Client-SDK in den HBase-Klassenpfad ein. Schreiben Sie als Nächstes die JuiceFS-bezogene Konfiguration in die Konfigurationsdatei core-site.xml, wie in der folgenden Tabelle gezeigt. Schließlich formatieren Sie das Dateisystem mit dem Juifs-Client.
| Konfigurationselement | Standardwerte | beschreiben |
|---|---|---|
| fs.jfs.impl | io.juicefs.JuiceFileSystem | Gibt die zu verwendende Speicherimplementierung an, standardmäßig jfs:// |
| fs.AbstractFileSystem.jfs.impl | io.juicefs.JuiceFS | |
| juicefs.meta | Gibt die Metadaten-Engine-Adresse des vorab erstellten JuiceFS-Dateisystems an. |
In Bezug auf die Metadatenspeicherung wird MySQL als Metadatenspeicher verwendet. Der Befehl zum Formatieren des Dateisystems lautet wie folgt. Es ist ersichtlich, dass zum Formatieren des Dateisystems die folgenden Informationen erforderlich sind:
--storage: Legen Sie den Speichertyp fest, z. B. Mobile Cloud EOS;--bucket: Legen Sie die Endpunktadresse des Objektspeichers fest;--access-key: Legen Sie die Zugriffsschlüssel-ID des Objektspeicher-API-Zugriffsschlüssels fest;--secret-key: Legen Sie das Schlüsselgeheimnis für den Objektspeicher-API-Zugriff fest.
juicefs format --storage eos \
--bucket https://myjfs.eos-wuxi-1.cmecloud.cn \
--access-key ABCDEFGHIJKLMNopqXYZ \
--secret-key ZYXwvutsrqpoNMLkJiHgfeDCBA \
mysql://username:password@(ip:port)/database NAME
Schemaverifizierung und -optimierung
Beginnen Sie nach der Einführung in die Verwendung von Juicefs mit dem Testen. In der Testumgebung wurde ein Server mit 48 Kernen und 187G Speicher ausgewählt. Im HBase-Cluster gibt es einen HMaster, einen RegionServer und drei Tierpfleger. In der Metadaten-Engine wird das Drei-Knoten-MySQL mit Master-Slave-Replikation verwendet. Der Objektspeicher verwendet den mobilen Cloud-Objektspeicher EOS, und die Netzwerkstrategie übernimmt das öffentliche Netzwerk. Juicefs konfiguriert die Blockgröße auf 64 MB, die physische Speicherblockgröße auf 4 MB, keinen Cache und 300 MB für MEM. Wir haben zwei Sätze von HBase-Clustern erstellt, einer ist HBase, der direkt auf dem mobilen Cloud-Objektspeicher platziert ist, der andere ist die Einführung von Juicefs zwischen HBase und mobilem Cloud-Objektspeicher. Sequenzielles Schreiben und zufälliges Lesen sind zwei wichtige Leistungsindikatoren des HBase-Clusters, und die PE-Testtools werden verwendet, um diese beiden Leistungsindikatoren zu testen. Die Test-Lese- und Schreibleistung ist in der folgenden Tabelle aufgeführt.
Cluster-Umgebung
| Clusterumgebung HBase-juicefs-EOS (Zeile/n) | Clusterumgebung HBase-EOS (Zeile/n) | |
|---|---|---|
| nacheinander schreiben | 79465 | 33343 |
| zufällig gelesen | 6698 | 6476 |
Laut den Testergebnissen wird mit der Juicefs-Lösung die sequentielle Schreibleistung des Clusters erheblich verbessert, aber die zufällige Leseleistung wird nicht verbessert. Der Grund dafür ist, dass die Schreibanforderung durch Schreiben in den Client-Speicherpuffer zurückgegeben werden kann, sodass die Schreiblatenz von JuiceFS im Allgemeinen sehr gering ist (zig Mikrosekunden). Wenn JuiceFS eine Leseanfrage verarbeitet, liest es im Allgemeinen den Objektspeicher gemäß der 4M-Block-Alignment-Methode, um eine gewisse Vorlesefunktion zu erreichen. Gleichzeitig werden die gelesenen Daten zur späteren Verwendung in das lokale Cache-Verzeichnis geschrieben. Beim sequentiellen Lesen wird auf die vorab gewonnenen Daten durch nachfolgende Anfragen zugegriffen und die Cache-Hit-Rate ist sehr hoch, sodass auch die Leseleistung des Objektspeichers voll ausgenutzt werden kann. Während des zufälligen Lesens ist die Pre-Caching-Effizienz von JuiceFS jedoch nicht hoch, aber die tatsächliche Nutzung der Systemressourcen wird aufgrund von Leseverstärkung und häufigen Schreibvorgängen und Räumungen des lokalen Caches reduziert.
Um die Leistung beim zufälligen Lesen zu verbessern, können zwei Richtungen in Betracht gezogen werden. Einer besteht darin, die Gesamtkapazität des Caches so weit wie möglich zu erhöhen, um den Effekt zu erzielen, dass die erforderlichen Daten fast vollständig zwischengespeichert werden.Im Szenario der Verwendung massiver Daten ist diese Optimierungsrichtung nicht durchführbar. Eine andere Richtung besteht darin, den JuiceFS-Kernel tief zu kultivieren und die Logik zum Lesen von Daten zu optimieren.
Derzeit haben wir folgende Optimierungen vorgenommen: 1) Deaktivieren Sie den Vorlesemechanismus und die Cache-Funktion, um die Datenleselogik zu vereinfachen, 2) Vermeiden Sie so weit wie möglich das Zwischenspeichern der gesamten Blockdaten und verwenden Sie häufiger HTTP-Anforderungsdaten von Range; 3) Stellen Sie eine kleinere Blockgröße ein 4) Verbessern Sie die Leseleistung des Objektspeichers so weit wie möglich. Nach Tests in der F&E-Umgebung wird die zufällige Leseleistung nach der Optimierung um etwa 70 % verbessert.
In Kombination mit der vorherigen Testarbeit erreicht Cloud HBase nach der Verwendung von Objektspeicher als zugrunde liegendes Datenspeichersystem die gleiche Lese- und Schreibleistung wie in HDFS gespeicherte Daten, aber der Benutzer verbraucht weniger als die Hälfte der in HDFS gespeicherten Daten Objektspeicherung ist eine Forschungs- und Entwicklungspraxis, die sowohl den Kuchen als auch die Pfote hat.
Wenn es hilfreich ist, folgen Sie bitte unserem Projekt Juicedata/JuiceFS ! (0ᴗ0✿)