Zhvillimi i një objekti magazinimi është një ndërmarrje e gjatë dhe serioze.
Shumë në jetën e një projekti varet nga sa mirë modeli i objektit dhe struktura bazë janë menduar në fillim.
Qasja e pranuar përgjithësisht ka qenë dhe mbetet variante të ndryshme të kombinimit të skemës së yjeve me formën e tretë normale. Si rregull, sipas parimit: të dhënat fillestare - 3NF, vitrinat - yll. Kjo qasje, e testuar me kohë dhe e mbështetur nga një sasi e madhe kërkimesh, është gjëja e parë (dhe ndonjëherë e vetmja) që i vjen në mendje një specialisti me përvojë të DWH kur mendon se si duhet të duket një depo analitike.
Nga ana tjetër, biznesi në përgjithësi dhe kërkesat e klientëve në veçanti priren të ndryshojnë shpejt, dhe të dhënat priren të rriten si "në thellësi" dhe "në gjerësi". Dhe këtu shfaqet disavantazhi kryesor i një ylli - i kufizuar fleksibilitet.
Dhe nëse në jetën tuaj të qetë dhe komode si zhvillues i DWH papritmas:
- u ngrit detyra "të bëjmë të paktën diçka shpejt, dhe pastaj do të shohim";
- u shfaq një projekt me zhvillim të shpejtë, me lidhjen e burimeve të reja dhe ripërpunimin e modelit të biznesit të paktën një herë në javë;
- është shfaqur një klient i cili nuk e ka idenë se si duhet të duket sistemi dhe cilat funksione duhet të kryejë në fund të fundit, por është gati të eksperimentojë dhe të rafinojë vazhdimisht rezultatin e dëshiruar duke i afruar vazhdimisht;
- Menaxheri i projektit hyri me lajmin e mirë: "Dhe tani ne kemi të shkathët!"
Ose nëse thjesht jeni të interesuar të zbuloni se si mund të ndërtoni objekte magazinimi - mirë se vini në prerje!
Çfarë do të thotë "fleksibilitet"?
Së pari, le të përcaktojmë se cilat veçori duhet të ketë një sistem në mënyrë që të quhet "fleksibël".
Më vete, vlen të përmendet se pronat e përshkruara duhet të lidhen në mënyrë specifike sistemi, jo për të procesi zhvillimin e saj. Prandaj, nëse dëshironi të lexoni për Agile si një metodologji zhvillimi, është më mirë të lexoni artikuj të tjerë. Për shembull, pikërisht atje, në Habré, ka shumë materiale interesante (si и Dhe ).
Kjo nuk do të thotë se procesi i zhvillimit dhe struktura e magazinës së të dhënave nuk janë plotësisht të lidhura. Në përgjithësi, duhet të jetë shumë më e lehtë për të zhvilluar një depo Agile për një arkitekturë të shkathët. Sidoqoftë, në praktikë, më shpesh ka mundësi me zhvillimin e shkathët të DWH klasike sipas Kimbal dhe DataVault - sipas Waterfall, sesa rastësi të lumtura të fleksibilitetit në dy format e tij në një projekt.
Pra, çfarë aftësish duhet të ketë ruajtja fleksibël? Këtu ka tre pika:
- Dorëzimi i hershëm dhe kthimi i shpejtë - kjo do të thotë që në mënyrë ideale rezultati i parë i biznesit (për shembull, raportet e para të punës) duhet të merret sa më shpejt që të jetë e mundur, domethënë edhe para se i gjithë sistemi të projektohet dhe zbatohet plotësisht. Për më tepër, çdo rishikim i mëvonshëm duhet gjithashtu të marrë sa më pak kohë të jetë e mundur.
- Përsosje përsëritëse - kjo do të thotë që çdo përmirësim i mëvonshëm në mënyrë ideale nuk duhet të ndikojë në funksionalitetin që tashmë po funksionon. Është ky moment që shpesh bëhet makthi më i madh në projekte të mëdha - herët a vonë, objektet individuale fillojnë të fitojnë aq shumë lidhje sa që bëhet më e lehtë të përsërisësh plotësisht logjikën në një kopje afër sesa të shtosh një fushë në një tabelë ekzistuese. Dhe nëse jeni të habitur që analizimi i ndikimit të përmirësimeve në objektet ekzistuese mund të marrë më shumë kohë sesa vetë përmirësimet, me shumë mundësi nuk keni punuar ende me depo të mëdha të dhënash në banka ose telekom.
- Duke iu përshtatur vazhdimisht kërkesave në ndryshim të biznesit - struktura e përgjithshme e objektit duhet të projektohet jo vetëm duke marrë parasysh zgjerimin e mundshëm, por me shpresën që drejtimi i këtij zgjerimi të ardhshëm nuk mund të ëndërrohej as në fazën e projektimit.
Dhe po, plotësimi i të gjitha këtyre kërkesave në një sistem është i mundur (sigurisht, në raste të caktuara dhe me disa rezerva).
Më poshtë do të shqyrtoj dy nga metodologjitë më të njohura të dizajnit të shkathët për depot e të dhënave - Modeli i ankorimit и Kasaforta e të dhënave. Janë lënë jashtë kllapave teknika të tilla të shkëlqyera si, për shembull, EAV, 6NF (në formën e tij të pastër) dhe gjithçka që lidhet me zgjidhjet NoSQL - jo sepse ato janë disi më keq, dhe as sepse në këtë rast artikulli do të kërcënonte të merrte vëllimi i diserit mesatar. Është thjesht se e gjithë kjo lidhet me zgjidhjet e një klase paksa të ndryshme - ose me teknikat që mund të përdorni në raste specifike, pavarësisht nga arkitektura e përgjithshme e projektit tuaj (si EAV), ose me paradigma të tjera globale të ruajtjes së informacionit (të tilla si bazat e të dhënave grafike dhe opsione të tjera NoSQL).
Problemet e qasjes "klasike" dhe zgjidhjet e tyre në metodologji fleksibël
Me qasjen "klasike" nënkuptoj yllin e vjetër të mirë (pavarësisht nga zbatimi specifik i shtresave themelore, mund të më falin ndjekësit e Kimball, Inmon dhe CDM).
1. Kardinaliteti i ngurtë i lidhjeve
Ky model bazohet në një ndarje të qartë të të dhënave në Dimensioni и fakte. Dhe kjo, dreqin, është logjike - në fund të fundit, analiza e të dhënave në shumicën dërrmuese të rasteve zbret në analizën e treguesve (fakteve) të caktuara numerike në seksione (dimensione) të caktuara.
Në këtë rast, lidhjet midis objekteve krijohen në formën e marrëdhënieve midis tabelave duke përdorur një çelës të huaj. Kjo duket mjaft e natyrshme, por menjëherë çon në kufizimin e parë të fleksibilitetit - përcaktim i rreptë i kardinalitetit të lidhjeve.
Kjo do të thotë që në fazën e hartimit të tabelës, duhet të përcaktoni me saktësi për çdo palë objektesh të lidhura nëse ato mund të lidhen sa më shumë, ose vetëm 1-me-shumë, dhe "në cilin drejtim". Kjo drejtpërdrejt përcakton se cila tabelë do të ketë çelësin primar dhe cila do të ketë çelësin e huaj. Ndryshimi i këtij qëndrimi kur pranohen kërkesa të reja ka shumë të ngjarë të çojë në një ripërpunim të bazës.
Për shembull, kur hartoni objektin e "pranimit të parave të gatshme", ju, duke u mbështetur në betimet e departamentit të shitjeve, parashtruat mundësinë e veprimit një promovim për disa pozicione kontrolli (por jo anasjelltas):
Dhe pas ca kohësh, kolegët prezantuan një strategji të re marketingu në të cilën ata mund të veprojnë në të njëjtin pozicion disa promovime në të njëjtën kohë. Dhe tani ju duhet të modifikoni tabelat duke e ndarë marrëdhënien në një objekt të veçantë.
(Të gjitha objektet e prejardhura në të cilat kontrolli i promovimit është bashkuar tani gjithashtu duhet të përmirësohen).
Marrëdhëniet në Data Vault dhe Model Anchor
Shmangia e kësaj situate doli të ishte mjaft e thjeshtë: nuk duhet t'i besoni departamentit të shitjeve për ta bërë këtë. të gjitha lidhjet fillimisht ruhen në tabela të veçanta dhe përpunoni atë si shumë-për-shumë.
Kjo qasje u propozua Dan Linstedt si pjesë e paradigmës Kasaforta e të dhënave dhe i mbështetur plotësisht Lars Rönnbäck в Modeli i ankorimit.
Si rezultat, ne marrim tiparin e parë dallues të metodologjive fleksibël:
Marrëdhëniet midis objekteve nuk ruhen në atributet e entiteteve mëmë, por janë një lloj objekti i veçantë.
В Kasaforta e të dhënave tabela të tilla lidhëse quhen lidhjedhe në Modeli i ankorimit - Tie. Në pamje të parë, ato janë shumë të ngjashme, megjithëse dallimet e tyre nuk mbarojnë me emrin (i cili do të diskutohet më poshtë). Në të dyja arkitekturat, tabelat e lidhjeve mund të lidhen çdo numër subjektesh (jo domosdoshmërisht 2).
Kjo tepricë, në shikim të parë, ofron fleksibilitet të konsiderueshëm për modifikime. Një strukturë e tillë bëhet tolerante jo vetëm ndaj ndryshimeve në kardinalitetin e lidhjeve ekzistuese, por edhe ndaj shtimit të atyre të reja - nëse tani një pozicion kontrolli ka gjithashtu një lidhje me arkëtarin që e depërtoi, shfaqja e një lidhjeje të tillë thjesht do të bëhet një shtesë mbi tabelat ekzistuese pa ndikuar në ndonjë objekt dhe proces ekzistues.
2. Dyfishimi i të dhënave
Problemi i dytë i zgjidhur nga arkitekturat fleksibël është më pak i dukshëm dhe është i natyrshëm në radhë të parë. Matjet e tipit SCD2 (ndryshon ngadalë dimensionet e tipit të dytë), edhe pse jo vetëm ato.
Në një magazinë klasike, një dimension është zakonisht një tabelë që përmban një çelës zëvendësues (si një PK) dhe një grup çelësash dhe atributesh biznesi në kolona të veçanta.
Nëse një dimension mbështet versionimin, kufijtë e vlefshmërisë së versionit shtohen në grupin standard të fushave dhe disa versione shfaqen në depo për një rresht në burim (një për çdo ndryshim në atributet e versionuara).
Nëse një dimension përmban të paktën një atribut të versionit që ndryshon shpesh, numri i versioneve të një dimensioni të tillë do të jetë mbresëlënës (edhe nëse atributet e mbetura nuk janë versionuar ose nuk ndryshojnë kurrë), dhe nëse ka disa atribute të tilla, numri i versioneve mund të rriten në mënyrë eksponenciale nga numri i tyre. Ky dimension mund të zërë një sasi të konsiderueshme të hapësirës në disk, megjithëse shumë nga të dhënat që ruan janë thjesht dublikatë të vlerave të pandryshueshme të atributeve nga rreshtat e tjerë.
Në të njëjtën kohë, përdoret gjithashtu shumë shpesh denormalizimi — disa atribute ruhen qëllimisht si vlerë, dhe jo si lidhje me një libër referimi ose një dimension tjetër. Kjo qasje shpejton aksesin e të dhënave, duke reduktuar numrin e lidhjeve kur aksesoni një dimension.
Në mënyrë tipike kjo çon në i njëjti informacion ruhet njëkohësisht në disa vende. Për shembull, informacioni për rajonin e vendbanimit dhe kategorinë e klientit mund të ruhet njëkohësisht në dimensionet "Klient" dhe në faktet "Blerje", "Dorëzimi" dhe "Thirrjet e Qendrës së Thirrjeve", si dhe në "Klient - Menaxheri i Klientit". ” Tabela e lidhjeve.
Në përgjithësi, sa më sipër vlen për dimensionet e rregullta (të paversionuara), por në ato të versionuara ato mund të kenë një shkallë të ndryshme: shfaqja e një versioni të ri të një objekti (veçanërisht në retrospektivë) çon jo vetëm në përditësimin e të gjitha të lidhura. tabela, por për pamjen kaskadë të versioneve të reja të objekteve të lidhura - kur Tabela 1 përdoret për të ndërtuar Tabelën 2, dhe Tabela 2 përdoret për të ndërtuar Tabelën 3, etj. Edhe nëse asnjë atribut i vetëm i Tabelës 1 nuk është i përfshirë në ndërtimin e Tabelës 3 (dhe atribute të tjera të Tabelës 2 të marra nga burime të tjera janë të përfshira), versionimi i këtij konstruksioni do të çojë minimalisht në shpenzime shtesë, dhe në maksimum në shtesë. versionet në tabelën 3. e cila nuk ka të bëjë fare me të dhe më tej në zinxhir.
3. Kompleksiteti jolinear i ripunimit
Në të njëjtën kohë, çdo vitrinë e re e ndërtuar mbi bazën e një tjetri rrit numrin e vendeve ku të dhënat mund të "ndryshojnë" kur bëhen ndryshime në ETL. Kjo, nga ana tjetër, çon në një rritje të kompleksitetit (dhe kohëzgjatjes) të çdo rishikimi pasues.
Nëse sa më sipër përshkruan sisteme me procese ETL të modifikuara rrallë, mund të jetoni në një paradigmë të tillë - thjesht duhet të siguroheni që modifikimet e reja të bëhen në mënyrë korrekte për të gjitha objektet e lidhura. Nëse rishikimet ndodhin shpesh, gjasat për të "humbur" aksidentalisht disa lidhje rriten ndjeshëm.
Nëse, përveç kësaj, marrim parasysh se ETL "i versionuar" është dukshëm më i ndërlikuar se ai "i paversionuar", bëhet mjaft e vështirë të shmangen gabimet kur përditësohet shpesh i gjithë ky objekt.
Ruajtja e objekteve dhe atributeve në Data Vault dhe Anchor Model
Qasja e propozuar nga autorët e arkitekturave fleksibël mund të formulohet si më poshtë:
Është e nevojshme të veçohet ajo që ndryshon nga ajo që mbetet e njëjtë. Kjo do të thotë, ruajini çelësat veçmas nga atributet.
Megjithatë, nuk duhet ngatërruar jo i versionuar atribut me e pandryshuar: i pari nuk ruan historinë e ndryshimeve të tij, por mund të ndryshojë (për shembull, kur korrigjoni një gabim në hyrje ose merrni të dhëna të reja); i dyti nuk ndryshon kurrë.
Pikëpamjet ndryshojnë në atë që saktësisht mund të konsiderohet e pandryshueshme në Data Vault dhe Modelin Anchor.
Nga pikëpamja arkitekturore Kasaforta e të dhënave, mund të konsiderohet i pandryshuar komplet i tërë çelësash - natyrore (NJP i organizatës, kodi i produktit në sistemin burimor, etj.) dhe zëvendësues. Në këtë rast, atributet e mbetura mund të ndahen në grupe sipas burimit dhe/ose shpeshtësisë së ndryshimeve dhe Mbani një tabelë të veçantë për secilin grup me një grup të pavarur versionesh.
Në paradigmë Modeli i ankorimit konsiderohet e pandryshuar vetëm çelës zëvendësues thelbi. Çdo gjë tjetër (përfshirë çelësat natyrorë) është vetëm një rast i veçantë i atributeve të tij. Ku të gjitha atributet janë të pavarura nga njëra-tjetra si parazgjedhje, pra për çdo atribut a tabela e veçantë.
В Kasaforta e të dhënave thirren tabelat që përmbajnë çelësa entiteti Hubami. Hub-et përmbajnë gjithmonë një grup fiks fushash:
- Çelësat e entitetit natyror
- Çelësi zëvendësues
- Lidhja me burimin
- Regjistroni kohën e shtimit
Postimet në Hubs kurrë mos ndryshoni dhe nuk keni versione. Nga jashtë, shpërndarësit janë shumë të ngjashëm me tabelat e tipit ID-hartë të përdorura në disa sisteme për të gjeneruar zëvendësues, megjithatë, rekomandohet të përdoret një hash nga një grup çelësash biznesi si zëvendësues në Data Vault. Kjo qasje thjeshton ngarkimin e marrëdhënieve dhe atributeve nga burimet (nuk ka nevojë të bashkohet me shpërndarësin për të marrë një zëvendësues, thjesht llogarit hash-in e një çelësi natyror), por mund të shkaktojë probleme të tjera (të lidhura, për shembull, me përplasjet, rastet dhe të paprintueshme karaktere në tastet e vargjeve, etj. .p.), prandaj nuk pranohet përgjithësisht.
Të gjitha atributet e tjera të entitetit ruhen në tabela të veçanta të quajtura Satelitët. Një qendër mund të ketë disa satelitë që ruajnë grupe të ndryshme atributesh.
Shpërndarja e atributeve midis satelitëve ndodh sipas parimit ndryshimi i përbashkët - në një satelit mund të ruhen atribute të paversionuara (për shembull, data e lindjes dhe SNILS për një individ), në një tjetër - ato të versioneve që ndryshojnë rrallë (për shembull, mbiemri dhe numri i pasaportës), në të tretën - ato që ndryshojnë shpesh (për shembull, adresa e dorëzimit, kategoria, data e porosisë së fundit, etj.). Në këtë rast, versionimi kryhet në nivelin e satelitëve individualë, dhe jo të njësisë në tërësi, kështu që këshillohet që të shpërndahen atributet në mënyrë që kryqëzimi i versioneve brenda një sateliti të jetë minimal (gjë që zvogëlon numrin total të versioneve të ruajtura ).
Gjithashtu, për të optimizuar procesin e ngarkimit të të dhënave, atributet e marra nga burime të ndryshme shpesh përfshihen në satelitë individualë.
Satelitët komunikojnë me Hub-in nëpërmjet çelësi i huaj (që korrespondon me kardinalitetin 1-në-shumë). Kjo do të thotë që vlerat e shumta të atributeve (për shembull, numrat e telefonit të shumëfishtë të kontaktit për një klient) mbështeten nga kjo arkitekturë "e parazgjedhur".
В Modeli i ankorimit quhen tabelat që ruajnë çelësat Ankorat. Dhe ata mbajnë:
- Vetëm çelësat zëvendësues
- Lidhja me burimin
- Regjistroni kohën e shtimit
Janë konsideruar çelësat natyrorë nga këndvështrimi i Modelit të Ankorimit atributet e zakonshme. Ky opsion mund të duket më i vështirë për t'u kuptuar, por jep shumë më tepër hapësirë për identifikimin e objektit.
Për shembull, nëse të dhënat për të njëjtin entitet mund të vijnë nga sisteme të ndryshme, secila prej të cilave përdor çelësin e vet natyror. Në Data Vault, kjo mund të çojë në struktura mjaft të rënda të disa shpërndarësve (një për burim + një version kryesor unifikues), ndërsa në modelin Anchor, çelësi natyror i çdo burimi bie në atributin e tij dhe mund të përdoret kur ngarkohet në mënyrë të pavarur nga gjithë të tjerët.
Por këtu ka edhe një pikë tinëzare: nëse atributet nga sisteme të ndryshme kombinohen në një entitet, ka shumë të ngjarë që të ketë disa rregullat e "ngjitjes", me anë të së cilës sistemi duhet të kuptojë se regjistrimet nga burime të ndryshme korrespondojnë me një shembull të njësisë ekonomike.
В Kasaforta e të dhënave këto rregulla me shumë gjasa do të përcaktojnë formimin “Qendra zëvendësuese” e entit master dhe të mos ndikojë në asnjë mënyrë në Hub-et që ruajnë çelësat e burimit natyror dhe atributet e tyre origjinale. Nëse në një moment ndryshojnë rregullat e bashkimit (ose atributet me të cilat kryhet ai përditësohen), do të mjaftojë të riformatoni qendrat zëvendësuese.
В Modeli i ankorimit një ent i tillë ka shumë të ngjarë të ruhet në e vetmja spirancë. Kjo do të thotë se të gjitha atributet, pa marrë parasysh se nga cili burim vijnë, do të jenë të lidhura me të njëjtin zëvendësues. Ndarja e regjistrimeve të bashkuara gabimisht dhe, në përgjithësi, monitorimi i rëndësisë së bashkimit në një sistem të tillë mund të jetë shumë më i vështirë, veçanërisht nëse rregullat janë mjaft komplekse dhe ndryshojnë shpesh, dhe i njëjti atribut mund të merret nga burime të ndryshme (edhe pse sigurisht që është e mundur, pasi secili version i atributit ruan një lidhje me burimin e tij).
Në çdo rast, nëse sistemi juaj supozohet të zbatojë funksionalitetin deduplikimi, shkrirja e të dhënave dhe elemente të tjera MDM, ia vlen t'i kushtohet vëmendje e veçantë aspekteve të ruajtjes së çelësave natyrorë në metodologjitë e shkathëta. Ka të ngjarë që dizajni më i madh i Data Vault të jetë papritmas më i sigurt për sa i përket gabimeve të bashkimit.
Modeli i ankorimit siguron gjithashtu një lloj objekti shtesë të quajtur Nyjë në thelb është e veçantë lloj i degjeneruar i spirancës, i cili mund të përmbajë vetëm një atribut. Nyjet supozohet të përdoren për të ruajtur drejtoritë e sheshta (për shembull, gjinia, statusi martesor, kategoria e shërbimit ndaj klientit, etj.). Ndryshe nga Anchor, Nyja nuk ka tabela të atributeve të lidhura, dhe atributi i tij i vetëm (emri) ruhet gjithmonë në të njëjtën tabelë me çelësin. Nyjet lidhen me Anchors me anë të tabelave lidhëse (Tie) në të njëjtën mënyrë si Anchors janë të lidhura me njëra-tjetrën.
Nuk ka asnjë mendim të qartë në lidhje me përdorimin e Nyjeve. Për shembull, , i cili promovon në mënyrë aktive përdorimin e Modelit të Ankorimit në Rusi, beson (jo pa arsye) se për asnjë libër të vetëm referimi nuk mund të thuhet me siguri se ai gjithmonë do të jetë statike dhe me një nivel, kështu që është më mirë të përdorni menjëherë një Anchor të plotë për të gjitha objektet.
Një tjetër ndryshim i rëndësishëm midis Data Vault dhe modelit Anchor është disponueshmëria atributet e lidhjeve:
В Kasaforta e të dhënave Lidhjet janë të njëjtat objekte të plota si Hubs dhe mund të kenë atributet e veta. Në Modeli i ankorimit Lidhjet përdoren vetëm për të lidhur Anchors dhe nuk mund të kenë atributet e tyre. Ky ndryshim rezulton në qasje dukshëm të ndryshme të modelimit fakte, e cila do të diskutohet më tej.
Ruajtja e fakteve
Para kësaj, ne folëm kryesisht për modelimin e matjes. Faktet janë pak më pak të qarta.
В Kasaforta e të dhënave një objekt tipik për ruajtjen e fakteve është Lidhje, në satelitët e të cilit shtohen tregues realë.
Kjo qasje duket intuitive. Ai siguron qasje të lehtë në treguesit e analizuar dhe në përgjithësi është i ngjashëm me një tabelë tradicionale të fakteve (vetëm treguesit nuk ruhen në vetë tabelën, por në tabelën "fqinje"). Por ka edhe gracka: një nga modifikimet tipike të modelit - zgjerimi i çelësit të faktit - kërkon duke shtuar një çelës të ri të huaj në Link. Dhe kjo, nga ana tjetër, "thyen" modularitetin dhe potencialisht shkakton nevojën për modifikime në objekte të tjera.
В Modeli i ankorimit Një lidhje nuk mund të ketë atributet e veta, kështu që kjo qasje nuk do të funksionojë - absolutisht të gjitha atributet dhe treguesit duhet të lidhen me një spirancë specifike. Përfundimi nga kjo është i thjeshtë - Çdo fakt gjithashtu ka nevojë për spirancën e vet. Për disa nga ato që jemi mësuar t'i perceptojmë si fakte, kjo mund të duket e natyrshme - për shembull, fakti i një blerjeje mund të reduktohet në mënyrë të përkryer në objektin "porosi" ose "marrje", vizita e një siti në një seancë, etj. Por ka edhe fakte për të cilat nuk është aq e lehtë të gjesh një "objekt transportues" të tillë natyror - për shembull, mbetjet e mallrave në magazina në fillim të çdo dite.
Prandaj, problemet me modularitetin kur zgjerohet një çelës fakti në modelin Anchor nuk lindin (mjafton thjesht të shtoni një Marrëdhënie të re në Anchor përkatës), por dizajnimi i një modeli për të shfaqur faktet është më pak i paqartë; mund të shfaqen spiranca "artificiale". që shfaqin në mënyrë të paqartë modelin e objektit të biznesit.
Si arrihet fleksibiliteti
Ndërtimi që rezulton në të dyja rastet përmban dukshëm më shumë tabelasesa matja tradicionale. Por mund të marrë dukshëm më pak hapësirë në disk me të njëjtin grup atributesh të versionuara si dimensioni tradicional. Natyrisht, nuk ka magji këtu - ka të bëjë me normalizimin. Duke shpërndarë atribute nëpër Satelitë (në Data Vault) ose tabela individuale (Modeli Anchor), ne reduktojmë (ose eliminojmë plotësisht) dyfishimi i vlerave të disa atributeve kur ndryshoni të tjerët.
Për Kasaforta e të dhënave fitimet do të varen nga shpërndarja e atributeve ndërmjet satelitëve, dhe për Modeli i ankorimit - është pothuajse drejtpërdrejt proporcionale me numrin mesatar të versioneve për objekt matjeje.
Megjithatë, kursimi i hapësirës është një avantazh i rëndësishëm, por jo kryesor, i ruajtjes së veçmas atributeve. Së bashku me ruajtjen e veçantë të marrëdhënieve, kjo qasje e bën dyqanin dizajn modular. Kjo do të thotë se shtimi i atributeve individuale dhe fushave të tëra lëndore në një model të tillë duket si superstrukturë mbi një grup ekzistues objektesh pa i ndryshuar ato. Dhe kjo është pikërisht ajo që i bën metodologjitë e përshkruara fleksibël.
Kjo gjithashtu i ngjan kalimit nga prodhimi i copave në prodhimin masiv - nëse në qasjen tradicionale secila tabelë e modelit është unike dhe kërkon vëmendje të veçantë, atëherë në metodologjitë fleksibël është tashmë një grup "pjesësh" standarde. Nga njëra anë, ka më shumë tabela, dhe proceset e ngarkimit dhe marrjes së të dhënave duhet të duken më të ndërlikuara. Nga ana tjetër, ato bëhen tipike. Që do të thotë se mund të ketë i automatizuar dhe i drejtuar nga metadata. Pyetja "si do ta shtrojmë?", përgjigja e së cilës mund të marrë një pjesë të konsiderueshme të punës për hartimin e përmirësimeve, tani thjesht nuk ia vlen (si dhe pyetja për ndikimin e ndryshimit të modelit në proceset e punës ).
Kjo nuk do të thotë që analistët nuk nevojiten fare në një sistem të tillë - dikush ende duhet të punojë nëpër grupin e objekteve me atribute dhe të kuptojë se ku dhe si t'i ngarkojë të gjitha. Por sasia e punës, si dhe gjasat dhe kostoja e një gabimi, janë ulur ndjeshëm. Si në fazën e analizës ashtu edhe gjatë zhvillimit të ETL, e cila në një pjesë të konsiderueshme mund të reduktohet në redaktim të meta të dhënave.
Ana e errët
Të gjitha sa më sipër i bëjnë të dyja qasjet vërtet fleksibël, teknologjikisht të avancuara dhe të përshtatshme për përmirësime të përsëritura. Sigurisht, ekziston edhe një "fuçi në vaj", për të cilën mendoj se tashmë mund ta merrni me mend.
Zbërthimi i të dhënave, i cili qëndron në themel të modularitetit të arkitekturave fleksibël, çon në një rritje të numrit të tabelave dhe, në përputhje me rrethanat, lart për t'u bashkuar gjatë marrjes së mostrave. Për të marrë thjesht të gjitha atributet e një dimensioni, në një dyqan klasik mjafton një përzgjedhje, por një arkitekturë fleksibël do të kërkojë një seri të tërë lidhjesh. Për më tepër, nëse të gjitha këto bashkime për raporte mund të shkruhen paraprakisht, atëherë analistët që janë mësuar të shkruajnë SQL me dorë do të vuajnë dyfish.
Ka disa fakte që e bëjnë këtë situatë më të lehtë:
Kur punoni me dimensione të mëdha, të gjitha atributet e tij pothuajse kurrë nuk përdoren njëkohësisht. Kjo do të thotë se mund të ketë më pak bashkime sesa duket në pamje të parë në model. Data Vault gjithashtu mund të marrë parasysh frekuencën e pritshme të ndarjes kur cakton atributet për satelitët. Në të njëjtën kohë, vetë Hubs ose Anchors nevojiten kryesisht për gjenerimin dhe hartografimin e zëvendësuesve në fazën e ngarkimit dhe përdoren rrallë në pyetje (kjo është veçanërisht e vërtetë për Anchors).
Të gjitha lidhjet janë me çelës. Për më tepër, një mënyrë më "e ngjeshur" e ruajtjes së të dhënave zvogëlon koston e përgjithshme të tabelave të skanimit aty ku është e nevojshme (për shembull, kur filtrohet sipas vlerës së atributit). Kjo mund të çojë në faktin se marrja e mostrave nga një bazë të dhënash e normalizuar me një sërë lidhjesh do të jetë edhe më i shpejtë se skanimi i një dimensioni të rëndë me shumë versione për rresht.
Për shembull, këtu brenda Artikulli përmban një test të detajuar krahasues të performancës së modelit Anchor me një mostër nga një tabelë.
Shumë varet nga motori. Shumë platforma moderne kanë mekanizma të brendshëm të optimizimit të bashkimit. Për shembull, MS SQL dhe Oracle mund të "kapërcejnë" bashkimet në tabela nëse të dhënat e tyre nuk përdoren askund, përveç lidhjeve të tjera dhe nuk ndikojnë në përzgjedhjen përfundimtare (eliminimin e tabelës/bashkimit) dhe MPP Vertica , është dëshmuar të jetë një motor i shkëlqyer për Modelin Anchor, duke pasur parasysh disa optimizime manuale të planit të pyetjes. Nga ana tjetër, ruajtja e modelit Anchor, për shembull, në Click House, e cila ka mbështetje të kufizuar për bashkimin, nuk duket ende si një ide shumë e mirë.
Përveç kësaj, për të dyja arkitekturat ekzistojnë lëvizje të veçanta, duke e bërë më të lehtë aksesin e të dhënave (si nga pikëpamja e performancës së pyetjeve ashtu edhe për përdoruesit fundorë). Për shembull, Tabelat Point-In-Time në Data Vault ose funksione të veçanta të tabelës në modelin Anchor.
Në total
Thelbi kryesor i arkitekturave fleksibël të konsideruar është modulariteti i "dizajnit" të tyre.
Është kjo pronë që lejon:
- Pas disa përgatitjeve fillestare në lidhje me vendosjen e meta të dhënave dhe shkrimin e algoritmeve bazë ETL, siguroni shpejt klientit rezultatin e parë në formën e disa raporteve që përmbajnë të dhëna nga vetëm disa objekte burimore. Nuk është e nevojshme të mendoni plotësisht (madje edhe në nivelin më të lartë) të gjithë modelin e objektit.
- Një model i të dhënave mund të fillojë të funksionojë (dhe të jetë i dobishëm) me vetëm 2-3 objekte dhe më pas rriten gradualisht (lidhur me modelin e Anchor Nikolai krahasim i bukur me miceli).
- Shumica e përmirësimeve, duke përfshirë zgjerimin e fushës së temës dhe shtimin e burimeve të reja nuk ndikon në funksionalitetin ekzistues dhe nuk paraqet rrezik për të prishur diçka që tashmë funksionon.
- Falë zbërthimit në elementë standardë, proceset ETL në sisteme të tilla duken njësoj, shkrimi i tyre i jep vetes algorithmizimit dhe, në fund të fundit, automatizimi.
Çmimi i këtij fleksibiliteti është performanca. Kjo nuk do të thotë se është e pamundur të arrihet performanca e pranueshme në modele të tilla. Më shpesh sesa jo, thjesht mund t'ju duhet më shumë përpjekje dhe vëmendje ndaj detajeve për të arritur metrikat që dëshironi.
Apps
Llojet e subjekteve Kasaforta e të dhënave
Më shumë informacion rreth Data Vault:
Llojet e subjekteve Modeli i ankorimit
Më shumë detaje rreth modelit Anchor:
Tabela përmbledhëse me veçoritë e përbashkëta dhe dallimet e qasjeve të konsideruara:
Burimi: www.habr.com