Neem contact op
Bel mij terug

Leer in 7 minuten

  1. Waarom het kopiëren van data tot problemen kan leiden
  2. Op welke twee pijlers het dataminimalisatieprincipe rust
  3. Wat het dataminimalisatieprincipe kan betekenen in verschillende situaties

Dataminimalisatie in de praktijk

In 2018 zijn er meer dan 2,5 triljoen bytes per dag geproduceerd en schattingen laten zien dat dit getal in 2025 kan groeien tot 175 triljard bytes. Veel van deze data is niet origineel, maar is een kopie. Met deze duizelingwekkende groei in het vooruitzicht, wordt het steeds belangrijker bij de beperking ervan stil te staan, zeker omdat het ook steeds moeilijker wordt om al deze data te beveiligen en de kwaliteit ervan hoog te houden.

Dataminimalisatie is het streven naar het zo min mogelijk kopiëren van data. Het principe rust op twee pijlers: ten eerste, het toepassen van data-on-demand in plaats van data-by-delivery en ten tweede, het verstrekken van toegang aan dataconsumenten tot zoveel mogelijk originele data en niet gekopieerde data.

Het artikel ‘Dataminimalisatie: Het nieuwe ontwerpprincipe voor data-architecturen’ bevat een beschrijving van dataminimalisatie als ontwerpprincipe voor data-architecturen en de gevolgen die het ongebreideld kopiëren van data met zich meebrengt. Dit artikel gaat een stap verder. Het gaat in op de praktijk en het behandelt de effecten van de toepassing van dataminimalisatie aan de hand van enkele voorbeelden.

Voorbeeld 1

In veel organisaties wordt periodiek data via bestandsuitwisseling of standaardrapportage naar externe partijen en overheidsorganen gestuurd. Dit is een duidelijk geval van data-by-delivery en steunt volledig op het kopiëren van data. De te versturen bestanden vormen al kopie nummer 1. Na verzending worden ze door de dataconsument (ontvanger) opgeslagen (kopie 2) en vervolgens in een van hun eigen databases geladen (kopie 3).

Het maken van al deze kopieën hebben verschillende nadelen tot gevolg, deze kun je terugvinden in het vorige artikel ‘Dataminimalisatie: Het nieuwe ontwerpprincipe voor data-architecturen’. Deze data-by-delivery oplossing kan vervangen worden door een data-on-demand oplossing waarbij dataconsumenten met behulp van query’s de benodigde data opvragen. In plaats van periodiek een query uit te voeren op een systeem om data op te halen, het resultaat naar een bestand weg te schrijven en vervolgens naar de consument te versturen, kan de consument zelf een query uitvoeren op hetzelfde bronsysteem. Het resultaat van die query bevat dezelfde data als het te versturen bestand.

Deze oplossing elimineert veel van de nadelen van het kopiëren van data. De workload op het aanleverende systeem is echter bij data-on-demand minder voorspelbaar, terwijl die van data-by-delivery volledig voorspelbaar is. De workload zal ook toenemen en dat kan betekenen dat zwaardere technologie ingezet moet worden.

Voorbeeld 2

Een data-by-delivery oplossing waarbij grote hoeveelheden data via bestandsuitwisseling of standaardrapportage naar dataconsumenten gestuurd worden, kan in sommige gevallen vervangen worden door een data-on-demand oplossing waarbij consumenten alleen ophalen wat ze nodig hebben.

Stel dat een gemeente wekelijks bepaalde data over burgers ontvangt van een ander overheidsorgaan. De gemeente gebruikt deze data voor het geval burgers een specifieke vraag stellen, waarbij elke vraag alleen data van die betreffende burger betreft. Dit betekent dat er telkens te veel data verstuurd wordt, namelijk data van alle burgers in hun gemeente. De overgrote meerderheid van de burgers zal in die week niet met een vraag komen. Maar omdat de gemeente niet vooraf weet welke burger een vraag gaat stellen, wordt telkens het gehele bestand ververst. De gemeente werkt dus met een kopie die, naarmate de week vordert, steeds meer verouderd raakt.

Deze vorm van bestanduitwisseling kan vervangen worden door een oplossing gebaseerd op data-on-demand. In plaats van elke week een bestand te versturen, heeft de gemeente live toegang tot de data. Zo kan de gemeente de gegevens van een burger inzien op het moment dat de betreffende burger de vraag stelt. In dit geval worden geen kopieën gebruikt, maar mogelijk originele data die niet verouderd is. De noodzaak om de data fysiek bij de gemeente op te slaan, te beveiligen en te beheren vervalt hiermee.

In het voorbeeld betekent deze verandering dat er bij de gemeente minder technologie ingezet hoeft te worden, er is slechts één applicatie nodig waarmee de data bij het overheidsorgaan opgevraagd kan worden. Bij dat overheidsorgaan verandert de workload wel sterk. In plaats van één bestand per week aan te maken, moet het nu mogelijk zijn dat het constant veel “kleine” query’s kan verwerken.

Voorbeeld 3

Veel organisaties gebruiken nog steeds klassieke datawarehouse-architecturen. In deze architecturen wordt data gekopieerd van bronsystemen naar een staging area, dan naar een datawarehouse, vervolgens naar datamarts en soms zelfs naar kubussen. Dataminimalisatie hier toepassen betekent dat bijvoorbeeld fysieke datamarts en kubussen vervangen worden door een virtuele laag geïmplementeerd met databaseviews of een datavirtualisatieserver. De architectuur verandert dan in een logische datawarehouse-architectuur.

Voorbeeld 4

Veel datalakes bevatten ook gekopieerde data. In sommige datalakes wordt data zelfs meerdere keren opgeslagen in zogenaamde tiers of zones. Ook hier is het raadzaam om meer met virtuele lagen te werken om de hoeveelheid gekopieerde data te minimaliseren.

On Demand

Dit zijn slechts enkele praktische voorbeelden van hoe het aantal kopieën drastisch verminderd kan worden door dataminimalisatie toe te passen.

Het effect van dataminimalisatie is bijna altijd dat er een grotere workload verwerkt zal moeten worden door de systemen die de originele data bevatten. Sommige architecten zetten hun vraagtekens bij de haalbaarheid hiervan. Ze zullen beweren dat er geen enkele technologie bestaat die zo’n workload kan verwerken en dat een dergelijke architectuur technisch en qua performance onhaalbaar is. Deze technologie bestaat wel degelijk, waaronder analytical SQL-databaseservers, cloudplatformen, translytical SQL-databaseservers, en datavirtualisatie engines.

Als bedrijven zoals YouTube erin slagen om miljoenen klanten te voorzien van video-on-demand, waarbij megabytes per seconde verstuurd worden, zou elke organisatie met veel minder traditionele, administratieve data data-on-demand moeten kunnen leveren.

Welke voordelen zou het toepassen van dataminimalisatie bij het ontwerpen van data-architecturen jou op kunnen leveren?

Webinar: Dataminimalisatie, van data-by-delivery naar data-on-demandTijdens dit webinar maak je kennis met de voordelen van het toepassen van het dataminimalisatieprincipe bij het ontwerpen van data-architecturen.Schrijf je hier in voor het gratis webinar!