Hei,
Data Lakehouse on uusi termi joka on hiipinyt data-alan keskusteluun parin viime vuoden aikana.
Alamme markkinointi-ihmisten haasteena on se, että kaikki hyvät nimet on jo käytetty ja monet niistä myöskin pilattu, usein juuri markkinoinnin lataamien ylisuurten odotusten seurauksena.
Data Lake eli tietoallas on monien mielestä yksi pilaantuneista termeistä, mikä on ymmärrettävää huomioiden, että tietoallastoteutuksista valtaosa on epäonnistunut.
Tietoaltaassa itsessään ei kuitenkaan ole vikaa vaan siinä, miten niitä toteutetaan ja hyödynnetään. Tarvittiin siis jälleen uusi termi. Syntyi Data Lakehouse.
Olen tutustunut viime viikkoina Data Lakehousen periaatteisiin sekä siihen, miten Databricks on toteuttanut Data Lakehouse -arkkitehtuuria.
Databricks ei termiä keksinyt, mutta se on alan toimijoista aktiivisimmin termin omaksunut kuvatessaan omaa tietoalusta-arkkitehtuuriaan.
Databricks on myös kustantajana Bill Inmonin uudessa kirjassa “Building the Data Lakehouse”.
Nimillä kikkailusta voi olla montaa mieltä, mutta uuden nimen alta löytyy viisaista ajatuksia, ja ensituntumalta myös toimivia toteutusratkaisuja.
Tietovaraston ja tietoaltaan viha-rakkaussuhde
Tietoallas tuli ja sen piti korvata tietovarastot. Tietoaltaita rakennettiin ensin Hadoopin ja myöhemmin pilvitallennusratkaisujen päälle. Tämä tarjosi relaatiotietokantaa edullisemman vaihtoehdon tietojen tallentamiseen ja monien mielestä riittävät välineet tiedon kyselyyn.
Kuitenkin relaatiotietokannat osoittautuivat edelleen ylivoimaiseksi strukturoidun tiedon tallentamiseen ja varsinkin kyselyyn. Relaatiomalliin perustuvat tietovarastot voivat paremmin kuin koskaan, ja yritykset kuten Snowflake ovat uudistaneet niitä onnistuneesti pilvimaailmaan.
Tietoallas kuitenkin vakiinnutti paikkansa suurten tietomassojen tallennusratkaisuna erityisesti strukturoimattoman tiedon osalta. Tietoaltaalla on myös keskeinen rooli tietovaraston lastausalueena (=staging area).
Yhä useampi organisaatio onkin todennut, että molemmilla on tärkeä rooli organisaation tietoalusta-arkkitehtuurissa.
Ongelmaksi on kuitenkin jäänyt se että tietovarasto ja tietoallas harvoin muodostavat yhtenäistä kokonaisuutta. Ne ovat erillisiä hiekkalaatikoita, joilla leikkivät eri ihmiset ja joiden analyyttinen työ erkaantuu toisistaan.
Kokonaisratkaisu Data Lakehousella?
Data Lakehouse pyrkii tarjoamaan ratkaisun, joka palvelee kaikkia niitä tarpeita, joihin on tarvittu erikseen sekä tietovarasto että tietoallas. Se pyrkii tarjoamaan yhtenäisen kokonaisuuden ja välttämään tiedon ja analyyttisen työn erkaantumista tietovarasto- ja tietoallassiiloihin.
Data Lakehouse ponnistaa tietoallasmaailmasta ja pyrkii sieltä laajentumaan tietovaraston tontille.
Kuten tietoaltaassa, myös Data Lakehousen tieto on tiedostoissa (esim. parquet file), joiden tallennusratkaisuna voi toimia mm. Microsoft Azuren, Google Cloudin tai AWS:n object storage -ratkaisut.
Keskeistä on looginen kerros, joka erottaa Data Lakehousen perinteisestä tietoaltaasta. Loogisella kerroksella rakennetaan tiedostojen päälle yhtenäinen metadata ja tietomallit.
Data Lakehousen kaikki tieto on tiedostoissa, myös se strukturoitu tieto, joka yleensä viedään tietovaraston relaatiotietokantaan. Edellä mainitun loogisen kerroksen avulla relaatiotietokannan toiminnallisuudet pitäisi pystyä tarjoamaan tiedostoratkaisun päälle.
Vasta kokemus kertoo kuinka hyvin tämä lupaus pystytään lunastamaan. Onnistuessaan tämä tarjoaa kuitenkin mahdollisuuden operoida kaikkea tietoa – sekä strukturoitua että strukturoimatonta – yhden loogisen kerroksen kautta.
Tämä taas tarjoaa huikeita mahdollisuuksia analyyttiseen työhön, joka nyt on siiloutunut tietovarastoon ja tietoaltaalle.
Analyyttisen työn siiloutuminen
Loppukäyttäjät ja BI-asiantuntijat kyselevät yleensä tietovarastoa.
Sen sijaan Data Scientistit ja erityisesti Machine Learning -kehittäjät tarvitsevat yleensä lähtöjärjestelmien tietoja sellaisenaan, jolloin tietoallas on heidän hiekkalaatikkonsa.
Johonkin rajaan asti järjestely toimii. Kuitenkin tiedolla johdetulla organisaatiolla pitäisi olla mahdollisuus siihen, että BI-asiantuntijoiden huomatessa, että yrityksen tärkeimmän tuotteen myynti sakkaa Yhdysvalloissa, Data Scientistit pystyisivät penkomaan syitä myynnin ongelmiin. Jos ongelmaksi osoittautuisi hinnoittelu, Machine Learning -kehittäjien tulisi pystyä optimoimaan hinnoittelua.
Kaikki ammattiryhmät työskentelevät tällöin saman ongelman parissa, ja heidän pitäisi pystyä operoimaan samalla datalla.
Tosiasiallisesti ammattiryhmät kuitenkin työskentelevät eri datan varassa. Tietovaraston tieto on yhä useammalla organisaatiolla kohtuullisen hyvin mallinnettua, mutta tietoaltaassa tiedot ovat yhtä hyvässä järjestyksessä kuin lähtöjärjestelmissäkin – eli huonossa.
Myös tietoaltaan tiedon pitäisi olla mallinnettua, jotta ammattiryhmät voisivat tehdä organisoidusti yhteistyötä.
Data Lakehousen looginen kerros antaa lupauksen siitä, että tietoaltaan tieto voitaisiin myös organisoida mallin mukaisesti. Tai tarkemmin: Kaikki tieto voitaisiin organisoida mallin mukaisesti. Data Lakehousessa kun ei eritellä tietoallasta ja tietovarastoa.
Miltä Data Lakehouse näyttää käytännössä ja mitä kysymysmerkkejä se jättää
Tutustuin Databricksin Data Lakehouse -toteutukseen.
Databricks perustuu Apache Sparkiin, joka avoimen lähdekoodin skaalatuva analytiikkaratkaisu.
Data Lakehousen kaikki tiedot ovat tiedostoissa. Databricksissä tiedostojärjestelmänä toimii Databricks File System, joka on abstraktiokerros esim. Microsoft Azuren, Google Cloudin tai AWS:n object storage -ratkaisun päällä.
Tiedostojärjestelmässä tiedot sijaitsevat esim. Parque-fileissa, joiden päälle voidaan rakentaa abstraktioita, jolloin tiedot näyttäytyvät käyttäjälle tietokantatauluina tai Data Framena.
Data Frame on tuttu rakenne Data Scientisteille ja Machine Learning -kehittäjille.
Sama rakenne saadaan näyttäytymään heille Data Framena ja tietovarastoammattilaisille tietokantauluna.
Näille tauluille voidaan tehdä operaatioita SQL:llä, Scalalla, Pythonilla tai R:llä, mikä onkin kunkin käyttäjän parhaiten tuntema kieli. Peräkkäisiä operaatioita voi samakin käyttäjä tehdä eri kielillä. Pystyin esimerkiksi tekemään tauluille ensin muokkausoperaatioita Pythonilla ja sen jälkeen kyselemään niitä SQL:llä.
Delta Laken avulla – joka on myös yksi abstraktiokerros tiedostorakenteen päälle – näille tauluille saadaan ACID-ominaisuudet.
Kaikki näytti hyvältä ja sujuvalta Databricksin tarjoamisessa esimerkkiharjoitustehtävissä. Luonnollisesti Databricks on valinnut harjoitustehtäviin happy case -skenaarioita. Puutteet tulevat esille vasta käytännön työssä ajan kanssa.
Oman mielenkiintoni konsepti ja Databricksin ratkaisu herätti. Puutteet ilmenevät vasta kokemuksen kautta, mutta mahdollisuudet olivat kyllä vakuuttavat.
Tällaisella ratkaisulla voidaan yhdistää eri analyyttisten heimojen työ yhteisen päämäärän eteen tavalla, joka ei ole sujuvaa nykyisillä arkkitehtuureilla, joissa tietovarasto ja tietoallas ovat valitettavsti siiloutuneet eri ammattiryhmien hiekkalaatikoiksi.
Suurin kysymysmerkki minulla ei liitykään Databricksin ratkaisuun, vaan Data Lakehousen voittokulkuun yleisesti.
Bill Inmon korostaa kirjassaan avoimen lähdekoodin ratkaisujen tärkeyttä Data Lakehousen perustana. Perustelujen läpikäyminen olisi ihan omankin blogikirjoituksen aihe, mutta lyhyesti sanoen avoimuuden etuna on se, että päästään ratsastamaan kehityksen aallonharjalla.
Omana huomiona lisäisin sen, että maailmalla trendi on menossa monoliittisista tietoalustaratkaisuista kohti hajautettuja Data Mesh -ratkaisuja, jolloin avointen ratkaisujen integroituvuus nousee suureen arvoon.
Suurin kysymysmerkki liittyykin siihen, miten muut pelurit kuin Databricks lähtevät mukaan Data Lakehouse -liikehdintään. Vaikka Databricks pohjautuu avoimen lähdekoodin ratkaisuihin, toimittajalukon välttäminen vaatisi, että uskottavia pelureita olisi tarjolla useita.
Ystävällisin terveisin,
Hannu Järvi
Ps. Itse Bill Inmon pitää meille ilmaisen webinaarin Data Lakehousesta:
BIll Inmon Architecture and the Data Lakehouse 10.11. – 11.11.2021 (klo 16-18.00 kumpanakin päivänä)
Bill “The father of the data warehouse” Inmon on kaikkien data-osaajien tuntema alan ehdoton legenda. Hän on kirjoittanut kirjan yhdessä Databricksin kanssa aiheesta Data Lakehouse. Onko kyseessä jälleen yksi hype vain todellinen game changer? Kannattaa tulla linjoille, niin tiedät mistä data-alalla puhutaan!
Osallistu ilmaiseen webinaariin tästä.
Mikäli haluat kattavamman näkemyksen Data Lakehousesta sekä Data Meshistä, kannattaa tutustua:
Creating Data Products in a Data Mesh, Data Lake or Lakehouse for Use In Analytics 03.02 – 04.02.2022
Kurssin vetäjä Mike Ferguson on kansainvälisesti arvostettu data-alan osaaja sekä teknologia-analyytikko. Hän on erikoistunut uusien teknologioiden, menetelmien ja arkkitehtuurien tutkimiseen sekä analysointiin.
Kaikkien data-alalla työskentelevien asiantuntijoiden sekä konuslttien on hyvä olla perillä uusista kehityssuunnista ja tietää mistä alalla puhutaan. Mike ei ole mikää hype-mies, vaan suhtautuu uusiin menetelmiin tarvittaessa myös hyvin kriittisesti.
Voit tutustua kurssin sisältöön tarkemmin tästä.
