Saugyklos kūrimas yra ilgas ir rimtas darbas.
Daug kas projekto gyvavimo metu priklauso nuo to, kaip gerai apgalvotas objekto modelis ir bazinė struktūra pradžioje.
Visuotinai priimtas požiūris buvo ir išlieka įvairūs žvaigždės schemos derinimo su trečiąja normalia forma variantai. Paprastai pagal principą: pradiniai duomenys - 3NF, vitrinos - žvaigždė. Šis laiko patikrintas ir daugybės tyrimų paremtas požiūris yra pirmas (o kartais ir vienintelis) dalykas, kuris ateina į galvą patyrusiam DWH specialistui, galvojančiam apie tai, kaip turėtų atrodyti analitinė saugykla.
Kita vertus, verslas apskritai ir ypač klientų poreikiai linkę greitai keistis, o duomenys linkę augti tiek „gyliu“, tiek „pločiu“. Ir čia išryškėja pagrindinis žvaigždės trūkumas – ribotas lankstumas.
Ir jei jūsų ramiame ir jaukiame gyvenime, kaip DWH kūrėjo, staiga:
- iškilo užduotis „bent ką nors greitai padaryti, o tada pamatysime“;
- atsirado sparčiai besivystantis projektas, bent kartą per savaitę prijungiant naujus šaltinius ir pertvarkant verslo modelį;
- atsirado klientas, kuris neįsivaizduoja, kaip turi atrodyti sistema ir kokias funkcijas ji galiausiai turėtų atlikti, tačiau yra pasiruošęs eksperimentuoti ir nuosekliai tobulinti norimą rezultatą, nuosekliai prie jo artėdamas;
- Projekto vadovas užsuko su džiugia žinia: „Ir dabar turime Agile!
Arba, jei tiesiog norite sužinoti, kaip dar galite pastatyti saugyklas – sveiki atvykę!
Ką reiškia "lankstumas"?
Pirma, apibrėžkime, kokias savybes turi turėti sistema, kad ją būtų galima pavadinti „lanksčia“.
Atskirai verta paminėti, kad aprašytos savybės turėtų būti konkrečiai susijusios su sistema, ne procesas jo plėtra. Todėl, jei norėjote paskaityti apie Agile kaip kūrimo metodiką, geriau perskaitykite kitus straipsnius. Pavyzdžiui, čia pat, Habré, yra daug įdomios medžiagos (pvz и Ir ).
Tai nereiškia, kad kūrimo procesas ir duomenų saugyklos struktūra yra visiškai nesusiję. Apskritai turėtų būti daug lengviau sukurti judrią saugyklą judriai architektūrai. Tačiau praktikoje dažniau yra variantų, susijusių su judriu klasikinio DWH kūrimu pagal Kimbalį ir „DataVault“ - pagal „Waterfall“, o ne laimingus lankstumo sutapimus dviem jo formomis viename projekte.
Taigi, kokias galimybes turėtų turėti lanksti saugykla? Čia yra trys punktai:
- Ankstyvas pristatymas ir greitas pristatymas - tai reiškia, kad idealiu atveju pirmasis verslo rezultatas (pavyzdžiui, pirmosios darbo ataskaitos) turėtų būti gautas kuo anksčiau, tai yra dar prieš visapusiškai suprojektavus ir įdiegus visą sistemą. Be to, kiekviena paskesnė peržiūra taip pat turėtų užtrukti kuo mažiau laiko.
- Iteratyvus tobulinimas - tai reiškia, kad kiekvienas paskesnis patobulinimas idealiu atveju neturėtų paveikti jau veikiančių funkcijų. Būtent šis momentas dažnai tampa didžiausiu didelių projektų košmaru – anksčiau ar vėliau atskiri objektai pradeda įgyti tiek daug sąsajų, kad tampa lengviau visiškai pakartoti logiką šalia esančioje kopijoje, nei pridėti lauką prie esamos lentelės. Ir jei nustebsite, kad esamų objektų patobulinimų įtakos analizė gali užtrukti daugiau laiko nei patys patobulinimai, greičiausiai dar nedirbote su dideliais duomenų saugyklomis bankininkystėje ar telekomunikacijoje.
- Nuolat prisitaikantis prie besikeičiančių verslo reikalavimų - bendra objekto struktūra turėtų būti projektuojama ne tik atsižvelgiant į galimą plėtrą, bet ir tikintis, kad apie šios kitos plėtros kryptį projektavimo etape net nebuvo galima pasvajoti.
Ir taip, visų šių reikalavimų tenkinimas vienoje sistemoje yra įmanomas (žinoma, tam tikrais atvejais ir su tam tikromis išlygomis).
Žemiau panagrinėsiu dvi populiariausias duomenų saugyklų judriojo projektavimo metodikas – Inkaro modelis и Duomenų saugykla. Iš skliaustų liko tokios puikios technikos kaip, pavyzdžiui, EAV, 6NF (gryna forma) ir viskas, kas susiję su NoSQL sprendimais – ne todėl, kad jie kažkaip blogesni, ir net ne todėl, kad tokiu atveju straipsnis grėstų įsigyti vidutinio disertacijos apimtis. Tiesiog visa tai susiję su šiek tiek kitokios klasės sprendimais – arba su technikomis, kurias galite naudoti konkrečiais atvejais, nepaisant bendros projekto architektūros (pvz., EAV), arba su kitomis informacijos saugojimo paradigmomis (pvz., grafų duomenų bazėmis). ir kitos parinktys NoSQL).
„Klasikinio“ požiūrio problemos ir jų sprendimai lanksčiose metodikose
„Klasikiniu“ požiūriu aš turiu galvoje seną gerą žvaigždę (nepriklausomai nuo konkretaus pagrindinių sluoksnių įgyvendinimo, Kimball, Inmon ir CDM pasekėjai gali man atleisti).
1. Kietas jungčių kardinalumas
Šis modelis pagrįstas aiškiu duomenų padalijimu į Matmenys и faktus. Ir tai, po velnių, yra logiška – juk duomenų analizė didžiąja dalimi atvejų baigiasi tam tikrų skaitinių rodiklių (faktų) analize tam tikrose atkarpose (dimensijose).
Šiuo atveju ryšiai tarp objektų nustatomi ryšių tarp lentelių forma naudojant išorinį raktą. Tai atrodo gana natūralu, bet iš karto sukelia pirmąjį lankstumo apribojimą - griežtas jungčių kardinalumo apibrėžimas.
Tai reiškia, kad lentelės kūrimo etape kiekvienai susijusių objektų porai turite tiksliai nustatyti, ar jie gali būti siejami su daugybe, ar tik „1 su daugeliu“, ir „kuria kryptimi“. Tai tiesiogiai nustato, kuri lentelė turės pirminį raktą, o kurioje - išorinį raktą. Pakeitus šį požiūrį, kai bus gauti nauji reikalavimai, greičiausiai bus pertvarkyta bazė.
Pavyzdžiui, kurdami „kasų kvito“ objektą, jūs, remdamiesi pardavimo skyriaus priesaika, numatėte veiksmų galimybę viena akcija už kelias čekio pozicijas (bet ne atvirkščiai):
Ir po kurio laiko kolegos pristatė naują rinkodaros strategiją, pagal kurią jie gali eiti tas pačias pareigas kelios akcijos vienu metu. O dabar reikia modifikuoti lenteles atskiriant ryšį į atskirą objektą.
(Visi išvestiniai objektai, kuriuose dabar yra prijungtas skatinimo patikrinimas, taip pat turi būti tobulinami).
Ryšiai duomenų saugykloje ir inkaro modelyje
Išvengti šios situacijos pasirodė gana paprasta: nebūtina pasitikėti pardavimo skyriumi. visos jungtys iš pradžių saugomos atskirose lentelėse ir apdoroti kaip daug su daugeliu.
Šis požiūris buvo pasiūlytas Danas Linstedtas kaip paradigmos dalis Duomenų saugykla ir visiškai palaikoma Larsas Rönnbäckas в Inkaro modelis.
Dėl to gauname pirmąjį išskirtinį lanksčių metodų bruožą:
Ryšiai tarp objektų nėra saugomi pirminių objektų atributuose, bet yra atskiras objektų tipas.
В Duomenų saugykla tokios susiejimo lentelės vadinamos ryšysIr Inkaro modelis - kaklaraištis. Iš pirmo žvilgsnio jie labai panašūs, nors jų skirtumai nesibaigia pavadinimu (jis bus aptartas toliau). Abiejose architektūrose nuorodų lentelės gali susieti bet koks subjektų skaičius (nebūtinai 2).
Šis perteklius, iš pirmo žvilgsnio, suteikia daug lankstumo atliekant pakeitimus. Tokia struktūra tampa tolerantiška ne tik esamų nuorodų kardinalumo pokyčiams, bet ir naujų papildymui – jei dabar čekio pozicija taip pat turi nuorodą į ją pralaužusią kasininką, tokios nuorodos atsiradimas tiesiog tapti esamų lentelių priedu, nepaveikdami jokių esamų objektų ir procesų.
2. Duomenų dubliavimas
Antroji problema, išspręsta lanksčiomis architektūromis, yra mažiau akivaizdi ir visų pirma būdinga. SCD2 tipo matavimai (lėtai kintantys antro tipo matmenys), nors ne tik juos.
Klasikiniame sandėlyje aspektas paprastai yra lentelė, kurioje yra pakaitinis raktas (kaip PK) ir verslo raktų bei atributų rinkinys atskiruose stulpeliuose.
Jei aspektas palaiko versijų kūrimą, versijos galiojimo ribos pridedamos prie standartinio laukų rinkinio, o vienoje šaltinio eilutėje saugykloje rodomos kelios versijos (po vieną kiekvienam versijų atributų pakeitimui).
Jei dimensijoje yra bent vienas dažnai kintantis versijų atributas, tokio dimensijos versijų skaičius bus įspūdingas (net jei likę atributai nėra versijuojami arba niekada nesikeičia), o jei tokių atributų yra keli, versijų skaičius gali eksponentiškai augti nuo jų skaičiaus. Šis matmuo gali užimti daug vietos diske, nors didžioji dalis jame saugomų duomenų yra tiesiog nekintamų atributų verčių iš kitų eilučių kopijos.
Tuo pačiu metu jis taip pat labai dažnai naudojamas denormalizacija — kai kurie atributai yra sąmoningai saugomi kaip vertė, o ne kaip nuoroda į žinyną ar kitą aspektą. Šis metodas pagreitina prieigą prie duomenų ir sumažina sujungimų skaičių pasiekiant aspektą.
Paprastai tai veda prie ta pati informacija vienu metu saugoma keliose vietose. Pavyzdžiui, informacija apie gyvenamąjį regioną ir kliento kategoriją vienu metu gali būti saugoma „Kliento“ dimensijose ir „Pirkimo“, „Pristatymo“ ir „Skambučių centro skambučių“ faktuose, taip pat „Klientas – klientų vadybininkas“. “ nuorodų lentelė.
Apskritai, tai, kas aprašyta aukščiau, galioja įprastiems (neversijuotiems) matmenims, tačiau versijose jie gali turėti skirtingą mastelį: naujos objekto versijos atsiradimas (ypač retrospektyviai) lemia ne tik visų susijusių matmenų atnaujinimą. lenteles, bet į pakopinį naujų susijusių objektų versijų atsiradimą – kai 1 lentelė naudojama 2 lentelei sudaryti, o 2 lentelė naudojama 3 lentelei kurti ir pan. Net jei kuriant 1 lentelę nėra įtrauktas nė vienas 3 lentelės atributas (ir kiti 2 lentelės atributai, gauti iš kitų šaltinių), šios konstrukcijos versijos sudarymas mažiausiai sukels papildomų išlaidų, o daugiausiai - papildomų išlaidų. versijos 3 lentelėje. kuris su juo visiškai nesusijęs, o toliau grandinėje.
3. Netiesinis perdirbimo sudėtingumas
Tuo pačiu metu kiekviena nauja vitrina, pastatyta remiantis kitu, padidina vietų, kur duomenys gali „skirti“, kai keičiami ETL, skaičių. Tai, savo ruožtu, padidina kiekvienos paskesnės peržiūros sudėtingumą (ir trukmę).
Jei aukščiau aprašytos sistemos su retai modifikuotais ETL procesais, galite gyventi tokioje paradigmoje – tereikia įsitikinti, kad visuose susijusiuose objektuose yra teisingai padarytos naujos modifikacijos. Jei peržiūros atliekamos dažnai, tikimybė, kad netyčia „praras“ keletą jungčių, žymiai padidėja.
Be to, atsižvelgus į tai, kad „versijuotas“ ETL yra žymiai sudėtingesnis nei „neversinis“, dažnai atnaujinant visą šią priemonę bus gana sunku išvengti klaidų.
Objektų ir atributų saugojimas „Data Vault“ ir „Anchor Model“.
Lanksčių architektūrų autorių pasiūlytas požiūris gali būti suformuluotas taip:
Būtina atskirti tai, kas keičiasi, nuo to, kas lieka nepakitusi. Tai yra, saugokite raktus atskirai nuo atributų.
Tačiau nereikėtų suklaidinti neversijuota atributas su nepakitęs: pirmasis nesaugo savo pakeitimų istorijos, bet gali keistis (pavyzdžiui, taisant įvesties klaidą ar gaunant naujus duomenis), antrasis niekada nesikeičia.
Požiūriai skiriasi dėl to, kas tiksliai gali būti laikoma nekintamu „Data Vault“ ir „Inchor Model“.
Architektūriniu požiūriu Duomenų saugykla, gali būti laikomas nepakeistu visas raktų komplektas - natūralus (organizacijos TIN, produkto kodas šaltinio sistemoje ir kt.) ir pakaitalas. Tokiu atveju likusius požymius galima suskirstyti į grupes pagal pakeitimų šaltinį ir/ar dažnumą ir Kiekvienai grupei turėkite atskirą lentelę su nepriklausomu versijų rinkiniu.
Paradigmoje Inkaro modelis laikomas nepakeistu tik surogatinis raktas esmė. Visa kita (įskaitant natūralius raktus) yra tik ypatingas jo atributų atvejis. Kuriame pagal numatytuosius nustatymus visi atributai yra nepriklausomi vienas nuo kito, taigi kiekvienam atributui a atskira lentelė.
В Duomenų saugykla iškviečiamos lentelės, kuriose yra objektų raktai Hubami. Hubuose visada yra fiksuotas laukų rinkinys:
- Natūralios būtybės raktai
- Pakaitinis raktas
- Nuoroda į šaltinį
- Įrašykite pridėjimo laiką
Įrašai centruose niekada nesikeičia ir neturi versijų. Išoriškai šakotuvai yra labai panašūs į ID žemėlapio tipo lenteles, naudojamas kai kuriose sistemose pakaitalams generuoti, tačiau rekomenduojama naudoti maišą iš verslo raktų rinkinio kaip pakaitalą „Data Vault“. Šis metodas supaprastina ryšių ir atributų įkėlimą iš šaltinių (nereikia prisijungti prie šakotuvo, kad gautumėte pakaitalą, tiesiog apskaičiuokite natūralaus rakto maišą), tačiau gali kilti kitų problemų (susijusių, pavyzdžiui, su susidūrimais, raidėmis ir nespausdinamomis). simboliai eilutės klavišuose ir pan. .p.), todėl tai nėra visuotinai priimta.
Visi kiti objekto atributai yra saugomi specialiose lentelėse, vadinamose Palydovai. Viename šakotuve gali būti keli palydovai, kuriuose saugomi skirtingi atributų rinkiniai.
Atributų pasiskirstymas tarp palydovų vyksta pagal principą sąnario pasikeitimas - viename palydove gali būti saugomi neversijuoti atributai (pavyzdžiui, asmens gimimo data ir SNILS), kitame - retai besikeičiantys versijos (pavyzdžiui, pavardė ir paso numeris), trečiame - dažnai besikeičiantys. (pavyzdžiui, pristatymo adresas, kategorija, paskutinio užsakymo data ir pan.). Šiuo atveju versijų nustatymas atliekamas atskirų palydovų, o ne viso objekto lygmeniu, todėl patartina atributus paskirstyti taip, kad versijų susikirtimas viename palydove būtų minimalus (tai sumažina bendrą saugomų versijų skaičių). ).
Taip pat, siekiant optimizuoti duomenų įkėlimo procesą, atributai, gauti iš įvairių šaltinių, dažnai įtraukiami į atskirus palydovus.
Palydovai susisiekia su Hub per svetimas raktas (tai atitinka kardinalumą nuo 1 iki daugelio). Tai reiškia, kad ši „numatytoji“ architektūra palaiko kelias atributų vertes (pavyzdžiui, kelis kontaktinius telefono numerius vienam klientui).
В Inkaro modelis yra vadinamos lentelės, kuriose saugomi raktai Inkarai. Ir jie laikosi:
- Tik pakaitiniai raktai
- Nuoroda į šaltinį
- Įrašykite pridėjimo laiką
Natūralūs raktai yra nagrinėjami Inkaro modelio požiūriu įprastiniai atributai. Ši parinktis gali atrodyti sunkiau suprantama, tačiau ji suteikia daug daugiau galimybių identifikuoti objektą.
Pavyzdžiui, jei duomenys apie tą patį objektą gali būti gaunami iš skirtingų sistemų, kurių kiekviena naudoja savo natūralų raktą. „Data Vault“ tai gali sukelti gana sudėtingas kelių šakotuvų struktūras (po vieną kiekvienam šaltiniui + vienijančią pagrindinę versiją), o „Anchor“ modelyje natūralus kiekvieno šaltinio raktas patenka į savo atributą ir gali būti naudojamas įkeliant nepriklausomai nuo visi kiti.
Tačiau čia taip pat yra vienas klastingas dalykas: jei skirtingų sistemų atributai yra sujungti į vieną objektą, greičiausiai yra keletas "klijavimo" taisyklės, pagal kurią sistema turi suprasti, kad įrašai iš skirtingų šaltinių atitinka vieną objekto egzempliorių.
В Duomenų saugykla šios taisyklės greičiausiai nulems formavimąsi pagrindinio subjekto „pakaitinis centras“. ir jokiu būdu neturi įtakos šakotuvams, kuriuose saugomi natūralūs šaltinio raktai ir jų pradiniai atributai. Jei tam tikru momentu pasikeis sujungimo taisyklės (arba atnaujinami atributai, pagal kuriuos tai atliekama), pakaks iš naujo suformatuoti surogatinius centrus.
В Inkaro modelis toks subjektas greičiausiai bus saugomas vienintelis inkaras. Tai reiškia, kad visi atributai, nesvarbu, iš kokio šaltinio jie kilę, bus susieti su tuo pačiu pakaitalu. Atskirti klaidingai sujungtus įrašus ir apskritai stebėti sujungimo aktualumą tokioje sistemoje gali būti daug sunkiau, ypač jei taisyklės yra gana sudėtingos ir dažnai keičiasi, o tą patį požymį galima gauti iš skirtingų šaltinių (nors tikrai įmanoma, nes kiekviena atributo versija išlaiko nuorodą į savo šaltinį).
Bet kokiu atveju, jei jūsų sistema turėtų įdiegti funkcionalumą deduplikacija, įrašų ir kitų MDM elementų sujungimas, verta atkreipti ypatingą dėmesį į natūralių raktų saugojimo aspektus judriose metodikose. Tikėtina, kad stambesnis „Data Vault“ dizainas staiga taps saugesnis dėl sujungimo klaidų.
Inkaro modelis taip pat suteikia papildomą objekto tipą, vadinamą Mazgas tai iš esmės ypatinga išsigimęs inkaro tipas, kuriame gali būti tik vienas atributas. Numatoma, kad mazgai bus naudojami vienodiems katalogams saugoti (pavyzdžiui, lytis, šeiminė padėtis, klientų aptarnavimo kategorija ir kt.). Skirtingai nuo inkaro, mazgo neturi susietų atributų lentelių, o vienintelis jo atributas (pavadinimas) visada saugomas toje pačioje lentelėje su raktu. Mazgai su inkarais sujungiami surišimo lentelėmis (Tie) taip pat, kaip inkarai yra sujungti vienas su kitu.
Nėra aiškios nuomonės dėl mazgų naudojimo. Pavyzdžiui, , kuris aktyviai propaguoja inkaro modelio naudojimą Rusijoje, mano (ne be pagrindo), kad ne vienai žinynai galima tvirtai teigti, kad visada bus statinis ir vieno lygio, todėl geriau iš karto naudoti visavertį Inkarą visiems objektams.
Kitas svarbus skirtumas tarp „Data Vault“ ir „Inchor“ modelio yra prieinamumas ryšių atributai:
В Duomenų saugykla Nuorodos yra tokie patys pilnaverčiai objektai, kaip ir šakotuvai, ir gali turėti savo atributus. Į Inkaro modelis Nuorodos naudojamos tik sujungti Inkarus ir negali turėti savo atributų. Šis skirtumas lemia labai skirtingus modeliavimo metodus faktus, apie kurį bus kalbama toliau.
Faktų saugojimas
Prieš tai daugiausia kalbėjome apie matavimo modeliavimą. Faktai yra šiek tiek mažiau aiškūs.
В Duomenų saugykla tipiškas faktų saugojimo objektas yra Nuoroda, kurio palydovuose pridedami realūs rodikliai.
Šis požiūris atrodo intuityvus. Ji suteikia lengvą prieigą prie analizuojamų rodiklių ir iš esmės yra panaši į tradicinę faktų lentelę (tik rodikliai saugomi ne pačioje lentelėje, o „kaimyninėje“). Tačiau yra ir spąstų: viena iš tipiškų modelio modifikacijų – fakto rakto išplėtimas – reikalauja pridedant naują išorinį raktą į nuorodą. O tai, savo ruožtu, „sulaužo“ moduliškumą ir gali sukelti kitų objektų modifikacijų poreikį.
В Inkaro modelis Ryšys negali turėti savo atributų, todėl toks požiūris neveiks – absoliučiai visi požymiai ir rodikliai turi būti susieti su vienu konkrečiu inkaru. Išvada iš to paprasta - Kiekvienam faktui taip pat reikia savo inkaro. Kai kuriems iš to, ką esame įpratę suvokti kaip faktus, tai gali atrodyti natūralu – pavyzdžiui, pirkimo faktą galima puikiai redukuoti iki objekto „užsakymas“ ar „gautas“, apsilankymas svetainėje į seansą ir pan. Tačiau yra ir faktų, dėl kurių ne taip lengva rasti tokį natūralų „nešiklio objektą“ - pavyzdžiui, prekių likučiai sandėliuose kiekvienos dienos pradžioje.
Atitinkamai, moduliškumo problemų išplečiant fakto raktą Inkaro modelyje nekyla (pakanka tiesiog pridėti naują ryšį prie atitinkamo inkaro), tačiau modelio kūrimas faktams rodyti yra ne toks vienareikšmis, gali atsirasti „dirbtinių“ inkarų. kurios verslo objekto modelį rodo neaiškiai.
Kaip pasiekiamas lankstumas
Abiem atvejais gautoje konstrukcijoje yra žymiai daugiau lenteliųnei tradicinis matavimas. Bet tai gali užtrukti žymiai mažiau vietos diske su tuo pačiu versijų atributų rinkiniu kaip ir tradicinis aspektas. Natūralu, kad čia nėra magijos - viskas susiję su normalizavimu. Paskirstydami atributus palydovuose (duomenų saugykloje) arba atskirose lentelėse (inkaro modelis), sumažiname (arba visiškai pašaliname) kai kurių atributų verčių dubliavimas keičiant kitus.
Už Duomenų saugykla laimėjimai priklausys nuo atributų pasiskirstymo tarp Satelitų ir už Inkaro modelis — yra beveik tiesiogiai proporcingas vidutiniam matavimo objekto versijų skaičiui.
Tačiau vietos taupymas yra svarbus, bet ne pagrindinis privalumas laikant atributus atskirai. Kartu su atskiru santykių saugojimu šis metodas sukuria parduotuvę modulinis dizainas. Tai reiškia, kad tiek atskirų atributų, tiek visiškai naujų dalykų įtraukimas į tokį modelį atrodo taip antstatas per esamą objektų rinkinį jų nekeičiant. Ir būtent tai daro aprašytas metodikas lanksčias.
Tai taip pat primena perėjimą nuo vienetinės gamybos prie masinės gamybos - jei tradiciniu požiūriu kiekviena modelio lentelė yra unikali ir reikalaujanti ypatingo dėmesio, tai lanksčiose metodikose tai jau yra standartinių „detalių“ rinkinys. Viena vertus, yra daugiau lentelių, o duomenų įkėlimo ir gavimo procesai turėtų atrodyti sudėtingesni. Kita vertus, jie tampa tipiškas. O tai reiškia, kad gali būti automatizuotas ir pagrįstas metaduomenimis. Klausimas „kaip mes tai padarysime?“, kurio atsakymas galėtų užimti nemažą dalį patobulinimų projektavimo darbo, dabar tiesiog nevertas (kaip ir klausimas apie modelio keitimo įtaką darbo procesams ).
Tai nereiškia, kad analitikų tokioje sistemoje visai nereikia – kažkas vis tiek turi perdirbti objektų rinkinį su atributais ir sugalvoti, kur ir kaip visa tai įkelti. Tačiau darbo kiekis, taip pat klaidos tikimybė ir kaina žymiai sumažėja. Tiek analizės stadijoje, tiek ETL kūrimo metu, kuri didžiąja dalimi gali būti redukuojama iki metaduomenų redagavimo.
Tamsi pusė
Dėl viso to, kas išdėstyta pirmiau, abu metodai yra tikrai lankstūs, technologiškai pažangūs ir tinkami nuolatiniam tobulėjimui. Žinoma, yra ir „statinė tepalu“, apie kurią, manau, jau galima numanyti.
Duomenų skaidymas, kuriuo grindžiamas lanksčių architektūrų moduliškumas, padidina lentelių skaičių ir atitinkamai virš galvos jungiasi imant mėginius. Norint paprasčiausiai gauti visus matmens atributus, klasikinėje parduotuvėje pakanka vieno pasirinkimo, tačiau lanksčiai architektūrai reikės daugybės sujungimų. Be to, jei visi šie ataskaitų sujungimai gali būti parašyti iš anksto, analitikai, įpratę rašyti SQL ranka, nukentės dvigubai.
Yra keletas faktų, kurie palengvina šią situaciją:
Dirbant su dideliais matmenimis, visi jo atributai beveik niekada nenaudojami vienu metu. Tai reiškia, kad sujungimų gali būti mažiau, nei atrodo iš pirmo žvilgsnio iš modelio. Priskirdama atributus palydovams, Data Vault taip pat gali atsižvelgti į numatomą bendrinimo dažnumą. Tuo pačiu metu patys šakotuvai arba inkarai pirmiausia reikalingi pakaitalams generuoti ir atvaizduoti įkėlimo etape ir retai naudojami užklausose (tai ypač pasakytina apie inkarus).
Visi sujungimai yra raktu. Be to, „suspaustas“ duomenų saugojimo būdas sumažina lentelių nuskaitymo išlaidas ten, kur jų reikia (pavyzdžiui, filtruojant pagal atributo reikšmę). Tai gali lemti tai, kad mėginių ėmimas iš normalizuotos duomenų bazės su daugybe sujungimų bus dar greitesnis nei vieno didelio matmens nuskaitymas su daugybe versijų eilutėje.
Pavyzdžiui, čia Straipsnyje pateikiamas išsamus lyginamasis Anchor modelio veikimo testas su pavyzdžiu iš vienos lentelės.
Daug kas priklauso nuo variklio. Daugelis šiuolaikinių platformų turi vidinius sujungimo optimizavimo mechanizmus. Pavyzdžiui, MS SQL ir Oracle gali „praleisti“ sujungimus į lenteles, jei jų duomenys niekur nenaudojami, išskyrus kitus sujungimus ir neturi įtakos galutiniam pasirinkimui (lentelės/jungimo pašalinimas), o MPP Vertica , pasirodė esąs puikus Inkaro modelio variklis, nes užklausos planas buvo optimizuotas rankiniu būdu. Kita vertus, „Anchor Model“ saugojimas, pavyzdžiui, „Click House“, kuris turi ribotą prisijungimo palaikymą, kol kas neatrodo labai gera idėja.
Be to, abiejose architektūrose yra specialūs judesiai, palengvinantis duomenų prieigą (tiek užklausos našumo požiūriu, tiek galutiniams vartotojams). Pavyzdžiui, Taško laiko lentelės „Data Vault“ arba specialios lentelės funkcijos Inkaro modelyje.
Iš viso
Pagrindinė nagrinėjamų lanksčių architektūrų esmė yra jų „dizaino“ moduliškumas.
Būtent ši savybė leidžia:
- Po tam tikro pirminio pasiruošimo, susijusio su metaduomenų diegimu ir pagrindinių ETL algoritmų rašymu, greitai pateikti klientui pirmąjį rezultatą kelių ataskaitų, kuriose yra duomenų iš kelių šaltinio objektų, forma. Nebūtina iki galo apgalvoti (net ir aukščiausiu lygiu) viso objekto modelio.
- Duomenų modelis gali pradėti veikti (ir būti naudingas) tik su 2–3 objektais ir tada augti palaipsniui (dėl inkaro modelio Nikolajus geras palyginimas su grybiena).
- Dauguma patobulinimų, įskaitant dalykinės srities išplėtimą ir naujų šaltinių įtraukimą neturi įtakos esamam funkcionalumui ir nekelia pavojaus sugadinti kažką, kas jau veikia.
- Dėl suskaidymo į standartinius elementus ETL procesai tokiose sistemose atrodo vienodai, jų rašymas tinkamas algoritmizavimui ir galiausiai automatizavimas.
Šio lankstumo kaina yra spektaklis. Tai nereiškia, kad tokiuose modeliuose neįmanoma pasiekti priimtinų eksploatacinių savybių. Dažniau jums gali prireikti daugiau pastangų ir dėmesio detalėms, kad pasiektumėte norimus rodiklius.
Apps "
Subjektų tipai Duomenų saugykla
Daugiau informacijos apie „Data Vault“:
Subjektų tipai Inkaro modelis
Daugiau informacijos apie inkaro modelį:
Suvestinė lentelė su bendrais nagrinėjamų metodų bruožais ir skirtumais:
Šaltinis: www.habr.com