De Data Lakehouse Architectuur
Een Data Lakehouse Architectuur combineert de voordelen van een Data Lake met die van een Data Warehouse.
Voordelen van een Data Lake zijn:
- Data ligt vast in relatief goedkope (cloud) storage
- Open data formaten (zoals bijvoorbeeld parquet) beschermen tegen Vendor Lock-in situaties
- Ook ongestructureerde data kan worden opgeslagen voor analyse (afbeeldingen, video, geluid, etc.)
- Scheiding tussen Storage en Compute zorgt voor een betere schaalbaarheid
Nadelen van een Data Lake zijn:
- Geen ACID transactions
- Lagere query performance dan bijvoorbeeld een MPP database
- Data Lakes ontaarden soms in Data Swamps of Data Cesspools
Een Data Lakehouse Platform biedt technische oplossingen voor de genoemde nadelen. Hierdoor wordt het mogelijk om de data van het Data Lake ook toe te passen voor Data Warehousing en Business Intelligence. Voorbeelden van dergelijke technische oplossingen worden hieronder toegelicht.
ACID Transactions
Het ACID (atomicity, consistency, isolation, durability) transactie mechanisme van databases zorgt ervoor dat de data consistent en betrouwbaar blijft. Mocht een laadproces crashen midden in een laadproces, dan kan dit transactie mechanisme er voor zorgen dat onafgemaakte wijzigingen automatisch worden teruggedraaid. Binnen een Data Lake is dit mechanisme niet aanwezig. Hierdoor zullen ontwikkelaars zelf moeten zorgdragen voor het opruimen en herstellen van data na een crash. Dit kost veel tijd en is foutgevoelig. Sommige Data Lakehouse platforms voegen ACID functionaliteit toe aan bestaande data formaten (meestal Parquet). Databricks heeft hiervoor bijvoorbeeld Delta Lake ontwikkeld.
Query Performance
Data Lakes worden van oudsher gebruikt door zware analytische batch processen die zeer grote hoeveelheden data analyseren, verwerken en de resultaten hiervan weer wegschrijven. Deze processen verwerken data gescheduled op de achtergrond en lopen vaak sequentieel. Op een datawarehouse daarentegen kunnen meerdere queries tegelijk draaien, waarbij de gebruikers snel resultaat moeten zien. Data Warehouse database engines draaien dan ook vaak op grote computers met snelle interne schijven en meerdere cores (z.g. MPP verwerking). Diverse Data Lakehouse platforms bieden een query-engine laag welke zich tussen de Data Lake opslag en de query/rapportage gebruikers bevindt. Door bijvoorbeeld data local te cachen wordt de performance van queries sterk versneld. Voorbeelden van dergelijke oplossingen zijn: Databricks SQL en Snowflake.
Data Catalogs
Een Data Lake kan grote hoeveelheden data bevatten in allerlei bestandsformaten. De data bestanden kunnen in principe overal worden neergezet. In dat opzicht lijkt het Data Lake op een hele grote harde schijf. Het is een uitdaging om deze harde schijf overzichtelijk en begrijpbaar te houden. Documenteren en het opzetten en naleven van standaarden is hiervoor een vereiste. In de praktijk vindt dit echter niet altijd plaats, met alle gevolgen van dien. Aanbieders van Data Lakehouse platforms ontwikkelen z.g. Data Catalogs in een poging om een oplossing te bieden voor deze problematiek. Deze Data Catalogs kunnen inzicht verschaffen in belangrijke metadata, zoals: Data Lineage, eigenaarschap, data formaten, data definities, etc.
Voordelen van een Data Lakehouse Architectuur
Zoals hiervoor beschreven is, lost het Data Lakehouse concept een aantal beperkingen op van een Data Lake met als doel om deze te kunnen gebruiken als Data Warehouse. De vraag is in hoeverre dit lukt en of dit vervolgens ook voordelen oplevert ten opzicht van een traditioneel Data Lake en traditioneel Data Warehouse die naast elkaar bestaan.
Kostenbesparing
Er wordt soms simpel gesteld dat een Data Lake ruwe data bevat en een Data Warehouse bewerkte data. Dit is niet helemaal waar. Veel Data Warehouse architecturen kennen zowel vluchtige als historische ruwe data lagen. Het is gebruikelijk om brontabellen in zijn geheel te ontsluiten met het oog op toekomstige requirements. In dat opzicht zal het dus voorkomen dat veel brontabellen zowel naar het Data Warehouse worden geladen, alsook naar het Data Lake.
In het kader van kostenbesparing is het logisch om rauwe brondata slechts 1 keer te ontsluiten en vervolgens door te verwerken voor zowel Data Warehouse (Rapportage en Analyse) als Data Lake (o.a. Data Science) toepassingen. Het ontsluiten van data uit een bronsystem kan redelijk complex zijn, vooral bij z.g. legacy systemen waarin het soms lastig kan zijn om deltas (gewijzigde records) te identificeren. Door de rauwe data op te slaan in goedkope cloudopslag in plaats van de dure opslag van een traditioneel datawarehouse, worden bovendien ook kosten bespaard. Het historisch opslaan van alle wijzigingen over de tijd van deze brondata zal ook goedkoper zijn binnen deze Data Lake storage, dan in een traditionele staging database van het Data Warehouse.
Vendor Lock-in voorkomen
Het gebruik van open opslag standaarden (zoals Parquet, Avro, ORC) werd eerder als voordeel genoemd van een Data Lake architectuur. Geldt dit voordeel ook voor een Data Lakehouse? Niet alle Data Lakehouse platforms slaan data standaard in open formaten op. Soms wordt de data wel opgeslagen in Cloud Storage, maar gebeurt dit in een eigen formaat op de achtergrond en onzichtbaar voor de gebruiker van het platform. Het lezen en schrijven van de data kan dan alleen via de beschikbare weg, zoals SQL of Python/Scala (dataframes). Bij andere Data Lakehouse platforms is het wel mogelijk om zelf de opslaglocatie en opslagvorm te kiezen. Welke situatie de voorkeur heeft, is afhankelijk van de eisen die hieraan gesteld worden. Het zelf beheren en bepalen van de opslag kan bepaalde voordelen hebben, maar vereist wel een bepaald kennisniveau. Het beschikbaar hebben van middelen om data eenvoudig te in- en exporteren, ook tussen verschillende cloudleveranciers, is wel een vereiste op dat gebied.