--- title: "Apache Hudi: samexistensfasen, ändringsdata från det gamla ERP-systemet in i registret" url: "https://hurukan.com/sv/blog/apache-hudi-samexistensfasen-andringar-fran-det-gamla-erp-systemet" description: "Modulerna tar över en process i taget; under tiden skriver det gamla ERP-systemet. Hur change data capture och Apache Hudi håller registret aktuellt." --- # Apache Hudi: samexistensfasen, ändringsdata från det gamla ERP-systemet in i registret 9 oktober 2026·4 min läsning·Redaktionen En serverrumskorridor sedd längs sin längd, två rack med äldre grå utrustning till vänster och ett nytt vitt rack till höger förbundna med en enda buntad kabel, en tekniker bakifrån som kontrollerar en handhållen skärm med abstrakta blågrå rader, tunna blå statuslampor Inget företag byter operativsystem en måndagsmorgon. Orderboken, lagret, de öppna fakturorna och tjugo års kundhistorik finns i ett ERP-system som kommer att fortsätta köra medan de första modulerna tar över en process i taget. I månader, ibland år, skriver två system till samma verksamhet, och registret måste förbli sant mot båda. Det är samexistensfasen, och den har en specifik teknisk form. Det gamla systemet fortsätter ändra rader; registret behöver de ändringarna inom minuter, inte i ett nattligt uttag; och det behöver dem som ändringar, så att en rättelse av en faktura inte innebär att ett år läses in på nytt. Apache Hudi byggdes kring den formen. Datalagret i Hurukan är under uppbyggnad; den här texten handlar om hur samexistensvägen utformas och var Hudi passar in i den. Varför registret är skilt från det levande tillståndet står i [det levande tillståndet och registret](https://hurukan.com/sv/blog/det-levande-tillstandet-och-registret-tva-minnen). ## Vad samexistens kräver **Ändringar, inte ögonblicksbilder.** Ett ERP-system ändrar tusentals rader i timmen: en status, en betalning, en rättad adress. En nattlig kopia av varje tabell är både för långsam och för dyr. Registret behöver raden som ändrades, med vad den var före och efter. **Uppdateringar per nyckel.** Samma kund, order eller faktura kommer många gånger med nya värden. Registret måste hitta den föregående versionen av just den nyckeln och ersätta den, utan att skriva om partitionen den ligger i. **Inkrementell läsning.** Allt nedströms — ontologins vy av en kund, en agent som förbereder ett kreditbeslut, en rapport — bör bearbeta det som ändrats sedan det senast kördes, inte hela historiken igen. **Radering per nyckel.** En begäran om radering under samexistensen måste nå registret lika säkert som den når ERP-systemet, och vara bevisligen fullständig efter rensning. ## Hur ändringen kommer fram ERP-systemets databas skriver redan en logg över sina egna ändringar för sin egen återställning. Change data capture läser den loggen och publicerar varje ändring som en händelse. I den design Hurukan bygger bär den händelsen det kontrakt serien beskriver under [Apache Avro](https://hurukan.com/sv/blog/apache-avro-kontraktet-mellan-moduler), så att konsumenten känner radens form före och efter. Därifrån läser [Hudi Streamer](https://hudi.apache.org/docs/hoodie_streaming_ingestion), projektets inläsningsverktyg, från Kafka eller direkt från Debezium-ändringshändelser, i ett kontinuerligt läge, med ett schemaregister, och skriver tabellen (kontrollerat den 21 oktober 2026). Ingen kod skrivs för det vanliga fallet; konfigurationen är designen, och i Hurukan är det ett förslag som en agent utarbetar och en människa godkänner. ## Vad Hudi gör med den Hudi ger varje post en nyckel och håller ett index över var den nyckeln bor, så att en uppdatering rör den filgrupp som rymmer den nyckeln snarare än en partition. [Indexdokumentationen](https://hudi.apache.org/docs/indexes) listar alternativen som hålls i tabellens metadata: Bloom-filter, ett index på postnivå som kan vara globalt, sekundära index och uttrycksindex tillagda i version 1.0.0 (kontrollerat den 21 oktober 2026). Två tabelltyper svarar på två behov som beskrivs under [tabelltyper](https://hudi.apache.org/docs/table_types). **Copy-on-Write** skriver om Parquet-basfilen vid varje ändring; läsning är enkel och snabb. **Merge-on-Read** lägger ändringar i loggfiler bredvid basfilen och slår ihop dem vid läsning; komprimering viker in dem i nya basfiler i bakgrunden. Under samexistensen är ERP-tabellerna vanligen Merge-on-Read, eftersom skrivningarna aldrig upphör; en rapporttabell som ändras en gång om dagen kan vara Copy-on-Write. Varje åtgärd landar på tabellens [tidslinje](https://hudi.apache.org/docs/timeline) — commit, delta commit, komprimering, rensning, återställning — med tillstånden begärd, pågående och slutförd, och historiken arkiveras i en LSM-struktur. Version [1.2.1](https://hudi.apache.org/releases/release-1.2) från september 2026 är aktuell; 1.1.0 och 1.0.0 före den byggde om tidslinjen och indexen (kontrollerat den 21 oktober 2026). Tre konsekvenser spelar roll för registret. Frågor kan vara **inkrementella**: ge mig det som ändrats sedan det här ögonblicket, som senaste tillstånd eller som bilder före och efter. Flera skrivare kan dela en Merge-on-Read-tabell under **icke-blockerande samtidighetskontroll**, som [dokumentationen om samtidighet](https://hudi.apache.org/docs/concurrency_control) begränsar till vissa indextyper och ännu inte till klustring. Och en **radering per nyckel** är en vanlig skrivning, slutgiltig efter att rensaren tagit bort de gamla filversionerna. ## Vad människor beslutar **Nyckeln.** Vilken kombination av fält som identifierar en rad i det gamla systemet, och om den förblir stabil genom migreringen. En fel nyckel dubblerar kunder för registrets hela livstid. **Tabelltypen och komprimeringsbudgeten.** Merge-on-Read håller skrivfördröjningen låg och flyttar kostnaden till komprimeringen, som körs kontinuerligt och betalas kontinuerligt. En agent föreslår schemat; en människa skriver under på kostnaden. **Bevarande och rensaren.** Hur många filversioner som behålls är samma beslut som hur långt tillbaka “vad såg agenten” når, och som när en raderad person är borta. Det sätts per tabell och registreras. **Var motorerna finns.** Hudi läses inbyggt av Spark, Flink, Trino och Presto. Ett företag vars övriga verktyg väntar sig Iceberg eller Delta når en Hudi-tabell genom metadataöversättning, med de gränser serien beskriver för [XTable och UniForm](https://hurukan.com/sv/blog/ett-register-lasbart-for-verktygen-du-redan-har-xtable-och-uniform). Det är ett skäl att hålla Hudi där det förtjänar sin plats — samexistensvägen — snarare än överallt. Lagret [Data](https://hurukan.com/sv/system/data) beskriver kopplingarna och den enda datamodell som den här vägen matar. När den sista processen har flyttat till en modul slutar ERP-systemet skriva, ändringsströmmen upphör, och registret fortsätter utan att märka det. ## Ett test du kan göra i dag Välj en tabell i ditt ERP-system som ändras hela dagen: orderrader eller betalningar. Fråga hur den når er rapportering i dag och skriv ner tre siffror: hur gammal kopian är när någon läser den, hur stor del av tabellen som läses in på nytt för att applicera en dags ändringar, och hur lång tid en begäran om radering tar innan den är bevisligen fullständig där. De tre siffrorna är vad samexistensvägen måste slå. - Apache Hudi - change data capture - samexistens - ERP-migrering - inkrementell bearbetning ## Läs vidare - [En identitet för människor och agenter: vem som får göra vad](https://hurukan.com/sv/blog/en-identitet-for-manniskor-och-agenter) - [Det levande tillståndet och registret: två minnen i ett operativsystem för företaget](https://hurukan.com/sv/blog/det-levande-tillstandet-och-registret-tva-minnen)