Schéma de l'historique de la table et métriques des opérations

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

Pour obtenir des conseils sur la récupération de l'historique de table, l'interrogation des versions précédentes de table et la restauration d'une table, consultez Travailler avec l'historique de table.

Schéma d'historique

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

Colonne	Type	Description
Version	`long`	La version de table générée par l'opération.
Horodatage	`timestamp`	Date de validation de cette version.
ID utilisateur	`string`	L'ID de l'utilisateur ayant effectué l'opération.
Nom d'utilisateur	`string`	Le nom de l'utilisateur ayant exécuté l'opération.
Opérations	`string`	Le nom de l’opération.
Paramètres d'opération	`map`	Les paramètres de l'opération (par exemple, les prédicats). Pour les opérations `OPTIMIZE`, ces paramètres identifient le type d'opération. Voir Identifier le type d'opération `OPTIMIZE`.
Job	`struct`	Les détails du Lakeflow job qui a exécuté l’opération. Se remplit uniquement pour les commits écrits à partir d’un Lakeflow job. Sinon, `null`.
Notebook	`struct`	Les détails du notebook Databricks à partir duquel l'opération a été exécutée. Se remplit uniquement pour les commits écrits à partir d'un notebook Databricks. Sinon, `null`.
clusterId	`string`	L'identifiant du cluster sur lequel l'opération a été exécutée.
readVersion	`long`	La version de la table qui a été lue pour effectuer l'opération d'écriture.
isolationLevel	`string`	Le niveau d'isolation utilisé pour cette opération.
isBlindAppend	`boolean`	Indique si cette opération a ajouté des données.
operationMetrics	`map`	Les métriques de l'opération (par exemple, le 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.

Colonne	Type	Description
Version	`long`	La version de table générée par l'opération.
Horodatage	`timestamp`	Date de validation de cette version.
ID utilisateur	`string`	L'ID de l'utilisateur ayant effectué l'opération.
Nom d'utilisateur	`string`	Le nom de l'utilisateur ayant exécuté l'opération.
Opérations	`string`	Le nom de l’opération.
Paramètres d'opération	`map`	Les paramètres de l'opération (par exemple, les prédicats). Pour les opérations `OPTIMIZE`, ces paramètres identifient le type d'opération. Voir Identifier le type d'opération `OPTIMIZE`.
Job	`struct`	Les détails du Lakeflow job qui a exécuté l’opération. Se remplit uniquement pour les commits écrits à partir d’un Lakeflow job. Sinon, `null`.
Notebook	`struct`	Les détails du notebook Databricks à partir duquel l'opération a été exécutée. Se remplit uniquement pour les commits écrits à partir d'un notebook Databricks. Sinon, `null`.
clusterId	`string`	L'identifiant du cluster sur lequel l'opération a été exécutée.
readVersion	`long`	La version de la table qui a été lue pour effectuer l'opération d'écriture.
isolationLevel	`string`	Le niveau d'isolation utilisé pour cette opération.
isBlindAppend	`boolean`	Indique si cette opération a ajouté des données.
operationMetrics	`map`	Les métriques de l'opération (par exemple, le 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.

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

remarque

Si vous écrivez dans une table en utilisant les méthodes suivantes, certaines colonnes ne sont pas disponibles :
Les colonnes ajoutées ultérieurement seront toujours ajoutées après la dernière colonne.

Comprendre `partitionBy` dans les paramètres d'opération

Le champ partitionBy dans l'historique de la table 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 sur des tables existantes (APPEND, INSERT, UPDATE, DELETE, MERGE), ce champ peut afficher un tableau vide [] ou des colonnes de partition selon la méthode d'écriture utilisée (.save() ou .saveAsTable()).

Cette incohérence est un comportement attendu et n'affecte pas la manière dont les données sont écrites dans les partitions. Vous ne devriez pas l'utiliser pour valider les opérations d'ajout (append).

Exemple

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

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

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

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

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

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

L'opération APPEND affiche :

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

La valeur partitionBy vide 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 .save() vers un chemin 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 des opérations

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

Les tableaux suivants listent les définitions des clés de mappage par opération.