jens andersen bloghoved

Bliver In-Memory det samme for BI som SQL var for databaser?

Det er så min første blog på Version2. Jeg har brugt en del tid på at tænke over, hvilket emne indenfor Business Intelligence (BI) som var mest påtrængende. Der er mange kandidater, idet det stadig er det område indenfor administrativ it, hvor der investeres mest.

Jeg har i den forgangne uge været i Paris for at deltage i SAPs EMEA Analytics Advisory Council, som en af 8 repræsentanter for BI leverandørerne i Europa - den eneste fra Nordeuropa. Her havde vi mulighed for at fremlægge og udveksle vores meninger om, hvordan markedet udvikler sig. Denne blog er skrevet på en Café i Paris i dejligt solskin med en god Café au Lait.

Det hotte emne lige nu for SAP er In-memory Technology. Det er i sig selv ikke nyt indenfor BI, idet QlikTech allerede tilbage i 1997 kom med QlikView som deres in-memory bud på løsning af performance problemer. Nu melder de store BI leverandører sig så ind i kampen – SAP med HANA, IBM med SolidDB, Oracle med Exalytics. Der er desuden andre leverandører som Terradata og Sybase (nu SAP), som har fokus på alternative måder at lagre data på.

Jeg er vokset op med C.J Date, som i sin bog An Introduction to Database Systems satte nye standarder for databaser i midten af 80’erne og kraftigt promoverede ideerne bag relationelle databaser, der første gang teoretisk blev beskrevet i 1970 af Edgar F. Codd. Sjovt nok gik der også 15 år fra QlikTech lancerede in-memory til at verdens største BI leverandør ser det som det store dyr i åbenbaringen. Er det samme skift vi nu ser som SQL bragte til os på database niveau? Hvis JA – så betyder det også noget for vores forretningsmodel. SQL var en stor ting og ændrede meget for forretningen – får in-memory den samme betydning?

Det som sker nu, er at teknologien flyttes fra forretningen tilbage til IT, som har en governance model for virksomhedens tilgang til data. Her tror jeg det er fornuftigt at tænke ud over traditionel IT og se på f.eks. Clayton Christensen (ja, han har danske aner) som er professor på Havard. I sin bog The Innovators Dilemma beskriver han begrebet ”Disruptive Innovation” – er det det, vi står over for? Personligt tror jeg det, idet f.eks. høj hastighed er en forudsætning for mobil BI. Vi er blevet forvænt til at en side på en iPad er der med det samme – hvor mange virksomheder kan sige det med deres BI-løsninger? 15 sekunder er lang tid…

En udfordring med de leverandører af in-memory løsninger som i dag har fået fodfæste er, at de henvender sig primært til forretningen. De slipper data fri, så alle kan bruge dem. Men hvad så med ”the single point of truth”? Det er her at Bill Inmon og Ralph Kimball ikke har levet forgæves.

Gartner er som sædvanligt kommet med en god model for, hvorledes BI brugere anvender data:

  1. Dem der kigger på, hvad der er sket
  2. Dem der kigger på, hvad sker der her og nu
  3. Dem der kigger på, hvad der kommer til at ske

In-memory skal supportere alle tre områder. Det er måske her de nye store leverandører overhaler de traditionelle in-memory leverandører indenom ved at tilbyde mere avanceret funktionalitet, f.eks. er SAP ved at implementere Data Mining i deres HANA miljø. Spørgsmålet er så f.eks. i Danmark, hvilket modtræk SAS Institute har imod dette?

Afslutningsvis vil jeg stille spørgsmålet – er dette bare en ny database, eller er der mere i det? Og hvorfor har én af stifterne af SAP lagt sit otium ind på dette. Prøv at besøge http://www.hpi.uni-potsdam.de/willkommen.html?L=1&cHash=7e31f9324645305286dc6c9c443d7730 og se hvad Hasso Platner Institute er.

Jeg glæder mig til en god diskussion om emnet. Næste blog vil være om det relaterede emne Mobile BI – så kommentarer om dette emne er også velkomne.

Se præsentationsartiklen af Jens Andersen her

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Nils Bøjden

De største problem med BI løsninger er som regel at de hviler på et fuldstændigt løst semantisk grundlag.

Derfor skal BI mere og mere hvile på et datavarehus (eller noget lignende) som er blevet dannet under et paradigme som hedder:

Topstyring Pædagogik Lingvistisk snilde Tvang + trusler

Derefter kan man begynde at lave BI løsninger som kan fastholdes i en konsensus.

Dette krav vil blive endnu mere udtalt nå mobile BI løsninger bliver et mantra (og det er der slet ingen tvivl om at de bliver), hvor den visuelle informationsmængde reduceres yderligere i forhold til i dag, hvorfor sporbarheden af dataaftryk i et givent BI skærmbillede reduceres til ingenting, med mindre det semantiske tvangsregime er indført.

  • 1
  • 0
#3 Daniel Madsen

In-memory løsninger er utrolig interessante, men de kan ikke stå alene.

