Innovatie & Strategie

Analytics
big data kruiwagens

Big Data-analytics: groter, sneller, slimmer?

Wat bepaalt het succes van Big Data analytics?

© CC0,  Pixabay
24 oktober 2016

Wat bepaalt het succes van Big Data analytics?

Datavolumes die worden opgeslagen en geanalyseerd om beslissingsprocessen te ondersteunen, nemen spectaculair toe. Toch zijn kansen én valkuilen van Big Data-analytics niet louter een gevolg van die volumes. Minstens zo relevant zijn opslag en het koppelen van uiteenlopende datatypes, het bewaken van datakwaliteit, organisatorische aspecten en het creëren van business value. Een overzicht van aandachtspunten die bepalend zijn voor het succes van Big Data-analytics.

Dankzij de sterk gedaalde prijs van ruwe opslagcapaciteit, steeds toenemende processing power én nieuw ontwikkelde analytics-technieken kunnen nu gegevensvolumes worden opgeslagen en geanalyseerd die voorheen ondenkbaar waren.

Daarnaast wordt data steeds meer heterogeen. Traditionele, gestructureerde gegevens blijven van cruciaal belang: klantendata, productgegevens, ordergegevens… Nieuwe inzichten ontstaan vooral door deze te kruisen met andere gegevenstypes: clickstreams van klanten om hun gedrag te analyseren, logfiles van serverapplicaties die de (in-)efficiëntie van het orderverwerkingsproces aantonen, socialmediafeeds om het sentiment van potentiële klanten tegenover nieuwe producten in te schatten, tot sensor- en RFID-data om allerhande fysieke gebeurtenissen vast te leggen. Vaak gaat het om (deels) ongestructureerde data, of om gegevens met een volatiele structuur.

 AG tekstballon-1

Opslagomgevingen

Zowel het volume van data als de grilligheid van hun structuur, maakt dat traditionele relationele databases niet langer de (enige) omgeving zijn om dergelijke data op te slaan. Relationele databases zijn immers op hun best als ze gegevens met een welomschreven structuur beheren, waarbij ze consistentie en gegevensintegriteit bewaken aan de hand van een vast schema. Tevens zetten ze sterk in op transactie-consistentie (zogenaamde ACID-transacties). Als (ook) gegevens met een variabele structuur worden opgeslagen, wordt dat rigide databaseschema een ongewenst keurslijf. Daarnaast lopen relationele databases tegen de grenzen van de schaalbaarheid aan. Vanaf bepaalde volumes volstaat immers niet het verticaal schalen – waarbij de capaciteit van ‘de’ server wordt uitgebreid – maar is er nood aan horizontaal schalen. Opslag- en verwerkingscapaciteit worden dan in een cluster geplaatst om zo een grote logische capaciteit te realiseren via meerdere fysieke knooppunten. Gegevens worden verdeeld én gedupliceerd via deze knooppunten, zowel omwille van prestatie (parallelle verwerking) als beschikbaarheid (redundante gegevensopslag). De nadruk van relationele databasesystemen op gegevensconsistentie vormt dan echter een knelpunt: het afdwingen van ACID-transacties over meerdere knooppunten in een cluster, met ook nog eens verschillende kopieën van dezelfde data, vraagt zoveel bijkomende coördinatie-overhead, dat de potentiële prestatiewinst door horizontaal schalen sterk wordt afgeroomd.

Het volume van data maakt dat traditionele relationele databases niet langer de enige omgeving zijn om data op te slaan

Een nieuwe generatie databasesystemen maakt daarom opgang: NoSQL-databases. Deze vlag dekt uiteenlopende ladingen, wat het vrijwel onmogelijk maakt om hen eenduidig te typeren. Je kan een aantal klassen onderscheiden, zoals key-value stores, document stores, column-oriented databases, en graph databases, maar zelfs binnen eenzelfde klasse vind je zeer uiteenlopende systemen. Het gemeenschappelijke kenmerk is echter dat ze zich afzetten tegen de beperkingen van relationele databases. Vaak hechten ze minder belang aan gegevensconsistentie en aan schema-constraints. Door sommige beperkingen los te laten, zijn ze quasi lineair horizontaal schaalbaar en kunnen ze veel performanter omgaan met grote hoeveelheden grillig gestructureerde data. Hun transacties zijn vaak niet ‘ACID’, maar gebaseerd op Eventual consistency: ‘uiteindelijk’ leidt elke transactie wel tot consistente data, maar tijdelijke inconsistentie wordt getolereerd om de prestatie en beschikbaarheid te verhogen.

