Convertir XLSX a Parquet

Cualquier otro destino de un libro de cálculo guarda un registro detrás de otro. Parquet guarda un campo detrás de otro: primero las cincuenta mil fechas de pedido juntas, después las cincuenta mil ciudades, después todos los importes. No es una preferencia de formato, es la razón entera de que exista.

La consecuencia aparece en la primera consulta. Una pregunta que lee dos campos de doscientos toca los bytes de dos columnas en vez de recorrer todas las filas, y una columna de valores repetidos comprime muchísimo más que los mismos valores repartidos por filas. Convertir una hoja de cálculo es por tanto una transposición tanto como una serialización, y el trabajo interesante está en decidir de qué tipo es cada columna. El archivo además lleva su propio esquema en un pie, que es lo que permite a un motor de consulta decirte los nombres y los tipos sin leer ni una fila.

La conversión toma la primera hoja del libro y la lee con los valores tal como están guardados. Eso es toda la lectura. Las hojas segunda en adelante no aparecen por ninguna parte, y tampoco llegan las fórmulas —vuelve el resultado guardado, nunca la expresión—, ni los formatos de número, ni las celdas combinadas, ni los gráficos, ni las imágenes, ni los anchos de columna, ni los estilos, ni las validaciones, ni los comentarios, ni los nombres definidos, ni las tablas dinámicas.

Para alimentar un motor de consulta eso no es una pérdida sino el objetivo: llega la tabla y nada más. Se vuelve un problema sólo si la hoja que te interesa no es la primera, y entonces la solución es moverla al principio del libro o copiarla a un archivo nuevo antes de convertir. Merece la pena comprobarlo, porque una conversión que devuelve la hoja equivocada no falla: devuelve datos perfectamente válidos que no son los tuyos.

El tipo se deduce de los valores y no se declara, porque una hoja de cálculo no lleva esquema. Cada columna se examina entera: si todos sus valores no vacíos son booleanos pasa a BOOLEAN; si son números enteros dentro del rango de 32 bits pasa a INT32; si son números pero no todos enteros, o no todos lo bastante pequeños, pasa a DOUBLE; cualquier otra cosa pasa a cadena de texto.

Los vacíos no participan. Una columna de números con huecos sigue siendo una columna numérica y los huecos se escriben como nulos, que es lo que espera un motor de consulta. La inferencia lee la columna completa antes de decidir, en vez de tomar una muestra, lo que cuesta una pasada sobre los datos y elimina toda una clase de sorpresas: el muestreo es lo que hacen casi todas las herramientas y es la razón de que una carga que funcionaba con el archivo de prueba reviente en producción, porque las primeras mil filas estaban limpias y la cuarenta mil no.

La regla anterior tiene una consecuencia muy concreta para quien trabaja en español: basta un valor no numérico para que la columna entera se escriba como texto. Y en un libro que nació de una exportación mal importada, un CSV abierto con la configuración equivocada o un pegado desde una web, los números con coma decimal muy a menudo no son números dentro de la hoja: son la cadena `1,50`, o `1.234,56`, alineada a la izquierda en la celda.

Excel los muestra con toda naturalidad y el ojo no distingue nada, pero el lector de esta conversión ve texto, y una sola celda así arrastra la columna completa a cadena. La comprobación es de diez segundos y hay que hacerla en el libro, no en el resultado: si los importes aparecen alineados a la izquierda o no responden a una suma, están guardados como texto y hay que convertirlos a número en Excel antes de traerlos aquí. Es preferible arreglarlo en origen que arreglarlo en la consulta con un reemplazo de comas por puntos, que es el parche que después nadie documenta.

Una columna de códigos postales con cinco mil entradas numéricas y después un `28001 (antiguo)` es una columna de texto, y las entradas numéricas también se escriben como texto. Lo mismo ocurre con una columna de cantidades que tenga un `n/d` dentro, o con una de referencias donde alguien escribió una nota.

La alternativa tentadora —tomar el tipo de la primera fila y anular lo que no encaje— produce un archivo válido, que carga sin protestar y que ha borrado en silencio los valores que no cabían. Nadie lo descubre hasta que un recuento sale corto. Una columna de texto es visible, se convierte con una sola expresión y jamás pierde una fila. Si una columna llega como texto y esperabas números, la manera más rápida de saber por qué es consultar los valores que fallan al convertir: suele ser un puñado de filas con una nota al pie, un total, un símbolo de unidad o la palabra «ninguno», y cada una de ésas es un hecho real sobre la hoja.

