KUNDENS TEKNISKE PLATTFORM. Kjøpsavtale DVH APPLIANCE

Transkript

1 Bilag 3 til Kjøpsavtalen (SSA-K lille) KUNDENS TEKNISKE PLATTFORM Avtalereferanse: PROSJ Kjøpsavtale DVH APPLIANCE

2 Innholdsfortegnelse 1 BESKRIVELSE AV NÅSITUASJON IT-STRATEGISKE FØRINGER Forretningskritiske prosesser IT Prinsipper Overordnet arkitektur Integrasjonsprinsipper Synkron forespørsel (tjenester) Asynkron meldingsoverføring Filoverføring Dataformater Ansvar for grensesnittspesifikasjoner Masterdata håndtering Oppsummering av viktige egenskaper for Norsk Tippings IT systemer DAGENS DRIFTSPRINSIPPER Tjenesteorientering Prinsipper for implementering og drift av tjenester Robusthet i driftsmiljøene DAGENS LØSNING Overordnet infrastruktur Infrastruktur for dagens Datavarehus løsning Viktige komponenter i datavarehusløsningen Produksjon-, test- og utviklingsmiljøer Tabellstørrelser Datadistribusjon Forventet økning i datamengde Interaktive spill (Multix/Belago) Tradisjonelle spill (Lotto, Vikinglotto, Tipping mm.) Totaler Databaseobjekter SQL Analytiske funksjoner Brukere Side 2 av 23

3 Bilaget inneholder en beskrivelse av nåværende tekniske plattform som er relevant for leveransen. Dette er kun en beskrivelse, og her er ikke krav fremsatt. 1 BESKRIVELSE AV NÅSITUASJON Avdelingen IT-Drift, har det tekniske ansvaret for driften av Norsk Tippings IT infrastruktur. Målet er en sikker og stabil drift. Avdelingen er delt opp i ulike enheter som jobber innenfor områder som Drift av spill, Nettverk, Server, Database, Mellomvare og Applikasjon. Norsk Tipping har i dag flere ulike driftsmodeller som strekker seg fra intern drift og support, til løsninger som er driftet eksternt. Skissen viser noen av aktørene vi samarbeider med. Side 3 av 23

4 2 IT-STRATEGISKE FØRINGER Modellen under er hentet fra IT-strategien til Norsk Tipping. Høyre side i tabellen beskriver hvordan vi skal oppnå de enkelte målene vi har satt oss i forretningsstrategien. Dette er en generalisering av krav og det vil selvsagt være avvik fra disse avhengig av system og viktighet. 2.1 Forretningskritiske prosesser Skissen under synliggjør produktene og forretningen til NT definert som 3 forretningskritiske hovedprosesser. Salg av spill, Gjennomføring av spill og Utbetaling av premier. Disse understøtter spillproduktene i de ulike kanalene. De forretningskritiske prosessene understøttes igjen av mange støtteprosesser og systemer, f.eks. datavarehus, CRM/ERP og ITIL prosessene. Side 4 av 23

5 Basert på NTs 3 hovedprosesser er det definert en kategorisering av løsninger i A, B, C og D. Det er beskrevet egenskaper som løsninger må oppfylle avhengig av hvilken kategorisering de har. Norsk Tipping sitt datavarehus er i dag kategorisert som en C-tjeneste. I framtida er det sannsynlig at det vil bli en B-tjeneste. 2.2 IT Prinsipper 1. Sikkerhet for kunden og stabil drift skal være en forutsetning for produksjon av våre spill. Dette prinsippet skal sikre våre kunder at deres penger, premier og spill blir godt ivaretatt og at informasjon om deres kundeforhold ikke kommer på avveie. Sikkerhet, stabilitet og kostnadseffektivitet er en forutsetning for alt vi foretar oss. 2. Fleksibilitet til å møte ulike virksomhetsscenarier skal ivaretas gjennom en tjenesteorientert arkitektur bestående av løst koblede og selvstendige komponenter. Endrede organiseringsformer som følge av rammevilkår eller forretningsmessige vurderinger skal kunne realiseres uten at IT-arkitekturen må bygges på nytt fra bunn. Dette stiller krav til integrasjonsarkitektur, tjenesteorientering og komponentorientering. 3. Nye spillkonsepter skal ha fleksibilitet i konseptutvikling og driftsmodell for å imøtekomme kravet om rask innføring og utfasing av spill i spillporteføljen. Vi skal legge til rette for hurtige endringer og ulike drifts-, forvaltnings- og leveranseformer i virksomheten. Dette prinsippet stiller krav til vår integrasjonsarkitektur, tjenesteorientering og komponentorientering. 4. Multikanal-distribusjon, en god brukeropplevelse og tilgjengelighet for kunden skal understøttes av en åpen arkitektur. Side 5 av 23