Het voornaamste advies is hier dat NoSQL-databaseystemen én relationele databases zich allemaal positioneren met een verschillende trade-off tussen consistentie, performance en flexibele datastructuur. Daarbij heeft elke categorie specifieke sterktes: column-oriented databases zijn bijvoorbeeld zeer geschikt om efficiënt aggregatie-operaties uit te voeren, terwijl graph databases goede ondersteuning bieden voor het leggen van (navigeerbare) verbanden tussen gegevens. Spring daarom niet klakkeloos op de NoSQL bandwagon, maar benoem de eigen, concrete behoeften in functie van die tradeoffs en selecteer op basis daarvan een systeem. NoSQL-systemen bieden in sommige gevallen een onmiskenbare meerwaarde, maar heel wat projecten zijn alsnog beter af met de vertrouwde relationele database, of met een hybride oplossing. Voorbeelden waar men mordicus alle data in een NoSQL-database tracht te wringen, soms met heel ongustige gevolgen, zijn legio.

 AG tekstballon-2

Data-integratie patronen

Een volgende vaststelling is dat Big Data-analytics een brug slaat tussen twee voorheen gescheiden werelden. Enerzijds heb je operationele systemen die de dagelijkse processen van een organisatie ondersteunen, bijvoorbeeld voorraadbeheer, boekhouding en planning. Anderzijds zijn er business intelligence-toepassingen die informatie aanleveren voor op lange termijn strategische beslissingen. Deze maken gebruik van een datawarehouse, waarin via ETL gegevens ( Extract, Transform en Load ) worden geconsolideerd uit operationele bronnen. Het ETL-proces zorgt doorgaans voor een zekere vertraging (latency), maar gezien het langetermijnperspectief van BI vormde dat in het verleden meestal geen probleem.

Dit onderscheid komt echter onder druk te staan door de opkomst van operational BI. Deze term geeft aan dat enerzijds analytics-technieken worden gebruikt voor operationele doelstellingen (bv. in real time detecteren van cross-selling kansen of monitoren en bijsturen van bedrijfsprocessen) en dat anderzijds ook strategische BI-toepassingen werken met (near) real time operationele data om zo kort mogelijk op de bal te spelen. Bijvoorbeeld executive dashboards met real time KPI’s. De latency die gepaard gaat met traditionele ETL vormt dan wél een struikelblok. Een mature Big Data-infrastructuur zal daarom idealiter bestaan uit een mix van data integratiepatronen (ETL, federatie, replicatie, changed data capture, virtualisatie/cloud). Soms is er ook sprake van streaming data, waarvoor specifieke opslag- en verwerkingstechnieken bestaan, zoals streaming databases, continuous queries en complex event processing. Het is daarom essentieel om zich voor elke toepassing vragen te stellen zoals: is er behoefte aan real time data? Moet de historiek bewaard worden? Moet de operationele data nog worden getransformeerd en/of gecleansed? Kan de bestaande infrastructuur een bijkomende analytische workload aan?

Big Data-analytics slaat een brug tussen twee voorheen gescheiden werelden

De antwoorden op deze vragen bepalen het meest aangewezen data-integratie patroon, waarbij ook weer onvermijdelijk trade-offs zullen spelen. Zo is bijvoorbeeld federatie niet onderhevig aan de latency van ETL, maar biedt het anderzijds minder mogelijkheden om data nog te transformeren of te verrijken, en is de performantie soms problematisch. Ook is de vraag of het koppelen van gegevens louter door IT gebeurt, of dit (deels) in handen van de gebruiker wordt gelegd. Ontwikkelingen zoals Self service BI en On Demand Integration spelen daar op in, maar kennen ook aanzienlijke risico’s, indien onoordeelkundig toegepast.

Een traditioneel ETL-proces tot slot wordt afgestemd op de analyses die men wenst uit te voeren: de data wordt in functie daarvan getransformeerd, gecleansed en geaggregeerd. Veel organisaties slaan echter al data op, zonder concrete analyses in gedachten: men gaat er (al dan niet terecht) van uit dat later nuttige informatie te distilleren valt. We spreken in die context over een data lake: gegevens uit diverse bronnen worden systematisch samengebracht en opgeslagen ‘as is’, zonder noemenswaardige transformatie. Op die wijze houdt men alle opties open. Uiteraard betekent dit dat achteraf nog heel wat preprocessing nodig is, alvorens men effectief tot analyse kan overgaan.

 AG tekstballon-3

Datakwaliteit

Een van oudsher bestaand probleem dat toeneemt in een Big Data-context, is datakwaliteit. Er ontstaat nu namelijk een verregaande ontkoppeling tussen de producent en de consument van de data. Vroeger werden gegevens immers vaak in een geïsoleerd systeem ingevoerd en gebruikt. De dataproducent was daardoor goed op de hoogte van de context waarin de gegevens werden aangewend en van de bijbehorende kwaliteitseisen. Bij Big Data-analytics worden gegevens echter onttrokken uit diverse bronsystemen en vervolgens gebruikt in allerhande analyses. Dataproducenten zijn zich daardoor niet langer bewust van alle toepassingen waarin hun gegevens gebruikt worden, laat staan dat ze rekening kunnen houden met de vaak zeer uiteenlopende kwaliteitseisen. Bovendien, het is al geen sinecure om de datakwaliteit van één dataset accuraat te meten en dat wordt nog complexer als men datasets met heel diverse kwaliteitskarakteristieken (bijvoorbeeld klantengegevens en clickstreams) met elkaar kruist.

