Miten hallita kasvavia datamassoja tehokkaasti – Data Lakehouse korjaa perinteisen tietovaraston pullonkaulat

Datamäärien kasvu haastaa perinteiset tietovarastoratkaisut

Käytettävissä olevan tiedon määrä nyky-yhteiskunnassa kasvaa räjähdysmäisesti, mikä asettaa jatkuvasti kovenevia vaatimuksia yritysten tietovarastoratkaisuille. Tämä kehitys ei myöskään osoita hidastumisen merkkejä – päinvastoin, kasvuvauhti kiihtyy edelleen.

Kolme keskeistä datan ominaisuutta – datan volyymi (volume), datan saapumisnopeus (velocity) ja datan vaihtelevuus (variety) – ovat kaikki kasvussa. Yhdessä nämä kolme V:tä asettavat omat tekniset vaatimuksensa, ja mahdollisuutensa, tietovarastoratkaisulle.

Kun datan määrä ja saapumisnopeus kasvavat, perinteiset relaatiotietokannat käyvät kalliiksi 

Perinteiset tietovarastot pohjautuvat usein relaatiotietokantapalvelimiin, joissa data tallennetaan suoraan rakenteiseen taulumuotoon (schema-on-write). Itse tietokantapalvelin voi sijaita joko yrityksen omassa konesalissa tai pilvessä, esimerkiksi Azure SQL -palveluna. Näissä ratkaisuissa tallennus- ja laskentaresurssit ovat kiinteästi sidoksissa toisiinsa, mikä rajoittaa tietovaraston joustavuutta ja skaalautuvuutta.

Relaatiotietokannat soveltuvat hyvin operatiivisiin käyttötarkoituksiin, joissa käsitellään nopeasti pieniä määriä dataa – yksittäisiä rivejä tai joitain satoja tai tuhansia rivejä kerrallaan. Ne eivät kuitenkaan ole optimaalisia analyyttisiin kuormiin, joissa operoidaan miljoonien rivien ja gigatavujen tietomäärien kanssa. Usein relaatiotietokantojen ongelmat johtuvat tauluindeksien ylläpidosta, jota vaaditaan datan nopeaan lukuun, mutta joka hidastaa hyvin paljon suurien datavolyymien kirjoitusta tietokantatauluihin. Indeksit myös kasvattavat tietokannan vaatiman varastotilan käyttöä huomattavasti.

Lisäksi kirjoitustapahtumien eheyden varmistavat transaktiolokit voivat kasvaa huomattavan suuriksi, mikä puolestaan lisää tarvetta prosessointimuistille, jotta kirjoitustapahtumat saadaan toteutettua. Näin ollen perinteiset relaatiotietokannat eivät skaalaudu riittävästi kasvaviin datamääriin – ainoana vaihtoehtona on usein kallis laskenta- ja varastointiresurssien lisäys tietokantapalveluun. 

Myös datan monimuotoisuus tuottaa haasteensa

Myös datatyyppien vaihtelevuus aiheuttaa ongelmia. Relaatiotietokannat on suunniteltu taulumuotoiselle datalle, eikä niihin voida tallentaa tehokkaasti ei-taulumuotoista dataa (esim. PDF-, kuva- tai videotiedostot) suoraan ilman kompromisseja. Tällainen data joudutaan usein tallentamaan binääridatana taulun soluun (BLOB, Binary Large Object), mikä nostaa tietokannan varastointikapasiteetin tarvetta huomattavasti ja kasvattaa siten myös tallennuskustannuksia. Näin tallennetun ei-taulumuotoisen datan jatkokäyttökään ei ole kovinkaan helppoa tai tehokasta.

Ratkaisuna Data Lakehouse -arkkitehtuuri

Vastauksena perinteisten relaatiotietokantojen skaalautuvuus- ja joustavuusongelmiin on noussut Data Lakehouse -arkkitehtuuri, joka pohjautuu avoimen lähdekoodin teknologioihin. Sen ytimessä on ajatus tallennus- ja laskentakerroksen selkeästä erottamisesta: edullinen tallennustila (esimerkiksi Azure Storage Account, n. 20 €/kk per teratavu) on erotettu hintavammasta laskentakapasiteetista, joten molemmat voidaan valita ja mitoittaa käyttötarpeen mukaan.

Data voidaan tallentaa alkuperäisessä muodossaan raakadatana – kuten .pdf-, .json-, .csv- tai videotiedostoina – jolloin sitä on helppo lukea ja käyttää myöhemmin ilman muuntamista toiseen formaattiin. Vaihtoehtoisesti dataa voidaan myös tallentaa taulumetadatan sisältävässä muodossa, kuten Delta Table tai Apache Iceberg -formaateissa. Näissä muodoissa dataa voidaan lukea tauluna joustavalla schema-on-read-periaatteella, aivan kuin se olisi relaatiotietokannassa. Esitettäviä taulurakenteita voidaan kuitenkin muokata joustavasti, koskematta itse raakadataan.

Delta- ja Iceberg-formaatit tuovat mukanaan muitakin hyödyllisiä ominaisuuksia:

• Datan versiointi, joka mahdollistaa muutosten hallinnan ja seuraamisen aikajanalla.
  
  
• Muutosdata (Change Data Capture), jolla voidaan seurata ja hyödyntää tapahtuneita muutoksia.
  
  
• ACID-tuki (Atomicity, Consistency, Isolation, Durability), mikä mahdollistaa turvallisen, monen käyttäjän yhtäaikaisen datan käytön.

Näiden dataformaattien avulla useat käyttäjät voivat siis lukea ja kirjoittaa dataa samanaikaisesti transaktioina – kuten relaatiotietokannoissa – ja versiointi toimii ilman lisätyötä. Transaktiolokit tallennetaan tiedostomuodossa suoraan tietovarastoon, mikä mahdollistaa läpinäkyvän, tehokkaan ja ennen kaikkea kustannustehokkaan datanhallinnointiratkaisun. 

