Å utvikle et lager er en lang og seriøs oppgave.
Mye i et prosjekts levetid avhenger av hvor godt objektmodellen og grunnstrukturen er gjennomtenkt i starten.
Den allment aksepterte tilnærmingen har vært og er fortsatt forskjellige varianter av å kombinere stjerneskjemaet med tredje normalform. Som regel, i henhold til prinsippet: innledende data - 3NF, utstillingsvinduer - stjerne. Denne tilnærmingen, tidstestet og støttet av en stor mengde forskning, er det første (og noen ganger det eneste) som kommer til hjernen til en erfaren DWH-spesialist når han tenker på hvordan et analytisk depot skal se ut.
På den annen side har virksomheten generelt og kundenes krav spesielt en tendens til å endre seg raskt, og data har en tendens til å vokse både "i dybden" og "i bredden". Og det er her den største ulempen med en stjerne vises - begrenset fleksibilitet.
Og hvis du plutselig er i ditt stille og koselige liv som DWH-utvikler:
- oppgaven oppsto "å gjøre i det minste noe raskt, og så får vi se";
- et raskt utviklende prosjekt dukket opp, med tilkobling av nye kilder og omarbeiding av forretningsmodellen minst en gang i uken;
- det har dukket opp en kunde som ikke har noen anelse om hvordan systemet skal se ut og hvilke funksjoner det til syvende og sist skal utføre, men som er klar til å eksperimentere og konsekvent foredle ønsket resultat samtidig som man konsekvent kommer nærmere det;
- Prosjektlederen kom innom med den gode nyheten: "Og nå har vi smidig!"
Eller hvis du bare er interessert i å finne ut hvordan du ellers kan bygge lagerlokaler - velkommen til kuttet!
Hva betyr "fleksibilitet"?
La oss først definere hvilke egenskaper et system må ha for å bli kalt "fleksibelt".
Separat er det verdt å nevne at de beskrevne egenskapene skal forholde seg spesifikt til system, ikke til prosess dens utvikling. Derfor, hvis du ønsker å lese om Agile som utviklingsmetodikk, er det bedre å lese andre artikler. For eksempel, akkurat der, på Habré, er det mye interessant materiale (som и Og ).
Dette betyr ikke at utviklingsprosessen og strukturen til datavarehuset er helt uten sammenheng. Samlet sett burde det være betydelig enklere å utvikle et Agile-depot for en smidig arkitektur. Imidlertid er det i praksis oftere alternativer med Agile utvikling av den klassiske DWH i henhold til Kimbal og DataVault - ifølge Waterfall, enn lykkelige tilfeldigheter av fleksibilitet i sine to former på ett prosjekt.
Så, hvilke muligheter bør fleksibel lagring ha? Det er tre punkter her:
- Tidlig levering og rask behandling - Dette betyr at ideelt sett bør det første forretningsresultatet (for eksempel de første arbeidsrapportene) innhentes så tidlig som mulig, det vil si selv før hele systemet er ferdig designet og implementert. Dessuten bør hver påfølgende revisjon også ta så kort tid som mulig.
- Iterativ foredling - Dette betyr at hver påfølgende forbedring ideelt sett ikke skal påvirke funksjonaliteten som allerede fungerer. Det er dette øyeblikket som ofte blir det største marerittet på store prosjekter – før eller siden begynner enkeltobjekter å få så mange forbindelser at det blir lettere å fullstendig gjenta logikken i en kopi i nærheten enn å legge til et felt i en eksisterende tabell. Og hvis du er overrasket over at å analysere effekten av forbedringer på eksisterende objekter kan ta mer tid enn selve forbedringene, har du mest sannsynlig ennå ikke jobbet med store datavarehus innen bank eller telekom.
- Konstant tilpasning til endrede forretningskrav - den overordnede objektstrukturen bør utformes ikke bare under hensyntagen til mulig utvidelse, men med en forventning om at retningen for denne neste utvidelsen ikke engang kunne drømmes om på designstadiet.
Og ja, det er mulig å oppfylle alle disse kravene i ett system (selvfølgelig i visse tilfeller og med noen forbehold).
Nedenfor vil jeg vurdere to av de mest populære smidige designmetodene for datavarehus - Ankermodell и Datahvelv. Utenfor parentesene er slike utmerkede teknikker som for eksempel EAV, 6NF (i sin rene form) og alt relatert til NoSQL-løsninger - ikke fordi de på en eller annen måte er dårligere, og ikke engang fordi artikkelen i dette tilfellet vil true med å anskaffe volumet til den gjennomsnittlige avhandlingen. Det er bare at alt dette er relatert til løsninger av en litt annen klasse - enten til teknikker som du kan bruke i spesifikke tilfeller, uavhengig av den overordnede arkitekturen til prosjektet ditt (som EAV), eller til globalt andre informasjonslagringsparadigmer (som grafdatabaser) og andre alternativer NoSQL).
Problemer med den "klassiske" tilnærmingen og deres løsninger i fleksible metoder
Med "klassisk" tilnærming mener jeg den gode gamle stjernen (uavhengig av den spesifikke implementeringen av de underliggende lagene, må tilhengerne av Kimball, Inmon og CDM tilgi meg).
1. Rigid kardinalitet av forbindelser
Denne modellen er basert på en klar inndeling av data i Dimensjon и fakta. Og dette, pokker, er logisk - tross alt kommer dataanalyse i det overveldende flertallet av tilfeller ned til analyse av visse numeriske indikatorer (fakta) i visse seksjoner (dimensjoner).
I dette tilfellet etableres forbindelser mellom objekter i form av relasjoner mellom tabeller ved hjelp av en fremmednøkkel. Dette ser ganske naturlig ut, men fører umiddelbart til den første begrensning av fleksibilitet - streng definisjon av kardinaliteten til forbindelser.
Dette betyr at på tabelldesignstadiet må du nøyaktig bestemme for hvert par relaterte objekter om de kan relatere så mange-til-mange, eller bare 1-til-mange, og "i hvilken retning". Dette bestemmer direkte hvilken tabell som skal ha primærnøkkelen og hvilken som skal ha fremmednøkkelen. Å endre denne holdningen når nye krav kommer inn vil mest sannsynlig føre til en omarbeiding av basen.
For eksempel, når du designet "kontantkvittering" -objektet, la du, basert på edene fra salgsavdelingen, ned muligheten for handling én kampanje for flere sjekkeposisjoner (men ikke omvendt):
Og etter en tid introduserte kolleger en ny markedsføringsstrategi der de kan handle på samme posisjon flere kampanjer samtidig. Og nå må du endre tabellene ved å separere forholdet i et separat objekt.
(Alle avledede objekter der opprykkssjekken er slått sammen må nå også forbedres).
Relasjoner i datahvelv og ankermodell
Å unngå denne situasjonen viste seg å være ganske enkelt: du trenger ikke stole på salgsavdelingen for å gjøre dette. alle tilkoblinger er i utgangspunktet lagret i separate tabeller og behandle det som mange-til-mange.
Denne tilnærmingen ble foreslått Dan Linstedt som en del av paradigmet Datahvelv og fullt støttet Lars Rönnbäck в Ankermodell.
Som et resultat får vi det første karakteristiske trekk ved fleksible metoder:
Relasjoner mellom objekter lagres ikke i attributter til overordnede enheter, men er en egen type objekt.
В Datahvelv slike koblingstabeller kalles linkog i Ankermodell - Slips. Ved første øyekast er de veldig like, selv om forskjellene deres ikke slutter med navnet (som vil bli diskutert nedenfor). I begge arkitekturer kan lenketabeller lenke et hvilket som helst antall enheter (ikke nødvendigvis 2).
Denne redundansen gir ved første øyekast betydelig fleksibilitet for modifikasjoner. En slik struktur blir tolerant ikke bare for endringer i kardinaliteten til eksisterende lenker, men også for tillegg av nye - hvis nå en sjekkposisjon også har en lenke til kassereren som brøt gjennom den, vil utseendet til en slik kobling ganske enkelt bli et tillegg over eksisterende tabeller uten å påvirke eksisterende objekter og prosesser.
2. Dataduplisering
Det andre problemet løst av fleksible arkitekturer er mindre åpenbart og er iboende i utgangspunktet. SCD2 type målinger (sakte skiftende dimensjoner av den andre typen), men ikke bare dem.
I et klassisk lager er en dimensjon vanligvis en tabell som inneholder en surrogatnøkkel (som en PK) og et sett med forretningsnøkler og attributter i separate kolonner.
Hvis en dimensjon støtter versjonering, legges grenser for versjonsgyldighet til standardsettet med felt, og flere versjoner vises i depotet for én rad i kilden (en for hver endring i versjonsattributter).
Hvis en dimensjon inneholder minst ett versjonsattributt som ofte endres, vil antallet versjoner av en slik dimensjon være imponerende (selv om de resterende attributtene ikke er versjonert eller aldri endres), og hvis det er flere slike attributter, kan antall versjoner vokse eksponentielt fra antallet deres. Denne dimensjonen kan ta opp en betydelig mengde diskplass, selv om mye av dataene den lagrer ganske enkelt er duplikater av uforanderlige attributtverdier fra andre rader.
Samtidig er det også veldig ofte brukt denormalisering — noen attributter er med vilje lagret som en verdi, og ikke som en kobling til en oppslagsbok eller en annen dimensjon. Denne tilnærmingen gjør datatilgangen raskere, og reduserer antallet sammenføyninger når du får tilgang til en dimensjon.
Vanligvis fører dette til samme informasjon lagres samtidig flere steder. For eksempel kan informasjon om bostedsregionen og klientens kategori lagres samtidig i «Kunde»-dimensjonene og «Kjøp», «Levering» og «Call Center Calls»-fakta, samt i «Client - Client Manager ” lenketabell.
Generelt gjelder det ovenfor beskrevne for vanlige (ikke-versjonerte) dimensjoner, men i versjonerte dimensjoner kan de ha en annen skala: fremveksten av en ny versjon av et objekt (spesielt i ettertid) fører ikke bare til oppdatering av alle relaterte tabeller, men til det overlappende utseendet til nye versjoner av relaterte objekter - når tabell 1 brukes til å bygge tabell 2, og tabell 2 brukes til å bygge tabell 3, etc. Selv om ikke en eneste attributt i tabell 1 er involvert i konstruksjonen av tabell 3 (og andre attributter i tabell 2 hentet fra andre kilder er involvert), vil versjonering av denne konstruksjonen i det minste føre til ekstra overhead, og maksimalt til ekstra versjoner i tabell 3. som ikke har noe med det å gjøre i det hele tatt, og lenger ned i kjeden.
3. Ikke-lineær kompleksitet av omarbeiding
Samtidig øker hver ny butikkfront som er bygget på grunnlag av en annen, antallet steder hvor data kan "avvike" når det gjøres endringer i ETL. Dette fører igjen til en økning i kompleksiteten (og varigheten) av hver påfølgende revisjon.
Hvis ovenstående beskriver systemer med sjelden modifiserte ETL-prosesser, kan du leve i et slikt paradigme - du trenger bare å sørge for at nye modifikasjoner er riktig gjort på alle relaterte objekter. Hvis revisjoner forekommer ofte, øker sannsynligheten for å "mangle" flere tilkoblinger ved et uhell.
Hvis vi i tillegg tar i betraktning at "versjonsbasert" ETL er betydelig mer komplisert enn "ikke-versjonsbasert", blir det ganske vanskelig å unngå feil ved hyppig oppdatering av hele denne funksjonen.
Lagring av objekter og attributter i Data Vault og Anchor Model
Tilnærmingen foreslått av forfatterne av fleksible arkitekturer kan formuleres som følger:
Det er nødvendig å skille det som endres fra det som forblir det samme. Det vil si, lagre nøkler atskilt fra attributter.
Man skal imidlertid ikke forvirre ikke versjonert attributt med uendret: den første lagrer ikke historikken for endringene, men kan endres (for eksempel når du retter en inndatafeil eller mottar nye data); den andre endres aldri.
Synspunktene er forskjellige på hva som kan anses som uforanderlig i Data Vault og Anchor Model.
Fra et arkitektonisk synspunkt Datahvelv, kan anses som uendret hele settet med nøkler - naturlig (TIN til organisasjonen, produktkode i kildesystemet osv.) og surrogat. I dette tilfellet kan de gjenværende attributtene deles inn i grupper i henhold til kilden og/eller hyppigheten av endringer og Oppretthold en egen tabell for hver gruppe med et uavhengig sett med versjoner.
I paradigmet Ankermodell anses som uendret eneste surrogatnøkkel essens. Alt annet (inkludert naturlige nøkler) er bare et spesielt tilfelle av attributtene. Hvori alle attributter er uavhengige av hverandre som standard, så for hver attributt a separat bord.
В Datahvelv tabeller som inneholder enhetsnøkler kalles Hubami. Huber inneholder alltid et fast sett med felt:
- Naturlige enhetsnøkler
- Surrogatnøkkel
- Link til kilde
- Registrer tilleggstid
Innlegg i Hubs aldri endre og har ingen versjoner. Eksternt er huber veldig lik ID-karttypetabeller som brukes i enkelte systemer for å generere surrogater, men det anbefales å bruke en hash fra et sett med forretningsnøkler som surrogater i Data Vault. Denne tilnærmingen forenkler innlasting av relasjoner og attributter fra kilder (du trenger ikke å bli med i navet for å få en surrogat, du trenger bare å beregne hashen til en naturlig nøkkel), men kan forårsake andre problemer (relatert for eksempel til kollisjoner , store og små bokstaver og ikke-utskrivbare tegn i strengnøkler, etc. .p.), derfor er det ikke generelt akseptert.
Alle andre enhetsattributter er lagret i spesielle tabeller kalt Satellitter. En hub kan ha flere satellitter som lagrer forskjellige sett med attributter.
Fordelingen av attributter mellom satellitter skjer i henhold til prinsippet felles endring - i en satellitt kan ikke-versjonsbaserte attributter lagres (for eksempel fødselsdato og SNILS for en person), i en annen - sjeldent endrede versjoner (for eksempel etternavn og passnummer), i den tredje - ofte skiftende (for eksempel leveringsadresse, kategori, dato for siste bestilling osv.). I dette tilfellet utføres versjonskontroll på nivået til individuelle satellitter, og ikke enheten som helhet, så det er tilrådelig å distribuere attributter slik at skjæringspunktet mellom versjoner innenfor en satellitt er minimal (noe som reduserer det totale antallet lagrede versjoner ).
Dessuten, for å optimere datainnlastingsprosessen, er attributter hentet fra ulike kilder ofte inkludert i individuelle satellitter.
Satellitter kommuniserer med Hub via fremmednøkkel (som tilsvarer 1-til-mange kardinalitet). Dette betyr at flere attributtverdier (for eksempel flere kontakttelefonnumre for én klient) støttes av denne "standard" arkitekturen.
В Ankermodell tabeller som lagrer nøkler kalles Ankre. Og de beholder:
- Bare surrogatnøkler
- Link til kilde
- Registrer tilleggstid
Naturlige nøkler fra ankermodellens synspunkt vurderes vanlige attributter. Dette alternativet kan virke vanskeligere å forstå, men det gir mye større rom for å identifisere objektet.
For eksempel, hvis data om samme enhet kan komme fra forskjellige systemer, som hver bruker sin egen naturlige nøkkel. I Data Vault kan dette føre til ganske tungvinte strukturer av flere huber (en per kilde + en samlende masterversjon), mens i Anchor-modellen faller den naturlige nøkkelen til hver kilde inn i sin egen attributt og kan brukes ved lasting uavhengig av alle de andre.
Men det er også ett lumsk poeng her: hvis attributter fra forskjellige systemer kombineres i en enhet, er det mest sannsynlig noen regler for "liming", hvorved systemet må forstå at poster fra forskjellige kilder tilsvarer én forekomst av enheten.
В Datahvelv disse reglene vil mest sannsynlig bestemme formasjonen "surrogathub" for hovedenheten og ikke på noen måte påvirke Hubs som lagrer naturlige kildenøkler og deres originale attributter. Hvis sammenslåingsreglene på et tidspunkt endres (eller attributtene som den utføres med oppdateres), vil det være nok å formatere surrogathubene.
В Ankermodell en slik enhet vil mest sannsynlig bli lagret i det eneste ankeret. Dette betyr at alle attributter, uansett hvilken kilde de kommer fra, vil være bundet til samme surrogat. Å skille feilaktig sammenslåtte poster og generelt overvåke relevansen av sammenslåing i et slikt system kan være mye vanskeligere, spesielt hvis reglene er ganske komplekse og endres ofte, og den samme egenskapen kan fås fra forskjellige kilder (selv om det absolutt er mulig, siden hver attributtversjon beholder en lenke til kilden).
I alle fall, hvis systemet ditt skal implementere funksjonaliteten deduplisering, sammenslåing av poster og andre MDM-elementer, er det verdt å være spesielt oppmerksom på aspektene ved lagring av naturlige nøkler i smidige metoder. Det er sannsynlig at den bulkere Data Vault-designen plutselig vil være tryggere når det gjelder sammenslåingsfeil.
Ankermodell gir også en ekstra objekttype kalt Knute det er egentlig spesielt degenerert type anker, som bare kan inneholde ett attributt. Nodene er ment å brukes til å lagre flate kataloger (for eksempel kjønn, sivilstatus, kundeservicekategori, etc.). I motsetning til ankeret, knuten har ingen tilknyttede attributttabeller, og dens eneste attributt (navn) er alltid lagret i samme tabell med nøkkelen. Noder er koblet til Anchors med tie-tabeller (Tie) på samme måte som Anchors er koblet til hverandre.
Det er ingen klar mening om bruken av noder. For eksempel, , som aktivt fremmer bruken av ankermodellen i Russland, mener (ikke urimelig) at det for ikke en eneste oppslagsbok kan fastslås med sikkerhet at det alltid vil være statisk og enkeltnivå, så det er bedre å umiddelbart bruke et fullverdig anker for alle objekter.
En annen viktig forskjell mellom Data Vault og Anchor-modellen er tilgjengeligheten attributter til forbindelser:
В Datahvelv Lenker er de samme fullverdige objektene som Hubs, og kan ha egne attributter. I Ankermodell Lenker brukes kun til å koble sammen ankere og kan ikke ha sine egne egenskaper. Denne forskjellen resulterer i betydelig forskjellige modelleringsmetoder fakta, som vil bli diskutert videre.
Faktalagring
Før dette snakket vi hovedsakelig om målemodellering. Fakta er litt mindre klare.
В Datahvelv et typisk objekt for å lagre fakta er Link, i hvis satellitter virkelige indikatorer er lagt til.
Denne tilnærmingen virker intuitiv. Den gir enkel tilgang til de analyserte indikatorene og ligner generelt på en tradisjonell faktatabell (bare indikatorene lagres ikke i selve tabellen, men i "nabotabellen"). Men det er også fallgruver: en av de typiske modifikasjonene av modellen - utvidelse av faktanøkkelen - nødvendiggjør legge til en ny fremmednøkkel til Link. Og dette "bryter" igjen modulariteten og forårsaker potensielt behov for modifikasjoner av andre objekter.
В Ankermodell En forbindelse kan ikke ha sine egne attributter, så denne tilnærmingen vil ikke fungere - absolutt alle attributter og indikatorer må være knyttet til ett spesifikt anker. Konklusjonen fra dette er enkel - Hvert faktum trenger også sitt eget anker. For noe av det vi er vant til å oppfatte som fakta, kan dette se naturlig ut - for eksempel kan et kjøp være perfekt redusert til objektet "bestilling" eller "kvittering", besøk på et nettsted til en økt, etc. Men det er også fakta som det ikke er så lett å finne et så naturlig "bærerobjekt" for - for eksempel rester av varer i varehus på begynnelsen av hver dag.
Følgelig oppstår ikke problemer med modularitet ved utvidelse av en faktanøkkel i ankermodellen (det er nok å bare legge til et nytt forhold til det tilsvarende ankeret), men å designe en modell for å vise fakta er mindre entydig; "kunstige" ankre kan vises som viser forretningsobjektmodellen på en uklar måte.
Hvordan fleksibilitet oppnås
Den resulterende konstruksjonen i begge tilfeller inneholder betydelig flere bordenn tradisjonell måling. Men det kan ta betydelig mindre diskplass med samme sett med versjonerte attributter som den tradisjonelle dimensjonen. Naturligvis er det ingen magi her - det handler om normalisering. Ved å distribuere attributter på tvers av satellitter (i datahvelvet) eller individuelle tabeller (ankermodell), reduserer (eller eliminerer vi fullstendig) duplisering av verdier for noen attributter når du endrer andre.
For Datahvelv gevinstene vil avhenge av fordelingen av attributter blant satellittene, og for Ankermodell — er nesten direkte proporsjonal med gjennomsnittlig antall versjoner per måleobjekt.
Plassbesparelser er imidlertid en viktig, men ikke den viktigste, fordelen ved å lagre attributter separat. Sammen med separat lagring av relasjoner gjør denne tilnærmingen butikken modulær design. Det betyr at å legge til både individuelle attributter og hele nye fagområder i en slik modell ser ut overbygning over et eksisterende sett med objekter uten å endre dem. Og det er nettopp dette som gjør de beskrevne metodikkene fleksible.
Dette ligner også overgangen fra brikkeproduksjon til masseproduksjon - hvis i den tradisjonelle tilnærmingen hver tabell i modellen er unik og krever spesiell oppmerksomhet, så er det i fleksible metoder allerede et sett med standard "deler". På den ene siden er det flere tabeller, og prosessene med å laste og hente data bør se mer kompliserte ut. På den annen side blir de typisk. Det betyr at det kan være det automatisert og metadatadrevet. Spørsmålet "hvordan skal vi legge det?", som svaret kan ta en betydelig del av arbeidet med å designe forbedringer på, er nå rett og slett ikke verdt det (samt spørsmålet om effekten av å endre modellen på arbeidsprosesser ).
Dette betyr ikke at det ikke er behov for analytikere i et slikt system i det hele tatt - noen må fortsatt jobbe gjennom settet med objekter med attributter og finne ut hvor og hvordan de skal laste det hele. Men mengden arbeid, samt sannsynligheten og kostnadene for en feil, er betydelig redusert. Både på analysestadiet og under utviklingen av ETL, som i en betydelig del kan reduseres til redigering av metadata.
Mørk side
Alt det ovennevnte gjør begge tilnærmingene virkelig fleksible, teknologisk avanserte og egnet for iterativ forbedring. Selvfølgelig er det også en "tønne i salven", som jeg tror du allerede kan gjette deg til.
Datanedbryting, som ligger til grunn for modulariteten til fleksible arkitekturer, fører til en økning i antall tabeller og følgelig, overhead å bli med ved prøvetaking. For ganske enkelt å få alle egenskapene til en dimensjon, i en klassisk butikk er ett utvalg tilstrekkelig, men en fleksibel arkitektur vil kreve en hel serie sammenføyninger. Dessuten, hvis alle disse sammenføyningene for rapporter kan skrives på forhånd, vil analytikere som er vant til å skrive SQL for hånd lide dobbelt.
Det er flere fakta som gjør denne situasjonen lettere:
Når du arbeider med store dimensjoner, brukes nesten aldri alle dens attributter samtidig. Det betyr at det kan være færre sammenføyninger enn det ser ut ved første øyekast på modellen. Data Vault kan også ta hensyn til den forventede frekvensen for deling når attributter tildeles satellitter. Samtidig er Hubs eller Anchors i seg selv først og fremst nødvendig for å generere og kartlegge surrogater på lastestadiet og brukes sjelden i spørringer (dette gjelder spesielt for Anchors).
Alle sammenføyninger skjer med nøkkel. I tillegg reduserer en mer "komprimert" måte å lagre data på kostnadene ved å skanne tabeller der det er nødvendig (for eksempel ved filtrering etter attributtverdi). Dette kan føre til at sampling fra en normalisert database med en haug med sammenføyninger vil være enda raskere enn å skanne én tung dimensjon med mange versjoner per rad.
For eksempel her inne Artikkelen inneholder en detaljert komparativ test av ytelsen til Anchor-modellen med et utvalg fra én tabell.
Mye avhenger av motoren. Mange moderne plattformer har interne sammenføyningsoptimaliseringsmekanismer. For eksempel kan MS SQL og Oracle "hoppe over" sammenføyninger til tabeller hvis dataene deres ikke brukes noe sted bortsett fra andre sammenføyninger og ikke påvirker det endelige valget (eliminering av tabell/join), og MPP Vertica , har vist seg å være en utmerket motor for ankermodellen, gitt en viss manuell optimalisering av spørringsplanen. På den annen side ser det foreløpig ikke ut som en veldig god idé å lagre ankermodellen, for eksempel på Click House, som har begrenset join-støtte.
I tillegg er det for begge arkitekturene spesielle trekk, noe som gjør datatilgang enklere (både fra et søkeytelsessynspunkt og for sluttbrukere). For eksempel, Tidspunkttabeller i Data Vault eller spesielle bordfunksjoner i Anchor-modellen.
Totalt
Hovedessensen av de betraktede fleksible arkitekturene er modulariteten til deres "design".
Det er denne egenskapen som tillater:
- Etter noen innledende forberedelser knyttet til distribusjon av metadata og skriving av grunnleggende ETL-algoritmer, raskt gi kunden det første resultatet i form av et par rapporter som inneholder data fra kun noen få kildeobjekter. Det er ikke nødvendig å tenke fullstendig gjennom (selv på toppnivå) hele objektmodellen.
- En datamodell kan begynne å fungere (og være nyttig) med bare 2-3 objekter, og deretter vokse gradvis (angående Ankermodellen Nikolai fin sammenligning med mycel).
- De fleste forbedringer, inkludert utvidelse av fagområdet og legge til nye kilder påvirker ikke eksisterende funksjonalitet og utgjør ingen risiko for å ødelegge noe som allerede fungerer.
- Takket være dekomponering til standardelementer ser ETL-prosesser i slike systemer like ut, skrivingen deres egner seg til algoritmisering og til slutt, automasjon.
Prisen på denne fleksibiliteten er opptreden. Dette betyr ikke at det er umulig å oppnå akseptabel ytelse på slike modeller. Oftere enn ikke kan det hende du trenger mer innsats og oppmerksomhet på detaljer for å oppnå målene du ønsker.
Apps
Enhetstyper Datahvelv
Mer informasjon om Data Vault:
Enhetstyper Ankermodell
Flere detaljer om ankermodell:
Sammendragstabell med fellestrekk og forskjeller ved de vurderte tilnærmingene:
Kilde: www.habr.com