Online analytisk behandling - Online analytical processing

Analyseprosessene , eller OLAP ( / oʊ l æ p / ), er en metode for å svare på flerdimensjonal analytisk (MDA) spør raskt i databehandling . OLAP er en del av den bredere kategorien forretningsinformasjon , som også omfatter relasjonsdatabaser , rapportskriving og datautvinning . Typiske anvendelser av OLAP inkluderer forretningsrapportering for salg, markedsføring , ledelsesrapportering, forretningsprosessstyring (BPM), budsjettering og prognoser ,finansiell rapportering og lignende områder, med nye applikasjoner som dukker opp, som landbruk .

Begrepet OLAP ble opprettet som en liten modifikasjon av den tradisjonelle databasetermen online transaksjonsbehandling (OLTP).

OLAP-verktøy gjør det mulig for brukere å analysere flerdimensjonale data interaktivt fra flere perspektiver. OLAP består av tre grunnleggende analytiske operasjoner: konsolidering (roll-up), drill-down, og skjæring og terning. Konsolidering innebærer aggregering av data som kan akkumuleres og beregnes i en eller flere dimensjoner. For eksempel blir alle salgskontor rullet opp til salgsavdelingen eller salgsavdelingen for å forutse salgstrender. Derimot er drill-down en teknikk som lar brukerne navigere gjennom detaljene. For eksempel kan brukere se salget etter individuelle produkter som utgjør en regions salg. Skjæring og terning er en funksjon der brukerne kan ta ut (skjære) et spesifikt sett med data fra OLAP-kuben og se (skjære) skjivene fra forskjellige synspunkter. Disse synspunktene kalles noen ganger dimensjoner (for eksempel å se på det samme salget av selger, eller etter dato, eller av kunde, eller av produkt, eller etter region, etc.).

Databaser konfigurert for OLAP bruker en flerdimensjonal datamodell, som muliggjør komplekse analytiske og ad hoc- spørsmål med rask utføringstid. De låner aspekter av navigasjonsdatabaser , hierarkiske databaser og relasjonsdatabaser.

OLAP er vanligvis i motsetning til OLTP (online transaksjonsbehandling), som generelt kjennetegnes av mye mindre komplekse spørsmål, i større volum, for å behandle transaksjoner i stedet for for forretningsinformasjon eller rapportering. Mens OLAP-systemer stort sett er optimalisert for lesing, må OLTP behandle alle slags spørsmål (lese, sette inn, oppdatere og slette).

Oversikt over OLAP-systemer

Kjernen i ethvert OLAP-system er en OLAP-kube (også kalt en 'flerdimensjonal kube' eller en hyperkube ). Den består av numeriske fakta kalt tiltak som er kategorisert etter dimensjoner . Tiltakene er plassert i skjæringspunktet mellom hyperkuben, som spennes av dimensjonene som et vektorrom . Det vanlige grensesnittet for å manipulere en OLAP-kube er et matriksgrensesnitt, som pivottabeller i et regnearkprogram, som utfører projiseringsoperasjoner langs dimensjonene, for eksempel aggregering eller gjennomsnitt.

Kubemetadataene blir vanligvis opprettet fra et stjerneskjema eller snøfnuggskjema eller faktakonstellasjon av tabeller i en relasjonsdatabase . Tiltak er hentet fra postene i faktatabellen og dimensjoner er avledet fra dimensjonstabellene .

Hvert mål kan betraktes som å ha et sett med etiketter , eller metadata assosiert med det. En dimensjon er det som beskriver disse merkelappene ; den gir informasjon om tiltaket .

Et enkelt eksempel vil være en kube som inneholder butikkens salg som mål , og dato / tid som dimensjon . Hver Sale har en dato / klokkeslett etikett som beskriver mer om at salg.

For eksempel: 

 Sales Fact Table
+-------------+----------+
| sale_amount | time_id  |
+-------------+----------+            Time Dimension
|      2008.10|     1234 |----+     +---------+-------------------+
+-------------+----------+    |     | time_id | timestamp         |
                              |     +---------+-------------------+
                              +---->|   1234  | 20080902 12:35:43 |
                                    +---------+-------------------+

Flerdimensjonale databaser

