BI-løsningsarkitektur i Center of Excellence

Denne artikel henvender sig til it-medarbejdere og it-ledere. Du får mere at vide om BI-løsningsarkitekturen i COE og de forskellige anvendte teknologier. Teknologier omfatter Azure, Power BI og Excel. Tilsammen kan de udnyttes til at levere en skalerbar og datadrevet CLOUD BI-platform.

Design af en robust BI-platform svarer lidt til at bygge en bro. en bro, der forbinder transformerede og forbedrede kildedata med dataforbrugere. Designet af en så kompleks struktur kræver et teknisk mindset, selvom det kan være en af de mest kreative og givende it-arkitekturer, du kan designe. I en stor organisation kan en BI-løsningsarkitektur bestå af:

• Datakilder
• Dataindtagelse
• Big data/dataforberedelse
• Data warehouse
• Semantiske BI-modeller
• Rapporter

Platformen skal understøtte specifikke krav. Det skal specifikt skal skaleres og udføres for at opfylde forventningerne hos forretningstjenester og dataforbrugere. Samtidig skal den være sikker fra bunden. Og den skal være tilstrækkelig robust til at tilpasse sig ændringer – fordi det er en sikkerhed for, at nye data og emneområder med tiden skal bringes online.

Rammer

Hos Microsoft har vi fra starten indført en systemlignende tilgang ved at investere i udvikling af strukturer. Tekniske og forretningsprocesrelaterede strukturer øger genbrug af design og logik og giver et ensartet resultat. De giver også fleksibilitet i arkitekturen, der udnytter mange teknologier, og de strømliner og reducerer de tekniske omkostninger via gentagne processer.

Vi har lært, at veldesignede strukturer øger synligheden af dataafstamning, effektanalyse, vedligeholdelse af forretningslogik, administration af taksonomi og strømlining af styring. Udviklingen blev også hurtigere, og samarbejdet på tværs af store teams blev mere dynamisk og effektivt.

Vi beskriver flere af vores strukturer i denne artikel.

Datamodeller

Datamodeller giver dig kontrol over, hvordan data struktureres og tilgås. For forretningstjenester og dataforbrugere er datamodeller deres grænseflade med BI-platformen.

En BI-platform kan levere tre forskellige typer modeller:

• Virksomhedsmodeller
• Semantiske BI-modeller
• Modeller til maskinel indlæring (ML)

Virksomhedsmodeller

Virksomhedsmodeller bygges og vedligeholdes af it-arkitekter. De kaldes nogle gange dimensionelle modeller eller datacentre. Data gemmes typisk i relationelt format som dimensions- og faktatabeller. Disse tabeller lagrer rensede og forbedrede data, der er konsolideret fra mange systemer, og de repræsenterer en autoritativ kilde til rapportering og analyse.

Virksomhedsmodeller leverer en ensartet og enkelt datakilde til rapportering og BI. De er bygget én gang og delt som en virksomhedsstandard. Styringspolitikker sikrer, at data er sikre, så adgangen til følsomme datasæt – f.eks. kundeoplysninger eller finansielle oplysninger – er begrænset efter behov. De vedtager navngivningskonventioner, der sikrer ensartethed og dermed yderligere fastslår troværdigheden af data og kvalitet.

I en BI-cloudplatform kan virksomhedsmodeller udrulles til en Synapse SQL-gruppe i Azure Synapse. Synapse SQL-puljen bliver derefter den eneste version af sandheden, som organisationen kan regne med for hurtig og robust indsigt.

Semantiske BI-modeller

Semantiske BI-modeller repræsenterer et semantisk lag i forhold til virksomhedsmodeller. De bygges og vedligeholdes af BI-udviklere og virksomhedsbrugere. BI-udviklere opretter centrale semantiske BI-modeller, der henter data fra virksomhedsmodeller. Erhvervsbrugere kan oprette mindre, uafhængige modeller – eller de kan udvide centrale semantiske BI-modeller med afdelingsbaserede eller eksterne kilder. Semantiske BI-modeller fokuserer ofte på et enkelt emneområde og deles ofte bredt.

Forretningsfunktioner aktiveres ikke kun af data, men af semantiske BI-modeller, der beskriver begreber, relationer, regler og standarder. På denne måde repræsenterer de intuitive og letforståede strukturer, der definerer datarelationer og indkapsler forretningsregler som beregninger. De kan også gennemtvinge detaljerede datatilladelser for at sikre, at de rette personer har adgang til de rette data. Det er vigtigt, at de fremskynder ydeevnen af forespørgsler, hvilket giver ekstremt dynamiske interaktive analyser – selv over terabyte data. På samme måde som virksomhedsmodeller anvender semantiske BI-modeller navngivningskonventioner, der sikrer ensartethed.

