Eliminación de archivos de datos sin usar con vacuum

Quite los archivos de datos a los que ya no hace referencia una tabla anterior al umbral de retención ejecutando el VACUUM comando en la tabla. La ejecución periódica de VACUUM es importante para el costo y el cumplimiento debido a las consideraciones siguientes:

  • La eliminación de archivos de datos no utilizados reduce los costos de almacenamiento en la nube.
  • Los archivos de datos eliminados por VACUUM pueden contener registros que se han modificado o eliminado. Al quitar permanentemente estos archivos del almacenamiento en la nube, se garantiza que estos registros dejen de ser accesibles.

En las tablas con lecturas de Iceberg (UniForm) habilitadas, VACUUM también limpia los archivos de metadatos de Iceberg inaccesibles. Consulte VACUUM y la limpieza de metadatos de Iceberg.

La optimización predictiva ejecuta automáticamente VACUUM en tablas administradas de Unity Catalog. Databricks recomienda habilitar las optimizaciones predictivas para todas las tablas administradas de Unity Catalog a fin de simplificar el mantenimiento de datos y reducir los costes de almacenamiento. Consulte Optimización predictiva para tablas administradas de Unity Catalog.

Precauciones para el vacío

El umbral de retención predeterminado para los archivos de datos tras ejecutar VACUUM es de 7 días. Para cambiar este comportamiento, consulte Configuración de la retención de datos para consultas de viaje en el tiempo.

VACUUM podría dejar directorios vacíos después de quitar todos los archivos en su interior. Las operaciones de VACUUM posteriores eliminan estos directorios vacíos.

Algunas características de tabla, como los vectores de eliminación, usan archivos de metadatos para marcar los datos como eliminados en lugar de volver a escribir archivos de datos. Use REORG TABLE ... APPLY (PURGE) para confirmar estas eliminaciones y reescribir archivos de datos. Consulte Purga de eliminaciones de solo metadatos para forzar la reescritura de datos.

Importante

  • En Databricks Runtime 13.3 LTS y versiones posteriores, la semántica de VACUUM para los clones superficiales con tablas administradas por Unity Catalog difiere de otras tablas. Consulte Usar VACUUM con clones superficiales de Unity Catalog.
  • VACUUM quita todos los archivos de directorios no administrados por Azure Databricks, ignorando los directorios que comienzan por _ o .. Si va a almacenar metadatos adicionales, como los puntos de control de Structured Streaming dentro de un directorio de tabla, use un nombre de directorio como _checkpoints.
  • La capacidad de hacer consultas a versiones de tabla anteriores al período de retención se pierde después de ejecutar VACUUM.
  • Los archivos de registro se eliminan de manera automática y asincrónica después de las operaciones de punto de comprobación y no los gobierna VACUUM. Aunque el período de retención predeterminado de los archivos de registro es de 30 días, al ejecutarse VACUUM en una tabla se eliminan los archivos de datos necesarios para el viaje en el tiempo.
  • Cuando el almacenamiento en caché de disco está habilitado, un clúster puede contener datos de archivos Parquet que se han eliminado con VACUUM. Por lo tanto, puede ser posible consultar los datos de versiones de la tabla anteriores cuyos archivos se han eliminado. Al reiniciar el clúster, se quitarán los datos almacenados en caché. Consulte Configuración de la caché de disco.

Sintaxis de ejemplo para vacuum

Para quitar los archivos que ya no requieren las versiones anteriores al período de retención predeterminado, ejecute VACUUM sin configuraciones adicionales:

VACUUM table_name

Para obtener una vista previa de la lista de archivos que se van a eliminar sin quitarlos, ejecute VACUUM con DRY RUN:

VACUUM table_name DRY RUN

Para obtener más información sobre la sintaxis de Spark SQL, consulte VACUUM.

Para obtener información sobre la sintaxis de Scala, Java y Python, consulte la documentación de La API de Delta Lake.

Nota:

En Databricks Runtime 18.0 y versiones posteriores, use la propiedad de tabla deletedFileRetentionDuration para controlar la retención. En el caso de las tablas administradas por El catálogo de Unity, esto se aplica a Databricks Runtime 13.3 LTS y versiones posteriores.

Vea Configuración de la retención de datos para las consultas de historial temporal.

Modo completo frente a modo ligero

Importante

Esta característica está en versión preliminar pública en Databricks Runtime 16.4 LTS y versiones posteriores.

Para mejorar el rendimiento y reducir los costes, y para evitar enumerar todos los archivos del directorio de la tabla, especifique la palabra clave LITE en la instrucción VACUUM para activar un modo alternativo de VACUUM. Esto es útil para tablas grandes que requieren operaciones frecuentes VACUUM .

LITE el modo usa el registro de transacciones para identificar los archivos de datos que ya no están dentro del VACUUM umbral de retención y quita estos archivos de datos de la tabla.

Nota:

La ejecución VACUUM en LITE modo no eliminará los archivos a los que no se hace referencia en el registro de transacciones. Por ejemplo, los archivos creados por una transacción anulada.

Utilice la sintaxis siguiente para VACUUM en modo LITE:

VACUUM table_name LITE

El modo FULL es el predeterminado para el vaciado. Puede ejecutar explícitamente el modo completo con el siguiente comando:

VACUUM table_name FULL

Consulte VACUUM.

Requirements

El modo LITE tiene el siguiente requisito:

  • Debe haber ejecutado al menos una operación correcta VACUUM dentro del umbral de retención del registro de transacciones configurado (30 días de forma predeterminada).

Si no se cumple este requisito, al intentar ejecutarse VACUUM en LITE modo, se muestra el siguiente mensaje de error. Para continuar, debe ejecutar VACUUM en modo FULL.

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the log. Please run VACUUM FULL.

