Een dataplatform implementeren

Wat is een (Big) Data Platform?

Een dataplatform is een oplossing voor het verkrijgen, opslaan, verwerken, analyseren en leveren van analytische gegevens binnen een organisatie. Het helpt hen bij een end-to-end datagedreven aanpak, om interne behoeften op te lossen en taken en beslissingen te automatiseren.

Wat is een data-architectuur?

Een data-architectuur is het framework voor de data-omgeving van een organisatie. De data-architectuur is niet het dataplatform zelf, maar het te volgen plan bij het uitvoeren van dataprocessen zoals dataverzameling, -transformatie en -distributie. Het omvat de datamodellen, het beleid, de regels en normen die bepalen welke data worden verzameld en hoe deze worden opgeslagen en geïntegreerd in het systeem van de organisatie. Het dataplatform daarentegen is de reeks technologieën die deze taken uitvoert terwijl de regels die bepaald zijn op het platform worden nageleefd.

Er is altijd een data-architectuur, ook als deze niet expliciet is omschreven. Als een data-architectuur niet expliciet is bepaald, is de architectuur de verzameling van vaak gefragmenteerde, impliciete en informele regels van de organisatie bij het bouwen, onderhouden en gebruik van hun dataplatform.

Overwegingen bij het ontwerpen van een dataplatform

Data-architectuur

Zoals eerder vermeld bevat een data-architectuur het plan om met data te werken. Het is de basis om te bepalen welke componenten nodig zijn en hoe we deze zullen samenbrengen.

Data

Data is natuurlijk een essentieel onderdeel van een dataplatform en om het te definiëren, zijn er drie hoofdkenmerken waarmee rekening moet worden gehouden, ook bekend als de 3 V's:

• Variety: Type en aard van data. Hoe groot is de variatie in de technische vorm en lay-out van de data, en de structuur (of het ontbreken daarvan) van de inhoud? Een grotere variëteit vereist meer gespecialiseerde tools.
• Volume: Hoeveelheid data. Miljoenen rijen per uur of slechts honderden? Een groot volume vereist verspreide verwerking en grote variatie in volume vereist on-demand voorziening van infrastructuur.
• Velocity: Snelheid van dataverwerking. Hoe snel moet je de data verwerken? Batch of streaming? Hoe sneller je informatie wilt, hoe sneller een dataplatform moet reageren op binnenkomende data.

Een modern dataplatform moet de groei van behoeften op die drie assen kunnen opvangen.

Onderstaande afbeelding toont het verschil tussen batch- en streamingsverwerking. Batch verwerkt de datagebeurtenissen die gedurende een bepaalde periode zijn opgeslagen/gebufferd, terwijl streaming ze verwerkt zodra de datagebeurtenissen beschikbaar zijn.

Datalevering (gedemocratiseerde toegang)

Het belangrijkste doel van het implementeren van een dataplatform is om een end-to-end datagedreven aanpak toe te passen, dus het is essentieel om data beschikbaar te maken voor elk team in de organisatie.

Natuurlijk mag niet iedereen toegang hebben tot al je data, maar door een goede data-architectuur te volgen, kunnen we bepalen en beperken tot welke delen van de gegevens elk team toegang nodig heeft om hun werk zo efficiënt mogelijk te doen.

Schaalbaarheid

Schaalbaarheid verwijst naar het vermogen van een systeem om zich aan te passen aan de veranderende vraag. Om te groeien, of op te schalen als de vraag toeneemt, maar ook om af te schalen als de vraag afneemt. Er zijn twee benaderingen voor schaalbaarheid: horizontaal schalen en verticaal schalen.

Het plannen van de schaalbaarheid van je platform moet onderdeel zijn van het ontwerp. Het vermijden van verticale schaalbaarheid kan ons behoeden voor compute- of opslagbeperkingen. Aan de andere kant stelt horizontale scaling ons in staat om gemakkelijker te schalen vanwege het principe van datadistributie, maar het is complexer door de benodigde orkestratie tussen de verschillende nodes.

Trends in dataplatform architecturen (1e kwartaal 2024)

Trends in software- en infrastructuur-architecturen zijn ook belangrijk bij het implementeren van een datatoepassing en de infrastructuur die deze zal uitvoeren. In dit deel zullen we er drie noemen die betrekking hebben op de applicatie- en infrastructuurlagen.

Van server naar serverless architecturen

Serverarchitecturen blijven voor sommige organisaties een goede optie, vooral bij omgevingen waar aangepaste beveiliging en databescherming moet worden geïmplementeerd. Het belangrijkste nadeel van deze architectuur is de kostprijs, het is duur om een team in te huren om voor je servers te zorgen, capaciteitsverhoging te plannen en software- en beveiligingsupdates te installeren.