6 Kundens behov og hvilke produkter vi velger å ta ut i hvilke kanaler av merkantile årsaker skal være førende for hvordan vi planlegger vår arkitektur og realiserer løsninger slik at det ikke eksisterer tekniske begrensninger. Når vi designer og tilrettelegger for nye eller ved endring av eksisterende produkter og tjenester skal kundens behov stå i fokus og sørge for en enhetlig opplevelse av Norsk Tipping 5. Tilgjengelighet til relevante og konsistente kundedata skal ivaretas for alle spill og i alle kanaler. Uavhengig av spill/produkt, tjeneste og kanal så skal virksomhetskritiske kundedata ivaretas på en slik måte at vi sitter med tidsriktig, konsistent og oppdatert informasjon som igjen skal være tilgjengelig for konsum av ulike kanaler og spill. Kontroll på master data er en forutsetning i så måte. 6. Ett hovedanliggende for Norsk Tipping er ett sett av fellestjenester som går på tvers av kanaler og produkter. Disse består av styring, prosesser, system, integrasjon og infrastruktur. Fellestjenestene i Norsk Tipping sikrer en enhetlig og standardisert tilnærming til forretningskritiske tjenester som gjenbrukes på tvers av Produktområder. Gjennom disse sikrer vi fleksibilitet, effektivitet via gjenbruk og de muliggjør strategiske allianser/muligheter for utviklings- og ulike sourcingsmodeller. For å oppnå dette må Fellestjenestene være løst koblet, enkelt tilgjengelig og ha definerte eierskap for å sikre riktig videreutvikling og forvaltning. Forretnings- og sikkerhetskrav skal understøttes av standardiserte Fellestjenester. 7. Kortere time to market skal oppnås ved å redusere omfang via hyppige releaser og kontinuerlige forbedringer. En arbeidsform som muliggjør kontinuerlige forbedringer gjennom mindre og hyppigere releaser gjør selskapet bedre posisjonert til å håndtere et stadig økende endringsbehov. Vi skal også redusere kompleksitet ved å tilrettelegge for at man kan foreta endringer på isolerte områder uten store ringvirkninger og dertil konsekvenser. Færre avhengigheter, mindre omfang og konsekvenser vil understøtte «teste og prøve» («beta-testing; endre- teste-justereteste-implementere») og vil være med å drive innovasjonsevnen i Norsk Tipping. 8. Vi skal ha tidsriktig kompetanse og verktøy For å være konkurransedyktige, er det viktig at vi kontinuerlig oppdaterer vår kompetanse og at våre verktøy er tidsriktige og moderne. En mangel på kontinuitet innenfor disse områdene vil føre til behov for større løft som vil være mer krevende og omfattende enn hele tiden å sørge for at vi er på rett nivå. Side 6 av 23

