De vijf aandachtspunten bij de ontwikkeling van een data lake

Whitepaper

Auteur:

Martin van Mierloo

Veel organisaties bezitten een schat aan historische data.

Van klantdata tot financiële data en van onderzoeksdata tot

data over social media. Vaak zit deze data opgesloten in

verschillende systemen en applicaties. Een klassiek IT-

vraagstuk is hoe deze data gecombineerd kan worden tot

centrale inzichten. Aan de hand van deze inzichten kunnen

betere keuzes worden gemaakt of een hogere efficiëntie

worden bereikt.

Een regelmatig gebruikte oplossing om databronnen te combineren is het ontwikkelen van een data lake. Een data lake is een vorm van dataopslag waarbij data afkomstig van meerdere bronnen initieel in ruwe vorm wordt opgeslagen. Op basis van deze ruwe data kan bijvoorbeeld data verrijkt

worden, kunnen gecombineerde analyses worden uitgevoerd, of processen worden aangesloten die gebruik maken van de gecombineerde data.

Inleiding

Data lakes worden vaak genoemd als versneller op gebieden zoals data science en machine learning. Ondanks de aantrekkelijke gedachte van alle data centraal op één plaats,

is de afgelopen jaren duidelijk geworden dat data lakes geen magische oplossingen zijn. Analistenfirma’s zoals Gartner en Forrester bevestigen al een aantal jaren dat een opvallend aantal implementaties geheel of gedeeltelijk mislukt zijn door verkeerde verwachtingen of verkeerde keuzes1). Vanuit Luminis komen wij dit ook tegen in de markt.

Vaak ontstaan implementatieproblemen door verkeerde verwachtingen in combinatie met een te grote focus op de technologie. Deze paper helpt u om een afgewogen keuze te maken of een data lake passend is voor uw situatie. Vanuit

zowel theorie als praktijk nemen we u mee in enkele afwegingen, randvoorwaarden, kansen en risico’s. Ook schetsen we alternatieve oplossingen voor een data lake. Hierdoor bent u beter in staat om een keuze te maken en kunt u de juiste stappen zetten om succesvol te zijn in de

uitvoering van uw datastrategie.

Tot 2005 was verreweg de meest gebruikte opslagvorm een relationele database. Meer dan 30 jaar vulden relationele databases de meeste ontwikkel- en gebruikersbehoeften prima in. Met name door de rol van het internet groeide de

hoeveelheid gegenereerde data sterk en was er ook meer behoefte aan analyses van deze grote hoeveelheden data. Bijvoorbeeld in het geval van websites met veel gebruikers of veel interacties. De opkomst van technieken zoals NoSQL en Bigtable markeerden in 2005 daarom de start van het

‘big data’-tijdperk. Relationele databases zijn heel erg goed in het verwerken van transacties. Dit wordt ook wel Online Transaction Processing (OLTP) genoemd. Nieuwe opslagmethodes zoals Bigtable en Hadoop zijn door hun structuur en architectuur veel beter geschikt voor opslag, bewerking en analyses van big data. Dit wordt ook wel

Online Analytical Processing (OLAP) genoemd. Naast backoffice applicaties werd steeds vaker een datawarehouse opgezet voor analyse-doeleinden, omdat de meeste enterprise applicaties niet geschikt zijn voor

grootschalige en complexe analyses. Data vanuit applicaties (Finance, logistiek, CRM etc.) komt samen in een datawarehouse, waar de data gestructureerd wordt opgeslagen. In datawarehouses wordt data zo veel mogelijk in structuren zoals tabellen opgeslagen, voorzien van de

juiste metadata, volgens strakke definities en herleidbaar tot de bron. De groei van het aantal datawarehouses zorgde er ook voor dat steeds meer organisaties Business Intelligence rollen of afdelingen creëerden.

