Formatos columnares y particionado de datos
Hay dos maneras de guardar una tabla: por filas (todas las columnas de un registro juntas) o por columnas (todos los valores de una columna juntos). Las bases transaccionales guardan por fila; el análisis guarda por columna, porque suele leer unas pocas columnas de millones de filas.
Almacenamiento por fila y por columna
Una lectura que necesita una o dos columnas de toda la tabla, en formato columnar ignora el resto del disco. Además, los valores parecidos quedan contiguos, así que comprimen muchísimo mejor que mezclar columnas distintas.
- Por fila: ideal para leer/escribir un registro completo (OLTP).
- Por columna: ideal para agregados sobre muchas filas y pocas columnas.
- Columnar reduce la E/S y habilita compresión agresiva por tipo.
Tres podas que ahorran lectura
- Poda de partición: una consulta filtrada por fecha solo lee las carpetas de esa fecha.
- Poda de columnas: se leen únicamente las columnas que el SELECT necesita.
- Pushdown de predicados: el filtro se aplica al leer, usando las estadísticas del pie de archivo, sin cargar todo a memoria.
Compresión
Los formatos columnares comprimen cada bloque con un códec. Snappy prioriza velocidad de CPU; Zstd equilibra ratio y velocidad; Gzip maximiza compresión pero cuesta al descomprimir. Menos bytes en disco también significa menos E/S.
Particionado de datos en el almacenamiento
Además del formato, conviene particionar los archivos en carpetas por una columna de filtro frecuente, como la fecha (anio=2024/mes=06/...). Así el motor descarta de entrada directorios irrelevantes. El riesgo es particionar por columnas de alta cardinalidad o muy finas, que generan miles de archivos pequeños.
| Técnica | Qué hace | Cuidado |
|---|---|---|
| Poda de columnas | lee solo las columnas usadas | ninguno, es barata |
| Pushdown de predicados | filtra al leer con el pie de archivo | no sirve con predicados no sargables |
| Poda de partición | salta carpetas irrelevantes | demasiadas particiones = archivos pequeños |
| Compresión | reduce almacenamiento y E/S | un códec lento eleva la CPU |
El problema de los archivos pequeños
Particionar muy fino o escribir micro-lotes crea muchísimos archivos diminutos: el motor gasta más abriendo archivos que leyendo datos, y el almacén se satura de metadatos. La solución es fijar un tamaño de archivo objetivo y compactar periódicamente.
Parquet y ORC
- Parquet: columnar, con estadísticas por bloque en el pie; amplio soporte multi-motor.
- ORC: columnar nacido en Hive, con índices y esquema embebido.
- Ambos comparten la idea: columnas, compresión y pushdown de predicados.
Errores frecuentes
- Particionar por una columna de altísima cardinalidad como un id.
- Guardar en formato de fila datos que solo se usan para agregar.
- Dejar que se acumulen archivos pequeños sin compactación.
Ejemplo resuelto: una consulta lee demasiado
- Medir cuántos bytes lee el motor frente a cuántos devuelve.
- Confirmar que el filtro principal es por fecha.
- Reescribir los datos en Parquet particionado por fecha.
- Elegir un códec rápido (snappy o zstd) y un tamaño de archivo objetivo.
- Programar compactación para los lotes diarios.
¿Para qué sirve en la realidad?
La mayor parte del costo y del tiempo de una plataforma de datos está en leer datos innecesarios. Elegir formato y partición correctos suele dar más aceleración que ajustar el clúster.
¿Por qué un formato columnar acelera una consulta analítica que agrega pocas columnas?
Particionar por una columna de muy alta cardinalidad suele ser buena idea.
Aplicar el filtro al momento de leer, apoyándose en las estadísticas del pie de archivo, se llama de predicados.
Clasifica cada decisión según si favorece o daña el rendimiento de lectura.
Favorece
Daña
Une cada término con su definición.
Formatos y particionado
Formatos columnares y particionado
# Formatos de datos ## Fila vs columna ### columna para analizar ### mejor compresion ## Podas ### particion ### columnas ### pushdown ## Almacenamiento ### carpetas por fecha ### cuidado cardinalidad ## Parquet y ORC ### pie con estadisticas ### compactar small files
Formato de archivo Parquet (documentación oficial)
Especificación del layout columnar, los bloques y la estadística del pie de archivo.
Spark SQL y Parquet (documentación oficial)
Cómo Spark aplica filter pushdown y particionado sobre archivos Parquet.
Una tabla particionada por customer_id (dos millones de valores) hoy tiene millones de archivos de unos cientos de bytes y las consultas empeoraron. ¿Qué cambio de particionado y de formato propondrías y por qué el filtro habitual de tus consultas manda en esa decisión?