Apache Parquet : comment le registre est rangé pour que la superintelligence lise toute l'entreprise

À sept heures du matin, on demande à un agent de planification quelles commandes ouvertes sont à risque parce que leurs articles font l’objet d’un blocage qualité. La réponse exige trois champs de l’enregistrement de commande, deux de l’enregistrement d’inspection et un de la fiche article, sur tout ce qui est ouvert dans l’entreprise. Il les lui faut avant que le planificateur s’installe, et il les lui faut à nouveau à neuf heures quand le plan change. Personne ne remarque la question tant qu’elle ne coûte rien. Tout le monde la remarque quand les agents qui la posent sont la raison pour laquelle les serveurs ont été remplacés.

La superintelligence lit le registre bien plus souvent que les personnes, et dans un système souverain elle le fait sur du matériel que l’entreprise paie. La disposition des fichiers qui portent le registre décide donc de quelque chose qui ressemble à un détail de performance et qui est en réalité un coût de fonctionnement de l’entreprise. Dans la couche Données de Hurukan, qui est en construction, le registre est conçu pour être stocké en Apache Parquet. Ce texte porte sur ce que ce choix apporte et sur ce qu’il exige.

Ce qu’il y a dans un fichier Parquet

Parquet stocke une table colonne par colonne. Un fichier contient un certain nombre de groupes de lignes ; chaque groupe de lignes contient un bloc par colonne ; chaque bloc est une suite de pages. Les métadonnées, dont le schéma et la position de chaque bloc, sont écrites à la fin, de sorte qu’un écrivain produit le fichier en une seule passe et qu’un lecteur ouvre d’abord le pied de fichier puis va droit aux octets dont il a besoin. La spécification est en version 2.14.0 (blog du projet, vérifié le 21 octobre 2026).

L’ordre des questions qu’un lecteur peut sauter est ce qui compte pour le coût :

Les colonnes qu’il n’a pas demandées. L’agent de planification veut six champs ; le fichier peut en contenir soixante. Les cinquante-quatre autres ne sont jamais lus.

Les groupes de lignes qui ne peuvent pas contenir la réponse. Chaque bloc de colonne porte des statistiques, la valeur minimale et maximale et le nombre de valeurs nulles. Si la question porte sur une famille d’articles et que le fichier est trié par article, la plupart des groupes de lignes sont exclus depuis le seul pied de fichier.

Les pages à l’intérieur d’un bloc. L’index de pages enregistre le minimum et le maximum par page et l’endroit où chaque page commence, de sorte que même dans un groupe de lignes retenu, le lecteur saute aux pages qui correspondent.

Les valeurs qui n’existent pas. Un filtre de Bloom par bloc de colonne répond à « ce numéro de commande est-il seulement ici » sans lire le bloc, ce dont a besoin une recherche ponctuelle sur un champ à forte cardinalité.

Ce qui reste est lu, et ce qui est lu est petit, parce que les colonnes se compressent bien : les valeurs répétées deviennent des entrées de dictionnaire, les séquences deviennent des comptes, et un codec général finit le travail. Les encodages et les codecs sont spécifiés, avec Snappy, GZIP, ZSTD et Brotli parmi les codecs et le plus récent LZ4_RAW qui remplace l’ancien cadrage LZ4.

Pourquoi la disposition est une question de souveraineté

Une plateforme managée cache le coût d’un registre mal rangé derrière une facture mensuelle. Sur l’infrastructure propre de l’entreprise, qui est l’endroit où vit un système d’exploitation souverain, le coût est visible sous forme de processeurs, de disques et de temps d’attente d’un agent. La même question posée à un registre trié sur le champ qu’elle filtre, avec des groupes de lignes de taille raisonnable et un encodage par dictionnaire là où les valeurs se répètent, touche une fraction des octets qu’elle toucherait autrement. La décision sur la disposition est une décision sur le nombre de questions que l’entreprise peut se permettre de laisser poser à ses agents. La conception d’ensemble, y compris la raison pour laquelle le registre est séparé de l’état courant des modules, est dans l’état courant et le registre.

Parquet est aussi le format que tous les moteurs lisent. Spark, Trino, DuckDB, Snowflake, BigQuery, Microsoft Fabric et les bibliothèques d’analyse l’ouvrent tous nativement. Un registre stocké en Parquet est un registre qu’un autre moteur pourra lire demain, ce qui est une moitié de la sortie ; l’autre moitié, les métadonnées de table au-dessus des fichiers, est le sujet de la piste d’audit est une table.

Les types dont le registre aura besoin

La spécification a grandi vers les formes qu’a réellement un registre d’entreprise. La version 2.11 a ajouté le type VARIANT pour les valeurs semi-structurées, ces attributs mal formés qui n’entrent pas dans une colonne fixe, ainsi que GEOMETRY et GEOGRAPHY pour les lieux ; la 2.12 a finalisé la manière dont les valeurs VARIANT peuvent être découpées en colonnes typées pour une lecture plus rapide ; la 2.14 a ajouté un type FILE (notes de version sur le blog du projet, définitions des types dans LogicalTypes, vérifié le 21 octobre 2026). Pour un registre qui doit tenir une adresse de livraison, un ensemble souple d’attributs d’inspection et une référence à un document numérisé sur la même ligne, ce n’est pas exotique. Ce qu’un moteur donné en lit doit être vérifié moteur par moteur, et la conception suppose que cette vérification est faite avant d’utiliser un type, pas après.

Ce que les agents proposent, ce que les personnes décident

Un agent qui observe les questions posées au registre est bien placé pour en améliorer la disposition : il peut voir que la plupart des filtres portent sur la famille d’articles, que les fichiers d’une table sont devenus petits et nombreux depuis qu’un connecteur écrit chaque minute, ou qu’une colonne a un dictionnaire qui ne tient plus. Dans la conception de Hurukan, ces observations deviennent des propositions, un ordre de tri, un plan de compactage, un changement de codec, avec les preuves jointes, et la proposition est enregistrée qu’elle soit acceptée ou non.

Ce qu’un agent ne décide pas, c’est combien de temps le registre garde chaque type de ligne, quelles lignes le quittent quand une personne demande la suppression de ses données, et si réécrire une année de fichiers, ce que sont à la fois le compactage et le retri, vaut le temps processeur cette semaine. Ce sont des décisions d’obligation et de coût, prises par une personne et écrites dans le registre comme toute autre.

Un test à faire aujourd’hui

Prenez le rapport ou le modèle de votre entreprise qui lit le plus d’historique. Découvrez deux choses : dans quel format ses fichiers source sont stockés, et si quelqu’un les a jamais triés selon quoi que ce soit. Si la réponse est CSV ou un export de base de données, chaque question lit chaque octet. Si les fichiers sont en colonnes mais non triés et jamais compactés, la première amélioration ne coûte rien et personne n’en est responsable. La page couche Données décrit où le registre se situe dans Hurukan ; la présentation montre ce qui le lit.