Convertir Parquet en TSV

C’est un conteneur binaire. `head` dessus affiche les quatre octets PAR1 puis un écran de bruit, `grep` n’y trouve rien de fiable parce que les valeurs sont compressées et encodées par dictionnaire, et `wc -l` rapporte un nombre sans rapport avec le nombre de lignes. Le fichier est conçu pour être lu par un moteur, et si la machine n’a pas de moteur, le fichier est opaque.

C’est la situation à laquelle cette conversion s’adresse : un extrait Parquet sur un serveur, un portable sans droits administrateur, un conteneur avec rien d’installé, ou un fichier que quelqu’un a envoyé avec une question qui demande une réponse dans les deux minutes. Le transformer en lignes est le chemin le plus court pour pouvoir commencer à y répondre.

Les valeurs dans un extrait de données sont pleines de virgules — adresses, noms de produits, texte libre, nombres écrits dans une locale européenne. Un fichier séparé par virgules doit entourer tout cela de guillemets, et chaque consommateur du fichier doit implémenter correctement citations, guillemets échappés et sauts de ligne avant de pouvoir trouver une limite de colonne.

Les tabulations sont quasi absentes de ce type de données, donc le délimiteur et le contenu cessent d’être en concurrence. Après cette conversion, `cut -f3` trouve la troisième colonne, `awk -F"\t"` la trouve aussi, et `sort -t$'\t' -k2` trie sur la deuxième. Rien n’a à analyser ; les choses n’ont qu’à séparer. C’est toute la différence de fiabilité entre les deux délimiteurs, et c’est pourquoi un vidage tabulé peut être traité correctement par une commande shell d’une seule ligne.

Une tabulation dans une valeur est l’exception. Elle est plus rare dans des données venues d’un fichier Parquet que dans des données venues d’un tableur, mais cela arrive — les champs en texte libre portent ce qui y a été collé à l’origine. Quand cela se produit, le convertisseur écrit ce champ entouré de guillemets, parce que l’alternative est une ligne qui gagne silencieusement une colonne.

Cette sortie est correcte et un vrai parseur la gère. `cut -f` non : il compte les caractères tabulation et n’a jamais entendu parler d’un guillemet, donc à partir de cette ligne il voit un champ de trop et tout ce qui suit est décalé d’un. Si un pipeline produit des résultats décalés sur quelques lignes parmi un million, `grep -c '"' output.tsv` vous dira en une seconde si c’est la raison.

Une colonne d’horodatage est écrite comme une chaîne ISO 8601 — `2024-03-11T09:30:00.000Z` — ce qui est la seule réponse sensée dans un format sans type date. Elle a une propriété qui compte beaucoup dans un shell : elle se trie chronologiquement avec un tri lexicographique ordinaire, parce que les champs vont du plus significatif au moins.

`sort -k4` sur une colonne de date fait donc ce que vous vouliez, `uniq -c` sur les dix premiers caractères compte les lignes par jour, et un filtre sur une plage est une comparaison de chaînes. Rien de tout cela ne marche sur une date en format local, et rien ne marche sur un nombre epoch sans arithmétique. C’est un des rares cas où convertir en texte rend une opération plus facile plutôt que plus dure.

Parquet porte nativement listes, structures et maps. Une ligne de texte ne le fait pas, donc une colonne imbriquée est écrite en JSON dans son champ : une liste arrive comme `["a","b"]`, une structure comme un objet avec les noms de ses membres.

C’est volontairement le format que quelque chose d’autre peut lire. `cut -f5 output.tsv | jq ".[0]"` tire le premier élément de chaque liste, et l’imbrication survit au passage plutôt que d’être aplatie en colonnes dont il faudrait ensuite deviner les noms. Comme le champ ne contient ni tabulation ni retour à la ligne, aucun guillemet n’est ajouté autour et le pipeline reste simple. Les colonnes binaires sans annotation texte sont écrites en hexadécimal minuscule pour une raison connexe : c’est réversible, cela ne contient pas de délimiteur, et personne ne le confondra avec du texte.

Un null est écrit comme un champ vide. Chaque ligne garde le même nombre de tabulations, donc le fichier reste rectangulaire et les outils positionnels restent alignés, ce qui est le comportement qu’il faut.

Cela efface aussi une distinction que le fichier source faisait soigneusement. Parquet enregistre la nullabilité par colonne et distingue un null d’une chaîne vide ; dans la sortie, les deux sont les mêmes zéro caractères entre deux tabulations. Si vous comptez les valeurs manquantes, `awk -F"\t" '$3==""'` compte les deux ensemble et aucune commande shell ne peut les séparer à nouveau. Là où cela compte, obtenez le compte depuis la source avec un moteur de requête plutôt que depuis le texte.

Tout ce que le fichier Parquet savait de ses colonnes — le type de chacune, le nombre de lignes, les statistiques par colonne — vit dans un pied de page, et rien de tout cela ne survit dans un fichier tabulé. La sortie a une ligne d’en-têtes et après ce sont des caractères.

Si vous avez un moyen de lire le schéma, lisez-le avant de convertir et notez-le. `DESCRIBE SELECT * FROM "file.parquet"` dans DuckDB l’imprime en une instruction. Là où vous n’avez rien du tout, le texte lui-même est la seule preuve disponible, et le geste sensé est de vérifier quelques valeurs distinctes par colonne avec `cut -f2 | sort -u | head` plutôt que de supposer qu’une colonne de chiffres est une quantité.

Parquet est compressé et encodé par dictionnaire, donc le texte dans lequel il se déploie est couramment plusieurs fois la taille du fichier et souvent bien davantage. Une colonne de codes de statut répétés ne coûtait presque rien dans la source et coûte une copie complète par ligne dans la sortie.

Cela vaut la peine d’être estimé avant de convertir un fichier que vous n’avez pas regardé, parce que la table déployée est gardée en mémoire pendant la conversion. Un extrait de cent mégaoctets peut produire beaucoup plus que cent mégaoctets de texte, et le plafond ici arrive plus vite que la taille sur disque ne le suggère.

Le lecteur Parquet est une bibliothèque chargée à la demande par cette page et l’écriture est du JavaScript ordinaire. Aucune requête ne transporte le fichier, donc un extrait pris au milieu d’une plateforme — d’ordinaire la version non agrégée, non masquée — ne devient pas une copie sur le serveur de quelqu’un d’autre pour être lu.

Il n’y a pas de file et pas de compte, et le plafond est de 100 Mo par fichier. Pour un fichier assez gros pour être un problème, la réponse est un moteur de requête plutôt qu’un convertisseur plus grand, et c’est de toute façon une meilleure réponse parce qu’il permet de ne prendre que les colonnes qui vous intéressent.

Si vous pouvez installer quelque chose, installez DuckDB. Il lit le fichier Parquet sur place sans étape d’import, imprime le schéma en une instruction, répond à la question que vous aviez vraiment avec une clause WHERE, et ne matérialise jamais la table entière. Convertir en texte est strictement moins bon à chaque fois que cette option existe.

Cette conversion est pour quand elle n’existe pas : une machine verrouillée, le portable d’un collègue, un fichier arrivé par e-mail, une question de cinq minutes qui ne justifie pas une installation. C’est aussi le bon choix quand la destination est vraiment un pipeline texte — un script awk existant, un diff contre le vidage d’hier, un collage dans un outil qui prend du tabulé en entrée.