Semanttinen Lakehouse selitetty

Semanttinen Lakehouse selitetty

Lähdesolmu: 1995005

Data järvet ja semanttiset kerrokset ovat olleet olemassa jo pitkään – jokainen asuu omassa muureissaan puutarhoissaan, jotka on tiiviisti yhdistetty melko kapeisiin käyttökohteisiin. Kun data- ja analytiikkainfrastruktuuri siirtyy pilveen, monet haastavat näiden perustavanlaatuisten teknologiakomponenttien sopivuuden nykyaikaiseen data- ja analytiikkapinoon. Tässä artikkelissa sukeltamme siihen, kuinka datajärvi ja semanttinen kerros yhdessä muokkaavat perinteistä suhdetta datalakkien ja analytiikkainfrastruktuurin välillä. Opimme kuinka semanttinen järvitalo voi yksinkertaistaa dramaattisesti pilvitietoarkkitehtuurit, eliminoi tarpeettoman tiedonsiirron ja lyhennä arvon saavuttamiseen kuluvaa aikaa ja pilvikustannuksia.

Perinteinen data- ja analyysiarkkitehtuuri

Vuonna 2006 Amazon esitteli Amazon Web Services (AWS) uutena tapana siirtää paikan päällä oleva datakeskus pilveen. AWS-ydinpalvelu oli sen tiedostotietovarasto, ja sen myötä syntyi ensimmäinen pilvitietojärvi, Amazon S3. Muut pilvipalvelun toimittajat esittelivät sen jälkeen omia versioitaan pilvitietojärven infrastruktuurista.

Pilvitietojärvi on suurimman osan elämästään jäänyt näyttelemään tyhmän, halvan roolia tietovarastonäyttämöllepano raakadata-alueelle, kunnes tiedot voidaan käsitellä hyödylliseksi. Analytiikkaa varten datajärvi toimi tietojen säilytyskynänä, kunnes ne voitiin kopioida ja ladata optimoituun analytiikka-alustaan, tyypillisesti relaatiopilvitietovarastoon, joka syöttää joko OLAP-kuutiot, omaa liiketoimintatiedon (BI) työkalun dataotteita, kuten Tableau Hyper tai Power BI Premium tai kaikki edellä mainitut. Tämän käsittelymallin seurauksena tiedot piti tallentaa vähintään kahdesti, kerran raaka-muodossa ja kerran "analyyttisesti optimoidussa" muodossa. 

Ei ole yllättävää, että useimmat perinteiset pilvianalyysiarkkitehtuurit näyttävät alla olevalta kaaviolta:

Kuva 1: Perinteinen data- ja analyysipino

Kuten näette, "analytiikkavarasto" vastaa suurimmasta osasta toiminnoista, jotka toimittavat analytiikkaa kuluttajille. Tämän arkkitehtuurin ongelma on seuraava:

  1. Tiedot tallennetaan kahdesti, mikä lisää kustannuksia ja vaikeuttaa toimintaa.
  2. Analytiikkavaraston tiedot ovat tilannevedoksia, mikä tarkoittaa, että tiedot ovat välittömästi vanhentuneita.
  3. Analytiikkavaraston tiedot ovat tyypillisesti datajärven tietojen osajoukko, mikä rajoittaa kuluttajien esittämiä kysymyksiä.
  4. Analytiikkavarasto skaalautuu erikseen ja eri tavalla kuin pilvitietoalusta, mikä tuo lisäkustannuksia, turvallisuusongelmia ja toiminnan monimutkaisuutta.

Näiden haittojen vuoksi saatat kysyä "Miksi pilvitietoarkkitehdit valitsisivat tämän suunnittelumallin?" Vastaus piilee analytiikan kuluttajien vaatimuksissa. Vaikka datajärvi voisi teoriassa palvella analyyttisiä kyselyitä suoraan kuluttajille, käytännössä datajärvi on liian hidas ja yhteensopimaton suosittujen analytiikkatyökalujen kanssa. 

Kunpa datajärvi voisi tarjota analytiikkavaraston edut ja voisimme välttää tietojen tallentamisen kahdesti!

Data Lakehousen synty

