Razvoj skladišča je dolgotrajen in resen podvig.
Veliko v življenju projekta je odvisno od tega, kako dobro sta objektni model in osnovna struktura premišljena na začetku.
Splošno sprejet pristop je bil in ostajajo različne različice kombiniranja zvezdne sheme s tretjo normalno obliko. Praviloma po načelu: začetni podatki - 3NF, vitrine - zvezda. Ta pristop, preizkušen s časom in podprt z veliko količino raziskav, je prva (in včasih edina) stvar, ki pride na misel izkušenemu strokovnjaku za DWH, ko razmišlja o tem, kako naj bi izgledal analitični repozitorij.
Po drugi strani pa se poslovanje na splošno in zlasti zahteve kupcev hitro spreminjajo, podatki pa rastejo tako »v globino« kot »v širino«. In tu se pokaže glavna slabost zvezde – omejenost prilagodljivost.
In če v vašem mirnem in prijetnem življenju kot razvijalec DWH nenadoma:
- pojavila se je naloga "na hitro narediti vsaj nekaj, potem pa bomo videli";
- pojavil se je hitro razvijajoč se projekt s povezovanjem novih virov in predelavo poslovnega modela vsaj enkrat tedensko;
- pojavila se je stranka, ki nima pojma, kako naj bi sistem izgledal in katere funkcije naj bi na koncu opravljal, vendar je pripravljen eksperimentirati in dosledno izpopolnjevati želeni rezultat ter se mu vztrajno približevati;
- Vodja projekta je prišel z dobro novico: "In zdaj imamo agile!"
Ali če vas samo zanima, kako drugače lahko zgradite skladiščne prostore - dobrodošli v rezu!
Kaj pomeni "fleksibilnost"?
Najprej opredelimo, katere lastnosti mora imeti sistem, da se lahko imenuje "prilagodljiv".
Ločeno je treba omeniti, da se morajo opisane lastnosti nanašati posebej na sistem, ne da postopek njegov razvoj. Zato, če želite brati o Agile kot razvojni metodologiji, je bolje, da preberete druge članke. Na primer, tam, na Habréju, je veliko zanimivih materialov (npr и In ).
To ne pomeni, da sta razvojni proces in struktura podatkovnega skladišča popolnoma nepovezana. Na splošno bi moralo biti bistveno lažje razviti Agile repozitorij za agilno arhitekturo. Vendar pa v praksi pogosteje obstajajo možnosti z Agilnim razvojem klasičnega DWH po Kimbalu in DataVault - po Waterfallu kot srečna naključja fleksibilnosti v dveh oblikah na enem projektu.
Kakšne zmogljivosti bi torej morala imeti prilagodljiva shramba? Tukaj so tri točke:
- Zgodnja dostava in hiter preobrat - to pomeni, da bi bilo idealno prvi poslovni rezultat (npr. prva delovna poročila) dosežen čim prej, torej še preden je celoten sistem zasnovan in implementiran. Poleg tega naj vsaka naslednja revizija traja čim manj časa.
- Iterativno izpopolnjevanje - to pomeni, da vsaka naslednja izboljšava v idealnem primeru ne bi smela vplivati na funkcionalnost, ki že deluje. Prav ta trenutek pogosto postane največja nočna mora pri velikih projektih - slej ko prej začnejo posamezni objekti pridobivati toliko povezav, da postane lažje popolnoma ponoviti logiko v bližnji kopiji kot dodati polje v obstoječo tabelo. In če ste presenečeni, da analiza vpliva izboljšav na obstoječe objekte lahko vzame več časa kot same izboljšave, najverjetneje še niste delali z velikimi podatkovnimi skladišči v bančništvu ali telekomunikacijah.
- Nenehno prilagajanje spreminjajočim se poslovnim zahtevam - celotno strukturo objekta je treba načrtovati ne le ob upoštevanju morebitne širitve, ampak s pričakovanjem, da o smeri te naslednje širitve v fazi načrtovanja ni mogoče niti sanjati.
In ja, izpolnjevanje vseh teh zahtev v enem sistemu je možno (seveda v določenih primerih in z nekaterimi zadržki).
Spodaj bom obravnaval dve izmed najbolj priljubljenih metodologij agilnega oblikovanja za podatkovna skladišča - Sidrni model и Podatkovni trezor. Iz oklepajev so izpuščene tako odlične tehnike, kot so na primer EAV, 6NF (v čisti obliki) in vse, kar je povezano z rešitvami NoSQL - ne zato, ker bi bile nekako slabše, niti ne zato, ker bi v tem primeru članek grozil, da bo pridobil glasnost povprečnega disserja. Samo, da se vse to nanaša na rešitve nekoliko drugačnega razreda – bodisi na tehnike, ki jih lahko uporabite v posebnih primerih, ne glede na splošno arhitekturo vašega projekta (kot je EAV), bodisi na globalno druge paradigme shranjevanja informacij (kot so baze podatkov grafov). in druge možnosti NoSQL).
Problemi »klasičnega« pristopa in njihove rešitve v fleksibilnih metodologijah
S “klasičnim” pristopom mislim na dobro staro zvezdo (ne glede na specifično izvedbo osnovnih plasti, naj mi privrženci Kimballa, Inmona in CDM oprostijo).
1. Toga kardinalnost povezav
Ta model temelji na jasni delitvi podatkov na Dimenzija и dejstva. In to je, prekleto, logično - navsezadnje se analiza podatkov v veliki večini primerov zmanjša na analizo določenih numeričnih kazalnikov (dejstev) v določenih odsekih (dimenzijah).
V tem primeru se povezave med objekti vzpostavijo v obliki odnosov med tabelami z uporabo tujega ključa. To je videti precej naravno, vendar takoj vodi do prve omejitve prožnosti - stroga opredelitev kardinalnosti povezav.
To pomeni, da morate na stopnji oblikovanja tabele natančno določiti za vsak par povezanih objektov, ali se lahko nanašajo enako veliko proti mnogo ali samo 1 proti mnogo in »v kateri smeri«. To neposredno določa, katera tabela bo imela primarni in katera tuji ključ. Sprememba tega odnosa, ko bodo prejete nove zahteve, bo najverjetneje povzročila predelavo osnove.
Na primer, pri oblikovanju predmeta "blagajniški prejemek" ste, opirajoč se na prisege prodajnega oddelka, določili možnost ukrepanja ena promocija za več kontrolnih pozicij (vendar ne obratno):
In čez nekaj časa so kolegi uvedli novo marketinško strategijo, v kateri lahko delujejo na enakem položaju več promocij hkrati. In zdaj morate spremeniti tabele tako, da ločite razmerje v ločen objekt.
(Zdaj je treba izboljšati tudi vse izpeljane objekte, v katere je združeno preverjanje napredovanja).
Razmerja v podatkovnem trezorju in modelu sidra
Izogniti se tej situaciji se je izkazalo za povsem preprosto: za to vam ni treba zaupati prodajnemu oddelku. vse povezave so na začetku shranjene v ločenih tabelah in ga obdelajte kot veliko proti mnogo.
Ta pristop je bil predlagan Dan Linstedt kot del paradigme Podatkovni trezor in v celoti podprt Lars Rönnbäck в Sidrni model.
Kot rezultat dobimo prvo posebnost fleksibilnih metodologij:
Relacije med objekti niso shranjene v atributih nadrejenih entitet, ampak so ločena vrsta predmeta.
В Podatkovni trezor takšne povezovalne tabele imenujemo Link, in v Sidrni model - Kravata. Na prvi pogled sta si zelo podobna, čeprav se njune razlike ne končajo z imenom (o katerem bomo govorili v nadaljevanju). V obeh arhitekturah se lahko povezovalne tabele povezujejo poljubno število subjektov (ni nujno 2).
Ta redundanca na prvi pogled zagotavlja precejšnjo prilagodljivost pri spremembah. Takšna struktura postane tolerantna ne le na spremembe v kardinalnosti obstoječih povezav, temveč tudi na dodajanje novih – če ima zdaj ček pozicija tudi povezavo do blagajnika, ki jo je prebil, bo pojav takšne povezave preprosto postanejo dodatek nad obstoječimi tabelami, ne da bi vplivali na obstoječe objekte in procese.
2. Podvajanje podatkov
Drugi problem, ki ga rešujejo prilagodljive arhitekture, je manj očiten in je že vgrajen. Meritve tipa SCD2 (počasi spreminjajoče se dimenzije druge vrste), čeprav ne samo oni.
V klasičnem skladišču je dimenzija običajno tabela, ki vsebuje nadomestni ključ (kot PK) ter niz poslovnih ključev in atributov v ločenih stolpcih.
Če dimenzija podpira vzdrževanje različic, se standardnemu naboru polj dodajo meje veljavnosti različice in v repozitoriju se prikaže več različic za eno vrstico v viru (ena za vsako spremembo atributov z različicami).
Če dimenzija vsebuje vsaj en atribut z različicami, ki se pogosto spreminja, bo število različic takšne dimenzije navdušujoče (tudi če preostali atributi nimajo različic ali se nikoli ne spremenijo), in če obstaja več takih atributov, lahko število različic njihovo število eksponentno narašča. Ta dimenzija lahko zavzame veliko prostora na disku, čeprav je večina podatkov, ki jih shranjuje, preprosto dvojniki nespremenljivih vrednosti atributov iz drugih vrstic.
Hkrati se tudi zelo pogosto uporablja denormalizacija — nekateri atributi so namerno shranjeni kot vrednost in ne kot povezava do referenčne knjige ali druge dimenzije. Ta pristop pospeši dostop do podatkov in zmanjša število združevanj pri dostopu do dimenzije.
Običajno to vodi do iste informacije so shranjene hkrati na več mestih. Na primer, informacije o regiji prebivališča in kategoriji stranke se lahko hkrati shranijo v dimenzijah »Stranka« in dejstvih »Nakup«, »Dostava« in »Klici klicnega centra« ter v »Stranka - upravitelj strank«. ” povezovalna tabela.
Na splošno zgoraj opisano velja za običajne (brez različic) dimenzije, vendar imajo lahko v različicah različno merilo: pojav nove različice predmeta (zlasti v retrospektivi) vodi ne le do posodobitve vseh povezanih tabel, temveč do kaskadnega pojavljanja novih različic povezanih objektov – ko se tabela 1 uporablja za izdelavo tabele 2, tabela 2 pa se uporablja za izdelavo tabele 3 itd. Tudi če v konstrukcijo tabele 1 ni vključen niti en atribut tabele 3 (in so vključeni drugi atributi tabele 2, pridobljeni iz drugih virov), bo različica te konstrukcije povzročila najmanj dodatne stroške in največ dodatne različice v tabeli 3. ki s tem sploh nima nobene zveze, in naprej po verigi.
3. Nelinearna kompleksnost predelave
Hkrati vsaka nova prodajalna, zgrajena na podlagi druge, poveča število mest, kjer se lahko podatki "razhajajo", ko se spremeni ETL. To pa vodi do povečanja kompleksnosti (in trajanja) vsake naslednje revizije.
Če zgoraj opisuje sisteme z redko spremenjenimi procesi ETL, lahko živite v takšni paradigmi – poskrbeti morate le, da so nove spremembe pravilno izvedene na vseh povezanih objektih. Če se revizije pogosto pojavljajo, se verjetnost nenamernega "manjkanja" več povezav znatno poveča.
Če poleg tega upoštevamo, da je »verzioniran« ETL bistveno bolj zapleten od »neverzioniranega«, postane precej težko izogniti se napakam pri pogostem posodabljanju celotnega pripomočka.
Shranjevanje predmetov in atributov v Data Vault in Anchor Model
Pristop, ki so ga predlagali avtorji fleksibilnih arhitektur, je mogoče formulirati na naslednji način:
Treba je ločiti tisto, kar se spreminja, od tistega, kar ostaja enako. To pomeni, da shranite ključe ločeno od atributov.
Vendar se ne sme zamenjati ni različic atribut z nespremenjeno: prvi ne shranjuje zgodovine svojih sprememb, lahko pa se spremeni (na primer pri popravljanju napake pri vnosu ali prejemu novih podatkov), drugi pa se nikoli ne spremeni.
Stališča se razlikujejo glede tega, kaj točno se lahko šteje za nespremenljivo v Data Vault in Sidrnem modelu.
Z arhitekturnega vidika Podatkovni trezor, se lahko šteje za nespremenjeno cel komplet ključev - naravni (TIN organizacije, šifra izdelka v izvornem sistemu itd.) in nadomestni. V tem primeru lahko preostale atribute razdelimo v skupine glede na izvor in/ali pogostost sprememb in Za vsako skupino vodite ločeno tabelo z neodvisnim nizom različic.
V paradigmi Sidrni model velja za nespremenjeno samo nadomestni ključ bistvo. Vse ostalo (vključno z naravnimi ključi) je le poseben primer njegovih lastnosti. pri čemer vsi atributi so privzeto neodvisni drug od drugega, torej za vsak atribut a ločena miza.
В Podatkovni trezor kličejo se tabele, ki vsebujejo ključe entitet Hubami. Vozlišča vedno vsebujejo fiksen nabor polj:
- Ključi naravnih entitet
- Nadomestni ključ
- Povezava do vira
- Zabeležite čas dodajanja
Objave v vozliščih nikoli se ne spreminjajo in nimajo različic. Navzven so vozlišča zelo podobna tabelam vrste preslikav ID-jev, ki se uporabljajo v nekaterih sistemih za generiranje nadomestkov, vendar je priporočljivo, da kot nadomestke v Data Vault uporabite zgoščeno vrednost iz niza poslovnih ključev. Ta pristop poenostavlja nalaganje relacij in atributov iz virov (ni se vam treba pridružiti vozlišču, da bi dobili nadomestek, samo izračunajte zgoščenost naravnega ključa), vendar lahko povzroči druge težave (povezane na primer s kolizijami, velikimi in malimi črkami ter nenatisljivimi znakov v nizovnih ključih itd. .p.), zato ni splošno sprejet.
Vsi ostali atributi entitet so shranjeni v posebnih tabelah, imenovanih Sateliti. Eno vozlišče ima lahko več satelitov, ki hranijo različne nize atributov.
Porazdelitev atributov med sateliti poteka po principu sklepna sprememba — v enem satelitu je mogoče shraniti atribute brez različic (na primer datum rojstva in SNILS za posameznika), v drugem - redko spreminjajoče se različice (na primer priimek in številka potnega lista), v tretjem - pogosto spreminjajoče se atribute (na primer naslov za dostavo, kategorija, datum zadnjega naročila itd.). V tem primeru se verzioniranje izvaja na ravni posameznih satelitov in ne entitete kot celote, zato je priporočljivo atribute porazdeliti tako, da je presečišče verzij znotraj enega satelita minimalno (kar zmanjša skupno število shranjenih različic ).
Poleg tega so za optimizacijo postopka nalaganja podatkov v posamezne satelite pogosto vključeni atributi, pridobljeni iz različnih virov.
Sateliti komunicirajo s Hubom prek tuji ključ (kar ustreza kardinalnosti 1 proti mnogo). To pomeni, da ta »privzeta« arhitektura podpira več vrednosti atributov (na primer več kontaktnih telefonskih številk za eno stranko).
В Sidrni model imenujemo tabele, ki shranjujejo ključe Sidra. In hranijo:
- Samo nadomestni ključi
- Povezava do vira
- Zabeležite čas dodajanja
Upoštevani so naravni ključi z vidika sidrnega modela običajni atributi. Ta možnost se morda zdi težje razumljiva, vendar daje veliko več prostora za prepoznavanje predmeta.
Na primer, če lahko podatki o isti entiteti prihajajo iz različnih sistemov, od katerih vsak uporablja svoj naravni ključ. V podatkovnem trezorju lahko to privede do precej okornih struktur več vozlišč (eno na vir + poenotena glavna različica), medtem ko v modelu Anchor naravni ključ vsakega vira pade v svoj atribut in se lahko uporablja pri nalaganju neodvisno od vsi ostali.
Toda tu obstaja tudi ena zahrbtna točka: če so atributi iz različnih sistemov združeni v eno entiteto, je najverjetneje nekaj pravila "lepljenja", s katerim mora sistem razumeti, da zapisi iz različnih virov ustrezajo enemu primerku entitete.
В Podatkovni trezor ta pravila bodo najverjetneje določila formacijo »nadomestno središče« glavne entitete in na noben način ne vpliva na vozlišča, ki shranjujejo naravne izvorne ključe in njihove izvirne atribute. Če se na neki točki pravila združevanja spremenijo (ali posodobijo atributi, po katerih se to izvaja), bo dovolj, da preoblikujete nadomestna vozlišča.
В Sidrni model taka entiteta bo najverjetneje shranjena v edino sidro. To pomeni, da bodo vsi atributi, ne glede na vir, iz katerega prihajajo, vezani na isti nadomestek. Ločevanje napačno spojenih zapisov in nasploh spremljanje ustreznosti združevanja v takem sistemu je lahko veliko težje, še posebej, če so pravila precej zapletena in se pogosto spreminjajo, isti atribut pa lahko pridobimo iz različnih virov (čeprav je vsekakor mogoče, saj vsaka različica atributa ohrani povezavo do svojega vira).
V vsakem primeru, če naj bi vaš sistem izvajal funkcionalnost deduplikacija, združevanje zapisov in drugi elementi MDM, je vredno posvetiti posebno pozornost vidikom shranjevanja naravnih ključev v agilnih metodologijah. Verjetno bo večja zasnova podatkovnega trezorja nenadoma varnejša v smislu napak pri spajanju.
Sidrni model ponuja tudi dodatno vrsto predmeta, imenovano Vozel v bistvu je poseben degenerirana vrsta sidra, ki lahko vsebuje samo en atribut. Vozlišča naj bi se uporabljala za shranjevanje ravnih imenikov (na primer spol, zakonski stan, kategorija storitev za stranke itd.). Za razliko od Sidra, Vozel nima povezanih tabel atributov, njegov edini atribut (ime) pa je vedno shranjen v isti tabeli s ključem. Vozlišča so povezana s sidri z veznimi tabelami (Tie) na enak način, kot so sidra povezana med seboj.
Glede uporabe vozlišč ni jasnega mnenja. na primer , ki aktivno spodbuja uporabo sidrnega modela v Rusiji, meni (ne neutemeljeno), da za nobeno referenčno knjigo ni mogoče z gotovostjo trditi, da vedno bo statična in enonivojska, zato je bolje, da takoj uporabite polnopravno sidro za vse predmete.
Druga pomembna razlika med Data Vault in modelom Anchor je razpoložljivost lastnosti povezav:
В Podatkovni trezor Povezave so enaki polnopravni predmeti kot vozlišča in jih lahko imajo lastne lastnosti. V Sidrni model Povezave se uporabljajo samo za povezovanje sider in ne morejo imeti lastnih lastnosti. Ta razlika povzroči bistveno različne pristope modeliranja dejstva, o čemer bomo še razpravljali.
Shranjevanje dejstev
Pred tem smo govorili predvsem o modeliranju meritev. Dejstva so malo manj jasna.
В Podatkovni trezor tipičen predmet za shranjevanje dejstev je Povezava, v katerih satelitih so dodani realni indikatorji.
Ta pristop se zdi intuitiven. Omogoča enostaven dostop do analiziranih kazalnikov in je na splošno podoben tradicionalni tabeli dejstev (le da kazalniki niso shranjeni v sami tabeli, temveč v »sosednji«). Obstajajo pa tudi pasti: ena od tipičnih modifikacij modela - razširitev ključa dejstev - zahteva dodajanje novega tujega ključa v povezavo. In to posledično "zlomi" modularnost in potencialno povzroči potrebo po modifikacijah drugih objektov.
В Sidrni model Povezava ne more imeti lastnih atributov, zato ta pristop ne bo deloval - absolutno vsi atributi in indikatorji morajo biti povezani z enim določenim sidrom. Sklep iz tega je preprost - Vsako dejstvo potrebuje tudi svoje sidro. Za nekaj tega, kar smo navajeni dojemati kot dejstva, je to lahko videti naravno - na primer dejstvo nakupa je mogoče popolnoma zmanjšati na predmet "naročilo" ali "prejem", obisk spletnega mesta na sejo itd. Obstajajo pa tudi dejstva, za katera ni tako enostavno najti takšnega naravnega "nosilnega predmeta" - na primer ostanki blaga v skladiščih na začetku vsakega dne.
Skladno s tem se težave z modularnostjo pri razširitvi ključa dejstev v sidrnem modelu ne pojavijo (dovolj je, da ustreznemu sidru preprosto dodate novo razmerje), vendar je oblikovanje modela za prikaz dejstev manj nedvoumno; lahko se pojavijo "umetna" sidra ki prikazujejo model poslovnih objektov na nejasen način.
Kako se doseže fleksibilnost
Nastala konstrukcija v obeh primerih vsebuje bistveno več mizkot tradicionalno merjenje. Lahko pa traja bistveno manj prostora na disku z enakim naborom verzioniranih atributov kot tradicionalna dimenzija. Seveda tu ni nobene čarovnije - gre za normalizacijo. Z razdelitvijo atributov po satelitih (v Data Vault) ali posameznih tabelah (Anchor Model) zmanjšamo (ali popolnoma odpravimo) podvajanje vrednosti nekaterih atributov pri spreminjanju drugih.
Za Podatkovni trezor dobitki bodo odvisni od porazdelitve atributov med sateliti in za Sidrni model — je skoraj premosorazmeren s povprečnim številom različic na merilni objekt.
Vendar je prihranek prostora pomembna, vendar ne glavna prednost ločenega shranjevanja atributov. Skupaj z ločenim shranjevanjem odnosov ta pristop naredi trgovino modularna zasnova. To pomeni, da dodajanje posameznih atributov in celotnih novih predmetnih področij v tak model izgleda takole nadgradnja nad obstoječim naborom predmetov, ne da bi jih spremenili. In prav to dela opisane metodologije fleksibilne.
To spominja tudi na prehod iz kosovne proizvodnje v množično proizvodnjo - če je v tradicionalnem pristopu vsaka tabela modela edinstvena in zahteva posebno pozornost, potem je v fleksibilnih metodologijah to že niz standardnih "delov". Po eni strani je več tabel, procesi nalaganja in pridobivanja podatkov pa bi morali izgledati bolj zapleteni. Po drugi strani pa postanejo tipično. Kar pomeni, da lahko obstaja avtomatizirano in na podlagi metapodatkov. Vprašanje »Kako ga bomo položili?«, katerega odgovor bi lahko zavzel precejšen del dela pri oblikovanju izboljšav, se zdaj preprosto ne splača (kot tudi vprašanje o vplivu spremembe modela na delovne procese). ).
To ne pomeni, da analitiki v takem sistemu sploh niso potrebni - nekdo mora še vedno obdelati nabor objektov z atributi in ugotoviti, kam in kako vse to naložiti. Vendar se količina dela, pa tudi verjetnost in stroški napake bistveno zmanjšajo. Tako v fazi analize kot med razvojem ETL, ki se lahko v precejšnjem delu zmanjša na urejanje metapodatkov.
Temna stran
Zaradi vsega navedenega sta oba pristopa resnično fleksibilna, tehnološko napredna in primerna za ponavljajoče se izboljšave. Seveda obstaja tudi “sod v mazlu”, ki ga mislim, da že ugibate.
Dekompozicija podatkov, ki je osnova modularnosti fleksibilnih arhitektur, vodi do povečanja števila tabel in posledično do nad glavo da se združi pri vzorčenju. Da enostavno dobimo vse atribute dimenzije, v klasični trgovini zadostuje en izbor, fleksibilna arhitektura pa bo zahtevala celo vrsto združevanj. Poleg tega, če je mogoče vse te spoje za poročila napisati vnaprej, bodo analitiki, ki so navajeni ročnega pisanja SQL, trpeli dvojno.
Obstaja več dejstev, ki olajšajo to situacijo:
Pri delu z velikimi dimenzijami se vsi njegovi atributi skoraj nikoli ne uporabljajo hkrati. To pomeni, da je lahko združevanj manj, kot se zdi na prvi pogled na model. Data Vault lahko pri dodeljevanju atributov satelitom upošteva tudi pričakovano pogostost skupne rabe. Hkrati so sama vozlišča ali sidra potrebna predvsem za generiranje in preslikavo nadomestkov v fazi nalaganja in se redko uporabljajo v poizvedbah (to še posebej velja za sidra).
Vsi spoji so po ključu. Poleg tega bolj "stisnjen" način shranjevanja podatkov zmanjša stroške skeniranja tabel, kjer je to potrebno (na primer pri filtriranju po vrednosti atributa). To lahko privede do dejstva, da bo vzorčenje iz normalizirane baze podatkov s kupom združevanj celo hitrejše kot skeniranje ene težke dimenzije z veliko različicami na vrstico.
Na primer, tukaj v Članek vsebuje podroben primerjalni test delovanja modela Anchor z vzorcem iz ene tabele.
Veliko je odvisno od motorja. Veliko sodobnih platform ima notranje mehanizme za optimizacijo pridružitve. Na primer, MS SQL in Oracle lahko »preskočita« združevanja s tabelami, če se njuni podatki ne uporabljajo nikjer razen za druge združevanja in ne vplivajo na končno izbiro (izločitev tabele/združevanja), in MPP Vertica , se je glede na nekaj ročne optimizacije načrta poizvedbe izkazal za odličen mehanizem za sidrni model. Po drugi strani pa shranjevanje sidrnega modela, na primer, na Click House, ki ima omejeno podporo za pridružitev, še ni videti kot zelo dobra ideja.
Poleg tega za obe arhitekturi obstajajo posebne poteze, kar olajša dostop do podatkov (tako z vidika zmogljivosti poizvedb kot za končne uporabnike). na primer Tabele točke v času v Data Vault oz posebne funkcije tabele v modelu Anchor.
Skupno
Glavno bistvo obravnavanih fleksibilnih arhitektur je modularnost njihovega »dizajna«.
Ta lastnost omogoča:
- Po nekaj začetnih pripravah, povezanih z uvedbo metapodatkov in pisanjem osnovnih algoritmov ETL, hitro zagotoviti stranki prvi rezultat v obliki nekaj poročil, ki vsebujejo podatke iz samo nekaj izvornih objektov. Ni potrebno popolnoma premisliti (tudi na najvišji ravni) celotnega objektnega modela.
- Podatkovni model lahko začne delovati (in je uporaben) s samo 2-3 objekti in nato rastejo postopoma (v zvezi z modelom Anchor Nikolajem lepa primerjava z micelijem).
- Večina izboljšav, vključno z razširitvijo tematskega področja in dodajanjem novih virov ne vpliva na obstoječo funkcionalnost in ne predstavlja tveganja za zlom nečesa, kar že deluje.
- Zahvaljujoč dekompoziciji na standardne elemente so procesi ETL v takšnih sistemih videti enaki, njihovo pisanje je primerno za algoritmizacijo in navsezadnje avtomatizacija.
Cena te prilagodljivosti je uspešnost. To ne pomeni, da je na takih modelih nemogoče doseči sprejemljivo zmogljivost. Pogosteje kot ne boste morda preprosto potrebovali več truda in pozornosti do podrobnosti, da dosežete želene meritve.
Apps
Vrste entitet Podatkovni trezor
Več informacij o Data Vault:
Vrste entitet Sidrni model
Več podrobnosti o modelu sidra:
Zbirna tabela s skupnimi lastnostmi in razlikami obravnavanih pristopov:
Vir: www.habr.com