Man bør stadig sørge for at have en dimensionel modelleret Mart og helst også et aggregerings-lag ovenpå denne - f.eks. en OLAP løsning. Så har man i det mindste stadig en anelse kontrol over de data man slipper brugerne løs på (imodsætning til at koble et in-memory værktøj op imod operationnelle systemer og tro man kan slippe for at lave datawarehouse løsningen gys) og man bør have for øje når man designer sin Mart løsning at data skal præsenteres på en måde så de er intuitive at anvende fra sådanne værktøjer - ellers fejler det også.

Husk også på at før folk slippes løs i ens datawarehouse med sådanne værktøjer, bør de have noget uddannelse - både i brug af værktøjerne, men så sandelig også i hvordan tingene er struktureret og modelleret i Mart'en, samt hvad der er af tekniske spidsfindigheder man skal være opmærksom på (f.eks. hvis data ikke nødvendigvis aggregerer super godt på tværs af markeder).

Og så mener jeg iøvrigt heller ikke at sådanne værktøjer er for alle brugere. Hovedparten af ens brugere vil formentlig stadig få mest ud af at kunne browse rundt i veldefinerede Dashboards (som BI teamet har forberedt) eller få leveret daglige/ugentlige/månedlige rapporter. Men folk med beslutningsansvar kan få meget ud af denne direkte adgang til at visualisere data, som inmemory løsninger tilbyder.

Rapporter og Dashboards giver dig også et valideringspunkt for disse ad-hoc udtræk, da der somregel er værdier man kan holde op imod disse officielle datakilder der gør at man kan vurdere om man har fat i det rigtige eller er helt skævt på den.

Så grundlæggende er disse blot et ekstra værktøj, som supplerer den mere traditionelle BI platform. Begge paradigmer mødes i disse tider og der går ikke længe før vi forventer at BI løsningerne supporterer begge dele optimalt og selvfølgelig også kan præsentere data på alle devices.

Nu hvor forskellige produkter nævnes, vil jeg da anbefale også at tage et kig på: http://www.tableausoftware.com som efter min mening leverer et af de fedeste in-memory produkter.

  • 2
  • 0
#4 Nils Bøjden

jeg mig løst via en veldefineret data model (som forretningen ejer).

Nej. Forretningen kan ikke eje en datamodel. En logisk eller fysisk datamodel er en konsekvens af en semantisk uniformering. Forretningen ejer denne uniformering. Denne ensretning af verbale udtryk er desuden det væsentligste designdokument til datamodellen.

Men min pointe var nu mere at des mindre det visuelle udtryk bliver, des vigtigere bliver den semantiske uniformering af virksomhedens data og processer.

  • 0
  • 0
#6 Jens Andersen

... At skrive et indlæg som giver mange gode tråde i diskussionen. Jeg havde denne gang alene til hensigt at få igangsat en dialog om In-memory. Men jeg rammer et blødt punkt som jeg har tænkt at bruge det næste halve år på. Men jeg kan lide udtrykket lingvistisk snilde. Et spørgsmål der rejser sig i dialogen - bygger BI på topstyring eller konsensus. Hilsen Jens Ps. Sendt fra en ferie i Thailand hvor ungerne endelig er smidt i seng.

  • 0
  • 0
#7 Daniel Madsen

"bygger BI på topstyring eller konsensus."

Imo konsensus, men selvfølgelig med en hvis grad af topstyring. Men det nytter ikke noget at det hele er designet efter hvordan ledelsen vil have tingene og ser på forretningsprocesserne. Man er nød til at komme ud i afdelingerne og snakke med folk og finde ud af hvordan processerne i virkeligheden foregår og hvilke terminologier man anvender (som ofte kan kræve ensretning på organisatorisk plan, da disse kan variere fra de terminologier ledelsen anvender).

Det er vigtigt at BI ikke bliver et værktøj forbeholdt top-ledelsen og derfor er man også nød til at sørge for at folk i de forskellige afdelinger er med til at levere input, føler et ansvar for projektet og tager BI-løsningen til sig - ellers ender man bare med at man har det her system, som ingen rigtig gider bruge fordi de ik føler de har en tilknytning til det - så bliver det netop en selvopfyldene profeti at det er "et system for ledelsen".

God ferie :-)

  • 0
  • 0
#8 Morten Andersen

Undskyld min naivitet, men hvad er "in memory" i denne sammenhæng? Hvis jeg skulle gætte ville jeg gætte på det henviste til "in-memory databaser" som jo har nogle andre karakteristika in diskbaserede db'er... men er ikke sikker af konteksten. For skulle "in memory" database giver anledning til specielle revolutioner indenfor BI?

  • 1
  • 0
#9 Daniel Madsen

Hej Morten

Både og, i denne sammenhæng er der dog normalt tale om properitære in-memory databaser som en del af tool'et, som er specifikt optimeret til at lave drill-downs i det pågældende tool, men det er ikke en databaseløsning man kan tage ud af pakken og anvende til andre formål.

