Arbeiten mit Tabellenverlauf

Bei Apache Iceberg- und Delta Lake-Tabellen erstellt jeder Vorgang, der eine Tabelle ändert, eine neue Tabellenversion. Verwenden Sie Verlaufsinformationen zum Überwachen von Vorgängen, zum Zurücksetzen einer Tabelle oder zum Abfragen einer Tabelle zu einem bestimmten Zeitpunkt mithilfe von Zeitreisen.

Note

Databricks empfiehlt die Verwendung des Tabellenverlaufs nicht als langfristige Sicherungslösung für die Datenarchivierung. Verwenden Sie nur die letzten 7 Tage für Zeitreisevorgänge, es sei denn, Sie haben sowohl Daten- als auch Protokollaufbewahrungskonfigurationen auf einen größeren Wert festgelegt.

Tabellenverlauf abrufen

Führen Sie den DESCRIBE HISTORY Befehl aus, um Informationen einschließlich der Vorgänge, des Benutzers und des Zeitstempels für jeden Schreibvorgang in eine Tabelle abzurufen. Die Vorgänge werden in umgekehrter chronologischer Reihenfolge zurückgegeben.

Die Beibehaltung des Tabellenverlaufs wird durch die Tabelleneinstellung logRetentionDurationbestimmt, die standardmäßig auf 30 Tage festgelegt ist.

Note

Zeitreisen und Tabellenverlauf werden durch unterschiedliche Aufbewahrungsschwellenwerte gesteuert. Siehe Zeitreise.

DESCRIBE HISTORY table_name       -- get the full history of the table

DESCRIBE HISTORY table_name LIMIT 1  -- get the last operation only

Details zur Spark SQL-Syntax finden Sie unter DESCRIBE HISTORY.

Details zur Syntax von Scala, Java und Python finden Sie in der Dokumentation zur Delta Lake-API.

Katalog-Explorer zeigt den Tabellenverlauf visuell auf der Registerkarte "Verlauf " an.

Verlaufsschema

Die Ausgabe des Vorgangs history enthält die folgenden Spalten.

Column	Typ	Beschreibung
version	`long`	Die vom Vorgang generierte Tabellenversion.
timestamp	`timestamp`	Zeitpunkt, zu dem diese Version committet wurde.
userId	`string`	Die ID des Benutzers, der den Vorgang ausgeführt hat.
userName	`string`	Der Name des Benutzers, der den Vorgang ausgeführt hat.
operation	`string`	Der Name des Vorgangs.
operationParameters	`map`	Die Parameter des Vorgangs (z. B. Prädikate.)
job	`struct`	Die Details des Lakeflow-Einzelvorgangs, der den Vorgang ausgeführt hat. Füllt nur für Commits, die aus einem Lakeflow-Einzelvorgang geschrieben wurden. Andernfalls, `null`.
notebook	`struct`	Die Details des Databricks-Notizbuchs, aus dem der Vorgang ausgeführt wurde. Wird nur für Commits ausgefüllt, die in einem Databricks-Notebook erstellt wurden. Andernfalls, `null`.
clusterId	`string`	Die ID des Clusters, auf dem der Vorgang ausgeführt wurde.
readVersion	`long`	Die Version der Tabelle, die zum Ausführen des Schreibvorgangs gelesen wurde.
isolationLevel	`string`	Die für diesen Vorgang verwendete Isolationsstufe.
isBlindAppend	`boolean`	Gibt an, ob dieser Vorgang Daten angefügt hat.
operationMetrics	`map`	Die Metriken des Vorgangs (z. B. Anzahl von Zeilen und Dateien geändert.)
Benutzermetadaten	`string`	Die benutzerdefinierten Commit-Metadaten, falls angegeben.

+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+
|version|          timestamp|userId|userName|operation| operationParameters| job|notebook|clusterId|readVersion|   isolationLevel|isBlindAppend|    operationMetrics|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+
|      5|2019-07-29 14:07:47|   ###|     ###|   DELETE|[predicate -> ["(...|null|     ###|      ###|          4|WriteSerializable|        false|[numTotalRows -> ...|
|      4|2019-07-29 14:07:41|   ###|     ###|   UPDATE|[predicate -> (id...|null|     ###|      ###|          3|WriteSerializable|        false|[numTotalRows -> ...|
|      3|2019-07-29 14:07:29|   ###|     ###|   DELETE|[predicate -> ["(...|null|     ###|      ###|          2|WriteSerializable|        false|[numTotalRows -> ...|
|      2|2019-07-29 14:06:56|   ###|     ###|   UPDATE|[predicate -> (id...|null|     ###|      ###|          1|WriteSerializable|        false|[numTotalRows -> ...|
|      1|2019-07-29 14:04:31|   ###|     ###|   DELETE|[predicate -> ["(...|null|     ###|      ###|          0|WriteSerializable|        false|[numTotalRows -> ...|
|      0|2019-07-29 14:01:40|   ###|     ###|    WRITE|[mode -> ErrorIfE...|null|     ###|      ###|       null|WriteSerializable|         true|[numFiles -> 2, n...|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+

Note

Wenn Sie mithilfe der folgenden Methoden in eine Tabelle schreiben, stehen einige Spalten nicht zur Verfügung:
Zukünftig hinzugefügte Spalten werden immer hinter der letzten Spalte hinzugefügt.

Verständnis `partitionBy` für Betriebsparameter

Das partitionBy Feld im Tabellenverlauf ist nur für CREATE- und OVERWRITE-Vorgänge sinnvoll, die das Partitionsschema einer Tabelle definieren oder ändern.

Bei Anfügevorgängen an vorhandene Tabellen (APPEND, INSERT, , UPDATEDELETE, MERGE) kann in diesem Feld je nach verwendeter Schreibmethode ([] vs .save()) ein leeres Array .saveAsTable() oder Partitionsspalten angezeigt werden.

Diese Inkonsistenz ist ein erwartetes Verhalten und wirkt sich nicht darauf aus, wie Daten in Partitionen geschrieben werden. Sie sollten sie nicht zum Überprüfen von Anfügevorgängen verwenden.

Beispiel

Betrachten Sie eine Tabelle, die von der date Spalte partitioniert wird. Wenn Sie die Tabelle erstellen, wird partitionBy mit folgenden Werten gefüllt:

df.write.format("delta") \
  .partitionBy("date") \
  .saveAsTable("sales_data")

Der CREATE-Vorgang im Verlauf zeigt Folgendes:

operationParameters: {
  "mode": "ErrorIfExists",
  "partitionBy": "[\"date\"]"
}

Wenn Sie Daten an diese Tabelle anhängen, zeigt partitionBy ein leeres Array an:

new_df.write.format("delta") \
  .mode("append") \
  .saveAsTable("sales_data")

Der APPEND-Vorgang zeigt:

operationParameters: {
  "mode": "Append",
  "partitionBy": "[]"
}

Es wird erwartet, dass der partitionBy Wert leer ist. Die Daten werden weiterhin basierend auf dem vorhandenen Partitionsschema der Tabelle in die richtigen Partitionen geschrieben. Bitte beachten Sie, dass .save() in einem Pfad in diesem Feld Partitionsspalten anzeigen kann; dieser Unterschied ist jedoch ein Implementierungsdetail und hat keinen Einfluss auf das Schreibverhalten.

Vorgangsmetriken

Die Operation history gibt eine Sammlung von Operationsmetriken in der Spaltenmap operationMetrics zurück.

In den folgenden Tabellen sind die Kartenschlüsseldefinitionen pro Vorgang aufgeführt.