HBase
 sql >> Datenbank >  >> NoSQL >> HBase

Online Apache HBase Backups mit CopyTable

CopyTable ist ein einfaches Apache HBase-Dienstprogramm, das wenig überraschend zum Kopieren einzelner Tabellen innerhalb eines HBase-Clusters oder von einem HBase-Cluster zu einem anderen verwendet werden kann. In diesem Blogbeitrag sprechen wir darüber, was dieses Tool ist, warum Sie es verwenden möchten, wie Sie es verwenden und einige allgemeine Konfigurationsvorbehalte.

Anwendungsfälle:

CopyTable ist im Kern ein Apache Hadoop MapReduce-Job, der die standardmäßige HBase Scan-Lesepfadschnittstelle verwendet, um Datensätze aus einer einzelnen Tabelle zu lesen und sie mithilfe der standardmäßigen HBase Put-Schreibpfadschnittstelle in eine andere Tabelle (möglicherweise auf einem separaten Cluster) zu schreiben. Es kann für viele Zwecke verwendet werden:

  • Interne Kopie einer Tabelle (Schnappschuss des armen Mannes)
  • Remote-HBase-Instanzsicherung
  • Inkrementelle HBase-Tabellenkopien
  • Teilweise HBase-Tabellenkopien und HBase-Tabellenschemaänderungen

Annahmen und Einschränkungen:

Das CopyTable-Tool hat einige grundlegende Annahmen und Einschränkungen. Erstens müssen bei Verwendung in einer Multi-Cluster-Situation beide Cluster online sein und die Zielinstanz muss die Zieltabelle mit denselben Spaltenfamilien haben, die als Quelltabelle definiert sind.

Da das Tool standardmäßige Scans und Puts verwendet, muss der Zielcluster nicht die gleiche Anzahl von Knoten oder Regionen haben. Tatsächlich kann es eine unterschiedliche Anzahl von Tabellen, eine unterschiedliche Anzahl von Regionsservern und völlig unterschiedliche Regionsaufteilungsgrenzen haben. Da wir ganze Tabellen kopieren, können Sie Leistungsoptimierungseinstellungen verwenden, wie z. B. das Festlegen größerer Scanner-Caching-Werte für mehr Effizienz. Die Verwendung der Put-Schnittstelle bedeutet auch, dass Kopien zwischen Clustern verschiedener Nebenversionen erstellt werden können. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) oder kabelkompatible Versionen (0.92.1 -> 0.94.0).

Schließlich bietet HBase nur ACID-Garantien auf Zeilenebene; Das bedeutet, dass während einer CopyTable neu eingefügte oder aktualisierte Zeilen auftreten können und diese gleichzeitigen Bearbeitungen entweder vollständig eingeschlossen oder vollständig ausgeschlossen werden. Während die Zeilen konsistent sind, gibt es keine Garantien für die Konsistenz, Kausalität oder Reihenfolge der Puts in den anderen Zeilen.

Interne Kopie einer Tabelle (Schnappschuss des armen Mannes)

HBase-Versionen bis einschließlich der neuesten 0.94.x-Versionen unterstützen keine Tabellen-Snapshots. Trotz der ACID-Einschränkungen von HBase kann CopyTable als naiver Snapshot-Mechanismus verwendet werden, der eine physische Kopie einer bestimmten Tabelle erstellt.

Nehmen wir an, wir haben eine Tabelle, tableOrig, mit den Spaltenfamilien cf1 und cf2. Wir wollen alle seine Daten nach tableCopy kopieren. Wir müssen zuerst tableCopy mit denselben Spaltenfamilien erstellen:

srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell

Wir können dann die Tabelle mit einem neuen Namen auf derselben HBase-Instanz erstellen und kopieren:

srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig

Dies startet einen MR-Job, der die Daten kopiert.

Remote-HBase-Instanzsicherung

Angenommen, wir möchten Daten in einen anderen Cluster kopieren. Dies kann eine einmalige Sicherung, ein regelmäßiger Job oder das Bootstrapping für die clusterübergreifende Replikation sein. In diesem Beispiel haben wir zwei separate Cluster:srcCluster und dstCluster.

In diesem Multi-Cluster-Fall ist CopyTable ein Push-Prozess – Ihre Quelle ist die HBase-Instanz, auf die sich Ihre aktuelle hbase-site.xml bezieht, und die hinzugefügten Argumente verweisen auf den Zielcluster und die Zieltabelle. Dies setzt auch voraus, dass alle MR TaskTracker auf alle HBase- und ZK-Knoten im Zielcluster zugreifen können. Dieser Konfigurationsmechanismus bedeutet auch, dass Sie dies als Job auf einem Remote-Cluster ausführen können, indem Sie die hbase/mr-Konfigurationen überschreiben, um Einstellungen von jedem zugänglichen Remote-Cluster zu verwenden und die ZK-Knoten im Zielcluster anzugeben. Dies kann nützlich sein, wenn Sie Daten aus einem HBase-Cluster mit niedrigeren SLAs kopieren und keine MR-Jobs direkt darauf ausführen möchten.