Purga de eliminaciones basadas solo en metadatos para forzar la reescritura de datos

El comando REORG TABLE con la sintaxis APPLY (PURGE) permite reescribir datos para aplicar eliminaciones suaves. Las eliminaciones suaves no vuelven a escribir datos ni eliminan archivos de datos, sino que usan archivos de metadatos para indicar que algunos valores de datos han cambiado. Consulte REORG TABLE.

Las operaciones que crean eliminaciones suaves incluyen lo siguiente:

  • La características de quitar columnas con la asignación de columnas está habilitada.
  • Cualquier modificación de datos con vectores de eliminación habilitados.

Con las eliminaciones temporales habilitadas, los datos antiguos pueden permanecer físicamente presentes en los archivos actuales de la tabla incluso después de que los datos se hayan eliminado o actualizado. Para quitar físicamente estos datos de la tabla, complete estos pasos:

  1. Ejecute REORG TABLE ... APPLY (PURGE). Después de hacerlo, los datos antiguos ya no están presentes en los archivos actuales de la tabla, pero todavía están presentes en los archivos más antiguos que se usan para el viaje en el tiempo.
  2. Ejecute VACUUM para eliminar estos archivos antiguos.

REORG TABLE crea una nueva versión de la tabla a medida que se complete la operación. Todas las versiones de tabla del historial antes de esta transacción hacen referencia a archivos de datos anteriores. De manera conceptual, esto es similar al comando OPTIMIZE, con el que los archivos de datos se reescriben aunque los datos de la versión de tabla actual sean coherentes.

Importante

Los archivos de datos solo se eliminan cuando los archivos han expirado según el período de retención de VACUUM. Esto significa que VACUUM debe realizarse con cierto retraso después de REORG para garantizar que los archivos anteriores hayan expirado. El período de retención de VACUUM puede reducirse para acortar el tiempo de espera requerido, a costa de reducir el historial máximo que se conserva.

Recomendaciones de tamaño de clúster para el vaciado

Para seleccionar el tamaño de clúster correcto para VACUUM, tenga en cuenta que la operación se produce en dos fases:

  1. El trabajo comienza al usar todos los nodos ejecutores disponibles para enumerar los archivos del directorio de origen en paralelo. El trabajo compara esta lista con todos los archivos a los que se hace referencia actualmente en el registro de transacciones para identificar los archivos para su eliminación. El controlador permanece inactivo durante este tiempo.
  2. El controlador emite comandos de eliminación para cada archivo identificado para su eliminación. Dado que la eliminación de archivos es una operación de solo controlador, todas las operaciones se producen en un solo nodo mientras los nodos de trabajo están inactivos.

Para optimizar el costo y el rendimiento, Databricks recomienda lo siguiente, especialmente para trabajos de vacío de larga duración:

  • Ejecute el vacío en un clúster con el escalado automático establecido para 1-4 trabajos, donde cada trabajador tiene 8 núcleos.
  • Seleccione un controlador con entre 8 y 32 núcleos. Aumente el tamaño del controlador para evitar errores de memoria insuficiente (OOM).

Si las operaciones de VACUUM eliminan regularmente más de 10 mil archivos o tardan más de 30 minutos en procesarse, es posible que deba aumentar el tamaño del controlador o el número de trabajadores.

Si observa que la ralentización se produce al identificar los archivos que se van a quitar, agregue más nodos de trabajo. Si la ralentización se produce mientras se ejecutan comandos de eliminación, intente aumentar el tamaño del controlador.

Databricks recomienda ejecutar VACUUM periódicamente en todas las tablas para reducir los costos de almacenamiento de datos en la nube excesivos. El umbral de retención predeterminado para los archivos es de 7 días. Si se establece un umbral superior, se obtiene acceso a un historial mayor para la tabla, pero aumenta el número de archivos de datos almacenados y, como resultado, aumenta los costos de almacenamiento del proveedor de nube.

Umbrales de vaciado y de retención baja

Advertencia

Databricks recomienda encarecidamente establecer un intervalo de retención de al menos 7 días. Si tiene trabajos que se ejecutan durante varios días, es posible que estos trabajos de ejecución prolongada escriban archivos que todavía no se han confirmado. Si el período de retención es demasiado corto, VACUUM podría eliminar estos archivos no confirmados antes de que se complete el trabajo.

Hay una comprobación de seguridad para evitar que ejecute un comando peligroso VACUUM . Si está seguro de que no hay ninguna operación que se ejecute en esta tabla que tarde más tiempo que el intervalo de retención que planea especificar, desactive esta comprobación de seguridad estableciendo la retentionDurationCheck configuración falsede Spark en :

Delta

SET spark.databricks.delta.retentionDurationCheck.enabled = false

Iceberg

SET spark.databricks.iceberg.retentionDurationCheck.enabled = false

Información de auditoría

VACUUM confirma la información de auditoría en el registro de transacciones. Consulte los eventos de auditoría mediante DESCRIBE HISTORY.

De forma predeterminada, el registro de auditoría está habilitado en todas las plataformas para las tablas administradas del catálogo de Unity. Controle el registro de auditoría del vaciado con la configuración de Spark vacuum.logging:

Delta

SET spark.databricks.delta.vacuum.logging.enabled = true

Iceberg

SET spark.databricks.iceberg.vacuum.logging.enabled = true

Para aplicar esta configuración para un área de trabajo completa, en todos los clústeres, use una directiva de clúster y agregue lo siguiente a la directiva JSON:

Delta

{
  "spark_conf.spark.databricks.delta.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Iceberg

{
  "spark_conf.spark.databricks.iceberg.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

Vea Crear y administrar políticas de cómputo.

Nota:

El registro de auditoría también está habilitado de forma predeterminada para tablas externas.

  • Last updated on