De afgelopen jaren sprak menigeen over “Big Data”. Maar wat er nu precies mee bedoeld werd, bleef een beetje duister. Het ging over “veel data”, maar waarom je nu voor “veel data”  een aparte oplossing nodig had, was onduidelijk. Per slot van rekening zijn er allerlei standaard oplossingen voor “veel data”. Onze databases kunnen veel data aan, de file servers kunnen veel data bevatten; kortom: waarom is “Big Data”  iets aparts, dat met standaard tooling niet te behappen is.
Het afgelopen jaar is duidelijk geworden waarom “Big Data” echt iets anders is. Big Data gaat over zoveel data, dat we niet meer genoeg hebben aan  één server om die data op te plaatsen. We hebben in het geval van “Big Data”  een serie van tientallen of zelfs honderden servers nodig om die Data op te zetten omdat het volume echt “Big” is. We praten dan over honderden TeraBytes aan data.

Het is ook duidelijk geworden dat we ook nieuwe technieken nodig hebben om die honderden servers aan te sturen. We moeten bijvoorbeeld data meerdere keren opslaan , omdat we bij honderden servers serieus rekening moeten houden met de uitval van een server. We moeten ook denken dat parallel verwerken van die data omdat we de rekenkracht van alle servers nodig hebben om een query actie te ondernemen.
We komen op die manier ineens voor andere problemen te staan. Laat ik eens als voorbeeld de uitval van een server nemen. In de “oude” wereld met een enkele server hielden we natuurlijk ook al rekening met de uitval van een server. Keurig hadden we voor die eventualiteit een back-up mechanisme ingericht. Als die server eens uitviel – dat gebeurde toch wel eens in de drie jaar, dan schakelde de beheerder een extra server in en werd de database uit de backup gerestored. So far so good: eens in de drie jaar hadden we een vervelend dagje omdat de database moest worden teruggezet.
Maar nu komen we in de nieuwe wereld, waar we zoveel data hebben, dat we 1000 servers nodig hebben. Dat betekent dat we iedere dag wel geconfronteerd worden met een servertje dat uitvalt. Oops. Als we dan zouden terugvallen op een backup / restore, zouden we een dijk van een probleem hebben. Iedere dag een restore doen, betekent iedere dag uitval en dat betekent dat je weinig gedaan krijgt. Kortom: andere technieken zijn nodig. Een element is de data meerdere keren opslaan, zodat de uitval van een server kan worden opgevangen door de data van een andere machine te halen. Een ander element van de oplossing is dat we heel snel een nieuwe server kunnen bijschakelen.
In de nieuwe wereld met Big Data hebben we de data verspreid over honderden servers. Om daar zinvolle analyse op te doen, kunnen we iedere server de eigen data laten analyseren. Op het einde van de analyse sturen de servers hun deel van de uitkomsten naar een centrale plaats, waar de deeluitkomsten tot een algemene uitkomst. Bij Big Data speelt het verdelen van de taken over de afzonderlijke servers en het samenvoegen van deeluitkomsten een grote rol. In termen van Big Data is dat de kern van MapReduce. Als je een Big Data opdracht op het scherm ziet rollen, zie je dat MapReduce eerst de taken verdeelt, daarna zie je dat de afzonderlijke server hun deeltaak oppakken en tot slot zie je dat MapReduce de deelkomsten ophaalt en ze samenknoopt tot een enkele uitkomst. De snelheidswinst wordt dan gehaald doordat veel servers parallel aan het werk worden gezet. Aan de andere kant is iedere opdracht minimaal een paar minuten bezig omdat MapReduce de taken moet verdelen en op het eind de deeluitkomsten moet ophalen. Dat kost altijd een paar minuten.
Maar die nieuwe technieken willen we graag inpassen in onze bekende manieren van werken. In traditionele databases werken we graag met SQL. Het is ook niet meer dan logisch dat we “Big Data”  graag met SQL willen benaderen. Op dit moment zijn er dan ook allerlei initiatieven om “Big Data” met behulp van SQL te benaderen.
In het komende jaar gaan we die nieuwe technieken gebruiken om in diverse organisaties echt met “Big Data”  aan de slag te gaan. We hebben het dan over de analyse van gegevens die we tot voor kort nog niet in de analyse betrokken. Ik geef een paar voorbeelden: analyse van sensordata, analyse van RFID gegevens, analyse van CDRs – kortom allerlei soorten van data die tot voor kort nog niet geanalyseerd konden worden vanwege de omvang.