Flerdimensjonal struktur er definert som "en variant av relasjonsmodellen som bruker flerdimensjonale strukturer for å organisere data og uttrykke forholdet mellom data". Strukturen er delt inn i kuber, og kubene kan lagre og få tilgang til data innenfor rammen av hver kube. "Hver celle i en flerdimensjonal struktur inneholder aggregerte data relatert til elementer langs hver av dens dimensjoner". Selv når data manipuleres, er det fortsatt lett tilgjengelig og fortsetter å utgjøre et kompakt databaseformat. Dataene forblir fortsatt innbyrdes relatert. Flerdimensjonal struktur er ganske populær for analytiske databaser som bruker online analytiske prosesseringsapplikasjoner (OLAP). Analytiske databaser bruker disse databasene på grunn av deres evne til å levere svar på komplekse forretningsspørsmål raskt. Data kan sees fra forskjellige vinkler, noe som gir et bredere perspektiv på et problem i motsetning til andre modeller.

Aggregasjoner

Det er blitt hevdet at for komplekse spørsmål kan OLAP-kuber gi svar på rundt 0,1% av tiden som kreves for den samme spørringen på relasjonsdata for OLTP . Den viktigste mekanismen i OLAP som gjør det mulig å oppnå slik ytelse er bruken av aggregasjoner . Aggregasjoner bygges fra faktatabellen ved å endre granulariteten på bestemte dimensjoner og samle opp data langs disse dimensjonene, ved hjelp av en samlet funksjon (eller aggregeringsfunksjon ). Antallet mulige aggregeringer bestemmes av alle mulige kombinasjoner av dimensjonsgranulariteter.

Kombinasjonen av alle mulige aggregeringer og basisdataene inneholder svarene på alle spørsmål som kan besvares fra dataene.

Fordi det vanligvis er mange aggregeringer som kan beregnes, blir bare bare et forhåndsbestemt tall fullstendig beregnet; resten løses på forespørsel. Problemet med å bestemme hvilke aggregeringer (visninger) som skal beregnes, er kjent som visningsvalgproblemet. Visningsvalg kan begrenses av den totale størrelsen på det valgte settet med aggregeringer, tiden for å oppdatere dem fra endringer i basisdataene, eller begge deler. Målet med visningsvalg er vanligvis å minimere gjennomsnittstiden for å svare på OLAP-spørsmål, selv om noen studier også minimerer oppdateringstiden. Visningsvalget er NP-komplett . Mange tilnærminger til problemet har blitt utforsket, inkludert grådige algoritmer , randomisert søk, genetiske algoritmer og A * søkealgoritme .

Noen aggregeringsfunksjoner kan beregnes for hele OLAP-kuben ved å forhåndsberegne verdier for hver celle, og deretter beregne aggregeringen for en samleoppbygging av celler ved å aggregere disse aggregatene, bruke en delings- og erobringsalgoritme til det flerdimensjonale problemet for å beregne dem effektivt. For eksempel er den totale summen av en samleoppbygging bare summen av delsummen i hver celle. Funksjoner som kan dekomponeres på denne måten kalles nedbrytbare aggregeringsfunksjoner , og inkluderer COUNT, MAX, MIN,og SUMsom kan beregnes for hver celle og deretter direkte aggregeres; disse er kjent som selvnedbrytbare aggregeringsfunksjoner. I andre tilfeller kan aggregatfunksjonen beregnes ved å beregne hjelpetall for celler, aggregere disse hjelpetallene, og til slutt beregne det totale tallet på slutten; eksempler inkluderer AVERAGE(sporingssum og -telling, deling på slutten) og RANGE(sporing maks og min, subtrahering på slutten). I andre tilfeller kan ikke den samlede funksjonen beregnes uten å analysere hele settet samtidig, men i noen tilfeller kan tilnærminger beregnes; eksempler inkluderer DISTINCT COUNT, MEDIAN,og MODE; for eksempel er medianen til et sett ikke medianen for medianer av delmengder. Disse sistnevnte er vanskelige å implementere effektivt i OLAP, da de krever å beregne den samlede funksjonen på basedataene, enten å beregne dem online (tregt) eller forhåndsberegne dem for mulige utrullinger (stor plass).

