Convertir XLSX en Parquet

Toutes les autres destinations d’un classeur stockent un enregistrement après l’autre. Parquet stocke un champ après l’autre : les cinquante mille dates de commande ensemble, puis les cinquante mille villes, puis les montants. Ce n’est pas une préférence de format, c’est la raison d’être du format.

La conséquence apparaît la première fois que vous l’interrogez. Une question qui lit deux champs sur deux cents touche deux colonnes d’octets plutôt que chaque ligne, et une colonne de valeurs répétées se compresse bien plus fort que les mêmes valeurs éparpillées dans les lignes. Convertir un tableur vers ce format est donc une transposition autant qu’une sérialisation, et le travail intéressant est de décider du type de chaque colonne. Le fichier porte aussi son propre schéma dans un pied de page, ce qui explique qu’un moteur de requête vous donne les noms et les types de colonnes sans lire une seule ligne — ce qu’aucun fichier délimité ni aucun tableur ne peut faire.

Le type est déduit des valeurs plutôt que déclaré, parce qu’un tableur ne porte pas de schéma. Chaque colonne est examinée entièrement : si toutes les valeurs non vides sont des booléens, elle devient BOOLEAN ; si ce sont tous des entiers dans la plage 32 bits, elle devient INT32 ; si ce sont des nombres mais pas tous des entiers, ou pas tous assez petits, elle devient DOUBLE ; tout le reste devient STRING.

Les valeurs nulles ne participent pas. Une colonne de nombres avec des trous reste une colonne numérique, les trous étant écrits comme null, ce que le moteur de requête attend. L’inférence lit la colonne entière avant de décider plutôt que d’échantillonner, ce qui coûte une passe sur les données et supprime une catégorie entière de surprises. L’échantillonnage est ce que font la plupart des outils, et c’est pourquoi un chargement qui marche sur un fichier de test échoue en production : les mille premières lignes étaient propres et la quarantième millième ne l’était pas. Tout lire est plus lent et ne peut pas se tromper de cette manière précise.

Une colonne de codes postaux qui commence par cinq mille entrées numériques puis contient SW1A 1AA est une colonne de chaînes, et les entrées numériques sont aussi écrites comme chaînes. Il en va de même pour une colonne de quantités qui contient « n/a », ou une colonne d’identifiants où quelqu’un a tapé une note.

L’alternative tentante — prendre le type de la première ligne et passer à null ce qui ne correspond pas — produit un fichier valide, qui se charge sans avertissement, et qui a silencieusement supprimé les valeurs qui ne rentraient pas. Personne ne le découvre avant qu’un compte revienne trop court. Une colonne de chaînes est visible, convertible en une expression, et ne perd jamais une ligne en silence. Si une colonne arrive en texte et que vous attendiez des nombres, le moyen le plus rapide de savoir pourquoi est d’interroger les valeurs qui refusent la conversion. C’est en général une poignée de lignes avec un renvoi en bas de page, un total, un symbole d’unité parasite ou le mot « aucun », et chacune de ces lignes est un fait réel sur le tableur.

Parquet possède un type entier 64 bits et il n’est pas utilisé ici. Les valeurs arrivent du classeur comme des nombres JavaScript, qui portent 53 bits de précision entière, donc tout ce qui se trouve déjà dans le pipeline est passé par cette limite avant que l’encodeur ne le voie.

Écrire une telle valeur en INT64 promettrait une exactitude que le nombre n’a plus, et la défaillance serait invisible : une référence de commande décalée d’un ressemble à une référence de commande. DOUBLE est la déclaration honnête de ce qui est réellement connu. Si vos données contiennent des identifiants au-delà de neuf quadrillions, stockez-les en texte dans le tableur avant de convertir et ils arriveront comme une colonne de chaînes, intacts.

Sur une feuille de cinquante mille lignes et six colonnes — un identifiant de commande, un code produit, une ville, une quantité, un prix et un drapeau — le fichier Parquet est arrivé à 301 Ko. La même donnée pesait environ 4,3 Mo en .xlsx et 1,8 Mo écrite en texte séparé par des tabulations.

L’écart n’est pas seulement la compression. Les valeurs répétées en stockage par colonne sont conservées une fois et référencées, ce qui explique que les colonnes ville et code produit ne coûtent presque rien, alors qu’une colonne de texte libre unique réduirait considérablement la différence. Attendez-vous à une économie importante sur des données opérationnelles et modeste sur une feuille qui contient surtout de la prose distincte. L’économie se cumule quand le fichier est interrogé plutôt que simplement stocké, parce qu’une requête qui lit deux colonnes sur six paie deux colonnes. Face à un tableur, où la seule façon de répondre à une question est de charger le classeur entier, c’est la différence que le format a été conçu pour faire.

