Ontsluiten van big data in de cloud
Ontsluiten van big data in de cloud
Tegenwoordig genereren alle software toepassingen en alle apparaten data. Al deze data wordt opgeslagen in de cloud, vaak onder services van Azure of AWS.
Deze enorme hoeveelheid aan data bevat een groot potentieel voor een breed scala aan toepassingen. Dit is het domein van de termen Internet of Things, Kunstmatige intelligentie, en zelflerende applicaties.
Om dit potentieel te benutten is het belangrijk om eerst het onderliggende proces goed te regelen. Helaas ontbreekt dat onderliggende proces vaak in het big data plan. De data wordt opgeslagen en er zijn toekomstdromen over wat er mee mogelijk is, maar in werkelijkheid gebeurt er weinig mee. Dit soort mislukte initiatieven zien we vaak voorkomen bij overheidsorganisaties, waar na een paar jaar investeren in big data uiteindelijk niets aan waarde wordt opgeleverd.
In dit artikel bespreek ik hoe je data op een goede manier ontsluit, welke uitdagingen daarbij komen kijken, en hoe je big data daarna stapsgewijs kunt gebruiken in steeds complexere toepassingen.
Data infrastructuur
Ervan uitgaande dat er al genoeg data beschikbaar is - het hele idee van big data is dat er nooit te veel data is - begint de big data reis bij de data engineering. Hierbij draait het om het op orde krijgen van infrastructuur in data lakes en warehouses. Alhoewel de eisen aan infrastructuur per bedrijf verschillen, zijn er een aantal overeenkomsten: (1) De gewenste data moet gemakkelijk vindbaar zijn, (2) de data moet snel op te halen zijn en (3) de kosten voor opslag en gebruik van de data mogen niet te hoog zijn.
Hiervoor zijn in de industrie twee concepten ontwikkeld, namelijk: (a) data lakes en (b) data warehouses. Deze twee concepten zal ik hieronder bespreken en vergelijken met een derde concept, de minder ideale (c) data silos.
a. Data lakes
Data lakes zijn verzamelplaatsen van ruwe data, waar alle data in een zo plat mogelijke structuur is opgeslagen. Dit betekent grote tabellen met veel kolommen.
Als twee tabellen sterk afhankelijk zijn van elkaar, kunnen ze veelal samengevoegd worden tot een tabel. De data in een data lake kan ingezet worden voor kunstmatige intelligentie toepassingen en worden verwerkt tot dashboards.
b. Data warehouses
Data warehouses zijn in veel opzichten het tegenovergestelde van data lakes. Hier wordt verwerkte data in eenvoudige kleine tabellen aangeboden voor Business intelligence (BI) dashboards en soortgelijke toepassingen. Vanwege deze structuur zijn de analyse-mogelijkheden beperkt.
c. Data silos
Data silo’s zijn net zoals data lakes opslagplaatsen voor grote hoeveelheden ruwe data. Echter, waar data lakes gestructureerd zijn met minimale hiërarchie, bestaan data silo’s juist vaak uit een doolhof van afhankelijkheden tussen data. Hierdoor is het vrijwel onmogelijk om de data te gebruiken voor analyses.
Voor een geslaagd data-project is het cruciaal om de ruwe data op te slaan in een data lake en vanuit daar de verwerkte data in een een data warehouse. Deze opslag vindt meestal plaats bij cloud storage providers, zoals Microsoft, Google en Amazon. Cloud storage garandeert dat de data altijd bereikbaar en online is. Alleen in het geval van gevoelige data, bijvoorbeeld medische of financiële data, is het nog gebruikelijk om de dataopslag zelf te hosten. In alle andere gevallen wegen de extra kosten en risico’s van eigen hosting niet op tegen cloud provisioned hosting.
Complicaties bij de overstap naar big data
Met het Nederlands Instituut voor de Software Industrie (NISI) hebben wij voor meerdere bedrijven het proces van Big Data ontsluiten gefaciliteerd. NISI is een aan de Universiteit Utrecht gelieerd instituut, waar wij kennis uit de academische wereld gebruiken om bedrijven verder te helpen in hun software en big data projecten. Hierbij zijn we een aantal veelvoorkomende complicaties tegengekomen, namelijk, (1) de overstap naar data lakes, (2) wat te doen met legacy data, (3) het gebruik van third party toepassingen. Deze zal ik hieronder verklaren, en oplossingen voor aandragen.
Overstap naar data lakes
Data is vaak nog opgeslagen in de eerder besproken data silo’s. Dit feit, gecombineerd met een redelijke hoeveelheid legacy infrastructuur, maakt dat niemand meer precies weet wat waar en hoe is opgeslagen. Het web van data ontwarren en opslaan in een data lake levert pas op de lange termijn waarde. Hierdoor is het vaak een ondergeschoven kindje, waardoor het met de tijd alleen maar ingewikkelder wordt om waarde te creëren met de data. Deze vicieuze cirkel moet eerst doorbroken worden, wil het bedrijf de data nuttig toepassen.
In deze gevallen helpt het om de data in stappen te converteren van data silo naar data lake. De stappen van zo’n proces bestaan uit:
Er wordt besloten tot een analyse richting op een deel van de data (bijvoorbeeld op een bepaalde categorie van een online winkel)
Alle relevante data voor de gekozen analyse richting wordt uitgezocht en overgebracht naar een data lake.
De analyse wordt uitgevoerd.
waarna een nieuwe analyse richting gekozen kan worden.
Op deze manier wordt er sneller waarde geleverd met de ontsloten data. Het nadeel is dat twee verschillende systemen naast elkaar bestaan. Dit brengt extra kosten met zich mee in het online houden en onderhouden van de systemen. Ook is de kans op inconsistenties tussen de twee systemen groot. Het is daarom belangrijk om te zorgen dat men uiteindelijk wel overstapt op het data lake.
Legacy data
Meetmethodes veranderen over de jaren, en systemen worden vaak uitgebreid. De consistentie van data is vaak niet meer te garanderen. Dit is de data equivalent van legacy software.
Bij het NISI ervaren we problemen met inconsistente data in het bijzonder in de zorg. In de zorg noteert het personeel veel van de data handmatig, waardoor de data al snel subjectief is. Daarnaast wisselt het beleid in de zorg (maar ook in andere sectoren die met overheidsbeleid te maken hebben) vaak. Jaarlijks worden er bepaalde zorgindicaties toegevoegd en afgeschaft. Als het systeem jaarlijks verandert is het vrijwel onmogelijk om de data consistent te houden.
In het geval van legacy data moeten er harde en moeilijke beslissingen genomen worden. Een deel van de data is te redden door oude data conform nieuwe richtlijnen op te slaan. Het deel van de data waarvan een transformatie conform nieuwe richtlijnen te veel tijd kost, moet vervolgens weggelaten worden uit verdere analyses. Data verwijderen is in tegenstrijd met het concept big data, en is daarom ook vaak een moeilijke beslissing om te nemen. Toch is het een juiste keuze, omdat op je deze manier sneller resultaat realiseert.
Third party applications
Als laatste wil ik nog het risico van third party applications benadrukken. Het is verleidelijk om via third party applicaties data te verzamelen, bijvoorbeeld via Google analytics. Third party plugins bieden op een makkelijke manier informatie. Het nadeel van deze plugins is dat data vervolgens versnipperd raakt over meerdere applicaties, en niet meer samen te voegen is tot een geheel. Kort gezegd: dit soort toepassingen bieden wel een data warehouse, maar niet een data lake. Terwijl een data lake cruciaal is om met de data voorspellingen te kunnen doen en toepassingen met kunstmatige intelligentie te implementeren. Het is daarom vrijwel altijd wenselijk om zoveel mogelijk data zelf te vergaren en op te slaan.
Efficiëntie
Aan het gebruik van de cloud zitten vanzelfsprekend kosten verbonden. Vaak gaat dit om pay-per-use kosten. Zo efficiënt mogelijk gebruik van de databases houdt de kosten laag. Hierboven hebben we al een aantal manieren besproken om de data goed in te richten. Veel van deze methoden brengen ook een kostenbesparing met zich mee. Een database met minimale hiërarchie betekent ook dat er minder requests uitgevoerd hoeven te worden, aangezien minder tabellen benaderd hoeven worden. Minder requests leiden vervolgens tot minder kosten.
Met het weggooien van legacy data, worden of kosten bespaard door minder opslag. En als laatste leidt minder gebruik van third party applications vanzelfsprekend tot minder kosten van die applications.
Vervolgstappen
Na het voorbereiden van big data in data lakes, komen de toepassingen in beeld. Een eerste stap is dan om in een sessie met relevante stakeholders en management vast te stellen op welke manier de data gebruikt en geanalyseerd moet worden.
Nu de analyses op de data gedaan worden, voegt big data pas waarde toe aan het bedrijf. Het is vrijwel onmogelijk om zonder voorbereidend werk al waardevolle big data toepassingen te leveren. Daarom is het ook belangrijk om big data te zien als een langetermijn-investering.
De analyse op de data ontwikkelt zich vervolgens in een aantal stappen. Eerst vindt een data verkenning plaats, waar de mogelijkheden van de data vastgesteld worden. Vervolgens vindt een beschrijvende analyse plaats, waarin de huidige en historische situatie in kaart gebracht wordt. Als laatste worden er voorspellende modellen gemaakt met de data. Het proces van data lake naar voorspellend model en AI toepassing is minstens zo interessant als het proces van data engineering beschreven in dit artikel, en verdient beschreven te worden in een volgend artikel.