I de sidste par årtier har datavarehusarkitekturen været grundpillen i virksomhedens dataøkosystemer. Og på trods af adskillige ændringer i løbet af de sidste fem år på arenaen af ​​big data, cloud computing, prædiktiv analyse og informationsteknologier, datavarehuse har kun fået større betydning.

I dag er vigtigheden af datalager kan ikke nægtes, og der er flere muligheder for lagring, analyse og indeksering af data end nogensinde før.

Denne artikel vil diskutere de forskellige grundlæggende begreber i en virksomhedsdatavarehusarkitektur, forskellige Enterprise Data Warehouse-modeller (EDW), deres egenskaber og væsentlige komponenter og undersøge det primære formål med et datavarehus i moderne industrier.

Data Warehouse Arkitektur Teorier

For at forstå datavarehusarkitekturen er det vigtigt at kende til Ralph Kimball og Bill Inmon, de to fremtrædende figurer inden for data warehousing. Disse to foreslog forskellige tilgange at designe data warehousing arkitekturer.

Kimball tilgang

Ralph Kimball er kendt for sit dimensionel modellering tilgang, som fokuserer på at levere data på en måde, der er optimeret til slutbrugerforespørgsler og rapportering. Kimball-tilgangen fokuserer på at skabe datavarehuse ved hjælp af stjerneskemastrukturer, hvor en central faktatabel indeholder kvantitative mål, og dimensionstabeller beskriver relaterede attributter. Det er en top-down, iterativ og agil tilgang, der understreger den hurtige levering af forretningsværdi ved at bygge fagspecifikke datamarts for at imødekomme specifikke brugerrapporteringsbehov.

Inmon tilgang

Bill Inmons tilgang lægger på den anden side vægt på et mere centraliseret, omfattende og struktureret data warehousing-miljø. Det går ind for en normaliseret datamodel, hvor data er organiseret i separate tabeller for at eliminere redundans og vedligeholde dataintegritet. Den bruger et "data warehouse bus"-koncept til at skabe standardiserede, genanvendelige komponenter og understreger dataintegration, transformation og styring for at sikre datanøjagtighed og konsistens.

Komponenter af DWH Architecture

Før vi går videre til arkitekturens detaljer, lad os forstå det grundlæggende i, hvad der gør et datavarehus - skelettet bag den struktur.

De forskellige lag i et datavarehus eller komponenterne i en DWH-arkitektur er:

1. Data Warehouse Database

Den centrale komponent i en typisk datavarehusarkitektur er en database, der lagerfører alle virksomhedsdata og gør dem overskuelige til rapportering. Det betyder naturligvis, at du skal vælge, hvilken type database du vil bruge til at gemme data på dit lager.

Følgende er de fire databasetyper, du kan bruge:

• Typiske relationsdatabaser er de rækkecentrerede databaser, du måske bruger til hverdag — for eksempel Microsoft SQL Server, SAP, Oracle og IBM DB2.
• Analyse databaser er netop udviklet til datalagring til at opretholde og administrere analyser, såsom Teradata og Greenplum.
• Data warehouse applikationer er ikke ligefrem lagringsdatabaser, men flere forhandlere tilbyder nu applikationer, der tilbyder software til datahåndtering samt hardware til lagring af data. For eksempel SAP Hana, Oracle Exadata og IBM Netezza.
• Cloud-baserede databaser kan hostes og hentes i skyen, så du ikke behøver at anskaffe noget hardware for at konfigurere dit datavarehus – for eksempel Amazon Redshift, Google BigQuery og Microsoft Azure SQL.

2. Ekstraktions-, transformations- og indlæsningsværktøjer (ETL)

ETL værktøjer er centrale komponenter i en virksomhedens datavarehus design. Disse værktøjer hjælper med at udtrække data fra forskellige kilder, transformere dem til et passende arrangement og indlæse dem i et datavarehus.

Det ETL-værktøj, du vælger, bestemmer følgende:

