Convertir Parquet en CSV

L’autre sens est évidemment une conversion : du texte devient des colonnes typées, et tout le monde s’attend à vérifier le résultat. Ce sens ressemble à un export — les données sortent, rien n’est compressé, rien n’est inféré — et cette impression est fausse d’une manière précise et coûteuse.

Parquet porte un schéma. Chaque colonne a un type déclaré, inscrit dans un pied de fichier, et un moteur de requête lit ce pied avant de lire une ligne. CSV porte une ligne d’en-têtes de noms et rien d’autre. La conversion déplace donc les valeurs intactes et jette tout ce que le fichier savait d’elles, et l’outil suivant devra inférer les types à partir du texte — différemment, selon toute vraisemblance, de ce que le fichier Parquet avait réellement déclaré.

Les booléens arrivent en `true` et `false`. Les entiers et les nombres à virgule flottante sont écrits dans leur forme décimale. Les chaînes de caractères sont écrites telles quelles, entre guillemets seulement quand la valeur contient une virgule, un guillemet double ou un saut de ligne. Les valeurs nulles deviennent des champs vides.

Rien de tout cela n’est réversible vers le schéma d’origine. Une colonne que Parquet déclarait entier 32 bits et une colonne qu’il déclarait double ressemblent toutes deux à des chiffres avec éventuellement un point, et une colonne booléenne et une colonne de texte contenant le mot « true » deviennent indiscernables. Si le CSV doit être chargé quelque part avec son propre schéma, récupérez d’abord les types de colonnes dans le fichier Parquet — `DESCRIBE` sous DuckDB les affiche en une ligne — et écrivez-les dans la définition du chargement plutôt que de laisser l’outil suivant deviner.

Une colonne d’horodatages est écrite comme une chaîne ISO 8601, et une valeur sort sous la forme `2024-03-11T09:30:00.000Z`. C’est la meilleure réponse possible dans un format sans type de date : le mois et le jour ne prêtent pas à confusion, le tri se fait correctement en texte brut, et toutes les bases de données et tous les langages la parsent sans qu’on leur précise un format.

C’est quand même du texte. Une colonne de dates dans le CSV ne répondra à l’arithmétique des dates que lorsque ce qui le lit saura que la colonne est une date, et un tableur qui ouvre le fichier appliquera sa propre interprétation. Si la destination est une base de données, déclarer la colonne comme horodatage au chargement coûte une ligne et préserve le sens ; si c’est une personne, la forme ISO au moins se lit de la même manière dans tous les pays.

Parquet a un type entier 64 bits, et JavaScript — qui est ce qui fait tourner la conversion — ne représente les nombres entiers de façon exacte que jusqu’à 53 bits. Une valeur au-delà ne peut pas être portée en tant que nombre sans perdre de la précision.

Plutôt que de l’arrondir, la conversion l’écrit en texte. Une référence de commande ou un identifiant de type snowflake apparaît donc dans le CSV avec chaque chiffre intact, et une colonne qui mélange des valeurs sûres et des valeurs non sûres aura des entrées qui étaient des nombres et d’autres qui étaient des chaînes, ce qui dans un CSV se ressemble de toute façon. L’alternative — l’arrondi — produit un fichier où un identifiant est décalé d’une unité, ce qui ressemble exactement à un identifiant valide et qui est le type d’erreur qui survit à plusieurs systèmes avant que quelqu’un s’en aperçoive.

Parquet porte nativement des données imbriquées : une colonne peut être une liste de chaînes, une structure à membres nommés, ou une map. Une cellule CSV ne porte qu’une valeur scalaire et n’a pas de syntaxe pour quoi que ce soit d’autre.

La conversion écrit ces valeurs en JSON dans le champ, de sorte qu’une colonne liste arrive sous la forme `["a","b"]` dans une cellule, entre guillemets parce que le JSON contient des virgules. C’est réversible si ce qui lit le fichier le parse, et c’est profondément gênant si la destination est un tableur ou un écran d’import. Les colonnes binaires reçoivent le même traitement pour la même raison : un tableau d’octets sans annotation textuelle est écrit en hexadécimal minuscule, ce qui est au moins réversible et clairement pas de la prose. Si le fichier comporte des colonnes imbriquées et que la destination est une personne, aplatissez-les ou supprimez-les dans une requête avant de convertir plutôt que d’envoyer un CSV plein de JSON embarqué.