7 2.3 Overordnet arkitektur Norsk Tipping har de siste årene jobbet med å rendyrke sin arkitektur i henhold til en tjenesteorientert arkitektur. Under vises en overordnet skisse over løsningen til Norsk Tipping i dag. Legend: Multix & Belago Net Partners PC & Tablet Mobile Cash Registers Retailer Terminals Presentation layer Integration layer Game Engines CMS Framework Web Web Channel Channel Server Servers? Mobil Channel Server Cash Register Channel Server LRT Channel Server Data store Back-office Operational External ID Services Frontend Integration Services Scheduling and Surveillance Interactive Video Terminal Engine Online Interactive Games Engine Sports Betting Engine Number Game Engine OLTP Data Storage Instant Game System Payment and Prize Payout services Package and delivery services Backend Integration Services Helpdesk/CRM System Game Auditing System Service Management ERP System Operational Data Storage ETL Services Data Warehouse Reporting and Analysis Customer Marketing System Side 7 av 23

8 2.4 Integrasjonsprinsipper Norsk Tipping har valgt å bygge egen kompetanse på området integrasjon. Vi anser fagområdet som viktig for oss, og tar derfor et aktiv forhold og ansvar til prinsippene som omhandler integrasjon. Norsk Tipping har valgt en arkitektur for sine systemer som består av mange enkeltsystemer som er koblet sammen med ulike integrasjonsmønstre. Vi har som hovedmål valgt å benytte synkrone integrasjoner der det er å foretrekke. Dette er likevel ikke praktisk mulig/nyttig i alle tilfeller, og vi har derfor ulike mønstre avhengig av typen integrasjon/datamengde: Synkron integrasjon Asynkron integrasjon Filoverføring Synkron forespørsel (tjenester) Dette er den foretrukne måten for integrasjon og den realiseres ved hjelp av et request/respons mønster. Dette er spesielt nyttig når man etterspør informasjon som krever umiddelbar respons tilbake. Dette er også et mønster som gir bedre kontroll på at forespurte hendelser virkelig har blitt utført. Synkrone tjenester realiseres som tjenester ved hjelp av HTTP-protokollen, og typisk formatert som XML eller JSON. Consumer Request data Response data Provider Asynkron meldingsoverføring Dette mønsteret er basert på meldinger. Et system generer et sett av data som overføres til et annet system(er), med det formål å persistere dataene lokalt eller prosessere dem. Dataene overføres typisk til flere systemer i et såkalt «broadcast» mønster. Abonnentene er typisk ukjente for avsenderen og vice versa. Side 8 av 23

9 Publisher Subscrib er Subscrib er Filoverføring Denne metoden benyttes der dataene er tilgjengelige som filer. Filoverføring benyttes der systemene mangler støtte for mer direkte form for kommunikasjon, eller der det er mer hensiktsmessig i forhold til datamengde, frekvens etc. Støttede protokoller, rangert etter preferanse er: Secure FTP (SFTP) Secure Copy (SCP) FTP Publisher Subscriber FTP server Dataformater Hvilke formater som brukes i dag avhenger av hva og hvordan integrasjonen skjer. Hensiktsmessig format vurderes ut i fra type integrasjon, datamengde, ytelse, mottaker, antall mottakere osv. Generelt kan man si at for frontend integrasjon så foretrekkes bruk av XML eller JSON. Men samtidig åpner vi for andre formater dersom det er hensiktsmessig. Alle dataelementer skal være komplette og «self-contained». Med det mener vi at det ikke skal være tvil om de individuelle meldingenes rekkefølge under transport Ansvar for grensesnittspesifikasjoner Det er tjenestetilbyder som til enhver tid har ansvar for å ta frem og vedlikeholde grensesnittspesifikasjoner for sine tjenester. Praktisering av bakoverkompatibilitet i tjenestene oppfordres for å unngå «big-bang» oppgraderinger Masterdata håndtering Norsk Tipping har et målbilde for dataarkitektur som understreker følgende prinsipper: Side 9 av 23