Bij serverless architecturen zorgt een externe organisatie voor je infrastructuur, zodat uw team zich kan concentreren op de toepassingen.

Azure, Google Cloud Platform (GPC) en Amazon Web Services (AWS) zijn hier typische voorbeelden van. Ze bieden de compute resources, opslagmogelijkheden en onderlinge verbindingen op elke schaal.

Onderstaande afbeelding illustreert het verschil tussen server- en serverless architecturen. De grijze vakken tonen de onderdelen waar de teams zich moeten inzetten om de belangrijkste applicaties te onderhouden.

Containers en FaaS (Functions as a Service) zijn twee voorbeelden van serverless architecturen.

Containers zijn een oplossing om je software op een betrouwbare manier te laten draaien wanneer deze van de ene computing environment naar de andere wordt verplaatst. Het zijn 'lichtgewicht pakketten van je applicatiecode samen met afhankelijkheden zoals specifieke versies van programming runtimes en libraries die nodig zijn om jouw softwareservices uit te voeren'.

Met containers kunnen ontwikkelaars zich concentreren op de applicatie. Daarnaast worden de softwareafhankelijkheden, zowel de hardware resources als de beveiliging, geabstraheerd. Sommigen beschouwen containers en serverless misschien als twee verschillende benaderingen, maar als we dieper ingaan op de details, lijken ze behoorlijk op elkaar. Wanneer een ontwikkelingsteam een applicatie ontwerpt en deze verpakt als een pod (set van Docker-images met de bijbehorende afhankelijkheden), kunnen ze deze implementeren op een in de cloud gehoste Kubernetes-cluster dat de hardware zal leveren om deze uit te voeren, waarbij het beheer van de infrastructuur wordt geabstraheerd van de ontwikkeling van de applicatie.

Aan de andere kant stelt FaaS ontwikkelaars in staat om hun inspanningen in de applicaties te steken door ze te abstraheren op een manier waarop ze zich alleen op de functies ervan concentreren. Functies zijn de individuele componenten die je applicatie maken, bijvoorbeeld individuele taken zoals het toevoegen van nieuwe gegevens aan een SQL-tabel, authenticatie, het toevoegen van nieuwe gebruikers, enz. Deze functies worden geactiveerd door een gebeurtenis, zijn van bepaalde duur en worden toegewezen aan stateless containers (compute resources) die worden geleverd door de cloudprovider op basis van de complexiteit van de codering en de huidige vraag.

Een voorbeeld van FaaS is Azure Functions in Azure, Lambda in AWS of Google Cloud Functions in GCP.

Groeiende behoefte naar generatieve AI-oplossingen

Door de razendsnelle opkomst van generatieve AI is de behoefte aan data van hoge kwaliteit nog meer toegenomen. Het moderne dataplatform moet in staat zijn om deze grote datasets met gestructureerde en ongestructureerde informatie te verwerken en aan te bieden aan de modellen.

De opslag voor deze AI-verwerking moet een lage latency en realtime toegang tot gegevens mogelijk maken. Daarnaast is de veilige opslag van bedrijfsinformatie van groot belang voor veel interne use cases. Dit brengt extra privacy en security vereisten met zich mee.

Generatieve AI-modellen vereisen vaak veel rekenkracht voor training en inferentie, hierdoor zal de behoefte om snel krachtigere hardware bij te schalen van groot belang zijn. Distributie van compute resources binnen het dataplatform is nodig om prestaties en schaalbaarheid te kunnen garanderen.

Goede data governance is essentieel

Steeds meer organisaties hebben te maken met een groeiende hoeveelheid aan gegevens die afkomstig zijn van een groot aantal interne en externe bronnen. Denk hierbij aan een variëteit van gestructureerde databases tot ongestructureerde afbeeldingen, teksten, audiobestanden en video’s. Daarnaast zien we dat er een toenemende druk is vanuit regelgeving om nauwkeurig om te gaan met (persoons)gegevens.

Om al deze databronnen te beheersen en effectief in te zetten, is het belangrijk deze gestructureerd te beheren. Uiteindelijk is hoge gegevenskwaliteit noodzakelijk omdat de gegevens de basis voor besluitvorming vormen binnen organisaties. Vertrouwen in de kwaliteit van de beschikbare gegevens speelt hierbij tevens een grote rol.

De volgende technische functionaliteiten van een dataplatform kunnen de business requirements op het gebied van data governance ondersteunen:

