Beheer

Dit is een bijdrage van Rubicon
Datamanagement
Waarom je Azure dataplatform een datalakehouse moet zijn

Waarom Azure dataplatform een datalakehouse moet zijn

Betrouwbaarheid en flexibiliteit combineren, tegen lagere kosten

22 juli 2021
Door: Rubicon, partner

Betrouwbaarheid en flexibiliteit combineren, tegen lagere kosten

Datalakehouse, je hoort het nu steeds vaker. Maar wat is het? Is het een buzzwoord, een nieuwe hype met oude wijn in nieuwe zakken, of is het echt van toegevoegde waarde? Jesse Gorter is Principal BI Consultant bij Rubicon. In dit artikel legt hij kort uit wat het is, en wat het voor je organisatie kan betekenen.

Als je op dit moment nadenkt over het opzetten of vernieuwen van je dataplatform, als je daarbij zoveel mogelijk verschillende vormen van data wilt kunnen verwerken, en je wilt ook nog kostenbesparend werken, dan is dit waarschijnlijk interessant voor jou.

Wat is een datalakehouse?

Een datalakehouse is simpelweg de combinatie van de kracht van een datalake, gecombineerd met die van een datawarehouse.

Een datawarehouse kon van oudsher betrouwbare informatie leveren door de controles op datakwaliteit – door schema on write bijvoorbeeld: de data past alleen in het datawarehouse als de data aan strikt formaat voldoet. Het datalake heeft juist als voordeel dat het allerlei formaten van data aankan. Dat laatste noemen we ook wel schema on read: sla het eerst op en maak je dan later pas zorgen over hoe je er weer betrouwbare informatie uit kan halen.

Tegenwoordig heeft het datalake als concept de wereld al wel veroverd. Er zijn weinig business intelligence/data architecten te vinden die geen plekje voor het datalake zien in de architectuur. Zo mag het vaak de rol van historical staging invullen. Dit kan niet meer als innoverend of baanbrekend worden gezien. Steeds meer organisaties maken de stap naar de cloud, en datalake is dan één van de tools in je gereedschapskist.

De flexibiliteit van een datalake maximaal benutten

Echter, als je datalake alleen maar als de staging laag inzet, beperk je de mogelijkheden van de datalake.

Voor sommige analytische vraagstukken is het prettig om de flexibiliteit van een datalake te hebben, bijvoorbeeld voor machine learning. Voor andere vraagstukken wil je wellicht de betrouwbaarheid en robuustheid van een datawarehouse. Kortom, je wil de flexibiliteit van de datalake niet alleen aan het begin van het inleesproces hebben, maar ook aan het einde waar gebruikers ermee kunnen werken.

Waarom zou je een datawarehouse en een datalake willen combineren?

De gebruikersbehoefte wordt namelijk steeds meer divers. Zo hebben steeds meer gebruikers andere behoeften. Data scientists hebben andere behoeften dan data analisten. Waar voorheen beide een eigen datasilo kregen is er nu meer behoefte aan een geïntegreerde aanpak. Hoe krachtig zou het dan zijn als je dit in één omgeving kunt aanbieden?

“Heb ik dan een datalakehouse als ik een datalake en een datawarehouse in één architectuur aanbied?”

De term is niet beschermd of scherp gedefinieerd. Dus ook de traditionele architectuur met datalake als enkel de staging zou je technisch gesproken een datalakehouse kunnen noemen. Maar dat is niet de essentie, het idee achter de term. Het nadeel van zowel een datalake als een fysiek datawarehouse is dat je twee platforms krijgt met twee keer de data. En beide zul je moeten opschalen om met grote hoeveelheden van data te kunnen werken.

Database views in je datalake met Azure Synapse of transacties definiëren met delta lake

Tegenwoordig zijn er in het Azure landschap meer mogelijkheden gekomen om datalake en datawarehouse functionaliteit te leveren, vanuit de datalake zelf. Dus zonder fysiek datawarehouse. Er zijn meerdere manieren waarop dit kan.

Met Azure Synapse bijvoorbeeld kun je met serverless pools views definiëren op data in je datalake. Client tools zien deze views dan alsof ze van een relationele database komen. Ze zien geen verschil met een fysieke database. Deze vorm van virtualisatie is precies de kracht waar we het over hebben: de data is eenmalig opgeslagen in een datalake, maar wordt aangeboden als zijnde relationele data. Je betaalt dan alleen voor de kosten van de datalake en de consumptie van de data.

Een andere technologie die interessant is, is die van delta lake. Hiermee kun je een schema en transacties definiëren op je data in de datalake. Ook kun je de historie van de data eenvoudig terughalen. Zo komen er steeds meer opties om datawarehouse functionaliteit direct vanuit een datalake aan te bieden.

Meer weten over de datalakehouse architectuur of Azure Synapse?

Heb je een dataplatform en wil je je eindgebruikers meer mogelijkheden bieden? Of heb je een fysiek datawarehouse, en een actief datalake als analyseplatform? Dan is het nu misschien wel een goed moment om na te denken over de datalakehouse architectuur. Wil je meer weten over de mogelijkheden van een datalakehouse, of heb je vragen over Azure Synapse?

Luister naar de Azure Synapse RubiCast waarin we dieper ingaan op de mogelijkheden maar ook beperkingen van Azure Synapse. Wil je liever direct in gesprek of aan de slag? Neem dan gerust contact met ons op.

Reactie toevoegen