10 Det bør kun være en unik master for hvert datadomene. Duplisering av data til andre systemer bør begrenses. Det foretrukne mønsteret for å hente eksterne data er via synkrone oppslag mot mastersystemet for dataene. Kun mastersystemet bør ha rettigheter til å endre dataene sine. Ved distribusjon av masterdata er det abonnenten som har ansvar for å avstemme og kvalitetssikre sin kopi av dataene. 2.5 Oppsummering av viktige egenskaper for Norsk Tippings IT systemer Basert på strategiske mål og prinsipper, søker man en del egenskaper i de løsningene som skal implementeres. Dette er egenskaper som er viktige for at NT skal nå sine mål både i forhold til effektiv drift og for å kunne tilby de tjenestene som forventes av selskapet. NT ser at en del egenskaper er generelle og blir viktig i valg av løsninger og implementeringen av disse framover: 100 % oppetid, 24/7/365 service og produksjonssettinger på dagtid 100 % Virtualisering fleksibilitet, god ressursutnyttelse og raske endringer. 100 % Ressursutnyttelse Capacity on demand 100 % Automatisering installasjon, konfigurasjon og drift av testmiljøer og produksjon. Side 10 av 23

11 3 DAGENS DRIFTSPRINSIPPER 3.1 Tjenesteorientering Norsk Tipping jobber kontinuerlig med langsiktige strategier og mål. Dette gir igjen føringer for NTs drift av datasystemer, og nedenfor beskrives de behovene og prinsippene for IKT løsninger som skal etableres for fremtiden. NT har utviklet og tilbyr en del stabile fellestjenester som de ulike forretningstjenestene skal/kan benytte seg av gjennom et standardisert grensesnitt. Et eksempel på dette er behovet en spilløsning har for å identifisere spillere, ta betalt for spill etc. Moduliseringen og standardiseringen gjør at NT raskt kan utføre endringer på selve spillet uten å måtte endre på disse tjenestene i tillegg. NT skal ha full kontroll på grensesnittet mot fellestjenestene, og det skal gjøres tilgjengelig mot både interne og eksterne systemer. På samme måte kan fellestjenestene NT tilbyr være lokalisert og driftet både internt og eksternt. Dette målbildet skal alle nye systemer NT etablerer støtte. 3.2 Prinsipper for implementering og drift av tjenester o Ressursene som understøtter en tjeneste skal implementeres med et tilgjengelighetsnivå i henhold til tjenestens kategorisering. o Infrastruktur tjenester skal i størst mulig grad implementeres basert på velprøvde standarder og understøtte sikker stabil drift. o Alle IT infrastruktur løsninger skal implementeres så de underbygger et 24/7/365 design med fokus på at man kan forvalte løsningene på dagtid uten at tjenestene de understøtter må stoppes. o Alle HW ressurser som understøtter tjenestene skal såfremt praktisk mulig virtualiseres i logiske enheter. o IT funksjonalitet skal om mulig realiseres i infrastrukturen og tilbys forretningsapplikasjonene som standard tjenester. o Uønsket avhengighet mellom tjenester skal unngås o Overvåking skal være tjenestebasert, slik at hver tjeneste rapporterer sin tilgjengelighet 3.3 Robusthet i driftsmiljøene Det er viktig å etablere gode systemer for feiltoleranse slik at man kan håndtere både feilsituasjoner og planlagt vedlikehold uten nedetid. Dette gjelder på et generelt grunnlag for alle områdene innen nettverk, SAN, lagring, server men også løsninger og programvare. Feiltoleranse på et HW enhets nivå, (disksystem, fysiske servere, nettverks og firewall fysiske enheter etc) skal ha sin feiltoleranse mot tilsvarende enheter i en annen datahall. Virtuelle logiske enheter, (disker, virtuelle servere som Vmware og IBM LPAR, virtuelle firewalls etc) skal ikke kunne flyttes på tvers av to datahaller. De skal kun realiseres på HW innen en datahall. Side 11 av 23

12 Det vil i stor grad bli benyttet cluster funksjonalitet på mellomvare nivå for å etablere automatisert feiltoleranse for å sikre oss mot bortfall av tjenester ved HW feil. Det vil for eksempel kunne være WAS cluster og Oracle RAC. Side 12 av 23

