Convertir TSV en Parquet

Une grande part de la sortie scientifique et analytique est tabulée par convention plutôt que par choix : matrices d’expression, résumés d’appel de variants, tables d’annotation, journaux d’instrument, exports de plateformes analytiques et publicitaires. La tabulation a été choisie parce que les colonnes descriptives sont pleines de virgules et de points-virgules, et elle a servi de format de transport pendant trente ans.

C’est un mauvais format sur lequel calculer de manière répétée. Chaque lecture parse chaque octet, chaque outil redérive les types de colonnes et les dérive légèrement différemment, et une table qui sera filtrée cent fois paie le coût de parsing cent fois. Convertir une fois vers un fichier typé en colonnes déplace ce travail au début, ce qui est tout l’argument pour le faire.

Une colonne Parquet contient un seul type pour toutes ses valeurs. L’écriture ici lit la colonne entière avant de décider, et la règle est délibérément sans indulgence : si chaque valeur non vide est un booléen la colonne est BOOLEAN, si toutes sont des nombres entiers dans la plage 32 bits elle est INT32, si toutes sont des nombres elle est DOUBLE, et si une seule valeur n’est rien de tout cela la colonne entière est une chaîne.

Les tables d’analyse sont pleines de valeurs qui ne sont rien de tout cela. `NA` est la convention R et apparaît dans presque toute table que R a touchée. Un point `.` nu est la convention VCF et GTF pour un champ manquant. `-`, `n/a`, `NULL`, `#N/A` et `--` apparaissent tous selon le programme qui a écrit le fichier. L’un d’eux dans une ligne fait qu’une colonne de dix millions de nombres devient une colonne de dix millions de chaînes, et c’est pour cela qu’une colonne que vous savez numérique arrive en texte.

L’alternative tentante est de typer la colonne d’après la première ligne, ou d’après les mille premières, et d’écrire tout ce qui est en désaccord comme null. La plupart des outils font exactement cela. Cela produit un fichier qui est valide, qui charge sans avertissement, et qui a silencieusement supprimé chaque ligne où le marqueur est apparu.

Personne ne le découvre avant qu’un compte revienne court, et à ce moment-là le fichier a en général été joint à trois autres. Une colonne chaîne est bruyante : elle apparaît dès qu’on regarde le schéma, elle peut être castée en une expression, et le cast dira précisément quelles valeurs n’ont pas pu être converties. Refuser de deviner coûte un cast et épargne une classe d’erreur très difficile à trouver après. Ce compromis est fait délibérément et c’est la décision la plus lourde de cette conversion.

Cela prend une commande. `cut -f7 table.tsv | sort -u | head -50` imprime les valeurs distinctes de la septième colonne, et le marqueur sera évident parmi elles. Le faire sur chaque colonne d’une table large est une boucle ; le faire sur les trois colonnes sur lesquelles vous filtrez réellement suffit en général.

La correction est dans la source, pas dans le convertisseur : remplacez le marqueur par un champ vraiment vide. Les nulls sont exclus de l’inférence de type, donc une colonne de nombres avec de vrais trous arrive comme colonne numérique avec des nulls à l’intérieur, ce que le moteur de requête attend et sur quoi une moyenne ou un filtre de plage peut travailler. Un awk faisant une substitution au niveau du champ sur une colonne est quelques secondes de travail et change le schéma du fichier produit.

Les tables larges sont là où la disposition en colonnes gagne le plus. Une matrice d’expression avec une ligne par gène et une colonne par échantillon, ou une table de caractéristiques avec une colonne par mesure, est stockée une colonne après l’autre plutôt qu’une ligne après l’autre — donc une requête nommant quatre colonnes lit quatre colonnes d’octets et ne touche jamais au reste.

Contre un TSV la même requête doit lire chaque octet de chaque ligne pour trouver les champs qu’elle veut, parce que la seule manière de localiser le dix-septième champ d’une ligne est de compter dix-sept tabulations. Cette différence ne diminue pas quand la table grandit ; elle s’élargit. C’est aussi pourquoi le pied de page compte davantage sur une table large que sur une étroite : lister deux mille noms et types de colonnes sans lire aucune donnée est la différence entre un schéma qu’on peut inspecter et une ligne d’en-tête qu’il faut démonter avec `head -1 | tr`.

