Ir al contenido principal

¿Qué es un archivo Parquet? Claves que debes conocer

Descubre cómo el diseño columnar de Parquet mejora la compresión, acelera las consultas y cuándo elegirlo frente a CSV.
Actualizado 17 sept 2026  · 15 min leer

Explorar con IA

ChatGPTClaudePerplexity

El formato de archivo es uno de los mayores cuellos de botella en analítica de datos. Los formatos basados en texto como CSV y JSON son fáciles de leer y compartir, pero no se diseñaron para la escala y complejidad de las cargas analíticas modernas. Cada consulta paga un peaje de rendimiento porque estos formatos no distinguen entre los datos que necesitas y los que no.

Parquet resuelve este problema. Es un formato de archivo creado específicamente para cargas analíticas en data engineering, data science y sistemas de big data. Al almacenar los datos por columnas en lugar de por filas, las consultas leen solo lo necesario. ¿El resultado? Consultas más rápidas, menor coste de almacenamiento y menos cómputo desperdiciado.

En este artículo te explico qué hace diferente a Parquet, cómo funciona a alto nivel y cuándo deberías usarlo. Me centro en conceptos y casos de uso, no en detalles de implementación o código. Si quieres poner manos a la obra con ejemplos y práctica, tenemos una guía detallada sobre Apache Parquet para profesionales de datos que cubre el lado técnico.

¿Qué es un archivo Parquet?

Entonces, ¿qué es exactamente Parquet? En esencia, es un formato de almacenamiento columnar creado para un almacenamiento eficiente y consultas analíticas rápidas. En lugar de guardar los datos fila a fila, como en los formatos tradicionales, Parquet los almacena columna a columna. Este cambio, que parece sencillo, lo hace ideal para el procesamiento de datos a gran escala.

Parquet funciona mejor cuando:

  • Lees solo un subconjunto de columnas de un conjunto de datos
  • Escaneas grandes volúmenes de datos
  • Realizas agregaciones, filtrado y consultas analíticas

El formato forma parte del ecosistema Apache y se mantiene como estándar de código abierto por Apache Parquet. Al ser abierto y estar bien soportado, Parquet se integra sin problemas con muchas herramientas modernas, incluidos data warehouses, data lakes y frameworks de procesamiento distribuido.

Almacenamiento columnar vs. formatos por filas

Los formatos basados en filas (CSV, JSON) almacenan registros completos en una sola fila. Esto funciona bien para casos transaccionales o cuando necesitas leer filas enteras de una vez.

Los formatos columnarios (Parquet) almacenan juntos todos los valores de la misma columna. Así, los motores analíticos leen solo las columnas que necesitan y omiten el resto.

Un ejemplo: si un dataset tiene 50 columnas pero tu análisis solo requiere 3, un formato columnar como Parquet puede leer únicamente esas 3. Con un formato por filas, hay que escanear la fila completa, aunque la mayor parte no se use.

Vamos a concretarlo. Imagina que analizas transacciones de e-commerce. Tu dataset tiene 40 columnas, pero solo necesitas calcular el valor medio del pedido por mes. Te basta con order_total y order_date. Con Parquet, tu consulta lee exactamente esas 2 columnas. Con CSV, lee las 40 columnas de cada fila, aunque 38 no aporten nada a tu análisis. En un dataset con millones de transacciones, la diferencia es enorme.

Este tipo de eficiencia es clave para que los datos resulten útiles. Si te interesa cómo los datos en bruto se convierten en insights accionables, nuestra chuleta sobre la pirámide dato-información-conocimiento-sabiduría explica esta transformación.

Por qué Parquet se usa tanto

Este diseño columnar se traduce en varias ventajas prácticas para la analítica:

  • Mejor compresión, ya que agrupar tipos de datos similares mejora la eficiencia
  • Consultas más rápidas, porque los motores procesan menos datos en total
  • Menores costes de almacenamiento frente a formatos de texto plano