13 4 DAGENS LØSNING Dagens løsninger er plassert i to datahaller. De er konfigurert basert på at hver datahall er redundant samt at datahallene er redundante mellom hverandre, dvs. two-site løsning med en aktiv-aktiv filosofi. Salgstransaksjoner kommer inn fra forskjellige salgskanaler, både via Internett og leide linjer i et IP/VPN nettverk. Begge typer trafikk er basert på løsninger som utøver feiltoleranse og lastbalansering mellom datahallene. LAN er delt inn i flere soner og disse er adskilt med brannmurer. Den tekniske infrastrukturen er basert på utvalgte produkter der det er bygget høy kompetanse internt. Infrastrukturen er basert på virtualisert teknologi, eksempelvis ved AIX dynamisk LPAR, VMware og virtuell brannmurløsning. 4.1 Overordnet infrastruktur Norsk Tipping benytter i dag IT infrastruktur fra flere produsenter. Listen under viser noen av de viktige hovedkomponentene i porteføljen: Nettverksløsninger, LAN/WAN o LAN / WAN tjenester - Cisco o Brannmur tjenester - Crossbeam/ Checkpoint o Proxy tjenester - Ironport / Varnish Lagringsløsning, datalagring o Diskløsning - Netapp Servere / OS: o Intel baserte servere HP, Linux og Windows. Virtualisert med VMware o Power baserte servere IBM, AIX. Virtualisert med LPar Mellomvare: o WebSphere Databaser: o Oracle Overvåkning o Tivoli o PRTG o Graphite Diverse o Citrix o Microsoft Active Directory o Glassfish NT bruker Intel-baserte, bærbare arbeidsstasjoner med Windows 7 og Microsoft Office. Side 13 av 23

14 4.2 Infrastruktur for dagens Datavarehus løsning Bilag 3 til Kjøpsavtalen: Kundens tekniske plattform PowerCenter Siebel Marketing ODBC JDBC Glassfish JDBC Staging Warehouse ODBC JAVA Apps ODBC ODBC ODBC Business Objects ODBC / JMS / XML / CSV CLIENT Source Systems PowerCenter Datawarehouse TWS Side 14 av 23

15 4.3 Viktige komponenter i datavarehusløsningen Bilag 3 til Kjøpsavtalen: Kundens tekniske plattform PowerCenter Datawarehouse -Informatica PowerCenter v9.5 IBM P795 / AIX v6.1 TL8 SP2 - PowerCenter Siebel Marketing Informatica PowerCenter v9.1 - IBM P795 / AIX v6.1 TL8 SP2 Kildesystemer Ulike applikasjoner og metoder for aksessering av data (ODBC, JMS, CSV, XML) Datavarehus / Staging Oracle IBM P795 / 1 CPU, 4 vcpu, 4 Threads / 350GB RAM / AIX v6.1 TL8 SP2 Datafile size: 2.8TB (Netapp) Partisjonskomprimering (uten komprimering; ca 8TB) Business Objects Oppgradering av verktøy er under planlegging (BO XI 4.1) Planlagt faseinndeling: Fase 1 Flytte VM Image til ny datahall Fase 2 Oppgradering til BO XI 3.1 SP6 Fase 3 Flytte løsning til ny VM (4 vcpu / 16GB / Windows 2012 x64) Oppgradering til BO XI 4.1 Nåværende løsning: o Business Objects Server Business Objects XI 3.1SP2 VMware VM / 2vCPU / 4GB RAM / Windows 2008 R2 x64 o Webserver Business Objects WebServer VMware VM / 2vCPU / 4GB RAM / Windows2008 R2 x64 Glassfish Flere ulike servere (VMware VM, RedHat Enterprise Linux, Glassfish) som fasiliterer applikasjoner og tjenester som kobler seg til varehusbasen vha. JDBC-tilkoblinger JAVA-applikasjoner Et flertall applikasjoner/servere (AIX 6.1) som aksesserer varehusbasen vha. JDBC IBM Tivoli IBM / AIX 6.1 / Tivoli Aksessering varehusbasen vha JDBC Side 15 av 23

