Iedereen wil zijn informatie snel. Gisteren liever dan vandaag. Terwijl ik (samen met Johan van der Kooij) maar een keynote sessie zat te luisteren, vroeg ik me af: “wat bedoelen we eigenlijk met real time?”
Tien jaar geleden vonden we maandelijkse updates van het DWH heel normaal, en die kwamen dan ergens 2-3 weken in de nieuwe maand beschikbaar. In het slechtste geval betekende “actueel” dan ongeveer 7 weken oud. Tegenwoordig ligt de norm zo rond dagelijks/wekelijks. En vaker dan 1 maal per dag is niet ongebruikelijk. Volgens de BI-guru waar wij naar luisterden, wordt de trend meer en meer real-time. Maar wat bedoelen we daar nu mee, vroeg ik me af?
Operationele systemen kun je praktisch gesproken alleen bevragen met “voorgebakken” queries. Geen enkele zichzelf respecterende DBA kan riskeren dat een runaway query zijn systeem omver trekt. Dus we vuren een vooraf gedefinieerde query af (doorgaans zonder al te veel Group By statements), om zo de meest actuele en mogelijk nog volatiele stand te krijgen. Bouwen en tunen van de query gebeurt in betrekkelijke rust, off-line.
Of we scoren transacties op fraude risico. Het model dat bepaalt welke transacties als “frauduleus” moeten worden bestempeld is wederom off-line ontwikkeld. Wat real-time gebeurt is enkel en alleen deployment. Analyse gebeurt ruim nadat de gegevens zijn verzameld, en de verversing frequentie van zulke scripts is doorgaans laag. Heeft volgens mij niet veel met real-time analyse te maken…
En on-line aanbevelingen (a la Amazon of Bol.com) die veranderen met elke opeenvolgende muisklik? Ook die zijn van tevoren gedetermineerd. Gelijkenis met andere klanten bepaalt je aanbeveling, wat neer komt op mathematische proximiteit. Geen gelijkenis met echte klanten, maar “ingedikte” cluster centroiden van klanten met vergelijkbaar koop/surf gedrag. En ook deze centroiden worden off-line berekend. Is niks “real-time” aan. Maar deployment van het model bij elke muisklik gebeurt (doorgaans) wel “on the fly”, dus in real-time. Door hoge performance eisen van dit soort web applicaties (aanbeveling gereed in 1/100e sec. o.i.d.) moeten de cluster centroiden van tevoren berekend worden.
Zo bezien lijkt real-time vooral (alleen?) betrekking te hebben op deployment, ik heb nog nauwelijks voorbeelden gehoord van real-time analyse.
Abonneren op:
Reacties plaatsen (Atom)
8 reacties:
Tom,
Ik denk dat real-time (nu) alleen mogelijk is wanneer het om een zogenaamd 'managed process' gaat. De query is standaard en de actie (gebaseerd op de uitkomst van de query) is eenvoudig (als a dan b). Dit is dan te automatiseren m.b.v. agents of business rules).
Wanneer er meer complexiteit komt in de beslissing neemt het real time vermogen sterk af. In het verleden heeft men wel eens een poging gewaagd met bijvoorbeeld expert systemen. Dit soort brain dumps klinkt prachtig maar zoals ik vroeger al op de universiteit leerde""The map is not the territory". De mens is altijd beter bij impliciete beslissingen omdat het onderbuikgevoel (of verborgen kennis) niet te automatiseren is. Bij expliciete beslissingen is dat makkelijker.
Kortom, Expliciete gegevens (cijfers, geen verborgen interpretaties) kunnen bij eenvoudige (geautomatiseerde) beslissingen bijna real time genomen worden. Dat zijn er niet zo veel. Hooguit wanneer het gaat om hele operationele procesmatige beslissingen. De vraag is of je daar real time voor nodig hebt.
De vraag zal dan ook meer gaan naar right time. Dat betekent in ieder geval sneller dan de concurrentie (want informatie voorsprong). De BI vendors zullen daar technologisch op inspringen. We zullen denk ik dus steeds meer real time achtige tools en architecturen gaan zien.
Maar... het echte competitie voordeel zit niet (alleen) in de snelheid van informatie maar wat je er mee doet. Laten we daarom in dit technologisch geweld vooral niet het menselijke element vergeten. Daar zit de echte return-on-intelligence!
Tom,
Het gaat inderdaad om real-time maar om right-time. Daarnaast ga je bij een hoge frequentie van gegevensverversing niet de bronsystemen belasten met queries, maar heb je messaging oplossingen nodig(push i.p.v. pull). Een goed voorbeeld in NL is Albert Heijn zie: http://www.few.vu.nl/nl/Images/ah_2009_tcm38-107212.doc
Hi!
"Dus we vuren een vooraf gedefinieerde query af (doorgaans zonder al te veel Group By statements), om zo de meest actuele en mogelijk nog volatiele stand te krijgen. Bouwen en tunen van de query gebeurt in betrekkelijke rust, off-line."
Je kunt de query toch gewoon op een replicatie slave afvuren? Dan heeft het operationele systeem er in ieder geval geen last van. Op MySQL is een dergelijke slave tamelijk eenvoudig in te richten, waarschijnlijk is dat voor andere DBs ook mogelijk.
Roland Bouman
http://rpbouman.blogspot.com/
Auteur van "Pentaho Solutions"
Ik ben het helemaal met je eens, Tom.
Real-time is een utopie binnen BI die vooralsnog niet haalbaar is.
Natuurlijk zijn er technisch zat mogelijkheden om het verversen van de informatie te versnellen maar die zijn allen niet beheer-baar, belasten ongewenst de bronsystemen en zijn simpelweg veel te duur.
Het belangrijkste bij het implementeren van BI is de mindset bij de gebruikers(-organisatie) dat BI per definitie niet real-time is of zou moeten zijn. Het doel is niet hulp bij het uitvoeren van operationele zaken maar het voorzien van de gebruikers van dusdanige informatie dat er betere beslissingen kunnen worden gemaakt. Meer lange termijn denken dus.
Zodra de behoefte duidelijk is dat er real-time informatie beschikbaar moet zijn zal dit moeten worden opgelost binnen de operationele systemen.
Voorbeeld: Controle of een invoice betaald is doe je binnen het financiele systeem zelf. Bepalen of het inkoopbeleid nog wel strookt met de bedrijfsdoelstellingen of dat we binnenkort het budget overschrijden doe je met behulp van BI.
Hi Tom,
Leuk om dit onderwerp eens ter sprake te brengen die graag met een boude stelling wil aanvullen:
De behoefte aan real-time informatie wordt ten onrechte door consultants en toolleveranciers aangepraat.
De zero-latency enterprise is een illusie. Sommige informatie is real-time nodig en andere informatie niet. Per organisatie en per branche verschilt deze verdeling bovendien. Right-time is de juiste qualificatie en zelfs als we die weten te realiseren, is er nog de decision / action latency, zoals Jorgen ook opmerkt.
Het gebruik van BI/datawarehouse in operationele toepassingen is bovendien principieel geen probleem (hoewel dat vaak wel zwart / wit wordt gezien) maar een afweging tussen 1) de gewenste ToBe-enterprise architectuur, 2) consequenties voor de realisatie en 3) beheer en ondersteuning
Real time BI is zoals andere reacties ook al aangeven wellicht iets voor de de simpele pseudo beslissingen (dus voor te programmeren) op operationeel niveau. En eigenlijk is het dan gewoon onderdeel van een operationeel proces. Maar niemand heeft mij nog ooit duidelijk kunnen wat voor het nemen van beslissingen op tactisch laat staan strategisch niveau van een organisatie de toegevoegde waarde is van het kunnen beschikken over de allerlaatste transactie gegevens..... Nou niemand is misschien overdreven; Tom Clancy heeft een paar aardige technothrillers geschreven...
bij operationele besturing kan de beschikking over realtime informatie zeer nuttig zijn (callcenter bemensing, logistieke besturing, ...), omdat er snel moet worden ingegrepen op basis van een opgetreden situatie. Belangrijkste kenmerk van deze vraagstukken is dat het eigenlijk op geen enkele manier met het traditionele BI (batch) denken en de daarvoor geldende technieken te maken heeft. Het draait hierbij om een slimme query op een OLTP omgeving, hooguit nog vanuit performance optiek voorzien van een replicatiemechanisme, bv als er door een niet te voorzien aantal gebruikers - via het web - op wordt gequeried. Veelal zal je zien dat dergelijke vraagstukken ook niet door BI mensen wordt opgelost, maar door de medewerkers die zich bezig houden met de OLTP omgeving.
Zoals Johan terecht opmerkt behoort het real-time informatie voorziening thuis bij OLTP systemen. Het zijn vaak de operationele gegevens die real-time als vereiste hebben. Waarom dan nog via een DWH/BI systeem faciliteren?
Het argument wat dan vaak gegeven wordt is dat het om geintegreerde data gaat. Ook zo'n argument houdt met de huidige technieken zoals SOA, Cloud Computing en mash-up geen stand.
Gaat het dan om de history gecombineerd met een actuele situatie? gebruik dan mash-up technologie om de actuele stand uit je OLTP en History uit je DWH te halen.
al met al (zoals een ieder hiervoor al concludeerde) is real-time een utopie in de BI wereld en zou het niet als argument gebruikt mogen worden in een BI/DWH business case.
Een reactie plaatsen