Estas propiedades hacen de Parquet una opción habitual en data lakes, almacenamiento en la nube y canalizaciones analíticas donde la eficiencia pesa más que la legibilidad humana.

En pocas palabras, Parquet es un formato columnar y abierto, creado para manejar grandes conjuntos de datos de forma eficiente, especialmente cuando el objetivo es el análisis y no el simple intercambio de datos.

Por qué se usan archivos Parquet en analítica de datos

Ahora que ya sabemos qué es Parquet, veamos por qué se ha hecho tan popular en analítica. No es porque sea más fácil de manejar que otros formatos, sino porque es mucho más eficiente a escala. La mayoría de cargas analíticas no se parecen a los sistemas transaccionales, donde recuperas un registro completo cada vez. En su lugar, escanean grandes conjuntos de datos y se centran en un subconjunto de columnas.

El almacenamiento columnar encaja de forma natural con este patrón. Cuando los datos se guardan por columnas, los motores leen solo los campos necesarios. Si una consulta toca cinco columnas de cincuenta, Parquet permite saltarse por completo las otras cuarenta y cinco. Esto reduce drásticamente el I/O de disco, que suele ser el principal cuello de botella.

La compresión es otra gran ventaja. Los valores de una misma columna comparten tipos y rangos similares, por lo que Parquet los comprime mucho mejor que los formatos por filas. Mejor compresión significa archivos más pequeños, menos coste de almacenamiento y menos datos que transferir durante la ejecución de consultas.

Estos dos factores (menos I/O y mejor compresión) se traducen directamente en consultas más rápidas. Por eso Parquet se ha convertido en la opción por defecto en muchos motores analíticos y sistemas de consulta distribuidos.

Parquet es ya un estándar en data lakes y plataformas de analítica en la nube, donde se almacenan grandes volúmenes de datos para consultarlos repetidamente. En estos entornos, el rendimiento y la eficiencia de costes importan más que la legibilidad humana, lo que hace a Parquet más adecuado que formatos de texto como CSV o JSON.

Si trabajas con Python, a menudo tendrás que moverte entre distintos formatos. Nuestra guía para importar datos en Python explica cómo trabajar con Parquet junto a CSV, JSON y otros formatos.

Cómo almacenan datos los archivos Parquet (visión general)

Ya hemos hablado de las ventajas del almacenamiento columnar, pero ¿cómo organiza Parquet los datos en disco? En lugar de escribir registros completos de forma secuencial (por filas), Parquet agrupa todos los valores de cada columna.

En un formato por filas, cada registro se escribe completo antes de pasar al siguiente. Esto va bien cuando necesitas a menudo la fila entera, pero se vuelve ineficiente cuando las consultas analíticas solo se fijan en unos pocos campos.

Parquet hace justo lo contrario. Todos los valores de una misma columna se almacenan juntos, y cada columna es independiente. Cuando se ejecuta una consulta, el motor escanea solo las columnas relevantes e ignora el resto. Si la consulta aplica condiciones sobre una columna concreta, el motor las evalúa directamente sin tocar campos no relacionados. Menos lecturas de disco, ejecución más rápida.

No necesitas conocer las estructuras internas de Parquet para sacarle partido. La idea clave es sencilla: almacenar datos similares juntos permite lecturas más inteligentes. Esa única decisión de diseño hace que Parquet sea tan efectivo para cargas analíticas, incluso antes de considerar la compresión u otras optimizaciones.

Estos patrones de almacenamiento cobran especial importancia cuando trabajas con sistemas de datos a gran escala. Si utilizas PostgreSQL para consultas estructuradas, echa un vistazo a nuestra chuleta de fundamentos de PostgreSQL para consejos de optimización. Y si lidias con datasets realmente masivos, quizá te interese explorar estrategias de particionado de datos para combinar con el almacenamiento columnar de Parquet.

