Convertir Parquet a CSV

El camino contrario se ve claramente como una conversión: el texto se convierte en columnas con tipo y todo el mundo entiende que hay que revisar el resultado. Este sentido parece una exportación — los datos salen, no se comprime nada, no se deduce nada — y esa impresión es falsa de una manera concreta y cara.

Parquet lleva un esquema. Cada columna tiene un tipo declarado, anotado en un pie de archivo, y un motor de consultas lee ese pie antes de leer una sola fila. Un CSV lleva una fila de encabezados con nombres y nada más. Así que la conversión traslada los valores intactos y tira todo lo que el archivo sabía sobre ellos, y la siguiente herramienta que lo lea volverá a deducir los tipos a partir del texto, con toda probabilidad de otra manera.

Los booleanos llegan como true y false. Los enteros y los números en coma flotante se escriben en su forma decimal, con punto decimal, porque es JavaScript quien los pasa a texto. Las cadenas salen tal cual, entrecomilladas solo cuando el valor contiene una coma, unas comillas dobles o un salto de línea. Los nulos quedan como campos vacíos.

Nada de eso se puede revertir hasta el esquema original. Una columna que Parquet declaraba entera de 32 bits y otra que declaraba de doble precisión son ambas dígitos con un punto opcional, y una columna booleana y una de texto que contenga la palabra true se vuelven indistinguibles. Si el CSV va a cargarse en algún sitio con esquema propio, saca antes los tipos del Parquet y escríbelos en la definición de carga en lugar de dejar que la herramienta siguiente adivine.

Este es el tropiezo previsible para quien trabaja con una configuración regional española o latinoamericana. El archivo que sale de aquí siempre separa los campos con comas y escribe los decimales con punto, porque esta pareja no ofrece ningún control de separador — la opción de delimitador solo aparece cuando el origen es un CSV o un TSV, no cuando lo es el destino.

Excel configurado en español espera el punto y coma como separador de listas y la coma como separador decimal, así que al abrir el archivo con doble clic mete la fila entera en una sola columna. No es un fallo del archivo: es un desencuentro entre dos convenciones. La solución no es reescribir el CSV a mano sino importarlo, y ahí se decide el separador de una vez.

El CSV se escribe en UTF-8 sin marca de orden de bytes y con un salto de línea sencillo entre filas. Eso es lo correcto para scripts, cargadores e historiales de versiones, y es exactamente lo que hace que «Álvarez», «Peña» o «Bogotá» aparezcan como galimatías al abrir el archivo con doble clic en Windows, porque sin esa marca Excel recurre a la página de códigos del sistema.

La ruta que evita las dos cosas a la vez es Datos, Obtener datos, Desde texto/CSV: ahí eliges UTF-8 y el separador coma en la misma pantalla, y de paso puedes marcar como texto las columnas de identificadores. Eso último importa, porque Excel aplicará su propia conversión numérica justo a las columnas cuyo tipo se acaba de descartar. En LibreOffice Calc el diálogo de importación aparece solo y ofrece las mismas dos casillas.

Una columna de fechas se escribe como cadena ISO 8601, de modo que un valor sale con la forma 2024-03-11T09:30:00.000Z. Es la mejor respuesta posible en un formato sin tipo de fecha: no hay ambigüedad sobre cuál de los números es el mes, ordena correctamente como texto plano y lo interpreta cualquier base de datos y cualquier lenguaje sin que haya que darle un patrón.

Para un lector hispanohablante hay además una ventaja concreta: el formato ISO esquiva la confusión permanente entre el 03/11 español y el 03/11 estadounidense, que en una hoja compartida entre oficinas es una fuente inagotable de errores silenciosos. Sigue siendo texto, eso sí: una columna de fechas no responderá a la aritmética de fechas hasta que quien la lea sepa que lo es.

Parquet tiene un tipo entero de 64 bits, y JavaScript —que es lo que ejecuta esta conversión— representa números enteros de forma exacta solo hasta 53 bits. Un valor más allá de ese punto no se puede arrastrar como número sin perder precisión.