Typer

OLAP-systemer har tradisjonelt blitt kategorisert ved hjelp av følgende taksonomi.

Flerdimensjonalt OLAP (MOLAP)

MOLAP (flerdimensjonal online analytisk behandling) er den klassiske formen for OLAP og blir noen ganger referert til som bare OLAP. MOLAP lagrer disse dataene i en optimalisert flerdimensjonal array-lagring, snarere enn i en relasjonsdatabase.

Noen MOLAP-verktøy krever forhåndsberegning og lagring av avledede data, for eksempel konsolideringer - operasjonen kjent som behandling. Slike MOLAP-verktøy bruker vanligvis et forhåndsberegnet datasett referert til som en datakube . Datakuben inneholder alle mulige svar på et gitt utvalg av spørsmål. Som et resultat har de veldig raskt svar på spørsmål. På den annen side kan oppdatering ta lang tid, avhengig av graden av forhåndsberegning. Forberegning kan også føre til det som kalles dataeksplosjon.

Andre MOLAP-verktøy, spesielt de som implementerer den funksjonelle databasemodellen, beregner ikke avledede data på forhånd, men gjør alle beregninger etter behov, bortsett fra de som tidligere ble forespurt og lagret i en cache.

Fordeler med MOLAP

  • Rask søkeytelse på grunn av optimalisert lagring, flerdimensjonal indeksering og hurtigbufring.
  • Mindre datastørrelse på data sammenlignet med data som er lagret i relasjonsdatabase på grunn av komprimeringsteknikker.
  • Automatisert beregning av data på høyere nivå.
  • Det er veldig kompakt for datasett med lav dimensjon.
  • Array-modeller gir naturlig indeksering.
  • Effektiv datautvinning oppnådd gjennom forhåndsstrukturering av aggregerte data.

Ulemper med MOLAP

  • Innen noen MOLAP-systemer kan behandlingstrinnet (datainnlasting) være ganske langt, spesielt på store datavolumer. Dette utbedres vanligvis ved å utføre bare trinnvis behandling, dvs. bare behandle dataene som er endret (vanligvis nye data) i stedet for å behandle hele datasettet på nytt.
  • Noen MOLAP-metoder introduserer dataredundans.

Produkter

Eksempler på kommersielle produkter som bruker MOLAP er Cognos Powerplay, Oracle Database OLAP Option , MicroStrategy , Microsoft Analysis Services , Essbase , TM1 , Jedox og icCube .

Relasjonell OLAP (ROLAP)

ROLAP jobber direkte med relasjonsdatabaser og krever ikke forhåndsberegning. Basisdataene og dimensjonstabellene er lagret som relasjonstabeller, og nye tabeller opprettes for å inneholde den samlede informasjonen. Det avhenger av et spesialisert skjema design. Denne metoden er avhengig av å manipulere dataene som er lagret i relasjonsdatabasen for å gi utseendet til tradisjonell OLAPs skjære- og skjæringsfunksjonalitet. I det vesentlige tilsvarer hver handling av kutting og kutting å legge til en "WHERE" -klausul i SQL-setningen. ROLAP-verktøy bruker ikke forhåndsberegnede datakuber, men stiller i stedet spørringen til standard relasjonsdatabase og dens tabeller for å bringe tilbake dataene som kreves for å svare på spørsmålet. ROLAP-verktøy har muligheten til å stille spørsmål, fordi metodikken ikke er begrenset til innholdet i en kube. ROLAP har også muligheten til å bore ned til det laveste detaljnivået i databasen.

Mens ROLAP bruker en relasjonell databasekilde, må databasen generelt være nøye utformet for ROLAP-bruk. En database som er designet for OLTP fungerer ikke bra som en ROLAP-database. Derfor innebærer ROLAP fortsatt å lage en ekstra kopi av dataene. Men siden det er en database, kan en rekke teknologier brukes til å fylle ut databasen.

