Convertir TSV a Parquet

Buena parte de la salida científica y analítica va separada por tabuladores por convención y no por elección: matrices de expresión, resúmenes de variantes, ficheros de anotación, registros de instrumental, exportaciones de plataformas de búsqueda y publicidad. Se eligió el tabulador porque las columnas descriptivas están llenas de comas y de puntos y comas, y lleva treinta años sirviendo como formato de transporte.

Es un mal formato para calcular una y otra vez. Cada lectura analiza cada byte, cada herramienta vuelve a deducir los tipos y los deduce de forma ligeramente distinta, y una tabla que vas a filtrar cien veces paga el coste de análisis cien veces. Convertirla una sola vez a un fichero columnar tipado mueve ese trabajo al principio, y ese es el argumento entero para hacerlo.

Una columna de Parquet tiene un solo tipo para todos sus valores. El escritor de esta página lee la columna completa antes de decidir, y la regla es deliberadamente inflexible: si todos los valores no vacíos son booleanos, la columna es BOOLEAN; si todos son enteros dentro del rango de 32 bits, es INT32; si todos son números, es DOUBLE; y si uno solo no es ninguna de esas cosas, la columna entera pasa a ser texto.

Las tablas de análisis están llenas de valores que no son ninguna de esas cosas. «NA» es la convención de R y aparece en casi todo lo que R ha tocado. Un punto suelto es la marca de campo ausente en los formatos de genómica. Un guion, «ND», «s/d», «n/d», «NULL» o dos guiones aparecen según el programa que escribiera el fichero. Cualquiera de ellos en cualquier fila convierte una columna de diez millones de números en una columna de diez millones de cadenas.

Antes de buscar marcas raras, mira el separador decimal. La deducción reconoce números escritos con punto decimal, que es lo que producen las herramientas anglosajonas; un valor escrito 12,5 no encaja en ese molde y se queda como cadena. Una columna entera de importes, medidas o porcentajes exportada desde una hoja de cálculo con configuración regional española llega a Parquet como STRING sin que nada avise.

Esto casi nunca sale en la documentación en inglés porque allí el problema no existe. Aquí es la primera comprobación que hay que hacer con cualquier tabla que venga de un portal de datos abiertos, de un organismo público o de una exportación hecha en un equipo configurado en español. La solución está en el origen: sustituir la coma por el punto en las columnas numéricas antes de convertir, con cuidado de no tocar las columnas de texto donde la coma es puntuación de verdad.

La alternativa tentadora es tipar la columna por la primera fila, o por las mil primeras, y escribir como nulo todo lo que no encaje. La mayoría de las herramientas hacen exactamente eso. Produce un fichero válido, que carga sin ninguna advertencia y que ha borrado en silencio todas las filas donde aparecía la marca.

Nadie descubre eso hasta que un recuento sale corto, y para entonces el fichero suele estar ya unido a otros tres. Una columna de texto es ruidosa: se ve en cuanto miras el esquema, se convierte con una sola expresión y la conversión te dirá exactamente qué valores no ha podido transformar. Negarse a adivinar te cuesta un casteo y te ahorra una clase de error muy difícil de encontrar después.

Se hace con una orden. Extraer una columna, ordenar sus valores únicos y mirar los primeros cincuenta deja la marca a la vista de inmediato. Hacerlo con todas las columnas de una tabla ancha es un bucle; hacerlo con las tres columnas sobre las que de verdad filtras suele bastar.

El arreglo va en el fichero de origen y no en el conversor: sustituye la marca por un campo genuinamente vacío. Los nulos quedan fuera de la deducción de tipo, así que una columna de números con huecos reales llega como columna numérica con nulos dentro, que es lo que un motor de consultas espera y lo que un promedio o un filtro por rango pueden usar. Una sustitución a nivel de campo sobre una sola columna son unos segundos de trabajo y cambia el esquema del fichero resultante.

Las tablas anchas son el caso en que la disposición columnar gana más. Una matriz de expresión con una fila por gen y una columna por muestra, o una tabla de características con una columna por medida, se guarda una columna detrás de otra en lugar de una fila detrás de otra, así que una consulta que nombra cuatro columnas lee los bytes de cuatro columnas y no toca el resto.

Contra un fichero de tabuladores la misma consulta tiene que leer cada byte de cada fila para localizar los campos que quiere, porque la única manera de encontrar el decimoséptimo campo de una línea es contar diecisiete tabuladores. Esa diferencia no se diluye cuando la tabla crece: se ensancha. Y es también el motivo de que el pie del fichero importe más en una tabla ancha, porque permite enumerar dos mil nombres de columna y sus tipos sin leer un solo dato.

