Whitepaper
Big Data zonder een (te) Groot Datacenter
Big Data zonder een (te) Groot Datacenter Eén van de dominante trends de laatste jaren is Big Data: het vergaren, opslaan en analyseren van grote hoeveelheden, meer en minder gestructureerde, data op nieuwe dwarsverbanden. Natuurlijk is de trend deels oude wijn in nieuwe zakken, net zoals clouds veel al bekende elementen samenvoegen – maar toch betekent het gewoon nieuw te zetten stappen. Met welke bouwstenen moet je rekening houden? En met welke gevolgen voor je personeel en IT-platforms? Big Data bouwstenen ‘Big Data’ is zelf een verzamelnaam van werkgebieden. Het analyseren van de gegevensverzameling bijvoorbeeld wordt ook wel aangeduid als ‘Big Analytics’, omdat het ook de klassieke wél gestructureerde data (uit het datawarehouse) meeneemt naast de modernere ongestructureerde data. Waarbij je hier ‘klassiek’ zeker niet moet verwarren met ‘ouderwets’ of ‘legacy’: beide werelden hebben een bestaansrecht naast elkaar, en voor (dwars-) verbanden die de traditionele MI/ datawarehouse benadering al kan opleveren is het duur en onzinnig om dit naar de Big Data-hoek toe te trekken. Wat overigens niet wil zeggen dat altijd traditionele Management Information (MI)-tools met normale databases zoals SAS of MicroStrategy of Teradata zaligmakend zijn voor hun thuishonk; als je vanuit de Big Analytics-hoek serieus nadenkt over in-memory databases zoals SAP HANA of Oracle Coherence/ Exadata dan kunnen die ook sommige MI-taken overnemen van de klassieke tools. Het is handig om je eerst alle nieuwe functionele bouwstenen voor Big Data te geven, want pas met die basis kun je de vertaling maken naar nieuwe eisen voor het datacenter. En natuurlijk volgen die bouwstenen het paradigma van vergaren-opslaan-analyseren oftewel capture-store-analyse. Met ook geregeld een extra ‘analyse’ en datareductiestap vóór het opslaan, omdat anders het datavolume onbeheersbaar zou worden. Zie bijgaand voorbeeldproces:
Stap voor stap deze bouwstenen: 1. Er is meer datacollectie nodig. Deels vanuit je eigen applicatielandschap, denk maar aan clickstream-analyse voor je website en Facebook-conversaties op je company-page; of video-opnamen van beveiligingscamera’s in je verkooppunten. En deels via B2B (Business to Business) import van zakenrelaties, denk maar aan details over alle creditcard-aankopen in jouw winkels gecombineerd met het overige koopgedrag van diezelfde creditcard. En zowel voor commercieele metingen als voor eventueel fraudedetectie kunnen ook andere gegevens over de consument verzameld worden, denk maar aan de lokaties waar gebeld of gepind of geFoursquared wordt – steeds binnen de grenzen van de privacywetgeving natuurlijk. 2. Eventueel dan nog alvorens langdurig opgeslagen wordt een eerste data-analyse om gegevens te verrijken maar vooral om het volume enigszins te reduceren. 3. Opslag van de data in gewone genormaliseerde SQL databases zal vaak niet volstaan, hoewel SQL wel degelijk een rol speelt voor een deel van de opslag. De optimale databases zijn zowel te vinden in de hoek van de
‘vormloze’ ontwerpen zoals Hadoop en NoSql (beiden open source) als in de hoek van in-memory ontwerpen zoals SAP HANA. 4. Binnen de opslag komt veel sterker dan bij klassieke databases een ‘hierarchical classification’ in beeld. Sommige data moeten 2 jaar bewaard worden, andere 5 jaar, nog andere weer 10 jaar. En naargelang er langer bewaard wordt kan soms ook tragere toegang acceptabel zijn, en daarmee goedkopere opslagmedia – bijvoorbeeld niet redundant uitgevoerd, in de cloud, etc. etc. Je hebt in feite het aloude HSM (Hierarchical Storage Management) terug maar nu in een nieuwe jas; bijvoorbeeld zonder de taperobots van weleer, die laagste-trap-qua-SLA is nu min of meer vervangen door goedkope cloud-opslag. 5. Juist omdat relaties tussen data-elementen ‘gezocht’ moeten worden met allerlei Big Analytics-tools is de rekenkracht voor queries en rapportages veel onvoorspelbaarder dan bij klassieke MI. Het is dan ook veel meer CPU-intensief ‘numbercrunching’ dan het disk-intensieve werk dat een klassieke SQL query plus rapportage met zich meebrengt. Je raadt het al, die rekenkracht is een goede kandidaat om optioneel ook van de cloud te betrekken. 6. En tot slot heb je zowel voor de nieuwe soorten datacollectie als voor de analyse nieuwe sets tools en bijbehorende skills nodig. Dat zijn primair zaken aan de applicatieve kant, en hebben dus minder gevolgen voor het datacenter en de platforms dan bouwstenen 2-3-4. Voor die laatste drie krijg je nu wat meer details, gesplitst over de database/opslagkant en de analysekant. Platformgevolgen voor data-opslag Bouwstenen 3 en 4, nieuwe databases en nieuwe HSM-dimensies, leiden allebei tot bijzondere opslag-eisen. En daarbij kijk je per organisatie/casus naar wat er nu precies geëist wordt onder de algemene kreet ‘extreme schaalbaarheid’. Er zijn namelijk ‘the three vees’ in beeld en elk bepaalt de schaalbaarheid in wat andere vorm: Volume, Variety en Velocity. Die hebben grofweg de volgende impact op het opschalen:
• Hoog volume betekent simpelweg meer Petabytes disks te kopen of huren, punt uit. Maar
ook hier moet de
klant uitgedaagd worden met detailvragen of alle data de hele bewaarperiode relevant is, of dat er misschien al een bepaalde set statistieken uit ge-extraheerd kan worden die de basisdata vervangt en veel compacter is. De ‘Map/reduce’ aanpak bijvoorbeeld, die tijdens de analyse van pas komt om werk te paralleliseren, kan ook gebruikt worden voor datafiltering om het bewaarvolume te beperken.
• Een grote variatie aan data-inhoud betekent minder mogelijkheid tot deduplicatie en compressie. Ook hier kan redelijk voorspeld worden wat de variatie is door een paar testmetingen; denk aan bewakingsvideobeelden, die bevatten 90% dezelfde (winkel-) achtergrond en slechts 10% variatie namelijk de bewegende personen. Variatie heeft ook impact op de te kiezen opslagmethode: in-memory databases zoals HANA kunnen iets beter met gestruktureerde (dus voorspelbaar-variabele) data omgaan en de Hadoop-achtigen beter met echt on gestruktureerde data.
• Velocity betreft veelal de groeisnelheid, dus het expansietempo. Een hoge velocity in deze zin is ook wel van belang voor de gekozen opslagcapaciteit, maar is het belangrijkst in de gemaakte keuzen qua netwerktoegang. Als bijvoorbeeld een NAS-array op zichzelf prima 20 Gb/dag groei aankan door opslag van videobestanden maar hij aan een edge netwerksegment vastzit waar elk volume boven de 5 Gb/dag het desktop-dataverkeer zou gaan
beïnvloeden of zelfs wegdrukken dan is er toch iets mis met het ontwerp. Veelal gerelateerd aan de Velocity is een hoog aantal IOPS (Input/Output Operations) per seconde of bandbreedte (GB/s). En dat heeft ook gevolgen voor aantal en de responstijd en doorvoersnelheid van de gekozen schijven; die moet minimaal de normale raadpleegsnelheid voor video’s kunnen bijhouden gegeven het te verwachten aantal parallelle raadplegingen. Een laatste dimensie van velocity is een andere soms gebruikte inhoud: het tijdsinterval tussen datacollectie en conclusies (analyse). Is dat erg kort dan is een in-memory database zoals HANA wederom geschikter dan een batchmodel zoals Hadoop. Dan wat meer over de struktuur van de data. Waar je bij SQL databases vaak disk volumes kunt laten optimaliseren voor pakweg een Oracle ‘logical partition’ of een SQL Server data tuple, daar zul je in de vormloze en in-memory systemen in principe moeten terugvallen op de klassieke file shares. Oftewel een file systeem zoals NFS of SMB, waar alle kennis over de samenhang van de diverse bestanden alleen in de database-software ligt. Dat is niet pers é erg, want classificatie van de data kan nu ook per bestand plaatsvinden en buiten de database-software zelf; terwijl je voor een SQL database hiervoor pers é ook ‘in’ de databasestruktuur die toolset moet gaan bijpluggen/ontwikkelen. Wil je Big Content (een andere term voor opgeslagen Big Data) goed kunnen hanteren dan gelden de volgende eisen voor de opslagsystemen:
• Dataclassificatie naar bewaartermijn en SLA moet kunnen worden vertaald naar fysieke opslag. En de tooling moet bijvoorbeeld een bepaald logisch volume na 2 jaar vanzelf kunnen migreren naar een goedkoper medium, zonder dat de analysesoftware erop moet worden aangepast.
• De opslag moet ook in andere zin transparant zijn voor de applicaties. Dus als pakweg elk disksysteem ‘slechts’ 5 Petabytes groot is dan moet via truuks als mounting het volgend disksysteem in dezelfde directory zichtbaar gemaakt worden als de nu volle disk.
• Er moet een soort ‘ content repository’ bijgehouden kunnen worden waar van elk diskvolume bekend is waar de data vandaan komen, wat hun SLA is en welke toegangseisen gesteld worden. Niet alleen voor hoofd-datacenters maar ook als de data gedistribueerd worden naar tientallen of meer lokaties, zoals voor cloud-opslag. Zo’n repository is een specifieke tak van sport die gerelateerd is aan de opgeslagen data, dus levering van het repository-tool zelf is veelal voorbehouden aan de vendor van de databases voor de Big Data zelf. Er is echter wél koppeling nodig met de HSM-achtige policies op disk-niveau, want die moeten op basis van de repository beslissingen kunnen doorkrijgen dat bepaalde volumes nu een lagere SLA krijgen of zelfs gedecommissioned mogen worden.
Voorbeeldinvulling: NetApp Om een concreet idee te krijgen wat deze eisen betekenen voor opslaghardware krijg je nu voorbeelden-uit-hetveld van een groot leverancier in dezen, NetApp. Men zet voor elk van de drie doelen een produkt/module in het veld. Voor de dataclassificatie is dat hun Data ONTAP ‘ Storage Operating System’. Dit bedient zowel alle nieuwe en bestaande NetApp SAN en NAS apparaten als een behoorlijk aantal devices van andere merken, mits die maar de open opslagstandaarden volgen. En het belangrijkste concept hier zijn de Storage VM’s: een groep opslagcapaciteit met een bepaalde SLA. Dus een logisch volume zit in Data ONTAP pakweg voor de eerste twee jaar vast aan SLA-
goud en zal daarna SLA-brons krijgen. Data ONTAP zelf zal de data na deze overgang verplaatsen naar pakweg een cloudprovider zonder dat de mapping voor de analyse-software hierdoor veranderd wordt, door de logische abstractie-laag welke de SVM vormt. Voor het volgende van de drie gegeven doelen, transparantie, is er een andere Data ONTAP feature: het ‘Infinite Volume’. Het breidt de mount-functie van Linux/Windows zodanig uit dat alle data in een enkel ‘meta-volume’ zichtbaar zijn, zodat de software geen last krijgt van overgangen naar verschillende fysieke opslagmedia. Ook Infinite Volume heeft nog steeds kennis van de onderliggende hardware, en kan andere Data ONTAP-features zoals deduplicatie, compressie en redundante opslag (de laatste bij een hoge SLA) inschakelen en herkennen. En voor de content repository biedt NetApp, speciaal voor sterk gedistribueerde data, een specifieke oplossing. Deze heet StorageGrid, en is in zijn volle functionaliteit bedoeld voor herkenbare ‘ files’ die aan bepaalde kern-artefacten van een organisatie kunnen worden toegeschreven; denk aan klantnummer of gebouwnummer. Als je pakweg Hadoop of NoSql databases hebt met gegevens over vele artefacten tesamen dan kan StorageGrid nog steeds helpen om te registreren wat er precies waar staat en met welke SLA; hij kan dan echter zelf niet goed worden ingezet voor ‘intelligent data classification’, daarvoor zou je dan weer een tweede content repository-tool moeten hebben dat in de Hadoop etc. database kijkt. En net als Data ONTAP kan Storage Grid SLA’s bewaken, dus data verplaatsen naar andere lokaties als dat vanwege bewaartermijn en karakter van de data gewenst is. Platformgevolgen voor numbercrunching De andere grote platformdimensie van Big Data is het rekenwerk; zoals gezegd is Big Analytics primair bedoeld voor de losser gestruktureerde opgeslagen Big Content maar kun je bepaalde SQL data wel ‘meenemen’; ofwel omdat ze essentieel zijn voor de analyse ofwel omdat je nu eenmaal een in-memory database engine hebt neergezet waarop klassieke SQL data ook soms kunnen meeliften. Rekentools kunnen ‘ klassiek’ zijn, simpelweg geprogrammeerd bovenop Windows- of Unix/Linux API’s. Daar is op zichzelf niets mis mee maar ze laten zich niet altijd even makkelijk horizontaal opschalen oftewel clusteren over meerdere processoren en zelfs cores. En als je cloud-rekenkracht zou willen gebruiken, wat op zichzelf goed past bij Big Analytics omdat het veel onvoorspelbaarder is dan klassieke MI, heb je een aardige uitdaging. Je bent namelijk ‘veroordeeld’ om IaaS (Infrastructure as a Service) kracht te gaan gebruiken, dus extra VM’s (Windows of Linux) die je van een provider zoals Amazon EC2, Microsoft Azure VM-role of een VMware vCloud-provider huurt. Het hele synchroniseren van deze VM’s en clusteren samen met je in-house CPU’s is dan allemaal aan jou en je team toegewezen. Sterke voorkeur voor Big Analytics-tools is daarom PaaS oftewel Platform as a Service. Dit betekent een middlewarestack waarbovenop de analysetools draaien die zeer gericht is op schaalbaarheid en lokatieonafhankelijkheid; de middleware draait in principe in de publieke cloud maar er zijn veelal ook private inhouse opties leverbaar. (Aangezien dit rekenwerk geen data-opslag kent kan alleen latency en communicatie-
afluistergevaar een reden zijn om persé in-house te willen gaan.) Grote namen hier zijn Google AppEngine, de basisversie van Azure (dus niet Azure VM-role) en Amazon Elastic Beantalk. Maar alle namen zijn slechts enablers – jij als IT platformspecialist zou nog altijd moeten helpen om goede analysetools te selecteren die bovenop zo’n PaaS enabler draaien, en de afweging tussen in-house en cloud helpen maken. Je werk hier is echter, ondanks de complexe meerlaags opzet, toch een stuk makkelijker dan bij een IaaS cloud. Big Data en je Datacenter De nieuwe ‘ Big’ trend is op bijna alle fronten revolutionair vergeleken met de traditionele MI/datawarehousebenadering; en het tragische vanuit kostenoogpunt gezien is dat je veelal voor een én- én benadering moet kiezen, de twee stijlen van analytische informatie zijn behoorlijk complementair. De nadruk in dit paper ligt niet zozeer op de nieuwe vergaar- en analysetooling maar op de gevolgen van Big Data voor je datacenter: dus de extra soorten capaciteit die nodig worden. Qua rekenkracht zijn de gevolgen niet onaanzienlijk. Door de enorme piekbelasting van Big Analytics is het veelal niet kostenefficiënt om de vereiste serverkracht hiervoor in-house aan te houden; cloud-kracht ligt voor de hand. En deze legt strenge eisen op aan de te kiezen analysetools: als die standaard Windows/Linux etc. gebruiken kun je alleen de hier suboptimale IaaS-clouds inzetten. Echt vliegen gaat de cloud-uitbreiding pas bij Platform as a Serviceclouds en die eisen speciaal aangepaste Big Analytics-tools. Qua opslag zijn de gevolgen ook groot, maar interessant genoeg vormen ze vooral een moderne opvolging van het aloude Hierarchical Storage Management. Door de forse datagroei is er een softwarelaag nodig die netjes opslag koppelt aan de juiste SLA en alle big data-bergen goed weet bij te houden én terug te vinden ook na heel wat jaren. Opslagvendoren zoals NetApp hebben dat goed begrepen, en de hier als voorbeeld gebruikte bouwstenen Data ONTAP en StorageGrid passen uitstekend in het wensenplaatje om al deze nieuwe ‘content’ te organiseren en kosteneffectief op te slaan en te raadplegen. Waarmee het Datacenter (plus eventuele cloud-opslag) wel groot kan worden maar op geen enkel moment té groot!
