L'état que lisent les agents de domaine : Paimon pour la file de travail, le stock et les approbations

On demande à un agent achats de préparer une commande de réapprovisionnement pour un composant qui vient à manquer. Pour bien le faire, il lui faut la position de stock dans trois entrepôts, les commandes clients ouvertes qui en réservent une partie, les livraisons entrantes déjà en route et le statut de risque actuel du fournisseur. Chacun de ces éléments a changé dans la dernière heure. La copie nocturne de l’entrepôt de données se trompe sur les quatre. Les tables de production des modules sont justes, mais un agent qui les lit à grande échelle est le moyen le plus rapide de ralentir les personnes qui travaillent dans ces modules.

C’est l’écart entre les deux mémoires d’un système d’exploitation d’entreprise : le registre, qui garde chaque événement pour de bon, et l’état courant, qui est ce à quoi les choses ressemblent maintenant. Le texte pilier décrit les deux. Celui-ci porte sur le second, et sur le format de table que la couche Données utilise pour lui. La couche Données est en construction ; voici comment elle est conçue.

Ce qu’un agent de domaine lit réellement

Les agents de Hurukan sont des agents de domaine : un pour les achats, un pour le service client, un pour la file de travail des opérations, et ainsi de suite. Chacun travaille à partir d’un petit nombre de tables d’état qui répondent à des questions au présent.

La file de travail. Quels ordres sont lancés, lesquels sont bloqués et pourquoi, quelle machine ou quelle équipe est libre. Alimentée par le module opérations à mesure que les ordres changent de statut.

Stock et réservations. Quantité disponible par article et par emplacement, moins ce que les commandes ouvertes ont déjà réclamé, plus ce qui est en route. Alimentée par les événements de Stocks et logistique, du commerce et des achats.

La boîte d’approbation. Chaque proposition faite par un agent, avec ses sources et son risque, et si une personne a déjà tranché. Alimentée par les agents eux-mêmes et par les personnes dans Décisions et tâches.

Aucune de ces tables n’est une copie de la base d’un module. Chacune est construite à partir des événements que les modules émettent, que le registre conserve aussi. La table d’état est une vue dérivée et toujours à jour du registre ; le registre est la preuve derrière elle.

Pourquoi c’est une table Paimon

Une table d’état change des milliers de fois par heure par clé : le même article, le même ordre, la même proposition, mis à jour encore et encore. Les formats de table construits autour de l’ajout de nouveaux fichiers gèrent mal ce cas, parce que chaque mise à jour devient un nouveau fichier et la table se noie dans les petits fichiers. Apache Paimon a été conçu exactement pour cela. Ses tables à clé primaire stockent les lignes dans un arbre LSM, triées par clé à l’intérieur d’un bucket, de sorte qu’un flux de mises à jour sur les mêmes clés reste compact et qu’un lecteur voit toujours la dernière version de chaque ligne (types de tables, vérifié le 21 octobre 2026).

Deux fonctions de Paimon font un travail qui serait sinon du code. Un moteur de fusion (merge engine) décide de ce qui arrive quand une nouvelle ligne se présente pour une clé existante : la remplacer, garder la première, agréger, ou ne remplir que les champs arrivés. La table de stock utilise cette dernière option : les stocks écrivent la quantité disponible, le commerce écrit la quantité réservée, les achats écrivent la quantité entrante, et la table tient les trois dans une seule ligne sans qu’aucun module ne sache rien des autres. Un producteur de changelog émet chaque changement de la table sous forme de flux à part entière, si bien qu’un agent en aval peut réagir à « le stock est passé sous le point de commande » au lieu d’interroger sans cesse.

La version courante est Paimon 2.0.0 du 7 août 2026 (catalogue des versions, vérifié le 21 octobre 2026). Flink l’écrit et la lit, et la jointure de consultation (lookup join) permet à un traitement en flux d’enrichir un événement avec l’état courant d’une autre table — une nouvelle commande avec le stock qu’elle réserve — sans aller-retour vers quoi que ce soit d’autre. Spark, Trino, Hive, StarRocks et Doris lisent les mêmes tables (moteurs).

L’agent lit l’état et n’écrit qu’une proposition

La frontière compte plus que le format. Un agent de domaine lit librement les tables d’état. Il n’écrit pas dans un module, et il n’écrit pas non plus dans la table d’état. Ce qu’il produit est une proposition : une commande de réapprovisionnement rédigée avec les lignes qu’il a lues, la règle qu’il a appliquée et le risque qu’il voit. La proposition arrive dans la boîte d’approbation. Une personne décide. Le module exécute la décision, émet l’événement, et la table d’état change parce que l’événement a été enregistré — pas parce que l’agent l’a modifiée.

C’est ce qui garde les deux mémoires honnêtes. Si les agents écrivaient directement l’état, l’état contiendrait des choses qui ne sont arrivées dans aucun module et n’ont jamais été enregistrées. En lisant l’état et en écrivant des propositions, chaque changement de ce que l’entreprise tient pour vrai passe encore par une personne et par le registre.

Cela répond aussi à la question de l’audit. Paimon conserve des instantanés, et une étiquette (tag) en épingle un pour qu’il n’expire pas. Quand une proposition est mise en question des mois plus tard, l’instantané pris au moment où l’agent a lu la table montre exactement le stock, la file et les commandes ouvertes qu’il a vus. Le journal des décisions tient le raisonnement ; l’instantané tient la preuve.

Des secondes, des minutes, ou cette nuit

Tout état n’a pas besoin d’être une table Paimon alimentée par un flux. La boîte d’approbation doit être à jour à la seconde, parce qu’une personne y attend. La file de travail doit être à jour à la minute, parce qu’une machine attend. Le stock pour le réapprovisionnement est une décision prise quelques fois par jour ; un état en retard de quelques minutes convient. Le statut de risque fournisseur change chaque semaine.

Tout pousser à la seconde coûte un compactage continu, un moteur de flux qui ne dort jamais, et une équipe d’exploitation pour garder les deux en bonne santé. La couche Données demande donc, pour chaque table d’état, quelle décision en dépend et à quelle vitesse cette décision change vraiment — et seules les tables qui ont besoin de secondes les obtiennent. Le « temps réel » n’est pas une propriété de la plateforme ; c’est un budget dépensé table par table.

Un test à faire aujourd’hui

Choisissez une décision que quelqu’un prend plusieurs fois par jour dans votre entreprise : approuver un achat, lancer un ordre, promettre une date de livraison. Notez chaque nombre qu’il regarde avant de décider et, à côté de chacun, d’où il vient et quand il a été rafraîchi pour la dernière fois.

Si plusieurs de ces nombres viennent de systèmes différents et ont été rafraîchis à des moments différents, la personne fait déjà la jointure dans sa tête, à partir d’un état qui n’a jamais été cohérent à un seul instant. C’est la table dont un agent de domaine aurait besoin en premier — et celle à concevoir avant de demander à un agent de décider quoi que ce soit.