El escritor emite INT32 solo cuando todos los valores de la columna caben en 32 bits. Más allá de ahí la columna pasa a DOUBLE y no a INT64, cosa que sorprende a quien sabe que Parquet tiene un tipo entero de 64 bits.

La razón es honestidad sobre lo que llegó. Los valores pasan por números de JavaScript en el camino de entrada, y esos números llevan 53 bits de precisión entera, de modo que una coordenada genómica o un identificador de evento por encima de ese punto ya venía redondeado antes de que el escritor lo viera. Declararlo INT64 prometería una exactitud que el valor ya no tiene, y un identificador que vuelve con una unidad de diferencia se parece exactamente a un identificador correcto. Si una columna guarda identificadores largos y no cantidades, déjala como texto en el origen: un prefijo no numérico basta.

La fila de cabecera aporta los nombres, con sus espacios, sus tildes, sus paréntesis y sus mayúsculas. Nada se renombra ni se normaliza, porque un conversor que reescribiera en silencio los nombres de columna haría imposible cuadrar la salida con el fichero del que salió.

Eso tiene una consecuencia aguas abajo: consultar una columna llamada «Importe total (€)» requiere entrecomillarla en casi cualquier motor. Si el fichero va a vivir dentro de código que alguien mantendrá, renombrar las columnas una vez en la propia cabecera antes de convertir es más barato que arrastrar comillas por todas partes. Los nombres quedan escritos en el pie junto con los tipos, así que después son inspeccionables sin leer datos.

Muchas páginas te dirán con qué algoritmo se comprime cada columna del Parquet que producen. Nosotros no pasamos ninguna opción de compresión a la biblioteca que escribe el fichero, así que ese detalle es su valor por omisión y no una decisión nuestra. Afirmar un nombre de algoritmo aquí sería copiar una expectativa en lugar de describir el código.

Lo que sí se puede decir es de dónde viene el tamaño en una tabla de análisis. Las columnas cuyos valores se repiten —un identificador de muestra, una categoría, una provincia, una hebra— se comprimen extraordinariamente bien en cualquier configuración razonable, mientras que una columna de medidas continuas no. Saber cuáles de tus columnas son de cada tipo predice bastante bien el tamaño que vas a obtener.

Un motor como DuckDB lee el fichero en su sitio: basta nombrar la ruta en la consulta, sin paso de importación ni definición de tabla. Describir el esquema antes de nada es el primer movimiento sensato y la manera más rápida de encontrar una columna que ha llegado como texto.

Las bibliotecas de análisis en Python lo leen en una llamada y los motores distribuidos lo tratan como formato de tabla nativo. En los tres casos, la reacción correcta ante una sorpresa es consultar los valores conflictivos y no castear a ciegas: un casteo anula lo que no encaje, que es precisamente el fallo que el escritor se negó a cometer en tu nombre. El fichero empieza y termina con cuatro bytes que sirven de firma, y así es como cada uno de ellos lo reconoce antes de leer el pie.

Las dos mitades se ejecutan en esta página: el analizador de texto delimitado es JavaScript corriente y el escritor de Parquet es una biblioteca que se carga bajo demanda. No se sube nada, lo cual importa con un conjunto de resultados sin publicar, una tabla bajo embargo o mediciones que no son tuyas para distribuir.

La tabla entera se sostiene en memoria mientras se transpone a columnas, así que decenas de megabytes se convierten sin ceremonia y a partir de unos centenares la pestaña empieza a sufrir; el tope duro por archivo son 100 MB. Una matriz de varios gigabytes pertenece a un motor de consultas que lea el fichero desde disco y escriba Parquet en una sola sentencia. Decirlo es más útil que dejar que una conversión muy grande falle a dos tercios del camino.

Consérvalo si una persona o un guion tienen que leerlo como texto. Parquet es binario, no se edita a mano y su soporte fuera del mundo analítico es irregular: un colaborador sin las herramientas adecuadas no puede abrirlo, y «instálate antes un motor de consultas» es una mala respuesta para quien solo quería mirar una tabla.

Consérvalo también si el fichero es un material publicado. Las tablas delimitadas son lo que aceptan las revistas, los repositorios y los portales de datos abiertos, y seguirán siendo legibles sin ninguna dependencia dentro de veinte años. Convierte a Parquet la copia de trabajo —la que filtras, cruzas y agregas a diario— y guarda el original como documento de referencia.