• Tiden brugt i dataudtræk
• Tilgange til at udtrække data
• Slags transformationer anvendt og enkelheden i at gøre det
• Forretningsregel definition for Data validering og udrensning for at forbedre slutproduktanalysen
• Udfyldning af fejllagte data
• Skitserer informationsdistribution fra det grundlæggende depot til dine BI-applikationer

"At bygge et datavarehus er ikke længere udelukkende for IT-kodere og -kodere."

Tag føringen nu!

3. Metadata

I en typisk datavarehusarkitektur beskriver metadata datavarehusdatabasen og tilbyder en ramme for data. Det hjælper med at konstruere, bevare, håndtere og gøre brug af datavarehuset.

Der er to typer metadata i data warehousing:

• Tekniske metadata omfatter information, som kan bruges af udviklere og ledere, når de udfører lagerudviklings- og administrationsopgaver.
• Erhvervs metadata omfatter information, der giver et let forståeligt synspunkt på de data, der er lagret på lageret.

Metadatas rolle i et datavarehus

Metadata spiller en vigtig rolle for virksomheder og tekniske teams for at forstå de data, der findes på lageret og konvertere dem til information.

Dit datavarehus er ikke et projekt; det er en proces. For at gøre din implementering så effektiv som muligt, skal du have en virkelig agil tilgang, hvilket kræver en metadatadrevet datavarehusarkitektur.

Dette er en visuel tilgang til data warehousing, der udnytter metadata-berigede datamodeller til at drive alle aspekter af udviklingsprocessen, lige fra at dokumentere kildesystemer til at replikere skemaer i en fysisk database og facilitere datakortlægning fra kilde til destination.

Datavarehusskemaet er opsat på metadataniveau, hvilket betyder, at du ikke behøver at bekymre dig om kodekvalitet, og hvordan den kan klare store mængder data. Faktisk kan du administrere og kontrollere dine data uden at gå ind i koden.

Du kan også test datavarehusmodeller samtidigt før implementering og repliker dit skema i enhver førende database. En metadatadrevet tilgang fører til en iterativ udviklingskultur og fremtidssikrer din datavarehusimplementering, så du kan opdatere den eksisterende infrastruktur med de nye krav uden at forstyrre dit datavarehuss integritet og anvendelighed.

Sammen med automatiseringsmuligheder kan et metadatadrevet datavarehusdesign strømline design, udvikling og implementering, hvilket fører til en robust datavarehusimplementering.

4. Værktøjer til adgang til datavarehus

Et 0data warehouse bruger en database eller gruppe af databaser som grundlag. Datavarehusselskaber kan generelt ikke arbejde med databaser uden brug af værktøjer, medmindre de har databaseadministratorer til rådighed. Det er dog ikke tilfældet med alle forretningsenheder.

Dette er grunden til, at de bruger hjælp fra adskillige no-code data warehousing-værktøjer, såsom:

• Forespørgsels- og rapporteringsværktøjer hjælpe brugere med at producere virksomhedsrapporter til analyse, der kan være i form af regneark, beregninger eller interaktive billeder.
• Applikationsudviklingsværktøjer hjælpe med at skabe skræddersyede rapporter og præsentere dem i fortolkninger beregnet til rapporteringsformål.
• Data mining værktøjer til data warehousing systematisere proceduren for at identificere arrays og links i enorme mængder af data ved hjælp af banebrydende statistiske modelleringsmetoder.
• OLAP værktøjer hjælpe med at konstruere et multidimensionelt datavarehus og tillade analyse af virksomhedsdata fra adskillige synsvinkler.

5. Datavarehusbus

Den definerer datastrømmen i en datavarehusbusarkitektur og inkluderer en datamart. En datamart er et adgangsniveau, der giver brugerne mulighed for at overføre data. Det bruges også til at partitionere data, der er produceret til en bestemt brugergruppe.

6. Rapporteringslag for datavarehus

Rapporteringslaget i datavarehuset giver slutbrugerne adgang til BI-grænsefladen eller BI-databasearkitekturen. Formålet med rapporteringslaget i datavarehuset er at fungere som et dashboard til datavisualisering, oprette rapporter og udtage eventuelle nødvendige oplysninger.

