Apache Hudi : la phase de coexistence, les changements de l'ancien ERP vers le registre

Aucune entreprise ne change de système d’exploitation un lundi matin. Le carnet de commandes, le stock, les factures ouvertes et vingt ans d’historique client vivent dans un ERP qui continuera de tourner pendant que les premiers modules reprennent les processus un par un. Pendant des mois, parfois des années, deux systèmes écrivent dans la même entreprise, et le registre doit rester fidèle aux deux.

C’est la phase de coexistence, et elle a une forme technique précise. L’ancien système continue de changer des lignes ; le registre a besoin de ces changements en minutes, pas dans un export nocturne ; et il en a besoin en tant que changements, pour qu’une correction sur une facture ne signifie pas recharger une année. Apache Hudi a été construit autour de cette forme. La couche Données de Hurukan est en construction ; ce texte porte sur la manière dont le chemin de coexistence est conçu et sur la place qu’y tient Hudi. La raison pour laquelle le registre est séparé de l’état courant est dans l’état courant et le registre.

Ce qu’exige la coexistence

Des changements, pas des instantanés. Un ERP change des milliers de lignes par heure : un statut, un paiement, une adresse corrigée. Une copie nocturne de chaque table est à la fois trop lente et trop chère. Le registre a besoin de la ligne qui a changé, avec son avant et son après.

Des mises à jour par clé. Le même client, la même commande ou la même facture arrive de nombreuses fois avec de nouvelles valeurs. Le registre doit retrouver la version précédente de cette clé et la remplacer, sans réécrire la partition où elle se trouve.

Une lecture incrémentale. Tout ce qui est en aval — la vue d’un client dans l’ontologie, un agent qui prépare une décision de crédit, un rapport — devrait traiter ce qui a changé depuis sa dernière exécution, pas tout l’historique à nouveau.

Une suppression par clé. Une demande de suppression pendant la coexistence doit atteindre le registre aussi sûrement qu’elle atteint l’ERP, et être prouvablement complète après nettoyage.

Comment le changement arrive

La base de l’ERP écrit déjà un journal de ses propres changements pour sa propre reprise. La capture de changements (change data capture) lit ce journal et publie chaque changement comme un événement. Dans la conception que Hurukan construit, cet événement porte le contrat que la série décrit sous Apache Avro, de sorte que le consommateur connaît la forme de la ligne avant et après.

De là, Hudi Streamer, l’outil d’ingestion du projet, lit depuis Kafka ou directement depuis des événements de changement Debezium, en mode continu, avec un registre de schémas, et écrit la table (vérifié le 21 octobre 2026). Aucun code n’est écrit pour le cas courant ; la configuration est la conception, et dans Hurukan c’est une proposition qu’un agent rédige et qu’une personne approuve.

Ce que Hudi en fait

Hudi donne à chaque enregistrement une clé et tient un index de l’endroit où cette clé vit, de sorte qu’une mise à jour touche le groupe de fichiers qui contient cette clé plutôt qu’une partition. La documentation des index liste les options conservées dans les métadonnées de la table : filtres de Bloom, un index au niveau de l’enregistrement qui peut être global, des index secondaires et des index d’expression ajoutés dans la version 1.0.0 (vérifié le 21 octobre 2026).

Deux types de table répondent à deux besoins décrits sous types de tables. Copy-on-Write réécrit le fichier Parquet de base à chaque changement ; la lecture est simple et rapide. Merge-on-Read ajoute les changements à des fichiers journaux à côté du fichier de base et les fusionne à la lecture ; le compactage les replie en nouveaux fichiers de base en arrière-plan. Pendant la coexistence, les tables de l’ERP sont généralement en Merge-on-Read, parce que les écritures ne s’arrêtent jamais ; une table de reporting qui change une fois par jour peut être en Copy-on-Write.

Chaque action atterrit sur la chronologie (timeline) de la table — commit, delta commit, compactage, nettoyage, retour arrière — avec un état demandé, en cours et terminé, et l’historique est archivé dans une structure LSM. La version 1.2.1 de septembre 2026 est courante ; les 1.1.0 et 1.0.0 avant elle ont reconstruit la chronologie et les index (vérifié le 21 octobre 2026).

Trois conséquences comptent pour le registre. Les requêtes peuvent être incrémentales : donne-moi ce qui a changé depuis cet instant, comme dernier état ou comme images avant et après. Plusieurs écrivains peuvent partager une table Merge-on-Read sous un contrôle de concurrence non bloquant, que la documentation de concurrence limite à certains types d’index et pas encore au regroupement. Et une suppression par clé est une écriture ordinaire, définitive une fois que le nettoyeur a retiré les anciennes versions de fichier.

Ce que les personnes décident

La clé. Quelle combinaison de champs identifie une ligne dans l’ancien système, et si elle reste stable pendant la migration. Une mauvaise clé duplique les clients pour toute la vie du registre.

Le type de table et le budget de compactage. Merge-on-Read garde la latence d’écriture basse et déplace le coût vers le compactage, qui tourne en continu et se paie en continu. Un agent proposera le calendrier ; une personne signe le coût.

La rétention et le nettoyeur. Combien de versions de fichier garder est la même décision que jusqu’où remonte « qu’a vu l’agent », et que le moment où une personne supprimée a disparu. Elle se fixe par table et s’enregistre.

Où sont les moteurs. Hudi est lu nativement par Spark, Flink, Trino et Presto. Une entreprise dont les autres outils attendent Iceberg ou Delta atteindra une table Hudi par traduction de métadonnées, avec les limites que la série décrit pour XTable et UniForm. C’est une raison de garder Hudi là où il mérite sa place — le chemin de coexistence — plutôt que partout.

La couche Données décrit les connecteurs et le modèle de données unique que ce chemin alimente. Quand le dernier processus est passé à un module, l’ERP cesse d’écrire, le flux de changements s’arrête, et le registre continue sans s’en apercevoir.

Un test à faire aujourd’hui

Choisissez une table de votre ERP qui change toute la journée : lignes de commande ou paiements. Demandez comment elle atteint votre reporting aujourd’hui et notez trois nombres : l’âge de la copie quand quelqu’un la lit, la part de la table rechargée pour appliquer une journée de changements, et le temps qu’il faut pour qu’une demande de suppression y soit prouvablement complète. Ces trois nombres sont ce que le chemin de coexistence doit battre.