Data Vault 2.0-metoden tager ikke kun modelleringsteknik, men giver en hel metode til alle Datalagerprojekter. Indellient ser Datahvelvmodelleringen som en meget levedygtig tilgang til at imødekomme behovene i datalagringsprojekter, hvor både historisk sporing og revision er to vigtige faktorer.

i mange år har business intelligence (BI) projekter og fortsætter med at fungere under en vandfaldsmodel. Det er defineret af en lang strakt sekvens af hver fase, der kræver en udtømmende liste over forhåndskrav, et komplet datamodeldesign efterfulgt af kodificering af alle hårde og bløde forretningsregler i ETL-processer. Visualiseringslaget er sekventielt bygget og præsenteret for slutbrugere til afmelding – måneder eller endda år fra den oprindelige startdato.

temmelig ofte ser vi også hold vedtage en” reduceret rækkevidde ” – version af vandfald, der sigter mod at bryde store BI-initiativer i mindre projekter. Selvom dette hjælper med at reducere den samlede kompleksitet, denne tilgang, når den anvendes på BI, er stadig ret risikabel på grund af to primære bekymringer:

  • forretningskravene ændrer sig nu hurtigere end evnen til at levere;
  • og budgetindehavere er uvillige til at bruge på langsigtede projekter uden materialiserede kortsigtede resultater.

ovenstående grunde er, hvorfor vi har set et skift i projektmetoder fra vandfald til den iterative adræt tilgang af agile – som genkender og giver nogle svar på disse problemer.

inden for Data analytics-domænet adresserer agile alene ikke de væsentlige udfordringer, vi støder på på de mere detaljerede niveauer af datalagring eller BI-projekter. Disse omfatter:

  • iterere over datamodellering
  • minimering af refactoring
  • design af ETL-eller ELT-rutiner, der muliggør hurtig reaktion på ændringer i forretningslogik eller nye tilføjelser af data
  • en tilgang til indsamling af forretningskrav, der nøje vil binde sig til det input, der kræves til designbeslutninger

som reaktion på disse udfordringer, Daniel linstedt, forfatter til opbygning af skalerbart datalager med datahvelv 2.0, definerer en metode, der fokuserer på at få mest muligt ud af agile praksis med andre gennemprøvede discipliner og teknikker til at levere, hvad der synes at være den mest iterative tilgang til BI endnu.

introduktion af Datahvelv

i modsætning til hvad man tror, er Datahvelv (DV) ikke kun en modelleringsteknik, det er en hel metode til datalagerprojekter. Det binder sammen aspekter af agile, indsamling af STRÅLEKRAV, CMMI, TKVM, seks Sigma og Datahvelvmodellering for at definere en tilgang, der er målrettet mod at forbedre både hastigheden og kvaliteten af BI-projekter. Jeg henviser til det som “guided missile approach”, da det fremmer både tilpasning og nøjagtighed.

DV omfatter også agile metoder til estimering af projekt og agile opgavestørrelser for at bestemme den traditionelt oversete kompleksitet eller arbejdsindsats, der er involveret på tværs af de fælles komponenter. På de lavere niveauer præsenterer den også en meget kortfattet og iterativ tilgang til at tackle fælles tekniske leverancer (inden for BI-verdenen) med nye eller skiftende funktionsanmodninger. Disse inkluderer gennemtænkte, gentagelige, trinvise og agile baserede processer til at udføre hyppige opgaver.

disse opgaver inkluderer (men er ikke begrænset til) tilføjelse af dataattributter, skiver, nye kilder, forstørrede kilder, historisk sporing, forældede kilder og ændringer i kildestrukturen i både ETL-og Modelleringsfasen.

DV-modellen er i en nøddeskal et lag, der eksisterer mellem regelmæssig dimensionel modellering (OLAP, Stjerneskema) og iscenesættelse, der giver skalering med voksende forretningskrav og tjener til at nedbryde kompleksiteter af både modellering og ETL. Det består af hubs (forretningsenheder), links (relationer) og satellitter (beskrivende attributter), som er modelleret et sted mellem 3NF og stjerneskemaet. Modellen er placeret inde i dataintegrationslaget i datalageret, ofte benævnt rå Datahvelvet, og bruges effektivt i kombination med Kimballs model.

Tip: Hvis du er interesseret i at forstå modellen og dens understregningsregler, foreslår jeg at tage en kopi af Dan ‘ s bog nævnt ovenfor.

Datahvelv 2.0 fordele