16 4.4 Produksjon-, test- og utviklingsmiljøer Replikering av data mellom datahaller Norsk Tipping har to datahaller og en IKT-policy som stadfester at det må være mulig å operere med kun én datahall i kortere perioder. Vår datavarehusløsning er ikke klassifisert som et absolutt virksomhetskritisk system. Av den grunn anser vi det ikke som nødvendig å ha en «aktiv-aktiv» redundans mellom datahallene. Derimot må det være mulig å flytte databaser fra primær til sekundær datahall for videre operasjon der. I vanlige driftsituasjon er begge datahaller online og belastning kan være distribuert over begge datahaller. Løsningen må være basert på redundans og inneha nok kapasitet til å kunne kjøre alle databaser (utvikling, QA, pre-produksjon og produksjon) i ÉN datahall for kortere perioder. Dette kan innebære en mulig lavere ytelse. Prosessen med å flytte databaser fra en datahall til en annen kan være manuell, men NT ser for seg at denne bør være automatisert i størst mulig grad. Periodene hvor det vil være aktuelt for NT å kun kjøre i en datahall vil vanligvis være planlagt. Det må være mulig å starte løsningen i sekundær datahall både i forbindelse med en uforberedt driftsstans og i forbindelse med en kontrollert stopp av primær datahall og påfølgende start i sekundær. I vanlig driftssituasjon skal det ikke spille noen rolle hvilken datahall som er aktiv. Et mulig oppsett er vist under. Side 16 av 23

17 Datahal X Datahal Y Data Replikering Aktiv : Produksjon Standby: DEV/QA/PreProd Standby: Produksjon Aktiv: DEV/QA/PreProd Miljøer NT har miljøer for utvikling, QA/test, pre-produksjon og produksjon. Miljøene er delt opp i soner (f.eks. QA01..QA05) hvor alle systemer er satt opp. På grunn av utnyttelse av ressurser og lisenser, har NT i enkelte miljøer satt opp en «felles» sone (eksempelvis våre QA/test-miljøer). Disse har en Informatica Powercenter-server i QA00 som fasiliterer 5 forskjellige repositories i fem ulike soner og tilhørende databaser. Hver sone (for eksempel QA00..QA05) har sin egen VLAN. Det er ingen kommunikasjon mellom sonene; kun med felles sone (Eksempel: QA01 kan ikke kommunisere med QA02 men, QA01 og QA02 kan kommunisere med felles sone QA00). I dag har NT 5 forskjellige QA-soner, men i framtiden skal det være mulig å sette opp flere. Mellom miljøene ellers (QA/Prod/osv.) er det ingen kommunikasjon. Løsningen må også kunne støtte NTs utviklingsmiljø. Dette innebærer at løsningen må kunne fasilitere mange forskjellige databaser i ulike soner, men at f.eks. brukere av QAdatabaser ikke kan kommunisere med databaser i Produksjon. Dette betyr at hver database må kunne knyttes til en sone (eksempel QA01) eller miljø-vlan (eksempel QA00). I følgende skisse er en del soner/miljøer grå fordi de ikke er aktive pr. i dag, men vi ser for oss et behov i framtiden. Side 17 av 23

18 DEV QA PRE PROD PROD DEV 01 DEV 02 QA 01 QA 02 QA03 PREPROD 01 PROD 01 DEV 00 QA 00 Datasenter Datahall 1 Datahall 2 Utviklingsmiljø: Pr. i dag benyttes en felles varehusbase til nyutvikling i prosjekter og forvaltningsmessige utviklingsoppgaver. Vi ser for oss at vi fortsatt vil kunne ha det slik, men at det kan være ønskelig med flere parallelle utviklingsdatabaser ved behov. I utviklingsmiljøet benytter vi en nedskalert, liten database. (databasen har en antatt størrelse på ca. 10% av produksjon til enhver tid). Test- & QA-miljøer: Pr. i dag har vi opp til fem konfigurerbare og parallelle miljøer til test og QA. De brukes til test og QA av pågående utviklingsprosjekter og forvaltning. Dette er et mønster vi vil opprettholde. I test- og QA-miljøene benytter vi nedskalerte, små databaser (hver av de små databasene har en antatt størrelse på ca. 10% av produksjon til enhver tid). Produksjonskopi / pre-prod: Det er ønskelig å kunne ha en fullverdig produksjonskopi i et eget miljø. Side 18 av 23

