Convertir CSV en Parquet

Tout ce qu’un CSV sait de lui-même est une ligne d’en-tête, et une ligne d’en-tête est une liste de noms. Elle ne peut pas dire que `montant` est un décimal, que `actif` est un booléen, ou que `id_client` ne doit jamais être traité comme de l’arithmétique. Chaque outil qui lit le fichier doit le redécouvrir, et chaque outil le découvre légèrement différemment, ce qui explique pourquoi le même extrait se charge de trois façons dans trois endroits.

Un fichier Parquet se termine par un pied de page qui contient le schéma, le nombre de lignes et des métadonnées par colonne. Un moteur de requête lit le pied de page en premier — quelques kilo-octets à la fin du fichier — et peut vous donner les noms et types de colonnes avant de toucher une seule ligne. C’est une propriété structurelle plus qu’une commodité : c’est ce qui rend le format sûr à remettre à quelqu’un qui n’était pas là quand il a été écrit.

Trois choses arrivent à chaque colonne sur le chemin et elles se composent. Les valeurs sont écrites sous leur forme binaire plutôt que comme du texte décimal, donc un nombre qui prenait onze caractères dans le CSV prend quatre octets. Chaque colonne est ensuite compressée pour son propre compte avec Snappy, qui est le codec par défaut ici. Et une colonne dont les valeurs se répètent est encodée en dictionnaire : les valeurs distinctes sont écrites une fois dans une page de dictionnaire, et la colonne elle-même devient une liste de petites références entières vers ce dictionnaire.

Le dictionnaire est appliqué par colonne et seulement quand il est rentable. L’encodeur échantillonne les mille premières valeurs et utilise un dictionnaire quand au plus la moitié sont distinctes, ce qui attrape les colonnes auxquelles on s’attend — pays, statut, code produit, devise — et saute une colonne de texte libre unique où un dictionnaire serait plus gros que les données. C’est pourquoi l’économie sur un extrait opérationnel est énorme et l’économie sur une table de phrases distinctes modeste, et cela vaut la peine de savoir dans laquelle des deux votre fichier se range avant de prédire le résultat.

Les lignes sont écrites en groupes plutôt qu’en un seul bloc, entre mille et cent mille lignes chacun, avec des pages à l’intérieur plafonnées à un mégaoctet. Chaque chunk de colonne au sein d’un groupe porte des statistiques, et ces statistiques sont ce qui transforme un balayage en un saut.

L’effet est celui qu’on désigne en disant que Parquet est plus rapide. Une requête filtrant sur une plage de dates lit le pied de page, voit qu’un row group contient des valeurs entièrement hors de la plage, et ne lit jamais ce groupe. Une requête nommant deux colonnes sur quarante lit la quantité d’octets de deux colonnes plutôt que de chaque ligne. Aucune de ces deux optimisations n’existe sur un CSV en aucun cas, parce qu’un CSV doit être lu depuis le début pour découvrir où quoi que ce soit se trouve.

Le type est inféré à partir des valeurs plutôt que déclaré, puisque la source n’a rien à déclarer. Chaque colonne est lue intégralement : tous booléens devient BOOLEAN, tous nombres entiers dans la plage 32 bits devient INT32, les nombres qui ne sont pas tous entiers ou pas tous assez petits deviennent DOUBLE, et tout le reste devient une chaîne. Les nulls ne participent pas, donc une colonne numérique avec des trous reste numérique.

Une seule valeur égarée rend toute la colonne texte, et c’est délibéré plutôt qu’une limitation. Prendre le type de la première ligne écrirait une colonne qui commence par des nombres comme colonne entière et transformerait chaque valeur non numérique ultérieure en null, produisant un fichier qui se charge sans se plaindre et qui a silencieusement supprimé des lignes. Une colonne en chaîne est visible, castable en une expression, et ne perd jamais rien. Si une colonne arrive en texte et que vous attendiez des nombres, interroger les valeurs qui refusent le cast vous montrera une poignée de lignes avec une note de bas de page, un total ou le mot « none » dedans — chacune est un fait vrai sur l’extrait.

La conversion lit le CSV avec inférence de type, donc `007` est le nombre 7 au moment où l’encodeur Parquet choisit un type de colonne, et la colonne INT32 qui en résulte est un fidèle reflet d’une valeur déjà fausse. Parquet prend le blâme pour cela régulièrement et ne le mérite pas : la perte se produit à l’étape d’analyse du texte, qui est la même étape que tout autre lecteur de CSV effectue.