Karakteristika for datavarehusdesign

Følgende er de vigtigste kendetegn ved data warehousing design, udvikling og bedste praksis:

Tema-fokuseret

Et datavarehusdesign bruger et bestemt tema. Det giver information om et emne snarere end en virksomheds drift. Disse temaer kan relateres til salg, annoncering, marketing og meget mere.

I stedet for at fokusere på forretningsdrift eller transaktioner, lægger data warehousing vægt på business intelligence (BI), det vil sige at vise og analysere data til beslutningstagning. Det giver også en ligetil og kortfattet fortolkning af et bestemt tema ved at eliminere data, som måske ikke er nyttige for beslutningstagere.

Unified

Ved hjælp af datavarehusmodellering forener og integrerer et datavarehusdesign data fra forskellige databaser på en kollektivt passende måde.

Det inkorporerer data fra forskellige kilder, såsom relationelle og ikke-relationelle databaser, flade filer, mainframes og cloud-baserede systemer. Desuden skal et datavarehus opretholde ensartet klassificering, layout og kodning for at lette effektiv dataanalyse.

Tidsvariation

I modsætning til andre driftssystemer gemmer datavarehuset centraliserede data fra en bestemt tidsperiode. Derfor identificerer datavarehuset de indsamlede data inden for en bestemt tidsperiode og giver indsigt fra tidligere perspektiv. Desuden tillader det ikke strukturen eller ændringen af ​​dataene, efter de er kommet ind på lageret.

Ikke-volatilitet

Ikke-volatilitet er en anden vigtig egenskab ved et datavarehus, hvilket betyder, at det ikke fjerner de primære data, når ny information indlæses. Desuden tillader den kun datalæsning og periodisk forfriskning for at give brugeren et komplet og opdateret billede.

Typer af datavarehusarkitektur

Arkitekturen af ​​et typisk datavarehus definerer arrangementet af data i forskellige databaser. For at udtrække værdifuld information fra rådata identificerer en moderne datavarehusstruktur den mest effektive teknik til at organisere og rense dataene.

Ved hjælp af en dimensionel model udtrækker og konverterer datavarehuset rådataene i opsamlingsområdet til en simpel forbrugsvarehusstruktur for at levere værdifuld business intelligence.

Desuden, i modsætning til en cloud datalager, kræver en traditionel datavarehusmodel lokale servere for at alle varehuskomponenter kan fungere.

Når du designer et virksomhedsdatavarehus, er der tre forskellige typer modeller at overveje:

Single-tier data warehouse

Kilde: InterviewBit

Strukturen af ​​en enkeltlags datavarehusarkitektur producerer et tæt sæt data og reducerer mængden af ​​de deponerede data.

Selvom det er fordelagtigt for at eliminere redundanser, er denne type lagerdesign ikke egnet til virksomheder med komplekse datakrav og talrige datastrømme. Det er her, multi-tier data warehouse-arkitekturer kommer ind, når de håndterer mere komplekse datastrømme.

To-lags datavarehus

Kilde: InterviewBit

Til sammenligning opdeler datastrukturen i en to-lags datavarehusmodel de håndgribelige datakilder fra selve varehuset. I modsætning til et enkeltlagsdesign bruger tolagsdesignet et system og en databaseserver.

Små organisationer, hvor en server bruges som datamarked, bruger typisk denne type datavarehusarkitektur. Selvom det er mere effektivt til datalagring og organisering, er to-lagsstrukturen ikke skalerbar. Desuden understøtter den kun et nominelt antal brugere.

Tre-lags datavarehus

Den trelagede datavarehusarkitekturtype er den mest almindelige type moderne DWH-design, da den producerer et velorganiseret dataflow fra rå information til værdifuld indsigt.

Det nederste niveau i datavarehusmodellen omfatter typisk databankserveren, der skaber et abstraktionslag på data fra adskillige kilder, som f.eks. transaktionsdatabanker, der bruges til front-end-brug.

