Apache Hudi: rinnakkaiselon vaihe, muutosdata vanhasta ERP:stä rekisteriin

Yksikään yritys ei vaihda käyttöjärjestelmäänsä maanantaiaamuna. Tilauskanta, varasto, avoimet laskut ja kahdenkymmenen vuoden asiakashistoria ovat ERP:ssä, joka jatkaa toimintaansa, kun ensimmäiset moduulit ottavat prosesseja hoitaakseen yksi kerrallaan. Kuukausien, joskus vuosien ajan kaksi järjestelmää kirjoittaa samaan liiketoimintaan, ja rekisterin on pysyttävä totena kummallekin.

Tämä on rinnakkaiselon vaihe, ja sillä on tietty tekninen muoto. Vanha järjestelmä muuttaa rivejä jatkuvasti; rekisteri tarvitsee nämä muutokset minuuteissa eikä yöllisenä vientinä; ja se tarvitsee ne muutoksina, jotta yhden laskun korjaus ei tarkoita vuoden datan lataamista uudelleen. Apache Hudi rakennettiin juuri tämän muodon ympärille. Hurukanin datakerros on rakenteilla; tämä teksti kertoo, miten rinnakkaiselon polkua suunnitellaan ja mihin Hudi siinä sijoittuu. Miksi rekisteri on erillään nykytilasta, kerrotaan tekstissä nykytila ja rekisteri.

Mitä rinnakkaiselo vaatii

Muutoksia, ei tilannekuvia. ERP muuttaa tuhansia rivejä tunnissa: tila, maksu, korjattu osoite. Jokaisen taulun yöllinen kopio on sekä liian hidas että liian kallis. Rekisteri tarvitsee muuttuneen rivin sekä sen, mikä se oli ennen ja jälkeen.

Päivityksiä avaimen mukaan. Sama asiakas, tilaus tai lasku saapuu monta kertaa uusin arvoin. Rekisterin on löydettävä juuri tämän avaimen edellinen versio ja korvattava se kirjoittamatta uudelleen osiota, jossa se on.

Inkrementaalista lukemista. Kaiken alavirrassa — ontologian näkymän asiakkaasta, luottopäätöstä valmistelevan agentin, raportin — pitäisi käsitellä se, mikä on muuttunut edellisen ajon jälkeen, eikä koko historiaa uudelleen.

Poistoa avaimen mukaan. Rinnakkaiselon aikana tehdyn poistopyynnön on ulotuttava rekisteriin yhtä varmasti kuin ERP:hen ja oltava todistettavasti valmis siivouksen jälkeen.

Miten muutos saapuu

ERP:n tietokanta kirjoittaa jo omien muutostensa lokia omaa palautumistaan varten. Muutosdatan kaappaus (change data capture) lukee tämän lokin ja julkaisee jokaisen muutoksen tapahtumana. Hurukanin rakenteilla olevassa suunnittelussa tapahtuma kantaa sopimusta, jonka sarja kuvaa tekstissä Apache Avro, joten vastaanottaja tietää rivin muodon ennen ja jälkeen.

Sieltä Hudi Streamer, projektin oma syöttötyökalu, lukee Kafkasta tai suoraan Debeziumin muutostapahtumista jatkuvassa tilassa, skeemarekisterin kanssa, ja kirjoittaa taulun (tarkistettu 21. lokakuuta 2026). Tavalliseen tapaukseen ei kirjoiteta koodia; konfiguraatio on suunnitelma, ja Hurukanissa se on ehdotus, jonka agentti laatii ja ihminen hyväksyy.

Mitä Hudi tekee sillä

Hudi antaa jokaiselle tietueelle avaimen ja pitää indeksiä siitä, missä avain sijaitsee, joten päivitys koskee avaimen sisältävää tiedostoryhmää eikä osiota. Indeksidokumentaatio luettelee taulun metatiedoissa pidettävät vaihtoehdot: Bloom-suodattimet, tietuetason indeksi, joka voi olla globaali, sekä toissijaiset indeksit ja lausekeindeksit, jotka lisättiin julkaisussa 1.0.0 (tarkistettu 21. lokakuuta 2026).