Sie verwenden die Einstellung –peer.adr, um das ZK-Ensemble des Zielclusters anzugeben (z. B. das Cluster, in das Sie kopieren). Dazu benötigen wir die IP und den Port des ZK-Quorums sowie den HBase-Root-ZK-Knoten für unsere HBase-Instanz. Nehmen wir an, einer dieser Rechner ist srcClusterZK (aufgelistet in hbase.zookeeper.quorum) und wir verwenden den Standard-zk-Client-Port 2181 (hbase.zookeeper.property.clientPort) und den standardmäßigen ZK-Znode-Elternteil /hbase (zookeeper.znode. Elternteil). (Hinweis:Wenn Sie zwei HBase-Instanzen hatten, die denselben ZK verwenden, benötigen Sie für jeden Cluster einen anderen zookeeper.znode.parent.

# create new tableOrig on destination cluster
dstCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
# on source cluster run copy table with destination ZK quorum specified using --peer.adr
# WARNING: In older versions, you are not alerted about any typo in these arguments!
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase tableOrig

Beachten Sie, dass Sie das Argument –new.name mit –peer.adr verwenden können, um in eine anders benannte Tabelle auf dem dstCluster zu kopieren.

# create new tableCopy on destination cluster
dstCluster$ echo "create 'tableCopy', 'cf1', 'cf2'" | hbase shell
# on source cluster run copy table with destination --peer.adr and --new.name arguments.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase --new.name=tableCopy tableOrig

Dadurch werden Daten von tableOrig auf dem srcCluster in die tableCopy-Tabelle von dstCluster kopiert.

Inkrementelle HBase-Tabellenkopien

Wie kopieren Sie neue Daten, die später in den Quellcluster geschrieben werden, sobald Sie eine Kopie einer Tabelle in einem Zielcluster haben? Naiverweise könnten Sie den CopyTable-Job erneut ausführen und die gesamte Tabelle kopieren. CopyTable bietet jedoch einen effizienteren inkrementellen Kopiermechanismus, der einfach die aktualisierten Zeilen aus dem srcCluster in den Backup-dstCluster kopiert, der in einem Zeitfenster angegeben ist. Daher könnten Sie nach der ersten Kopie einen periodischen Cron-Job haben, der nur Daten der letzten Stunde von srcCluster auf dstCuster kopiert.

Dies geschieht durch Angabe der Argumente –starttime und –endtime. Zeiten werden als dezimale Millisekunden seit der Unix-Epochenzeit angegeben.

# WARNING: In older versions, you are not alerted about any typo in these arguments!
# copy from beginning of time until timeEnd 
# NOTE: Must include start time for end time to be respected. start time cannot be 0.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=1 --endtime=timeEnd ...
# Copy from starting from and including timeStart until the end of time.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timeStart ...
# Copy entries rows with start time1 including time1 and ending at timeStart excluding timeEnd.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timestart --endtime=timeEnd

Teilweise HBase-Tabellenkopien und HBase-Tabellenschemaänderungen

Standardmäßig kopiert CopyTable alle Spaltenfamilien aus übereinstimmenden Zeilen. CopyTable bietet Optionen zum ausschließlichen Kopieren von Daten aus bestimmten Spaltenfamilien. Dies kann nützlich sein, um ursprüngliche Quelldaten zu kopieren und abgeleitete Datenspaltenfamilien auszuschließen, die durch Folgeverarbeitung hinzugefügt werden.

Durch Hinzufügen dieser Argumente kopieren wir nur Daten aus den angegebenen Spaltenfamilien.

  • –familien=srcCf1
  • –familien=srcCf1,srcCf2

Ab 0.92.0 können Sie kopieren, während Sie den Familiennamen der Spalte ändern:

  • –familien=srcCf1:dstCf1
    • von srcCf1 nach dstCf1 kopieren
  • –familien=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
    • Kopiere von srcCf1 nach destCf1, kopiere dstCf2 nach dstCf2 (keine Umbenennung) und srcCf3 nach dstCf3

Bitte beachten Sie, dass dstCf* in der dstCluster-Tabelle vorhanden sein muss!

Ab 0.94.0 werden neue Optionen angeboten, um Löschmarkierungen zu kopieren und eine begrenzte Anzahl überschriebener Versionen einzufügen. Wenn zuvor eine Zeile im Quellcluster gelöscht wurde, wurde die Löschung nicht kopiert – stattdessen verblieb eine veraltete Version dieser Zeile im Zielcluster. Dies nutzt einige der erweiterten Funktionen der Version 0.94.0.

  • –versions=vers
    • wobei vers die Anzahl der zu kopierenden Zellversionen ist (Standard ist 1, auch bekannt als nur die neueste)
  • –all.cells
    • kopiere auch Löschmarkierungen und gelöschte Zellen

Häufige Fallstricke

Der HBase-Client in den Versionen 0.90.x, 0.92.x und 0.94.x verwendet immer zoo.cfg, wenn es sich im Klassenpfad befindet, selbst wenn eine hbase-site.xml-Datei andere ZooKeeper-Quorum-Konfigurationseinstellungen angibt. Dieses „Feature“ verursacht ein in CDH3 HBase übliches Problem, da seine Pakete standardmäßig ein Verzeichnis enthalten, in dem sich zoo.cfg im Klassenpfad von HBase befindet. Dies kann und hat beim Versuch, CopyTable (HBASE-4614) zu verwenden, zu Frustration geführt. Die Problemumgehung hierfür besteht darin, die Datei zoo.cfg aus dem Klassenpfad Ihrer HBase auszuschließen und ZooKeeper-Konfigurationseigenschaften in Ihrer Datei hbase-site.xml anzugeben. http://hbase.apache.org/book.html#zookeeper

Schlussfolgerung

CopyTable bietet eine einfache, aber effektive Notfallwiederherstellungsversicherung für HBase 0.90.x (CDH3)-Bereitstellungen. In Verbindung mit der Replikationsfunktion, die in CDH4s HBase 0.92.x-basierter HBase gefunden und unterstützt wird, werden die inkrementellen Funktionen von CopyTable weniger wertvoll, aber ihre Kernfunktionalität ist wichtig für das Bootstrapping einer replizierten Tabelle. Auch wenn fortgeschrittenere Funktionen wie HBase-Snapshots (HBASE-50) nach der Implementierung bei der Notfallwiederherstellung helfen können, wird CopyTable immer noch ein nützliches Tool für den HBase-Administrator sein.