L’écriture n’émet INT32 que là où chaque valeur de la colonne tient dans la plage 32 bits. Au-delà la colonne devient DOUBLE plutôt que INT64, ce qui surprend les gens qui savent que Parquet a un type entier 64 bits.

La raison est l’honnêteté sur ce qui est arrivé. Les valeurs passent par des nombres JavaScript à l’entrée, qui portent 53 bits de précision entière, donc une coordonnée génomique ou un identifiant d’événement au-delà a déjà été arrondi avant que l’écriture ne le voie. Le déclarer INT64 promettrait une exactitude que la valeur n’a plus, et un identifiant qui revient à un près ressemble exactement à un identifiant. Si une colonne contient de grands identifiants plutôt que des quantités, gardez-la en texte dans la source — un préfixe non numérique suffit — et elle arrivera comme colonne chaîne, intacte.

Le pied de page du fichier contient les noms de colonnes tels que la ligne d’en-tête les a écrits, le type de chacune et le nombre de lignes, et les données elles-mêmes sont écrites en groupes de lignes entre mille et cent mille lignes avec des statistiques par colonne attachées. Chaque colonne est compressée seule avec Snappy, et une colonne dont les valeurs se répètent est stockée une fois comme dictionnaire avec de petites références entières dedans.

Pour une table d’analyse c’est cette dernière partie qui prend la taille. Une colonne chromosome, un identifiant d’échantillon, un brin, une catégorie — chacune a une poignée de valeurs distinctes répétées sur des millions de lignes, et chacune s’effondre à presque rien. Une colonne de mesures continues ne le fait pas, et c’est celle qui dominera le fichier produit. Savoir lesquelles de vos colonnes sont lesquelles est un bon prédicteur de la taille que vous obtiendrez.

DuckDB lit le fichier en place : une clause FROM nommant le chemin suffit, pas d’étape d’import ni de définition de table. `DESCRIBE SELECT * FROM "table.parquet"` imprime le schéma inféré, qui est la première chose à regarder et le moyen le plus rapide de trouver une colonne qui est passée en texte.

pandas le lit en un appel et Spark le traite comme format de table natif. Dans les trois, le bon réflexe après une surprise est d’interroger les valeurs fautives plutôt que de caster à l’aveugle — un cast mettra en null ce qui ne convient pas, ce qui est précisément l’échec que l’écriture a refusé de commettre à votre place. Le fichier commence et finit par les quatre octets PAR1, qui est comment chacun d’eux le reconnaît avant de lire le pied de page.

Les deux moitiés tournent sur cette page : l’analyseur de TSV est du JavaScript ordinaire et l’écriture Parquet est une bibliothèque chargée à la demande. Rien n’est téléversé, ce qui compte pour un jeu de résultats non publié, une table sous embargo, ou des mesures qui ne vous appartiennent pas pour les distribuer.

La table entière est tenue en mémoire pendant qu’elle est transposée en colonnes, donc quelques dizaines de mégaoctets se convertit sans cérémonie et quelques centaines est le point où un onglet de navigateur commence à peiner. Une matrice de plusieurs gigaoctets appartient à DuckDB, qui lira le TSV depuis le disque et écrira du Parquet en une seule instruction sans le tenir. Le dire est plus utile que de laisser une très grande conversion échouer aux deux tiers.

Gardez-le si une personne ou un script doit le lire comme texte. Parquet est binaire, n’est pas éditable, et le registre enregistre son support comme inégal — un collaborateur sans le bon outillage ne peut pas l’ouvrir du tout, et « installer DuckDB d’abord » est une pauvre réponse à quelqu’un qui voulait regarder une table.

Gardez-le aussi si le fichier est un artefact publié. Les tables tabulées sont ce que les journaux, les dépôts et les jeux de données publics acceptent, et elles seront toujours lisibles sans dépendance dans vingt ans. Convertissez en Parquet pour la copie de travail — celle que vous filtrez, joignez et agrégez de manière répétée — et gardez l’original comme la chose de référence.