Fordeler med ROLAP

  • ROLAP anses å være mer skalerbar når det gjelder å håndtere store datamengder, spesielt modeller med dimensjoner med veldig høy kardinalitet (dvs. millioner av medlemmer).
  • Med en rekke tilgjengelige datainnlastingsverktøy, og muligheten til å finjustere utdrag, transformere, laste (ETL) -koden til den bestemte datamodellen, er belastningstider generelt mye kortere enn med automatiserte MOLAP- belastninger.
  • Dataene lagres i en standard relasjonsdatabase og kan nås av ethvert SQL- rapporteringsverktøy (verktøyet trenger ikke å være et OLAP-verktøy).
  • ROLAP-verktøy er bedre til å håndtere fakta som ikke kan samles (f.eks. Tekstbeskrivelser). MOLAP- verktøy har en tendens til å lide av langsom ytelse når du spør etter disse elementene.
  • Ved å koble datalagringen fra den flerdimensjonale modellen, er det mulig å modellere data som ellers ikke passer inn i en streng dimensjonsmodell.
  • ROLAP-tilnærmingen kan utnytte databaseautorisasjonskontroller , for eksempel radnivåsikkerhet , hvorved søkeresultatene blir filtrert avhengig av forhåndsinnstilte kriterier, for eksempel til en gitt bruker eller gruppe brukere ( SQL WHERE-ledd).

Ulemper med ROLAP

  • Det er enighet i bransjen om at ROLAP-verktøy har lavere ytelse enn MOLAP-verktøy. Se imidlertid diskusjonen nedenfor om ROLAP-ytelse.
  • Lastingen av aggregattabeller må administreres av tilpasset ETL- kode. ROLAP-verktøyene hjelper ikke med denne oppgaven. Dette betyr ekstra utviklingstid og mer kode å støtte.
  • Når trinnet med å opprette samlede tabeller hoppes over, lider ytelsen til spørringen fordi de større detaljerte tabellene må spørres. Dette kan delvis løses ved å legge til flere aggregattabeller, men det er fortsatt ikke praktisk å lage aggregattabeller for alle kombinasjoner av dimensjoner / attributter.
  • ROLAP er avhengig av databasen for generelle formål for spørring og hurtigbufring, og derfor er flere spesielle teknikker som brukes av MOLAP- verktøy ikke tilgjengelige (for eksempel spesiell hierarkisk indeksering). Imidlertid utnytter moderne ROLAP-verktøy de nyeste forbedringene i SQL- språk som CUBE- og ROLLUP-operatører, DB2 Cube Views, samt andre SQL OLAP-utvidelser. Disse SQL-forbedringene kan redusere fordelene med MOLAP- verktøyene.
  • Siden ROLAP-verktøy er avhengige av SQL for alle beregningene, er de ikke egnet når modellen er tung på beregninger som ikke oversettes godt til SQL . Eksempler på slike modeller inkluderer budsjettering, tildelinger, finansiell rapportering og andre scenarier.

Utførelse av ROLAP

I OLAP-bransjen blir ROLAP vanligvis oppfattet som å kunne skalere for store datamengder, men lider av langsommere søkeytelse i motsetning til MOLAP . The OLAP Survey , den største uavhengige undersøkelsen på tvers av alle store OLAP produkter, blir gjennomført i 6 år (2001 til 2006) har stadig funnet at bedrifter som bruker ROLAP rapport tregere ytelse enn de som bruker MOLAP selv når datamengder ble tatt i betraktning.

Imidlertid, som med alle undersøkelser, er det en rekke subtile problemer som må tas i betraktning når vi tolker resultatene.

  • Undersøkelsen viser at ROLAP-verktøy har 7 ganger flere brukere enn MOLAP- verktøy innen hvert selskap. Systemer med flere brukere har en tendens til å lide av flere ytelsesproblemer i topp brukstid.
  • Det er også et spørsmål om kompleksiteten i modellen, målt både i antall dimensjoner og rikdom av beregninger. Undersøkelsen gir ikke en god måte å kontrollere for disse variasjonene i dataene som analyseres.

Ulempen med fleksibilitet

Noen selskaper velger ROLAP fordi de har tenkt å gjenbruke eksisterende relasjonelle databasetabeller - disse tabellene vil ofte ikke være optimalt designet for bruk av OLAP. Den overlegne fleksibiliteten til ROLAP-verktøy gjør at denne mindre enn optimale designen fungerer, men ytelsen lider. MOLAP- verktøy derimot vil tvinge dataene til å lastes inn på nytt til en optimal OLAP-design.