Kaksi taulutyyppiä vastaa kahteen tarpeeseen, jotka on kuvattu sivulla taulutyypit. Copy-on-Write kirjoittaa Parquet-perustiedoston uudelleen jokaisen muutoksen yhteydessä; lukeminen on yksinkertaista ja nopeaa. Merge-on-Read lisää muutokset lokitiedostoihin perustiedoston viereen ja yhdistää ne luettaessa; tiivistys (compaction) yhdistää ne taustalla uusiksi perustiedostoiksi. Rinnakkaiselon aikana ERP-taulut ovat yleensä Merge-on-Read-tyyppisiä, koska kirjoitukset eivät koskaan lakkaa; raporttitaulu, joka muuttuu kerran päivässä, voi olla Copy-on-Write.

Jokainen toiminto päätyy taulun aikajanalle (timeline) — commit, delta commit, tiivistys, siivous, palautus — tiloineen pyydetty, käynnissä ja valmis, ja historia arkistoidaan LSM-rakenteeseen. Ajantasainen on syyskuun 2026 1.2.1; sitä edeltäneet 1.1.0 ja 1.0.0 rakensivat aikajanan ja indeksit uudelleen (tarkistettu 21. lokakuuta 2026).

Rekisterin kannalta kolme seurausta on tärkeitä. Kyselyt voivat olla inkrementaalisia: anna minulle se, mikä on muuttunut tämän hetken jälkeen, viimeisimpänä tilana tai ennen- ja jälkeen-kuvina. Useampi kirjoittaja voi jakaa Merge-on-Read-taulun estottoman samanaikaisuuden hallinnan (non-blocking concurrency control) avulla, jonka samanaikaisuusdokumentaatio rajaa tiettyihin indeksityyppeihin eikä vielä klusterointiin. Ja poisto avaimen mukaan on tavallinen kirjoitus, joka on lopullinen, kun siivooja poistaa vanhat tiedostoversiot.

Mitä ihmiset päättävät

Avain. Mikä kenttien yhdistelmä tunnistaa rivin vanhassa järjestelmässä ja pysyykö se vakaana koko siirtymän ajan. Väärä avain monistaa asiakkaat koko rekisterin eliniäksi.

Taulutyyppi ja tiivistyksen budjetti. Merge-on-Read pitää kirjoitusviiveen pienenä ja siirtää kustannuksen tiivistykseen, joka toimii jatkuvasti ja maksaa jatkuvasti. Agentti ehdottaa aikataulua; ihminen allekirjoittaa kustannuksen.

Säilytys ja siivooja. Se, kuinka monta tiedostoversiota säilytetään, on sama päätös kuin se, kuinka kauas “mitä agentti näki” ulottuu, ja se, milloin poistettu henkilö on poissa. Se asetetaan taulukohtaisesti ja kirjataan.

Missä moottorit ovat. Spark, Flink, Trino ja Presto lukevat Hudia natiivisti. Yritys, jonka muut työkalut odottavat Icebergiä tai Deltaa, tavoittaa Hudi-taulun metatietojen kääntämisen kautta, niin rajoituksin kuin sarja kuvaa tekstissä XTable ja UniForm. Se on syy pitää Hudi siellä, missä se ansaitsee paikkansa — rinnakkaiselon polulla — eikä kaikkialla.

Data-kerros kuvaa liittimet ja sen yhden tietomallin, jota tämä polku syöttää. Kun viimeinen prosessi on siirtynyt moduuliin, ERP lakkaa kirjoittamasta, muutosvirta päättyy ja rekisteri jatkaa huomaamatta mitään.

Testi, jonka voit tehdä tänään

Valitse ERP:stäsi yksi taulu, joka muuttuu koko päivän: tilausrivit tai maksut. Kysy, miten se tänään päätyy raportointiin, ja kirjaa kolme lukua: kuinka vanha kopio on, kun joku lukee sitä, kuinka suuri osa taulusta ladataan uudelleen yhden päivän muutosten viemiseksi ja kuinka kauan kestää, ennen kuin poistopyyntö on siellä todistettavasti valmis. Nämä kolme lukua rinnakkaiselon polun on voitettava.