Lakehouse-Arkkitehtuurin Selitys

Jotta ymmärtäisi, miksi Lakehouse on merkittävä edistysaskel, on tarkasteltava "vanhaa tapaa" toimia – järjestelmää, jonka kanssa monet yritykset kamppailevat edelleen. Vuosikymmenten ajan datamaailma oli jakautunut kahteen erilliseen saareen, jotka eivät yksinkertaisesti puhuneet samaa kieltä.

Ensimmäisellä saarella oli Data Warehouse. Ajattele tätä erittäin järjestäytyneenä, korkeatasoisena kirjastona. Kaikki on omilla paikoillaan, taulukoihin luokiteltuna ja optimoituna SQL-käyttäjille raportointia varten. Tämän kirjaston ylläpito on kuitenkin hyvin kallista. Se on myös melko jäykkä; se hyväksyy vain tietyn kokoisia ja muotoisia kirjoja. Jos yritit tuoda raakavideotiedostoja, sekavia sosiaalisen median syötteitä tai valtavia verkkolokeja, Warehouse ei yksinkertaisesti pystynyt käsittelemään niitä.

Toisella saarella yritykset rakensivat Data Lakeja. Jos Warehouse on kirjasto, Lake on valtava digitaalinen "ullakko" tai laaja varastotila, johon voi edullisesti dumpata kaiken raakadatan – kuvat, sensoridata, äänet, mitä tahansa. Vaikka ne olivat hyviä kaiken tallentamiseen, niistä tuli nopeasti niin sanottuja "Data Swampeja". Koska järjestystä tai laadunvalvontaa ei ollut, tietyn tiedon löytäminen oli kuin neulan etsimistä heinäsuovasta. Lisäksi niitä oli erittäin vaikea kysellä tavallisella SQL:llä, mikä teki niistä lähes saavuttamattomia perinteisille liiketoiminta-analyytikoille.

"Sekava" välimuoto

Suurin ongelma ei kuitenkaan ollut vain nämä kaksi saarta – vaan niiden välinen silta. Jotta data saatiin siirrettyä "Lakesta" "Warehouseen" raportointia varten, insinöörien piti rakentaa monimutkaisia, hauraita putkistoja, joita kutsutaan ETL:ksi (Extract, Transform, Load). Tämä johti kolmeen merkittävään "dataongelmaan":

• Vanhentunut data: kun data oli siirretty, puhdistettu ja muotoiltu lakesta warehouseen, se oli usein tuntien, päivien tai jopa viikkojen ikäistä. Nykyaikaisessa liiketoiminnassa eilinen data on usein liian myöhäistä;
• Epäjohdonmukaisuus: syntyi usein "totuuden versio" -ongelma. Python-kehittäjä, joka työskentelee raakatiedostojen kanssa Lakessa, saattoi laskea katteen eri tavalla kuin SQL-analyytikko, joka tarkastelee käsiteltyjä tauluja Warehousessa;
• Korkeat kustannukset: käytännössä maksettiin saman datan tallentamisesta kahdesti. Vielä pahempaa, maksettiin korkeasti koulutetuille insinööreille vain siitä, että "silta" pysyi ehjänä aina, kun datan muoto muuttui.

Lakehouse-arkkitehtuuri

Databricks esittelee Lakehouse-arkkitehtuurin yhdistääkseen nämä kaksi erillistä aluetta yhdeksi yhtenäiseksi kokonaisuudeksi. Se toimii suoraan edullisen pilvitallennuksen päällä, mutta lisää siihen tärkeän hallintakerroksen – nimeltään Delta Lake. Tämä kerros tuo "säännöt" kirjastosta "varaston" mittakaavaan.

Lakehouse-arkkitehtuurilla saat vihdoin:

• Yksi totuuden lähde: kaikki, SQL-analyytikosta, joka rakentaa kojelautaa, tekoälymallia kouluttavaan data scientistiin, työskentelevät saman datan parissa samanaikaisesti;
• Varastotason suorituskyky järkevillä kustannuksilla: saat tietokannan salamannopean nopeuden ja luotettavuuden ilman perinteisen varaston korkeita kustannuksia;
• Tuki kaikille datatyypeille: olipa kyseessä rakenteinen myyntitaulu, joka muistuttaa Excel-taulukkoa, tai rakenteeton videotiedosto, kaikki sijaitsee yhdessä hallitussa ja turvallisessa ympäristössä.

Miksi tämä on tulevaisuutta

Kun datan siirtelyä ei enää tarvita, Databricks mahdollistaa tiimien keskittymisen oivalluksiin infrastruktuurin sijaan. Sinun ei enää tarvitse valita "joustavuuden" ja "rakenteen" välillä – saat molemmat. Oppijana tämä tarkoittaa, että kun hallitset Databricks-ympäristön, hallitset käytännössä koko modernin datan elinkaaren – datan synnystä aina liiketoimintapäätökseen asti.