Laskentakapasiteetti tarpeen mukaan

Koska Data Lakehouse -arkkitehtuurissa laskenta on erotettu datan varastoinnista, voidaan valita käyttöön parhaiten kuhunkin tarpeeseen sopiva, yksi tai useampi, laskentapalvelu. Pieniin ja toistuviin prosesseihin sopii hyvin esimerkiksi Azure Function, jossa voidaan ajaa muun muassa Python- tai C#-koodia kevyesti. Myös Azure Logic Apps tarjoaa helppokäyttöisen graafisen työkalun, jolla voidaan toteuttaa yksinkertaisia ehtoperustaisia dataprosesseja ilman koodausta.

Suurten datamassojen käsittelyyn soveltuvat hajautettua laskentaa hyödyntävät analytiikkamoottorit, kuten Apache Spark, jota käytetään esimerkiksi Azure Databricksissä ja Microsoft Fabricissa. Sparkin avulla voidaan prosessoida skaalautuvasti koko tietovarastoon tallennettua dataa ja kirjoittaa prosessoitu tieto takaisin tietovarastoon loppukäyttäjiä varten.

Datan tarjoilu ja kysely SQL:n avulla

Prosessoitu data voidaan tarjota loppukäyttäjille helposti esimerkiksi Delta Table -liittimien kautta. Työkaluja tähän ovat esimerkiksi Power BI:n Delta Connector ja Delta Sharing, jotka mahdollistavat datan hyödyntämisen suoraan itse visualisointityökalussa tai muiden järjestelmien kautta.

Lisäksi tietovaraston päälle voidaan virtualisoida SQL-päätepiste, käyttämällä esimerkiksi Azure Synapse SQL on-demand -ratkaisua tai Fabric Lakehouse -palvelimettomia SQL-laskentamoottoreita. Näissä SQL-kyselyt voidaan kohdistaa suoraan tietovarastoon ilman, että dataa tarvitsee kopioida tai ladata tietokantaan. 

Tärkeä SQL-luvun suorituskykyä parantava ominaisuus on predikaatin alastyöntö (predicate pushdown), joka hyödyntää esimerkiksi Delta Table- ja Apache Iceberg -formaattien taulujen metatietoja ja optimointitekniikoita. Kun SQL-kysely suoritetaan, moottori lukee vain ne tiedostot, joissa kyselyn kohteena oleva data voi sijaita. Tämä parantaa huomattavasti koko lukuoperaation suoritustehoa ja vähentää tarvittavan prosessointikapasiteetin käyttöä.

Delta Table -formaatti käytettäessä datannoudon optimointitekniikoita ovat muun muassa:

• Partitiointi, joka jakaa datan loogisiin osiin esim. aikajaksoittain, jolloin vain tarvittavat loogiset osat luetaan kyselyn aikana.
  
  
• Z-ordering, joka järjestää dataa tiedostojen kesken uudelleen nopeampia hakuja varten.
  
  
• Liquid Clustering, joka sallii joustavamman datan partitioinnin hallinnan ilman tiedostojen uudelleen kirjoitusta.

Näiden optimointitekniikoiden ansiosta voidaan suorittaa huomattavan nopeita hakuja sadoista miljoonista riveistä (3–5 sekuntia) ja sekä kirjoittaa suuria datamääriä ilman indeksien ylläpidon aiheuttamaa hidastusta – toisin kuin perinteisissä relaatiotietokannoissa.

Kustannusmalli käyttöperusteisesti

Koska laskentakapasiteetti ja SQL-virtualisointi on erotettu varsinaisesta tietovarastoinnista, voidaan datan prosessointi toteuttaa kulutuspohjaisella (pay-as-you-go) mallilla. Tämä tarkoittaa, että kustannuksia syntyy vain silloin, kun dataa todella prosessoidaan – ei esimerkiksi palvelimen pidosta jatkuvasti käyttövalmiudessa.

Data Lakehouse -arkkitehtuuri mahdollistaa näin suurien tietomäärien edullisen säilyttämisen ja kustannustehokkaan käsittelyn. Halvan varastoinnin seuraksena kustannukset pääsääntöisesti määräytyvät datan käytön, ei sen olemassaolon, mukaan.

Apache Spark – tehokas moottori suurten datamassojen käsittelyyn

Erityisen keskeisessä roolissa Lakehouse-arkkitehtuurissa on jo mainittu Apache Spark, joka on hajautetun laskennan analytiikkamoottori. Sen ansiosta voidaan käsitellä suuria määriä dataa tehokkaasti ja edullisesti – sellaisia määriä, joiden käsittely relaatiotietokannoissa olisi joko hidasta, kallista tai teknisesti haastavaa tekniikan rajoitteiden vuoksi.

Apache Sparkin neljä ominaisuutta, jotka mahdollistavat nopean ja kustannustehokkaan datan prosessoinnin

Modernisoinnin hetki on nyt

Yritykset, jotka haluavat pysyä mukana kilpailussa datavetoisessa maailmassa, eivät voi enää nojata pelkästään vanhoihin relaatiotietokantaratkaisuihin. Data Lakehouse -arkkitehtuuri tarjoaa modernin, joustavan ja kustannustehokkaan tavan käsitellä valtavia ja monimuotoisia tietomääriä. Se ei ainoastaan ratkaise tämän päivän datahaasteita – se myös rakentaa vankan perustan tulevaisuuden analytiikalle, tekoälylle ja liiketoimintapäätöksenteolle.

Yhteenveto perinteisten relaatiotietokantojen ja Data Lakehouse -arkkitehtuurin eroista