In 2010 kwam James Dixon, CTO van analyticsplatform Pentaho, met de nieuwe term ‘data lake’. Hij gebruikte hiervoor een metafoor. De gestructureerde data in datawarehouses vergeleek hij met flesjes water. Allemaal

gestandaardiseerde afmetingen en kwaliteit, en klaar voor gebruik. Voor sommige toepassingen is dit prima, maar voor andere toepassingen zijn flesjes water helemaal niet handig. Voor data science of voor exploratief onderzoek kan het handig zijn om toegang te hebben tot een grote hoeveelheid

water, zonder beperkingen van een flesje. Zo’n meer van data – oftewel data lake – biedt gebruikers directe toegang tot de ruwe en ongestructureerde data, zodat de gebruikers hier zelf hun toepassing mee kunnen verzinnen. De verplichte dataschema’s binnen een datawarehouse zijn een essentieel verschil met data lakes, die in de basis met ruwe

data werken2). Tien jaar later is de term data lake een architectuurpatroon geworden dat regelmatig wordt toegepast binnen organisaties. Er is een heel ecosysteem ontstaan van

bedrijven die onderdelen van data lakes of kant-en-klare data lakes leveren. Door de opkomst van cloud-infrastructuren vanaf 2010 worden steeds meer data lakes in de cloud gehost, of ontwikkeld op basis van cloud services. De verwachting is dat op termijn alle data lakes in de cloud

zullen draaien. Cloud-infrastructuren bieden naast lage opstartkosten en vrijwel onbeperkte opslag ook grote bewerkings- en rekencapaciteit voor bijvoorbeeld machine learning-toepassingen.

De oorsprong van data lakes

RELATIONALE DATABASES

1970 1970 2005 2010 2020

DATA WAREHOUSES BIG DATA DATA LAKES CLOUD DATA LAKES

CLOUD

BIG DATA

5 DE TOP 5

AANDACHTSPUNTEN BIJ DE

ONTWIKKELING VAN EEN

DATA LAKE

Er zijn veel soorten data binnen een organisatie. Een bekend model om data onder te verdelen komt van Bill Inmon3):

Een praktijkvoorbeeld Een producent van elektrische componenten wil onderzoeken hoe ze het onderhoud aan machines beter kunnen plannen zodat het zo min mogelijk gevolgen heeft voor de logistieke keten. Daarom wil de producent een

analyse hebben van logistieke data, gecombineerd met onderhoudsdata en sensordata van verschillende machines. De logistieke data en onderhoudsdata blijken behoorlijk

gestructureerd. De sensordata moet eerst voorbewerkt worden, want het volume is te groot en slechts een deel van de data is nodig. Het implementatieteam besluit om alleen de momenten vast te leggen wanneer sensoren buiten hun normwaarden gaan. Dit reduceert de data met 95%. Tevens is dit een eerste classificatie die later bij de

analyse waardevol blijkt in de voorspellingsscenario’s. Uit de analyse komen verschillende inzichten. Het blijkt dat onderhoud aan het begin van de avond de minste gevolgen heeft voor de logistieke keten. Ook blijkt dat een

bepaald type machine vaker onderhouden moet worden. Er zijn bij dit type machine in het verleden door te laat onderhoud vaak verstoringen geweest met grote gevolgen voor de logistieke operatie. Op basis van deze inzichten wist dit bedrijf de productiecapaciteit met 6% te

vergroten zonder grote investeringen.

1. Gestructureerde versus ongestructureerde data

Slechts 10-20% van de data binnen organisaties is gestructureerde data4). De overige data is ongestructureerd. Ongestructureerde data is weer onder te verdelen in repetitieve data en niet-repetitieve data. Repetitieve data is

data die behoorlijk voorspelbaar en vaak doorlopend gegenereerd wordt, zoals data van sensoren. Niet-repetitieve data is onder te verdelen in tekstuele data en niet-tekstuele data.