Este diseño orientado a columnas explica por qué Parquet rinde tan bien en entornos intensivos en analítica y por qué se ha convertido en un formato fundamental en los sistemas de datos modernos.

Características clave del formato Parquet

Más allá del concepto de almacenamiento columnar, Parquet incluye varias características que lo hacen especialmente eficaz para cargas analíticas. En lugar de priorizar la legibilidad humana, el formato prioriza el almacenamiento eficiente, las consultas rápidas y la interoperabilidad entre herramientas modernas.

Almacenamiento columnar

Parquet guarda los datos por columnas en vez de por filas, permitiendo a los motores analíticos leer solo los campos necesarios para una consulta. Esto reduce escaneos innecesarios y mejora notablemente el rendimiento en grandes volúmenes de datos.

Compresión eficiente

Como los valores de una misma columna suelen ser similares, Parquet logra ratios de compresión mucho más altos que los formatos por filas. Archivos más pequeños significan menor coste y transferencias más rápidas.

Soporte de esquemas

Los archivos Parquet incluyen un esquema explícito que define tipos y estructura. Esto garantiza una interpretación consistente entre herramientas y evita problemas típicos de los formatos de texto con tipado laxo. Si trabajas con Power BI, la gestión del esquema es especialmente importante. Puedes saber más sobre cómo manejar estructuras de tablas en nuestra guía sobre trabajar con tablas en Power Query M.

Metadatos integrados para acelerar consultas

Parquet almacena metadatos sobre columnas y bloques de datos, lo que permite a los motores de consulta saltarse secciones irrelevantes del archivo. Así, el filtrado y las lecturas selectivas son más eficientes sin escanear el dataset completo.

Compatibilidad con herramientas de big data

Parquet es compatible con la mayoría de frameworks modernos de procesamiento de datos y motores de consulta, por lo que es una apuesta fiable para data lakes y flujos de analítica en la nube. Esta amplia compatibilidad ayuda a evitar el encierro en un formato sin renunciar al rendimiento.

El formato funciona sin fricciones entre distintas herramientas e idiomas. Si construyes dashboards, nuestro itinerario Power BI Fundamentals cubre cómo trabajar con diversas fuentes de datos de forma eficiente. Para usuarios de R que manipulan datos a gran escala, el paquete data.table combina muy bien con Parquet para analítica de alto rendimiento.

Parquet vs. CSV y otros formatos

Llegados a este punto quizá te preguntes cómo se compara Parquet con formatos conocidos como CSV. La respuesta corta es que Parquet y CSV se han diseñado para casos de uso distintos.

CSV es un formato de texto plano y por filas. Es fácil de crear, de abrir en un editor o en una hoja de cálculo y de compartir. Es una buena opción para datasets pequeños, exportaciones rápidas e intercambios básicos entre sistemas o personas.

Parquet, en cambio, es un formato binario y columnar pensado para analítica. En lugar de priorizar la legibilidad, prioriza el rendimiento. Las consultas analíticas a menudo necesitan solo unas pocas columnas de un dataset grande, y Parquet está diseñado para leer justo esas columnas con eficiencia. Esto hace que el análisis a gran escala sea mucho más rápido y rentable, especialmente en entornos distribuidos.

Ese mismo diseño explica sus concesiones. No es legible para humanos y rara vez es la mejor opción para compartir datos ad hoc o inspecciones manuales. Para esos casos, CSV o JSON siguen siendo más prácticos.

Otros formatos quedan a medio camino. JSON es flexible y muy usado en APIs, pero es ineficiente para analítica a escala. Avro y ORC, como Parquet, están pensados para sistemas de big data, pero cubren funciones algo distintas según se prefiera acceso por filas o por columnas. Si estás decidiendo entre ellos, hemos preparado una comparación detallada de Avro vs. Parquet que repasa pros y contras.

En la práctica, Parquet se ha convertido en la opción más habitual cuando importan el rendimiento de consulta y la eficiencia de almacenamiento.

