Cloudera Data Platform (CDP) bietet eine sofort einsatzbereite Lösung, die es Apache HBase-Bereitstellungen ermöglicht, Amazon Simple Storage Service (S3) als Hauptpersistenzschicht zum Speichern von Tabellendaten zu verwenden. Amazon S3 ist ein Objektspeicher, der ein hohes Maß an Langlebigkeit mit einer Pay-per-Use-Kostenstruktur bietet. Für S3 muss keine serverseitige Komponente ausgeführt oder verwaltet werden – es werden lediglich die S3-Client-Bibliothek und AWS-Anmeldeinformationen benötigt. HBase erfordert jedoch ein konsistentes und atomares Dateisystem, was bedeutet, dass S3 nicht direkt verwendet werden kann, da es sich um einen letztendlich konsistenten Objektspeicher handelt. Sowohl CDH als auch HDP haben HBase nur mit HDFS bereitgestellt, da es seit langem Hindernisse gab, die HBase daran hinderten, S3 nativ zu verwenden. Um diese Probleme anzugehen, haben wir eine sofort einsatzbereite Lösung entwickelt, die wir zum ersten Mal über CDP bereitstellen. Wenn Sie einen Operational Database (HBase)-Cluster auf CDP starten, werden HBase StoreFiles (die Sicherungsdateien für HBase-Tabellen) in S3 und HBase Write-Ahead-Logs (WAL) in einer HDFS-Instanz gespeichert, die wie gewohnt neben HBase ausgeführt wird.
Wir beschreiben kurz jede Komponente, die in diese Architektur einfließt, und die Rolle, die jede erfüllt.
Der S3A-Dateisystemadapter wird von Hadoop bereitgestellt, um über die standardmäßigen Dateisystem-APIs auf Daten in S3 zuzugreifen. Der S3A-Adapter ermöglicht Anwendungen, die für Hadoop-APIs geschrieben wurden, auf Daten in S3 zuzugreifen, indem ein URI der Form „s3a://my_bucket/“ anstelle von „hdfs://namenode:8020/“ wie bei HDFS verwendet wird. Die Möglichkeit, ein zu verwendendes Standard-„Dateisystem“ anzugeben, macht Migrationen im „Lift-and-Shift“-Stil von On-Prem-Clustern mit HDFS zu Cloud-basierten Clustern mit S3 extrem einfach. HBase kann mit einem Basisspeicherort (z. B. einem Verzeichnis in HDFS oder einem S3-Bucket) für alle Anwendungsdaten konfiguriert werden, sodass HBase gleich funktionieren kann, unabhängig davon, ob sich diese Daten in HDFS oder S3 befinden.
S3Guard ist Teil des Apache Hadoop-Projekts, das konsistente Verzeichnislisten und Objektstatus für den S3A-Adapter bereitstellt, die für die Anwendung transparent sind. Um dies zu erreichen, verwendet S3Guard eine konsistente, verteilte Datenbank, um Änderungen an S3 nachzuverfolgen, und garantiert, dass ein Client immer den korrekten Status von S3 sieht. Ohne S3Guard sieht HBase möglicherweise keine neue StoreFile, die einer HBase-Tabelle hinzugefügt wurde. Wenn HBase eine Datei auch nur vorübergehend nicht beobachtet, kann dies zu Datenverlust in HBase führen. S3guard bietet jedoch nicht alles, was HBase für die Verwendung von S3 benötigt.
HBase Object Store Semantics (oder einfach „HBOSS“) ist ein neues Softwareprojekt im Rahmen des Apache HBase-Projekts, das speziell entwickelt wurde, um die Lücke zwischen S3Guard und HBase zu schließen. HBOSS ist eine Fassade auf dem S3A-Adapter und S3Guard, die eine verteilte Sperre verwendet, um sicherzustellen, dass HBase-Vorgänge atomar können seine Dateien auf S3 manipulieren. Ein Beispiel, bei dem HBase Atomarität erfordert, ist eine Verzeichnisumbenennung. Beim S3-Client wird eine Umbenennung als Kopie der Quelldaten zum Ziel implementiert, gefolgt von einer Löschung der Quelldaten. Ohne die von HBOSS bereitgestellte Sperre sieht HBase möglicherweise, dass der Umbenennungsvorgang ausgeführt wird, was zu Datenverlust führen kann. Um dieses verteilte Sperren zu erreichen, verwendet HBOSS Apache ZooKeeper. Die Wiederverwendung von ZooKeeper ist beabsichtigt, da HBase bereits eine ZooKeeper-Instanz benötigt, um sicherzustellen, dass alle HBase-Dienste zusammen funktionieren. Somit erfordert die Einbindung von HBOSS keinen zusätzlichen Aufwand für das Service-Management und schließt die Lücke zu dem, was HBase für die Verwendung von S3 mit S3Guard benötigt.
Die Konfiguration von HBase für die Verwendung von S3 für seine StoreFiles hat viele Vorteile für unsere Benutzer. Einer dieser Vorteile besteht darin, dass Benutzer ihren Speicher und ihre Rechenleistung entkoppeln können. Wenn es Zeiten gibt, in denen kein Zugriff auf HBase erforderlich ist, kann HBase sauber heruntergefahren und alle Rechenressourcen zurückgewonnen werden, um jegliche Betriebskosten zu eliminieren. Wenn der HBase-Zugriff erneut benötigt wird, kann der HBase-Cluster neu erstellt werden und auf dieselben Daten in S3 verweisen. Beim Start kann sich HBase ausschließlich aus den Daten in S3 neu initialisieren.
Die Verwendung von S3 zum Speichern von HBase StoreFiles ist mit einigen Herausforderungen verbunden. Ein solches Problem ist die erhöhte Latenz für eine zufällige Suche nach einer Datei in S3 im Vergleich zu HDFS. Eine erhöhte Latenz beim S3-Zugriff würde dazu führen, dass HBase Gets und Scans länger dauern als normalerweise mit HDFS. S3-Latenzen variieren von 10 bis 100 Millisekunden im Vergleich zum Bereich von 0,1 bis 9 Millisekunden bei HDFS. CDP kann die Auswirkungen dieser S3-Latenz verringern, indem HBase automatisch für die Verwendung des BucketCache konfiguriert wird. Bei aktiviertem BucketCache treten S3-Latenzen nur beim ersten Auslesen einer StoreFile aus S3 auf. Nachdem HBase eine Datei gelesen hat, versucht es, die Rohdaten zwischenzuspeichern, um langsame S3-Lesevorgänge durch schnelle Lesevorgänge im lokalen Speicher zu ersetzen. Wenn ein HBase-Cluster über CDP gestartet wird, wird er automatisch so konfiguriert, dass kürzlich gelesene Daten aus S3 im Arbeitsspeicher zwischengespeichert werden, um schnellere Lesevorgänge von „heißen“ Daten zu ermöglichen.
Wir freuen uns sehr, unseren Benutzern diese neuen Funktionen zur Verfügung zu stellen. Probieren Sie HBase noch heute auf S3 in der Operational Database-Vorlage in CDP aus!
