Verwaltete Tabellen sind Hive-eigene Tabellen, bei denen der gesamte Lebenszyklus der Tabellendaten von Hive verwaltet und kontrolliert wird. Externe Tabellen sind Tabellen, bei denen Hive eine lose Kopplung mit den Daten hat. Der Replication Manager repliziert externe Tabellen erfolgreich auf einen Zielcluster. Die verwalteten Tabellen werden nach der Replikation in externe Tabellen umgewandelt.

Hive unterstützt die Replikation von externen Tabellen mit Daten auf den Zielcluster und behält alle Eigenschaften der externen Tabellen bei. Die Berechtigung und der Besitz der Datendateien bleiben erhalten, so dass die entsprechenden externen Prozesse auch nach dem Failover weiterhin darin schreiben können.

Die Schreibvorgänge auf externen Tabellen werden mit den SQL-Befehlen von Hive durchgeführt, und die Datendateien können auch von Prozessen außerhalb von Hive aufgerufen und verwaltet werden. Wenn eine externe Tabelle oder Partition gelöscht wird, werden nur die mit der Tabelle oder Partition verbundenen Metadaten gelöscht, die zugrunde liegenden Datendateien bleiben jedoch intakt. Ein typisches Beispiel für eine externe Tabelle ist die Ausführung analytischer Abfragen auf HBase- oder Druid-eigenen Daten mit Hive, wobei die Datendateien von HBase oder Druid geschrieben werden und Hive sie für die Analyse liest.

Wenn Sie einen Zeitplan für eine Hive-Replikationsrichtlinie erstellen, legen Sie die Häufigkeit so fest, dass Änderungen oft genug repliziert werden, um zu große Kopien zu vermeiden.

Bei der Hive-Replikation können Sie auf folgende Anwendungsfälle stoßen:

Anwendungsfall Replication Manager-Upgrade In einem normalen Szenario, wenn Sie externe Tabellen hatten, die als verwaltete Tabellen repliziert wurden, müssen Sie diese Tabellen nach dem Upgrade-Prozess aus dem Ziel löschen und das Basisverzeichnis festlegen. In der nächsten Instanz werden sie dann als externe Tabellen repliziert. Konflikte beim Speicherort der Daten externer Tabellen bei der Replikation mehrerer Quellcluster auf denselben Zielcluster Um Konflikte beim Speicherort der Daten externer Tabellen bei der Replikation mehrerer Quellcluster auf denselben Zielcluster zu behandeln, weist der Replication Manager jedem Quellcluster ein eindeutiges Basisverzeichnis zu, unter das die Daten externer Tabellen aus dem entsprechenden Quellcluster kopiert werden. Wenn der Speicherort der externen Tabellen in einem Quellcluster beispielsweise /ext/hbase_data ist, lautet der Speicherort im Zielcluster nach der Replikation <base_dir>/ext/hbase_data. Sie können den Befehl DESCRIBE TABLE verwenden, um den neuen Speicherort der externen Tabellen zu verfolgen. Replikationskonflikte zwischen HDFS- und Hive-Speicherort für externe Tabellen Wenn Sie die Hive-Replikationsrichtlinie für eine externe Tabelle ausführen, werden die Daten im Zielverzeichnis an einem bestimmten Speicherort gespeichert. Wenn Sie dann die HDFS-Replikationsrichtlinie ausführen, die versucht, Daten an denselben Speicherort der externen Tabelle zu kopieren, stellt Replication Manager sicher, dass die Hive-Daten nicht von HDFS überschrieben werden. Wenn Sie beispielsweise eine Hive-Replikationsrichtlinie für eine externe Tabelle ausführen, erstellt die Richtlinie ein Zielverzeichnis /tmp/db1/ext1. Wenn Sie eine HDFS-Replikationsrichtlinie ausführen, sollte die Richtlinie die Daten nicht außer Kraft setzen, indem sie in das Verzeichnis /tmp/db1/ext1 repliziert. Konflikte während des Replikationsprozesses für externe Tabellen Konflikte treten auf, wenn zwei Hive-Replikationsrichtlinien auf DB1 und DB2 (entweder aus demselben Quellcluster oder aus verschiedenen Quellclustern) externe Tabellen haben, die auf denselben Datenspeicherort verweisen (z. B. /abc) und auf denselben Zielcluster repliziert werden. Um solche Konflikte zu vermeiden, müssen Sie unterschiedliche Pfade für die Konfiguration des Basisverzeichnisses der externen Tabellen für beide Richtlinien festlegen. Legen Sie zum Beispiel /db1 für DB1 und /db2 für DB2 fest. Dadurch wird sichergestellt, dass der Speicherort der externen Tabellendaten für beide Datenbanken unterschiedlich ist. Zum Beispiel: /db1/abcd und /db2/abcd.

Articles

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.