Experimente mit dem Backup und Restore von Apache Kudu

In der ORDIX news wurde bereits die Apache Kudu Datenbank vorgestellt. Im Juli 2019 wurde dann die Version 1.10.0 der Kudu Datenbank veröffentlicht. Über die Neuerungen berichtete Olaf Hein in einem ORDIX blog Beitrag. In diesem Beitrag wird die in der Version 1.10.0 implementierte Backup-Funktionalität sowie die Möglichkeit zur Analyse der Backups betrachtet. 

Zielsetzung 

In Version 1.10.0 von Apache Kudu wurde die Möglichkeit für logische, vollständige und inkrementelle Backups auf Tabellenebene geschaffen. Bei einem logischen Backup werden die Datensätze aus den Tabellen exportiert und in diesem Fall in Parquet-Dateien gespeichert. Möglichkeiten zur Erstellung eines Snapshots oder das Kopieren der physischen Datendateien werden nicht offiziell bereitgestellt. Aktuell wird nur das Apache Parquet-Format als Output-Format für Backups der Kudu Datenbank unterstützt.

Ziel diese Artikels ist es, aufzuzeigen, wie die erzeugten Backups mit Hilfe von Apache Hive und Impala analysiert werden können. Schwerpunkt sind dabei Erkenntnisse über die Anzahl der geänderten, hinzugefügten und gelöschten Datensätze in einem bestimmten Zeitraum.

Backups Analysieren – Vorgehensweise 

Um die Backups analysieren zu können, wird über die Parquet-Dateien, die bei einem Backup erzeugt werden, eine externe Hive-Tabelle gelegt. Im konkreten Fall bedeutet dies, dass jedes Backup, welches durch die backup-id identifizierbar ist, als eigene Partition einer Hive-Tabelle hinzugefügt wird. Hive wird hier aufgrund der Möglichkeit gewählt, eine externe Tabelle über die Backup-Dateien zu legen und diese flexibel um neue Partitionen zu erweitern. Zusätzlich wird durch die Integration im Hive-Metastore die Abfrage der Tabelle auch über andere Tools wie Impala, oder Apache Spark ermöglicht.

Erzeugte Backups werden in der folgenden Struktur im HDFS abgelegt: 

Inkrementelle Backups beinhalten dabei immer eine zusätzliche Spalte "ROW_ACTION", die den eigentlichen Datensätzen der Tabelle hinzugefügt wird. Diese zusätzliche Spalte wird auch später zur Analyse hinzugezogen.

Die vollständige Dokumentation für das Backup und Recovery von Kudu inklusive der Erläuterung der Struktur ist unter https://kudu.apache.org/releases/1.10.0/docs/administration.html#backup abrufbar.

Die in diesem Artikel aufgeführten Beispiele basieren auf der "ORDERS"-Tabelle des TPCH-Benchmark Dataset. Konkret wurde die "ORDERS"-Tabelle in Kudu als "ORDERS_KUDU"-Tabelle geladen und und mehrere Backups nach INSERT, UPDATE und DELETE Operationen durchgeführt.

Externe Tabelle Erstellen 

 Um auf den im HDFS unter /kudu-backups/* abgelegten Dateien eine externe Hive-Tabelle "ORDERS_BACKUP" zu erstellen, wird über die Hive-Beeline das "CREATE EXTERNAL TABLE"-SQL-Statement ausgeführt:

Zu beachten ist insbesondere der Partitionsschlüssel, der im weiteren Verlauf auf den Zeitstempel des Backups bzw. der backup-id gesetzt wird. Ebenfalls wichtig ist die Beachtung der bestehenden Spalten und deren Datentypen, da es sonst zu Fehlermeldungen bei der Erstellung und Abfrage der externen Tabelle kommen kann.

Um die Partitionen, also die jeweiligen Datensätze eines inkrementellen Backups, hinzuzufügen, wird das "ADD PARTITION"-SQL-Statement über die Hive-Beeline ausgeführt:

Nach dem Hinzufügen der angefertigten Backups steht die Tabelle als "ORDERS_BACKUP" zur Analyse bereit. 

Analyse der Backups 

Grundsätzlich können für die Analyse in Form von SQL-Abfragen sowohl die Hive-Beeline als auch auch die Impala-Shell genutzt werden.

Eine erste Analyse über SELECT-Statemens auf die jeweiligen Partitionen und die "ROW_ACTION" der einzelnen Datensätze zeigt folgende Ergebnisse:

Die Ergebnisse zeigen, dass mit Hilfe der zusätzlichen Spalte ROW_ACTION konkrete Aussagen über die im Backup enthaltenen Datensätze getroffen werden können. Damit können die weiteren SQL-Statements zur Analyse formuliert werden. Fokussiert wird sich dabei im Folgenden vor allem auf die Anzahl der Datensätze in einem Backup und die Änderungsoperationen (INSERT/UPDATE/DELETE). Wie die Ergebnisse zeigen, ist die Spalte "ROW_ACTION" in dem ersten vollständigen Backup nicht enthalten, somit lassen sich keine Operationen (bspw. UPDATE) auf in dem ersten Backup enthaltene Datensätze nachvollziehen.

Die Anzahl der Datensätze pro Backup in aufsteigender Reihenfolge kann über das folgende SQL-Statement abgefragt werden:

Etwas erweitert können die Datensätzen auch nach den jeweiligen Operationen (INSERT/UPDATE, DELETE) aufgeschlüsselt werden. Zur besseren Darstellung des Ergebnisses wurde hier mit optionalen Aliasen und CASE-Statements gearbeitet. 

 Ergebnis:

Um die Backups eines bestimmten Zeitraums zu analysieren, lassen sich auch alle Abfragen auf einen Zeitraum einschränken. Aus diesem Grund wurde die Tabelle in Hive über den UNIX-Timestamp partitioniert. So lässt sich jede Abfrage in Form von "ts =, ts >, ts <, ts >= und ts <=" über die ts-Spalte einschränken.

Fazit 

Backups von Tabellen der Apache-Kudu-Datenbank lassen sich mit geringem Aufwand und unter Zuhilfenahme von Hive und Impala analysieren. Damit können Informationen wie die Anzahl der Datensätze pro Backup, aber auch komplexere Information über die Löschung, Änderung oder das Hinzufügen von Datensätzen im Zeitverlauf gewonnen werden. Auch komplizierte Analysen wie bspw. die Untersuchung, wann bestimmte Datensätze gelöscht wurden, um im Fehlerszenario das richtige Backup wiederherzustellen, werden so ermöglicht. Einschränkungen gibt es bei der Analyse von vollständigen Backups, da diese keine zusätzliche Spalte "ROW_ACTION" beinhalten. Hier kann bspw. bei regelmäßigen vollständigen Backups über den Vergleich von mehreren Tabellen (bei einer Tabelle pro vollständigem Backup) gearbeitet werden.