¿Qué es un archivo Parquet?

Parquet es un formato binario, que solo significa algo para un programa que lo conoce. Se usa para el archivado y mover datos entre programas.

La extensión es .parquet y el nombre completo, Apache Parquet. Ambos importan menos que lo que el archivo puede contener, y de eso trata el resto de esta página.

Apache Software Foundation lo publicó en 2013.

La edad interesa por un motivo práctico: cuanto más antiguo es un formato, más programas han tenido tiempo de aprenderlo.

Está publicada entera, así que cualquiera puede implementarla leyendo el documento en vez de a base de inspeccionar archivos. Por eso aparece en tantos programas, y por eso los archivos escritos hace veinte años siguen abriéndose hoy. Publicada no quiere decir libre de regalías: cuando un formato envuelve un códec, la licencia de las patentes es un asunto aparte que la norma no resuelve.

Parquet guarda su contenido exactamente. Volver a guardarlo no cambia nada, así que puedes abrirlo, editarlo y guardarlo tantas veces como quieras sin acumular daño; eso es lo que lo convierte en un formato de trabajo y no de entrega.

Parquet lleva una suma de verificación, para que un archivo dañado se detecte en vez de leerse mal en silencio y cifrado opcional.

Un archivo cifrado hay que abrirlo antes de que nada pueda convertirlo, aquí y en cualquier otro sitio. Una contraseña no es algo que un conversor pueda esquivar, y a uno que dijera lo contrario tampoco habría que confiarle el archivo.

pandas, Apache Spark y DuckDB lo leen, y también la mayoría de programas del mismo tipo.

Cuando un archivo no se abre, el formato rara vez es el problema: lo más habitual es que el programa sea anterior al formato. Convertir a algo más antiguo es la salida fiable, y para eso está el resto de este sitio.

Ningún navegador lo lee.

Ese es el motivo más frecuente para convertirlo: no que el formato sea malo, sino que el sitio donde quieres mostrar el archivo no sabe leerlo.

Parquet está pensado para entregarse, no para trabajar dentro. Editar uno es posible y rara vez agradable; lo sensato es cambiar el original y volver a exportar.

Las quejas recurrentes: fuera de su terreno la compatibilidad es irregular.

Nada de esto es motivo para evitar el formato. Son las cosas que conviene conocer antes de que una de ellas te sorprenda, que es una afirmación distinta y más útil.

Un CSV escribe un registro cada vez: nombre, fecha, país, importe, y a continuación el siguiente registro. Parquet escribe una columna cada vez: todos los nombres juntos, después todas las fechas, después todos los países.

Esa reordenación es el formato entero. Suena a manía de archivador y cambia la economía de todo lo que viene después, porque una consulta que necesita dos columnas de cincuenta lee exactamente esas dos y se salta el resto, y porque una columna de valores parecidos se comprime muchísimo mejor que una fila de valores que no tienen nada que ver entre sí.

Los valores de una columna se parecen: las fechas tienen forma de fecha, los códigos de provincia se repiten, los importes comparten magnitud. De esa semejanza vive la compresión. Además Parquet codifica antes de comprimir: una columna con pocos valores distintos se convierte en un diccionario y una lista de enteros pequeños, y una racha de valores idénticos se convierte en una cuenta.

El resultado normal es entre cinco y diez veces más pequeño que los mismos datos en CSV, y bastante más en tablas anchas con columnas repetitivas. Eso ahorra almacenamiento y, sobre todo, ahorra tiempo de transferencia a todo lo que tenga que leerlo.

Un CSV no tiene tipos, así que cada programa que lo abre adivina, y ahí es donde se evaporan los ceros a la izquierda y donde un código de artículo se convierte en una fecha. Parquet declara en su propio esquema el tipo de cada columna: esto es un entero de 64 bits, esto una cadena, esto una marca de tiempo con zona horaria, esto un decimal con tantas posiciones.

