Apache Hudi: sameksistensfasen, endringsdata fra det gamle ERP-systemet inn i registeret

Ingen virksomhet bytter operativsystem en mandag morgen. Ordreboken, lageret, de åpne fakturaene og tjue års kundehistorikk ligger i et ERP-system som fortsetter å kjøre mens de første modulene tar over én prosess om gangen. I måneder, noen ganger år, skriver to systemer til den samme virksomheten, og registeret må være tro mot begge.

Det er sameksistensfasen, og den har en bestemt teknisk form. Det gamle systemet fortsetter å endre rader; registeret trenger disse endringene i løpet av minutter, ikke i en nattlig eksport; og det trenger dem som endringer, slik at en korreksjon av én faktura ikke betyr å laste inn et helt år på nytt. Apache Hudi ble bygd rundt den formen. Datalaget i Hurukan er under bygging; denne teksten handler om hvordan sameksistensveien utformes og hvor Hudi passer inn i den. Hvorfor registeret er atskilt fra nåtilstanden, står i nåtilstanden og registeret.

Hva sameksistens krever

Endringer, ikke øyeblikksbilder. Et ERP-system endrer tusenvis av rader i timen: en status, en betaling, en rettet adresse. En nattlig kopi av hver tabell er både for treg og for dyr. Registeret trenger raden som endret seg, med hvordan den var før og etter.

Oppdateringer etter nøkkel. Den samme kunden, ordren eller fakturaen kommer mange ganger med nye verdier. Registeret må finne den forrige versjonen av akkurat den nøkkelen og erstatte den, uten å skrive om partisjonen den ligger i.

Inkrementell lesing. Alt nedstrøms — ontologiens bilde av en kunde, en agent som forbereder en kredittbeslutning, en rapport — bør behandle det som har endret seg siden forrige kjøring, ikke hele historikken på nytt.

Sletting etter nøkkel. En sletteforespørsel under sameksistensen må nå registeret like sikkert som den når ERP-systemet, og være beviselig fullført etter opprydding.

Hvordan endringen kommer

ERP-systemets database skriver allerede en logg over sine egne endringer for sin egen gjenoppretting. Endringsfangst (change data capture) leser den loggen og publiserer hver endring som en hendelse. I utformingen Hurukan bygger, bærer den hendelsen kontrakten serien beskriver under Apache Avro, slik at mottakeren kjenner radens form før og etter.

Derfra leser Hudi Streamer, prosjektets innlastingsverktøy, fra Kafka eller direkte fra Debezium-endringshendelser, i kontinuerlig modus, med et skjemaregister, og skriver tabellen (kontrollert 21. oktober 2026). For det vanlige tilfellet skrives det ingen kode; konfigurasjonen er utformingen, og i Hurukan er den et forslag en agent utarbeider og en person godkjenner.

Hva Hudi gjør med den

Hudi gir hver post en nøkkel og holder en indeks over hvor nøkkelen ligger, slik at en oppdatering berører filgruppen som holder nøkkelen, ikke en partisjon. Indeksdokumentasjonen lister alternativene som holdes i tabellens metadata: Bloom-filtre, en postnivåindeks som kan være global, sekundærindekser og uttrykksindekser lagt til i utgave 1.0.0 (kontrollert 21. oktober 2026).

To tabelltyper svarer på to behov beskrevet under tabelltyper. Copy-on-Write skriver om den grunnleggende Parquet-filen ved hver endring; lesing er enkel og rask. Merge-on-Read legger endringer i loggfiler ved siden av grunnfilen og slår dem sammen ved lesing; komprimering bretter dem inn i nye grunnfiler i bakgrunnen. Under sameksistensen er ERP-tabellene som regel Merge-on-Read, fordi skrivingen aldri stopper; en rapporttabell som endres én gang om dagen, kan være Copy-on-Write.

Hver handling havner på tabellens tidslinje — commit, delta commit, komprimering, opprydding, tilbakerulling — med tilstandene forespurt, under utførelse og fullført, og historikken arkiveres i en LSM-struktur. Utgave 1.2.1 fra september 2026 er gjeldende; 1.1.0 og 1.0.0 før den bygde om tidslinjen og indeksene (kontrollert 21. oktober 2026).

Tre konsekvenser betyr noe for registeret. Spørringer kan være inkrementelle: gi meg det som har endret seg siden dette øyeblikket, som siste tilstand eller som før- og etterbilder. Flere skrivere kan dele en Merge-on-Read-tabell under ikke-blokkerende samtidighetskontroll, som samtidighetsdokumentasjonen begrenser til bestemte indekstyper og ennå ikke til klynging. Og en sletting etter nøkkel er en vanlig skriving, endelig etter at oppryddingen har fjernet de gamle filversjonene.

Hva mennesker avgjør

Nøkkelen. Hvilken kombinasjon av felt som identifiserer en rad i det gamle systemet, og om den forblir stabil gjennom migreringen. En feil nøkkel dupliserer kunder i hele registerets levetid.

Tabelltypen og komprimeringsbudsjettet. Merge-on-Read holder skriveforsinkelsen lav og flytter kostnaden til komprimering, som kjører kontinuerlig og betales kontinuerlig. En agent vil foreslå tidsplanen; en person signerer kostnaden.

Oppbevaring og oppryddingen. Hvor mange filversjoner som beholdes, er den samme beslutningen som hvor langt tilbake «hva så agenten» rekker, og som når en slettet person er borte. Den settes per tabell og registreres.

Hvor motorene er. Hudi leses direkte av Spark, Flink, Trino og Presto. En virksomhet der de andre verktøyene forventer Iceberg eller Delta, vil nå en Hudi-tabell gjennom oversettelse av metadata, med de begrensningene serien beskriver for XTable og UniForm. Det er en grunn til å holde Hudi der den gjør seg fortjent — på sameksistensveien — heller enn overalt.

Data-laget beskriver koblingene og den ene datamodellen som denne veien mater. Når den siste prosessen har flyttet til en modul, slutter ERP-systemet å skrive, endringsstrømmen tar slutt, og registeret fortsetter uten å merke det.

En test du kan gjøre i dag

Velg én tabell i ERP-systemet ditt som endres hele dagen: ordrelinjer eller betalinger. Spør hvordan den når rapporteringen din i dag, og skriv ned tre tall: hvor gammel kopien er når noen leser den, hvor mye av tabellen som lastes inn på nytt for å bruke én dags endringer, og hvor lang tid en sletteforespørsel tar før den er beviselig fullført der. De tre tallene er det sameksistensveien må slå.