En vez de redondearlo, la conversión lo escribe como texto. Una referencia de pedido o un identificador largo aparece así en el CSV con todos sus dígitos, y una columna que mezcle valores seguros e inseguros tendrá entradas que eran números y entradas que eran cadenas, que en un CSV se ven igual de todas formas. La alternativa —redondear— produce un archivo donde un identificador está desviado en una unidad, cosa que se parece muchísimo a un identificador válido y sobrevive a varios sistemas antes de que nadie lo note.

Parquet guarda datos anidados de forma nativa: una columna puede ser una lista de cadenas, una estructura con miembros con nombre o un mapa. Una celda de CSV contiene un único valor escalar y no tiene sintaxis para nada más.

La conversión escribe esos valores como JSON dentro del campo, así que una columna de listas llega como ["a","b"] en una celda, entrecomillada porque el JSON contiene comas. Eso es reversible si quien lea el archivo lo interpreta, y es profundamente incómodo si el destino es una hoja de cálculo. Las columnas binarias reciben un trato parecido por el mismo motivo: una secuencia de bytes sin anotación de texto se escribe como hexadecimal en minúsculas, que al menos es reversible y no aparenta ser prosa.

Cuenta con varias veces el tamaño, y a veces con mucho más. Parquet escribe los valores en su forma binaria, comprime cada columna por separado y guarda una vez las columnas de valores repetidos, con referencias pequeñas hacia ellas. Un CSV no tiene nada de eso: cada valor se escribe como caracteres, en cada fila, sin comprimir.

Las columnas que más se encogieron al entrar son las que más se hinchan al salir. Un código de provincia repetido en un millón de filas no costó casi nada en el archivo Parquet y cuesta un millón de copias en el CSV. Conviene saberlo antes de intentar mandarlo por correo, y conviene recordar que comprimir el CSV en ZIP recupera buena parte de la diferencia si el destino lo acepta.

El lector materializa todas las filas antes de escribir nada, así que la tabla entera existe en memoria a la vez. Decenas de megabytes de Parquet van cómodos; ten presente que es un formato comprimido, de modo que un archivo modesto se expande en una cantidad enorme de texto y el techo llega antes de lo que sugiere el tamaño en disco.

Para una extracción grande la herramienta correcta es DuckDB, que lee el Parquet y escribe el CSV en una sola instrucción sin sostener ninguno de los dos en memoria. Además te deja elegir las columnas que de verdad hacen falta, que suele ser la mejor respuesta de todos modos: la mayoría de las peticiones de «pásame los datos en CSV» resultan ser peticiones de seis columnas.

El lector de Parquet es una biblioteca que la página descarga cuando la necesita, y la escritura es JavaScript corriente, así que ninguna petición lleva el archivo a ningún servidor. Eso importa más aquí que en la mayoría de las parejas: un archivo Parquet suele ser un artefacto del interior de una plataforma de datos, es decir, la versión anterior al enmascarado y a la agregación.

No hay cola, ni cuenta, ni cupo diario, ni límite de filas más allá de tu memoria. El único límite nuestro es de 100 MB por archivo, y puedes soltar hasta cien archivos por tanda; lo que sobre de cien se descarta sin aviso.

Si quien recibe tiene cualquier herramienta de datos moderna, manda el original. DuckDB, pandas, Polars, R con arrow, Spark y todos los almacenes leen Parquet directamente, y hacerlo conserva los tipos, mantiene el archivo pequeño y elimina un paso entero en el que algo puede salir mal.

Convierte a CSV cuando quien recibe de verdad no pueda: una compañera de administración con una hoja de cálculo, un requerimiento que nombra el formato, una pantalla de subida con una lista cerrada de extensiones. Esos casos son reales y frecuentes, y esta conversión existe para ellos. Lo que no debería ser es una costumbre, porque cada CSV producido a partir de un Parquet es una copia que ha olvidado lo que contiene.