Compactación de ficheros

¿Qué es?

La compactación es el proceso de reescribir muchos ficheros pequeños como unos pocos ficheros grandes, sin cambiar el contenido lógico de la tabla. Es una tarea de mantenimiento, invisible para quien consulta, y una de las que más diferencia marca en el rendimiento de un data lakehouse.

El problema que resuelve tiene nombre propio: el small files problem.

Por qué aparecen los ficheros pequeños

Una tabla sobre almacenamiento de objetos no se actualiza en sitio: cada escritura añade ficheros nuevos. Cuantas más escrituras y más frecuentes, más ficheros y más pequeños.

Las fuentes habituales:

• Ingesta frecuente: un flujo que escribe cada minuto genera 1.440 ficheros al día por partición, aunque solo lleguen unas decenas de filas en cada tanda.
• Replicación continua: un pipeline de CDC que aterriza cambios según ocurren produce exactamente ese patrón, y es el caso que más veces acaba en una tabla inconsultable.
• Particionado demasiado fino: partir por hora, o por una columna con muchos valores distintos, multiplica los directorios y reparte los mismos datos en trozos minúsculos.
• Actualizaciones y borrados: cada modificación deja ficheros de cambio que se acumulan hasta que alguien los consolida.

Por qué es un problema

El coste de leer un fichero no es proporcional a su tamaño: hay una parte fija por cada uno. Abrirlo, pedir sus metadatos, planificar su lectura. Con ficheros de unos pocos kilobytes, ese coste fijo domina y el motor pasa más tiempo gestionando ficheros que leyendo datos.

Los efectos concretos:

• Consultas lentas que empeoran con el tiempo aunque el volumen de datos no crezca.
• Planificación cara: el motor tiene que listar y evaluar los metadatos de miles de ficheros antes de leer ninguno.
• Coste de almacenamiento por peticiones: en almacenamiento de objetos se paga por operación, no solo por gigabyte.
• Peor compresión y peor filtrado: los formatos columnares como Parquet comprimen y descartan bloques por estadísticas; con ficheros diminutos, ambas ventajas casi desaparecen.

La señal típica es una tabla que va bien el primer mes y es inutilizable al sexto, sin que nadie haya cambiado nada.

Cómo se resuelve

Los formatos de tabla del lakehouse —Delta Lake, Apache Iceberg y Apache Hudi— incorporan la compactación como operación de mantenimiento. Reescriben los ficheros pequeños de una partición en ficheros del tamaño objetivo y actualizan el log de metadatos para que la tabla pase a apuntar a los nuevos.

Como el cambio se registra como una versión más de la tabla, las consultas en curso no se rompen y la operación es transparente.

Dos cosas conviene tener claras:

• Consume recursos. Compactar es leer y reescribir datos. Se programa en la ventana donde menos molesta, con una frecuencia proporcional al ritmo de ingesta.
• Los ficheros antiguos siguen ahí un tiempo, porque son los que sostienen la consulta de versiones pasadas. Liberar ese espacio es una tarea aparte, y recortarla demasiado reduce la ventana de recuperación disponible.

Ejemplo

Una tabla de movimientos de stock recibe cambios desde el ERP según ocurren. Cada tanda escribe un fichero de pocos kilobytes; al cabo de unos meses la partición del mes en curso acumula decenas de miles.

Una consulta que agrega el stock del mes tarda minutos, y el perfil de ejecución muestra que la mayor parte del tiempo se va en planificar, no en leer. Una compactación diaria que consolide los ficheros de la víspera en bloques de unos cientos de megabytes deja la misma consulta en segundos, sin tocar ni el modelo ni el pipeline.

Más información

• Almacenamiento de datos: data lakes, data warehouses y lakehouses — capítulo de la guía práctica de arquitectura de datos de Dataprix.
• Compara plataformas de datos en el directorio de software de Dataprix.