Wat maakt big data ‘big’? En welke factoren geven de doorslag om te bepalen of een datawarehouse geschikt is voor big data analytics? Dat heeft alles te maken met hoe snel en tijdig de analyse moet zijn. Gericht op inzicht of actie? Betreffen het (historische) data die stil liggen of (actuele) data in beweging? De antwoorden op die vragen bepalen de keuzes in infrastructuur en maken een datawarehouse geschikt of niet. Indien ongeschikt: wat wel?
Niet alleen de aspecten hoeveelheid en diversiteit, maar vooral de aspecten actualiteit en snelheid bepalen de rol van het datawarehouse in het tijdperk van big data. Organisaties zetten het datawarehouse traditioneel in om een selectie van historische transactionele gegevens te verzamelen en te consolideren voor analyse- en rapportagedoeleinden. Dit gebeurt in een aparte, daarvoor specifiek ontworpen omgeving, om de operationale systemen te ontlasten. Dat uitgangspunt blijft van kracht, maar zijn het alleen historische gegevens die we willen analyseren?
Gegevens in beweging
De exponentiële groei, maar zeker ook de complexiteit en diversiteit van data, gaan de verwerkingskracht en opslagcapaciteit van conventionele databasesystemen te buiten. Big data gaat niet zozeer om veel data, maar met name om andere data dan waarvoor het traditionele datawarehouse is ontworpen. Dat verklaart de toenemende populariteit van NoSQL-opslagsystemen als Hadoop. Dat zou je gemakshalve een modern datawarehouse kunnen noemen. Maar nog steeds gaat het in dat geval om historische gegevens, gegevens die stil liggen. Het datawarehouse, traditioneel of modern, schiet tekort als het gaat om de analyse van gegevens in beweging, ofwel: fast data.
Fast data zijn gegevens die op het moment ontstaan door een gebeurtenis, activiteit of interactie via sociale en online kanalen, mobiele apparaten, sensoren, point-of-sale, het internet van alles. Ze zijn vluchtig en hebben een beperkte houdbaarheid. Ze lenen zich vooral voor het ondersteunen van actuele beslissingen en acties, hier en nu, zodat bedrijven hun aanbod kunnen personaliseren, processen in real-time kunnen bijsturen en proactief maatregelen kunnen nemen om risico’s te voorkomen.
Keuzes in infrastructuur
Dat heeft ook gevolgen voor keuzes in de infrastructuur. Een datawarehouse is in essentie een relationele database waarvan de gegevens vastliggen op een harde schijf. De toegangs- en verwerkingssnelheid van een harde schijf is relatief laag. Wil je big data analytics toepassen op gegevens in beweging, dan ben je altijd te laat. Dat vraagt om in-memory computing. Biedt een in-memory datawarehouse soelaas? Wellicht.
Maar niet in alle gevallen vanwege het keurslijf van een relationele database en de fysieke afstand tussen applicatie en opslag, waardoor zelfs seconden nog als een eeuwigheid aanvoelen. Data-offload in een in-memory datagrid heeft daarentegen de potentie om analyses in micro- of nanoseconden (lees: in real-time) te laten plaatsvinden zonder beperkingen in opslagformaat of -capaciteit.
Intelligent business operations
Het datawarehouse is onder voorwaarden geschikt voor de analyse van big data die stil liggen. Analyse van big data in beweging vraagt echter om een andere, revolutionaire benadering. Een in-memory datagrid is de meest voor de hand liggende oplossing als fundament voor analyse van big data in het hier en nu. Dit plaveit de weg voor een intelligente bedrijfsvoering. Of zoals Gartner het bestempelt: ‘intelligent business operations’.
Misschien moet ik nog een paar uurtjes wachten om te reageren omdat ik anders negatief uit de bocht vlieg, maar real-time is het sleutel woord en zonder verdere analyse te doen gebruik ik mijn in-memory datagrid om direct een reactie te geven in enkele nano-seconden:
Dit is een zwak artikel en wel om de volgende redenen:
– in memory datagrid is geen algemene term, wat het doet is totaal niet duidelijk en zullen weinig mensen hier wat aan hebben c.q. kunnen valideren wat hier staat.
– datawarehouse heeft mijn inziens weinig met big data te maken
– er wordt geen enkel voorbeeld gegeven waarom IMDG een oplossing is en welk probleem het oplost of voorbeelden geeft hoe het een probleem op lost
– Het artikel lijkt alleen maar geschreven om deze IMDG term te pluggen
– Het artikel gaat nergens naar toe, heeft geen kop en staart en daardoor geen enkele waarde.
Sorry, maar ik kan er niet meer van maken.
Om dan toch nog iets toe te voegen.
Virtualisatie maakt bijvoorbeeld meerdere servers op 1 fysieke server mogelijk, grid doet in de regel het tegenovergestelde: meerdere fysieke servers vormen samen 1 virtuele superserver (noem het mainframe).
Met in-memory datagrid wordt een verzameling objecten bedoeld die alleen maar bestaan in het geheugen en dit geheugen kan verdeeld worden over meerdere servers (hence: grid). Een soort cache over meerdere servers en daarom schaalbaar.
Wat je vervolgens met deze data doet laat zich raden, een voorbeeld, alle tweets uit Twitter worden geladen en vastgehouden voor een uur waardoor je zou kunnen herkennen dat er een opstootje ergens is ontstaan of er een gebeurtenis plaatsvind die door meerdere personen wordt vastgesteld. In memory perfomt nu eenmaal beter, maar het is in feite altijd meta-data, ofwel data over data en niet de originele data zelf.
Tja en op die data kun je jobs of query’s loslaten, maar inhoudelijk is dat allemaal maatwerk.
Een toepassing die ik zou kunnen verzinnen is gezichtsherkenning op een luchthaven.
Inderdaad. Veel kretelogie en weinig wol.
[quote]De toegangs- en verwerkingssnelheid van een harde schijf is relatief laag.[/quote]
Dit is altijd waar, maar wat zegt het? Iedere database gebruikt RAM en wanneer de relevante data in RAM staat, hoeft er dus geen (of weinig) data vanaf schijf te komen. De vraag is dan of het wel een probleem is dat een harde schijf relatief langzaam is. En wat is “relatief” ?
[quote]Wil je big data analytics toepassen op gegevens in beweging, dan ben je altijd te laat.[/quote]
Klinklare onzin! Dit is mijn vakgebied en wij doen niet anders dan “big data analytics” (groot woord voor simpel werk) op miljarden records. En die staan gewoon op een paar harde schijven en zijn snel genoeg voor millisecond response tijden. Waarom? Omdat we slim werken. En dan is hard- + software van een paar duizend euro (inclusief support en licenties) goed genoeg voor big data analytics. En ja, de analyses zijn snel genoeg om de beveiliging van onze klant te garanderen.
Wanneer je het probleem niet snapt, maakt het niet uit welke techniek of hoeveel geld je er tegenaan gooit. De kans op succes is zonder deze kennis zeer minimaal.
Een artikel dat weinig feiten bevat en enigszins opvallend de naam SAP vermijdt. De uiteindelijke technische grondslag van de in-memory techniek wordt in het volgende PDF van Hasso Plattner uitgebreid uit de doeken gedaan : http://global.sap.com/platform/pdf/In-Memory%20Data%20Management.pdf
@Frank : conventionele DB’s hebben hun tijd gehad. Als een een DBA/BI-er bent zou je toch wel enige aandacht moeten gaan besteden aan nieuwe zaken zoals de column-oriented database. We hebben het hier over real time analytics en niet over een data warehouse dat middels langdurige batchjobs gegevens moet trekken uit een OLTP systeem alvorens in staat te zijn om die de volgende dag te kunnen presenteren (als de aggregatie en index jobs klaar zijn). Zodra de data in het OLTP systeem wordt ge-commit wordt die gepusht naar het SAP HANA systeem en is dan direct beschikbaar voor analyse : http://www.youtube.com/watch?v=p94hK5FcsKc
De response tijden van een conventioneel BW systeem zijn niet te vergelijken met SAP HANA.
In SAP BW HANA systemen heb je geen extended-star schema meer en is de architectuur stukken vereenvoudigd : http://www.saphana.com/servlet/JiveServlet/previewBody/1363-102-2-1810/SDN_HANA_opt_InfoCube%20FINAL.PDF
Zelfs Oracle heeft dat door : http://www.oracle.com/us/corporate/press/2020717 en komt met een column-oriented optie voor BI.
@Henri: Je opmerking betreffende meta-data in datagrids klopt niet. Er wordt juist WEL data opgeslagen en niet alleen meta-data. Over het algemeen maken IMDG’s gebruik van NoSQL-datastores, bijvoorbeeld als key-value pairs waarbij de daadwerkelijke data als waarde worden opgeslagen. Door middel van de key kan de betreffende data direct worden benaderd, wat neer komt op (near) real-time access. Is de key niet bekend, of moeten er datasets worden benaderd, kan er gebruik worden gemaakt van meer traditionele queries. Veel voorkomende toepassingen zijn algorithmic trading, fraudedetectie, hoogvolume-transactieverwerking en event stream processing. Je genoemde toepassing van gezichtsherkenning past zeker in dit rijtje en is inderdaad een goed voorbeeld. Als je je kennis van IMDG’s wilt actualiseren, kijk dan eens op: http://architects.dzone.com/articles/memory-data-grids
@KJ: Enigszins opvallend dat jij juist wel de naam SAP noemt. Het opinie-artikel gaat over concepten, en niet over producten en leveranciers, mede om partijdigheid te vermijden en een objectief beeld te schetsen. Overigens sta ik volledig achter je opmerking betreffende conventionele databases. Relationele databases hebben ons jarenlang goed gediend, maar zoals overal vindt er ook in de databasewereld een langzame, maar zekere evolutie plaats. We hebben dit al gezien bij de opkomst van datawarehouses, welke veelal gebaseerd zijn op gedenormaliseerde datastructuren. Nieuwe stappen in deze evolutie zijn NoSQL, key-value stores en inderdaad ook column-oriented databases. De opkomst van in-memory technologie zorgt voor een verdere scheiding van data. Gegevens die (near) real-time beschikbaar moeten zijn, of short-lived zijn (bijv sensordata, events, e.d.) worden in een in-memory datastore opgeslagen. De meer statische data, of gegevens die langere tijd bewaard dienen te worden, komen terecht in datawarehouses of Hadoop-achtige systemen. Dit is de kern van het artikel: waar sla je welke data op? Neem als voorbeeld een bedrijf als Bosch, bekend van hun groenkleurig gereedschap en powertools. Tegenwoordig zijn deze apparaten voorzien van allerlei sensoren die je vertellen wanneer de accu leeg dreigt te raken, of een onderdeel defect is. Deze sensoren produceren een enorme hoeveelheid data. De vraag is in hoeverre deze data relevant is om op te slaan. Uiteindelijk gaat het om de gebeurtenis die de data representeren, nl. de melding dat bijvoorbeeld een onderdeel defect is. Hierna heeft de data geen waarde meer. Dit soort gegevens wordt typisch in een in-memory datastore opgeslagen, en na verwerking van het event weer verwijderd. Een bank die betaaltransacties controleert en opslaat, is meer gebaat bij datawarehouse-achtige structuren.
@Ricardo Passchier
Ik begrijp dat je partijdigheid wilt vermijden, maar ik ben van mening dat dit concept echter wel van SAP afkomstig is.
http://en.wikipedia.org/wiki/SAP_HANA
Tenzij je mij van het tegendeel kan overtuigen ?
@KJ: Hoewel HANA een in-memory database is en in-memory concepten gebruikt, is SAP zeker niet de bedenker van deze concepten. Vrijwel elke technologie zoals gebruikt in HANA is afkomstig van acquisities of gebaseerd op third party producten, hetgeen wordt onderstreept in het wikipedia-artikel waarnaar je verwijst.
Een grote drijvende kracht achter de zogenaamde column-oriented databases is onder andere Facebook, met diens Cassandra-database (tegenwoordig een Apache project). De databaseconcepten van HANA en SAP DB zijn afkomstig van MaxDB, wat op zijn beurt weer gebaseerd is op Software AG’s ADABAS D.
Kortom: de producten en concepten hebben vele wortels, en kunnen derhalve niet naar één leverancier herleid worden.