Het probleem van de kwaliteit van data neemt toe in een Big Data-context

Daarenboven is datakwaliteit niet eendimensionaal. Het wordt gekarakteriseerd door dimensies als volledigheid, consistentie, tijdigheid, en accuraatheid. Bij afweging tussen de hiervoor vermelde dataintegratiepatronen moet men daarom ook de impact op datakwaliteit in aanmerking nemen. Elk van deze patronen zal immers een verschillende trade-off impliceren tussen deze dimensies: cleansing-mogelijkheden van ETL zullen bijvoorbeeld de consistentie ten goede komen, maar vaak ten koste gaan van de tijdigheid. Bij veel analytics-toepassingen is de datakwaliteit cruciaal en zal een investering in verbeterde datakwaliteit meer renderen dan een investering in een meer geavanceerde analysetechniek of een meer complex predictiemodel. Anderzijds dient opgemerkt dat sommige analytics-technieken (bijvoorbeeld neurale netwerken) veel minder gevoelig zijn voor vervuilde data dan andere.

 AG tekstballon-4

Aan de slag

Hoe creëren we nu business value met Big Data-analytics? In de eerste plaats kunnen we beter geïnformeerde beslissingen nemen. Er kan bijvoorbeeld een meer gefundeerde inschatting gemaakt worden van kredietrisico, alvorens iemand een lening toe te kennen. Ten tweede ontstaat de mogelijkheid om korter op de bal te spelen, bijvoorbeeld door bedrijfsprocessen continu te monitoren of door tijdig in te grijpen wanneer analyse van de event cloud voor een bepaalde creditcard alarmbellen doet afgaan die op fraude wijzen. Ook laten predictive analyticstechnieken toe te anticiperen op bepaalde gebeurtenissen: zo kan bij churn prediction getracht worden een klant aan boord te houden, wanneer analyse aangeeft dat hij dreigt over te stappen naar de concurrentie.

Eerste stap moet zijn het experimenteren in een veilige 'zandbak'-omgeving

Om deze meerwaarde effectief te realiseren, is er nood aan data scientists met de juiste mix van kwantitatieve vaardigheden, zakelijk inzicht en IT-kennis. Verder moet men gepaste keuzes maken uit een scala aan analytics-technieken, variërend van gekende statistische methoden, associatieregels en neurale netwerken tot meer exotische technieken. Belangrijk is om niet te focussen op de zuivere predictiekracht, maar ook aandacht te besteden aan de interpreteerbaarheid van de modellen (bijvoorbeeld white box versus black box), tool-ondersteuning, benodigde rekenkracht en gevoeligheid voor datakwaliteitsproblemen.

Het is raadzaam incrementeel te werk te gaan. Een eerste stap voor organisaties die willen experimenteren met Big Data-analytics is het creëren van een veilige ‘zandbak’ omgeving, afgeschermd van de overige infrastructuur. Dat biedt de mogelijkheid om data te leren kennen, ervaring op te doen met verschillende technieken én de onvermijdelijke beginnersfouten te maken zonder al te grote consequenties. Het betekent echter ook dat heel wat manipulaties (ontsluiten van data, formatting, cleansing, …) nog grotendeels manueel zullen gebeuren. Dit is geen probleem in een eerste experimentele fase. Het is wel belangrijk om ook dan reeds voldoende oog te hebben voor de business value, zodat men de nodige buy-in behoudt bij de business stakeholders.

Om op langere termijn tot duurzame toepassingen te komen, kunnen de initiële manuele oplossingen beter geleidelijk afgebouwd worden en moeten specifieke Big Data-voorzieningen naadloos ingepast worden in, en geïntegreerd met de infrastructuur. De data integratie suites van de belangrijkste vendors, zoals het Hadoop-ecosysteem en diverse analytics tools, houden expliciet rekening met dergelijke hybride omgeving, met zowel relationele als NoSQL gegevensopslag en verschillende data-integratietechnieken die naast elkaar bestaan, al dan niet gekoppeld aan een cloud-oplossing. Gezien echter het enorme aanbod aan producten, (soms exotische) benamingen en mogelijke combinaties, is het sterk aanbevolen om deze bij het keuzeproces te herleiden tot een aantal elementaire patronen en trade-offs. Alleen zo blijft men door de bomen het bos zien.

Zie ook Innovatie & Strategie op AG Connect Intelligence
2
Reacties
Thijs Doorenbosch 05 december 2016 10:36

Excuses, deze fout is door de webredactie geïntroduceerd en is inmiddels hersteld.

Bart Heinsius 24 oktober 2016 19:36

Ik kan het artikel bijna niet serieus nemen met de taalfout in de ondertitel.

Reactie toevoegen