Esquema histórico de tablas y métricas de operación

El DESCRIBE HISTORY comando devuelve 14 columnas para tablas Apache, Iceberg y Delta Lake que describen la historia de las operaciones de tablas. Utiliza esta referencia para interpretar cada columna.

Para orientación sobre cómo recuperar el historial de tablas, consultar versiones anteriores de las tablas y restaurar una tabla, véase Trabajar con historial de tablas.

Esquema del historial

La salida de la operación history tiene las columnas siguientes.

Columna	Tipo	Descripción
version	`long`	La versión de la tabla generada por la operación.
timestamp	`timestamp`	Cuándo se confirmó esta versión.
ID de usuario	`string`	Identificador del usuario que ejecutó la operación.
userName	`string`	Nombre del usuario que ejecutó la operación.
operation	`string`	Nombre de la operación.
parámetros de operación	`map`	Parámetros de la operación (por ejemplo, predicados). En el caso `OPTIMIZE` de las operaciones, estos parámetros identifican el tipo de operación. Consulte Identificación del tipo de `OPTIMIZE` operación.
trabajo	`struct`	Detalles del trabajo de Lakeflow que ejecutó la operación. Rellena solo las confirmaciones escritas desde un trabajo de Lakeflow. En caso contrario, es `null`.
notebook	`struct`	Detalles del cuaderno de Databricks desde el que se ejecutó la operación. Rellena solo las confirmaciones escritas desde un cuaderno de Databricks. En caso contrario, es `null`.
clusterId	`string`	Identificador del clúster en el que se ejecutó la operación.
versión de lectura	`long`	Versión de la tabla que se leyó para realizar la operación de escritura.
isolationLevel	`string`	Nivel de aislamiento usado para esta operación.
isBlindAppend	`boolean`	Indica si esta operación ha anexado datos.
operationMetrics	`map`	Métricas de la operación (por ejemplo, número de filas y archivos modificados).
userMetadata	`string`	Metadatos de confirmación definidos por el usuario si se especificó.

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

Nota:

Si escribe en una tabla con los métodos siguientes, algunas columnas no están disponibles:
Las columnas agregadas en el futuro siempre se agregarán después de la última columna.

Descripción `partitionBy` de los parámetros de operación

El partitionBy campo del historial de tablas solo es significativo para las operaciones CREATE y OVERWRITE que definen o cambian el esquema de partición de una tabla.

Para las operaciones de anexión a tablas existentes (APPEND, INSERT, , UPDATEDELETE, MERGE), este campo podría mostrar una matriz [] vacía o columnas de partición en función del método de escritura usado (.save() frente .saveAsTable()a ).

Esta incoherencia es el comportamiento esperado y no afecta a cómo se escriben los datos en las particiones. No debe usarlo para validar las operaciones de anexión.

Ejemplo

Considere una tabla particionada por la columna date. Al crear la tabla, partitionBy se rellena:

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

La operación CREATE en el historial muestra:

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

Al anexar datos a esta tabla, partitionBy se muestra una matriz vacía:

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

La operación APPEND muestra:

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

Se espera el valor vacío partitionBy. Los datos se siguen escribiendo en las particiones correctas según el esquema de partición existente de la tabla. Tenga en cuenta que .save() para una ruta podría mostrar columnas de partición en este campo, pero esta diferencia es un detalle de implementación y no afecta al comportamiento al escribir.

Métricas de operación

La history operación devuelve una colección de métricas de operación en el operationMetrics mapa de columnas.

En las tablas siguientes, se muestran las definiciones de clave del mapa según la operación.