Deze verschillende categorieën data hebben meestal een behoorlijk verschil in business waarde. Data afkomstig van sensoren in een fabriek heeft bijvoorbeeld een repetitief karakter en heeft in het algemeen een lage business waarde. Dat komt omdat de kosten om de data te vervangen, of de

prijs die een concurrent voor de data over heeft relatief laag zullen zijn. Voor de keuze en inrichting voor een data lake betekent dit dat het belangrijk is om goed na te denken welke data u wel en niet onder brengt in een data lake. In de praktijk gebeurt

het nog regelmatig dat grote hoeveelheden data met een lage business waarde in een data lake worden geïmporteerd. Dit resulteert in kosten waar weinig waarde tegenover staat. Door het karakter van bijvoorbeeld sensordata of visuele data moeten ook veel bewerkingen worden uitgevoerd

voordat overstijgende analyses uitgevoerd kunnen worden. Alle bewerkingen kosten tijd en geld, zowel aan de implementatie- als beheerkant.

Orders, transacties

Bijvoorbeeld

Business waarde

Sensoren (IoT) E-mail, documenten

Afbeeldingen, Video

ALLE DATA

GESTRUCTUREERD ONGESTRUCT UREERD

NIET-REPETITIEF

OVERIGTEKST UEEL

REPETITIEF

! ! ! !! ! ! !! ! ! !! ! ! !

Zonder aanpassingen is deze data meestal niet bruikbaar voor data scientists of business analisten. Na bewerkingen is de data van voldoende kwaliteit voor de data scientists om te gebruiken. Voor andere toepassingen is dit nog niet

voldoende. Een deel van de data kan vertrouwelijk zijn en moet apart afgeschermd worden door middel van autorisaties, pseudonimisering en/of anonimisering. Ook een data lake moet uiteraard voldoen aan AVG- en GDPR-wetgeving.

Hiervoor zijn een data governance proces en verschillende bewerkingen nodig. Let er bij de technologiekeuze voor een data lake op dat er voldoende mogelijkheden zijn voor een waterdichte autorisatie- en toegangsstructuur. Anders loopt u enorme security- en compliance-risico’s.

De belangrijkste data is gecureerde data. Dit is data waarvan de herkomst herleidbaar is (door data lineage of data provenance), die voldoende metadata heeft en waarvan aan alle kwaliteitscriteria wordt voldaan. Voor organisaties die

aan de slag willen met een data lake betekent het dat ze moeten nadenken over de hoeveelheid data governance die nodig is om uiteindelijk zoveel mogelijk data op een hoog kwaliteitsniveau te krijgen. Als dit niet goed geregeld is, dan is de uiteindelijke business rapportage misschien onbetrouwbaar. Of bent u in het ergste geval niet in control

over uw data. Het is belangrijk om dit uitzoekwerk vóór een implementatie te doen, omdat het grote gevolgen kan hebben als dit onderschat wordt. Alle bewerkingen op de

data, inregelen van autorisaties, inrichten van data governance en data lineage zijn namelijk arbeidsintensief en brengen dus hoge kosten met zich mee.

De volgende vragen zijn belangrijk om te beantwoorden

voordat met de implementatie wordt gestart: 1. Hoe ziet de classificering van de data in het data lake

eruit? (Gestructureerd, ongestructureerd etc.) 2. Wat is de verwachte business waarde van deze data?

Hoe verhoudt deze zich met de waarde die het data lake mogelijk kan opleveren?

3. In welke mate zijn bewerkingen vooraf nodig om de data op een zinvolle manier met elkaar te correleren? Maak ook een inschatting van de kosten om dit te ontwikkelen, want op dit punt zijn heel veel organisaties opgezadeld met onverwachte kosten. Indien er veel

bewerkingen nodig zijn, stel dan de vraag of een data lake wel de meest passende oplossing is. (zie ook het hoofdstuk ‘Alternatieven voor een data lake’)

2. Data governance en datakwaliteit

