Apache Paimon: yksi tilataulu operaattorille, suunnittelijalle ja agentille

Tuotannonsuunnitteluhuone sivulta kuvattuna: suunnittelija pöydän ääressä, näytöllä abstrakti sinertävänharmaa työtaulu, lasiseinän takana kokoonpanolinja, jossa operaattori katsoo seinälle kiinnitettyä päätettä samoin muodoin, yksi sininen merkkivalo linjan yläpuolella

Kokoonpanotilaus vaihtaa tilaa yksitoista kertaa vapautuksen ja toimituksen välillä: suunniteltu, vapautettu, aloitettu ensimmäisellä työpisteellä, pysäytetty puuttuvan osan vuoksi, jatkettu, tarkastettu, yksi yksikkö hylätty, korjattu, pakattu, vahvistettu, lähetetty. Työpisteen operaattori näkee oman vaiheensa päätteellä moduulissa Toiminnot ja laatu. Suunnittelija näkee tilauksen taululla. Toimintoagentti, jolta kysytään, pitääkö viikon suunnitelma yhä, näkee raportin. Kolme näkymää ja useimmissa yrityksissä kolme taulua, jotka päivitetään kolmen eri aikataulun mukaan, joten joka iltapäivä tunnin ajan operaattori, suunnittelija ja agentti uskovat kukin eri asian samasta tilauksesta.

Hurukanin datakerros on suunniteltu niin, että tilauksella on yksi tilataulu ja kaikki lukevat sitä. Pääteksti selittää, miksi nykytila on eri muisti kuin rekisteri. Tämä teksti kertoo muodosta, jolla taulu rakennetaan, Apache Paimonista, ja siitä, mitä valinta maksaa. Kerros on rakenteilla; näin sitä suunnitellaan.

Taulu, jota päivitetään eikä jatketa

Useimmat lakehousen taulumuodot olettavat, että data saapuu ja jää. Uudet rivit muuttuvat uusiksi tiedostoiksi; rivin muuttaminen tarkoittaa tiedoston uudelleenkirjoittamista tai sen merkitsemistä poistetuksi. Se on oikea rakenne rekisterille, jossa mitään ei koskaan muuteta. Se on väärä rakenne tilaukselle, jonka tila muuttuu yksitoista kertaa ennen kuin se on valmis.

Apache Paimon on muodoltaan toisenlainen. Sen pääavaintaulut pitävät rivit avaimen mukaan järjestettyinä lohkoissa (buckets) log-structured merge -puussa (LSM): uudet versiot saapuvat ylimmälle tasolle, ja taustalla tapahtuva tiivistys yhdistää ne alempiin järjestettyihin tiedostoihin, joten taulu pysyy tiiviinä, kirjoitettiinpa samoja avaimia uudelleen kuinka usein tahansa (Paimonin taulutyypit, tarkistettu 21. lokakuuta 2026). Lukija näkee jokaisen avaimen uusimman version käymättä läpi historiaa. Taulut ilman pääavainta ovat lisäystauluja (append tables), jotka sopivat rekisteripuolelle; tässä olennaista on pääavaintaulu. Ajantasainen julkaisu on 2.0.0 7. elokuuta 2026 (julkaisuluettelo).

Yhdistämismoottorit ovat ontologian sääntöjä

Paimonista nopeaa päivitystaulua enemmän tekee se, että muoto itse päättää, miten rivin uusi versio yhdistyy vanhaan. Paimon kutsuu tätä yhdistämismoottoriksi (merge engine), ja datakerroksessa jokainen valinta vastaa sääntöä, jonka ontologia jo esittää objektista.

Deduplicate, oletus: uusin versio voittaa. Oikea sääntö tilauksen tilalle — viimeisin tapahtuma on totuus.

Partial update: jokainen kirjoittaja täyttää vain omat sarakkeensa. Tilauksen tilarivillä on suunnitellut päivämäärät suunnittelusta, todellinen aloitus ja lopetus työpisteen päätteeltä, tarkastustulos laadusta ja pakattu määrä varastosta. Neljä moduulia, yksi rivi, eikä mikään niistä kirjoita toisten päälle. Sekvenssiryhmät (sequence groups) antavat jokaiselle sarakejoukolle oman järjestyksensä, joten työpisteen myöhässä saapunut viesti ei voi kumota laadun myöhempää viestiä (partial update).

Aggregation: luvut lasketaan yhteen tapahtumien yli — työvaiheelle kirjatut tunnit, valmiit yksiköt, hylätyt yksiköt.

