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

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.

De udfordringer du bringer på banen Nils forestiller jeg mig løst via en veldefineret data model (som forretningen ejer). Jeg er dog helt enig i at det ikke skal/kan løses teknisk.

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.

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.

"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 :-)

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?

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.

Datavarehuset bygger på topstyring. BI bygger på forvaltningsgrenens behov.

Datavarehuset er et stykke infrastruktur. BI er en applikation.

Hvis man undlader at differentiere mellem de 2 funktioner er man allerede gået ned ad den forkerte vej.

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?

Vectorwise fra Actian (tidligere Ingres Corp) http://www.actian.com/products/vectorwise er vist lige hvad du leder efter.

Mine venner fortæller mig at den er hurtig; meget hurtig...

Mange hilsner,
Jacob

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.

@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.