Cuando un equipo empieza a construir un data lake, la conversación suele girar en torno a herramientas: qué motor de procesamiento, qué orquestador, qué plataforma en la nube. Pero hay una decisión más discreta que acaba por determinar la mitad del rendimiento y del coste de la plataforma: el formato en el que los datos quedan guardados en disco. Aquí es donde entran nombres como Parquet, Avro y ORC.
Estos tres formatos abiertos resuelven el mismo problema —almacenar grandes volúmenes de datos de forma eficiente— pero lo hacen de maneras distintas, pensadas para cargas de trabajo distintas. Elegir mal no rompe nada de inmediato: los datos siguen ahí. Lo que ocurre es más sutil. Las consultas se vuelven más lentas, la factura de almacenamiento y de compute sube, y nadie entiende del todo por qué.
Este artículo explica cómo funciona cada formato, dónde brilla y dónde tropieza, para que la elección deje de ser un detalle heredado de un tutorial y pase a ser una decisión consciente.
Fila o columna: la decisión que lo cambia todo
Antes de los nombres, la idea de base. Un archivo de datos puede organizar la información de dos formas: por fila o por columna.
En un formato orientado a la fila, los valores de un registro quedan juntos: el nombre, la edad, la ciudad y la fecha de un cliente se graban en secuencia, y el siguiente cliente viene a continuación. Es ideal para escribir un registro cada vez y para leer registros enteros, como hace una aplicación transaccional.
En un formato orientado a la columna es al revés: todos los nombres quedan juntos, luego todas las edades, luego todas las ciudades. Leer una tabla entera pasa a ser más trabajoso, pero responder a "cuál es la edad media de los clientes de Lisboa" se vuelve mucho más rápido, porque el motor solo lee las columnas edad y ciudad e ignora todo lo demás. En analítica, donde las consultas tocan pocas columnas pero millones de filas, esta diferencia es enorme.
Guardar esta distinción en la cabeza resuelve el 80% de las dudas: Parquet y ORC son columnares; Avro está orientado a la fila. El resto son detalles, importantes, pero detalles.
Parquet: el formato columnar que domina la analítica
Apache Parquet se ha convertido en el formato por defecto de prácticamente todo el ecosistema de datos moderno. Si usas Spark, un lakehouse o un motor de consulta como Trino, es casi seguro que los datos están en Parquet, y hay buenas razones para ello.
Al guardar los datos por columna, Parquet permite que el motor lea solo las columnas necesarias (el llamado projection pushdown). Como los valores de la misma columna son similares entre sí —muchas fechas parecidas, muchos códigos repetidos—, la compresión es mucho más eficaz que en un formato de fila. Además, Parquet guarda estadísticas por bloque (mínimo, máximo, recuento de nulos), lo que permite al motor saltarse bloques enteros que no interesan a la consulta (predicate pushdown). Menos datos leídos significa consultas más rápidas y más baratas.
El reverso de la moneda: escribir un único registro cada vez en Parquet es ineficiente. El formato se pensó para escribir muchos registros de una vez y leer muchas veces, no para actualizaciones constantes de filas sueltas.
ORC: el primo columnar del mundo Hive
Apache ORC (Optimized Row Columnar) nació en el ecosistema Hive y resuelve el mismo problema que Parquet, también de forma columnar. En la práctica, los dos se parecen más de lo que se diferencian: ambos comprimen bien, ambos guardan estadísticas, ambos aceleran las consultas analíticas.
Las diferencias son de afinado. ORC tiende a conseguir ratios de compresión ligeramente mejores en algunos escenarios y aporta índices ligeros y un soporte robusto de transacciones ACID cuando se usa dentro de Hive. Parquet, por su parte, tiene un soporte más universal fuera del mundo Hadoop: bibliotecas, motores y servicios en la nube hablan Parquet de forma nativa.
La regla práctica: si tu entorno es fuertemente Hive/Hadoop, ORC se siente en casa. Si quieres el denominador común que funciona en todas partes, Parquet es la apuesta segura. Elegir entre los dos rara vez decide el éxito de una plataforma; usar un formato columnar en lugar de fila, eso sí marca la diferencia.
Avro: cuando mandan la fila y el esquema
Apache Avro juega en otra liga. Está orientado a la fila, lo que lo convierte en mal candidato para consultas analíticas que recorren pocas columnas, pero excelente para otra cosa: mover datos y escribir registros a medida que llegan.
Avro guarda el esquema junto a los datos, en JSON, y se toma en serio la evolución del esquema: puedes añadir un campo nuevo, darle un valor por defecto y seguir leyendo archivos antiguos sin romper nada. Por eso es el formato natural para flujos de eventos —es omnipresente en pipelines con Kafka— y para la capa donde los datos aterrizan en bruto antes de ser transformados.
Piensa en Avro como el formato del transporte y del aterrizaje, y en Parquet/ORC como el formato del almacén analítico. Muchas arquitecturas usan ambos: reciben eventos en Avro y, más adelante en el pipeline, los reescriben en Parquet para consulta.
Compresión, esquema y evolución
Los tres formatos admiten compresión, pero con matices. En los columnares, como los valores similares quedan uno al lado del otro, algoritmos como Snappy (rápido) o ZSTD (más compacto) rinden mucho. La elección del codec es un compromiso clásico: comprimir más ahorra almacenamiento pero gasta más CPU al leer y escribir.
En cuanto al esquema, todos lo guardan con los datos, lo que evita la pesadilla de los archivos CSV sin una cabecera fiable. La diferencia está en la cultura de evolución: Avro se diseñó en torno a ella, con reglas claras de compatibilidad hacia delante y hacia atrás. Parquet y ORC también evolucionan el esquema, pero la disciplina recae más en el lado de la tabla (por ejemplo, mediante formatos de tabla como Delta Lake o Iceberg, que gestionan metadatos por encima de los archivos).
El problema de los archivos pequeños
Hay una trampa que atrapa a casi todo el mundo, y no depende del formato: los archivos pequeños. Un data lake con millones de archivos minúsculos —resultado, por ejemplo, de escrituras en streaming cada pocos segundos— es lento con independencia de que sea Parquet, ORC o Avro. Cada archivo tiene un coste fijo de apertura y de lectura de metadatos; multiplicado por millones, ese coste lo domina todo.
- Síntoma: consultas simples tardan una eternidad y el motor pasa más tiempo listando archivos que leyendo datos.
- Causa: ingesta frecuente que genera muchos archivos pequeños, sin consolidación.
- Cura: procesos de compaction que unen archivos pequeños en archivos mayores (idealmente del orden de cientos de MB), y una partición sensata que no fragmente los datos en exceso.
Elegir el formato correcto no salva a una plataforma llena de archivos pequeños. Los dos problemas hay que resolverlos juntos.
Cómo elegir sin complicarse
Reduciéndolo todo a lo esencial, la decisión cabe en tres preguntas:
- ¿Vas a consultar pocas columnas de tablas grandes? Usa un formato columnar: Parquet como elección por defecto, ORC si vives en el mundo Hive.
- ¿Vas a mover eventos o aterrizar datos en bruto que cambian de forma? Avro, por la evolución del esquema y la escritura registro a registro.
- ¿Necesitas transacciones, time travel o actualizaciones? La respuesta ya no es solo el formato de archivo, sino un formato de tabla (Delta Lake, Iceberg, Hudi) por encima de Parquet u ORC.
En la mayoría de las plataformas, la combinación ganadora es banal: Avro (o JSON) a la entrada, Parquet en el almacén analítico. No hace falta más exotismo que eso para acertar.
Mini-caso: una empresa de retail ordenando el data lake
Una empresa de retail con tienda física y online guardaba todo —ventas, clics, stock— en archivos JSON comprimidos, escritos cada hora. Los informes diarios tardaban cerca de 40 minutos y la factura de compute no paraba de crecer. El equipo creía que necesitaba un motor más potente; en realidad, necesitaba ordenar la casa.
Hicieron dos cambios. Primero, pasaron a reescribir los datos históricos en Parquet particionado por fecha, con compresión ZSTD. Segundo, introdujeron un paso de compaction nocturno que consolidaba los miles de archivos pequeños del día en unos pocos archivos grandes. Mantuvieron Avro solo en la capa de entrada, donde llegan los eventos.
El resultado: los informes que tardaban 40 minutos pasaron a ejecutarse en unos 6, el volumen de datos leído por consulta cayó a una fracción del anterior y el almacenamiento se redujo cerca de un 60% gracias a la mejor compresión. Ningún motor nuevo, ninguna reescritura de la aplicación: solo el formato correcto, en el lugar correcto, sin archivos pequeños estorbando.
En la práctica
Los formatos de archivo no son el tema más glamuroso de una plataforma de datos, pero están entre los que más silenciosamente deciden su coste y su velocidad. La buena noticia es que la decisión es sencilla cuando se entiende la lógica: columnar (Parquet u ORC) para consultar, fila (Avro) para transportar y aterrizar.
Antes de cambiar de motor o de aumentar recursos por culpa de consultas lentas, vale la pena mirar hacia abajo, hacia el formato y el tamaño de los archivos. Muchas veces, la mayor ganancia está justo ahí, y no cuesta una licencia nueva, solo una decisión de ingeniería bien tomada.
