The Semantic Lakehouse Explained

Datasjöar och semantiska lager har funnits länge – var och en bor i sina egna muromgärdade trädgårdar, tätt kopplade till ganska smala användningsområden. När data- och analysinfrastrukturen migrerar till molnet, utmanar många hur dessa grundläggande teknologikomponenter passar in i den moderna data- och analysstapeln. I den här artikeln kommer vi att dyka in i hur ett datasjöhus och ett semantiskt lager tillsammans upphäver det traditionella förhållandet mellan datasjöar och analysinfrastruktur. Vi kommer att lära oss hur ett semantiskt sjöhus dramatiskt kan förenkla molndataarkitekturer, eliminera onödiga datarörelser och minska tid till värde och molnkostnader.

Den traditionella data- och analysarkitekturen

2006 introducerade Amazon Amazon Web Services (AWS) som ett nytt sätt att ladda ner det lokala datacentret till molnet. En central AWS-tjänst var dess fildatalager och med det föddes den första molndatasjön, Amazon S3. Andra molnleverantörer skulle därefter introducera sina egna versioner av molndatasjöinfrastruktur.

Under större delen av sitt liv har molndatasjön blivit förpassad till att spela rollen som dum, billig datalagring - a staging område för rådata, tills data kunde bearbetas till något användbart. För analys fungerade datasjön som en hållpenna för data tills den kunde kopieras och laddas in i en optimerad analysplattform, vanligtvis ett relationellt molndatalager som matar antingen OLAP-kuber, proprietära business intelligence (BI) verktygsdataextrakt som Tableau Hyper eller Power BI Premium, eller alla ovanstående. Som ett resultat av detta bearbetningsmönster behövde data lagras minst två gånger, en gång i sin råa form och en gång i sin "analytikoptimerade" form. 

Inte överraskande ser de flesta traditionella molnanalysarkitekturer ut som diagrammet nedan:

Som du kan se är "analytiklagret" ansvarigt för en majoritet av de funktioner som levererar analyser till konsumenterna. Problemet med denna arkitektur är följande:

1. Data lagras två gånger, vilket ökar kostnaderna och skapar komplexitet i verksamheten.
2. Data i analyslagret är en ögonblicksbild, vilket innebär att data omedelbart är inaktuella.
3. Data i analyslagret är vanligtvis en delmängd av data i datasjön, vilket begränsar de frågor som konsumenter kan ställa.
4. Analyslagret skalas separat och annorlunda än molndataplattformen, vilket introducerar extra kostnader, säkerhetsproblem och operationell komplexitet.

Med tanke på dessa nackdelar kan du fråga "Varför skulle molndataarkitekter välja detta designmönster?" Svaret ligger i kraven från analytikkonsumenterna. Även om datasjön teoretiskt sett skulle kunna betjäna analytiska frågor direkt till konsumenter, är datasjön i praktiken för långsam och inkompatibel med populära analysverktyg. 

Om bara datasjön kunde leverera fördelarna med ett analyslager och vi kunde undvika att lagra data två gånger!

Födelsen av Data Lakehouse

Begreppet "Lakehouse" debuterade 2020 med det framträdande vitboken Databricks "Vad är ett Lakehouse?" av Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia och Ali Ghodsi. Författarna introducerade idén att datasjön kunde fungera som en motor för att leverera analyser, inte bara en statisk filbutik.

Data Lakehouse-leverantörer levererade sin vision genom att introducera höghastighets, skalbara frågemotorer som arbetar på rådatafiler i datasjön och exponerar ett ANSI-standard SQL-gränssnitt. Med denna nyckelinnovation hävdar förespråkare för denna arkitektur att datasjöar kan bete sig som ett analyslager, utan att behöva duplicera data.

Det visar sig dock att analyslagret utför andra viktiga funktioner som inte enbart tillfredsställs av datalakehouse-arkitekturen, inklusive:

1. Levererar "speed of thought"-frågor (frågor på under 2 sekunder) konsekvent över ett brett spektrum av frågor.
2. Presenterar ett företagsvänligt semantiskt lager som låter konsumenter ställa frågor utan att behöva skriva SQL.
3. Tillämpa datastyrning och säkerhet vid frågetillfället.

Så för att ett datasjöhus verkligen ska ersätta analyslagret behöver vi något annat.

Det semantiska skiktets roll

Jag har skrivit mycket om rollen som den semantiskt lager i den moderna datastacken. För att sammanfatta, är ett semantiskt lager en logisk vy av affärsdata som utnyttjar datavirtualiseringsteknik för att översätta fysisk data till affärsvänlig data vid frågetillfället. 

Genom att lägga till en semantisk lagerplattform ovanpå ett datasjöhus kan vi eliminera analyslagerfunktionerna helt eftersom den semantiska lagerplattformen:

1. Levererar "speed of thought-frågor" på datasjöhuset med hjälp av datavirtualisering och automatisk justering av frågeprestanda.
2. Levererar ett affärsvänligt semantiskt lager som ersätter de egenutvecklade semantiska vyerna som är inbäddade i varje BI-verktyg och låter företagsanvändare ställa frågor utan att behöva skriva SQL-frågor.
3. Levererar datastyrning och säkerhet vid frågetid.

En semantisk lagerplattform levererar de saknade bitarna som datasjöhuset saknar. Genom att kombinera ett semantiskt lager med ett datasjöhus kan organisationer:

1. Eliminera datakopior och förenkla datapipelines.
2. Konsolidera datastyrning och säkerhet.
3. Leverera en "enda källa till sanning" för affärsmått.
4. Minska operativ komplexitet genom att behålla data i datasjön.
5. Ge tillgång till mer data och mer aktuell data till analytikerkonsumenter.

The Semantic Lakehouse: Alla vinner

Alla vinner med denna arkitektur. Konsumenter får tillgång till mer finkornig data utan latens. IT- och datateknikteam har mindre data att flytta och omvandla. Finans spenderar mindre pengar på kostnader för molninfrastruktur. 

Som du kan se, genom att kombinera ett semantiskt lager med ett datasjöhus, kan organisationer förenkla sin data- och analysverksamhet och leverera mer data, snabbare, till fler konsumenter, med lägre kostnad.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://www.dataversity.net/the-semantic-lakehouse-explained/