Tabellengeschichtsschema und Operationsmetriken

Der Befehl DESCRIBE HISTORY liefert 14 Spalten für Apache Iceberg- und Delta Lake-Tabellen, die die Geschichte der Tabellenoperationen beschreiben. Verwenden Sie diese Referenz, um jede Spalte zu interpretieren.

Für Hinweise zum Abruf der Tabellenhistorie, zum Abfragen früherer Tabellenversionen und zur Wiederherstellung einer Tabelle siehe Arbeit mit Tabellengeschichte.

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.
Betrieb	`string`	Der Name des Vorgangs.
Betriebsparameter	`map`	Die Parameter des Vorgangs (z. B. Prädikate.) Bei `OPTIMIZE` Vorgängen identifizieren diese Parameter den Typ des Vorgangs. Siehe Identifizieren des Vorgangstyps`OPTIMIZE`.
job	`struct`	Die Details des Lakeflow-Auftrags, der den Vorgang ausgeführt hat. Füllt nur für Commits, die aus einem Lakeflow-Auftrag 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.
Version lesen	`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...|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+

Hinweis

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. Beachten Sie, dass beim Schreiben in einen Pfad .save() in diesem Feld möglicherweise Partitionsspalten angezeigt werden, dieser Unterschied jedoch ein Implementierungsdetail ist und keine Auswirkungen auf das Schreibverhalten hat.

Vorgangsmetriken

Die Operation history liefert eine Sammlung von Operationsmetriken in der Spaltenabbildung operationMetrics .

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