The Semantic Lakehouse forklart

Datainnsjøer og semantiske lag har eksistert i lang tid - hver bor i sine egne inngjerdede hager, tett koblet til ganske smale bruksområder. Ettersom data- og analyseinfrastruktur migrerer til skyen, utfordrer mange hvordan disse grunnleggende teknologikomponentene passer inn i den moderne data- og analysestabelen. I denne artikkelen vil vi dykke ned i hvordan et datainnsjøhus og et semantisk lag sammen opphever det tradisjonelle forholdet mellom datainnsjøer og analyseinfrastruktur. Vi vil lære hvordan et semantisk innsjøhus kan forenkle dramatisk skydataarkitekturer, eliminer unødvendig databevegelse, og reduser time to value og skykostnader.

Den tradisjonelle data- og analysearkitekturen

I 2006 introduserte Amazon Amazon Web Services (AWS) som en ny måte å avlaste det lokale datasenteret til skyen. En kjerne AWS-tjeneste var fildatalageret, og med det ble den første skydatasjøen, Amazon S3, født. Andre skyleverandører vil deretter introdusere sine egne versjoner av skydatainnsjøinfrastruktur.

I det meste av livet har skydatasjøen blitt henvist til å spille rollen som dum, billig datalagring - En iscenesettelse område for rådata, inntil data kunne bearbeides til noe nyttig. For analyse fungerte datainnsjøen som en holdepenn for data til den kunne kopieres og lastes inn i en optimalisert analyseplattform, typisk et relasjonsbasert skydatavarehus som mater enten OLAP-kuber, proprietære business intelligence (BI)-verktøydataekstrakter som Tableau Hyper eller Power BI Premium, eller alle de ovennevnte. Som et resultat av dette behandlingsmønsteret måtte data lagres minst to ganger, en gang i rå form og en gang i "analyseoptimalisert" form. 

Ikke overraskende ser de fleste tradisjonelle skyanalysearkitekturer ut som diagrammet nedenfor:

Som du kan se, er "analysevarehuset" ansvarlig for et flertall av funksjonene som leverer analyser til forbrukere. Problemet med denne arkitekturen er som følger:

1. Data lagres to ganger, noe som øker kostnadene og skaper operasjonell kompleksitet.
2. Data i analyselageret er et øyeblikksbilde, noe som betyr at data umiddelbart er foreldet.
3. Data i analysevarehuset er vanligvis en delmengde av dataene i datasjøen, noe som begrenser spørsmålene forbrukere kan stille.
4. Analyselageret skaleres separat og annerledes enn skydataplattformen, og introduserer ekstra kostnader, sikkerhetsproblemer og operasjonell kompleksitet.

Gitt disse ulempene, kan du spørre "Hvorfor ville skydataarkitekter velge dette designmønsteret?" Svaret ligger i kravene fra analyseforbrukerne. Mens datainnsjøen teoretisk sett kan tjene analytiske spørsmål direkte til forbrukere, er datasjøen i praksis for treg og uforenlig med populære analyseverktøy. 

Hvis bare datainnsjøen kunne levere fordelene med et analyselager og vi kunne unngå å lagre data to ganger!

Fødselen til Data Lakehouse

Begrepet "Lakehouse" så sin debut i 2020 med den banebrytende Databricks-hvitboken "Hva er et Lakehouse?" av Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia og Ali Ghodsi. Forfatterne introduserte ideen om at datainnsjøen kunne tjene som en motor for å levere analyser, ikke bare en statisk fillager.

Data Lakehouse-leverandører leverte på sin visjon ved å introdusere høyhastighets, skalerbare søkemotorer som fungerer på rådatafiler i datasjøen og avslører et ANSI-standard SQL-grensesnitt. Med denne nøkkelinnovasjonen hevder talsmenn for denne arkitekturen at datainnsjøer kan oppføre seg som et analysevarehus, uten behov for duplisering av data.

Det viser seg imidlertid at analyselageret utfører andre viktige funksjoner som ikke tilfredsstilles av datainnsjø-arkitekturen alene, inkludert:

1. Levere "speed of thought"-spørringer (spørringer på under 2 sekunder) konsekvent over et bredt spekter av spørringer.
2. Presenterer et forretningsvennlig semantisk lag som lar forbrukere stille spørsmål uten å måtte skrive SQL.
3. Bruk av datastyring og sikkerhet på spørretidspunktet.

Så for at et datainnsjøhus virkelig skal erstatte analysevarehuset, trenger vi noe annet.

Rollen til det semantiske laget

Jeg har skrevet mye om rollen til semantisk lag i den moderne datastakken. For å oppsummere er et semantisk lag et logisk syn på forretningsdata som utnytter datavirtualiseringsteknologi for å oversette fysiske data til bedriftsvennlige data på spørringstidspunktet. 

Ved å legge til en semantisk lagplattform på toppen av et datainnsjø, kan vi eliminere analysevarehusfunksjonene helt fordi den semantiske lagplattformen:

1. Leverer "speed of thought-spørringer" på datainnsjøhuset ved hjelp av datavirtualisering og automatisert justering av søkeytelse.
2. Leverer et forretningsvennlig semantisk lag som erstatter de proprietære semantiske visningene som er innebygd i hvert BI-verktøy og lar bedriftsbrukere stille spørsmål uten å måtte skrive SQL-spørringer.
3. Leverer datastyring og sikkerhet på spørringstidspunktet.

En semantisk lagplattform leverer de manglende delene som datainnsjøhuset mangler. Ved å kombinere et semantisk lag med et datainnsjøhus kan organisasjoner:

1. Eliminer datakopier og forenkle datapipelines.
2. Konsolidere datastyring og sikkerhet.
3. Lever en «enkelt kilde til sannhet» for forretningsberegninger.
4. Reduser operasjonell kompleksitet ved å holde dataene i datasjøen.
5. Gi tilgang til flere data og mer tidsriktige data til analyseforbrukere.

The Semantic Lakehouse: Everybody Wins

Alle vinner med denne arkitekturen. Forbrukere får tilgang til mer finkornet data uten ventetid. IT- og dataingeniørteam har mindre data å flytte og transformere. Finans bruker mindre penger på kostnader til skyinfrastruktur. 

Som du kan se, ved å kombinere et semantisk lag med et datainnsjø, kan organisasjoner forenkle sine data- og analyseoperasjoner, og levere mer data, raskere, til flere forbrukere, med mindre kostnader.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://www.dataversity.net/the-semantic-lakehouse-explained/