Attendez-vous à plusieurs fois la taille, et parfois bien plus. Parquet écrit les valeurs sous forme binaire, compresse chaque colonne séparément, et stocke une colonne de valeurs répétées une seule fois sous forme de dictionnaire avec de petites références. Un CSV n’a rien de tout cela : chaque valeur est écrite caractère par caractère, sur chaque ligne, sans compression.

Les colonnes qui se sont le plus compactées à l’entrée sont celles qui se déploient le plus à la sortie. Un code pays répété sur un million de lignes n’a presque rien coûté dans le Parquet et coûte un million de copies dans le CSV. Cela mérite d’être su avant d’essayer d’envoyer le résultat par courriel, et il faut se rappeler que gzipper le CSV récupère une bonne partie de la différence si la destination l’accepte.

Le CSV est en UTF-8 sans marque d’ordre d’octet et avec un simple saut de ligne entre les lignes. C’est correct pour les scripts, les importateurs et la gestion de versions, et c’est ce qui fait que les noms accentués apparaissent en mojibake quand le fichier est ouvert par double-clic sous Windows, parce qu’Excel se rabat sur la page de code du système quand il n’y a pas de marque.

Importer via Données, Obtenir des données, À partir d’un fichier texte/CSV, et choisir UTF-8, l’évite, et vous donne en même temps l’occasion de marquer les colonnes d’identifiants comme texte — ce qui compte, parce qu’Excel appliquera sinon sa propre conversion numérique aux colonnes dont les types viennent d’être jetés. Si la destination est vraiment un tableur, convertir le Parquet en XLSX supprime la question de l’encodage et conserve les types.

Le lecteur matérialise chaque ligne avant que quoi que ce soit soit écrit, de sorte que la table entière se trouve en mémoire d’un coup. Quelques dizaines de mégaoctets de Parquet passent confortablement ; notez que c’est un format compressé, donc un fichier modeste peut se déployer en une grande quantité de texte et le plafond arrive plus tôt que la taille du fichier ne le suggère.

Pour un gros extraxt, le bon outil est DuckDB, qui lira le Parquet et écrira un CSV en une seule instruction sans rien garder en mémoire. Cela vous permet aussi de sélectionner les colonnes dont vous avez réellement besoin, ce qui est en général la meilleure réponse de toute façon — la plupart des demandes de « les données en CSV » se révèlent être des demandes de six colonnes du CSV.

Le lecteur Parquet est une bibliothèque chargée à la demande par cette page, et l’écriture est du JavaScript ordinaire, donc aucune requête n’emporte le fichier où que ce soit. Cela compte davantage ici que pour la plupart des conversions : un fichier Parquet est en général un artefact du milieu d’une plateforme de données, c’est-à-dire la version avant le masquage et l’agrégation.

Il n’y a pas de file, pas de compte et pas de limite de lignes autre que votre propre mémoire. La seule chose qui décide si la conversion marche, c’est de savoir si la table développée tient, ce que vous pouvez estimer à partir du nombre de lignes dans le pied de fichier.

Si le destinataire a la moindre outillerie de données moderne, envoyez l’original. DuckDB, pandas, Polars, R avec arrow, Spark et tous les entrepôts de données lisent Parquet directement, et le faire ainsi préserve les types, garde le fichier petit et supprime une étape entière au cours de laquelle quelque chose peut mal tourner.

Convertissez en CSV quand le destinataire ne peut vraiment pas — un collègue de la finance avec un tableur, une demande d’audit qui nomme le format, un écran d’import avec une liste fixe. Ces cas sont réels et fréquents, et cette conversion est pour eux. Ce qu’elle ne devrait pas être, c’est une habitude : chaque CSV produit à partir d’un Parquet est une copie qui a oublié ce qu’elle contenait.