19 Norsk Tipping har behov for enkelt å kunne administrere alle disse selvstendige databaseinstansene også i ny løsning. Vi kan ha behov for å generere «tomme» test- og utviklingsdatabaser basert på script eller en annen eksisterende basestruktur (inkl. produksjonsdatabasen). Vi må også kunne kopiere hele eller deler av eksisterende baser fra produksjon til test/utvikling eller populere eksisterende test-/utviklingsdatabaser med større eller mindre datamengder fra produksjon til test/utvikling. 4.5 Tabellstørrelser Tabellen under viser de største tabellene i dagens datavarehus, sortert etter antall rader. Tabellnavn Rader x Radlengde (gj.snitt) Størrelse (*) FACT_MX_GAME_ROUND GB FACT_COUPON GB AGG_DAY_DRAW_CUST_RET_PM GB AGG_DRAW_CUST_GAME_CP_PM GB AGG_DAY_CUSTOMER_GAME_RET_PM GB AGG_DAY_CUSTOMER_GAME GB Merk: Størrelse = Rader x Gj.snitt radlengde og ikke lagringsplass benyttet av Oracle. Inkluderer ikke størrelse på indekser. Side 19 av 23

20 Tabellen under viser de største tabellene (utenom aggregater) i dagens datavarehus, sortert etter antall rader. Tabellnavn Rader x Radlengde (gj.snitt) Størrelse (*) FACT_MX_GAME_ROUND GB FACT_COUPON GB FACT_COUPON_MATCH GB FACT_CHARITY_CONTRIBUTION GB FACT_ROW GB FACT_WINNER GB Merk: Størrelse = Rader x Gj.snitt radlengde og ikke lagringsplass benyttet av Oracle. Inkluderer ikke størrelse på indekser. 4.6 Datadistribusjon Ca. 45% av vårt datavolum i dag består av aggregater. Resterende 55% utgjør fakta- og dimensjonstabeller. 4.7 Forventet økning i datamengde Interaktive spill (Multix/Belago) FACT_MX_GAME_ROUND Kvartal Rader x Q Q Q Q Q Q Q Q Q Q Q Q Q Q Side 20 av 23

21 Introduksjonen av spill med høy brukerfrekvens (IVT, internett og mobil) forårsaker stor økning i antall transaksjoner. Denne tabellen inneholder spilltransaksjoner for IVT (Interactive Video Terminals). Økningen i transaksjonmengde ser ut til å vedvare. Om økningen fortsetter (+40% hvert år) blir antall transaksjoner: År Rader x For øyeblikket inneholder datavarehuset transaksjoner for siste 5 år Tradisjonelle spill (Lotto, Vikinglotto, Tipping mm.) FACT_COUPON Kvartal Rader x Q Q Q Q Q Q Q Q Q Q Q Q Q Q Tradisjonelle NT-spill har en relativt stabil transaksjonsmengde. Ca. 2/3 av datavolum/lagringsplass i datavarehuset utgjøres av tradisjonelle NT-spill. I hovedsak består disse dataene av relativt stabile mengder transaksjonsdata, kunde- og agentdata osv. Side 21 av 23