Ce qu’un tableur stocke dans une cellule de date est un nombre et un format d’affichage. La conversion écrit le nombre, donc le 1er janvier 2024 devient 45292, compté à partir de fin décembre 1899, et la colonne est typée comme un entier comme n’importe quel autre nombre entier.

Cela signifie qu’il n’y a pas de sémantique d’horodatage dans la sortie, et qu’un moteur de requête traitera la colonne comme ce qu’elle est : un entier. Appliquer le calendrier est une expression d’une ligne à l’endroit où vous interrogez — ajouter le nombre de jours à la date d’origine — et le faire là vaut mieux que reformater le tableur en texte d’abord, ce qui remplace un problème d’arithmétique par un problème d’analyse.

Rien de spécial n’est requis. DuckDB lit le fichier directement dans une clause FROM, pandas le lit avec un seul appel, et Spark ainsi que les moteurs de requête bâtis dessus le traitent comme un format de table natif. Le fichier commence et se termine par les quatre octets PAR1, ce qui est la manière dont chacun d’eux le reconnaît avant de lire le pied de page.

La première chose à faire après chargement est de regarder les types inférés plutôt que les dix premières lignes. Une colonne à laquelle vous vous attendiez à être numérique et qui arrive comme texte vous dit quelque chose de vrai sur le tableur, et il est bien moins cher de l’apprendre maintenant qu’après que le fichier a été joint à trois autres. Convertir au moment de l’entrée dans une table est une expression par colonne et c’est la chose normale à faire. Ce qu’il ne faut pas faire, c’est convertir à l’aveugle : une colonne qui passe en texte pour une raison produira silencieusement des null là où les valeurs ne rentraient pas, ce qui est exactement la défaillance que l’encodeur a refusé de commettre à votre place.

La conversion lit la première feuille du classeur. Parquet contient une table avec un schéma, donc un classeur à plusieurs feuilles ne peut pas être représenté dans un seul fichier sans inventer une fusion que personne n’a demandée, et prendre la première feuille est le seul choix qui ne le fait pas.

Pour un classeur où plusieurs feuilles comptent, convertissez chacune séparément et laissez le moteur de requête les rassembler. C’est l’arrangement pour lequel ces moteurs sont conçus — plusieurs fichiers, lus ensemble, filtrés au chargement — et cela produit un meilleur résultat qu’une feuille unique avec une colonne discriminante boulonnée. Cela maintient aussi les schémas honnêtes. Trois feuilles qui se ressemblent dans un classeur diffèrent souvent d’une colonne ou d’un type, et les forcer dans un seul fichier signifie décider quelles différences effacer — une décision mieux prise explicitement dans une requête qu’implicitement par un convertisseur.

Les deux moitiés tournent dans votre navigateur : le lecteur de tableur et l’encodeur Parquet sont des bibliothèques chargées à la demande par cette page, et aucune requête ne transporte le classeur. Pour un export de données client ou financières, c’est souvent le facteur décisif, parce que le téléverser vers un convertisseur serait précisément la partie que votre politique interdit.

La limite est la mémoire plutôt qu’un palier de plan. La feuille est lue en lignes, transposée en colonnes puis écrite, donc toute la table existe à la fois ; quelques dizaines de mégaoctets sont une utilisation normale et quelques centaines de mégaoctets sont le moment où un onglet de navigateur commence à forcer. Au-delà, un script avec un lecteur en flux est le bon instrument, et le dire vaut mieux que d’échouer au milieu d’un gros fichier.

Parquet est un mauvais choix pour tout ce qu’une personne doit regarder. Il est binaire, il n’est pas éditable, et un collègue sans les bons outils ne peut pas l’ouvrir du tout — le registre marque son support comme inégal pour exactement cette raison. Si le fichier va à un être humain, envoyez un tableur ou un CSV.

C’est aussi la mauvaise cible pour un chargement ponctuel, où le coût d’écriture n’achète rien : le NDJSON entre en flux dans un travail d’ingestion et c’est terminé. Choisissez Parquet quand les mêmes données seront interrogées à plusieurs reprises, jointes à d’autres tables, et conservées — ce qui est précisément le moment où la taille et les colonnes typées commencent à se payer d’elles-mêmes.