Compartir a través de

Eliminación de archivos de datos sin usar con vacuum

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.

Para quitar archivos de datos a los que una tabla de Delta ya no hace referencia y que son anteriores al umbral de retención, puede ejecutar el comando VACUUM 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.

Advertencias sobre la eliminación

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 dejarse directorios vacíos después de quitar todos los archivos de ellos. Las operaciones de VACUUM posteriores eliminan estos directorios vacíos.

Databricks recomienda usar la optimización predictiva para ejecutar VACUUM automáticamente para las tablas Delta. Consulte Optimización predictiva para tablas administradas de Unity Catalog.

Algunas características de Delta Lake usan archivos de metadatos para marcar los datos como eliminados en lugar de volver a escribir archivos de datos. Puede usar REORG TABLE ... APPLY (PURGE) para confirmar estas eliminaciones y volver a escribir 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 clones poco profundos con tablas administradas de Unity Catalog difieren de otras tablas delta. Clones superficiales de Vacuum y Unity Catalog.
  • VACUUM quita todos los archivos de directorios no administrados por Delta Lake, 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 Delta, 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.

Nota:

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

VACUUM table_name   -- vacuum files not required by versions older than the default retention period

VACUUM table_name DRY RUN    -- do dry run to get the list of files to be deleted

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 12.2 y versiones posteriores.

Vea Configuración de la retención de datos para las consultas de viaje en el tiempo.

Modo completo frente a modo ligero

Importante

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

Puede especificar la palabra clave LITE en la instrucción de vacuum para desencadenar un modo alternativo de VACUUM que evite enumerar todos los archivos del directorio de tabla.

LITE el modo usa el registro de transacciones Delta 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. LITE el modo es especialmente útil para tablas grandes que requieren operaciones frecuentes VACUUM , ya que evita tener que enumerar todos los archivos para identificar esos archivos de datos que se van a quitar.

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.

Use la sintaxis siguiente para VACUUM en LITE modo:

VACUUM table_name LITE

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 Delta log. Please run VACUUM FULL.

FULL mode es el valor predeterminado para el vacío. Puede ejecutar explícitamente el modo completo con el siguiente comando:

VACUUM table_name FULL

Consulte VACUUM.

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

El comando REORG TABLE proporciona la sintaxis APPLY (PURGE) para volver a escribir datos para aplicar eliminaciones temporales. Las eliminaciones temporales 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 temporales en Delta Lake 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 un retraso después de REORG para que los archivos anteriores puedan haber 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.

¿Qué tamaño necesita el clúster de vacuum?

Para seleccionar el tamaño de clúster correcto para VACUUM, es bueno comprender 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. Esta lista se compara con todos los archivos a los que se hace referencia actualmente en el registro de transacciones Delta para identificar los archivos que se van a eliminar. El controlador se sienta inactivo durante este tiempo.
  2. A continuación, el controlador emite comandos de eliminación para cada archivo que se va a eliminar. La eliminación de archivos es una operación de solo controlador, lo que significa que 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 periódicamente 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 trabajos.

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.

¿Con qué frecuencia debe ejecutar vacuum?

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. Establecer un umbral superior le proporciona acceso a un historial mayor para la tabla, pero aumenta el número de archivos de datos almacenados y, como resultado, incurre en mayores costos de almacenamiento del proveedor de nube.

¿Por qué no se puede aspirar una tabla Delta con un umbral de retención bajo?

Advertencia

Se recomienda establecer un intervalo de retención de al menos siete días, ya que es posible que todavía se usen instantáneas antiguas y archivos sin confirmar en operaciones de lectura o escritura simultáneas en la tabla. Si VACUUM limpia los archivos activos, las operaciones de lectura simultáneas pueden producir un error o, lo que es peor, las tablas pueden resultar dañadas cuando VACUUM elimina archivos que todavía no se han confirmado. Debe elegir un intervalo que sea más largo que la transacción simultánea de ejecución más prolongada y el período de mayor retraso de una secuencia con respecto a la actualización más reciente de la tabla.

Delta Lake tiene una comprobación de seguridad para evitar que ejecute un comando VACUUM peligroso. Si está seguro de que en esta tabla no se realiza ninguna operación que tarde más tiempo que el intervalo de retención que planea especificar, puede desactivar esta comprobación de seguridad estableciendo la propiedad de configuración de Spark spark.databricks.delta.retentionDurationCheck.enabled en false.

Información de auditoría

Las confirmaciones de VACUUM en el registro de transacciones de Delta contienen información de auditoría. Puede consultar los eventos de auditoría mediante DESCRIBE HISTORY.

  • Last updated on