22 4.7.3 Totaler Med utgangspunkt i dagens datamengde, introduksjon av nye spill og spillkonsepter, økt behov for historikk og framtidig introduksjon av ustrukturerte data, estimerer vi følgende utvikling i datamengde, basert på 50% økning hvert år: År Datamengde I TB (ukomprimert) , Databaseobjekter Dagens varehusløsning består i hovedsak av tabeller og views i tillegg til enkelte andre objekter: Tabeller Standardtabeller, partisjonerte tabeller (ingen subpartisjonering), indeks-organiserte tabeller, partisjonerte indeks-organiserte tabeller. For partisjonerte tabeller, gjelder at eldre partisjoner er komprimert (vha. en ukentlig batchjobb). Så og si alle tabeller har unike nøkler i tillegg til indekser (og partisjonerte indekser i de tilfellene tabellene i seg selv er partisjonerte). Enkelte tabeller har definert flere indekser og/eller kombinerte indekser. Størrelsen på enkelte indekser er i visse tilfeller like stor som datamengden i selve tabellen. Indekser For øyeblikket benytter varehusbasen følgende typer indekser: Unike, Ikke-unike, funksjonsbaserte, partisjonerte (unike/ikke-unike), indeksorganiserte, bitmap. Views Materialiserte Views Vi benytter materialiserte views til en viss grad i dag. Noen views blir oppdatert av ETL-jobber, andre trigget av Tivoli. Databaselinker For øyeblikket benyttes enkelte linker til andre interne Oracle-databaser. NT har startet en prosess for å fjerne bruken av databaselinker, men foreløpig er løsningene våre implementert slik at det er nødvendig med databaselinker. Funksjoner Funksjoner er i bruk i begrenset omfang. Brukes til balansering mellom tabeller og til støtte for annen forretningslogikk. Packages Packages er i bruk i begrenset omfang. Brukes til balansering mellom tabeller og til støtte for annen forretningslogikk. Side 22 av 23

23 Prosedyrer Enkelte prosedyrer er definert. Brukes f.eks til oppdatering av materialiserte views. Sekvenser Alle sekvenser styres via funksjonalitet i Informatica Powercenter. 4.9 SQL Varehusløsningen inneholder et variert spekter av SQL-stiler/-syntaks. I Powercenter er hovedvekten av SQL-setningene genererte eller relativt enkle, men det finnes enkelte mer komplekse spørringer. Noen av de komplekse SQL ene bruker Oracles stil/syntaks for join/ outer join andre bruker ANSI-stil/syntaks. Prosessen med å endre til ANSI-stil/syntaks har startet og ny kode vil kun inneholde ANSI-stil/syntaks. SQL-kode eksekvert fra Business Objects er for det meste auto-generert SQL. Enkelte rapporter inneholder håndkodet SQL. Bruk av Oracle stil/syntaks ifm. outer joins er minimal Analytiske funksjoner Nåværende løsning benytter enkelte analytiske funksjoner i SQL, men mesteparten av denne typen funksjoner leveres/understøttes via 3.partsverktøy (som Informatica Powercenter). Organisasjonen beveger seg i økende grad fra ferdiggenererte rapporter på hva som skjedde i går mot selvbetjening og prediksjon. Vi antar derfor at datavarehusløsningen vil ha et utvidet behov for bruk av analytiske funksjoner i SQL. Dette for å understøtte selvbetjent BI hvor analytiske funksjoner ikke leveres via ETL-verktøy men kalkuleres ifm. spørring mot varehusbasen direkte vha. auto-generert SQL Brukere Norsk Tipping forventer en stor endring i bruk av datavarehuset. I dag har vi omkring hundre interne brukere som kjører (tunge) rapporter og analyser. Her planlegger vi overgang til selvbetjent analyse. I tillegg har vi noen hundre eksterne brukere som henter mindre rapporter. Kunder (spillere 2,1 mill.) har i dag ikke tilgang til datavarehuset, men vi ser for oss at vi etterhvert skal bruke informasjon fra datavarehus for å tilby en mer personalisert opplevelse på f.eks. webside eller mobil. Alle NTs IT-systemer, også DVH Appliance, må i fremtiden kunne understøtte denne type utvikling i bruksmønster. Når det gjelder antall samtidige brukere, ligger det godt under 100 i dag. Vi ser for oss at vi i løpet av levetida til tilbudt DVH Appliance maksimalt vil komme opp i 200 samtidige brukere. Side 23 av 23