Het semantische Lakehouse uitgelegd

Datameren en semantische lagen bestaan ​​al heel lang - elk leeft in zijn eigen ommuurde tuin, nauw verbonden met vrij beperkte use-cases. Nu de data- en analyse-infrastructuur naar de cloud migreert, vragen velen zich af hoe deze fundamentele technologiecomponenten passen in de moderne data- en analysestack. In dit artikel gaan we dieper in op hoe een data lakehouse en een semantische laag samen de traditionele relatie tussen data lakes en analyse-infrastructuur op zijn kop zetten. We zullen leren hoe een semantisch meerhuis drastisch kan vereenvoudigen cloud data-architecturen, elimineer onnodige gegevensverplaatsing en verminder time-to-value en cloudkosten.

De traditionele data- en analysearchitectuur

In 2006 introduceerde Amazon Amazon Web Services (AWS) als een nieuwe manier om het on-premise datacenter naar de cloud te verplaatsen. Een kerndienst van AWS was de bestandsgegevensopslag en daarmee was het eerste datameer in de cloud, Amazon S3, geboren. Andere cloudleveranciers zouden daarna hun eigen versies van cloud data lake-infrastructuur introduceren.

Het grootste deel van zijn leven is het datameer in de cloud gedegradeerd tot het spelen van de rol van dom, goedkoop gegevensopslag - een regie ruimte voor ruwe data, totdat de data verwerkt kunnen worden tot iets bruikbaars. Voor analyse diende het datameer als opslagplaats voor gegevens totdat deze konden worden gekopieerd en geladen in een geoptimaliseerd analyseplatform, meestal een relationeel datawarehouse in de cloud dat ofwel OLAP-kubussen, propriëtaire data-extracten voor business intelligence (BI) zoals Tableau Hyper of Power BI Premium, of al het bovenstaande. Als gevolg van dit verwerkingspatroon moesten gegevens minimaal twee keer worden opgeslagen, één keer in ruwe vorm en één keer in de vorm 'geoptimaliseerd voor analyse'. 

Het is niet verrassend dat de meeste traditionele cloudanalyse-architecturen er uitzien als het onderstaande diagram:

Zoals u kunt zien, is het "analysemagazijn" verantwoordelijk voor de meeste functies die analyses aan consumenten leveren. Het probleem met deze architectuur is als volgt:

1. Gegevens worden twee keer opgeslagen, wat de kosten verhoogt en operationele complexiteit creëert.
2. Gegevens in het analysemagazijn zijn momentopnamen, wat betekent dat gegevens onmiddellijk verouderd zijn.
3. Gegevens in het analysemagazijn zijn meestal een subset van de gegevens in het datameer, wat de vragen die consumenten kunnen stellen beperkt.
4. Het analysemagazijn schaalt apart en anders dan het clouddataplatform, wat extra kosten, beveiligingsproblemen en operationele complexiteit met zich meebrengt.

Gezien deze nadelen zou je je kunnen afvragen: "Waarom zouden clouddata-architecten dit ontwerppatroon kiezen?" Het antwoord ligt in de eisen van de analytische consumenten. Hoewel het datameer in theorie analytische vragen rechtstreeks aan consumenten zou kunnen leveren, is het datameer in de praktijk te traag en onverenigbaar met populaire analysetools. 

Kon het datameer maar de voordelen van een analysemagazijn bieden en konden we voorkomen dat we gegevens twee keer opslaan!

De geboorte van het Data Lakehouse

De term "Lakehouse" zag zijn debuut in 2020 met het baanbrekende Databricks-witboek "Wat is een Lakehouse?" door Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia en Ali Ghodsi. De auteurs introduceerden het idee dat het datameer zou kunnen dienen als een motor voor het leveren van analyses, niet alleen als een statische bestandsopslag.

Data Lakehouse-leveranciers hebben hun visie waargemaakt door snelle, schaalbare query-engines te introduceren die werken aan onbewerkte gegevensbestanden in het data lake en een ANSI-standaard SQL-interface blootleggen. Met deze belangrijke innovatie beweren voorstanders van deze architectuur dat datameren zich kunnen gedragen als een analysemagazijn, zonder de noodzaak om gegevens te dupliceren.

Het blijkt echter dat het analysemagazijn andere vitale functies vervult waaraan niet alleen kan worden voldaan door de data lakehouse-architectuur, waaronder:

1. Consistent leveren van "denksnelheid"-query's (query's in minder dan 2 seconden) over een breed scala aan query's.
2. Een bedrijfsvriendelijke semantische laag presenteren waarmee consumenten vragen kunnen stellen zonder SQL te hoeven schrijven.
3. Gegevensbeheer en beveiliging toepassen tijdens het uitvoeren van query's.

Dus als een data lakehouse het analysemagazijn echt wil vervangen, hebben we iets anders nodig.

De rol van de semantische laag

Ik heb veel geschreven over de rol van de semantische laag in de moderne datastapel. Samenvattend: een semantische laag is een logische weergave van bedrijfsgegevens die gebruikmaakt van gegevensvirtualisatietechnologie om fysieke gegevens te vertalen naar bedrijfsvriendelijke gegevens tijdens het uitvoeren van zoekopdrachten. 

Door een semantisch laagplatform bovenop een data-meerhuis toe te voegen, kunnen we de analysemagazijnfuncties helemaal elimineren omdat het semantische laagplatform:

1. Levert "snelheid van denkvragen" op het data-meerhuis met behulp van datavirtualisatie en geautomatiseerde prestatieafstemming van query's.
2. Levert een bedrijfsvriendelijke semantische laag die de eigen semantische weergaven vervangt die in elke BI-tool zijn ingesloten en waarmee zakelijke gebruikers vragen kunnen stellen zonder SQL-query's te hoeven schrijven.
3. Levert gegevensbeheer en -beveiliging op het moment van opvragen.

Een semantisch lagenplatform levert de ontbrekende stukjes die de data lakehouse mist. Door een semantische laag te combineren met een data lakehouse kunnen organisaties:

1. Elimineer gegevenskopieën en vereenvoudig gegevenspijplijnen.
2. Consolideer gegevensbeheer en -beveiliging.
3. Lever een "single source of truth" voor bedrijfsstatistieken.
4. Verminder de operationele complexiteit door de gegevens in het datameer te bewaren.
5. Bied analytische consumenten toegang tot meer gegevens en actuelere gegevens.

Het semantische Lakehouse: iedereen wint

Iedereen wint met deze architectuur. Consumenten krijgen toegang tot meer fijnmazige gegevens zonder latentie. IT- en data-engineeringteams hebben minder gegevens om te verplaatsen en te transformeren. Finance geeft minder geld uit aan cloudinfrastructuurkosten. 

Zoals u kunt zien, kunnen organisaties, door een semantische laag te combineren met een data lakehouse, hun data- en analyseactiviteiten vereenvoudigen en sneller meer data leveren aan meer consumenten, tegen lagere kosten.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://www.dataversity.net/the-semantic-lakehouse-explained/