Apache Paimon : une seule table d'état pour l'opérateur, le planificateur et l'agent

Un ordre d’assemblage change d’état onze fois entre le lancement et l’expédition : planifié, lancé, démarré au premier poste, en attente d’une pièce manquante, repris, contrôlé, une unité rejetée, retouché, emballé, confirmé, expédié. L’opératrice au poste voit son étape sur un terminal dans Opérations et qualité. Le planificateur voit l’ordre dans un tableau. L’agent opérations, à qui l’on demande si le plan de la semaine tient encore, voit un rapport. Trois vues, et dans la plupart des entreprises trois tables, rafraîchies selon trois calendriers, si bien que pendant une heure chaque après-midi l’opératrice, le planificateur et l’agent croient chacun une chose différente sur le même ordre.

La couche Données de Hurukan est conçue pour qu’il y ait une seule table d’état pour cet ordre, et que tout le monde la lise. Le texte pilier explique pourquoi l’état courant est une mémoire distincte du registre. Ce texte porte sur le format dans lequel cette table est construite, Apache Paimon, et sur ce que ce choix coûte. La couche est en construction ; voici comment elle est conçue.

Une table que l’on met à jour, pas que l’on complète

La plupart des formats de table d’un lakehouse supposent que les données arrivent et restent. De nouvelles lignes deviennent de nouveaux fichiers ; changer une ligne signifie réécrire un fichier ou la marquer supprimée. C’est la bonne conception pour un registre, où rien n’est jamais modifié. C’est la mauvaise conception pour l’état d’un ordre qui change onze fois avant d’être terminé.

Apache Paimon prend une autre forme. Ses tables à clé primaire gardent les lignes triées par clé à l’intérieur de buckets, dans un arbre LSM (log-structured merge tree) : les nouvelles versions arrivent dans un niveau supérieur, et un compactage en arrière-plan les fusionne vers le bas en fichiers triés, de sorte que la table reste compacte quelle que soit la fréquence de réécriture des mêmes clés (types de tables Paimon, vérifié le 21 octobre 2026). Un lecteur voit la dernière version de chaque clé sans parcourir d’historique. Les tables sans clé primaire sont des tables d’ajout, qui conviennent au côté registre ; ici, c’est la variante à clé primaire qui compte. La version courante est 2.0.0 du 7 août 2026 (catalogue des versions).

Les moteurs de fusion sont des règles d’ontologie

Ce qui fait de Paimon plus qu’une table d’upsert rapide, c’est que le format lui-même décide de la manière dont une nouvelle version d’une ligne se combine avec l’ancienne. Paimon appelle cela le moteur de fusion (merge engine), et dans la couche Données chaque choix correspond à une règle que l’ontologie énonce déjà sur un objet.

Deduplicate, le défaut : la version la plus récente gagne. La bonne règle pour le statut d’un ordre — le dernier événement est la vérité.

Partial update : chaque écrivain ne remplit que ses propres colonnes. La ligne d’état de l’ordre a les dates planifiées venant de la planification, le début et la fin réels venant du terminal de poste, le résultat de contrôle venant de la qualité, la quantité emballée venant de l’entrepôt. Quatre modules, une ligne, aucun n’écrasant les autres. Les groupes de séquence permettent à chaque jeu de colonnes de porter son propre ordre, de sorte qu’un message tardif du poste ne peut pas annuler un message plus récent de la qualité (partial update).

Aggregation : les nombres s’additionnent au fil des événements — heures pointées sur une opération, unités terminées, unités rejetées.

First row : la première version est conservée. Utile là où l’ontologie dit qu’une valeur se fixe une fois, comme le moment où un ordre a été lancé.

Dans l’ontologie, ces règles sont décrites comme des propriétés de l’objet : quel champ se fixe une fois, lequel s’accumule, lequel appartient à quel module. Les exprimer dans la définition de la table signifie que la règle vaut pour chaque écrivain, y compris un pipeline construit par un agent qui n’existait pas quand la règle a été écrite.

Une table, trois lecteurs, un changelog

Le terminal de l’opératrice, le tableau du planificateur et la vue de l’agent sont trois lecteurs de la même table, chacun filtré différemment. Flink l’écrit à partir du flux d’événements des modules et la relit dans des jointures de consultation (lookup joins). Spark, Trino, Hive, StarRocks et Doris la lisent aussi (moteurs pris en charge), de sorte qu’un moteur de rapport et un carnet d’analyse voient la même ligne que le terminal affiche.

La table émet aussi ses propres changements. Un producteur de changelog — input, lookup ou full-compaction, choisi par table — transforme chaque changement fusionné en flux. L’agent opérations s’abonne à « ordre en attente » plutôt que de parcourir le tableau, et la vue de planification se met à jour parce que la table a changé, pas parce que quelqu’un a appuyé sur actualiser.

Pour l’audit, Paimon garde des instantanés et permet à une étiquette (tag) d’en épingler un définitivement. Quand l’agent a proposé de déplacer trois ordres à la semaine suivante, l’étiquette prise à ce moment montre le tableau qu’il regardait. La proposition, la décision et l’instantané sont côte à côte dans le registre.

Ce que cela coûte

Une table d’état Paimon n’est pas gratuite, et la couche Données est honnête sur la facture.

Le compactage ne s’arrête jamais. L’arbre de fusion est maintenu compact par un travail d’arrière-plan qui consomme du calcul en continu. Plus les clés sont réécrites souvent et plus la table doit être fraîche, plus cela coûte. C’est la raison pour laquelle toutes les tables de la couche ne sont pas des tables Paimon : le registre lui-même, qui ne fait que croître, n’en a pas besoin.

Un moteur de flux est un prérequis. Écrire l’état en continu signifie faire tourner Flink en continu, avec quelqu’un qui en est responsable. Les entreprises qui n’ont pas cette capacité devraient commencer par des tables rafraîchies en minutes par des traitements par lots et ne passer aux flux que là où une décision a besoin de secondes.

La clé doit être juste. Une table à clé primaire ne vaut que ce que vaut sa clé. Si l’ontologie ne dit pas encore ce qui identifie un ordre à travers les modules, la table ne peut pas être construite, et le premier pas honnête est l’ontologie, pas le format.

Les agents aident pour la partie routinière : proposer le nombre de buckets et les calendriers de compactage, rédiger le pipeline qui projette les événements des modules sur la ligne, remarquer quand le retard d’une table augmente. Les personnes décident de la clé, de la règle de fusion et de la durée de conservation des instantanés — parce que ce sont des affirmations sur ce que l’entreprise tient pour vrai.

Un test à faire aujourd’hui

Prenez un objet que plusieurs équipes surveillent — une commande, un ordre, une expédition — et demandez à chaque équipe de vous montrer où elle le consulte. Comptez les écrans. Puis choisissez un champ, comme la quantité terminée, et demandez à chacune ce qu’il indique en ce moment.

Si les réponses diffèrent, vous avez trouvé la ligne que la couche Données est conçue pour garder une seule fois. Si elles concordent seulement parce que quelqu’un les rapproche chaque après-midi, vous avez trouvé la personne qui fait à la main ce qu’un moteur de fusion fait dans le format.