her er en oversigt over nogle vigtige fordele ved Data Vault 2.0-tilgangen:

  • det antager det værst tænkelige scenario for datamodelleringsforhold. N: m forhold mellem forretningsobjekter for at eliminere behovet for opdateringer, hvis en 1:M bliver til en M:M. derved kræver stort set intet yderligere arbejde inden for Datahvelv, når graden af forhold ændres.
  • det er designet til historisk sporing af alle aspekter af datarelationer og attributter samt hvor dataene hentes fra over tid. Satellitter, der ligner dimensioner, fungerer på samme måde som SCD Type 2.
  • fremsætter et sæt designprincipper & strukturer til at øge Historisk sporingsydelse inden for hvælvet (PiT og Bro). Data Vault-modellen er fleksibel nok til at vedtage disse strukturer på ethvert tidspunkt inden for den iterative modelleringsproces og kræver ikke avanceret planlægning.
  • designet til logisk at adskille rum, der indeholder rå vs. ændrede data. Rå data vault er grundlaget for data, der kan revideres til kildesystemer, og business vault giver et sted for strømbrugere, der har brug for adgang til data et trin ned fra informationsmart.
  • adskiller bløde og hårde forretningsregler i forskellige dele af dataintegrationen. Dette håndhæver genanvendelighed af data på tværs af flere slutanvendelser. For eksempel hentes rådata kun en gang inden for Datahvelvet (mindre genintegrering i iscenesættelse) og kan fodres flere gange til nedstrøms behov.
  • for hver agile iteration er Data Vault-modellen, der gemmer al den historiske sporing af data, let udvidelig uden at skulle bekymre sig om at miste Historiske data. Historisk sporing gemmes også uafhængigt af den dimensionelle model.
  • Data Vault 2.0 går ind for hash-nøgleimplementering af forretningsnøgler for at reducere opslag og derfor øge indlæsningsparalleliseringen. Dette resulterer i mindre sekventielle belastningsafhængigheder.
  • Rådatahvelvet er designet til at være helt auditabelt.
  • som helhed er behandlingen involveret i at gå fra iscenesættelse til Stjerneskema & OLAP gjort meget mere glat & iterativ med Datahvelv.
  • det giver en meget gennemtænkt tilgang til at kombinere data med flere forskellige forretningsnøgler fra heterogene datakilder (et almindeligt problem med at integrere data i lageret på tværs af flere kildesystemer). Forretningsnøgler er ikke altid 1: 1 eller i samme format.
  • modelleringsmentaliteten “just in time”er et godt match med den smidige tilgang.

ulemperne

mens der er mange fordele ved Data Vault, har den også sine mangler, såsom:

  • Datahvelv er i det væsentlige et lag mellem information mart / star-skemaet og iscenesættelse. Der er nogle ekstra omkostninger, der følger med at udvikle dette lag både med hensyn til ETL-udvikling og modellering. Hvis projektet er i lille skala, eller projektets levetid er kortvarig, er det måske ikke værd at forfølge en Datahvelvmodel.
  • en af de vigtigste drivende faktorer bag brug af Data Vault er til både revision og historisk sporing formål. Hvis ingen af disse er vigtige for dig eller din organisation, kan det være svært at spise den overhead, der kræves for at introducere et andet lag i din modellering. Imidlertid, taler fra langsigtede krav, det kan være en værdifuld investering på forhånd.
  • Datahvelv repræsenterer en nedbrudt tilgang til relationer, forretningsnøgler og attributter, og derfor er antallet af tabeller, der oprettes, højt sammenlignet med denormaliserede strukturer såsom stjerneskema. Imidlertid, overvej, at Data Vault komplimenterer stjerneskema, så denne sammenligning er kun til kontrasterende formål. Af denne grund kræves mange joinforbindelser for at se data inden for DV.
  • på tidspunktet for at skrive dette – dv ressourcer er begrænsede. Komplekse projekter, der bruger DV 2.0, er ikke udbredt information.
  • modelleringsmetoden kan generelt være meget ukonventionel for dem, der har arbejdet under Kimball og (mindre) Inmons modeller.

Skal Du Forfølge Data Vault?

svaret afhænger af nogle få variabler.

vi ser datahvelvmodelleringen som en meget levedygtig tilgang til at imødekomme behovene i datalagringsprojekter, hvor både historisk sporing og revision er to vigtige faktorer.

hvis relationer på tværs af forretningsenheder konstant udvikler sig i dine data (eksempel 1:M til M:M ), forenkler Data Vault indfangningen af disse relationer og giver dig mulighed for at fokusere mere på at levere reel værdi.

hvis din organisation planlægger at lagre PII-data på lageret og er underlagt GDPR, HIPPA eller andre regler, hjælper Data Vault med datarevisioner og sporbarhed.

det vil være vigtigt at tage både de fordele og ulemper, der er anført ovenfor, for at hjælpe med at vælge, om en Data Vault-tilgang er fordelagtig for din brugssag.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.

lg