Hybrid OLAP (HOLAP)

Den uønskede avveiningen mellom ekstra ETL- kostnader og langsom spørringsytelse har sørget for at de fleste kommersielle OLAP-verktøy nå bruker en "Hybrid OLAP" (HOLAP) -tilnærming, som gjør det mulig for modelldesigneren å bestemme hvilken del av dataene som skal lagres i MOLAP og hvilken del i ROLAP.

Det er ingen klar avtale i bransjen om hva som er "hybrid OLAP", bortsett fra at en database vil dele data mellom relasjonell og spesialisert lagring. For eksempel, for noen leverandører, vil en HOLAP-database bruke relasjonstabeller til å inneholde større mengder detaljerte data, og bruke spesiallagring for i det minste noen aspekter av mindre mengder mer aggregerte eller mindre detaljerte data. HOLAP løser manglene ved MOLAP og ROLAP ved å kombinere funksjonene til begge tilnærminger. HOLAP-verktøy kan bruke både forhåndsberegnede kuber og relasjonelle datakilder.

Vertikal partisjonering

I denne modusen HOLAP lagrer aggregeringer i MOLAP for rask spørringsytelsen, og detaljerte data i ROLAP optimal tids av kuben behandling .

Horisontal partisjonering

I denne modusen lagrer HOLAP noe stykke data, vanligvis den nyeste (dvs. skiver etter tidsdimensjon) i MOLAP for rask spørringsytelse, og eldre data i ROLAP . Videre kan vi lagre noen terninger i MOLAP og andre i ROLAP , og utnytte det faktum at det i en stor kuboid vil være tette og sparsomme underregioner.

Produkter

Det første produktet som ga HOLAP-lagring var Holos , men teknologien ble også tilgjengelig i andre kommersielle produkter som Microsoft Analysis Services , Oracle Database OLAP Option , MicroStrategy og SAP AG BI Accelerator. Den hybrid OLAP-tilnærmingen kombinerer ROLAP og MOLAP-teknologi, og drar nytte av større skalerbarhet av ROLAP og raskere beregning av MOLAP. For eksempel kan en HOLAP-server lagre store mengder detaljerte data i en relasjonsdatabase, mens aggregeringer holdes i en egen MOLAP-butikk. Microsoft SQL Server 7.0 OLAP Services støtter en hybrid OLAP-server

Sammenligning

Hver type har visse fordeler, selv om det er uenighet om fordelene mellom leverandørene.

  • Noen MOLAP-implementeringer er utsatt for databaseeksplosjon, et fenomen som fører til at store mengder lagringsplass brukes av MOLAP-databaser når visse vanlige betingelser er oppfylt: høyt antall dimensjoner, forhåndsberegnede resultater og sparsomme flerdimensjonale data.
  • MOLAP leverer generelt bedre ytelse på grunn av spesialiserte indeksering og lagringsoptimaliseringer. MOLAP trenger også mindre lagringsplass sammenlignet med ROLAP fordi spesiallagring vanligvis inkluderer komprimeringsteknikker .
  • ROLAP er generelt mer skalerbart. Imidlertid er forprosessering med stort volum vanskelig å implementere effektivt, så det hoppes ofte over. ROLAP-spørringsytelse kan derfor lide enormt.
  • Siden ROLAP er mer avhengig av databasen for å utføre beregninger, har den flere begrensninger i de spesialiserte funksjonene den kan bruke.
  • HOLAP prøver å blande det beste fra ROLAP og MOLAP. Det kan generelt forhåndsbehandles raskt, skalere godt og tilby god funksjonsstøtte.

Andre typer

Følgende akronymer brukes også noen ganger, selv om de ikke er så utbredte som de ovenfor:

  • WOLAP - Nettbasert OLAP
  • DOLAP - OLAP på skrivebordet
  • RTOLAP - OLAP i sanntid
  • GOLAP - Graf OLAP
  • CaseOLAP - Kontekstbevisst Semantic OLAP, utviklet for biomedisinske applikasjoner. CaseOLAP-plattformen inkluderer forhåndsbehandling av data (f.eks. Nedlasting, utpakking og parsing av tekstdokumenter), indeksering og søking med Elasticsearch, oppretting av en funksjonell dokumentstruktur kalt Text-Cube, og kvantifisering av brukerdefinerte setningskategorirelasjoner ved bruk av CaseOLAP-algoritmen.

