Razvoj skladišta je dug i ozbiljan posao.
Mnogo toga u životu projekta ovisi o tome koliko su objektni model i osnovna struktura osmišljeni na početku.
Općeprihvaćeni pristup je bio i ostaje razne kombinacije zvjezdaste sheme sa trećim normalnim oblikom. U pravilu, po principu: početni podaci - 3NF, vitrine - zvijezda. Ovaj pristup, vremenski testiran i potkrijepljen brojnim istraživanjima, prva je (a ponekad i jedina) stvar koja iskusnom stručnjaku za DWH padne na pamet kada razmišlja o tome kako bi analitičko spremište trebalo izgledati.
S druge strane, poslovanje općenito i zahtjevi kupaca posebno imaju tendenciju da se brzo mijenjaju, dok podaci rastu i „u dubinu“ i „u širinu“. I ovdje se pojavljuje glavni nedostatak zvijezde - ograničen fleksibilnost.
A ako u vašem mirnom i udobnom životu kao DWH programer odjednom:
- postavio se zadatak „da se bar nešto uradi brzo, a onda ćemo vidjeti“;
- pojavio se projekat koji se ubrzano razvija, uz povezivanje novih izvora i promenu poslovnog modela najmanje jednom nedeljno;
- pojavio se kupac koji nema pojma kako sistem treba da izgleda i koje funkcije na kraju treba da obavlja, ali je spreman za eksperimente i dosledno usavršavanje željenog rezultata uz dosledan pristup njemu;
- menadžer projekta je pogledao sa dobrim vijestima: “A sada imamo agilne!”.
Ili ako ste samo zainteresirani da naučite kako još možete izgraditi skladište - dobrodošli u mačku!
Šta znači "fleksibilnost"?
Za početak, hajde da definišemo koja svojstva sistem mora imati da bi se mogao nazvati „fleksibilnim“.
Zasebno, vrijedno je spomenuti da se opisana svojstva trebaju posebno odnositi sistem, ne da proces njegov razvoj. Stoga, ako želite čitati o Agileu kao razvojnoj metodologiji, bolje je pročitati druge članke. Na primjer, upravo tamo, na Habréu, ima puno zanimljivih materijala (kao и , i ).
To ne znači da su proces razvoja i struktura skladišta podataka potpuno nepovezani. Općenito, Agile razvoj agilnog skladišta trebao bi biti mnogo lakši. Međutim, u praksi, postoji više opcija sa Agile razvojem klasičnog DWH prema Kimbalu i DataVaultu - prema vodopadu nego sretnim slučajnostima fleksibilnosti u dva oblika na jednom projektu.
Dakle, koje karakteristike treba da ima fleksibilna pohrana? Ovdje postoje tri tačke:
- Rana isporuka i brz završetak - to znači da u idealnom slučaju prvi poslovni rezultat (npr. prvi radni izvještaji) treba dobiti što je prije moguće, odnosno čak i prije nego što se cijeli sistem osmisli i implementira. U isto vrijeme, svaka naredna revizija također treba da traje što je moguće manje vremena.
- Iterativno usavršavanje - to znači da svaka naredna revizija, u idealnom slučaju, ne bi trebala utjecati na već radnu funkcionalnost. Upravo taj trenutak često postaje najveća noćna mora na velikim projektima - prije ili kasnije, pojedinačni objekti počnu stjecati toliko odnosa da postaje lakše potpuno ponoviti logiku u kopiji rame uz rame nego dodati polje postojećoj tablici. A ako ste iznenađeni da analiza uticaja poboljšanja na postojeće objekte može trajati duže od same revizije, najverovatnije niste radili sa velikim skladištima podataka u bankarstvu ili telekomunikacijama.
- Stalno prilagođavanje promenljivim poslovnim zahtevima - opštu strukturu objekta treba projektovati ne samo uzimajući u obzir moguće proširenje, već sa očekivanjem da se pravac ovog sledećeg proširenja ne može ni sanjati u fazi projektovanja.
I da, usklađenost sa svim ovim zahtjevima u jednom sistemu je moguća (naravno, u određenim slučajevima i uz određene rezerve).
U nastavku ću pregledati dvije najpopularnije metodologije agilnog dizajna za HD − sidro model и Trezor podataka. Izvan zagrada su takvi odlični trikovi kao što su, na primjer, EAV, 6NF (u čistom obliku) i sve što se tiče NoSQL rješenja - ne zato što su nekako lošija, pa čak ni zato što bi u ovom slučaju članak prijetio da dobije obim prosječnog dissera. Samo što se sve ovo odnosi na rješenja malo drugačije klase – bilo na tehnike koje možete primijeniti u određenim slučajevima, bez obzira na opću arhitekturu vašeg projekta (kao što je EAV), ili na globalno različite paradigme skladištenja informacija (kao što su baze podataka grafova i druge opcije). NoSQL).
Problemi “klasičnog” pristupa i njihova rješenja u fleksibilnim metodologijama
Pod „klasičnim“ pristupom mislim na staru dobru zvijezdu (bez obzira na specifičnu implementaciju osnovnih slojeva, oprostite mi pristalice Kimballa, Inmona i CDM-a).
1. Kruta kardinalnost veza
Ovaj model se zasniva na jasnoj podeli podataka na mjere (dimenzija) и činjenice (činjenica). I ovo je, dovraga, logično - uostalom, analiza podataka u ogromnoj većini slučajeva svodi se na analizu određenih brojčanih pokazatelja (činjenica) u određenim dijelovima (dimenzijama).
U isto vrijeme, veze između objekata postavljaju se u obliku veza između tabela stranim ključem. Ovo izgleda sasvim prirodno, ali odmah dovodi do prvog ograničenja fleksibilnosti − striktno definisanje kardinalnosti odnosa.
To znači da u fazi dizajna tabela, morate specificirati za svaki par povezanih objekata da li mogu biti povezani kao više-prema-više, ili samo 1-prema-mnogo, i "u kom smjeru". To direktno zavisi od toga koja će tabela imati primarni ključ, a koja strani ključ. Promjena ovog omjera kada se dobiju novi zahtjevi će najvjerovatnije dovesti do prerade baze.
Na primjer, prilikom dizajniranja objekta "gotovinskog računa", vi ste, oslanjajući se na zakletveno uvjerenje odjela prodaje, postavili mogućnost djelovanja jedno unapređenje za više pozicija za proveru (ali ne i obrnuto):
I nakon nekog vremena, kolege su uvele novu marketinšku strategiju u kojoj više promocija u isto vrijeme. A sada trebate finalizirati tabele isticanjem odnosa u zasebnom objektu.
(Svi izvedeni objekti, u koje se promotivna provjera spaja, sada također trebaju biti poboljšani).
Veze u trezoru podataka i modelu sidra
Pokazalo se da je izbjeći takvu situaciju prilično jednostavno: ne morate vjerovati odjelu prodaje, dovoljno je svi odnosi se inicijalno pohranjuju u zasebne tabele i obraditi koliko-toliko.
Ovaj pristup je predložen Dan Linstedt kao dio paradigme Trezor podataka i u potpunosti podržan Lars Rönnbäck в Anchor Model.
Kao rezultat, dobijamo prvu karakterističnu osobinu fleksibilnih metodologija:
Odnosi između objekata nisu pohranjeni u atributima roditeljskih entiteta, već su posebna vrsta objekata.
В Trezor podataka takve tabele se nazivaju linkand in Anchor Model - Tie. Na prvi pogled su vrlo slični, iako se njihove razlike ne iscrpljuju imenom (o čemu će biti riječi u nastavku). U obje arhitekture, tabele veza se mogu povezati bilo koji broj entiteta (ne nužno 2).
Ova na prvi pogled redundantnost daje bitnu fleksibilnost pri završetku. Takva struktura postaje tolerantna ne samo na promjenu kardinaliteta postojećih veza, već i na dodavanje novih - ako sada čekovna pozicija ima i vezu s blagajnikom koji ju je prekinuo, pojava takve veze jednostavno će biti nadgradnja preko postojećih tabela bez uticaja na postojeće objekte i procese.
2. Dupliciranje podataka
Drugi problem koji rješavaju fleksibilne arhitekture manje je očigledan i prije svega inherentan. mjerenja tipa SCD2 (polagano mijenjanje mjerenja drugog tipa), iako ne samo njih.
U klasičnoj memoriji, dimenzija je obično tabela koja sadrži surogat ključ (kao PK) i skup poslovnih ključeva i atributa u odvojenim kolonama.
Ako dimenzija podržava verzioniranje, standardnom skupu polja se dodaju vremenska ograničenja verzije i više verzija se pojavljuje u spremištu po redu u izvoru (jedna za svaku promjenu verzioniranih atributa).
Ako dimenzija sadrži barem jedan verzionirani atribut koji se često mijenja, broj verzija takve dimenzije bit će impresivan (čak i ako ostali atributi nisu verzionirani ili se nikada ne mijenjaju), a ako postoji nekoliko takvih atributa, broj verzija može eksponencijalno rasti od njihovog broja. Takva dimenzija može zauzeti značajnu količinu prostora na disku, iako je većina podataka pohranjenih u njoj jednostavno duplikati nepromjenjivih vrijednosti atributa iz drugih redova.
Istovremeno, često se koristi denormalizacija - neki od atributa su namjerno pohranjeni kao vrijednost, a ne kao referenca na referentnu knjigu ili drugu dimenziju. Ovaj pristup ubrzava pristup podacima smanjenjem broja spajanja prilikom pristupa dimenziji.
Obično to rezultira iste informacije se pohranjuju istovremeno na više mjesta. Na primjer, informacije o regiji prebivališta i članstvu kategorije kupaca mogu se istovremeno pohraniti u dimenzijama „Kupac“, te činjenice „Kupovina“, „Isporuka“ i „Kontakti za pozivni centar“, kao i u link tabela “Kupac - Menadžer kupaca”.
Općenito, gore navedeno vrijedi za redovna (neverzionirana) mjerenja, ali u verzioniranim mjerenjima ona mogu imati drugačiju skalu: pojava nove verzije objekta (posebno gledano unatrag) dovodi ne samo do ažuriranja svih povezanih tabela, već na kaskadni izgled novih verzija povezanih objekata - kada se tabela 1 koristi za pravljenje tabele 2, a tabela 2 se koristi za pravljenje tabele 3 i tako dalje. Čak i ako nijedan atribut Tabele 1 nije uključen u konstrukciju Tabele 3 (a uključeni su i drugi atributi Tablice 2 dobijeni iz drugih izvora), verzija ove konstrukcije će barem dovesti do dodatnih troškova, a najviše do dodatne verzije u tabeli 3, što generalno nema veze sa tim, i dalje u lancu.
3. Nelinearna složenost dorade
U isto vrijeme, svaki novi izlog koji je izgrađen na drugom povećava broj mjesta na kojima se podaci mogu "razilaziti" kada se izvrše promjene u ETL-u. To, zauzvrat, dovodi do povećanja složenosti (i trajanja) svake sljedeće revizije.
Ako se gore navedeno odnosi na sisteme sa rijetko modificiranim ETL procesima, možete živjeti u takvoj paradigmi - samo se pobrinite da su nova poboljšanja ispravno napravljena na svim povezanim objektima. Ako se revizije dešavaju često, vjerovatnoća da slučajno „propuste“ nekoliko veza značajno se povećava.
Ako, pored toga, uzmemo u obzir da je „verzionisani“ ETL mnogo komplikovaniji od „neverzionisanog“, postaje prilično teško izbeći greške tokom čestog usavršavanja cele ove ekonomije.
Pohranjivanje objekata i atributa u Data Vault i Anchor model
Pristup koji predlažu autori fleksibilnih arhitektura može se formulirati na sljedeći način:
Potrebno je odvojiti ono što se mijenja od onoga što ostaje nepromijenjeno. To znači da se ključevi pohranjuju odvojeno od atributa.
Međutim, nemojte zbuniti nije verzionisano atribut sa nepromijenjen: prvi ne pohranjuje historiju svojih promjena, ali se može promijeniti (na primjer, prilikom ispravljanja greške u unosu ili primanja novih podataka), drugi se nikada ne mijenja.
Tačke gledišta o tome šta se tačno može smatrati nepromijenjenim u Data Vault i Anchor modelu se razlikuju.
Što se tiče arhitekture Trezor podataka, može se smatrati nepromijenjenim ceo set ključeva — prirodni (TIN organizacije, šifra proizvoda u izvornom sistemu, itd.) i surogat. Istovremeno, preostali atributi se mogu podijeliti u grupe prema izvoru i/ili učestalosti promjena i vodite posebnu tabelu za svaku grupu sa nezavisnim skupom verzija.
U istoj paradigmi Anchor Model smatra nepromijenjenim samo surogat ključ entiteta. Sve ostalo (uključujući prirodne ključeve) je samo poseban slučaj njegovih atributa. Gde svi atributi su po defaultu nezavisni jedan od drugog, tako da za svaki atribut mora biti kreiran poseban sto.
В Trezor podataka pozivaju se tabele koje sadrže ključeve entiteta Hubami (Čvorište). Hubovi uvijek sadrže fiksni skup polja:
- Ključevi prirodnih entiteta
- Surogate Key
- Link do izvora
- Vrijeme snimanja
Unosi u čvorišta nikada se ne mijenjaju i nemaju verzije. Spolja, čvorišta su vrlo slični tabelama ID-mapa koje se koriste u nekim sistemima za generiranje surogata, međutim, preporučuje se korištenje ne cjelobrojnog niza, već hash iz skupa poslovnih ključeva kao surogata u Data Vaultu. Ovaj pristup pojednostavljuje učitavanje veza i atributa iz izvora (nema potrebe da se pridružite čvorištu da biste dobili surogat, samo izračunajte hash iz prirodnog ključa), ali može uzrokovati druge probleme (na primjer, s kolizijama, velikim i ne- štampanje znakova u string ključevima, itd. .p.), stoga nije općenito prihvaćeno.
Svi ostali atributi entiteta pohranjeni su u posebnim tablicama tzv Sateliti (Sateliti). Jedno čvorište može imati nekoliko satelita koji pohranjuju različite skupove atributa.
Raspodjela atributa među satelitima odvija se prema principu zajednička promena - u jednom satelitu mogu se pohraniti neverzionirani atributi (na primjer, datum rođenja i SNILS za pojedinca), u drugom - verzija koja se rijetko mijenja (na primjer, prezime i broj pasoša), u trećem - koja se često mijenja (na primjer, adresa za dostavu, kategorija, datum posljednje narudžbe, itd.). Versioniranje se u ovom slučaju vrši na nivou pojedinačnih satelita, a ne entiteta u cjelini, stoga je preporučljivo rasporediti atribute na način da je ukrštanje verzija unutar jednog satelita minimalno (što smanjuje ukupan broj pohranjenih verzija).
Takođe, radi optimizacije procesa učitavanja podataka, atributi dobijeni iz različitih izvora često se postavljaju u odvojene satelite.
Sateliti komuniciraju sa čvorištem putem strani ključ (što odgovara kardinalnosti 1 prema mnogo). To znači da višestruke vrijednosti atributa (na primjer, više telefonskih brojeva za kontakt za istog kupca) podržava ova „podrazumevana“ arhitektura.
В Anchor Model pozivaju se tabele koje pohranjuju ključeve Sidra. I čuvaju:
- Samo zamjenski ključevi
- Link do izvora
- Vrijeme snimanja
Razmatraju se prirodni ključevi sa stanovišta modela sidra obični atributi. Ova opcija može izgledati teže razumljiva, ali daje mnogo više prostora za identifikaciju objekta.
Na primjer, ako podaci o istom entitetu mogu doći iz različitih sistema, od kojih svaki koristi svoj prirodni ključ. U trezoru podataka to može dovesti do prilično glomaznih konstrukcija nekoliko čvorišta (jedan po izvoru + spajanje master verzije), dok u modelu Anchor prirodni ključ svakog izvora spada u svoj vlastiti atribut i može se koristiti pri učitavanju nezavisno od svi ostali.
Ali ovdje leži jedan podmukli trenutak: ako se atributi iz različitih sistema kombinuju u jedan entitet, najvjerovatnije postoje neki pravila lepka, čime sistem mora razumjeti da zapisi iz različitih izvora odgovaraju jednoj instanci entiteta.
В Trezor podataka ova pravila će vjerovatno odrediti formaciju “surogat hub” glavnog entiteta i ni na koji način ne utiču na čvorišta koja pohranjuju prirodne ključeve izvora i njihove originalne atribute. Ako se u nekom trenutku promijene pravila za spajanje (ili atributi koji se koriste za spajanje dođu da se ažuriraju), biće dovoljno da se ponovo formiraju surogat čvorišta.
В sidro model takav entitet će vjerovatno biti pohranjen u jedno sidro. To znači da će svi atributi, bez obzira iz kojeg izvora su dobijeni, biti vezani za isti surogat. Razdvajanje pogrešno spojenih zapisa i, općenito, praćenje relevantnosti spajanja u takvom sistemu može biti mnogo teže, pogotovo ako su pravila prilično složena i često se mijenjaju, a isti atribut se može dobiti iz različitih izvora (iako je definitivno moguće, jer svaka verzija atributa zadržava referencu na svoje porijeklo).
U svakom slučaju, ako vaš sistem treba da implementira funkcionalnost deduplikacija, spajanje zapisa i drugi MDM elementi, trebali biste posebno pažljivo pročitati aspekte pohranjivanja prirodnih ključeva u fleksibilnim metodologijama. Možda je glomazniji dizajn Data Vault-a odjednom sigurniji u smislu grešaka pri spajanju.
sidro model također pruža dodatni tip objekta tzv Knot u stvari je poseban degenerisani tip sidra, koji može sadržavati samo jedan atribut. Čvorovi bi se trebali koristiti za pohranjivanje ravnih direktorija (na primjer, spol, bračni status, kategorija korisničke usluge, itd.). Za razliku od Anchor, Knot nema pridružene tablice atributa, a njegov jedini atribut (ime) je uvijek pohranjen u istoj tablici s ključem. Čvorovi su povezani sa sidrima pomoću tablica veza (Tie) na isti način na koji su sidra međusobno povezana.
Ne postoji jednoznačno mišljenje o upotrebi čvorova. Na primjer, , koji aktivno promoviše upotrebu sidro modela u Rusiji, smatra (ne bezrazložno) da je nemoguće reći za jednu knjigu da je on uvek bit će statična i na jednom nivou, pa je bolje koristiti punopravno sidro za sve objekte odjednom.
Još jedna važna razlika između Data Vault-a i Anchor modela je prisutnost atributi za veze:
В Trezor podataka Linkovi su isti punopravni objekti kao i čvorišta i mogu ih imati sopstvenih atributa. The sidro model Linkovi se koriste samo za povezivanje sidra i ne mogu imati svoje atribute. Ova razlika dovodi do značajno različitih pristupa modeliranju. činjenice, o čemu će biti reči u nastavku.
Skladištenje činjenica
Do sada smo uglavnom govorili o modeliranju mjerenja. Činjenice su malo manje jasne.
В Trezor podataka tipičan objekat za pohranjivanje činjenica − Veza, u čijim satelitima su dodani stvarni indikatori.
Čini se da je ovaj pristup intuitivan. Omogućava lak pristup analiziranim indikatorima i generalno je sličan tradicionalnoj tabeli činjenica (samo indikatori nisu pohranjeni u samoj tabeli, već u „susednoj tabeli“). Ali postoje i zamke: jedna od tipičnih modifikacija modela - proširenje ključa činjenica - zahtijeva dodavanje novog stranog ključa na Link. A to, zauzvrat, "razbija" modularnost i potencijalno uzrokuje potrebu za poboljšanjima drugih objekata.
В sidro model Veza ne može imati svoje atribute, tako da ovaj pristup neće funkcionirati - apsolutno svi atributi i indikatori moraju biti povezani s jednim specifičnim sidrom. Zaključak iz ovoga je jednostavan - svaka činjenica takođe treba svoje sidro. Za nešto od onoga što smo navikli doživljavati kao činjenice, to može izgledati prirodno – na primjer, činjenica kupovine je savršeno svedena na objekt „narudžba“ ili „priznanica“, posjeta web mjestu se svodi na sesiju itd. Ali postoje i činjenice za koje nije tako lako pronaći takav prirodni „nosečki objekt” - na primjer, stanje robe u skladištima na početku svakog dana.
Shodno tome, nema problema s modularnošću prilikom proširenja ključa činjenica u modelu Anchor (dovoljno je samo dodati novu relaciju odgovarajućem sidru), ali dizajniranje modela za prikaz činjenica je manje jasno, mogu se pojaviti „vještačka“ sidra. koji prikazuju objektni model poslovanja nije očigledan.
Kako se postiže fleksibilnost
Rezultirajuća konstrukcija u oba slučaja sadrži znatno više stolovanego tradicionalno merenje. Ali može potrajati znatno manje prostora na disku s istim skupom verzioniranih atributa kao i tradicionalna dimenzija. Naravno, tu nema magije – sve je u normalizaciji. Distribucijom atributa preko satelita (u trezoru podataka) ili pojedinačnih tabela (sidreni model), smanjujemo (ili potpuno eliminiramo) dupliranje vrijednosti nekih atributa prilikom promjene drugih.
Do Trezor podataka dobit će zavisiti od distribucije atributa među satelitima, i za sidro model — je gotovo direktno proporcionalna prosječnom broju verzija po objektu mjerenja.
Međutim, zauzimanje prostora je važna, ali ne i glavna prednost odvojenog pohranjivanja atributa. Zajedno sa odvojenim skladištenjem veza, ovaj pristup čini skladištenje modularni dizajn. To znači da u takvom modelu izgleda dodavanje pojedinačnih atributa i potpuno novih predmetnih područja nadgradnja preko postojećeg skupa objekata bez njihovog mijenjanja. I upravo to čini opisane metodologije fleksibilnima.
To također podsjeća na prijelaz s komadne proizvodnje na masovnu proizvodnju - ako je u tradicionalnom pristupu svaki model stola jedinstven i zahtijeva posebnu pažnju, onda je u fleksibilnim metodologijama to već skup tipičnih "detalja". S jedne strane, ima više tabela, procesi učitavanja i dohvaćanja podataka bi trebali izgledati komplikovanije. S druge strane, oni postaju tipično. To znači da može postojati automatizovani i upravljani metapodacima. Pitanje "kako ćemo to postaviti?", čiji bi odgovor mogao zauzeti značajan dio posla na dizajnu poboljšanja, sada jednostavno nije vrijedno toga (kao ni pitanje utjecaja promjene modela na radni procesi).
To ne znači da analitičari u takvom sistemu uopće nisu potrebni - neko ipak mora razraditi skup objekata sa atributima i smisliti gdje i kako sve to učitati. Ali količina posla, kao i vjerovatnoća i cijena greške, značajno su smanjeni. Kako u fazi analize tako i tokom razvoja ETL-a, koji se u značajnom dijelu može svesti na uređivanje metapodataka.
Tamna strana
Sve navedeno čini oba pristupa zaista fleksibilnim, produktivnim i pogodnim za iterativno usavršavanje. Naravno, tu je i “bure katrana” za koje mislim da već znate.
Dekompozicija podataka koja leži u osnovi modularnosti fleksibilnih arhitektura dovodi do povećanja broja tabela i, shodno tome, iznad glave za spajanja prilikom preuzimanja. Da bi se jednostavno dobili svi atributi dimenzije, dovoljan je jedan odabir u klasičnoj memoriji, a fleksibilna arhitektura će zahtijevati određeni broj spojeva. Štaviše, ako se za izvještaje svi ovi spojevi mogu napisati unaprijed, onda će analitičari koji su navikli pisati SQL ručno patiti dvostruko.
Nekoliko je činjenica koje olakšavaju ovu situaciju:
Kada se radi s velikim dimenzijama, gotovo se svi njegovi atributi gotovo nikada ne koriste istovremeno. To znači da može biti manje spojeva nego što se čini na prvi pogled na modelu. U Data Vault-u možete uzeti u obzir i očekivanu učestalost dijeljenja prilikom dodjele atributa satelitima. Istovremeno, sami čvorišta ili sidri su potrebni prvenstveno za generiranje i mapiranje surogata u fazi učitavanja i rijetko se koriste u upitima (ovo posebno vrijedi za sidra).
Svi spojevi su po ključu. Osim toga, “komprimirani” način pohranjivanja podataka smanjuje troškove skeniranja tablice gdje je to potrebno (na primjer, kada se filtrira po vrijednosti atributa). To može dovesti do činjenice da će dohvaćanje iz normalizirane baze podataka s gomilom spojeva biti čak i brže od skeniranja jedne teške dimenzije s puno verzija po redu.
Na primjer, ovdje u U članku se nalazi detaljan uporedni test performansi Anchor modela sa izborom iz jedne tabele.
Mnogo zavisi od motora. Mnoge moderne platforme imaju interne mehanizme za optimizaciju spojeva. Na primjer, MS SQL i Oracle mogu „preskočiti“ spajanja na tablice ako se njihovi podaci ne koriste nigdje osim za druge spojeve i ne utiču na konačni odabir (eliminacija tablice/pridruživanja), dok MPP Vertica , pokazao se kao odličan motor za Anchor model, uz nešto ručnog optimiziranja plana upita. S druge strane, pohranjivanje Anchor modela, na primjer, na Click House, koji ima ograničenu podršku za pridruživanje, još se ne čini kao dobra ideja.
Osim toga, za obje arhitekture postoje specijalni trikovi, koji olakšavaju pristup podacima (kako u pogledu performansi upita tako i za krajnje korisnike). Na primjer, Tablice na vrijeme u Trezoru podataka ili posebne tablične funkcije u modelu sidra.
Ukupno
Glavna suština razmatranih fleksibilnih arhitektura je modularnost njihovog „dizajna“.
Ovo svojstvo omogućava:
- Nakon nekih početnih priprema vezanih za implementaciju metapodataka i pisanje osnovnih ETL algoritama, brzo pružiti kupcu prvi rezultat u obliku nekoliko izvještaja koji sadrže podatke iz samo nekoliko izvornih objekata. Za to nije potrebno u potpunosti promisliti (čak i na najvišem nivou) cijeli objektni model.
- Model podataka može početi raditi (i koristan) sa samo 2-3 objekta, a zatim rastu postepeno (u vezi sa modelom Anchor Nikolay prelepo poređenje sa micelijumom).
- Većina poboljšanja, uključujući proširenje predmetnog područja i dodavanje novih izvora ne utiče na postojeću funkcionalnost i ne uzrokuje opasnost od pokvarenja nečega što već radi.
- Zahvaljujući dekompoziciji na standardne elemente, ETL procesi u takvim sistemima izgledaju isto, njihovo pisanje je podložno algoritmizaciji i, na kraju, automatizacija.
Cijena ove fleksibilnosti je performanse. To ne znači da je nemoguće postići prihvatljive performanse na takvim modelima. Češće nego ne, možda će vam trebati više truda i pažnje na detalje kako biste postigli željene metrike.
aplikacije
Tipovi entiteta Trezor podataka
Više o Trezoru podataka:
Tipovi entiteta Anchor Model
Više o modelu sidra:
Tabela sažetka sa zajedničkim karakteristikama i razlikama između razmatranih pristupa:
izvor: www.habr.com