Data governance staat voor het voorspelbaar, controleerbaar en procesmatig zorgen voor de juiste datakwaliteit. De inrichting van data governance speelt een

belangrijke rol bij de inrichting van data lakes, omdat de kwaliteit van de gegeneerde inzichten afhangt van de kwaliteit van de data. Data governance gaat ook verder dan een aantal technische bewerkingen (zoals Extract, Transform en Load bewerkingen) en gaat ook over processen, organisatie, autorisatie en kennis.

Een data lake is in veel gevallen op te delen in verschillende gebieden, met een wisselende datakwaliteit en data governance. Onderstaande afbeelding laat een aantal stadia zien waarin de data zich kan bevinden. In de meeste gevallen

stroomt ruwe, onbewerkte data het data lake in.

Lage datakwaliteit

Weinig governance Veel governance

Voldoende datakwaliteit

Ad-hoc rapportage Data science rapportage

Standaard rapportage Self-service rapportage

Hoge datakwaliteit

RUWE DATA

DATA ENGINEERS

DATA SCIENTIS TS DATA STEWARDS

BUSINESS ANALISTEN DATA SCIENTIS TS

BEWERKTE DATA VERTROUWELIJKE DATA

GECUREERDE DATA

3. Een centraal data lake of

Voor de opkomst van data lakes was het niet ongebruikelijk dat voor een hele organisatie één datawarehouse werd

opgezet. Indien nodig werd dit onderverdeeld in verschillende ‘data marts’, oftewel subsets van data. Voor datawarehouses was dit mogelijk, omdat de data goed gestructureerd is en omdat het datavolume nog beperkt was. De performance en kwaliteit was op deze manier te waarborgen.

Bij de implementatie van een data lake is een gecentraliseerde aanpak niet altijd logisch en verstandig. Stel, een autofabrikant wil een data lake opzetten. Een autofabrikant is georganiseerd in verschillende

bedrijfsonderdelen, zoals R&D, productie, marketing, landenorganisaties, inkoop en service. Theoretisch is het mogelijk om alle data van al deze bedrijfsonderdelen in één data lake te laden. Dit zou toegevoegde waarde bieden bij analyses die deze bedrijfsonderdelen overstijgen. De meeste

analyses zullen echter binnen één bedrijfsonderdeel plaatsvinden. Daarom zijn meerdere en gescheiden data lakes bij grotere organisaties vaak een betere optie. Als daarnaast grote hoeveelheden ongestructureerde data worden toegevoegd, zal het data lake binnen afzienbare tijd

een onbeheersbare bron met een lage datakwaliteit en een lange analysetijd worden. Dit heeft niet met de techniek te maken, maar met de benodigde domeinkennis om over al deze bedrijfsonderdelen structuur aan te brengen in de data en de datakwaliteit te verbeteren. Alle afzonderlijke

bedrijfsonderdelen vragen namelijk specifieke kennis van de bronnen van de data. Er is kennis nodig van de structuur van de data en de metadata. Er is kennis nodig om vast te stellen dat verschillende data-objecten van klanten eigenlijk één en dezelfde klant zijn. Er is domeinspecifieke kennis nodig om

meerdere data lakes?

Een data lake voor Amazon Amazon is één van de grootste data-bezitters ter wereld. In 2019 heeft Amazon een data lake ontwikkeld om tot betere centrale inzichten te komen. Het standaardbeleid

binnen Amazon is dat bedrijfsonderdelen zelf vrijheid hebben in keuze voor opslag van data. Dit bevordert de innovatie en maakt de integratie van overgenomen bedrijven ook eenvoudiger.

Om tot integrale financiële en logistieke inzichten te komen heeft Amazon een data lake ontwikkeld dat data uit meer dan 25 verschillende databronnen combineert. Dit biedt niet alleen voordelen op data en analyseniveau, maar was ook een verbetering op het gebied van data-toegang en informatiebeveiliging. De belangrijkste reden

