--- title: "Parquet et Avro : l'événement entre modules et le registre que lit la superintelligence" url: "https://hurukan.com/fr/blog/parquet-et-avro-l-evenement-et-le-registre" description: "Un événement circule entre modules comme une ligne sous contrat et repose dans le registre en colonnes. Pourquoi Avro porte le premier et Parquet le second." --- # Parquet et Avro : l'événement entre modules et le registre que lit la superintelligence 11 septembre 2026·5 min de lecture·La rédaction Un bureau logistique vu de derrière un opérateur à un pupitre debout : sur l'écran de gauche un seul formulaire abstrait bleu et gris, sur celui de droite une large table abstraite de fines colonnes, une fine bande LED bleue le long du bord du bureau, lumière du matin par une haute fenêtre Une réception de marchandises est confirmée au quai. Dans la même seconde, le module commerce doit savoir que le reliquat peut partir, la finance doit lancer le rapprochement de facture, et le module stocks doit faire bouger le niveau. Chacun veut la réception entière : fournisseur, article, quantité, lot, qui a confirmé. Trois mois plus tard, l’agent finance pose une autre question : à quelle fréquence les réceptions de ce fournisseur sont-elles arrivées incomplètes ces deux dernières années. Il veut deux colonnes sur un million de lignes, et il les veut en quelques secondes. Ce sont deux formes différentes du même fait. La première est une ligne qui voyage. La seconde est une colonne qui repose. Un système d’exploitation d’entreprise doit stocker les deux, et c’est une erreur de les stocker de la même manière. Dans la [couche Données](https://hurukan.com/fr/system/donnees) de Hurukan, qui est en construction, la conception veut qu’un événement entre modules soit porté par Apache Avro, et que le registre lu par la superintelligence soit rangé en Apache Parquet. Ce texte explique pourquoi cette séparation existe et ce que chaque côté paie. ## Deux questions, deux dispositions Un format de fichier décide de la façon dont un fichier range ses octets : si les enregistrements se suivent l’un après l’autre ou si toutes les valeurs d’un même champ sont réunies, comment ils sont compressés, et où vit la description de leurs types. **Disposition en lignes.** Chaque enregistrement est écrit en entier : tous les champs de cette réception, puis tous les champs de la suivante. Écrire un enregistrement coûte peu, en lire un coûte peu, et ne lire que la quantité sur un million de réceptions oblige à lire aussi tous les autres champs, parce qu’ils sont sur le chemin. **Disposition en colonnes.** Toutes les quantités sont ensemble, tous les identifiants de fournisseur sont ensemble. Une question sur deux champs touche deux bandes étroites du fichier et saute le reste. Écrire un seul enregistrement est malcommode, parce qu’un fichier doit être fermé avant qu’on puisse le lire ; les colonnes s’écrivent donc par lots. Avro est la disposition en lignes avec un schéma qui voyage avec les données. Parquet est la disposition en colonnes avec des statistiques qui permettent au lecteur de sauter ce dont il n’a pas besoin. Aucun des deux ne connaît l’autre, et aucun ne sait s’il appartient à une table ; c’est le travail d’un format de table au-dessus d’eux, décrit dans [l’état courant et le registre](https://hurukan.com/fr/blog/l-etat-courant-et-le-registre-deux-memoires). ## L’événement : une ligne sous contrat Quand la réception quitte le module stocks, c’est un message. Chaque module qui le lit doit s’entendre sur le sens des champs, et cet accord doit survivre au jour où quelqu’un ajoute un champ. [Avro](https://avro.apache.org/docs/1.12.0/specification/) transporte cet accord avec le message : le schéma est en JSON, l’enregistrement est une ligne binaire compacte, et la spécification fixe la manière dont un lecteur doté d’une version du schéma résout un enregistrement écrit avec une autre. Un champ que le lecteur ne connaît pas est ignoré. Un champ que le lecteur attend et que l’écrivain n’a pas envoyé prend la valeur par défaut du schéma du lecteur, ou bien la lecture échoue et le dit. La version courante est 1.12.2 ([blog du projet](https://avro.apache.org/blog/), vérifié le 21 octobre 2026). Dans un système où des agents étendent les modules, cette règle de résolution fait la différence entre un changement sûr et un changement qui arrête un module à trois heures du matin. La manière dont un changement de schéma passe par la proposition, le contrôle de compatibilité et l’approbation est le sujet de [Apache Avro : le contrat entre modules](https://hurukan.com/fr/blog/apache-avro-le-contrat-entre-modules). L’événement ne reste pas un événement. Une fois accepté par les modules qui en ont besoin, la même réception est écrite dans le registre, d’où elle sera lue d’une tout autre manière. ## Le registre : des colonnes que lit la superintelligence La superintelligence ne demande pas une réception. Elle demande un motif dans toutes les réceptions d’un fournisseur, toutes les commandes d’un trimestre, chaque non-conformité sur une révision d’article. Ce sont des questions sur quelques champs à travers beaucoup de lignes, et c’est pour cela que [Parquet](https://parquet.apache.org/docs/file-format/) est conçu : un fichier est divisé en groupes de lignes, chaque groupe en un bloc par colonne, chaque bloc en pages, avec un pied de fichier qui décrit où tout se trouve. Un lecteur demande deux colonnes et reçoit deux colonnes. Chaque groupe de lignes porte des valeurs minimale et maximale, si bien que des pans entiers du fichier sont sautés quand la question porte sur un seul fournisseur. La spécification du format est en version 2.14.0 ([blog du projet](https://parquet.apache.org/blog/), vérifié le 21 octobre 2026). L’enjeu pour un système souverain est le coût. Le registre vit sur l’infrastructure que l’entreprise choisit, et chaque question posée par la superintelligence se paie en octets lus et en temps processeur sur cette infrastructure. Un registre rangé en colonnes, compressé par dictionnaire et trié sur les champs que la plupart des questions filtrent, est un registre que l’entreprise peut se permettre de laisser lire à ses agents aussi souvent qu’il le faut. La façon dont la disposition à l’intérieur d’un fichier devient ce coût est traitée dans [Apache Parquet : comment le registre est rangé](https://hurukan.com/fr/blog/apache-parquet-comment-le-registre-est-range). ## Où se décide la séparation Le fait est Forme Format dans la couche Données En circulation entre modules ou entrant par un connecteur un enregistrement entier, maintenant Avro, sous un schéma enregistré Au repos dans le registre, lu par des agents et des personnes beaucoup d’enregistrements, quelques champs Parquet, dans un format de table Arrivant un par un mais lu en masse plus tard les deux, l’un après l’autre Avro en entrée, regroupé en Parquet La troisième ligne est là où se trouve l’essentiel de l’ingénierie. Les événements arrivent un par un ; Parquet veut des lots. Quelque chose doit collecter une minute ou une heure d’événements, les écrire en un seul fichier et dire à la table quel fichier est nouveau. Faites-le trop souvent et le registre devient un tas de minuscules fichiers lents à lire. Faites-le trop rarement et l’agent qui a besoin des réceptions d’aujourd’hui lit le registre d’hier. L’intervalle est une décision sur les questions qui doivent être fraîches, et c’est une décision pour une personne, pas un réglage par défaut. ## Ce qu’un agent peut changer ici, et ce qu’il ne peut pas Les agents étendent Hurukan, et la couche Données ne fait pas exception. Un agent peut proposer un nouveau champ sur l’événement de réception, rédiger le travail de regroupement qui dépose les événements dans le registre, ou suggérer qu’une table soit triée par fournisseur parce que les questions du dernier mois ont filtré dessus. Chacune de ces actions est une proposition accompagnée de son raisonnement, et chacune est enregistrée. Deux choses restent aux personnes. Le contrat lui-même : un changement de schéma d’événement est un changement de l’accord entre modules, et le propriétaire du module récepteur l’approuve. Et la forme du registre : combien de temps les événements sont conservés, quels champs quittent le registre sur demande de suppression, et à quelle fréquence les lots se ferment. Cela décide du coût et de l’obligation, et un agent ne signe ni l’un ni l’autre. ## Un test à faire aujourd’hui Prenez un fait qui circule aujourd’hui entre deux systèmes de votre entreprise, une confirmation de commande ou une réception de marchandises. Notez trois choses : où sa liste de champs est définie, qui serait prévenu si un champ était ajouté, et où le même fait est ensuite lu en masse pour un rapport. Si la liste de champs est définie à deux endroits, le contrat n’existe pas encore. Si personne ne serait prévenu, le prochain champ ajouté cassera quelque chose en silence. Si la lecture en masse se fait sur le même magasin qui reçoit les événements, les deux formes partagent une seule disposition, et l’une des deux le paie. La page [couche Données](https://hurukan.com/fr/system/donnees) décrit où chaque forme est censée vivre ; la [présentation de Hurukan](https://hurukan.com/fr) montre les couches autour. - Apache Parquet - Apache Avro - contrats d'événements - le registre - couche Données ## À lire aussi - [Une identité pour les personnes et les agents : qui peut quoi](https://hurukan.com/fr/blog/une-identite-pour-les-personnes-et-les-agents) - [L'état courant et le registre : les deux mémoires d'un système d'exploitation d'entreprise](https://hurukan.com/fr/blog/l-etat-courant-et-le-registre-deux-memoires)