Les colonnes à risque sont celles où l’arithmétique n’aurait pas de sens — codes postaux, références de pièces, numéros de téléphone, références de compte, tout ce qui est zéro-rempli. Si l’extrait est sous votre contrôle, exportez ces colonnes entre guillemets ou avec un préfixe, et elles arrivent en chaîne intactes. S’il ne l’est pas, vérifiez la colonne en sortie avant que le fichier ne soit écrit dans un endroit durable, parce que tout l’intérêt de passer à Parquet est que le fichier cesse d’être re-dérivé.

Sur une table de cinquante mille lignes et six colonnes — un identifiant, un code produit, une ville, une quantité, un prix et un drapeau — la sortie Parquet mesurait 301 Ko. Les mêmes données écrites en texte tabulé pesaient environ 1,8 Mo, et un CSV s’en distingue seulement par le caractère qui sépare les champs et par les guillemets autour des valeurs contenant des virgules.

C’est une réduction d’environ un facteur six, et c’est une attente raisonnable pour des données opérationnelles avec des codes et catégories qui se répètent. Un fichier dominé par du texte libre unique s’en tirera nettement moins bien, parce que ni le dictionnaire ni l’encodage binaire n’ont grand-chose à y faire. Les deux chiffres supposent aucune compression sur le CSV ; un CSV gzippé referme une partie de l’écart, au prix de devenir non interrogeable tant qu’il n’est pas décompressé en entier.

Aucune configuration n’est nécessaire. DuckDB lit le fichier directement dans une clause FROM, pandas le lit en un seul appel, et Spark le traite comme un format de table natif. Le fichier commence et finit par les quatre octets PAR1, ce qui est la façon dont chacun d’eux le reconnaît avant de lire le pied de page.

La première chose à regarder après le chargement est le schéma inféré plutôt que les dix premières lignes. Une colonne que vous attendiez numérique et qui arrive en texte vous dit quelque chose de vrai sur le CSV, et il est beaucoup moins coûteux de l’apprendre maintenant qu’après que le fichier a été joint à trois autres et copié dans un entrepôt. Faire le cast à l’entrée d’une table est une expression par colonne ; caster à l’aveugle est exactement la façon dont les lignes qu’on cherchait à ne pas perdre finissent par être perdues.

La table entière est tenue en mémoire : le CSV est parsé en lignes, les lignes transposées en colonnes, et les colonnes écrites. Des dizaines de mégaoctets se convertissent sans cérémonie, et au-delà le cent mégaoctets est le point où un onglet commence à peiner, ce qui est un vrai plafond et pas un niveau d’offre — il n’y a pas de téléversement et rien à payer.

Pour un extrait réellement gros, le bon instrument est DuckDB, qui lira le CSV depuis le disque et écrira le Parquet en une seule instruction sans jamais tenir le fichier entier. Le dire clairement est plus utile que de laisser une conversion de deux gigaoctets échouer aux deux tiers. Cette page est pour le fichier qui passe, ce qui est la plupart d’entre eux, et pour le cas où installer quelque chose n’est pas une option.

Les deux étapes tournent sur cette page : le parseur CSV et l’encodeur Parquet sont des bibliothèques chargées à la demande, et aucune requête ne transporte le fichier. Un CSV en partance pour une plateforme de données est très souvent l’artefact le moins redacté de tout le pipeline — le vidage brut avant les jointures et le masquage — et le téléverser vers un convertisseur est précisément l’étape qu’une politique de protection des données existe pour empêcher.

Cela retire aussi un étage de la conversation. Il n’y a pas de file, pas de nombre maximum de lignes et pas de compte, donc la seule question est de savoir si le fichier tient en mémoire, ce à quoi vous pouvez répondre en le regardant.

Parquet est une mauvaise destination pour tout ce qu’une personne doit lire. Il est binaire, non éditable, et un collègue sans le bon outillage ne peut pas l’ouvrir du tout — le registre enregistre son support comme parcellaire exactement pour cette raison. Si le fichier va à un être humain plutôt qu’à un moteur, envoyez le CSV ou un tableur.

C’est aussi la mauvaise cible pour un chargement qui arrive une fois puis est jeté : le coût d’écriture n’achète rien si le fichier n’est plus jamais interrogé, et un chargeur en masse lisant du texte délimité directement sera plus rapide de bout en bout. Choisissez Parquet quand les mêmes données seront balayées à plusieurs reprises, filtrées, jointes et conservées — c’est précisément à ce moment que les colonnes typées et les row groups sautés commencent à se payer eux-mêmes.