Dónde se usa Parquet habitualmente

Con todo lo que hemos visto sobre cómo funciona Parquet y por qué es efectivo, veamos dónde te lo encontrarás. Los archivos Parquet son más comunes en entornos donde grandes volúmenes de datos se consultan repetidamente para análisis, en lugar de leerse de principio a fin una sola vez.

Data lakes y arquitecturas lakehouse

Un caso muy común son los data lakes y las arquitecturas lakehouse, donde se almacena barato tanto el dato en bruto como el procesado y se consulta bajo demanda. El almacenamiento eficiente y las lecturas selectivas de columnas hacen que Parquet encaje de maravilla con estos datasets grandes y en evolución.

Inteligencia de negocio y cargas analíticas

Parquet también se usa ampliamente en inteligencia de negocio y cargas analíticas. Los dashboards, informes y el análisis exploratorio suelen escanear solo un subconjunto de columnas a lo largo de muchos registros, lo que encaja perfectamente con el diseño columnar de Parquet.

Herramientas como Power BI y Tableau aprovechan Parquet para mejorar el rendimiento. Si trabajas con Power BI y quieres gestionar mejor tus activos de datos, nuestro curso sobre despliegue y mantenimiento de activos en Power BI cubre buenas prácticas. Y si te estás preparando para certificar oficialmente tus habilidades en Power BI, consulta nuestra guía para aprobar la certificación PL-300 de Power BI.

Flujos de trabajo de machine learning

En los flujos de machine learning, Parquet se usa a menudo para almacenar características y datos de entrenamiento. Los modelos pueden cargar solo las features necesarias, reduciendo el I/O y acelerando los experimentos con datasets grandes. Cuando haces análisis exploratorio de estas features, librerías de visualización como Plotly Express funcionan bien con Parquet. Nuestra chuleta de Plotly Express te muestra cómo crear visualizaciones interactivas con eficiencia.

Sistemas de consulta en la nube y distribuidos

Por último, Parquet encaja muy bien en sistemas de consulta en la nube y distribuidos, donde el rendimiento y el coste dependen estrechamente de la cantidad de datos escaneados. Al minimizar lecturas innecesarias y comprimir eficazmente, Parquet ayuda a que estos sistemas escalen con eficiencia a medida que crecen los volúmenes.

Herramientas y plataformas que soportan Parquet

Saber dónde se usa Parquet es una cosa, pero ¿qué herramientas utilizarás realmente? Una de las razones de su adopción masiva es el amplio soporte en los ecosistemas de datos modernos. No estás aprendiendo un formato de nicho ni dependiente de un proveedor. Parquet es un estándar de facto en analítica a gran escala.

La mayoría de motores de consulta distribuidos y frameworks de procesamiento pueden leer y escribir Parquet de forma nativa. Es común en plataformas de datos en la nube, sistemas de big data y motores de analítica diseñados para escanear datasets grandes con eficiencia. Al ser un formato abierto respaldado por Apache, se integra bien entre herramientas sin atarte a un proveedor o stack concretos.

Parquet también está muy bien soportado en data science y machine learning, donde los datasets deben compartirse entre equipos, canalizaciones y entornos. Los mismos archivos Parquet pueden servir para exploración, reporting y entrenamiento de modelos sin conversiones. Si trabajas con R y necesitas documentos reproducibles, Quarto funciona bien con Parquet para crear informes que combinan código, análisis y resultados.

Esta amplia compatibilidad es parte del atractivo de Parquet. Elegir Parquet no implica casarte con una base de datos, un proveedor cloud o un motor analítico concreto. Implica adoptar un formato que funciona en múltiples plataformas y escala con tu arquitectura de datos.

Limitaciones y trade-offs de Parquet

Con tantas ventajas, podrías pensar que Parquet soluciona cualquier problema de almacenamiento de datos. No es así. A pesar de sus fortalezas, Parquet no es una solución universal. Su diseño favorece ciertos tipos de cargas, y conocer sus límites ayuda a evitar usos inadecuados.