I en BI-cloudplatform kan BI-udviklere udrulle semantiske BI-modeller til Azure Analysis Services eller Power BI Premium-kapaciteter. Vi anbefaler, at du udruller til Power BI, når det bruges som dit rapporterings- og analyselag. Disse produkter understøtter forskellige lagringstilstande, så datamodeltabeller kan cachelagre deres data eller bruge DirectQuery, som er en teknologi, der sender forespørgsler til den underliggende datakilde. DirectQuery er en ideel lagringstilstand, når modeltabeller repræsenterer store datamængder, eller der er behov for at levere resultater i næsten realtid. De to lagringstilstande kan kombineres: Sammensatte modeller kombinerer tabeller, der bruger forskellige lagringstilstande i en enkelt model.

I forbindelse med modeller med mange forespørgsler kan Azure Load Balancer bruges til at fordele forespørgselsbelastningen jævnt på tværs af modelreplikaer. Det giver dig også mulighed for at skalere dine programmer og oprette meget tilgængelige semantiske BI-modeller.

Machine Learning-modeller

Modeller til maskinel indlæring (ML) bygges og vedligeholdes af datateknikere. De er hovedsageligt udviklet fra rå kilder i datasøen.

Oplærte ML-modeller kan vise mønstre i dine data. I mange tilfælde kan disse mønstre bruges til at foretage forudsigelser, der kan bruges til at forbedre data. Købsadfærd kan f.eks. bruges til at forudsige kundeafgang eller segmentkunder. Forudsigelsesresultater kan føjes til virksomhedsmodeller for at tillade analyse efter kundesegment.

I en BI-cloudplatform kan du bruge Azure Machine Learning til at oplære, udrulle, automatisere, administrere og spore modeller til maskinel indlæring.

Data warehouse

Når du sidder i hjertet af en BI-platform, er det data warehouse, der hoster dine virksomhedsmodeller. Det er en kilde til sanktionerede data – som et postsystem og som en hub – der betjener virksomhedsmodeller til rapportering, BI og datavidenskab.

Mange forretningstjenester, herunder LOB-programmer (line of business), kan stole på data warehouse'et som en autoritativ og styret kilde til virksomhedskendskab.

Hos Microsoft hostes vores data warehouse på Azure Data Lake Storage Gen2 (ADLS Gen2) og Azure Synapse Analytics.

• ADLS Gen2 gør Azure Storage til grundlaget for opbygning af virksomhedsdatasøer på Azure. Den er designet til at servicere flere petabytes af oplysninger, samtidig med at der opretholdes hundredvis af gigabits af dataoverførselshastighed. Og det tilbyder lavprislagerkapacitet og transaktioner. Desuden understøtter den Hadoop-kompatibel adgang, som giver dig mulighed for at administrere og få adgang til data på samme måde som med et HDFS (Hadoop Distributed File System). Faktisk kan Azure HDInsight, Azure Databricks og Azure Synapse Analytics alle få adgang til data, der er gemt i ADLS Gen2. På en BI-platform er det derfor et godt valg at gemme rå kildedata, halvbehandlede eller fasede data og produktionsklare data. Vi bruger den til at gemme alle vores forretningsdata.
• Azure Synapse Analytics er en analysetjeneste, der samler virksomhedsdatawarehousing og Big Data-analyser. Du får friheden til at sende forespørgsler om data på dine egne betingelser ved hjælp af enten serveruafhængige ressourcer efter behov eller klargjorte ressourcer – i stor målestok. Synapse SQL, der er en komponent i Azure Synapse Analytics, understøtter komplette T-SQL-baserede analyser, så det er ideelt til at hoste virksomhedsmodeller, der består af dine dimensions- og faktatabeller. Tabeller kan indlæses effektivt fra ADLS Gen2 ved hjælp af simple T-SQL-polybaseforespørgsler . Du har derefter styrken ved MPP til at køre analyser med høj ydeevne.

Business Rules Engine Framework

Vi har udviklet en BRE-struktur (Business Rules Engine ) for at katalogisere enhver forretningslogik, der kan implementeres i data warehouse-laget. En BRE kan betyde mange ting, men i forbindelse med et data warehouse er det nyttigt at oprette beregnede kolonner i relationstabeller. Disse beregnede kolonner repræsenteres normalt som matematiske beregninger eller udtryk ved hjælp af betingede sætninger.

