Een dataplatform implementeren

Richtlijnen volgens trends in 2022

  • Artikel
  • Data Engineering
een dataplatform implementeren
Oscar-Mike-data-engineer
Oscar Mike Claure Cabrera
Data Engineer/Data Scientist
9 min
29 Apr 2022

Deze blog is bedoeld om onze kennis en ervaring over te dragen aan de gemeenschap door richtlijnen te beschrijven voor de implementatie van een dataplatform in een organisatie, gebaseerd op onze knowhow. We weten dat de specifieke behoeften van elke organisatie anders zijn, dat ze een impact zullen hebben op de gebruikte technologieën en dat één enkele architectuur die aan al deze behoeften voldoet, niet realistisch is. Daarom houden we het in deze blog zo algemeen mogelijk.

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.

data-platform-streaming-versus-batch

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.

monolithische architectuur

Enkele voor- en nadelen van monolithische architecturen:

monolithic-architectures-1

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.

microservices

Voor- en nadelen van microservice-architecturen:

microservices-advantages-disadvantages

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.

difference-server-and-serverless-architectures

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.

Diagram van een algemeen dataplatform

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.
batch-data-flow

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.

Dit artikel werd geschreven door Oscar Mike

Oscar Mike werkt graag in hard core Data Analytics teams. Met een achtergrond in verschillende gebieden van engineering, is hij een T-shaped Data Engineer/Data Scientist met ervaring in de telecom-, productie- en luchtvaartindustrie.

Oscar Mike Claure Cabrera

Data Engineer/Data Scientist

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

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

Misschien vind je dit ook interessant:

Azure App functions configureren

In dit Engelstalige artikel beginnen we met het bespreken van Serverless Functions. Vervolgens demonstreren we hoe je Terraform-bestanden gebruikt om het implementatieproces van een doelinfrastructuur te vereenvoudigen, hoe een Function App in Azure kan worden gemaakt, het gebruik van GitHub-workflows om continuous integration en implementatie te beheren, en hoe branching strategieën kunnen worden gebruikt om code wijzigingen selectief uit te rollen naar specifieke instanties van Function Apps.

Lees meer

Hoe word ik een Data Engineer?

Een paar jaar geleden bestond de functietitel nog niet eens: Data Engineer. Inmiddels is er veel vraag naar Data Engineers. Vrijwel elke organisatie verzamelt bewust data en het besef dat dit op een gestructureerde manier moet gebeuren, groeit. Als de data die je verzamelt niet goed georganiseerd is en klopt, kun je het niet gebruiken als input voor goede beslissingen. Data Engineers bouwen infrastructuren waarmee data wordt verwerkt. Ze zijn daarmee onmisbaar voor organisaties die hun data op een gestructureerde manier willen verzamelen en toepassen.

Lees meer
data geestelijke gezondheidszorg

Centrale dataopslag met een nieuwe data-infrastructuur

Dedimo is een samenwerking van vijf zorginitiatieven in de geestelijke gezondheidszorg. Om de kwaliteit van hun zorg continu te verbeteren, richten ze interne processen efficiënter in. Hiervoor gebruiken ze inzichten uit de data die intern beschikbaar is. Voorheen haalden ze deze data zelf uit verschillende bronsystemen met ad hoc scriptjes. Om dit proces robuuster en efficiënter te maken en verder te professionaliseren, schakelden ze onze hulp in. Ze vroegen ons de centrale opslag van hun data in een cloud data warehouse te faciliteren. Omdat ze al gewend waren te werken met Google Cloud Platform (GCP), was de wens de data-infrastructuur binnen deze omgeving op te zetten.

Lees meer

5 redenen om Infrastructure as Code (IaC) te gebruiken

Infrastructure as Code heeft zich bewezen als betrouwbare techniek om platformen sterk neer te zetten in de cloud. Het vraagt echter wel een extra tijdsinvestering van de betrokken ontwikkelaars. In welke gevallen loont de extra inspanning zich? Je leest het in dit artikel.

Lees meer
billboards

Een schaalbaar machine learning-platform voor het voorspellen van billboard-impressies

The Neuron biedt een programmatisch biedingsplatform om digitale Out-Of-Home-advertenties in realtime te plannen, kopen en beheren. Ze vroegen ons het aantal verwachte impressies voor digitale advertenties op billboards op een schaalbare en efficiënte manier te voorspellen.

Lees meer

Digitale transformatie en betere interne samenwerking dankzij inzicht in off- én online data

Uitgever Malmberg verzamelt veel off- en online data. Steeds meer onderwijsinstellingen maken gebruik van online licenties ter aanvulling op (of in plaats van) gedrukt lesmateriaal. Om hierop in te spelen, maakt Malmberg gebruik van maandelijkse rapportages. Het in-house data team stelt deze samen als input voor specifieke afdelingen. Malmberg vroeg ons dit team te versterken en de interne processen rondom data efficiënter te maken.

Lees meer
Data Engineer aan het werk

Data Engineer

Werk aan uitdagende technische opdrachten bij verschillende opdrachtgevers.

Lees meer
Data Engineering

Een loopbaan als Data Engineer? Geef je eigen opleiding vorm

In juni 2020 werd Sander onderdeel van ons team. Hoewel hij midden in coronatijd startte, merkte hij al snel dat hij flink gestimuleerd werd om contact te maken met zijn nieuwe collega’s. Dit ging grotendeels vanzelf als onderdeel van ons onboarding programma: “Dit sloot perfect aan bij mijn behoeftes: ik ben namelijk zelf veel collega’s gaan opbellen om kennis te maken!” Lees hoe Sander zijn eigen opleiding tot Data Engineer vormgeeft.

Lees meer
Data engineer Oskar in gesprek

5 vragen voor Data Engineer Oskar

In deze video ontdek je hoe een baan als Data Engineer eruit ziet! Hoe ziet een werkweek eruit, voor welke klanten werken onze Data Engineers en wat maakt het werken zo leuk? Oskar vertelt je er graag meer over!

Lees meer