Los datos llegan queriendo decir lo que querían decir. No se infiere nada, no depende de la configuración regional de nadie, y una columna de códigos postales sigue siendo una columna de códigos postales al llegar. Para cualquier cosa que se mueva entre sistemas, esto pesa más en la práctica que la compresión.

El archivo se organiza en grupos de filas, y cada grupo guarda estadísticas por columna: mínimo, máximo y cuántos nulos hay. Una consulta que filtra por un rango de fechas lee esas estadísticas, ve que un grupo entero queda fuera del rango y se lo salta sin descomprimir nada.

De ahí que una consulta sobre un conjunto grande en Parquet pueda ser incomparablemente más rápida que la misma sobre CSV, más allá de leer menos columnas. Y de ahí también que particionar por fecha en carpetas —una por día— funcione tan bien: el motor descarta archivos enteros antes de empezar a leer.

En devolver un registro suelto. Reconstruir una fila obliga a recoger un valor de cada columna, que es justo el patrón de acceso para el que la disposición no está pensada. Parquet es un formato de análisis, no una base de datos.

En añadir datos. El archivo se escribe entero, con sus estadísticas y su pie calculados al final, así que sumar una fila significa reescribirlo o escribir otro archivo. Por eso los flujos continuos acaban dejando muchos archivos pequeños que alguien compacta después. Y en dejarse mirar: es binario, un editor de texto no enseña nada útil y hace falta una herramienta para asomarse.

La barrera es más baja de lo que era. DuckDB lee un Parquet directamente con una sola consulta SQL y se instala en segundos. Python con pandas o con Polars lo abre en una línea. Hay varios visores de escritorio gratuitos que lo enseñan como una hoja de cálculo.

La otra vía es convertirlo a CSV, y es la correcta cuando quien lo necesita va a abrirlo en una hoja de cálculo, asumiendo que los tipos vuelven a ser conjeturas y que el archivo se multiplica de tamaño. Conserva el Parquet como origen y genera el CSV para quien lo pidió.

Donde se analicen datos a cierta escala: lagos de datos en almacenamiento en la nube, Spark y Databricks, exportaciones de Snowflake o BigQuery, Athena, canalizaciones de dbt, y cada vez más en análisis corriente con Python, donde ha sustituido silenciosamente al CSV como manera de guardar un dataframe.

También es el formato en el que administraciones y proyectos de investigación empiezan a publicar conjuntos grandes, precisamente porque la alternativa —un CSV de dos gigas que ninguna hoja de cálculo abre— no le sirve a nadie. Si te han pasado uno, casi seguro que viene de ahí.

Conviene saber qué llega al otro lado. Un entero de 64 bits se entrega como número, pero si pasa de 2^53 se entrega como texto, porque a partir de ahí un número de JavaScript ya no lo representa con exactitud. Las fechas se convierten en cadenas con formato ISO, los campos binarios en hexadecimal en minúsculas, y cualquier estructura anidada en texto JSON.

Nada de eso es un fallo: es la única manera honesta de meter un esquema tipado en una tabla plana. Pero significa que el valor que sale se parece al que entró sin ser del mismo tipo, y conviene contarlo antes de que alguien lo descubra en una comparación que no cuadra.

El escritor mira cada columna y elige entre cuatro tipos físicos: booleano, entero de 32 bits, doble o cadena. Un solo valor no numérico convierte toda la columna en texto, y los enteros que no caben en 32 bits pasan a doble en lugar de a entero de 64, porque escribirlos como entero de 64 prometería una exactitud que ya no tienen.

Dos consecuencias. Una: los datos anidados se aplanan en columnas con el nombre separado por puntos, igual que hacia CSV o XLSX, así que la estructura de árbol no llega. Otra: una ida y vuelta a Parquet no devuelve el esquema original. Si lo que necesitas es conservar los tipos exactos del archivo de partida, la conversión no es el camino: el Parquet original lo es.