Histórico de tabela esquema e métricas de operação

O DESCRIBE HISTORY comando retorna 14 colunas para as tabelas Apache Iceberg e Delta Lake que descrevem a história das operações de tabelas. Use essa referência para interpretar cada coluna.

Para orientações sobre como recuperar o histórico de tabelas, consultar versões anteriores de tabelas e restaurar uma tabela, veja Trabalhar com histórico de tabela.

Esquema de história

A saída da operação history tem as colunas a seguir.

Coluna	Tipo	Descrição
versão	`long`	A versão da tabela gerada pela operação.
carimbo de data/hora	`timestamp`	Quando esta versão foi comprometida.
userId	`string`	A ID do usuário que executou a operação.
nome do usuário	`string`	O nome do usuário que executou a operação.
operação	`string`	O nome da operação.
parâmetros de operação	`map`	Os parâmetros da operação (por exemplo, predicados.) Para `OPTIMIZE` operações, esses parâmetros identificam o tipo de operação. Consulte Identificar o tipo de `OPTIMIZE` operação.
cargo	`struct`	Os detalhes da tarefa Lakeflow que executou a operação. É preenchido somente para commits gerados por um job do Lakeflow. Caso contrário, `null`.
notebook	`struct`	Os detalhes do notebook do Databricks a partir do qual a operação foi executada. É preenchido somente para commits feitos a partir de um notebook do Databricks. Caso contrário, `null`.
clusterId	`string`	A ID do cluster no qual a operação foi executada.
lerVersão	`long`	A versão da tabela que foi lida para executar a operação de gravação.
isolationLevel	`string`	O nível de isolamento usado para esta operação.
isBlindAppend	`boolean`	Se essa operação acrescenta dados.
operationMetrics	`map`	As métricas da operação (por exemplo, número de linhas e arquivos modificados).)
userMetadata	`string`	Os metadados de confirmação definidos pelo usuário se forem especificados.

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

Observação

Se você escrever em uma tabela usando os seguintes métodos, algumas colunas não estão disponíveis:
Colunas incluídas mais tarde sempre são adicionadas após a última coluna.

Noções básicas `partitionBy` sobre parâmetros de operação

O partitionBy campo no histórico de tabelas só é significativo para operações CREATE e OVERWRITE que definem ou alteram o esquema de partição de uma tabela.

Para operações de acréscimo a tabelas existentes (APPEND, INSERT, UPDATE, DELETE, MERGE), esse campo pode mostrar uma matriz [] vazia ou colunas de partição dependendo do método de gravação usado (.save() vs .saveAsTable()).

Essa inconsistência é o comportamento esperado e não afeta a forma como os dados são gravados em partições. Você não deve usá-lo para validar operações de acréscimo.

Exemplo

Considere uma tabela particionada pela date coluna. Quando você cria a tabela, partitionBy é populada:

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

A operação CREATE no histórico mostra:

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

Quando você acrescenta dados a esta tabela, partitionBy mostra uma matriz vazia:

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

A operação APPEND mostra:

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

O valor vazio partitionBy é esperado. Os dados ainda são gravados nas partições corretas com base no esquema de partição existente da tabela. Observe que .save() para um caminho pode mostrar colunas de partição nesse campo, mas essa diferença é um detalhe de implementação e não afeta o comportamento de gravação.

Métricas de operação

A history operação retorna uma coleção de métricas de operação no operationMetrics mapa de colunas.

As tabelas a seguir listam as definições essenciais do mapa por operação.