--- title: "Delta Lake: kun yritys seisoo Microsoftin päällä" url: "https://hurukan.com/fi/blog/delta-lake-kun-yritys-seisoo-microsoftin-paalla" description: "OneLake tallentaa taulut Delta Parquet -muodossa. Mitä Delta-loki antaa yrityksen rekisterille, mitä Fabric hoitaa puolestasi ja mitä päätät edelleen itse." --- # Delta Lake: kun yritys seisoo Microsoftin päällä 1\. lokakuuta 2026·3 min lukuaika·Toimitus Talouden controller sivulta kuvattuna seisomapöydän ääressä avokonttorissa, leveällä näytöllä abstrakti sinertävänharmaa pääkirja ja sarake versionumeroita, toisella näytöllä kalenteri, harmaat seinät ja ohut sininen LED-nauha pöydän alla Yritys on toiminut Microsoftin varassa viisitoista vuotta. Sähköpostit, dokumentit ja kokoukset Microsoft 365:ssä, raportit Power BI:ssä ja viime aikoina Fabric-työtila, johon datatiimi tuo otteita ERP:stä. Kun tällainen yritys harkitsee käyttöjärjestelmää koko liiketoiminnalle, IT:n ensimmäinen kysymys on perusteltu: päätyykö rekisteri paikkaan, jota työkalumme vielä osaavat lukea? Tällaisessa asemassa olevalle yritykselle vastaus kulkee Delta Laken kautta. OneLake, Fabricin alla oleva tallennus, säilyttää taulunsa Delta Parquet -muodossa [Microsoftin dokumentaation](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview) mukaan, joten Delta-muotoinen rekisteri on rekisteri, jonka Fabric lukee ilman kopiota. Hurukanin integraatio Microsoft 365 Copilotiin on suunnitteilla, ei käytössä, ja datakerros on rakenteilla; tämä teksti kertoo, mitä Delta Lake antaa rekisterille tässä ympäristössä ja mitä yritys päättää edelleen itse. Miksi rekisteri ylipäätään on olemassa, kerrotaan tekstissä [nykytila ja rekisteri](https://hurukan.com/fi/blog/nykytila-ja-rekisteri-kaksi-muistia). ## Mitä loki tekee Delta Lake lisää Parquet-tiedostojen hakemistoon yhden asian: transaktiolokin. `_delta_log/` sisältää yhden JSON-tiedoston jokaista commitia kohden, nimettynä version mukaan, ja jokainen luettelee, mitkä tiedostot lisättiin tai poistettiin ja mikä on skeema ja protokolla. Säännölliset Parquet-tarkistuspisteet tiivistävät lokin, jotta lukijan ei tarvitse käydä sitä läpi alusta. Tämän määrittelee [protokolladokumentti](https://github.com/delta-io/delta/blob/master/PROTOCOL.md); ajantasainen julkaisu on [4.4.0](https://github.com/delta-io/delta/releases) (tarkistettu 21. lokakuuta 2026). Tästä yhdestä mekanismista seuraa kaikki, mitä rekisteri tarvitsee. Kirjoitus on atominen, koska commit-tiedosto joko on olemassa tai ei ole. Lukijat näkevät kokonaisen version, koska ne lukevat numeroidun commitin eivätkä hakemistolistausta. Kaksi kirjoittajaa ei turmele toistensa työtä, koska optimistinen samanaikaisuuden hallinta havaitsee ristiriidan commit-hetkellä. Ja “taulu sellaisena kuin se oli, kun agentti ehdotti tätä” on versionumero, mikä tekee tarkastuskysymykseen vastaamisesta mahdollista. ## Rekisterin kannalta tärkeät ominaisuudet Deltan taulukohtaiset ominaisuudet (table features) otetaan käyttöön taulu kerrallaan ja kirjataan protokollaan, joten lukija tietää, pystyykö se lukemaan sen, mitä katsoo. [Versiointisivu](https://docs.delta.io/latest/versioning.html) luettelee ne sekä niiden edellyttämät lukija- ja kirjoittajaversiot (tarkistettu 21. lokakuuta 2026). Neljä niistä muovaa yrityksen rekisteriä. **Poistovektorit** (deletion vectors) merkitsevät rivit poistetuiksi kirjoittamatta tiedostoa uudelleen, joten yhden henkilön poistopyyntö ei kirjoita vuoden laskuja uudelleen. Poisto muuttuu lopulliseksi, kun vanhat tiedostot siivotaan (vacuum), mikä on säilytysasetus eikä automaattinen seuraus. **Change Data Feed** näyttää, mikä muuttui kahden version välillä; näin jatkotaulut ja agentit saavat tiedon muutoksesta lukematta kaikkea uudelleen. **Liquid clustering** korvaa kiinteät osiot klusterointiavaimilla, joita voi muuttaa myöhemmin, joten asettelu voi seurata sitä, miten rekisteriä todella kysytään. **UniForm** kirjoittaa Iceberg-metatiedot Delta-lokin viereen, joten Icebergiä lukevat moottorit näkevät saman taulun. Se edellyttää sarakemappausta, on Iceberg-puolelta vain luettava, ja sillä on dokumentoituja rajoituksia poistovektorien ja muutosdatan osalta, jotka on kuvattu sivulla [Delta UniForm](https://docs.delta.io/latest/delta-uniform.html). Sarjan teksti [XTablesta ja UniFormista](https://hurukan.com/fi/blog/yksi-rekisteri-luettavissa-nykyisilla-tyokaluilla) kertoo, mitä sillä saavutetaan. ## Mitä Fabric hoitaa ja mitä ei Hallinnoitu alusta vie yritykseltä oikeaa työtä: tallennuksen, laskennan, moottorit, Power BI -yhteyden ja yhä useammin ylläpitotehtävät. Se on järkevä paikka rekisterille, jos yritys on jo päättänyt seistä Microsoftin päällä. Neljä asiaa jää yrityksen vastuulle, huomasi se sen tai ei. **Luettelo.** OneLake päättää, mikä taulun nimi on, kuka saa lukea sitä ja missä nykyinen versio ilmoitetaan. Tiedostot ovat avoimia; tiedostojen hakemisto on alustan. Irtautumissuunnitelma, jossa lukee “meillä on Parquetia järvessä”, ei ole ottanut tätä hakemistoa huomioon. **Säilytys ja poisto.** Lokin säilytysaika ja vacuum-kynnykset ovat taulun asetuksia. Ne määräävät, kuinka kauas aikamatka (time travel) ulottuu ja milloin poistettu henkilö on todella poissa. Kukaan alustalla ei aseta niitä puolestasi, ja Hurukanissa agentti voi ehdottaa niitä, mutta ei hyväksy niitä. **Ominaisuuksien käyttöönotto.** Uudemman ominaisuuden käyttöönotto nostaa protokollaversiota ja voi sulkea pois vanhemman lukijan muualla yrityksessä. Hyöty on todellinen; niin on myös lukija, joka lakkaa toimimasta. Ihminen päättää taulu kerrallaan, lukijoiden luettelo edessään. **Kirjoituspolku.** Deltaa voi kirjoittaa moni moottori, mutta se, mikä moottori kirjoittaa tiettyä taulua, on suunnittelupäätös, koska siinä on datan omistajuus. Hurukanissa moduulit kirjoittavat rekisterin omaa polkua pitkin ja alusta lukee; päinvastainen järjestely on eri arkkitehtuuri. Mitkä näistä yritys omistaa, on juuri se kysymys, jota käsitellään kohdassa [tietoturva ja suvereniteetti](https://hurukan.com/fi/system/tietoturva-ja-suvereniteetti): yrityksen valitsema infrastruktuuri, yrityksellä pysyvät data ja mallit sekä irtautuminen, joka on käytännössä mahdollinen. ## Missä agentit auttavat ja mihin ne pysähtyvät Delta-rekisterin ylläpito on mekaanista ja jatkuvaa: tiivistystä, vacuumia, tilastoja, klusterointia. Agentit laativat nämä tehtävät hyvin ja selittävät hitaan kyselyn paremmin kuin koontinäyttö. Hurukanissa jokainen tällainen tehtävä on ehdotus hyväksyntäjonossa perusteluineen; ihminen hyväksyy sen, ja se kirjataan kuten mikä tahansa muu muutos. Agentit eivät päätä säilytyksestä, hyväksy protokollan päivitystä eivätkä valitse kirjoituspolkua. Nämä kolme päätöstä määräävät, mitä rekisteri voi myöhemmin todistaa, ja yrityksen on pystyttävä sanomaan, kuka ne teki. ## Testi, jonka voit tehdä tänään Avaa yksi taulu, joka Fabric-työtilassasi jo on, ja etsi kolme asetusta: sen lokin säilytysaika, sen vacuum-kynnys ja lukijalta vaadittu protokollaversio. Jos kaikki kolme ovat siinä, mihin alusta ne jätti, kukaan ei ole vielä päättänyt, kuinka kauas rekisterisi ulottuu tai mitkä työkalusi pystyvät lukemaan sitä ensi vuonna. Se on ensimmäinen päätös, jonka yrityksen rekisteri tarvitsee, eikä sen tekeminen maksa mitään. - Delta Lake - Microsoft Fabric - OneLake - transaktioloki - suvereniteetti ## Lue lisää - [Yksi identiteetti ihmisille ja agenteille: kuka saa tehdä mitä](https://hurukan.com/fi/blog/yksi-identiteetti-ihmisille-ja-agenteille) - [Nykytila ja rekisteri: yrityksen käyttöjärjestelmän kaksi muistia](https://hurukan.com/fi/blog/nykytila-ja-rekisteri-kaksi-muistia)