APIer og spørrespråk

I motsetning til relasjonsdatabaser , som hadde SQL som standard spørrespråk, og utbredte API-er som ODBC , JDBC og OLEDB , var det ingen slik enhet i OLAP-verdenen over lang tid. Den første virkelige standard API var OLE DB for OLAP- spesifikasjon fra Microsoft, som dukket opp i 1997 og introduserte MDX- spørringsspråket. Flere OLAP-leverandører - både server og klient - adopterte den. I 2001 kunngjorde Microsoft og Hyperion XML for Analysis- spesifikasjonen, som ble godkjent av de fleste av OLAP-leverandørene. Siden dette også brukte MDX som spørrespråk, ble MDX de facto-standarden. Siden september 2011 kan LINQ brukes til å spørre SSAS OLAP-kuber fra Microsoft .NET.

Produkter

Historie

Det første produktet som utførte OLAP-spørringer, var Express, som ble utgitt i 1970 (og kjøpt av Oracle i 1995 fra Information Resources). Begrepet dukket imidlertid ikke opp før i 1993 da det ble laget av Edgar F. Codd , som har blitt beskrevet som "faren til den relasjonelle databasen". Codds papir resulterte fra et kort konsulentoppdrag som Codd påtok seg for tidligere Arbor Software (senere Hyperion Solutions , og i 2007 ervervet av Oracle), som et slags markedsføringskupp. Selskapet hadde gitt ut sitt eget OLAP-produkt, Essbase , et år tidligere. Som et resultat ble Codds "tolv lover for online analytisk behandling" eksplisitt i sin henvisning til Essbase. Det var noe påfølgende kontrovers, og da Computerworld fikk vite at Codd ble betalt av Arbor, trakk den artikkelen. OLAP-markedet opplevde sterk vekst på slutten av 1990-tallet med dusinvis av kommersielle produkter som kom på markedet. I 1998 ga Microsoft ut sin første OLAP-server - Microsoft Analysis Services , som drev bred adopsjon av OLAP-teknologi og flyttet den til mainstream.

Produktsammenligning

Hovedartikkel: Sammenligning av OLAP-servere

OLAP-klienter

OLAP-klienter inkluderer mange regnearkprogrammer som Excel, webapplikasjon, SQL, instrumentbordverktøy, etc. Mange klienter støtter interaktiv datautforskning der brukere velger dimensjoner og mål av interesse. Noen dimensjoner brukes som filtre (for kutting og skjæring av data), mens andre er valgt som aksene i et pivottabell eller pivottabell. Brukere kan også variere aggregeringsnivået (for nedboring eller opprulling) av den viste visningen. Klienter kan også tilby en rekke grafiske widgets som glidebrytere, geografiske kart, varmekart og mer som kan grupperes og koordineres som dashbord. En omfattende liste over klienter vises i visualiseringskolonnen i sammenligningen av OLAP-servertabellen .

Markedsstruktur

Nedenfor er en liste over de beste OLAP-leverandørene i 2006, med tall i millioner av amerikanske dollar .

Leverandør Globale inntekter Konsolidert selskap
Microsoft Corporation 1806 Microsoft
Hyperion Solutions Corporation 1.077 Oracle
Cognos 735 IBM
Forretningsobjekter 416 SEVJE
MicroStrategy 416 MicroStrategy
SAP AG 330 SEVJE
Cartesis ( SAP ) 210 SEVJE
Applix 205 IBM
Infor 199 Infor
Oracle Corporation 159 Oracle
Andre 152 Andre
Total 5700

Åpen kilde

Se også

Bibliografi

  • Daniel Lemire (desember 2007). "Data Warehousing and OLAP-A Research-Oriented Bibliography" .
  • Erik Thomsen. (1997). OLAP Solutions: Building Multidimensional Information Systems, 2. utgave . John Wiley & Sons. ISBN 978-0-471-14931-6.

Referanser

Sitater

Kilder