Het kan een beetje moeilijk zijn om alle beschikbare services en architecturale opties te overwegen bij het nadenken over dataplatforms.
Een enterprise dataplatform bestaat vaak uit datawarehouses, datamodellen, datameren en rapporten, elk met een specifiek doel en een reeks benodigde vaardigheden. Daarentegen is de afgelopen jaren een nieuw ontwerp ontstaan, het data lakehouse genaamd.
De veelzijdigheid van datameren en datawarehouse-databeheer worden gecombineerd in een revolutionaire dataopslagarchitectuur die een 'data lakehouse' wordt genoemd.
We zullen data lakehouse diepgaand onderzoeken in dit bericht, inclusief de componenten, functies, architectuur en andere aspecten.
Wat is Data Lakehouse?
Zoals de naam al aangeeft, is een data lakehouse een nieuw type data-architectuur die een data lake combineert met een datawarehouse om de tekortkomingen van elk afzonderlijk op te lossen.
In wezen gebruikt het Lakehouse-systeem goedkope opslag om enorme hoeveelheden gegevens in hun oorspronkelijke vorm te behouden, net als datameren. Het toevoegen van de metadatalaag bovenop de winkel geeft ook datastructuur en maakt databeheertools mogelijk, zoals die in datawarehouses.
Het slaat de enorme hoeveelheden georganiseerde, semi-gestructureerde en ongestructureerde gegevens op die ze krijgen van de verschillende bedrijfsapplicaties, systemen en gadgets die in hun hele organisatie worden gebruikt.
Meestal gebruiken datameren een goedkope opslaginfrastructuur met een file application programming interface (API) om gegevens op te slaan in open, generieke bestandsindelingen.
Dit maakt het voor veel teams mogelijk om via één systeem toegang te krijgen tot alle bedrijfsgegevens voor verschillende initiatieven, zoals datawetenschap, machine learningen bedrijfsinformatie.
Voordelen
- Goedkope opslag. Een data lakehouse moet gegevens kunnen opslaan in goedkope objectopslag, zoals: Google Cloud Storage, Azure Blob Storage, Amazon Simple Storage Service of native met ORC of Parquet.
- Mogelijkheid voor gegevensoptimalisatie: optimalisatie van gegevenslay-out, caching en indexering zijn enkele voorbeelden van hoe een data lakehouse de gegevens moet kunnen optimaliseren met behoud van het oorspronkelijke formaat van de gegevens.
- Een laag met transactionele metadata: bovenop de essentiële goedkope opslag, maakt dit gegevensbeheer mogelijk die cruciaal zijn voor de prestaties van het datawarehouse.
- Ondersteuning voor de Declarative DataFrame API: de meeste AI-tools kunnen DataFrames gebruiken om onbewerkte objectopslaggegevens op te halen. Ondersteuning voor Declarative DataFrame API vergroot de mogelijkheid om de presentatie en structuur van de gegevens dynamisch te verbeteren als reactie op bepaalde datawetenschaps- of AI-taken.
- Ondersteuning voor ACID-transacties: het acroniem ACID, dat staat voor atomiciteit, consistentie, isolatie en duurzaamheid, is een essentieel onderdeel bij het definiëren van een transactie en het waarborgen van de consistentie en betrouwbaarheid van gegevens. Dergelijke transacties waren voorheen alleen mogelijk in datawarehouses, maar de lakehouse biedt de mogelijkheid om ze te gebruiken met datameren ook. Met verschillende gegevenspijplijnen, waaronder gelijktijdige gegevenslezen en schrijven, lost dit het probleem van de lage gegevenskwaliteit van de laatste op.
Elementen van Data Lakehouse
De architectuur van het data lakehouse is op hoog niveau verdeeld in twee hoofdlagen. De data-inname van de opslaglaag wordt gecontroleerd door het Lakehouse-platform (dwz het datameer).
Zonder de gegevens in een datawarehouse te hoeven laden of naar een eigen formaat te hoeven converteren, kan de verwerkingslaag de gegevens in de opslaglaag rechtstreeks opvragen met behulp van een reeks tools.
Vervolgens kunnen BI-apps, maar ook AI- en ML-technologieën de gegevens gebruiken. Dit ontwerp biedt de economie van een datameer, maar omdat elke verwerkingsengine deze gegevens kan lezen, hebben bedrijven de vrijheid om de voorbereide gegevens toegankelijk te maken voor analyse door een reeks systemen. Processorprestaties en kosten kunnen beide worden verbeterd door deze methode voor verwerking en analyse te gebruiken.
Vanwege de ondersteuning voor databasetransacties die voldoen aan de volgende ACID-criteria (atomiciteit, consistentie, isolatie en duurzaamheid), stelt de architectuur ook veel partijen in staat om gelijktijdig toegang te krijgen tot gegevens en deze te schrijven binnen het systeem:
- Atomiciteit verwijst naar het feit dat ofwel de volledige transactie of niets ervan slaagt tijdens het voltooien van een transactie. In het geval dat een proces wordt onderbroken, helpt dit gegevensverlies of corruptie te voorkomen.
- Consistentie garanties dat transacties op een voorspelbare, consistente manier plaatsvinden. Het handhaaft de integriteit van de gegevens door ervoor te zorgen dat alle gegevens legitiem zijn in overeenstemming met vooraf bepaalde regels.
- Isolatie zorgt ervoor dat, totdat het is voltooid, geen enkele transactie kan worden beïnvloed door een andere transactie binnen het systeem. Hierdoor kunnen meerdere partijen tegelijkertijd uit hetzelfde systeem lezen en schrijven zonder elkaar te storen.
- Duurzaamheid garandeert dat wijzigingen in de gegevens in een systeem blijven bestaan nadat een transactie is voltooid, zelfs in het geval van een systeemstoring. Alle wijzigingen die door een transactie worden veroorzaakt, worden voor altijd bewaard.
Data Lakehouse-architectuur
Databricks (de innovator en ontwerper van hun Delta Lake-concept) en AWS zijn de twee belangrijkste pleitbezorgers voor het concept van een data lakehouse. We zullen dus vertrouwen op hun kennis en inzicht om de architecturale lay-out van meerhuizen te beschrijven.
Een data lakehouse-systeem heeft doorgaans vijf lagen:
- Inslikken laag
- Opslaglaag
- Metadatalaag
- API-laag
- Verbruikslaag
Inslikken laag
De eerste laag van het systeem is verantwoordelijk voor het verzamelen van gegevens uit verschillende bronnen en het verzenden naar de opslaglaag. De laag kan verschillende protocollen gebruiken om verbinding te maken met tal van interne en externe bronnen, inclusief het combineren van batch- en streaminggegevensverwerkingsmogelijkheden, zoals:
- NoSQL-databases,
- bestandsshares
- CRM-toepassingen,
- websites,
- IoT-sensoren,
- sociale media,
- Software as a Service (SaaS) applicaties, en
- relationele databasebeheersystemen, enz.
Op dit punt kunnen componenten zoals Apache Kafka voor gegevensstreaming en Amazon Data Migration Service (Amazon DMS) voor het importeren van gegevens uit RDBMS- en NoSQL-databases worden gebruikt.
Opslaglaag
De Lakehouse-architectuur is bedoeld om de opslag van verschillende soorten gegevens als objecten in goedkope objectwinkels, zoals AWS S3, mogelijk te maken. Met behulp van open bestandsindelingen kunnen de clienttools deze items vervolgens rechtstreeks vanuit de winkel lezen.
Dit maakt het voor veel API's en verbruikslaagcomponenten mogelijk om toegang te krijgen tot dezelfde gegevens en deze te gebruiken. De metadatalaag slaat de schema's op voor gestructureerde en semi-gestructureerde datasets, zodat de componenten ze kunnen toepassen op de data terwijl ze deze lezen.
Het Hadoop Distributed File System (HDFS)-platform kan bijvoorbeeld worden gebruikt om cloudrepositoryservices te bouwen die computing en opslag on-premises splitsen. Lakehouse is bij uitstek geschikt voor deze diensten.
Metadatalaag
De metadatalaag is het fundamentele onderdeel van een data lakehouse dat dit ontwerp onderscheidt. Het is een enkele catalogus die metadata (informatie over andere gegevensstukken) biedt voor alle items die in het meer zijn opgeslagen en waarmee gebruikers beheermogelijkheden kunnen gebruiken zoals:
- Een consistente versie van de database wordt gezien door gelijktijdige transacties dankzij ACID-transacties;
- caching om cloud-objectopslagbestanden op te slaan;
- het toevoegen van gegevensstructuurindexen met behulp van indexering om de verwerking van query's te versnellen;
- het gebruik van zero-copy klonen om gegevensobjecten te dupliceren; en
- om bepaalde versies van de gegevens op te slaan, enz., gebruikt u gegevensversiebeheer.
Bovendien maakt de metadatalaag de implementatie van schemabeheer, het gebruik van DW-schematopologieën zoals ster-/sneeuwvlokschema's en de levering van datagovernance en auditmogelijkheden direct op het datameer mogelijk, waardoor de integriteit van de gehele datapijplijn wordt verbeterd.
Functies voor schema-evolutie en handhaving zijn opgenomen in schemabeheer. Door schrijfbewerkingen te weigeren die niet aan het schema van de tabel voldoen, stelt schema-handhaving gebruikers in staat de gegevensintegriteit en -kwaliteit te handhaven.
Schema-evolutie maakt het mogelijk om het huidige schema van de tabel aan te passen aan veranderende gegevens. Door één beheerinterface bovenop het datameer zijn er ook toegangscontrole- en auditmogelijkheden.
API-laag
Een andere cruciale laag van de architectuur is nu aanwezig, met een aantal API's die alle eindgebruikers kunnen gebruiken om taken sneller uit te voeren en geavanceerdere statistieken te krijgen.
Het gebruik van metadata-API's maakt het gemakkelijker om de gegevensitems die nodig zijn voor een bepaalde toepassing te identificeren en te openen.
In termen van machine learning-bibliotheken kunnen sommige, zoals TensorFlow en Spark MLlib, open bestandsindelingen zoals Parquet lezen en rechtstreeks toegang krijgen tot de metadatalaag.
Tegelijkertijd bieden DataFrame-API's grotere kansen voor optimalisatie, waardoor programmeurs verspreide gegevens kunnen ordenen en wijzigen.
Verbruikslaag
Power BI, Tableau en andere tools en apps worden gehost onder de verbruikslaag. Met het ontwerp van het meerhuis zijn alle metadata en alle gegevens die in een meer worden bewaard, toegankelijk voor de client-apps.
Het meerhuis kan door alle gebruikers binnen een bedrijf worden gebruikt om allerlei soorten taken uit te voeren analysebewerkingen, inclusief het maken van business intelligence-dashboards en het uitvoeren van SQL-query's en machine learning-taken.
Voordelen van Data Lakehouse
Organisaties kunnen een data lakehouse creëren om hun huidige dataplatform te verenigen en hun hele datamanagementproces te optimaliseren. Door de silobarrières die verschillende bronnen met elkaar verbinden te ontmantelen, kan een data lakehouse de behoefte aan afzonderlijke oplossingen vervangen.
In vergelijking met beheerde gegevensbronnen levert deze integratie een aanzienlijk effectievere end-to-end-procedure op. Dit heeft meerdere voordelen:
- Minder administratie: In plaats van gegevens uit onbewerkte gegevens te halen en deze voor te bereiden voor gebruik in een datawarehouse, stelt een data lakehouse alle bronnen die eraan zijn gekoppeld in staat om hun gegevens beschikbaar en georganiseerd te hebben voor gebruik.
- Verhoogde kosteneffectiviteit: Data lakehouses zijn gebouwd met behulp van moderne infrastructuur die berekening en opslag verdeelt, waardoor het eenvoudig is om de opslag uit te breiden zonder de rekenkracht te vergroten. Alleen al het gebruik van goedkope gegevensopslag resulteert in schaalbaarheid die kosteneffectief is.
- Beter gegevensbeheer: Data lakehouses zijn gebouwd met een gestandaardiseerde open architectuur, waardoor er meer controle is over beveiliging, metrische gegevens, op rollen gebaseerde toegang en andere belangrijke beheercomponenten. Door middelen en gegevensbronnen te verenigen, vereenvoudigen en verbeteren ze het bestuur.
- Vereenvoudigde normen: Aangezien de verbinding in de jaren tachtig zeer beperkt was, toen datawarehouses voor het eerst werden ontwikkeld, werden vaak gelokaliseerde schemastandaarden ontwikkeld binnen bedrijven, zelfs afdelingen. Data lakehouses maken gebruik van het feit dat veel soorten gegevens nu open standaarden voor schema's hebben door talrijke gegevensbronnen op te nemen met het overlappende uniforme schema om procedures te stroomlijnen.
Nadelen van Data Lakehouse
Ondanks alle heisa rond data lakehouses, is het belangrijk om in gedachten te houden dat het idee nog erg nieuw is. Zorg ervoor dat u de nadelen afweegt voordat u zich volledig inzet voor dit nieuwe ontwerp.
- Monolithische structuur: Het all-inclusive ontwerp van een Lakehouse biedt verschillende voordelen, maar roept ook enkele problemen op. Monolithische architectuur leidt vaak tot slechte service voor alle gebruikers en kan rigide en moeilijk te onderhouden zijn. Doorgaans houden architecten en ontwerpers van een meer modulaire architectuur die ze kunnen aanpassen voor verschillende gebruikssituaties.
- De technologie is er nog niet helemaal: het uiteindelijke doel brengt een aanzienlijke hoeveelheid machine learning en kunstmatige intelligentie met zich mee. Voordat Lakehouses kunnen presteren zoals voorzien, moeten deze technologieën zich verder ontwikkelen.
- Geen significante vooruitgang ten opzichte van bestaande structuren: Er is nog steeds veel scepsis over hoeveel meer waarde Lakehouses daadwerkelijk zullen bijdragen. Sommige tegenstanders beweren dat een ontwerp van een meermagazijn in combinatie met de juiste geautomatiseerde apparatuur een vergelijkbare efficiëntie kan bereiken.
Uitdagingen van Data Lakehouse
Het kan moeilijk zijn om de data lakehouse-techniek toe te passen. Vanwege de ingewikkeldheid van de samenstellende delen, is het onjuist om het data lakehouse te zien als een allesomvattende ideale structuur of "één platform voor alles", bijvoorbeeld.
Bovendien zullen bedrijven, vanwege de toenemende acceptatie van datameren, hun huidige datawarehouses naar hen moeten verhuizen, waarbij ze alleen moeten vertrouwen op een belofte van succes zonder aantoonbaar economisch voordeel.
Als er tijdens het overdrachtsproces latentieproblemen of storingen optreden, kan dit duur, tijdrovend en misschien onveilig worden.
Zakelijke gebruikers moeten zeer gespecialiseerde technologieën omarmen, volgens bepaalde leveranciers die uitdrukkelijk of impliciet oplossingen op de markt brengen als data lakehouses. Deze werken mogelijk niet altijd met andere tools die zijn gekoppeld aan het datameer in het midden van het systeem, wat de problemen nog vergroot.
Bovendien kan het moeilijk zijn om 24/7 analyses te leveren terwijl bedrijfskritieke workloads worden uitgevoerd, wat een infrastructuur met kosteneffectieve schaalbaarheid vereist.
Conclusie
De nieuwste variëteit aan datacenters van de afgelopen jaren is het data lakehouse. Het integreert een verscheidenheid aan gebieden, zoals informatietechnologie, open-source software, cloud computingen gedistribueerde opslagprotocollen.
Het stelt bedrijven in staat om alle soorten gegevens centraal op te slaan vanaf elke locatie, wat het beheer en de analyse vereenvoudigt. Data Lakehouse is een behoorlijk intrigerend concept.
Elk bedrijf zou een aanzienlijk concurrentievoordeel hebben als het toegang had tot een alles-in-één dataplatform dat net zo snel en efficiënt was als een datawarehouse en tegelijkertijd zo flexibel als een datameer.
Het idee is nog in ontwikkeling en is nog relatief nieuw. Als gevolg hiervan kan het enige tijd duren om te bepalen of iets wijdverbreid kan worden.
We zouden allemaal nieuwsgierig moeten zijn naar de richting die de Lakehouse-architectuur opgaat.
Laat een reactie achter