om dit te doen is de noodzaak om door middel van machine learning betere voorspellingen te doen op het gebied van financiën en logistiek. Uiteraard heeft Amazon dit grotendeels met eigen

technologie en oplossingen geïmplementeerd. De CTO van Amazon omschrijft in een blog dat ze dit een aantal maanden en heel veel handwerk heeft gekost. Dit laat zien dat het ontwikkelen van een data lake zelfs voor een partij als Amazon geen vanzelfsprekende klus is.

Bron: Blog van Werner Vogels, de CTO van Amazon5)

de juiste analyses uit te voeren en de resultaten te interpreteren en te presenteren aan de aanvrager.

Het is onrealistisch om te denken dat data engineers en data scientists al deze brede en diepgaande kennis hebben van R&D, productie, marketing etc. Kortom: hoe groter de organisatie, hoe complexer het ontwikkelen van een data lake wordt.

Er zijn verschillende manieren om met dit vraagstuk om te gaan: 1. Deel een centraal data lake op in meerdere domeinen,

zonder sterke afhankelijkheden. Voordeel is dat de infrastructuur wel centraal beheerd kan worden. Dit volgt

de theorie van ‘bounded contexts’6) 2. Deel de teams die de data beheren ook op in

verschillende domeinen. Het is bijvoorbeeld mogelijk om met verschillende teams van data engineers en data scientists te werken die onderdeel zijn van een

bedrijfsonderdeel, of hier heel nauw mee samenwerken, of letterlijk onderdeel van zijn van het bedrijfsonderdeel. Hierdoor zitten ze letterlijk en figuurlijk dichter bij de

juiste kennis. Ook is het zichtbaarder en beter meetbaar

hoe ze waarde toevoegen 3. Zorg voor selfservice-omgevingen, zodat verschillende

domeinen zelf hun analyses kunnen doen. Dit kan alleen als de data van voldoende kwaliteit is en er heldere definities zijn van de data. Ook gaat dit alleen op voor eenvoudige analyses, niet voor verkenningen van data of

bijvoorbeeld machine learning. 4. Werk met verschillende data lakes, eventueel met een

gelijke technologische basis7). Door met gescheiden data lakes te werken wordt data nog strikter gescheiden. Deze ontkoppeling zorgt voor betere aansluiting bij

domeinspecifieke eisen. Ook kunnen performance, onderhoud en planning specifiek voor een domein ingeregeld worden. Belangrijkste nadeel is dat data behoorlijk opgedeeld is. Een mogelijke oplossing hiervoor is een data lake te ontwikkelen voor

domeinoverstijgende analyses.

Voor de start van de implementatie is het van belang om hier met meerdere disciplines over na te denken. Formuleer gezamenlijke uitgangspunten die nu, maar ook in de toekomst gelden. Ook is het aan te raden om in

groeiscenario’s te denken. Start klein en beheersbaar en werk via leren en bijsturen door naar de ideale eindsituatie.

4. Moet het ook snel?

Met de hedendaagse mogelijkheden verwachten consumenten en bedrijven dat zo veel mogelijk realtime

gebeurt. Een fraudecheck bij de aanvraag van een lening? Een aanbeveling voor de volgende serie die u wilt kijken? Tijdens het spreekuur van de dokter een passend medicijn dat zo weinig mogelijk bijwerkingen heeft? Direct inzicht in de productiecapaciteit in een fabriek? U wilt dit het liefst

direct hebben en niet dagen of weken hoeven te wachten. In de wereld van de big data vormt dit een behoorlijke uitdaging. Zoals in de vorige paragrafen is omschreven zijn vaak allerlei bewerkingen nodig op de data voordat deze geanalyseerd of ingezet kan worden. Deze bewerkingen