Mellemlaget indeholder en Online analytisk behandling (OLAP) server. Dette niveau ændrer dataene til et mere passende arrangement til analyse og mangefacetteret sondering fra en brugers perspektiv. Da det inkluderer en OLAP-server forudbygget i arkitekturen, kan vi også kalde det det OLAP-fokuserede datavarehus.

Det tredje og øverste niveau er klientniveauet, som inkluderer værktøjerne og Application Programming Interface (API), der bruges til dataanalyse, forespørgsler og rapportering på højt niveau.

Men folk medtager næppe det 4. lag i datavarehusarkitekturen, da det ofte ikke anses for at være lige så integreret som de tre andre typer.

Lad os nu lære om hovedkomponenterne i et datavarehus (DWH), og hvordan de hjælper med at bygge og skalere et datavarehus i detaljer.

Design og start dit datavarehus fra bunden uden kodning

Tilmeld dig demo

Cloud-baseret datavarehusarkitektur

En cloud-baseret datavarehusarkitektur udnytter cloud computing-ressourcer til at gemme, administrere og analysere data til business intelligence og analyser. Grundlaget for dette datavarehus er cloud-infrastrukturen leveret af cloud-tjenesteudbydere som AWS (Amazon Web Services), Azure eller Google Cloud. Disse udbydere tilbyder on-demand ressourcer såsom computerkraft, lagring og netværk.

Her er hovedkomponenterne i den skybaserede datavarehusarkitektur:

1. Dataindtagelse: Den første komponent er en mekanisme til indlæsning af data fra forskellige kilder, herunder lokale systemer, databaser, tredjepartsapplikationer og eksterne datafeeds.
2. Datalagring: Dataene lagres i cloud data warehouse, som typisk bruger distribuerede og skalerbare lagersystemer. Valget af lagringsteknologi kan variere baseret på cloud-udbyderen og arkitekturen, med muligheder som Amazon S3, Azure Data Lake Storage eller Google Cloud Storage.
3. Beregn ressourcer: Cloud-baserede datavarehuse giver fleksible og skalerbare computerressourcer til at køre analytiske forespørgsler. Disse ressourcer kan leveres on-demand, så virksomheder kan justere processorkraft baseret på arbejdsbelastningskrav.
4. Auto-skalering: Cloud-baserede datavarehuse understøtter ofte automatisk skalering, hvilket gør det nemmere for virksomheder at justere dynamisk for at imødekomme kravene fra arbejdsbyrden.

Traditionelle vs. Cloud Data Warehouse-arkitekturmodeller

Mens traditionelle datavarehuse tilbyder fuld kontrol over hardware og dataplacering, kommer de ofte med højere forudgående omkostninger, begrænset skalerbarhed og langsommere implementeringstider. Cloud-datavarehuse giver på den anden side fordele i form af skalerbarhed, omkostningseffektivitet, global tilgængelighed og nem vedligeholdelse, med en afvejning af potentielt reduceret kontrol over dataplacering og opholdssted.

Valget mellem de to arkitekturer afhænger af en organisations specifikke behov, budget og præferencer. Her er et dybere kig på forskellene mellem de to:

Tilpasning af DW Architecture med iscenesættelsesområde og Data Marts

Du kan tilpasse din datavarehusarkitektur med et iscenesættelsesområde og datamarts. Med denne tilpasning kan du levere de rigtige data til de rigtige brugere, hvilket gør det mere effektivt til business intelligence og analyser.

Iscenesættelsesområde:

• Formål: Et iscenesættelsesområde er et mellemlagerrum inden for datavarehusarkitekturen, hvor rå eller minimalt behandlede data gemmes midlertidigt, før de indlæses i hoveddatavarehuset.
• Tilpasning: Du kan tilpasse iscenesættelsesområdet baseret på din organisations behov for dataintegration. For eksempel kan du designe iscenesættelsesområdet til at rumme datatransformation, datarensning og datavalideringsprocesser, der forbereder dataene til analyse.

Data Marts:

• Formål: Data marts er delmængder af et datavarehus, der er specifikt designet til at opfylde de analytiske behov hos forretningsafdelinger, funktioner eller brugergrupper. De indeholder præ-aggregerede og skræddersyede data til specifikke typer analyser.
• Tilpasning: For at tilpasse datavarehusarkitekturen med datamarts skal du designe og udfylde disse datamarts baseret på de unikke krav fra hver afdeling eller brugergruppe.

