Een dataplatform implementeren

Wat is een (Big) Data Platform?

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

Wat is een data-architectuur?

Een data-architectuur is het raamwerk 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 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:

• Variëteit: 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.
• Velociteit: 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 een behoeftevector op die drie assen kunnen opvangen.

Onderstaande afbeelding toont het verschil tussen batch- en streamingverwerking. 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 datagestuurde 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 uw platform moet onderdeel zijn van het ontwerp. Het vermijden van verticale schaalbaarheid kan ons behoeden voor computer- of opslagbeperkingen. Aan de andere kant stelt horizontale schaling ons in staat om gemakkelijker te schalen vanwege het principe van datadistributie, maar het is complexer door de instrumentatie tussen de verschillende knooppunten.

Trends in dataplatformarchitecturen (1e kwartaal 2022)

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 twee noemen die betrekking hebben op de applicatie- en infrastructuurlagen.

Van monolithisch naar microservices

Monolitisch

Bij het ontwerpen van een applicatie, begin je meestal met een modulaire architectuur die componenten bevat zoals: dataverzameling, opslag, bedrijfslogica en API's voor integratie. Maar ondanks een modulair ontwerp kunnen functies uiteindelijk op één plek worden beheerd en gebruikt.

Enkele voor- en nadelen van monolithische architecturen:

Microservices

Een microservice-architectuur is een ontwerp dat een applicatie structureert als een verzameling of services die gemakkelijk te onderhouden, los gekoppeld en onafhankelijk inzetbaar zijn, en worden beheerd door een klein team.

Voor- en nadelen van microservice-architecturen:

Van server naar serverloze architecturen

Serverarchitecturen blijven voor sommige organisaties een goede optie, vooral bij omgevingen waar aangepaste beveiliging en databescherming moeten 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 serverloze architecturen zorgt een externe organisatie voor je infrastructuur, zodat uw team zich kan concentreren op de toepassingen.

Azure, GCP en AWS zijn hier typische voorbeelden van. Ze bieden de rekenkracht, opslagmogelijkheden en onderlinge verbindingen op elke schaal.

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

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

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

Met containers kunnen ontwikkelaars zich concentreren op de applicatie en de softwareafhankelijkheden, waarbij zowel de hardwarebronnen als de beveiliging worden geabstraheerd. Sommigen beschouwen containers en serverloos 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 (rekenkracht) 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-functies in GCP.

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 of/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 verleend. 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.

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

• Landing Data Zone: Een zone voor externe databronnen kan gegevens naar uw platform pushen zonder de gegevens die je platform opneemt in gevaar te brengen.
• Raw Data Zone: De zone waar je onbewerkte gegevens worden opgeslagen.
• Curated Zone: De zone waar je samengestelde/verwerkte/geanalyseerde/aangepaste data worden opgeslagen en van waaruit deze beschikbaar zullen zijn voor een bredere doelgroep in de organisatie.
• Analytics Sandbox Zone: Een zone waar analyseteams delen van onbewerkte en samengestelde gegevens kunnen ophalen gebruiken voor onderzoek.

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':