gebeuren meestal niet realtime, maar in batches. Dit houdt in dat het op geplande momenten en/of in geplande hoeveelheden gebeurt. Dit zorgt voor een beheersbare situatie waarin piekbelastingen vermeden worden. Maar het blokkeert de mogelijkheid om data realtime (direct) of near-

realtime (binnen enkele seconden) in te zetten.

Realtime analytics voor een game met 200 miljoen gebruikers De meestgespeelde game van de afgelopen jaren is Fortnite, ontwikkeld door Epic Games. In deze game

spelen op piekmomenten miljoenen spelers tegelijk. Om de game goed te laten werken is een solide infrastructuur nodig. De game genereert meer dan 125 miljoen events per minuut. Dit komt neer op zo’n 60GB aan data per minuut, oftewel 3 Petabytes data per maand.

Epic games gebruikt event streaming voor alle data die in de game gegenereerd wordt. De verwerking gebeurt in

twee snelheden: een near-realtime stroom voor performance-analyse en scoreborden in de game en een batch-gebaseerde stroom voor uitgebreide analyses van spelgedrag. Beide datastromen gebruiken verschillende Amazon technologieën en zijn compleet gescheiden van elkaar.

Bron: AWS Epic Games case study8)

. 5. Totaaloplossing of zelf ontwikkelen

Een ander vraagstuk is de ‘make or buy’ beslissing. Als u de websites van verschillende leveranciers bekijkt kunt u de indruk krijgen dat zo’n beetje alles mogelijk is tegen relatief lage inspanningen. Helaas blijkt dit in de praktijk niet zo te zijn.

In deze paper zullen we geen uiteenzetting doen over hoe u een goede make or buy keuze kunt maken. Specifiek voor dit onderwerp kunnen we wel enkele tips geven op basis van onze ervaring:

• Kijk realistisch naar de totale organisatie-, implementatie- en beheerskosten voor een data lake. De basis van het data lake kan er zo staan. De (onverwachte) kosten zitten in allerlei bewerkingen van de data, koppelingen met systemen,

datakwaliteitsverbeteringen en maatwerkoplossingen voor eindgebruikers.

• Start met een proof-of-concept, of een proof-of-technology. Liefst met meer dan een leverancier.

Hierdoor kunt u tegen relatief lage kosten leren hoe goed de fit is op het gebied van resultaat, technologie en samenwerking.

• Amazon en Microsoft bieden een schaalbare infrastructuur en services waarmee een data lake

ontwikkeld kan worden. Kijk hierbij goed naar de Total Cost of Ownership (TCO), want door alle losse componenten en services kan deze flink oplopen. De integratiekosten van de losse onderdelen kunnen hoog zijn. Een managed cloud omgeving betekent niet dat

de infrastructuur niet beheerd hoeft te worden, dus kijk ook hier realistisch naar de beheerskosten.

• Er zijn prima open source componenten en technologieën beschikbaar voor data lakes. Kijk hierbij vooral naar de activiteit van de developercommunity en de toegepaste use cases.

• Zoek naar implementatiepartners met 10+ jaar ervaring met databases en datawarehouses, en met een goede mix tussen developers en consultants. Een goed advies of een goed model kan tientallen uren development besparen.

Data lake Datawarehouse Data-as-a-service platform

Primaire doel Toegang tot data afkomstige van verschillende bronnen

Toegang tot gestructureerde data afkomstige van verschillende bronnen

Structuren van toegang tot meerdere soorten databronnen

Geschikt voor Gestructureerde en ongestructureerde repetitieve data

Gestructureerde data

Alle vormen van data

Schema Volgt data-schema Vooraf bepaald Vooraf bepaald

Datakwaliteit Wisselt sterk Hoog Hoog

Geschikt voor primaire/operationele proces en (near-) realtime analytics

Deels Nee Ja

Primaire gebruikers Data scientist, data engineer, analist, business

Analist, business Developer, analist, business

Meest voorkomende analyses Machine learning, voorspellend, verkennend, standaard rapportages, self-service rapportages