No optimizado para actualizaciones frecuentes

Parquet está optimizado para lectura intensiva, no para actualizaciones frecuentes o escrituras pequeñas e incrementales. Normalmente se escribe en lotes, por lo que no encaja bien con sistemas transaccionales o actualizaciones en tiempo real registro a registro.

Complejidad en la gestión de esquemas

Gestionar esquemas puede ser más complejo que con formatos de texto simples. Aunque Parquet admite evolución de esquemas, cambiar definiciones de columnas con el tiempo requiere coordinación y cuidado, especialmente en entornos compartidos.

No es un sustituto de una base de datos

Parquet no está diseñado para reemplazar bases de datos en cargas operacionales. Carece de soporte nativo para transacciones, índices de búsqueda puntual y actualizaciones de baja latencia, todos críticos en sistemas orientados a aplicaciones.

El problema de los archivos pequeños

Por último, Parquet puede sufrir el llamado "problema de los archivos pequeños". Almacenar los datos como muchos archivos Parquet diminutos reduce las ganancias de eficiencia del formato columnar y perjudica el rendimiento en sistemas distribuidos. Parquet rinde mejor cuando los datos se escriben en fragmentos de tamaño razonable alineados con la forma en que se van a consultar.

Estos trade-offs no restan valor a Parquet, pero sí aclaran dónde encaja mejor: analítica a gran escala optimizada para lectura, no cargas transaccionales o muy mutables.

Errores comunes a evitar con Parquet

Crear demasiados archivos pequeños es un error. Escribir miles de archivos Parquet diminutos va contra el objetivo. Apunta a archivos de decenas de MB como mínimo, idealmente cientos. En sistemas distribuidos, esto suele implicar configurar las escrituras para agrupar en lotes adecuadamente.

Usar Parquet para datos que se actualizan con frecuencia es otro error. Si actualizas registros individuales a lo largo del día, Parquet no es la mejor opción. Está pensado para escrituras por lotes, no para actualizaciones incrementales.

Ignorar la evolución del esquema es un error. Si necesitas añadir o cambiar columnas, planifícalo. Parquet admite evolución de esquemas, pero requiere coordinación cuidadosa, sobre todo en entornos compartidos.

Por último, no particionar datasets muy grandes sería un error. Para volúmenes muy altos, conviene particionar por columnas que se filtran habitualmente. Así, los motores pueden saltarse archivos enteros que no cumplan los criterios.

Cuándo deberías (y no deberías) usar Parquet

Con todo esto en mente, ¿cuándo deberías usar Parquet? La respuesta depende de ajustar el formato a tu carga. Parquet es una gran opción, pero solo cuando encaja con el tipo de trabajo que haces. Pensar en cómo se leen y se escriben tus datos suele aclarar la decisión.

Cuándo Parquet es buena opción

  • Trabajas con cargas analíticas o de reporting que escanean grandes datasets
  • Las consultas suelen leer solo un subconjunto de columnas, no filas completas
  • Los datos se escriben por lotes (ingestas diarias o canalizaciones programadas, por ejemplo)
  • La eficiencia de almacenamiento y el rendimiento pesan más que la legibilidad humana
  • Estás construyendo o contribuyendo a un data lake o a una arquitectura lakehouse

En estas situaciones, el diseño columnar, la compresión y los metadatos de Parquet se notan enseguida.

Cuándo pueden convenir formatos más simples

  • Necesitas archivos fáciles de inspeccionar o editar a mano
  • Intercambias datos entre sistemas en volúmenes pequeños o flujos ad hoc
  • Tienes actualizaciones frecuentes o escrituras transaccionales
  • La sencillez y la interoperabilidad importan más que el rendimiento

