The Semantic Lakehouse Explained - Plato AiStream V2.1

Genudgivet af Platon

Abonnenter: 0

Datasøer og semantiske lag har eksisteret i lang tid - hver bor i deres egne murede haver, tæt koblet til ret snævre use cases. Efterhånden som data- og analyseinfrastrukturen migrerer til skyen, udfordrer mange, hvordan disse grundlæggende teknologikomponenter passer ind i den moderne data- og analysestak. I denne artikel vil vi dykke ned i, hvordan et data-søhus og et semantisk lag tilsammen hæver det traditionelle forhold mellem datasøer og analyseinfrastruktur. Vi lærer, hvordan et semantisk søhus dramatisk kan forenkle skydataarkitekturer, eliminer unødvendig databevægelse og reducerer time to value og cloud-omkostninger.

Den traditionelle data- og analysearkitektur

I 2006 introducerede Amazon Amazon Web Services (AWS) som en ny måde at overføre det lokale datacenter til skyen. En kerne AWS-tjeneste var dens fildatalager, og dermed blev den første cloud-datasø, Amazon S3, født. Andre cloud-leverandører vil derefter introducere deres egne versioner af cloud-datasø-infrastruktur.

I det meste af sit liv er cloud-datasøen blevet henvist til at spille rollen som dum, billig data opbevaring - En iscenesættelse område for rådata, indtil data kunne bearbejdes til noget brugbart. Til analyse fungerede datasøen som en holdepen for data, indtil de kunne kopieres og indlæses i en optimeret analyseplatform, typisk et relationelt cloud-datavarehus, der fodrer enten OLAP-kuber, proprietære business intelligence (BI)-værktøjsdataekstrakter som Tableau Hyper eller Power BI Premium eller alle ovenstående. Som et resultat af dette behandlingsmønster skulle data lagres mindst to gange, én gang i sin rå form og én gang i sin "analyseoptimerede" form.

Ikke overraskende ser de fleste traditionelle cloudanalysearkitekturer ud som nedenstående diagram:

*Billede 1: Traditionel data- og analysestak*

Som du kan se, er "analytiklageret" ansvarlig for et flertal af de funktioner, der leverer analyser til forbrugerne. Problemet med denne arkitektur er som følger:

Data gemmes to gange, hvilket øger omkostningerne og skaber driftsmæssig kompleksitet.
Data i analyselageret er et øjebliksbillede, hvilket betyder, at data øjeblikkeligt er forældede.
Data i analysevarehuset er typisk en delmængde af dataene i datasøen, hvilket begrænser de spørgsmål, forbrugerne kan stille.
Analyselageret skaleres separat og forskelligt fra cloud-dataplatformen, hvilket introducerer ekstra omkostninger, sikkerhedsproblemer og operationel kompleksitet.

I betragtning af disse ulemper kan du spørge "Hvorfor ville cloud-dataarkitekter vælge dette designmønster?" Svaret ligger i analytics-forbrugernes krav. Mens datasøen teoretisk set kunne tjene analytiske forespørgsler direkte til forbrugerne, er datasøen i praksis for langsom og uforenelig med populære analyseværktøjer.

Hvis blot datasøen kunne levere fordelene ved et analyselager, og vi kunne undgå at gemme data to gange!

Fødslen af Data Lakehouse

Begrebet "Lakehouse" så sin debut i 2020 med den banebrydende Databricks hvidbog "Hvad er et Lakehouse?" af Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia og Ali Ghodsi. Forfatterne introducerede ideen om, at datasøen kunne tjene som en motor til at levere analyser, ikke blot et statisk fillager.

Data Lakehouse-leverandører leverede deres vision ved at introducere højhastigheds, skalerbare forespørgselsmotorer, der arbejder på rådatafiler i datasøen og afslører en ANSI-standard SQL-grænseflade. Med denne nøgleinnovation hævder tilhængere af denne arkitektur, at datasøer kan opføre sig som et analysevarehus uden behov for duplikering af data.

Det viser sig dog, at analyselageret udfører andre vitale funktioner, som ikke opfyldes alene af data-lakehouse-arkitekturen, herunder:

Levering af "speed of thought"-forespørgsler (forespørgsler på under 2 sekunder) konsekvent over en bred vifte af forespørgsler.
Præsenterer et forretningsvenligt semantisk lag, der giver forbrugerne mulighed for at stille spørgsmål uden at skulle skrive SQL.
Anvendelse af datastyring og sikkerhed på forespørgselstidspunktet.

Så for at et datasøhus virkelig skal erstatte analysevarehuset, har vi brug for noget andet.

Det semantiske lags rolle

Jeg har skrevet meget om rollen som den semantisk lag i den moderne datastak. For at opsummere er et semantisk lag en logisk visning af forretningsdata, der udnytter datavirtualiseringsteknologi til at oversætte fysiske data til forretningsvenlige data på forespørgselstidspunktet.

Ved at tilføje en semantisk lag platform oven på et data lakehouse, kan vi eliminere analytics warehouse funktionerne helt, fordi den semantiske lag platform:

Leverer "speed of thought-forespørgsler" på data-søhuset ved hjælp af datavirtualisering og automatisk justering af forespørgselsydeevne.
Leverer et forretningsvenligt semantisk lag, der erstatter de proprietære semantiske visninger, der er indlejret i hvert BI-værktøj, og giver forretningsbrugere mulighed for at stille spørgsmål uden at skulle skrive SQL-forespørgsler.
Leverer datastyring og sikkerhed på forespørgselstidspunktet.

En semantisk lagplatform leverer de manglende stykker, som datasøhuset mangler. Ved at kombinere et semantisk lag med et datasøhus kan organisationer:

Eliminer datakopier og forenkle datapipelines.
Konsolidere datastyring og sikkerhed.
Lever en "enkelt kilde til sandhed" til forretningsmålinger.
Reducer den operationelle kompleksitet ved at holde dataene i datasøen.
Giv analytics-forbrugere adgang til flere data og mere rettidige data.

*Billede 2: Ny data Lakehouse-stak med et semantisk lag*

The Semantic Lakehouse: Alle vinder

Alle vinder med denne arkitektur. Forbrugere får adgang til mere finkornede data uden forsinkelse. IT- og dataingeniørteams har færre data at flytte og transformere. Finans bruger færre penge på omkostninger til cloud-infrastruktur.

Som du kan se, kan organisationer ved at kombinere et semantisk lag med et datasøhus forenkle deres data- og analyseoperationer og levere flere data hurtigere til flere forbrugere med færre omkostninger.