Opdag de agile bedste praksisser til at udvikle et datavarehus

Download hvidbog

Bedste praksis for datavarehusarkitektur

• Opret data warehouse modeller der er optimeret til informationssøgning i både dimensionelle, denormaliserede eller hybride tilgange.
• Vælg mellem en ETL eller en ELT tilgang til dataintegration.
• Vælg en enkelt tilgang til datavarehusdesign, såsom top-down eller bottom-up tilgang, og hold fast ved den.
• Hvis du bruger en ETL skal du altid rense og transformere data ved hjælp af et ETL-værktøj, før du indlæser dataene til datavarehuset.

Foto taget fra medium.com/@vishwan/data-preparation-etl-in-business-performance-37de0e8ef632

• Opret en automatiseret datarensningsproces, hvor alle data er ensartet renset før indlæsning.
• Tillad deling af metadata mellem forskellige komponenter i datavarehuset for en jævn udtræksproces.
• Brug en agil tilgang i stedet for en fast tilgang til at bygge dit datavarehus.
• Sørg altid for, at data er korrekt integreret og ikke bare konsolideret når den flyttes fra datalagrene til datavarehuset. Dette ville kræve 3NF-normalisering af datamodeller.

Automatisering af datavarehusdesign 

Automatisering af data warehouse design kan kom i gang med udviklingen af ​​dit datavarehus. Det er vigtigt at få din tilgang rigtig.

Først skal du identificere, hvor dine kritiske forretningsdata findes, og hvilke data der er relevante for dine BI-initiativer. Opret derefter en standardiseret metadataramme, der giver kritisk kontekst for disse data på datamodellering fase.

En sådan ramme ville matche din datavarehusmodel til kildesystemet og sikre passende konstruktion af relationer mellem entiteter med korrekt definerede primære og fremmede nøgler. Det ville også etablere korrekte tabelsammenføjninger og nøjagtigt tildele entitetsrelationstyper.

Du skal også have processer på plads, der giver dig mulighed for at integrere nye kilder og andre ændringer i din kildedatamodel og ominstallere den. At tage en iterativ tilgang vil give et mere detaljeret syn på de data, der leveres til BI-formål og materialiserede visninger.

Du kan vedtage en 3NF eller dimensionel modellering tilgang, afhængigt af dine BI-krav. Sidstnævnte er bedre, da det vil hjælpe dig med at skabe en strømlinet, denormaliseret struktur til din datavarehusmodel.

Mens du er i gang, er her nogle vigtige tips, som du bør huske på:

• Oprethold et ensartet korn i dimensionelle datamodeller
• Anvend den korrekte SCD-håndteringsteknik på dine dimensionelle attributter
• Strømlin indlæsning af faktatabel ved hjælp af en metadatadrevet tilgang
• Sæt processer på plads for at håndtere tidligt ankomne fakta

Endelig kan teammedlemmer teste datakvalitet og integriteten af ​​datamodeller, før de implementeres på måldatabasen. At have en automatiseret datamodelverifikation værktøj kan give betydelige tidsbesparelser.

Hvis du følger disse bedste fremgangsmåder, når du automatiserer skemamodellering, hjælper det dig med at opdatere din model problemfrit og udbrede ændringer på tværs af dine datapipelines.

Det næste trin i designprocessen for datavarehus er at vælge den rigtige datavarehusarkitektur.

Byg dit datavarehus med Astera DW Builder

Astera DW Builder er en end-to-end data warehousing løsning, der automatiserer design og implementering af et data warehouse i et kodefrit miljø.

Den bruger en meta-drevet tilgang, der gør det muligt for brugere at manipulere data ved hjælp af et omfattende sæt af indbyggede transformationer uden kompleks ETL-scripting eller SQL-scripting.

Lær mere om den bedste datavarehusarkitektur til rapportering.

Reducer udviklingstiden for datavarehus med op til 80 %