Standaardrapportages, self-service rapportages

Standaardrapportages, self-service rapportages

Alternatieven voor een data lake

De ontwikkel- en beheerskosten voor een data lake zijn aanzienlijk. Daarom zal een goede afweging gemaakt

moeten worden of een data lake voldoende waarde toevoegt ten opzichte van bestaande systemen, of in vergelijking met alternatieve oplossingen. Naast data lakes kunnen bijvoorbeeld datawarehouses of dataplatforms ook een prima keuze zijn voor de gevraagde functionaliteit.

Data lakes en datawarehouses zijn als begrippen geïntroduceerd in het eerste deel van de paper.

Een data-as-a-service (DaaS) platform is een moderne vorm van dataopslag in de cloud. Een DaaS-platform is geschikt

voor realtime dataverwerking en wordt vaak ingezet in het primaire proces. Een Daas-platform leent zich ook voor het betere structuren van data en het maken van analyses. Daarom kan een Daas-platform een goed alternatief zijn voor een data lake. Een voorbeeld van een Daas-platform is

InformationGrid, een eigen product van Luminis.

z

Hopelijk heeft de informatie in deze paper u een aantal nieuwe inzichten gegeven. Zoals u heeft kunnen lezen is het ontwikkelen van een data lake in de veel gevallen een niet te

onderschatten klus. Een stuk van het denkwerk kunt u vooraf doen en een deel zult u tijdens de implementatie pas ontdekken. Ook is het goed om te weten dat er alternatieven zijn voor een data lake die misschien beter aansluiten bij uw vraag.

Heeft u vragen, of kunt u advies gebruiken op het gebied van cloud of data? Vanuit Luminis denken we graag met u mee. Wij beschikken over ruim 10 jaar cloud-ervaring en hebben uitgebreide kennis op het gebied van data, data intelligence en search. Wij bieden op dit vlak advies en ondersteuning

voor organisaties zoals Bol.com, Albert Heijn, OHRA en KLM en veel andere organisaties.

Voor meer informatie

https://www.luminis.eu info@luminis.eu

+31 (0)88 58 64 600

Over Luminis

Luminis is een software- en technologiebedrijf met vestigingen in Amsterdam, Apeldoorn, Arnhem, Eindhoven,

Rotterdam en de UK. Vanuit deze vestigingen werken 200 professionals aan technisch hoogwaardige oplossingen voor klanten. Luminis levert diensten op het gebied van cloud-technologie, IT consultancy, dataOps en design. Daarnaast heeft Luminis een eigen data-as-a-service cloudplatform

ontwikkeld: InformationGrid.

Nawoord

Uw vragen of opmerkingen naar aanleiding van deze paper kunt u mailen naar de auteur of naar info@luminis.eu. Op de Luminis website (www.luminis.eu) vindt u ook diverse

andere papers, bijvoorbeeld op het gebied van datastrategie en search.

Over de auteur Martin van Mierloo is product marketing manager bij Luminis Technologies. Martin heeft ruim 20 jaar ervaring

met de ontwikkeling van digitale strategieën voor B2B en B2C organisaties. Contact: martin.vanmierloo@luminis.eu

Bronnen

1. https://www.gartner.com/en/newsroom/press-releases/2014-07-28-gartner-says-beware-of-the-data-lake-fallacy 2. https://martinfowler.com/bliki/DataLake.html 3. W.H. Inmon, D. Linstedt, M. Levins (2019) - Data Architecture: Second Edition - Elsevier Publications 4. http://breakthroughanalysis.com/2008/08/01/unstructured-data-and-the-80-percent-rule/ 5. https://www.allthingsdistributed.com/2020/01/aws-datalake.html

6. https://martinfowler.com/bliki/BoundedContext.html 7. https://martinfowler.com/articles/data-monolith-to-mesh.html 8. https://aws.amazon.com/solutions/case-studies/EPICGames/