First row: ensimmäinen versio säilytetään. Hyödyllinen siellä, missä ontologia sanoo arvon asetettavan kerran, kuten hetki, jolloin tilaus vapautettiin.

Ontologiassa nämä kuvataan objektin ominaisuuksina: mikä kenttä asetetaan kerran, mikä kertyy, mikä kuuluu millekin moduulille. Kun ne ilmaistaan taulun määrittelyssä, sääntö pätee jokaiselle kirjoittajalle, myös agentin rakentamalle putkelle, jota ei ollut olemassa säännön kirjoittamishetkellä.

Yksi taulu, kolme lukijaa, yksi muutosloki

Operaattorin pääte, suunnittelijan taulu ja agentin näkymä ovat saman taulun kolme lukijaa, kukin eri tavalla suodatettuna. Flink kirjoittaa sen moduulien tapahtumavirrasta ja lukee sen takaisin lookup join -liitoksissa. Myös Spark, Trino, Hive, StarRocks ja Doris lukevat sitä (moottorituki), joten raporttimoottori ja muistikirja näkevät saman rivin, jonka pääte näyttää.

Taulu tuottaa myös omat muutoksensa. Muutoslokin tuottaja (changelog producer) — input, lookup tai full-compaction, taulukohtaisesti valittuna — muuttaa jokaisen yhdistetyn muutoksen virraksi. Toimintoagentti tilaa tapahtuman “tilaus pysäytetty” sen sijaan, että kävisi taulua läpi, ja suunnittelunäkymä päivittyy, koska taulu muuttui, eikä siksi, että joku painoi päivityspainiketta.

Tarkastusta varten Paimon säilyttää tilannekuvat ja antaa tagin kiinnittää niistä yhden pysyvästi. Kun agentti ehdotti kolmen tilauksen siirtämistä seuraavalle viikolle, sillä hetkellä otettu tagi näyttää taulun, jota se katsoi. Ehdotus, päätös ja tilannekuva ovat rekisterissä vierekkäin.

Mitä se maksaa

Paimonin tilataulu ei ole ilmainen, ja datakerros kertoo laskusta rehellisesti.

Tiivistys ei koskaan lopu. LSM-puu pidetään tiiviinä taustatyöllä, joka kuluttaa laskentaa jatkuvasti. Mitä useammin avaimia kirjoitetaan uudelleen ja mitä tuoreempi taulun on oltava, sitä enemmän se maksaa. Siksi kaikki kerroksen taulut eivät ole Paimon-tauluja: rekisteri itse, joka vain kasvaa, ei sitä tarvitse.

Virtakäsittelymoottori on edellytys. Tilan jatkuva kirjoittaminen tarkoittaa Flinkin jatkuvaa ajamista, ja jonkun on vastattava siitä. Yritysten, joilla tätä kyvykkyyttä ei ole, kannattaa aloittaa tauluista, joita eräajot päivittävät minuuttien välein, ja siirtyä virtoihin vain siellä, missä päätös tarvitsee sekunteja.

Avaimen on oltava oikea. Pääavaintaulu on vain niin hyvä kuin sen avain. Jos ontologia ei vielä kerro, mikä tunnistaa tilauksen moduulien välillä, taulua ei voi rakentaa, ja rehellinen ensimmäinen askel on ontologia, ei muoto.

Agentit auttavat rutiiniosassa: ne ehdottavat lohkojen määriä ja tiivistysaikatauluja, laativat putken, joka kohdistaa moduulien tapahtumat riville, ja huomaavat, kun taulun viive kasvaa. Ihmiset päättävät avaimen, yhdistämissäännön ja sen, kuinka kauan tilannekuvia säilytetään — koska ne ovat väitteitä siitä, mitä yritys pitää totena.

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

Ota yksi objekti, jota useampi tiimi seuraa — tilaus, työ, lähetys — ja pyydä jokaista tiimiä näyttämään, mistä he sen katsovat. Laske näytöt. Valitse sitten yksi kenttä, esimerkiksi valmis määrä, ja kysy jokaiselta, mitä se juuri nyt näyttää.

Jos vastaukset eroavat, olet löytänyt rivin, jonka datakerros on suunniteltu pitämään kerran. Jos ne täsmäävät vain siksi, että joku täsmäyttää ne joka iltapäivä, olet löytänyt henkilön, joka tekee käsin sen, minkä yhdistämismoottori tekee muodossa.