Formatos como CSV o JSON suelen encajar mejor para intercambios ligeros o fases tempranas. Piénsalos como los archivos de configuración de tu entorno de desarrollo (si has trabajado con dotfiles, sabes por qué importa el texto plano cuando tienes que leer y editar a menudo).

La idea clave es que Parquet brilla en entornos con mucha lectura y enfoque analítico. Si tu carga encaja ahí, es difícil superarlo. Si no, los formatos más simples suelen dar menos quebraderos de cabeza.

Conclusión

La clave práctica: si trabajas con grandes datasets y tus consultas suelen necesitar solo un subconjunto de columnas, Parquet probablemente te ahorrará tiempo y dinero. Si haces actualizaciones frecuentes a registros individuales o necesitas archivos legibles para humanos, quédate con formatos más simples.

Lo bueno de Parquet es que es un estándar abierto con amplio soporte en el ecosistema. Puedes usarlo en distintas herramientas sin atarte a un proveedor. Tanto si eres analista que lanza consultas, ingeniero que construye canalizaciones o arquitecto que diseña sistemas de datos, Parquet encaja de forma natural en entornos modernos y distribuidos.

Si eres nuevo en Parquet, empieza en pequeño. Prueba a convertir a Parquet uno de tus CSV que más consultas y compara el rendimiento. La diferencia en datasets grandes suele ser evidente. A partir de ahí, decide dónde más te conviene el almacenamiento columnar en tu flujo de trabajo.

¿Quieres profundizar en la implementación? Nuestro tutorial de Apache Parquet recorre ejemplos prácticos con código, y tenemos muchos más recursos sobre formatos modernos y herramientas analíticas para ayudarte a construir sistemas de datos más eficientes.


Oluseye Jeremiah's photo
Author
Oluseye Jeremiah
LinkedIn

Redactor técnico especializado en IA, ML y ciencia de datos, que hace que las ideas complejas sean claras y accesibles.

Temas
Ingeniería de datos

Aprende con DataCamp

Curso

Python intermedio para desarrolladores

2 h
67.6K
Sumérgete en el ecosistema Python, descubre los módulos y paquetes y aprende a escribir funciones personalizadas.
Ver detallesRight Arrow
Iniciar Curso
Ver másRight Arrow
Relacionado

blog

CSV frente a Excel: Elegir bien tus proyectos de datos

Elige CSV para un intercambio de datos sencillo y una alta compatibilidad, y Excel para un análisis completo, visualización y funciones avanzadas.
Samuel Shaibu's photo

Samuel Shaibu

10 min

blog

Contratos de datos desmitificados: Todo lo que necesitas saber

Lograr la escalabilidad en los sistemas de datos distribuidos y reducir los errores.
Mike Shakhomirov's photo

Mike Shakhomirov

11 min

blog

¿Qué son los modelos semánticos de Power BI?

Conozca los modelos semánticos en Power BI, sus componentes, modos y mejores prácticas para crearlos y gestionarlos.
Joleen Bothma's photo

Joleen Bothma

7 min

blog

Las 7 mejores bases de datos vectoriales en 2026

Una guía completa sobre las mejores bases de datos vectoriales. Domina el almacenamiento de datos de alta dimensión, descifra información no estructurada y aprovecha las incrustaciones vectoriales para aplicaciones de IA.
Moez Ali's photo

Moez Ali

14 min

Tutorial

Seleccionar varias columnas en SQL

Aprende a seleccionar fácilmente varias columnas de una tabla de base de datos en SQL, o a seleccionar todas las columnas de una tabla en una simple consulta.
DataCamp Team's photo

DataCamp Team

3 min

Tutorial

Cómo utilizar un alias SQL para simplificar tus consultas

Explora cómo el uso de un alias SQL simplifica tanto los nombres de las columnas como los de las tablas. Aprende por qué utilizar un alias SQL es clave para mejorar la legibilidad y gestionar uniones complejas.
Allan Ouko's photo

Allan Ouko

9 min

Ver MásVer Más