Apache Hudi: sameksistensfasen, ændringer fra det gamle ERP ind i registret

Ingen virksomhed skifter sit operativsystem en mandag morgen. Ordrebogen, lageret, de åbne fakturaer og tyve års kundehistorik lever i et ERP, der fortsætter med at køre, mens de første moduler overtager én proces ad gangen. I måneder, nogle gange år, skriver to systemer til den samme forretning, og registret skal forblive sandt over for begge.

Det er sameksistensfasen, og den har en bestemt teknisk form. Det gamle system bliver ved med at ændre rækker; registret har brug for de ændringer inden for minutter, ikke i et natligt udtræk; og det har brug for dem som ændringer, så en rettelse af én faktura ikke betyder, at et år skal genindlæses. Apache Hudi blev bygget omkring den form. Datalaget i Hurukan er under opbygning; denne tekst handler om, hvordan sameksistensvejen designes, og hvor Hudi passer ind. Hvorfor registret er adskilt fra den levende tilstand, står i den levende tilstand og registret.

Hvad sameksistens kræver

Ændringer, ikke øjebliksbilleder. Et ERP ændrer tusindvis af rækker i timen: en status, en betaling, en rettet adresse. En natlig kopi af hver tabel er både for langsom og for dyr. Registret har brug for den række, der ændrede sig, med hvordan den var før og efter.

Opdateringer efter nøgle. Den samme kunde, ordre eller faktura ankommer mange gange med nye værdier. Registret skal finde den forrige version af netop den nøgle og erstatte den uden at omskrive den partition, den ligger i.

Inkrementel læsning. Alt længere nede — ontologiens billede af en kunde, en agent, der forbereder en kreditbeslutning, en rapport — skal behandle det, der er ændret siden sidste kørsel, ikke hele historikken igen.

Sletning efter nøgle. En sletteanmodning under sameksistens skal nå registret lige så sikkert, som den når ERP, og være beviseligt fuldført efter oprydning.

Hvordan ændringen ankommer

ERP’ets database skriver allerede en log over sine egne ændringer til sin egen gendannelse. Ændringsregistrering (change data capture, CDC) læser den log og udgiver hver ændring som en hændelse. I det design, Hurukan bygger, bærer den hændelse den kontrakt, serien beskriver under Apache Avro, så forbrugeren kender rækkens form før og efter.

Derfra læser Hudi Streamer, projektets indlæsningsværktøj, fra Kafka eller direkte fra Debezium-ændringshændelser, i kontinuerlig tilstand, med et skemaregister, og skriver tabellen (kontrolleret den 21. oktober 2026). Der skrives ingen kode til det almindelige tilfælde; konfigurationen er designet, og i Hurukan er den et forslag, som en agent udarbejder, og et menneske godkender.

Hvad Hudi gør med den

Hudi giver hver post en nøgle og fører et indeks over, hvor nøglen bor, så en opdatering rører den filgruppe, der rummer nøglen, frem for en partition. Indeksdokumentationen oplister de muligheder, der føres i tabellens metadata: Bloom-filtre, et indeks på postniveau, der kan være globalt, sekundære indekser og udtryksindekser tilføjet i udgivelse 1.0.0 (kontrolleret den 21. oktober 2026).

To tabeltyper dækker to behov, beskrevet under tabeltyper. Copy-on-Write omskriver den grundlæggende Parquet-fil ved hver ændring; læsning er enkel og hurtig. Merge-on-Read tilføjer ændringer til logfiler ved siden af grundfilen og fletter dem ved læsning; kompaktering folder dem ind i nye grundfiler i baggrunden. Under sameksistens er ERP-tabellerne som regel Merge-on-Read, fordi skrivningerne aldrig stopper; en rapporttabel, der ændres én gang om dagen, kan være Copy-on-Write.

Hver handling lander på tabellens tidslinje — commit, delta commit, kompaktering, oprydning, tilbagerulning — med tilstandene anmodet, i gang og fuldført, og historikken arkiveres i en LSM-struktur. Udgivelse 1.2.1 fra september 2026 er den aktuelle; 1.1.0 og 1.0.0 før den byggede tidslinjen og indekserne om (kontrolleret den 21. oktober 2026).

Tre konsekvenser betyder noget for registret. Forespørgsler kan være inkrementelle: giv mig det, der er ændret siden dette tidspunkt, som seneste tilstand eller som før- og efterbilleder. Flere skribenter kan dele en Merge-on-Read-tabel under ikke-blokerende samtidighedskontrol, som samtidighedsdokumentationen begrænser til bestemte indekstyper og endnu ikke til klyngedannelse. Og en sletning efter nøgle er en almindelig skrivning, endelig efter at oprydderen har fjernet de gamle filversioner.

Hvad mennesker beslutter

Nøglen. Hvilken kombination af felter der identificerer en række i det gamle system, og om den forbliver stabil gennem migreringen. En forkert nøgle dublerer kunder i hele registrets levetid.

Tabeltypen og kompakteringsbudgettet. Merge-on-Read holder skrivelatensen lav og flytter omkostningen til kompaktering, som kører løbende og betales løbende. En agent foreslår planen; et menneske underskriver omkostningen.

Opbevaring og oprydderen. Hvor mange filversioner der beholdes, er samme beslutning som, hvor langt tilbage “hvad så agenten” rækker, og hvornår en slettet person er væk. Den fastsættes pr. tabel og registreres.

Hvor motorerne er. Hudi læses direkte af Spark, Flink, Trino og Presto. En virksomhed, hvis øvrige værktøjer forventer Iceberg eller Delta, når en Hudi-tabel gennem oversættelse af metadata, med de begrænsninger, serien beskriver for XTable og UniForm. Det er en grund til at holde Hudi, hvor det gør sig fortjent — på sameksistensvejen — frem for overalt.

Laget Data beskriver konnektorerne og den ene datamodel, som denne vej fodrer. Når den sidste proces er flyttet til et modul, holder ERP op med at skrive, ændringsstrømmen slutter, og registret fortsætter uden at bemærke det.

En test, du kan lave i dag

Vælg én tabel i jeres ERP, der ændrer sig hele dagen: ordrelinjer eller betalinger. Spørg, hvordan den når jeres rapportering i dag, og skriv tre tal ned: hvor gammel kopien er, når nogen læser den, hvor meget af tabellen der genindlæses for at anvende én dags ændringer, og hvor lang tid en sletteanmodning tager om at være beviseligt fuldført dér. De tre tal er dem, sameksistensvejen skal slå.