Hensigten er at opdele forretningslogik fra kerne-BI-kode. Traditionelt er forretningsregler hard-coded i SQL-lagrede procedurer, så det resulterer ofte i en stor indsats for at vedligeholde dem, når virksomhedens behov ændres. I et BRE defineres forretningsregler én gang og bruges flere gange, når de anvendes på forskellige data warehouse-enheder. Hvis beregningslogik skal ændres, skal den kun opdateres ét sted og ikke i mange lagrede procedurer. Der er også en sidefordel: En BRE-struktur skaber gennemsigtighed og synlighed i implementeret forretningslogik, som kan eksponeres via en række rapporter, der opretter dokumentation, der opdaterer sig selv.

Datakilder

Et data warehouse kan konsolidere data fra stort set alle datakilder. Det er hovedsageligt bygget via LOB-datakilder, som ofte er relationsdatabaser, der lagrer emnespecifikke data for salg, marketing, økonomi osv. Disse databaser kan hostes i skyen, eller de kan være placeret i det lokale miljø. Andre datakilder kan være filbaserede, især weblogge eller IOT-data, der stammer fra enheder. Derudover kan data hentes fra SaaS-leverandører (Software-as-a-Service).

Hos Microsoft sender nogle af vores interne systemer driftsdata direkte til ADLS Gen2 ved hjælp af rå filformater. Ud over vores datasø omfatter andre kildesystemer relations-LOB-programmer, Excel-projektmapper, andre filbaserede kilder og MDM (Master Dataadministration) og brugerdefinerede datalagre. MDM-lagre giver os mulighed for at administrere vores masterdata for at sikre autoritative, standardiserede og validerede versioner af data.

Dataindtagelse

Med jævne mellemrum og i henhold til virksomhedens rytmer hentes data fra kildesystemer og indlæses i data warehouse'et. Det kan være en gang om dagen eller med hyppigere intervaller. Dataindtagelse vedrører udtrækning, transformering og indlæsning af data. Eller måske omvendt: udtrækning, indlæsning og derefter transformering af data. Forskellen kommer ned til, hvor transformationen finder sted. Transformationer anvendes til at rense, overholde, integrere og standardisere data. Du kan få flere oplysninger under Udtræk, transformér og indlæs (ETL).

I sidste ende er målet at indlæse de rigtige data i din virksomhedsmodel så hurtigt og effektivt som muligt.

Hos Microsoft bruger vi Azure Data Factory (ADF). Tjenesterne bruges til at planlægge og orkestrere datavalideringer, transformationer og massebelastninger fra eksterne kildesystemer til vores datasø. Det administreres af brugerdefinerede strukturer til behandling af data parallelt og i stor skala. Derudover udføres omfattende logføring for at understøtte fejlfinding, overvågning af ydeevnen og for at udløse beskedmeddelelser, når bestemte betingelser er opfyldt.

I mellemtiden udfører Azure Databricks – en Apache Spark-baserede analyseplatforme, der er optimeret til Azure Cloud Services-platformen – transformationer specifikt til datavidenskab. Den bygger og udfører også ML-modeller ved hjælp af Python-notesbøger. Scorer fra disse ML-modeller indlæses i data warehouse'et for at integrere forudsigelser med virksomhedsprogrammer og rapporter. Da Azure Databricks tilgår data lake-filerne direkte, eliminerer eller minimerer det behovet for at kopiere eller hente data.

Indtagelsesstruktur

Vi har udviklet en indtagelsesstruktur som et sæt konfigurationstabeller og -procedurer. Den understøtter en datadrevet tilgang til at hente store datamængder med høj hastighed og med minimal kode. Kort sagt forenkler denne struktur processen for dataanskaffelse for at indlæse data warehouse.

Strukturen afhænger af konfigurationstabeller, der gemmer datakilde- og datadestinationsrelaterede oplysninger, f.eks. kildetype, server, database, skema og tabelrelaterede oplysninger. Denne designtilgang betyder, at vi ikke behøver at udvikle specifikke ADF-pipelines eller SSIS-pakker (SQL Server Integration Services). I stedet skrives procedurer på det sprog, vi vælger, for at oprette ADF-pipelines, der genereres dynamisk og udføres på kørselstidspunktet. Dataanskaffelse bliver derfor en konfigurationsøvelse, der nemt kan aktiveres. Traditionelt ville det kræve omfattende udviklingsressourcer at oprette hard-coded ADF- eller SSIS-pakker.

Indtagelsesstrukturen er også designet til at forenkle processen til håndtering af ændringer i upstream-kildeskemaer. Det er nemt at opdatere konfigurationsdata – manuelt eller automatisk, når der registreres skemaændringer for at hente nyligt tilføjede attributter i kildesystemet.

Orkestreringsstruktur