Parquet tiene un tipo entero de 64 bits y aquí no se usa. Los valores llegan desde el libro como números de JavaScript, que conservan 53 bits de precisión entera, así que cualquier cosa fuera del rango de 32 bits ya ha pasado por ese límite antes de que el escritor la vea.

Escribirla como INT64 prometería una exactitud que el número ya no tiene, y el fallo sería invisible: una referencia de pedido desplazada en una unidad sigue pareciendo una referencia de pedido. DOUBLE es la declaración honesta de lo que realmente se sabe. Si tus datos tienen identificadores muy largos —un número de cuenta, un IBAN sin espacios, un código de barras—, guárdalos como texto en la hoja antes de convertir y llegarán como columna de cadenas, intactos.

Lo que una hoja de cálculo guarda en una celda de fecha es un número y un formato de presentación. La lectura de esta conversión toma los valores en crudo y escribe lo que encuentra, sin aplicar el calendario y sin producir un tipo de marca de tiempo en el Parquet: no hay semántica de fecha en la salida.

Qué aparece exactamente en esa columna es lo primero que hay que mirar después de cargar el archivo, y esta página no te lo va a adivinar. Carga el resultado, imprime las cinco primeras filas de la columna de fechas y compáralas con la hoja. Con eso sabrás en un minuto qué expresión necesitas para aplicar el calendario en el sitio donde consultas, que es el sitio correcto para aplicarlo: reformatear el libro a texto antes de convertir cambia un problema de aritmética por uno de análisis sintáctico.

No hace falta nada especial. DuckDB lee el archivo directamente en una cláusula FROM, pandas lo abre con una sola llamada, y Spark y los motores construidos encima lo tratan como formato de tabla nativo. El archivo empieza y termina con los cuatro bytes PAR1, que es como cualquiera de ellos lo reconoce antes de leer el pie.

Lo primero que conviene mirar después de cargarlo son los tipos deducidos, no las diez primeras filas. Una columna que esperabas numérica y llegó como texto te está diciendo algo cierto sobre la hoja, y sale mucho más barato enterarse ahora que después de haberla unido a otras tres. Convertir el tipo al insertar en una tabla es una expresión por columna y es lo normal. Lo que no conviene es convertir a ciegas: una columna que llegó como texto por un motivo producirá nulos en silencio donde los valores no encajen, que es exactamente el fallo que el escritor se negó a cometer en tu nombre.

Parquet contiene una tabla con un esquema, así que un libro de seis pestañas no cabe en un solo archivo sin inventar una fusión que nadie ha pedido. Tomar la primera hoja es la única elección que no inventa nada.

Para un libro donde importan varias hojas, conviértelas por separado y deja que el motor de consulta las vuelva a juntar: leer varios archivos a la vez y filtrarlos al cargar es justo aquello para lo que esos motores están hechos. Además mantiene los esquemas honestos. Tres hojas que en el libro parecen iguales suelen diferir en una columna o en un tipo, y meterlas a la fuerza en un archivo obliga a decidir cuál de esas diferencias se borra, decisión que es mucho mejor tomar explícitamente en una consulta que implícitamente en un conversor.

Las dos mitades corren en tu navegador: el lector de la hoja y el escritor de Parquet son bibliotecas que esta página carga bajo demanda, y ninguna petición lleva el libro a ninguna parte. Para una exportación de clientes, de nóminas o de facturación eso suele ser el factor que decide, porque subirla a un conversor es precisamente lo que la política de la casa prohíbe.

El límite real es la memoria y no un plan de pago. La hoja se lee en filas, se transpone en columnas y se escribe, así que la tabla entera existe a la vez: decenas de megas son rutina y unos cuantos cientos es donde una pestaña empieza a sufrir. El tope formal son 100 MB por archivo. Pasado ese punto, la herramienta correcta es un script con un lector en flujo, y decirlo por adelantado es mejor que fallar a mitad de un archivo grande.

Parquet es una mala elección para cualquier cosa que tenga que mirar una persona. Es binario, no se edita y un compañero sin las herramientas adecuadas no puede abrirlo en absoluto. Si el archivo va a un ser humano, mándale una hoja de cálculo o un CSV.

También es el destino equivocado para una carga puntual, donde el coste de escribirlo no compra nada. Elige Parquet cuando los mismos datos se vayan a consultar repetidamente, a cruzar con otras tablas y a conservar, que es exactamente cuando el tamaño y las columnas tipadas empiezan a pagarse solos.