Pêşxistina depoyek karekî dirêj û cidî ye.
Pir di jiyana projeyekê de bi vê yekê ve girêdayî ye ku di destpêkê de modela objektê û avahiya bingehîn çiqas baş têne fikirîn.
Nêzîkatiya pejirandî bi gelemperî cûrbecûr cûrbecûr yên tevhevkirina nexşeya stêrkê bi forma normal ya sêyemîn re bûye û dimîne. Wekî qaîdeyek, li gorî prensîbê: daneyên destpêkê - 3NF, pêşandan - stêrk. Ev nêzîkatî, bi dem-ceribandin û ji hêla lêkolînek mezin ve hatî piştgirî kirin, yekem (û carinan jî yekane) tiştê ku tê hişê pisporek pisporê DWH-ê dema ku difikire ka depoyek analîtîk çawa xuya dike.
Ji hêla din ve, karsazî bi gelemperî û hewcedariyên xerîdar bi taybetî zû zû diguhezin, û daneyan hem "bi kûrahî" hem jî "bi berfirehî" mezin dibin. Û li vir dezavantaja sereke ya stêrkek xuya dike - sînorkirî nermbûnî.
Û heke di jiyana xweya bêdeng û xweş de wekî pêşdebirek DWH ji nişkê ve:
- peywir rabû "bi kêmanî tiştek zû bikin, û paşê em ê bibînin";
- projeyek bi lez pêşveçû, bi girêdana çavkaniyên nû û ji nû ve xebitandina modela karsaziyê bi kêmî ve hefteyek carekê xuya bû;
- xerîdarek xuya bû ku nizane pergal divê çawa xuya bike û di dawiyê de divê kîjan fonksiyonan pêk bîne, lê amade ye ku ceribandinê bike û bi domdarî encama xwestî safî bike dema ku bi domdarî nêzî wê dibe;
- Rêvebirê projeyê bi mizgîniya xwe daket: "Û naha em xwedan aqil in!"
An jî heke hûn tenê eleqedar in ku hûn fêr bibin ka hûn çawa dikarin dezgehên hilanînê ava bikin - bi xêr hatî qutkirinê!
Wateya "leşkerî" çi ye?
Pêşî, em rave bikin ka pergalek divê xwediyê çi taybetmendiyan be ji bo ku jê re "maker" were gotin.
Ji hev veqetandî, hêjayî gotinê ye ku taybetmendiyên diyarkirî divê bi taybetî re têkildar bin sîstem, ne ji doz pêşveçûna wê. Ji ber vê yekê, heke we xwest ku hûn li ser Agile wekî rêbazek pêşkeftinê bixwînin, çêtir e ku hûn gotarên din bixwînin. Mînakî, li wir, li ser Habré, gelek materyalên balkêş hene (wek и , û ).
Ev nayê vê wateyê ku pêvajoya pêşkeftinê û avahiya depoya daneyê bi tevahî ne têkildar in. Bi tevayî, pêdivî ye ku pêşvebirina depoyek Agile ya ji bo mîmariyek agile pir hêsantir be. Lêbelê, di pratîkê de, pir caran vebijarkên bi pêşkeftina Agile ya DWH-ya klasîk li gorî Kimbal û DataVault - li gorî Waterfall-ê, ji hevhatinên dilşewat ên nermbûnê di du formên wê de li ser yek projeyê hene.
Ji ber vê yekê, çi kapasîteyên hilanînê yên maqûl hene? Li vir sê xal hene:
- Radestkirina zû û zivirîna zû - ev tê vê wateyê ku bi îdeal yekem encama karsaziyê (mînakî, yekem raporên xebatê) divê bi zûtirîn dem were bidestxistin, ango, hêj berî ku tevahiya pergalê bi tevahî were sêwirandin û bicîh kirin. Digel vê yekê, her guhertoya paşîn divê di heman demê de hindik dem bigire.
- Paqijkirina dubare - ev tê vê wateyê ku her pêşkeftina paşîn divê bi îdeal bandorê li fonksiyona ku jixwe dixebite neke. Ev gav e ku pir caran dibe kabûsa herî mezin li ser projeyên mezin - zû an dereng, tiştên takekesî dest bi bidestxistina ewqas girêdanan dikin ku hêsantir dibe ku meriv bi tevahî mantiqê di kopiyek nêzîk de dubare bike ji lê zêdekirina zeviyek li tabloyek heyî. Û heke hûn şaş bimînin ku analîzkirina bandora çêtirkirinan li ser tiştên heyî dikare ji çêtirkirinan bi xwe bêtir wext bigire, bi îhtîmaleke mezin we hîn di banking an telekomê de bi depoyên daneya mezin re nexebitî.
- Bi domdarî li gorî hewcedariyên karsaziyê diguhezîne - Pêdivî ye ku strukturên giştgiriyê ne tenê li ber berfirehbûna gengaz were sêwirandin, lê bi hêviyê ku rêwerziya vê berfirehbûna paşîn di qonaxa sêwiranê de jî neyê xeyal kirin.
Û erê, bicihanîna van hemî hewcedariyên di yek pergalê de gengaz e (bê guman, di hin rewşan de û bi hin rezervan).
Li jêr ez ê du rêbazên sêwirana herî populer ên ji bo depoyên daneyê binirxînim - Modela Ankerê и Data Vault. Li derveyî kevanan teknîkên hêja hene, wek mînak, EAV, 6NF (di forma xwe ya paqij de) û her tiştê ku bi çareseriyên NoSQL ve girêdayî ye - ne ji ber ku ew bi rengek xirabtir in, û ne jî ji ber ku di vê rewşê de gotar dê tehdîd bi dest bixe. qebareya disser navîn. Tenê ev hemî bi çareseriyên çînek piçûktir ve girêdayî ye - an bi teknîkên ku hûn dikarin di rewşên taybetî de bikar bînin, bêyî ku mîmariya giştî ya projeya xwe (mîna EAV), an jî bi paradîgmayên din ên hilanîna agahdariya gerdûnî re (wek databasên grafîkî û vebijarkên din ên NoSQL).
Pirsgirêkên nêzîkatiya "klasîk" û çareseriyên wan di metodolojiyên maqûl de
Bi nêzîkatiya "klasîk" mebesta min stêrka kevnar a baş e (tevî pêkanîna taybetî ya qatên jêrîn, bila şagirtên Kimball, Inmon û CDM min bibaxşînin).
1. Qertaxa hişk a girêdanan
Ev model li ser dabeşkirina zelal a daneyan li ser bingeha Ebat и facts. Û ev, lanet, mentiqî ye - her tiştî, analîza daneyê di pirraniya bûyeran de bi analîzkirina hin nîşangirên hejmarî (rastî) di hin beşan (pîvan) de tê.
Di vê rewşê de, girêdanên di navbera tiştan de di forma têkiliyên di navbera tabloyan de bi karanîna mifteyek biyanî têne saz kirin. Ev pir xwezayî xuya dike, lê tavilê dibe sedema yekem sînorkirina nermbûnê - pênase hişk ya cardinality yên girêdan.
Ev tê vê wateyê ku di qonaxa sêwirana tabloyê de, divê hûn ji bo her cotek tiştên têkildar rast diyar bikin ka ew dikarin wekî gelek-bi-gelek, an tenê 1-bi-gelek, û "di kîjan alî de" têkildar bin. Ev rasterast diyar dike ka kîjan tablo dê xwedan mifteya bingehîn be û kîjan dê mifteya biyanî hebe. Guhertina vê helwestê dema ku daxwazên nû têne wergirtin dê bi îhtîmalek mezin bibe sedema ji nû ve xebitandina bingehê.
Mînakî, dema sêwirana tişta "meqbûza dravê", we, xwe dispêre sondên beşa firotanê, îhtîmala çalakiyê danî. yek pêşvebirina ji bo çend çeperên kontrolê (lê ne berevajî):
Û piştî demekê, hevkaran stratejiyek kirrûbirra nû destnîşan kirin ku tê de ew dikarin li ser heman pozîsyonê tevbigerin çend promotions di heman demê de. Û naha hûn hewce ne ku tabloyan bi veqetandina pêwendiyê di nav tiştek cûda de biguhezînin.
(Hemû tiştên ku jêderketî yên ku nuha kontrolkirina pêşkeftinê tê de ye jî pêdivî ye ku bêne başkirin).
Têkiliyên di Data Vault û Modela Anchor de
Dûrxistina vê rewşê pir hêsan derket holê: hûn ne hewce ne ku ji beşa firotanê bawer bikin ku vê yekê bikin. hemî girêdan di destpêkê de di tabloyên cihê de têne hilanîn û wê wekî gelek-bi-gelek pêvajo bikin.
Ev nêzîkatî hate pêşniyar kirin Dan Linstedt wekî beşek ji paradîgmayê Data Vault û bi tevahî piştgirî kirin Lars Rönnbäck в Modela Anchor.
Wekî encamek, em yekem taybetmendiya cihêreng a metodolojiyên maqûl digirin:
Têkiliyên di navbera tiştan de ne di taybetmendiyên hebûnên dêûbav de têne hilanîn, lê celebek celebek cihê ne.
В Data Vault tabloyên girêdanê yên weha têne gotin Pêvek, û bi Modela Anchor - Girêdan. Di nihêrîna pêşîn de, ew pir dişibin hev, her çend cûdahiyên wan bi navê (ya ku dê li jêr were nîqaş kirin) neqede. Di her du mîmarî de, tabloyên girêdanê dikarin girêdin her hejmarek saziyan (ne pêwîst e 2).
Ev zêdebûnek xuyang ji bo guheztinê nermbûnek girîng peyda dike. Strukturek wusa ne tenê ji guheztinên di qertafên girêdanên heyî re, lê di heman demê de ji lêzêdekirina yên nû re jî tolerans dibe - heke naha pozîsyonek kontrolê jî girêdanek bi diravê ku ew vekiriye hebe, xuyangkirina girêdanek wusa dê bi hêsanî bibe pêvekek li ser tabloyên heyî bêyî ku bandorê li ti tişt û pêvajoyên heyî bike.
2. Dubarekirina daneyan
Pirsgirêka duyemîn a ku ji hêla mîmariyên maqûl ve hatî çareser kirin kêmtir eşkere ye û di rêza yekem de xwerû ye. Pîvana tîpa SCD2 (hêdî hêdî pîvanên celebê duyemîn diguhezin), her çend ne tenê ew.
Di depoyek klasîk de, pîvanek bi gelemperî tabloyek e ku di stûnên cihê de mifteyek cîgir (wek PK) û komek bişkok û taybetmendiyên karsaziyê vedihewîne.
Ger pîvanek guhertoyê piştgirî dike, sînorên derbasbûna guhertoyê li rêza standard a qadan têne zêdekirin, û çend guhertoyên ji bo rêzek di çavkaniyê de di depoyê de têne xuyang kirin (yek ji bo her guheztina taybetmendiyên versiyonê).
Ger pîvanek bi kêmanî yek taybetmendiyek guhertoya ku pir caran diguhere dihewîne, dê hejmara guhertoyên pîvanek weha balkêş be (her çend taybetmendiyên mayî neyên guherandin an jî qet neguherin), û heke çend taybetmendiyên weha hebin, hejmara guhertoyan dikare ji hejmara wan qat bi qat mezin dibin. Ev pîvan dikare jimarek girîng cîhê dîskê bigire, her çend pir daneyên ku ew hildigire bi tenê kopiyên nirxên taybetmendiya neguhêrbar ên ji rêzên din in.
Di heman demê de, ew pir caran tê bikaranîn denormalîzasyon - Hin taybetmendî bi mebest wekî nirxek têne hilanîn, û ne wekî girêdanek bi pirtûkek referansê an pîvanek din ve têne hilanîn. Ev nêzîkatî gihîştina daneyê bileztir dike, dema ku bigihîje pîvanek hejmara tevlêbûnê kêm dike.
Bi gelemperî ev dibe sedema heman agahî bi hevdemî li çend cihan tên tomarkirin. Mînakî, agahdariya li ser devera niştecîh û kategoriya xerîdar dikare di heman demê de di pîvanên "Xerîdar" û rastiyên "Kirin", "Radestkirin" û "Bêgumanên Navenda Bangê" de, û hem jî di "Xerîdar - Rêvebirê Xerîdar" de werin hilanîn. ” tabloya girêdanê.
Bi gelemperî, ya ku li jor hatî destnîşan kirin ji bo pîvanên birêkûpêk (ne-versiyonê) derbas dibe, lê di yên guhertoyan de dibe ku ew xwedan pîvanek cûda bin: xuyangkirina guhertoyek nû ya tiştekê (nemaze di paşverû de) ne tenê dibe sedema nûvekirina hemî têkildar. tabloyan, lê ji bo xuyangiya kaskadî ya guhertoyên nû yên tiştên têkildar - dema ku Tablo 1 ji bo avakirina Tablo 2, û Tablo 2 ji bo avakirina Tablo 3, hwd tê bikar anîn. Tewra ku yek taybetmendiyek Tabloya 1-ê di avakirina Tablo 3-ê de beşdar nebe (û taybetmendiyên din ên Tabloya 2-ê ku ji çavkaniyên din hatine wergirtin tevlê bibin), guhertokirina vê çêkirinê bi kêmanî dê bibe sedema sermayek zêde, û herî zêde jî berbi zêdebûnê. guhertoyên di Tabloya 3. de ku qet pêwendiya wê bi wê re tune ye, û ji zincîrê bêtir.
3. Tevliheviya nehêle ya rework
Di heman demê de, her pêşangehek nû ya ku li ser bingeha yekî din hatî çêkirin, dema ku guhertin li ETL têne çêkirin, hejmara cîhên ku dane dikarin "ji hev cuda bibin" zêde dike. Ev, di encamê de, dibe sedema zêdebûna tevliheviya (û dirêjahiya) her guhertoya paşîn.
Ger jor pergalên bi pêvajoyên ETL yên kêm kêm hatine guheztin diyar dike, hûn dikarin di paradîgmayek weha de bijîn - hûn tenê hewce ne ku pê ewle bibin ku guheztinên nû bi rast li hemî tiştên têkildar têne çêkirin. Ger guheztin bi gelemperî çêdibin, îhtîmala ku bi xeletî "wenda" çend girêdan pir zêde dibe.
Digel vê yekê, heke em bihesibînin ku ETL-ya "guhertokirî" ji ya "ne-guhertoyî" pir tevlihevtir e, dema ku pir caran vê saziyê nûve dikin dûrketina ji xeletiyan pir dijwar dibe.
Di Data Vault û Modela Anchor de tişt û taybetmendiyan hilîne
Nêzîkatiya ku ji hêla nivîskarên mîmariya nerm ve hatî pêşniyar kirin dikare wiha were formule kirin:
Pêdivî ye ku meriv çi diguhere ji ya ku dimîne ji hev veqetîne. Ango, mifteyên cuda ji taybetmendiyan hilînin.
Lêbelê, divê meriv tevlihev neke ne versiyonê taybetmendî bi neguherî: ya yekem dîroka guheztinên xwe hilnagire, lê dikare biguhezîne (mînak, gava rastkirina xeletiyek têketinê an wergirtina daneya nû); ya duyemîn qet naguhere.
Di Daneyên Vault û Modela Anchor de çi bi rastî dikare bêguhezbar were hesibandin, xalên dîtinê cûda dibin.
Ji aliyê mîmarî ve Data Vault, dikare bê guhertin bête hesibandin hemû set of keys - xwezayî (TIN ya rêxistinê, koda hilberê di pergala çavkaniyê de, hwd.) û surrogate. Di vê rewşê de, taybetmendiyên mayî dikarin li gorî çavkanî û / an jî frekansa guhertinan li koman bêne dabeş kirin Ji bo her komê tabloyek cuda bihêlin bi komek serbixwe ya versiyonên.
Di paradîgmayê de Modela Anchor nayê guhertin tenê mifteya surrogate esas. Her tiştê din (tevî bişkojkên xwezayî) tenê rewşek taybetî ya taybetmendiyên wê ye. Wherein hemî taybetmendî ji hêla xwerû ve ji hev serbixwe ne, lewra ji bo her taybetmendiyek a tabloya cuda.
В Data Vault tabloyên ku mifteyên sazûmanan tê de hene têne gotin Hubami. Hub her gav komek sabît a zeviyan vedihewîne:
- Keys Entity xwezayî
- Mifteya surrogate
- Girêdana çavkaniyê
- Demê lêzêdekirina tomar bikin
Mesajên li Hubs qet naguhere û guhertoyên wan tune. Ji derve ve, hub pir dişibin tabloyên celeb-nexşeya ID-ê yên ku di hin pergalan de têne bikar anîn da ku surrogatan çêbikin, lêbelê, tê pêşniyar kirin ku di Data Vault de haşek ji komek bişkojkên karsaziyê wekî surrogat bikar bînin. Ev nêzîkatî barkirina têkilî û taybetmendiyên ji çavkaniyan hêsan dike (hûn ne hewce ne ku hûn beşdarî navendê bibin da ku cîhgirek bidest bixin, hûn tenê hewce ne ku haşa kilîtek xwezayî hesab bikin), lê dikare bibe sedema pirsgirêkên din (girêdayî, mînakî, bi pevçûnan , karakter û tîpên neçapkirî yên di bişkojkên rêzan de, hwd. .p.), ji ber vê yekê ew bi gelemperî nayê pejirandin.
Hemî taybetmendiyên din ên hebûnê di tabloyên taybetî yên ku jê re tê gotin têne hilanîn Satellites. Yek hub dikare çend satelaytan hebin ku komek taybetmendiyên cihêreng hilînin.
Dabeşkirina taybetmendiyan di nav satelîtan de li gorî prensîbê pêk tê guhertina hevbeş - Di yek satelaytê de taybetmendiyên ne-guhertokirî dikarin werin hilanîn (mînak, dîroka jidayikbûnê û SNILS ji bo kesek), li yekî din - guhertoyên kêm kêm têne guheztin (mînak, paşnav û hejmara pasaportê), di ya sêyemîn de - yên ku pir caran diguhezin. (mînak, navnîşana radestkirinê, kategorî, roja fermana paşîn, hwd.). Di vê rewşê de, guhertokirin di asta satelaytên ferdî de, û ne sazî bi tevahî, tête kirin, ji ber vê yekê tê pêşniyar kirin ku taybetmendî werin belavkirin da ku hevberdana guhertoyên di hundurê yek satelaytê de hindik be (ku jimara giştî ya guhertoyên hilanîn kêm dike ).
Di heman demê de, ji bo xweşbînkirina pêvajoya barkirina daneyê, taybetmendiyên ku ji çavkaniyên cihêreng têne wergirtin bi gelemperî di satelaytên kesane de têne girtin.
Satelîtan bi rêya Hub-ê re têkilî daynin key biyanî (ku bi 1-ji-gelek cardinality re têkildar e). Ev tê vê wateyê ku gelek nirxên taybetmendiyê (mînak, çend hejmarên têlefonê yên têkiliyê ji bo yek xerîdar) ji hêla vê mîmariya "default" ve têne piştgirî kirin.
В Modela Anchor maseyên ku mifteyên hilanîn têne gotin Anchors. Û ew diparêzin:
- Tenê mifteyên surrogate
- Girêdana çavkaniyê
- Demê lêzêdekirina tomar bikin
Mifteyên xwezayî ji nêrîna Modela Ankerê têne hesibandin taybetmendiyên asayî. Dibe ku ev vebijark ji bo têgihiştinê dijwartir xuya bike, lê ew ji bo naskirina objeyê pir firehtir dide.
Mînakî, heke daneyên di derheqê heman hebûnê de dikarin ji pergalên cûda werin, ku her yek ji wan mifteya xweya xwezayî bikar tîne. Di Data Vault de, ev dikare bibe sedema strukturên pir giran ên çend navendê (yek ji her çavkaniyek + guhertoyek masterê ya yekbûyî), dema ku di modela Anchor de, mifteya xwezayî ya her çavkaniyek dikeve nav taybetmendiya xwe û dikare dema ku serbixwe bar dike were bikar anîn. hemû yên din.
Lê li vir xalek xapînok heye: heke taybetmendiyên pergalên cihêreng di yek hebûnê de werin berhev kirin, bi îhtîmalek mezin hindek hene. qaîdeyên "zeliqandinê", ku divê pergal fêm bike ku tomarên ji çavkaniyên cihêreng bi yek mînakek saziyê re têkildar in.
В Data Vault ev qaîdeyên bi îhtîmaleke mezin dê avabûnê diyar bikin "Navenda surrogate" ya saziya masterê û bi tu awayî bandorê li Hubên ku mifteyên çavkaniya xwezayî û taybetmendiyên wan ên orîjînal hilîne, neke. Ger di deverekê de qaîdeyên hevgirtinê biguhezin (an jî taybetmendiyên ku ew pê têne kirin têne nûve kirin), ew ê bes be ku hûn navendên surrogate ji nû ve bikin.
В Modela Ankerê saziyek wusa bi îhtîmalek mezin dê tê de were hilanîn tenê lenger. Ev tê wê wateyê ku hemî taybetmendî, bêyî ku ew ji kîjan çavkaniyê werin, dê bi heman surrogatê ve werin girêdan. Veqetandina tomarên bi xeletî yên yekbûyî û, bi gelemperî, şopandina pêwendiya yekbûnê di pergalek wusa de dikare pir dijwartir be, nemaze heke qaîdeyên pir tevlihev in û pir caran diguhezin, û heman taybetmendî dikare ji çavkaniyên cihêreng were wergirtin (her çend bê guman ew e mimkun e, ji ber ku her guhertoya taybetmendiyê girêdanek bi çavkaniya xwe ve digire).
Di her rewşê de, heke pergala we pêdivî ye ku fonksiyonê bicîh bîne jêbirin, tomarên hevgirtinê û hêmanên din ên MDM, hêja ye ku meriv bi taybetî balê bikişîne ser aliyên hilanîna kilîtên xwezayî di metodolojiyên hejker de. Ihtîmal e ku sêwirana mezin a Data Vault ji nişkê ve di warê xeletiyên hevgirtinê de ewletir be.
Modela Ankerê di heman demê de celebek pêvek a ku jê re tê gotin jî peyda dike Girêkkirin ew bi bingehîn taybetî ye cureya dejenere ya lengerê, ku dikare tenê yek taybetmendiyek hebe. Tê payîn ku girêk ji bo hilanîna pelrêçanên guncan werin bikar anîn (mînak, zayend, rewşa zewacê, kategoriya karûbarê xerîdar, hwd.). Berevajî Anchor, Knot tabloyên taybetmendiyê yên têkildar tune, û taybetmendiya wê ya yekane (nav) her gav bi mifteyê re di heman tabloyê de tê hilanîn. Nod bi tabloyên girêdanê (Tie) bi Anchors ve têne girêdan bi heman rengî ku Anchors bi hev ve têne girêdan.
Di derbarê karanîna Nodes de nerînek zelal tune. Bo nimûne, , ku bi awayekî çalak bikaranîna Modela Ankerê li Rûsyayê pêşdixe, bawer dike (ne bêaqil) ku ji bo yek pirtûkek referansê jî bi teqez nayê gotin ku ew her tim dê statîk û yek-asta be, ji ber vê yekê çêtir e ku meriv tavilê ji bo hemî tiştan Anchor-a tam bikar bîne.
Cûdahiyek din a girîng di navbera Data Vault û modela Anchor de hebûna ye taybetmendiyên girêdanan:
В Data Vault Girêdan heman tiştên bêkêmasî yên wekî Hubs in, û dikarin hebin taybetmendiyên xwe. ew Modela Ankerê Girêdanên tenê ji bo girêdana Anchors û nikarin xwedî taybetmendiyên xwe bin. Ev cûdahî di nêzîkatiyên modelkirinê yên pir cûda de encam dide facts, ku dê bêtir nîqaş kirin.
Depokirina rastiyê
Berî vê yekê, me bi taybetî li ser modela pîvandinê axivî. Rastî hinekî kêmtir zelal in.
В Data Vault tiştekî tîpîk ji bo hilanîna rastiyan e Girêk, di satelaytên wan de nîşaneyên rastîn têne zêdekirin.
Ev nêzîkatî xuya dike. Ew bi hêsanî gihîştina nîşaneyên analîzkirî peyda dike û bi gelemperî dişibihe tabloyek rastiya kevneşopî ye (tenê nîşanker ne di tabloyê bixwe, lê di tabloya "cîran" de têne hilanîn). Lê kêmasî jî hene: yek ji guheztinên tîpîk ên modelê - berfirehkirina mifteya rastiyê - hewce dike zêdekirina mifteyek biyanî ya nû li Girêdanê. Û ev, di encamê de, modularîteyê "dişkîne" û dibe sedema hewcedariya guheztina tiştên din.
В Modela Ankerê Têkiliyek nikare taybetmendiyên xwe hebin, ji ber vê yekê ev nêzîkatî dê nexebite - bê guman divê hemî taybetmendî û nîşangir bi yek ankerek taybetî ve werin girêdan. Encam ji vê hêsan e - Her rastiyek jî lengereke xwe hewce dike. Ji bo hin ji yên ku em bikar tînin ku em wekî rastiyan bihesibînin, ev dibe ku xwezayî xuya bike - mînakî, rastiya kirînê dikare bi rengek bêkêmasî li tiştê "ferman" an "wergirtin", serdana malperek danişînê, hwd. Lê di heman demê de rastî jî hene ku ji bo wan ne hêsan e ku meriv "tiştek hilgirê" wusa xwezayî bibîne - mînakî, bermayiyên tiştan di depoyan de di destpêka her rojê de.
Li gorî vê yekê, dema ku di modela Anchor de mifteyek rastînek berfireh bikin, pirsgirêkên modularîteyê dernakeve ( bes e ku meriv bi tenê Têkiliyek nû li Anchor-a têkildar lê zêde bike), lê sêwirandina modelek ji bo nîşandana rastiyan kêmtir nezelal e; Dibe ku Anchorên "çêkirî" xuya bibin. ku modela armanca karsaziyê bi rengek ne diyar nîşan dide.
Çiqas nermbûn tê bidestxistin
Avakirina encam di her du rewşan de pêk tê tabloyên girîng zêdetirji pîvana kevneşopî. Lê dibe ku bigire cîhê dîskê bi girîngî kêmtir bi heman koma taybetmendiyên guhertoyî yên wekî pîvana kevneşopî. Bi xwezayî, li vir sêrbazek tune - ew hemî li ser normalîzekirinê ye. Bi belavkirina taybetmendiyan li ser Satelîtan (di Data Vault) an tabloyên takekesî (Modela Anchor), em kêm dikin (an bi tevahî ji holê radikin) dubarekirina nirxên hin taybetmendiyan dema ku yên din diguhezînin.
bo Data Vault serkeftin dê li ser belavkirina taybetmendiyan di nav Satelîtan de û ji bo ve girêdayî be Modela Ankerê - hema hema rasterast bi rêjeya navînî ya guhertoyên her tiştê pîvandinê re têkildar e.
Lêbelê, teserûfa cîhê avantajek girîng, lê ne sereke ye ku taybetmendiyan ji hev veqetîne. Digel hilanîna têkiliyan cuda, ev nêzîkatî dikanê dike design modular. Ev tê vê wateyê ku di modelek wusa de lêzêdekirina hem taybetmendiyên kesane û hem jî hemî deverên mijara nû di modelek weha de xuya dike superstructure li ser komek tiştên heyî bêyî ku wan biguhezîne. Û ev tam ya ku metodolojiyên diyarkirî maqûl dike.
Ev di heman demê de dişibe derbasbûna ji hilberîna perçeyê berbi hilberîna girseyî - heke di nêzîkatiya kevneşopî de her tabloya modelê yekta ye û baldariyek taybetî hewce dike, wê hingê di metodolojiyên maqûl de ew jixwe komek "beş"ên standard e. Ji aliyekî ve, bêtir tablo hene, û pêvajoyên barkirin û wergirtina daneyan divê tevlihevtir xuya bikin. Li aliyê din jî dibin mîna. Wate dibe ku hebe otomatîk û metadata rêve kirin. Pirsa "em ê çawa deynin?", bersiva ku dikare beşek girîng ji xebata li ser sêwirana çêtirkirinan bigire, naha bi tenê ne hêja ye (û her weha pirsa di derbarê bandora guhertina modelê li ser pêvajoyên xebatê de ).
Ev nayê vê wateyê ku di pergalek weha de hîç ne hewceyî analîstan in - kesek hîn jî neçar e ku di nav komek tiştên bi taybetmendiyan de bixebite û fêhm bike ku li ku û çawa wê hemî bar bike. Lê mîqdara kar, û her weha îhtîmal û lêçûna xeletiyekê pir kêm dibe. Hem di qonaxa analîzê de û hem jî di dema pêşkeftina ETL de, ku di beşek girîng de dikare bi guherandina metadata were kêm kirin.
Aliyê tarî
Hemî yên jorîn her du nêzîkatiyan bi rastî maqûl, teknolojîk pêşkeftî û ji bo baştirkirina dubare dike. Bê guman, "bermîlek di rûnê de" jî heye, ku ez difikirim ku hûn jixwe dikarin li ser texmîn bikin.
Dabeşkirina daneyan, ku di binê modularîteya mîmariya nerm de ye, dibe sedema zêdebûna hejmara tabloyan û, li gorî vê, serserî ji bo tevlêbûna dema nimûne. Ji bo ku meriv bi hêsanî hemî taybetmendiyên pîvanê bistîne, di firotgehek klasîk de yek hilbijark bes e, lê mîmariyek maqûl dê rêzek tevheviyê hewce bike. Wekî din, heke van hemî tevlêbûnên ji bo raporan dikarin pêşwext werin nivîsandin, wê hingê analîstên ku fêrî nivîsandina SQL-ya bi destan in, dê du caran zirarê bibînin.
Gelek rastî hene ku vê rewşê hêsantir dike:
Dema ku bi pîvanên mezin re dixebitin, hemî taybetmendiyên wê hema hema qet carî hevdem nayên bikar anîn. Ev tê vê wateyê ku dibe ku ji ya ku di nihêrîna pêşîn de li modelê xuya dike kêmtir tevlêbûn hebin. Daneyên Vault di heman demê de dema ku taybetmendiyan ji satelaytan re veqetandin dikare frekansa parvekirina hêvîkirî jî bigire ber çavan. Di heman demê de, Hubs an Anchors bi xwe di serî de ji bo hilberîn û nexşeya surrogatên di qonaxa barkirinê de hewce ne û kêm kêm di pirsnameyê de têne bikar anîn (ev bi taybetî ji bo Anchors rast e).
Hemî girêdan bi key in. Digel vê yekê, awayê hilanîna daneya "tevlihev"tir, sermaya tabloyên şopandinê li ku derê hewce dike kêm dike (mînak, dema fîlterkirina li gorî nirxa taybetmendiyê). Ev dikare bibe sedema vê yekê ku nimûneya ji databasek normalîzekirî ya bi komek hevalbendan re dê ji şopandina yek pîvanek giran bi gelek guhertoyên li ser rêzek jî zûtir be.
Mînakî, li vir Gotar testek berawirdî ya berbiçav a performansa modela Anchor bi nimûneyek ji yek tabloyê vedihewîne.
Pir tişt bi motorê ve girêdayî ye. Gelek platformên nûjen mekanîzmayên xweşbîniya tevlêbûna navxweyî hene. Mînakî, MS SQL û Oracle dikarin tevlêbûnên tabloyan "derbaz bikin" heke daneyên wan ji bilî tevlêbûnên din li cîhek neyê bikar anîn û bandorê li hilbijartina dawîn (tablo/hilweşîna tevlêbûnê) neke, û MPP Vertica. , îsbat kiriye ku ji bo Modela Anchor motorek hêja ye, ji ber ku hin xweşbîniya destan a plana pirsê daye. Ji hêla din ve, hilanîna Modela Anchor, mînakî, li ser Click House, ku piştgirîya tevlêbûnê tixûbdar e, hîn jî wekî ramanek pir baş xuya nake.
Ji bilî vê, ji bo her du mîmarî hene tevgerên taybet, gihîştina daneyê hêsantir dike (hem ji hêla performansa pirsê ve hem jî ji bo bikarhênerên dawîn). Bo nimûne, Tabloyên Point-In-Time li Data Vault an fonksiyonên sifrê taybet di modela Anchor de.
Tevahî
Esasê sereke yên mîmariyên maqûl ên ku têne hesibandin modularbûna "sêwirana" wan e.
Ev milkê ku destûrê dide:
- Piştî hin amadekariyên destpêkê yên têkildarî danîna metadata û nivîsandina algorîtmayên bingehîn ên ETL, bi lez ji mişterî bi encama yekem di forma çend raporên ku daneyên tenê ji çend tiştên çavkanî vedihewîne. Ne hewce ye ku meriv bi tevahî modela objektê (tewra di asta jorîn de) bi tevahî bifikire.
- Modelek daneyê dikare bi tenê 2-3 tiştan dest bi xebatê bike (û bikêr be) û dûv re hêdî hêdî mezin dibin (li ser modela Anchor Nikolai berhevdana xweş bi mycelium).
- Pir çêtirbûn, di nav de berfirehkirina qada mijarê û lê zêdekirina çavkaniyên nû bandorê li fonksiyonên heyî nake û metirsiya şikandina tiştê ku jixwe dixebite nahêle.
- Bi saya veqetandina nav hêmanên standard, pêvajoyên ETL yên di pergalên weha de heman xuya dikin, nivîsandina wan xwe dide algorîtmkirinê û, di dawiyê de, otomatîkî.
Buhayê vê nermbûnê ye performansa. Ev nayê vê wateyê ku ne gengaz e ku meriv performansa pejirandî li ser modelên weha bi dest bixe. Pir caran ji na, dibe ku hûn bi tenê hewceyê bêtir hewildan û baldarî bi hûrgulî bin da ku bigihîjin metrîkên ku hûn dixwazin.
apps
Cureyên saziyê Data Vault
Agahiyên bêtir li ser Data Vault:
Cureyên saziyê Modela Anchor
Agahiyên bêtir li ser Modela Anchor:
Tabloya kurteya bi taybetmendî û cûdahiyên hevpar ên nêzîkatiyên berçav:
Source: www.habr.com