Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El tamaño de la tabla notificado para las tablas respaldadas por Delta Lake en Azure Databricks difiere del tamaño total de los directorios de archivos correspondientes en el almacenamiento de objetos en la nube. En este artículo se explica por qué existe esta diferencia y se proporcionan recomendaciones para controlar los costos.
¿Por qué mi tamaño de tabla Delta no coincide con el tamaño del directorio?
Los tamaños de la tabla notificados en Azure Databricks a través de interfaces de usuario y comandos DESCRIBE hacen referencia al tamaño total de los archivos de datos del disco para esos archivos a los que se hace referencia en la versión actual de la tabla Delta. La mayoría de las operaciones que escriben en tablas requieren volver a escribir archivos de datos subyacentes, pero los archivos de datos antiguos se conservan durante un período de tiempo para admitir consultas de viaje en el tiempo.
Nota:
Si elimina o actualiza registros en tablas con regularidad, los vectores de eliminación pueden acelerar las consultas y reducir el tamaño total de los archivos de datos. Consulte ¿Qué son los vectores de eliminación?.
Calcular métricas de almacenamiento para una tabla
Se aplica a:
Databricks Runtime 18.0 y versiones posteriores
Para comprender por qué el tamaño total de almacenamiento difiere del tamaño de tabla, use ANALYZE TABLE … COMPUTE STORAGE METRICS. Este comando proporciona un desglose detallado de la asignación de almacenamiento, lo que le ayuda a:
-
Identificación de las oportunidades de optimización de costos: consulte la cantidad de almacenamiento que se puede reclamar con
VACUUM - Análisis de la sobrecarga del viaje en el tiempo: comprenda el costo de conservar los datos históricos.
- Seguimiento de patrones de almacenamiento: supervise la evolución del almacenamiento de tablas con el tiempo mediante la ejecución periódica del comando.
- Auditar el almacenamiento entre tablas: ejecute el comando en un bucle para analizar todo el patrimonio de datos.
El comando devuelve métricas completas, entre las que se incluyen:
- Tamaño total de almacenamiento: superficie completa, incluidos todos los datos, metadatos y registros
- Datos activos: tamaño de la versión actual de la tabla
- Datos recuperables: espacio que se puede liberar
- Datos de viaje en el tiempo: datos históricos para reversiones
Esto es especialmente útil para las tablas administradas de Unity Catalog en las que Azure Databricks administra automáticamente el almacenamiento a través de la optimización predictiva.
Consulte COMPUTE STORAGE METRICS para obtener ejemplos y sintaxis completos.
Uso de la optimización predictiva para controlar el tamaño de los datos
Databricks recomienda el uso de Unity Catalog para tablas administradas con la optimización predictiva habilitada. Con las tablas administradas y la optimización predictiva, Databricks ejecuta automáticamente los comandos OPTIMIZE y VACUUM para evitar la acumulación de archivos de datos no utilizados. Espere que siempre haya una diferencia de tamaño entre la versión actual de una tabla y el tamaño total de los archivos de datos en el almacenamiento de objetos en la nube. Esto se debe a que los archivos de datos a los que no se hace referencia en la versión actual son necesarios para admitir consultas de viaje en el tiempo. Consulte Optimización predictiva para tablas administradas de Unity Catalog.
¿Qué métricas de archivo notifica VACUUM?
Al limpiar los archivos de datos no utilizados con VACUUM o usar DRY RUN para obtener una vista previa de los archivos establecidos para su eliminación, las métricas informan del número de archivos y el tamaño de los datos eliminados. El tamaño y el número de archivos eliminados por VACUUM varía drásticamente, pero no es raro que el tamaño de los archivos eliminados supere el tamaño total de la versión actual de la tabla.
¿Qué métricas de archivo notifica OPTIMIZE?
Cuando OPTIMIZE se ejecuta en una tabla de destino, los nuevos archivos de datos combinan registros de los archivos de datos existentes. Los cambios confirmados durante OPTIMIZE solo afectan a la organización de datos y no se producen cambios en el contenido de los datos subyacentes. El tamaño total de los archivos de datos asociados a la tabla aumenta después de ejecutarse OPTIMIZE, ya que los nuevos archivos compactos coexisten en el directorio contenedor con los archivos de datos a los que ya no se hace referencia.
El tamaño de la tabla que se ha notificado después de OPTIMIZE suele ser menor que el tamaño antes de la ejecución de OPTIMIZE, ya que el tamaño total de los archivos de datos a los que hace referencia la versión de la tabla actual disminuye con la compresión.
VACUUM debe ejecutarse una vez que se supere el umbral de retención para quitar los archivos de datos subyacentes.
Nota:
Es posible que vea métricas similares para operaciones como REORG TABLE o DROP FEATURE. Todas las operaciones que requieren volver a escribir archivos de datos aumentan el tamaño total de los datos del directorio contenedor hasta que VACUUM quita los archivos de datos a los que ya no se hace referencia en la versión de la tabla actual.