Fordelen er at man kan "slice og dice" sig igennem dataene utrolig hurtigt, men ofte tager man så et initial-hit hvor dataene skal indlæses i hukommelsen.

  • 0
  • 0
#11 Simon Pape

Som du rigtigt skriver, Jens, så kan efterhånden alle BI-leverandører levere en eller anden form for appliance. De markedsføres næsten altid i kontekst med "Big Data", og der er da næppe den store tvivl om at jo hurtigere maskineriet snurrer, jo større datamængder kan behandles med acceptabel responstid.

Jeg tænker dog på om ikke denne kapacitet kunne bruges til at give brugerne større indsigt - hurtigere. Min erfaring er at i de fleste BI-løsningen bruges en stor del af tiden på at lægge data til rette (for at kompensere for dårlig performance ved udsøgning). Hvad nu hvis man med en appliance kunne analysere/rapportere direkte på rådata (mere eller mindre)?

I den sammenhæng vil et godt semantisk lag komme til sin ret. Modelleringen sker så bare virtuelt i dette lag frem for at bygge EDW og datamarter. Og med den store regnekraft i en appliance afvikles reglerne i datamodellen "at runtime" frem for i batch i ETL-jobbene.

Jeg ser et stort potentiale i at kunne nøjes med at hælde rådata ind og vedligeholde en (eller flere) virtuel datamodel. Og slutbrugerne ville elske at kunne få data stillet til rådighed hurtigere.

Jeg har diskuteret dette potentiale med flere af de leverandører, du nævner, men ingen har rigtigt kunnet henvise til kunder, hvor de har prøvet det.

Er der mon andre her på V2, der har erfaring i den retning med appliances?

  • 0
  • 0
#13 Daniel Madsen

Simon: Det er på ingen måde let at koble direkte op imod operationelle data, det handler om langt mere end blot performance. Data i operationelle systemer er lagret for bedst muligt at servicere systemet og efterhånden som systemerne udvikler sig ser man ofte at der er blevet foretaget en del krumspring fordi det er besværligt (ikke mindst tidskrævende og dyrt) at ændre modellen efterfølgene. Jeg siger ikke det er optimalt at det gøres på denne måde, men det er desværre i vid udstrækning realiteten baseret på min erfaring.

Men det er ikke det mindste problem, et langt større problem er at en enterprise virksomhed ofte har rigtig mange forskellige systemer kørende til at servicere forskellige afdelinger og behov. Disse systemer har intet kendskab til hinanden og der er derfor ingen konsistens i forhold til hvordan data er lagret. Det betyder at det kan være svært at sammenholde data imellem systemerne. Et simpelt eksempel er at et system kan ske at lagre datoer i UTC, mens et andet anvender CET - er man ikke opmærksom på det får man skæve resultater.

Det stiller derfor store krav og indgående kendskab til hvordan data er lagret i de forskellige systemer at konsolidere dem til en samlet løsning hvorfra rapportering kan ske uden at skulle være ekspert i hvordan data er lagret i de forskellige systemer.

Det er i høj grad denne konsolidering af data der tager tiden ved opbygning af en BI løsning - hvorvidt du så opstiller dette virtuelt eller opbygger ETL jobs ændrer ikke på ret meget i forhold til udviklingstiden.

Desuden ændrer det heller ikke på at dit analyse tool stadig vil skulle extracte forholdsvis store datamængder for at kunne opbygge in-memory modeller du efterfølgende kan "slice og dice" i.

I forhold til at opbygge virtuelle modeller og afvikle det "run time" kan du reelt se på EDW'et som et mellemliggende "cache-lager". Det vil alt andet lige give bedre "run time" performance for slutbrugerne at koble analyse-værktøjet op imod dette "cache-lager" end at skulle grave resultaterne ud af de operationelle systemer - og du har langt mere kontrol over processen.

Min anbefaling vil derfor være at opbygge EDW'et - det giver langt større kontrol med dataene OG også bedre slutbruger-performance og udviklingstiden vil ikke være ret meget større fordi udfordringen ligger i at konsolidere forretningens data og stille dem tilrådighed på en overskuelig måde - uagtet om du gør dette "virtuelt" eller ej.

  • 0
  • 0
#14 Nikolaj Henrichsen

@Simon: Acinta bygger på et semantisk lag, der tillader, at data hentes direkte fra kildesystemerne - altså rådata som du siger, men uden nogen form for replikering.

Det har nogle begrænsninger på datamængderne (omkring 10 mio. rækker pt.), men den grænse vil flytte sig i takt med at disksystemerne bliver hurtigere, jf den nye generation af Solid State Diske (SSD).

Det giver en meget hurtig time-to-market idet en færdig løsning kan lægges direkte ovenpå f.eks. et ERP system, og data er altid live, hvilket igen åbner for en række andre muligheder i rapporteringen.

Personligt tror jeg, at in-memory teknologien blot er et mellemskridt på vejen mod andre løsninger idet disksystemer som sagt med tiden vil blive meget hurtige.

  • 0
  • 0
Log ind eller Opret konto for at kommentere