De leercurve van Big Data: Vier vragen aan Big Data infrastructuur manager Vincent Verheul

Vincent Verheul heeft meer dan twintig jaar (internationale) ervaring als adviseur op het gebied van informatie technologie en procesoptimalisatie, met name in de supply chain. Momenteel werkt hij als infrastructuur manager aan een Big Data project.

Hoi Vincent, je hebt enorm veel business, proces, organisatie en ICT kennis. Nu ben je voor dit project gerold in de wereld van Big Data. Hoe is dat? Is het één grote ontdekkingstocht?

Ja dat kun je wel zeggen. Het project management is wel een belangrijke taak en dat is natuurlijk bekend terrein. Maar Big Data is nieuw voor me. Het gaat in dit project om een migratie van eigen hardware (cluster van 60 servers) naar de cloud, van Amazon. De cloud blijkt toch behoorlijk verschillend van eigen hardware. Het ene cluster en de software om het te besturen is het andere niet. Er is een flinke leercurve. Ook de kostenbeheersing vraagt veel aandacht. Je moet daar goed op letten, anders wordt het snel een stuk duurder dan je gewend was met eigen hardware.

Je houdt je veel bezig met stabiliteit en kostenreductie. Hoe kun je dit proces het beste begeleiden?

De stabiliteit, dat wil zeggen een betrouwbare infrastructuur, is iets waar je als gebruiker van uitgaat, het zou geen onzekere factor moeten zijn. Dat is in dit geval toch een zorg. De oorzaak is dat bestaande programmatuur met een aanpak die geschikt is voor de situatie met eigen (vaste) hardware ineens niet meer klopt met de nieuwe situatie in de cloud.

Om een voorbeeld te geven: In de oude situatie werd de gegevensopslag (van ongeveer een halve peta-byte) op het cluster zelf gedaan: op het Hadoop File System (HDFS). Dan staat alles op (snelle) hard disk. Voor de programma’s op het cluster staan de bestanden dan lokaal en kunnen snel benaderd worden. In de cloud kan dat ook, maar dan wordt het erg duur. Daarnaast wordt in de cloud geen garantie gegeven dat een afzonderlijke server (van een cluster) altijd zal blijven draaien. Ook wordt er geen garantie gegeven voor het gehele cluster. Daarom bestaat in de cloud een aparte omgeving voor gegevensopslag die wel gegarandeerd is, maar die een stuk trager is dan lokale bestanden. De werkwijze moet daarom zo worden aangepast, dat daar rekening mee wordt gehouden. Dat valt niet mee als je vele honderden grote- en kleine programma’s uit het verleden hebt.

De kostenreductie heeft alles te maken met het verschil in aanpak tussen eigen hardware en de cloud. Bij eigen hardware koop je altijd een (veel) te ruime jas, zodat je niet te gauw tegen capaciteitsbeperkingen aanloopt. In zo’n situatie kijk je natuurlijk of (de zwaarste) jobs efficiënt lopen, maar het is niet echt een focus. Als je in de cloud zit, dan ben je flexibel om hardware op te schalen en weer af te schalen. Je betaalt voor de servers die je hebt draaien. In de cloud heb je een flexibele capaciteit, maar het is relatief duur.

Om de kosten te beheersen is het erg belangrijk om de ingezette capaciteit aan te passen aan de behoefte. Je kunt zeggen dat je vraag en aanbod goed op elkaar moet afstemmen. Nu had Amazon geen automatische op- en afschaal methodiek beschikbaar toen het project begon, dus hebben we intussen zelf al diverse metrics en logica gebouwd. Vanaf 20 november heeft Amazon een nieuwe service beschikbaar gesteld die dit kan doen. Het is natuurlijk handiger om deze standaard tools te gebruiken.

Wat zijn jouw grootste uitdagingen als manager infra?

Ik heb gemerkt dat het werken met clusters in de cloud nog steeds een grote dosis technische kennis vereist. Die kennis is dun gezaaid en dat maakt het lastig. In het team heb je te maken met een flinke leercurve. Het behouden van deze kennis is een uitdaging, omdat er voor deze mensen overall nieuwe spannende projecten zijn. De afdelingen in de organisatie die gebruik maken van de rekencapaciteit zijn veelal data analisten. De managers van deze afdelingen houden zich vanzelfsprekend niet bezig met de techniek van de infrastructuur, ze gaan ervan uit dat het er is. Dat is een terecht uitgangspunt, maar het is voor hen niet altijd  inzichtelijk dat het toch wel specifieke kennis vereist om die service te kunnen leveren. Zo ontstaan er behoorlijke spanningen wanneer de infrastructuur niet altijd even betrouwbaar is. Daar heb ik af en toe mijn handen vol aan.

Om een vergelijk te kunnen maken zijn we ook gaan praten met Google. Zij bieden naast het kunnen draaien van clusters ook een ‘gemanagede’ service aan. Daarbij kunnen hele grote bestanden geanalyseerd worden zonder dat je zelf hoeft na te denken over de onderliggende infrastructuur. Dat regelt Google dan voor je. Dat zou voor de relatief eenvoudige analyses (waar geen ingewikkelde algoritmes voor nodig zijn) misschien een interessante optie kunnen zijn. Maar daarmee heb je nog niet alle soorten gebruik kunnen afdekken.

Hoe begin je het beste met Big Data?

Als je nog geen big data activiteiten hebt, dan heb je het voordeel dat je gericht kunt kiezen voor een big data platform met de daarbij horende tools die zich snel ontwikkelen. Je hebt de keuze tussen een cloud oplossing of eigen hardware met daarop big data software. Voor beide opties zijn diverse aanbieders.

Je kunt dan zo dicht mogelijk bij de ‘standaard werkwijze’ en ‘standaard tools’ blijven van dat platform. Daarmee moet je het nodige aan kennis opdoen, maar je blijft dan mooi werken ‘zoals het bedoeld was’. En zoals altijd met ICT projecten: als het nieuw is dan zul je een leercurve door moeten, dus probeer het eerst uit met een deel van de databronnen, niet alles tegelijk. “Take small steps to Big Data…”