Bergingontwikkeling is 'n lang en ernstige besigheid.
Baie in die lewe van 'n projek hang af van hoe goed die voorwerpmodel en basisstruktuur aan die begin deurdink is.
Die algemeen aanvaarde benadering was en bly verskeie kombinasies van die sterskema met die derde normaalvorm. As 'n reël, volgens die beginsel: aanvanklike data - 3NF, vertoonvensters - 'n ster. Hierdie benadering, getoets en gerugsteun deur baie navorsing, is die eerste (en soms die enigste) ding wat vir 'n ervare DWH-spesialis in gedagte kom wanneer hy dink oor hoe 'n analitiese bewaarplek moet lyk.
Aan die ander kant is besigheid in die algemeen en kliëntevereistes in die besonder geneig om vinnig te verander, terwyl data beide "in diepte" en "in breedte" groei. En hier verskyn die grootste nadeel van die ster - beperk buigsaamheid.
En as jy skielik in jou stil en gemaklike lewe as 'n DWH-ontwikkelaar is:
- die taak het ontstaan "om ten minste iets vinnig te doen, en dan sal ons sien";
- 'n vinnig ontwikkelende projek het verskyn, met die koppeling van nuwe bronne en die verandering van die sakemodel ten minste een keer per week;
- 'n kliënt het verskyn wat geen idee het hoe die stelsel moet lyk en watter funksies dit op die ou end moet verrig nie, maar gereed is vir eksperimente en konsekwente verfyning van die gewenste resultaat met 'n konsekwente benadering daartoe;
- die projekbestuurder het ingekyk met die goeie nuus: “En nou het ons rats!”.
Of as jy net belangstel om te leer hoe jy anders stoorplek kan bou - welkom by die kat!
Wat beteken "buigsaamheid"?
Om mee te begin, kom ons definieer watter eienskappe 'n stelsel moet hê om "buigsaam" genoem te word.
Afsonderlik is dit die moeite werd om te noem dat die beskryfde eienskappe spesifiek moet verwys stelsel, nie proses sy ontwikkeling. As u dus oor Agile as 'n ontwikkelingsmetodologie wou lees, is dit beter om ander artikels te lees. Byvoorbeeld, net daar, op Habré, is daar baie interessante materiaal (soos и En ).
Dit beteken nie dat die ontwikkelingsproses en die struktuur van die datapakhuis heeltemal onverwant is nie. Oor die algemeen behoort ratse ontwikkeling van 'n ratse berging baie makliker te wees. In die praktyk is daar egter meer opsies met Agile ontwikkeling van klassieke DWH volgens Kimbal en DataVault - volgens waterval as gelukkige toevallighede van buigsaamheid in sy twee vorme op een projek.
So, watter kenmerke moet buigsame berging hê? Daar is drie punte hier:
- Vroeë aflewering en vinnige voltooiing - dit beteken dat ideaal gesproke die eerste besigheidsresultaat (byvoorbeeld die eerste werksverslae) so vroeg as moontlik verkry moet word, dit wil sê selfs voordat die hele stelsel ontwerp en geïmplementeer is. Terselfdertyd moet elke daaropvolgende hersiening ook so min as moontlik tyd neem.
- Iteratiewe verfyning - dit beteken dat elke daaropvolgende hersiening, ideaal gesproke, nie die reeds werkende funksionaliteit moet beïnvloed nie. Dit is hierdie oomblik wat dikwels die grootste nagmerrie op groot projekte word – vroeër of later begin individuele voorwerpe soveel verwantskappe kry dat dit makliker word om die logika in 'n kopie heeltemal langs mekaar te herhaal as om 'n veld by 'n bestaande tabel te voeg. En as jy verbaas is dat die ontleding van die impak van verbeterings op bestaande voorwerpe langer kan neem as die hersiening self, het jy heel waarskynlik nie met groot datapakhuise in bankwese of telekommunikasie gewerk nie.
- Voortdurende aanpassing by veranderende besigheidsvereistes - die algemene voorwerpstruktuur moet ontwerp word nie net met inagneming van die moontlike uitbreiding nie, maar met die verwagting dat die rigting van hierdie volgende uitbreiding nie eers op die ontwerpstadium gedroom kan word nie.
En ja, voldoening aan al hierdie vereistes in een stelsel is moontlik (natuurlik in sekere gevalle en met sekere voorbehoude).
Hieronder sal ek twee van die gewildste ratse ontwerpmetodologieë vir HD hersien - anker model и Data Vault. Buite die hakies is sulke uitstekende truuks soos byvoorbeeld EAV, 6NF (in sy suiwer vorm) en alles wat met NoSQL-oplossings verband hou - nie omdat hulle op een of ander manier slegter is nie, en nie eers omdat die artikel in hierdie geval sou dreig om die volume te verkry nie. van 'n gemiddelde verhandeling. Dit is net dat dit alles verwys na oplossings van 'n effens ander klas - óf na tegnieke wat jy in spesifieke gevalle kan toepas, ongeag die algemene argitektuur van jou projek (soos EAV), of na wêreldwyd verskillende inligtingstoorparadigmas (soos grafiekdatabasisse) en ander opsies). NoSQL).
Probleme van die "klassieke" benadering en hul oplossings in buigsame metodologieë
Met die "klassieke" benadering bedoel ek die goeie ou ster (ongeag die spesifieke implementering van die onderliggende lae, vergewe my die aanhangers van Kimball, Inmon en CDM).
1. Rigiede kardinaliteit van verbindings
Hierdie model is gebaseer op 'n duidelike verdeling van data in afmetings (afmeting) и feite (Feit). En dit, verdomp, is logies – data-analise kom immers in die oorweldigende meerderheid van gevalle neer op die ontleding van sekere numeriese aanwysers (feite) in sekere afdelings (dimensies).
Terselfdertyd word skakels tussen voorwerpe gelê in die vorm van skakels tussen tabelle deur 'n vreemde sleutel. Dit lyk redelik natuurlik, maar lei onmiddellik tot die eerste beperking van buigsaamheid − streng definisie van die kardinaliteit van verhoudings.
Dit beteken dat jy in die ontwerpstadium van tabelle vir elke paar verwante voorwerpe moet spesifiseer of hulle as baie-tot-baie, of slegs 1-tot-baie, en "in watter rigting" verwant kan wees. Dit hang direk af van watter van die tabelle 'n primêre sleutel sal hê en watter een 'n vreemde sleutel sal hê. Die verandering van hierdie verhouding wanneer nuwe vereistes ontvang word, sal heel waarskynlik lei tot 'n herbewerking van die basis.
Byvoorbeeld, met die ontwerp van die "kontantontvangs"-objek, het jy, met staatmaak op die geswore versekering van die verkoopsafdeling, die moontlikheid van optrede neergelê een bevordering vir verskeie kontrole posisies (maar nie andersom nie):
En na 'n rukkie het kollegas 'n nuwe bemarkingstrategie bekendgestel waarin verskeie promosies op dieselfde tyd. En nou moet jy die tabelle finaliseer deur die verwantskap in 'n aparte voorwerp uit te lig.
(Alle afgeleide voorwerpe, waarby die promo-tjek aansluit, moet nou ook verbeter word).
Skakels in Data Vault en Anchor Model
Dit blyk redelik eenvoudig te wees om so 'n situasie te vermy: jy hoef nie die verkoopsafdeling te vertrou nie, dit is genoeg alle verhoudings word aanvanklik in aparte tabelle gestoor en verwerk soveel-tot-veel.
Hierdie benadering is voorgestel Dan Linstedt as deel van die paradigma Data Vault en ten volle ondersteun Lars Rönnbäck в Anker Model.
As gevolg hiervan kry ons die eerste kenmerkende kenmerk van buigsame metodologieë:
Verwantskappe tussen objekte word nie in die eienskappe van ouer-entiteite gestoor nie, maar is 'n aparte tipe objekte.
В Data Vault sulke tabelle word genoem Linken in Anker Model - Tie. Met die eerste oogopslag is hulle baie soortgelyk, hoewel hul verskille nie uitgeput word deur die naam nie (wat hieronder bespreek sal word). In beide argitekture kan skakeltabelle skakel enige aantal entiteite (nie noodwendig 2).
Hierdie by die eerste oogopslag oortolligheid gee noodsaaklike buigsaamheid by voltooiing. So 'n struktuur word verdraagsaam nie net om die kardinaliteite van bestaande skakels te verander nie, maar ook om nuwes by te voeg - as 'n tjekposisie nou ook 'n skakel het na die kassier wat dit gebreek het, sal die voorkoms van so 'n skakel bloot 'n bobou wees oor bestaande tabelle sonder om enige bestaande voorwerpe en prosesse te beïnvloed.
2. Data duplisering
Die tweede probleem wat deur buigsame argitekture opgelos word, is in die eerste plek minder voor die hand liggend en inherent. metings tipe SCD2 (stadig veranderde mates van die tweede tipe), hoewel nie net hulle nie.
In klassieke berging is 'n dimensie gewoonlik 'n tabel wat 'n surrogaatsleutel (as PK) en 'n stel besigheidsleutels en kenmerke in aparte kolomme bevat.
As die dimensie weergawe ondersteun, word weergawetydperke by die standaardstel velde gevoeg, en verskeie weergawes verskyn in die bewaarplek per ry in die bron (een vir elke verandering aan weergawe-kenmerke).
As 'n dimensie ten minste een weergawe-kenmerk bevat wat gereeld verander, sal die aantal weergawes van so 'n dimensie indrukwekkend wees (selfs al is die ander kenmerke nie weergawes nie of verander nooit nie), en as daar verskeie sulke eienskappe is, die aantal weergawes kan eksponensieel groei vanaf hul getal. So 'n dimensie kan 'n aansienlike hoeveelheid skyfspasie in beslag neem, hoewel die meeste van die data wat daarin gestoor word, bloot duplikate is van onveranderlike kenmerkwaardes uit ander rye.
Terselfdertyd word dit ook dikwels gebruik denormalisering - sommige van die eienskappe word doelbewus as 'n waarde gestoor, en nie as 'n verwysing na 'n naslaanboek of 'n ander dimensie nie. Hierdie benadering versnel datatoegang deur die aantal aansluitings te verminder wanneer toegang tot 'n dimensie verkry word.
Tipies lei dit tot dieselfde inligting word gelyktydig op verskeie plekke gestoor. Byvoorbeeld, inligting oor die woongebied en lidmaatskap van die kliëntekategorie kan gelyktydig gestoor word in die dimensies "Klant", en die feite "Aankoop", "Aflewering" en "Kontakte aan die inbelsentrum", sowel as in die skakeltabel “Klant - Kliëntebestuurder”.
Oor die algemeen is bogenoemde van toepassing op gereelde (nie-weergawe) metings, maar in weergawes kan hulle 'n ander skaal hê: die voorkoms van 'n nuwe weergawe van 'n voorwerp (veral in terugskou) lei nie net tot die opdatering van alle verwante tabelle nie, maar tot 'n kaskade-voorkoms van nuwe weergawes van verwante voorwerpe - wanneer Tabel 1 gebruik word om Tabel 2 te bou, en Tabel 2 word gebruik om Tabel 3 te bou, ensovoorts. Selfs al is nie 'n enkele kenmerk van Tabel 1 betrokke by die konstruksie van Tabel 3 nie (en ander eienskappe van Tabel 2 wat van ander bronne verkry is betrokke), sal die weergawe van hierdie konstruksie ten minste lei tot bykomende bokoste, en hoogstens tot ekstra weergawes in Tabel 3, wat oor die algemeen "niks daarmee te doen het nie" en verder af in die ketting.
3. Nie-lineêre kompleksiteit van verfyning
Terselfdertyd verhoog elke nuwe winkelfront wat bo-op 'n ander gebou word die aantal plekke waar data kan “afwyk” wanneer veranderinge aan die ETL aangebring word. Dit lei weer tot 'n toename in die kompleksiteit (en duur) van elke daaropvolgende hersiening.
As bogenoemde van toepassing is op stelsels met selde gewysigde ETL-prosesse, kan jy in so 'n paradigma leef - maak net seker dat nuwe verbeterings korrek aan alle verwante voorwerpe aangebring word. As hersienings gereeld voorkom, verhoog die waarskynlikheid om per ongeluk verskeie skakels te "mis" aansienlik.
As ons daarbenewens in ag neem dat die "weergawe" ETL baie meer ingewikkeld is as die "nie-weergawe", word dit nogal moeilik om foute te vermy tydens die gereelde verfyning van hierdie hele ekonomie.
Berging van voorwerpe en eienskappe in Data Vault en Anchor Model
Die benadering wat deur die skrywers van buigsame argitekture voorgestel word, kan soos volg geformuleer word:
Dit is nodig om te skei wat verander van wat onveranderd bly. Dit is om sleutels apart van eienskappe te stoor.
Moet egter nie verwar nie weergawe nie eienskap met onveranderd: die eerste een stoor nie die geskiedenis van sy verandering nie, maar kan verander (byvoorbeeld wanneer 'n invoerfout reggestel word of nuwe data ontvang word), die tweede een verander nooit.
Standpunte oor wat presies in die Data Vault en die Anchor-model as onveranderd beskou kan word, verskil.
In terme van argitektuur Data Vault, kan as onveranderd beskou word die hele stel sleutels - natuurlik (TIN van die organisasie, produkkode in die bronstelsel, ens.) en surrogaat. Terselfdertyd kan die oorblywende eienskappe in groepe verdeel word volgens die bron en/of frekwensie van veranderinge en hou 'n aparte tabel vir elke groep met 'n onafhanklike stel weergawes.
In dieselfde paradigma Anker Model as onveranderd beskou slegs surrogaatsleutel entiteite. Alles anders (insluitend natuurlike sleutels) is net 'n spesiale geval van sy eienskappe. Waarin alle eienskappe is by verstek onafhanklik van mekaar, so vir elke kenmerk moet geskep word aparte tafel.
В Data Vault tabelle wat entiteitsleutels bevat word genoem Hubami (Hub). Hubs bevat altyd 'n vaste stel velde:
- Natuurlike entiteitsleutels
- Surrogaatsleutel
- Skakel na bron
- Opname tyd
Inskrywings in Hubs verander nooit en het geen weergawes nie. Uiterlik is hubs baie soortgelyk aan ID-kaart-tabelle wat in sommige stelsels gebruik word om surrogate te genereer, maar dit word aanbeveel om nie 'n heelgetalvolgorde te gebruik nie, maar 'n hash van 'n stel besigheidsleutels as surrogate in Data Vault. Hierdie benadering vergemaklik die laai van skakels en eienskappe vanaf bronne (nie nodig om by die spilpunt aan te sluit om 'n surrogaat te kry nie, bereken net die hash vanaf die natuurlike sleutel), maar dit kan ander probleme veroorsaak (byvoorbeeld met botsings, kas en nie- die druk van karakters in stringsleutels, ens. .p.), daarom word dit nie algemeen aanvaar nie.
Alle ander entiteiteienskappe word gestoor in spesiale tabelle genoem Satelliete (Satelliet). Een spilpunt kan verskeie satelliete hê wat verskillende stelle eienskappe stoor.
Die verspreiding van eienskappe onder satelliete geskied volgens die beginsel gesamentlike verandering - in een satelliet kan nie-weergawe eienskappe gestoor word (byvoorbeeld geboortedatum en SNILS vir 'n individu), in die ander - selde verander weergawe (byvoorbeeld, van en paspoortnommer), in die derde - gereeld verander (byvoorbeeld afleweringsadres, kategorie, datum van laaste bestelling, ens.). Weergawe word in hierdie geval op die vlak van individuele satelliete uitgevoer, en nie die entiteit as geheel nie, daarom is dit raadsaam om die eienskappe so te versprei dat die kruising van weergawes binne een satelliet minimaal is (wat die totale aantal verminder van gestoorde weergawes).
Om die proses van die laai van data te optimaliseer, word eienskappe wat van verskeie bronne verkry word, dikwels in aparte satelliete geplaas.
Satelliete kommunikeer met die Hub deur onbekende sleutel (wat ooreenstem met 1-tot-veel kardinaliteit). Dit beteken dat veelvuldige kenmerkwaardes (byvoorbeeld veelvuldige kontakfoonnommers vir dieselfde kliënt) deur hierdie "verstek" argitektuur ondersteun word.
В Anker Model tabelle wat sleutels stoor word genoem Ankers. En hulle hou:
- Slegs surrogaatsleutels
- Skakel na bron
- Opname tyd
Natuurlike sleutels vanuit die oogpunt van die Ankermodel word oorweeg gewone eienskappe. Hierdie opsie lyk dalk moeiliker om te verstaan, maar dit gee baie meer ruimte om 'n voorwerp te identifiseer.
Byvoorbeeld, as data oor dieselfde entiteit van verskillende stelsels kan kom, wat elkeen sy eie natuurlike sleutel gebruik. In die Data Vault kan dit lei tot taamlik omslagtige konstruksies van verskeie spilpunte (een per bron + samesmeltende meesterweergawe), terwyl in die Anchor-model die natuurlike sleutel van elke bron in sy eie eienskap val en gebruik kan word wanneer onafhanklik gelaai word al die ander.
Maar hier lê een verraderlike oomblik: as eienskappe van verskillende stelsels in een entiteit gekombineer word, is daar heel waarskynlik gom reëls, waardeur die stelsel moet verstaan dat rekords van verskillende bronne ooreenstem met een geval van die entiteit.
В Data Vault hierdie reëls sal waarskynlik die vorming bepaal "surrogaat-hub" van die meester-entiteit en beïnvloed op geen manier die Hubs wat die natuurlike sleutels van die bronne en hul oorspronklike eienskappe stoor nie. As die reëls vir samesmelting op 'n sekere punt verander (of die eienskappe wat vir samesmelting gebruik word bygewerk word), sal dit genoeg wees om die surrogaat-hubs te hervorm.
В anker model so 'n entiteit sal waarskynlik in gestoor word enkele anker. Dit beteken dat alle eienskappe, ongeag van watter bron hulle verkry word, aan dieselfde surrogaat gebind sal wees. Om foutiewelik saamgevoegde rekords te skei en in die algemeen die relevansie van samesmelting in so 'n stelsel na te spoor, kan baie moeiliker wees, veral as die reëls redelik kompleks is en gereeld verander, en dieselfde eienskap uit verskillende bronne verkry kan word (alhoewel dit beslis is moontlik, want elkeen die kenmerk weergawe behou 'n verwysing na sy oorsprong).
In elk geval, as jou stelsel veronderstel is om die funksionaliteit te implementeer deduplisering, samevoeging van rekords en ander MDM-elemente, moet jy veral die aspekte van die berging van natuurlike sleutels in buigsame metodologieë noukeurig lees. Miskien is die meer ingewikkelde ontwerp van die Data Vault skielik veiliger in terme van samesmeltingsfoute.
anker model verskaf ook 'n addisionele tipe voorwerp genoem Knoop eintlik is dit 'n besonderse ontaarde tipe anker, wat slegs een kenmerk kan bevat. Die nodusse is veronderstel om gebruik te word vir die stoor van plat gidse (byvoorbeeld geslag, huwelikstatus, kliëntedienskategorie, ens.). Anders as Anchor, Knot het geen geassosieerde kenmerktabelle nie, en sy enigste kenmerk (naam) word altyd in dieselfde tabel met die sleutel gestoor. Nodusse word aan Ankers deur Tie-tabelle gekoppel op dieselfde manier as wat ankers aan mekaar verbind is.
Daar is geen ondubbelsinnige mening oor die gebruik van Nodes nie. Byvoorbeeld, , wat aktief die gebruik van die Ankermodel in Rusland bevorder, meen (nie onredelik nie) dat dit onmoontlik is om vir 'n enkele naslaanboek te sê dat hy altyd sal staties en enkelvlak wees, daarom is dit beter om 'n volwaardige Anker vir alle voorwerpe gelyktydig te gebruik.
Nog 'n belangrike verskil tussen Data Vault en Anchor Model is die teenwoordigheid eienskappe vir skakels:
В Data Vault Skakels is dieselfde volwaardige voorwerpe as Hubs, en kan hê eie eienskappe. In anker model Skakels word slegs gebruik om Ankers en kan nie hul eie eienskappe hê nie. Hierdie verskil lei tot aansienlik verskillende modelleringsbenaderings. feite, wat volgende bespreek sal word.
Feitberging
Tot dusver het ons hoofsaaklik oor modellering metings gepraat. Die feite is 'n bietjie minder duidelik.
В Data Vault 'n tipiese voorwerp vir die stoor van feite − Skakel, in wie se satelliete werklike aanwysers bygevoeg word.
Hierdie benadering blyk intuïtief te wees. Dit bied maklike toegang tot die geanaliseerde aanwysers en is oor die algemeen soortgelyk aan 'n tradisionele feitetabel (slegs die aanwysers word nie in die tabel self gestoor nie, maar in die "aangrensende tabel"). Maar daar is ook slaggate: een van die tipiese modifikasies van die model - die uitbreiding van die feitesleutel - noodsaak die byvoeging van 'n nuwe vreemde sleutel by die skakel. En dit "breek" op sy beurt modulariteit en veroorsaak moontlik die behoefte aan verbeterings aan ander voorwerpe.
В anker model 'n Skakel kan nie sy eie eienskappe hê nie, so hierdie benadering sal nie werk nie - absoluut alle eienskappe en aanwysers moet aan een spesifieke anker gekoppel word. Die gevolgtrekking hieruit is eenvoudig - elke feit het ook sy eie anker nodig. Vir sommige van wat ons gewoond is om as feite te beskou, kan dit natuurlik lyk - byvoorbeeld, die feit van 'n aankoop is perfek gereduseer tot die voorwerp "bestelling" of "kwitansie", besoek 'n webwerf word verminder tot 'n sessie, ens. Maar daar is ook feite waarvoor dit nie so maklik is om so 'n natuurlike "draervoorwerp" te vind nie - byvoorbeeld die balans van goedere in pakhuise aan die begin van elke dag.
Gevolglik is daar geen probleme met modulariteit wanneer die feitesleutel in die Anker-model uitgebrei word nie (dit is genoeg om net 'n nuwe Verwantskap by die ooreenstemmende Anker te voeg), maar die ontwerp van die model om feite te vertoon is minder duidelik, "kunsmatige" Ankers kan verskyn wat die objekmodel van die besigheid vertoon, is nie voor die hand liggend nie.
Hoe buigsaamheid bereik word
Die gevolglike konstruksie in beide gevalle bevat aansienlik meer tafelsas tradisionele meting. Maar dit kan vat aansienlik minder skyfspasie met dieselfde stel weergawe-eienskappe as die tradisionele dimensie. Hier is natuurlik geen towerkrag nie – dit gaan alles oor normalisering. Deur kenmerke oor satelliete (in die datakluis) of individuele tabelle (ankermodel) te versprei, verminder (of skakel ons heeltemal uit) die waardes van sommige eienskappe te dupliseer wanneer ander verander word.
Vir Data Vault die wins sal afhang van die verspreiding van eienskappe onder die satelliete, en vir anker model — is byna direk eweredig aan die gemiddelde aantal weergawes per meetvoorwerp.
Om spasie op te neem is egter 'n belangrike, maar nie die belangrikste nie, voordeel om eienskappe afsonderlik te stoor. Saam met aparte berging van skakels maak hierdie benadering die berging modulêre ontwerp. Dit beteken dat die toevoeging van beide individuele eienskappe en heel nuwe vakgebiede in so 'n model lyk bobou oor 'n bestaande stel voorwerpe sonder om dit te verander. En dit is presies wat die beskryfde metodologieë buigsaam maak.
Dit lyk ook soos die oorgang van stukproduksie na massaproduksie - as in die tradisionele benadering elke modeltafel uniek is en aparte aandag verg, dan is dit in buigsame metodologieë reeds 'n stel tipiese "besonderhede". Aan die een kant is daar meer tabelle, die prosesse van laai en haal van data behoort meer ingewikkeld te lyk. Aan die ander kant word hulle tipies. Dit beteken dat daar kan wees geoutomatiseer en bestuur deur metadata. Die vraag "hoe gaan ons lê?", waarvan die antwoord 'n beduidende deel van die werk aan die ontwerp van verbeterings kan beslaan, is nou eenvoudig nie die moeite werd nie (soos die vraag na die impak van die verandering van die model op werk). prosesse).
Dit beteken nie dat ontleders in so 'n stelsel glad nie nodig is nie - iemand moet nog 'n stel voorwerpe met eienskappe uitwerk en uitvind waar en hoe om dit alles te laai. Maar die hoeveelheid werk, sowel as die waarskynlikheid en koste van 'n fout, word aansienlik verminder. Beide in die stadium van analise en tydens die ontwikkeling van ETL, wat in 'n beduidende deel gereduseer kan word tot die redigering van metadata.
Donker kant
Al die bogenoemde maak beide benaderings werklik buigsaam, vervaardigbaar en geskik vir iteratiewe verfyning. Daar is natuurlik ook 'n "vat teer", waarvan ek dink jy reeds weet.
Data-ontbinding onderliggend aan die modulariteit van buigsame argitekture lei tot 'n toename in die aantal tabelle en dienooreenkomstig, oorhoofse vir aansluitings by haal. Om eenvoudig al die eienskappe van 'n dimensie te kry, is 'n enkele keuse voldoende in die klassieke berging, en 'n buigsame argitektuur sal 'n aantal verbindings vereis. Verder, as vir verslae al hierdie aansluitings vooraf geskryf kan word, sal ontleders wat gewoond is om SQL met die hand te skryf dubbeld ly.
Daar is verskeie feite wat hierdie situasie makliker maak:
Wanneer daar met groot afmetings gewerk word, word byna al sy eienskappe amper nooit gelyktydig gebruik nie. Dit beteken dat daar minder aansluitings kan wees as wat dit met die eerste oogopslag by die model lyk. In Data Vault kan jy ook die verwagte frekwensie van deling in ag neem wanneer eienskappe aan satelliete toegewys word. Terselfdertyd is Hubs of Anchors self hoofsaaklik nodig vir die generering en kartering van surrogate tydens die laaistadium en word selde in navrae gebruik (dit is veral waar vir Anchors).
Alle aansluitings is per sleutel. Boonop verminder 'n meer "saamgeperste" manier om data te stoor die bokoste van skandering van tabelle waar dit nodig is (byvoorbeeld wanneer gefiltreer word volgens 'n kenmerkwaarde). Dit kan daartoe lei dat die afhaal van 'n genormaliseerde databasis met 'n klomp aansluitings selfs vinniger sal wees as om een swaar dimensie te skandeer met baie weergawes per ry.
Byvoorbeeld, hier in artikel is daar 'n gedetailleerde vergelykende prestasietoets van die Anchor-model met 'n keuse uit een tabel.
Baie hang af van die enjin. Baie moderne platforms het interne meganismes om verbindings te optimaliseer. MS SQL en Oracle kan byvoorbeeld koppelings na tabelle "oorslaan" as hul data nêrens gebruik word nie, behalwe vir ander aansluitings en nie die finale keuse (tabel/aansluiting eliminasie) beïnvloed nie, terwyl MPP Vertica , was 'n uitstekende enjin vir die ankermodel, met 'n mate van handoptimalisering van die navraagplan. Aan die ander kant lyk dit nog nie na 'n goeie idee om die ankermodel byvoorbeeld op Click House, wat beperkte ondersteuning vir aansluiting het, te stoor nie.
Daarbenewens is daar vir beide argitekture spesiale truuks, wat dit makliker maak om toegang tot data te verkry (beide in terme van navraagprestasie en vir eindgebruikers). Byvoorbeeld, Punt-in-tyd tabelle in Data Vault of spesiale tafelfunksies in die ankermodel.
In totaal
Die belangrikste essensie van die oorweegde buigsame argitekture is die modulariteit van hul "ontwerp".
Hierdie eiendom laat toe:
- Na 'n paar aanvanklike voorbereiding wat verband hou met die implementering van metadata en die skryf van basiese ETL-algoritmes, gee die kliënt vinnig die eerste resultaat in die vorm van 'n paar verslae wat data van slegs 'n paar bronobjekte bevat. Dit is nie nodig om die hele objekmodel hiervoor volledig deur te dink (selfs op topvlak) nie.
- 'n Datamodel kan begin werk (en nuttig) met net 2-3 voorwerpe, en dan geleidelik groei (met betrekking tot die Anchor model Nikolay pragtige vergelyking met miselium).
- Die meeste verbeterings, insluitend die uitbreiding van die vakgebied en die byvoeging van nuwe bronne affekteer nie bestaande funksionaliteit nie en veroorsaak nie die gevaar om iets te breek wat reeds werk nie.
- Danksy ontbinding in standaardelemente lyk ETL-prosesse in sulke stelsels dieselfde, hul skryfwerk leen hom tot algoritmisering en, uiteindelik, outomatisering.
Die prys van hierdie buigsaamheid is optrede. Dit beteken nie dat dit onmoontlik is om aanvaarbare werkverrigting op sulke modelle te behaal nie. Meer dikwels as nie, het jy dalk net meer moeite en aandag aan detail nodig om die verlangde maatstawwe te bereik.
Programme
Entiteit tipes Data Vault
Meer oor Data Vault:
Entiteit tipes Anker Model
Meer oor ankermodel:
Opsommingstabel met algemene kenmerke en verskille tussen die beskoude benaderings:
Bron: will.com