Apache Hudi: de overgangsfase, wijzigingen uit het oude ERP in het register

Geen bedrijf schakelt zijn besturingssysteem op een maandagochtend om. Het orderboek, de voorraad, de openstaande facturen en twintig jaar klanthistorie zitten in een ERP dat blijft draaien terwijl de eerste modules één proces tegelijk overnemen. Maanden, soms jaren, schrijven twee systemen naar hetzelfde bedrijf, en het register moet trouw blijven aan beide.

Dat is de overgangsfase, en die heeft een specifieke technische vorm. Het oude systeem blijft rijen wijzigen; het register heeft die wijzigingen binnen minuten nodig, niet in een nachtelijke export; en het heeft ze nodig als wijzigingen, zodat een correctie op één factuur niet betekent dat een jaar opnieuw wordt geladen. Apache Hudi is rond die vorm gebouwd. De laag Data in Hurukan is in aanbouw; deze tekst gaat over hoe het pad voor de overgangsfase wordt ontworpen en waar Hudi daarin past. Waarom het register los staat van de actuele toestand, staat in de actuele toestand en het register.

Wat de overgangsfase vraagt

Wijzigingen, geen momentopnamen. Een ERP wijzigt duizenden rijen per uur: een status, een betaling, een gecorrigeerd adres. Een nachtelijke kopie van elke tabel is tegelijk te traag en te duur. Het register heeft de rij nodig die veranderde, met wat die ervoor en erna was.

Updates op sleutel. Dezelfde klant, order of factuur komt vele keren binnen met nieuwe waarden. Het register moet de vorige versie van die ene sleutel vinden en vervangen, zonder de partitie waarin die zit te herschrijven.

Incrementeel lezen. Alles wat erna komt — het beeld van een klant in de ontologie, een agent die een kredietbeslissing voorbereidt, een rapport — moet verwerken wat er sinds de vorige keer veranderde, niet opnieuw de hele historie.

Verwijderen op sleutel. Een verwijderverzoek tijdens de overgangsfase moet het register even zeker bereiken als het ERP, en na het opschonen aantoonbaar volledig zijn.

Hoe de wijziging binnenkomt

De database van het ERP schrijft voor zijn eigen herstel al een log van zijn wijzigingen. Change data capture leest dat log en publiceert elke wijziging als gebeurtenis. In het ontwerp dat Hurukan bouwt, draagt die gebeurtenis het contract dat de reeks beschrijft onder Apache Avro, zodat de afnemer de vorm van de rij ervoor en erna kent.

Van daaruit leest Hudi Streamer, de ingestietool van het project, uit Kafka of rechtstreeks uit Debezium-wijzigingsgebeurtenissen, in een continue modus, met een schemaregister, en schrijft de tabel (gecontroleerd op 21 oktober 2026). Voor het gewone geval wordt geen code geschreven; de configuratie is het ontwerp, en in Hurukan is die een voorstel dat een agent opstelt en een mens goedkeurt.

Wat Hudi ermee doet

Hudi geeft elk record een sleutel en houdt een index bij van waar die sleutel staat, zodat een update de bestandsgroep raakt die die sleutel bevat in plaats van een partitie. De indexdocumentatie noemt de opties die in de metadata van de tabel worden bijgehouden: Bloom-filters, een index op recordniveau die globaal kan zijn, secundaire indexen en expressie-indexen, toegevoegd in release 1.0.0 (gecontroleerd op 21 oktober 2026).

Twee tabeltypen beantwoorden twee behoeften, beschreven onder table types. Copy-on-Write herschrijft het Parquet-basisbestand bij elke wijziging; lezen is eenvoudig en snel. Merge-on-Read voegt wijzigingen toe aan logbestanden naast het basisbestand en voegt ze bij het lezen samen; compactie vouwt ze op de achtergrond in nieuwe basisbestanden. Tijdens de overgangsfase zijn de ERP-tabellen meestal Merge-on-Read, omdat het schrijven nooit stopt; een rapporttabel die eens per dag verandert, kan Copy-on-Write zijn.

Elke actie komt op de tijdlijn van de tabel terecht — commit, delta commit, compactie, opschoning, rollback — met een status aangevraagd, in uitvoering en voltooid, en de historie wordt gearchiveerd in een LSM-structuur. Release 1.2.1 van september 2026 is de actuele; 1.1.0 en 1.0.0 daarvoor bouwden de tijdlijn en de indexen opnieuw op (gecontroleerd op 21 oktober 2026).

Drie gevolgen tellen voor het register. Query’s kunnen incrementeel zijn: geef me wat er sinds dit moment veranderde, als laatste toestand of als voor-en-na-beelden. Meerdere schrijvers kunnen een Merge-on-Read-tabel delen onder niet-blokkerende concurrency control, die de concurrencydocumentatie beperkt tot specifieke indextypen en nog niet tot clustering. En een verwijdering op sleutel is een gewone schrijfactie, definitief nadat de cleaner de oude bestandsversies heeft verwijderd.

Wat mensen beslissen

De sleutel. Welke combinatie van velden een rij in het oude systeem identificeert, en of die stabiel blijft tijdens de migratie. Een verkeerde sleutel dupliceert klanten voor de hele levensduur van het register.

Het tabeltype en het compactiebudget. Merge-on-Read houdt de schrijflatentie laag en verschuift de kosten naar compactie, die doorlopend draait en doorlopend betaald wordt. Een agent stelt het schema voor; een mens tekent voor de kosten.

Bewaring en de cleaner. Hoeveel bestandsversies er bewaard blijven, is dezelfde beslissing als hoe ver “wat zag de agent” terugreikt, en als wanneer een verwijderde persoon weg is. Ze wordt per tabel ingesteld en vastgelegd.

Waar de engines staan. Hudi wordt native gelezen door Spark, Flink, Trino en Presto. Een bedrijf waarvan de andere tools Iceberg of Delta verwachten, bereikt een Hudi-tabel via vertaling van metadata, met de beperkingen die de reeks beschrijft voor XTable en UniForm. Dat is een reden om Hudi te houden waar het zijn plaats verdient — het pad van de overgangsfase — en niet overal.

De laag Data beschrijft de connectoren en het ene datamodel dat dit pad voedt. Wanneer het laatste proces naar een module is verhuisd, stopt het ERP met schrijven, eindigt de wijzigingsstroom, en gaat het register door zonder het te merken.

Een test die u vandaag kunt doen

Kies één tabel in uw ERP die de hele dag verandert: orderregels of betalingen. Vraag hoe die vandaag uw rapportage bereikt en noteer drie getallen: hoe oud de kopie is wanneer iemand haar leest, hoeveel van de tabel opnieuw wordt geladen om één dag aan wijzigingen te verwerken, en hoe lang het duurt voordat een verwijderverzoek daar aantoonbaar volledig is. Die drie getallen moet het pad van de overgangsfase verslaan.