Storia, schema della tabella e metriche operative

Il DESCRIBE HISTORY comando restituisce 14 colonne per le tabelle Apache Iceberg e Delta Lake che descrivono la storia delle operazioni delle tabelle. Usa questo riferimento per interpretare ogni colonna.

Per indicazioni su come recuperare la cronologia delle tabelle, interrogare versioni precedenti e ripristinare una tabella, vedi Lavoro con la cronologia delle tabelle.

Schema cronologia

L'output dell'operazione history include le colonne seguenti.

colonna	Tipo	Description
version	`long`	Versione della tabella generata dall'operazione.
Marca temporale	`timestamp`	Quando è stato effettuato il commit di questa versione.
userId	`string`	ID dell'utente che ha eseguito l'operazione.
userName	`string`	Nome dell'utente che ha eseguito l'operazione.
operation	`string`	Nome dell'operazione.
parametri di operazione	`map`	Parametri dell'operazione, ad esempio predicati. Per `OPTIMIZE` le operazioni, questi parametri identificano il tipo di operazione. Vedi Identificare il tipo di `OPTIMIZE` operazione.
attività	`struct`	I dettagli del job Lakeflow che ha eseguito l'operazione. Si popola solo per i commit creati da un job Lakeflow. In caso contrario, `null`.
notebook	`struct`	Dettagli del notebook di Databricks da cui è stata eseguita l'operazione. Viene popolato solo per i commit creati da un notebook Databricks. In caso contrario, `null`.
clusterId	`string`	ID del cluster in cui è stata eseguita l'operazione.
leggiVersione	`long`	Versione della tabella letta per eseguire l'operazione di scrittura.
isolationLevel	`string`	Livello di isolamento utilizzato per questa operazione.
isBlindAppend	`boolean`	Indica se questa operazione ha accodato dati.
operationMetrics	`map`	Metriche dell'operazione(ad esempio, numero di righe e file modificati).
metadati dell'utente	`string`	Metadati di commit definiti dall'utente, se specificati.

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

Annotazioni

Se si scrive in una tabella usando i metodi seguenti, alcune colonne non sono disponibili:
Le colonne aggiunte in futuro verranno sempre aggiunte dopo l'ultima colonna.

Informazioni sui `partitionBy` parametri dell'operazione

Il partitionBy campo nella cronologia tabelle è significativo solo per le operazioni CREATE e OVERWRITE che definiscono o modificano lo schema di partizione di una tabella.

Per le operazioni di accodamento alle tabelle esistenti (APPEND, INSERT, , UPDATEDELETE, MERGE), questo campo potrebbe mostrare una matrice [] vuota o colonne di partizione a seconda del metodo di scrittura usato (.save() vs .saveAsTable()).

Questa incoerenza è un comportamento previsto e non influisce sul modo in cui i dati vengono scritti nelle partizioni. Non è consigliabile usarlo per convalidare le operazioni di accodamento.

Esempio

Si consideri una tabella partizionata dalla date colonna . Quando si crea la tabella, partitionBy viene popolata:

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

L'operazione CREATE nella cronologia mostra:

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

Quando si aggiungono dati a questa tabella, partitionBy viene visualizzata una matrice vuota:

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

L'operazione APPEND mostra:

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

È previsto il valore vuoto partitionBy . I dati vengono comunque scritti nelle partizioni corrette in base allo schema di partizione esistente della tabella. Si noti che .save() a un percorso potrebbe mostrare colonne di partizione in questo campo, ma questa differenza è un dettaglio di implementazione e non influisce sul comportamento di scrittura.

Metriche operative

L'operazione history restituisce una raccolta di metriche operative nella operationMetrics mappa a colonne.

Le tabelle seguenti elencano le definizioni delle chiavi della mappa in base all'operazione.