1. Het vastleggen van data eigenaarschap.
2. De beschikbaarheid van een datacatalog om transparantie te bieden over de beschikbare gegevens en de manier waarop deze tot stand komen (data lineage).
3. Brede mogelijkheden om metadata toe te voegen aan de beschikbare datasets.
4. Het granulair beheren van toegang tot de data.
5. Het afdwingen van beleid door het toepassen van regels en conventies.
6. Meerdere opties voor het veilig opslaan van data, onder meer door encryptie, anonimisering en toegangscontrole.

Diagram van een algemeen dataplatform

Nu enkele concepten en trends zijn besproken, kunnen we beginnen met een schema over hoe ons dataplatform eruit zal zien, welke componenten het moet hebben en hoe het de verschillende stappen in een beheerde datastroom zal beheren en loskoppelen.

Zoals weergegeven in bovenstaand diagram, hebben we dit in vijf hoofdcomponenten opgesplitst:

1. Data Ingestion. – Dit blok is bedoeld om de dataverzameling uit externe bronnen te beheren. Het moet in staat zijn om data in batch te verkrijgen door opnametaken te plannen en indien nodig ook streamingbronnen te beheren. Schaalbaarheid is ook een belangrijke functie voor dit blok, het moet de flexibiliteit hebben om meerdere gegevensbronnen toe te voegen en grotere hoeveelheden ervan te beheren.
   
   
2. Data Processing. – Dit blok is gewijd aan dataverwerking. Het moet data in hun definitieve vorm brengen en teamleden in staat stellen om op grotere schaal onderzoek/testen uit te voeren.
   
   
3. Data Storage. – Data moeten worden opgeslagen in een centrale module (maar niet in een enkele database of bestandssysteem!) om silo's in de organisatie te voorkomen. Dit blok moet verschillende eindpunten kunnen dienen. Zowel teams als applicaties mogen alleen toegang hebben tot data waartoe ze toegang hebben verkregen. Datatransacties moeten waar mogelijk ACID zijn.
   
   
4. Data Serving. – Dit algemene blok omvat de applicatie(s) waaraan we data zullen leveren. Het kan visualisatie-engines, AI & ML, data-analyse, API's of andere eindpunten omvatten.
   
   
5. Data Governance. – Omvat het vermogen van de organisatie om de datakwaliteit te waarborgen gedurende een volledige levenscyclus. De focus moet liggen op de beschikbaarheid, bruikbaarheid, integriteit en beveiliging van data.

Extra opmerkingen over het onderdeel dataopslag

Zoals vermeld aan het begin van deze blog, willen we een algemene dataplatformarchitectuur beschrijven, dus zonder al te specifiek te zijn over de behoeften, kunnen we een stap verder gaan om het onderdeel dataopslag te beschrijven. Een module voor dataopslag moet al je data bevatten, maar opgedeeld in verschillende zones, afhankelijk van de aard van de gegevens.

Bovenstaand schema toont 4 verschillende gegevenszones op onze opslagcomponent, evenals hoe data moeten stromen wanneer dataverzameling in batch wordt gebruikt:

• Landing Zone: De zone waar je onbewerkte gegevens worden opgeslagenin het formaat waarin ze worden aangeboden door het externebronsysteem.
• Bronze Zone: De zone waar je ruwe data in tabelvorm beschikbaar wordt gesteld, zonder verdere transformaties.
• Silver Zone: De zone waar je data wordt opgeschoond, samengevoegd en op elkaar afgestemd zodat het een overzicht geeft van je belangrijkste bedrijfsonderdelen.
• Gold Zone: De zone met daarin gebruiksklare en project specifieke databases. De data in deze laag is bedoeld voor rapportages en het leveren van business inzichten. Om deze reden zijn ze vaak gedenormaliseerd en geoptimaliseerd om te lezen.

In vergelijking met de dataopslag zijn de onderdelen dataverzameling, -verwerking, -serving en -beheer afhankelijk van de specifieke vereisten van de organisatie, dus we zullen in deze blog niet verder in detail treden. We gaan graag met je in gesprek als er een specifieke behoefte is die je met ons wilt bespreken. Neem hier contact met ons op.

Versterk ons team als Data Engineering Consultant

Wil je dataplatforms implementeren voor verschillende soorten klanten en deel uitmaken van een team van meer dan 100 ambitieuze dataprofessionals? Bekijk onze vacature en solliciteer hier.

1x per maand data insights, praktijkcases en een kijkje achter de schermen ontvangen?

Meld je aan voor onze maillijst en blijf 'up to data':