Schema van tabelgeschiedenis en operatiemetrieken

Het DESCRIBE HISTORY commando geeft 14 kolommen terug voor Apache Iceberg- en Delta Lake-tabellen die de geschiedenis van de tabeloperaties beschrijven. Gebruik deze referentie om elke kolom te interpreteren.

Voor begeleiding bij het ophalen van tabelgeschiedenis, het opvragen van eerdere tabelversies en het herstellen van een tabel, zie Werken met tabelgeschiedenis.

Geschiedenisschema

De uitvoer van de history bewerking heeft de volgende kolommen.

Rubriek	Type	Description
version	`long`	De tabelversie die door de bewerking is gegenereerd.
timestamp	`timestamp`	Wanneer deze versie is doorgevoerd.
userId	`string`	De id van de gebruiker die de bewerking heeft uitgevoerd.
userName	`string`	De naam van de gebruiker die de bewerking heeft uitgevoerd.
operatie	`string`	De naam van de operatie.
operationParameters	`map`	De parameters van de bewerking (bijvoorbeeld predicaten.) Voor `OPTIMIZE` bewerkingen identificeren deze parameters het type bewerking. Zie Het type van de `OPTIMIZE`-bewerking bepalen.
taak	`struct`	De details van de Lakeflow-taak die de bewerking heeft uitgevoerd. Wordt alleen ingevuld voor commits die door een Lakeflow-taak zijn uitgevoerd. Anders `null`.
notebook	`struct`	De details van het Databricks-notebook van waaruit de bewerking is uitgevoerd. Wordt alleen ingevuld voor commits die zijn gemaakt in een Databricks-notebook. Anders `null`.
clusterId	`string`	De id van het cluster waarop de bewerking is uitgevoerd.
leesVersie	`long`	De versie van de tabel die is gelezen om de schrijfbewerking uit te voeren.
isolationLevel	`string`	Het isolatieniveau dat voor deze bewerking wordt gebruikt.
isBlindAppend	`boolean`	Of aan deze bewerking gegevens zijn toegevoegd.
operationMetrics	`map`	De metrische gegevens van de bewerking (bijvoorbeeld het aantal rijen en bestanden dat is gewijzigd.)
userMetadata	`string`	De door de gebruiker gedefinieerde commitmetagegevens, indien opgegeven.

+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+
|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...|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+

Opmerking

Als u met de volgende methoden naar een tabel schrijft, zijn sommige kolommen niet beschikbaar:
Kolommen die in de toekomst worden toegevoegd, worden altijd toegevoegd na de laatste kolom.

Inzicht `partitionBy` in bewerkingsparameters

Het partitionBy veld in de tabelgeschiedenis is alleen zinvol voor CREATE- en OVERWRITE-bewerkingen waarmee het partitieschema van een tabel wordt gedefinieerd of gewijzigd.

Voor toevoegbewerkingen aan bestaande tabellen (APPEND, INSERT, , UPDATEDELETE, MERGE), kan dit veld een lege matrix [] of partitiekolommen weergeven, afhankelijk van de gebruikte schrijfmethode (.save() vs .saveAsTable()).

Deze inconsistentie is verwacht gedrag en heeft geen invloed op de wijze waarop gegevens naar partities worden geschreven. U moet deze niet gebruiken om toevoegbewerkingen te valideren.

Voorbeeld

Overweeg een tabel die is gepartitioneerd door de date kolom. Wanneer u de tabel maakt, wordt partitionBy met het volgende ingevuld:

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

De bewerking CREATE in de geschiedenis toont:

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

Wanneer u gegevens aan deze tabel toevoegt, partitionBy wordt een lege matrix weergegeven:

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

De bewerking APPEND toont:

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

De lege partitionBy waarde wordt verwacht. De gegevens worden nog steeds naar de juiste partities geschreven op basis van het bestaande partitieschema van de tabel. Houd er rekening mee dat .save() naar een pad in dit veld mogelijk partitiekolommen weergeeft, maar dit verschil is een implementatiedetail en heeft geen invloed op het schrijfgedrag.

Operationele kengetallen

De history operatie geeft een verzameling operatiemetrieken terug in de operationMetrics kolomkaart.

In de volgende tabellen worden de kaartsleuteldefinities per operatie weergegeven.