de vijf aandachtspunten bij de ontwikkeling van een data lake · opslagmethodes zoals bigtable en...
TRANSCRIPT
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 [email protected]
+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 [email protected]. 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: [email protected]
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/