Historique de table, schéma et métriques d’opération

La DESCRIBE HISTORY commande retourne 14 colonnes pour les tables Apache Iceberg et Delta Lake qui décrivent l’histoire des opérations de table. Utilisez cette référence pour interpréter chaque colonne.

Pour des conseils sur la récupération de l’historique des tables, la requête des versions antérieures des tables et la restauration d’une table, voir Travail avec l’historique des tables.

Schéma de l’historique

La sortie de l'opération history contient les colonnes suivantes.

Colonne	Type	Description
version	`long`	Version de table générée par l’opération.
timestamp	`timestamp`	Moment de validation de cette version.
userId	`string`	ID de l’utilisateur qui a exécuté l’opération.
userName	`string`	Nom de l’utilisateur qui a exécuté l’opération.
fonctionnement	`string`	Nom de l’opération.
paramètres d'opération	`map`	Paramètres de l’opération (par exemple, prédicats.) Pour `OPTIMIZE` les opérations, ces paramètres identifient le type d’opération. Consultez Identifier le type d’opération`OPTIMIZE`.
tâche	`struct`	Détails du travail Lakeflow qui a exécuté l’opération. Remplit uniquement les validations écrites à partir d’un travail Lakeflow. Sinon, `null`.
notebook	`struct`	Détails du notebook Databricks depuis lequel l’opération a été exécutée. Remplit uniquement les validations écrites à partir d’un notebook Databricks. Sinon, `null`.
clusterId	`string`	ID du cluster sur lequel l’opération s’est exécutée.
lireVersion	`long`	Version de la table qui a été lue pour effectuer l’opération d’écriture.
isolationLevel	`string`	Niveau d’isolation utilisé pour cette opération.
isBlindAppend	`boolean`	Indique si cette opération a ajouté des données.
operationMetrics	`map`	Métriques de l’opération (par exemple, nombre de lignes et de fichiers modifiés.)
UserMetadata	`string`	Les métadonnées de commit définies par l’utilisateur, si elles ont été spécifiées.

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

Si vous écrivez dans une table à l’aide des méthodes suivantes, certaines colonnes ne sont pas disponibles :
Les colonnes ajoutées à l’avenir seront toujours ajoutées après la dernière colonne.

Présentation des `partitionBy` paramètres d’opération

Le partitionBy champ de l’historique des tables n’est significatif que pour les opérations CREATE et OVERWRITE qui définissent ou modifient le schéma de partition d’une table.

Pour les opérations d’ajout à des tables existantes (APPEND, INSERT, DELETE UPDATE, MERGE), ce champ peut afficher un tableau [] ou des colonnes de partition vides en fonction de la méthode d’écriture utilisée (.save() vs .saveAsTable()).

Cette incohérence est attendue et n’affecte pas la façon dont les données sont écrites dans des partitions. Vous ne devez pas l’utiliser pour valider les opérations d’ajout.

Exemple

Considérez une table partitionnée par la date colonne. Lorsque vous créez la table, partitionBy est renseignée :

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

L’opération CREATE dans l’historique montre :

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

Lorsque vous ajoutez des données à cette table, partitionBy affiche un tableau vide :

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

L’opération APPEND montre :

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

La valeur vide partitionBy est attendue. Les données sont toujours écrites dans les partitions correctes en fonction du schéma de partition existant de la table. Notez que la référence .save() à un chemin d’accès peut afficher des colonnes de partition dans ce champ, mais cette différence est un détail d’implémentation et n’affecte pas le comportement d’écriture.

Métriques d’opération

L’opération history retourne une collection de métriques d’opération dans la operationMetrics carte de colonnes.

Les tableaux suivants répertorient les définitions de clé de mappage par opération.