Vi har udviklet en orkestreringsstruktur til drift og orkestrering af vores datapipelines. Den bruger et datadrevet design, der afhænger af et sæt konfigurationstabeller. Disse tabeller gemmer metadata, der beskriver pipelineafhængigheder, og hvordan kildedata knyttes til måldatastrukturer. Investeringen i udvikling af denne adaptive ramme har siden betalt sig selv; der er ikke længere et krav om at hard-code hver dataflytning.

Datalager

En datasø kan gemme store mængder rådata til senere brug sammen med transformationer af midlertidige data.

Hos Microsoft bruger vi ADLS Gen2 som vores eneste kilde til sandhed. Den gemmer rådata sammen med fasede data og produktionsklare data. Det giver en yderst skalerbar og omkostningseffektiv data lake-løsning til big data-analyser. Hvis du kombinerer styrken ved et filsystem med høj ydeevne med stor skala, er det optimeret til dataanalysearbejdsbelastninger og fremskynder tiden til indsigt.

ADLS Gen2 leverer det bedste fra to verdener: Det er BLOB-lager og et filsystemnavneområde med høj ydeevne, som vi konfigurerer med detaljerede adgangstilladelser.

Raffinerede data gemmes derefter i en relationsdatabase for at levere et højtydende, yderst skalerbart datalager til virksomhedsmodeller med sikkerhed, styring og administration. Emnespecifikke datacentre gemmes i Azure Synapse Analytics, som indlæses af Azure Databricks- eller Polybase T-SQL-forespørgsler.

Dataforbrug

På rapporteringslaget forbruger forretningstjenester virksomhedsdata fra data warehouse'et. De får også adgang til data direkte i datasøen til ad hoc-analyser eller datavidenskabelige opgaver.

Detaljerede tilladelser gennemtvinges på alle lag: i datasøen, virksomhedsmodeller og semantiske BI-modeller. Tilladelserne sikrer, at dataforbrugere kun kan se de data, de har adgangsrettigheder til.

Hos Microsoft bruger vi Power BI-rapporter og -dashboards og sideinddelte Rapporter i Power BI. Nogle rapporterings- og ad hoc-analyser udføres i Excel – især i forbindelse med finansiel rapportering.

Vi publicerer dataordbøger, som indeholder referenceoplysninger om vores datamodeller. De er gjort tilgængelige for vores brugere, så de kan finde oplysninger om vores BI-platform. Ordbøger dokumentmodeldesign, der giver beskrivelser om objekter, formater, struktur, dataafstamning, relationer og beregninger. Vi bruger Azure Data Catalog til at gøre det nemt at finde og forstå vores datakilder.

Dataforbrugsmønstre varierer typisk afhængigt af rolle:

• Dataanalytikere opretter direkte forbindelse til centrale semantiske BI-modeller. Når centrale semantiske BI-modeller indeholder alle de data og den logik, de har brug for, bruger de direkte forbindelser til at oprette Power BI-rapporter og -dashboards. Når de har brug for at udvide modellerne med afdelingsdata, opretter de sammensatte Power BI-modeller. Hvis der er behov for rapporter i regnearksformat, bruger de Excel til at oprette rapporter, der er baseret på centrale semantiske BI-modeller eller semantiske bi-afdelingsmodeller.
• BI-udviklere og driftsrapportforfattere opretter direkte forbindelse til virksomhedsmodeller. De bruger Power BI Desktop til at oprette analyserapporter med direkte forbindelse. De kan også oprette driftsrelaterede BI-rapporter som sideinddelte Power BI-rapporter, skrive oprindelige SQL-forespørgsler for at få adgang til data fra Azure Synapse Analytics-virksomhedsmodeller ved hjælp af T-SQL eller semantiske Power BI-modeller ved hjælp af DAX eller MDX.
• Datateknikere opretter direkte forbindelse til data i datasøen. De bruger Azure Databricks- og Python-notesbøger til at udvikle ML-modeller, som ofte er eksperimentelle og kræver specialfærdigheder til produktionsbrug.

Relateret indhold

Du kan få flere oplysninger om denne artikel i følgende ressourcer:

• Oversigt over stof adoption: Center of Excellence
• Enterprise BI i Azure med Azure Synapse Analytics
• Spørgsmål? Prøv at spørge Power BI-community'et
• Forslag? Bidrag med idéer til forbedring af Power BI

Professionelle services

Certificerede Power BI-partnere er tilgængelige for at hjælpe din organisation med at få succes, når du konfigurerer et COE. De kan give dig omkostningseffektiv oplæring eller en revision af dine data. Hvis du vil engagere en Power BI-partner, skal du gå til Power BI-partnerportalen.

Du kan også interagere med erfarne konsulentpartnere. De kan hjælpe dig med at vurdere, evaluere eller implementere Power BI.