Un data lake puede crecer rápido y, al mismo tiempo, rendir peor. Una causa típica es la proliferación de archivos muy pequeños: cada lectura paga overhead de metadatos, apertura y planificación, aunque el volumen total no sea alto.
La documentación de Apache Iceberg sobre mantenimiento y reescritura de archivos de datos describe justamente este patrón y propone compactación controlada para mejorar el rendimiento de lectura.
Cómo reconocer el problema
- Muchas tareas de consulta dedican más tiempo a planificar que a procesar datos.
- Incremento de latencia pese a volumen estable por partición.
- Jobs de streaming/microbatch que generan miles de objetos diminutos.
- Coste de metastore o catálogo desproporcionado frente al dato útil.
Sin diagnóstico, la reacción típica es escalar cómputo; eso alivia temporalmente, pero no corrige la raíz.
Qué compactar y cuándo
| Pregunta | Riesgo si se ignora | Decisión recomendada |
|---|---|---|
| ¿Qué tablas concentran más archivos pequeños? | Compactación indiscriminada y costosa | Priorizar por impacto en consultas críticas |
| ¿Qué ventanas están “frías”? | Reescrituras continuas sobre datos activos | Compactar periodos cerrados primero |
| ¿Cómo afecta al SLA de ingestión? | Bloqueos o retrasos de carga | Ejecutar en franjas de baja demanda |
| ¿Existe rollback o snapshot? | Riesgo de inconsistencia tras fallo | Validar versión antes y después de compactar |
La compactación es operación de mantenimiento, no parche aislado.
Caso sintético: pipeline transaccional
Caso ficticio: una tabla de eventos diarios recibe microarchivos cada cinco minutos. Las consultas de cierre mensual empiezan a degradarse. Se define una política: compactar particiones cerradas al día siguiente, mantener la ventana intradía sin compactar y revisar tamaño objetivo semanalmente.
El criterio de éxito no es una cifra inventada, sino evidencia comparativa: menos archivos por partición, menor tiempo de planificación y estabilidad de resultados.
Integrar compactación en el ciclo operativo
Relaciona esta práctica con particionado por fecha y exportaciones de grandes datos. Particionar bien sin estrategia de archivos puede dejar cuellos de botella igualmente.
También conviene separar compactación de transformaciones funcionales: una corrige forma física de almacenamiento, la otra corrige semántica del dato.
Si tu lake ya muestra síntomas de small files, en Nexeus Big Data podemos plantear un diagnóstico técnico y un plan de compactación progresiva sin interrumpir cargas esenciales.