Termi "Lakehouse" sai debyyttinsä vuonna 2020 Databricks-valkoisessa kirjassa. "Mikä on Lakehouse?" Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia ja Ali Ghodsi. Kirjoittajat esittelivät ajatuksen, että datajärvi voisi toimia analytiikan toimittamisen moottorina, ei vain staattisena tiedostosäilönä.

Data Lakehouse -toimittajat toteuttivat visionsa ottamalla käyttöön nopeita, skaalautuvia kyselymoottoreita, jotka toimivat datajärven raakadatatiedostoilla ja paljastavat ANSI-standardin SQL-rajapinnan. Tämän keskeisen innovaation myötä tämän arkkitehtuurin kannattajat väittävät, että datajärvet voivat toimia kuin analytiikkavarasto ilman tietojen monistamisen tarvetta.

Osoittautuu kuitenkin, että analytiikkavarasto suorittaa muita tärkeitä toimintoja, joita data Lakehouse -arkkitehtuuri ei yksinään tyydytä, mukaan lukien:

  1. Toimittaa "ajattelun nopeus" -kyselyt (kyselyt alle 2 sekunnissa) johdonmukaisesti useissa eri kyselyissä.
  2. Esittelemme yritysystävällisen semanttisen kerroksen, jonka avulla kuluttajat voivat esittää kysymyksiä ilman, että heidän tarvitsee kirjoittaa SQL:ää.
  3. Tietojen hallinnan ja turvallisuuden soveltaminen kyselyn aikana.

Jotta datajärvi todella korvaisi analytiikkavaraston, tarvitsemme jotain muuta.

Semanttisen kerroksen rooli

Olen kirjoittanut paljon roolista semanttinen kerros nykyaikaisessa tietopinossa. Yhteenvetona voidaan todeta, että semanttinen kerros on looginen näkymä yritystiedoista, joka hyödyntää datan virtualisointiteknologiaa muuntaakseen fyysistä dataa yritysystävällisiksi tiedoiksi kyselyn aikana. 

Lisäämällä semanttisen kerroksen alustan datajärven päälle, voimme eliminoida analytiikkavaraston toiminnot kokonaan, koska semanttisen kerroksen alusta:

  1. Tarjoaa "ajattelun nopeuskyselyitä" datajärvirakennuksessa datan virtualisoinnin ja automaattisen kyselyn suorituskyvyn virityksen avulla.
  2. Tarjoaa yritysystävällisen semanttisen kerroksen, joka korvaa jokaiseen BI-työkaluun upotetut omat semanttiset näkymät ja antaa yrityskäyttäjille mahdollisuuden esittää kysymyksiä ilman SQL-kyselyjen kirjoittamista.
  3. Tarjoaa tietojen hallinnan ja turvallisuuden kyselyn aikana.

Semanttisen kerroksen alusta toimittaa puuttuvat osat, jotka datajärvirakennuksesta puuttuu. Yhdistämällä semanttisen kerroksen datajärvirakennukseen organisaatiot voivat:

  1. Poista datakopiot ja yksinkertaista tietoputkia.
  2. Yhdistä tietojen hallinta ja turvallisuus.
  3. Tarjoa "yksittäinen totuuden lähde" ​​liiketoimintamittareille.
  4. Vähennä toiminnan monimutkaisuutta pitämällä tiedot datajärvessä.
  5. Tarjoa analytiikan kuluttajille pääsy enemmän dataan ja oikea-aikaisempaan dataan.
Kuva 2: Uusi Data Lakehouse -pino semanttisella kerroksella 

The Semantic Lakehouse: Kaikki voittaa

Kaikki voittavat tällä arkkitehtuurilla. Kuluttajat saavat käyttöönsä tarkempia tietoja ilman viivettä. IT- ja tietotekniikkatiimeillä on vähemmän siirrettävää ja muunnettavaa dataa. Rahoitus käyttää vähemmän rahaa pilviinfrastruktuurikustannuksiin. 

Kuten näet, yhdistämällä semanttisen kerroksen datajärvirakennukseen organisaatiot voivat yksinkertaistaa data- ja analytiikkatoimintojaan ja toimittaa enemmän dataa nopeammin, useammille kuluttajille pienemmillä kustannuksilla.

Aikaleima:

Lisää aiheesta DATAVERSITEETTI