Ang pagbuo ng pasilidad ng imbakan ay isang mahaba at seryosong gawain.
Karamihan sa buhay ng isang proyekto ay nakasalalay sa kung gaano kahusay na naisip ang object model at base structure sa simula.
Ang pangkalahatang tinatanggap na diskarte ay naging at nananatiling iba't ibang mga opsyon para sa pagsasama-sama ng star scheme sa ikatlong normal na anyo. Bilang isang patakaran, ayon sa prinsipyo: paunang data - 3NF, mga showcase - bituin. Ang diskarteng ito, nasubok sa oras at sinusuportahan ng malaking dami ng pananaliksik, ay ang una (at kung minsan ang tanging) bagay na pumapasok sa isip ng isang may karanasan na espesyalista sa DWH kapag iniisip kung ano ang dapat na hitsura ng isang analytical repository.
Sa kabilang banda, ang negosyo sa pangkalahatan at partikular na mga kinakailangan ng customer ay may posibilidad na mabilis na magbago, at malamang na lumago ang data sa parehong "malalim" at "sa lawak". At dito lumilitaw ang pangunahing kawalan ng isang bituin - limitado flexibility.
At kung sa iyong tahimik at maaliwalas na buhay bilang isang developer ng DWH ay biglang:
- ang gawain ay bumangon "upang gumawa ng hindi bababa sa isang bagay nang mabilis, at pagkatapos ay makikita natin";
- isang mabilis na umuunlad na proyekto ang lumitaw, na may koneksyon ng mga bagong mapagkukunan at muling paggawa ng modelo ng negosyo nang hindi bababa sa isang beses sa isang linggo;
- lumitaw ang isang customer na walang ideya kung ano dapat ang hitsura ng system at kung anong mga function ang dapat nitong gumanap sa wakas, ngunit handang mag-eksperimento at patuloy na pinuhin ang nais na resulta habang patuloy na lumalapit dito;
- Bumaba ang project manager dala ang magandang balita: βAt ngayon, maliksi na tayo!β
O kung interesado ka lang na malaman kung paano ka pa makakagawa ng mga pasilidad ng imbakan - maligayang pagdating sa hiwa!
Ano ang ibig sabihin ng "flexibility"?
Una, tukuyin natin kung anong mga katangian ang dapat taglayin ng isang sistema upang matawag na βflexibleβ.
Hiwalay, ito ay nagkakahalaga ng pagbanggit na ang inilarawan na mga katangian ay dapat na partikular na nauugnay sa sistema, hindi sa proseso pag-unlad nito. Samakatuwid, kung nais mong basahin ang tungkol sa Agile bilang isang pamamaraan ng pag-unlad, mas mahusay na magbasa ng iba pang mga artikulo. Halimbawa, doon mismo, sa HabrΓ©, mayroong maraming mga kagiliw-giliw na materyales (tulad ng ΠΈ At ).
Hindi ito nangangahulugan na ang proseso ng pagbuo at ang istraktura ng data warehouse ay ganap na walang kaugnayan. Sa pangkalahatan, mas madali dapat itong bumuo ng isang Agile repository para sa isang maliksi na arkitektura. Gayunpaman, sa pagsasagawa, mas madalas na mayroong mga opsyon na may Agile development ng classic na DWH ayon sa Kimbal at DataVault - ayon sa Waterfall, kaysa sa mga masasayang pagkakataon ng flexibility sa dalawang anyo nito sa isang proyekto.
Kaya, anong mga kakayahan ang dapat magkaroon ng nababaluktot na imbakan? Mayroong tatlong puntos dito:
- Maagang paghahatid at mabilis na pagbabalik - Nangangahulugan ito na ang unang resulta ng negosyo (halimbawa, ang mga unang gumaganang ulat) ay dapat makuha nang maaga hangga't maaari, iyon ay, bago pa man ganap na idisenyo at ipatupad ang buong sistema. Bukod dito, ang bawat kasunod na rebisyon ay dapat ding tumagal ng kaunting oras hangga't maaari.
- Paulit-ulit na pagpipino - nangangahulugan ito na ang bawat kasunod na pagpapabuti ay dapat na perpektong hindi makakaapekto sa functionality na gumagana na. Ito ang sandaling ito na madalas na nagiging pinakamalaking bangungot sa malalaking proyekto - maaga o huli, ang mga indibidwal na bagay ay nagsisimulang makakuha ng napakaraming koneksyon na nagiging mas madali upang ganap na ulitin ang lohika sa isang kopya sa malapit kaysa magdagdag ng isang patlang sa isang umiiral na talahanayan. At kung nagulat ka na ang pagsusuri sa epekto ng mga pagbabago sa mga umiiral na bagay ay maaaring tumagal ng mas maraming oras kaysa sa mismong pagbabago, malamang na hindi ka pa nakakatrabaho sa malalaking data warehouse sa pagbabangko o telecom.
- Patuloy na umaangkop sa pagbabago ng mga kinakailangan sa negosyo - ang pangkalahatang istraktura ng bagay ay dapat na idinisenyo hindi lamang isinasaalang-alang ang posibleng pagpapalawak, ngunit sa pag-asa na ang direksyon ng susunod na pagpapalawak na ito ay hindi maaaring pinangarap sa yugto ng disenyo.
At oo, ang pagtugon sa lahat ng mga kinakailangang ito sa isang sistema ay posible (siyempre, sa ilang mga kaso at may ilang mga reserbasyon).
Sa ibaba ay isasaalang-alang ko ang dalawa sa mga pinakasikat na pamamaraan ng maliksi na disenyo para sa mga warehouse ng data - Modelo ng anchor ΠΈ Vault ng Data. Naiwan sa mga bracket ang napakahusay na mga diskarte gaya ng, halimbawa, EAV, 6NF (sa purong anyo nito) at lahat ng nauugnay sa mga solusyon sa NoSQL - hindi dahil mas masahol pa ang mga ito, at hindi dahil sa kasong ito ang artikulo ay nagbabanta na makakuha ng ang dami ng karaniwang disser. Ang lahat ng ito ay nauugnay sa mga solusyon ng isang bahagyang naiibang klase - alinman sa mga diskarte na maaari mong gamitin sa mga partikular na kaso, anuman ang pangkalahatang arkitektura ng iyong proyekto (tulad ng EAV), o sa iba pang mga paradigma sa pag-imbak ng impormasyon sa buong mundo (tulad ng mga database ng graph at iba pang mga opsyon NoSQL).
Mga problema ng "klasikal" na diskarte at ang kanilang mga solusyon sa mga nababaluktot na pamamaraan
Sa pamamagitan ng "klasikal" na diskarte ang ibig kong sabihin ay ang magandang lumang bituin (anuman ang partikular na pagpapatupad ng mga pinagbabatayan na layer, nawa'y patawarin ako ng mga tagasunod ng Kimball, Inmon at CDM).
1. Rigid cardinality ng mga koneksyon
Ang modelong ito ay batay sa isang malinaw na dibisyon ng data sa Dimensyon ΠΈ katotohanan. At ito, mapahamak, ay lohikal - pagkatapos ng lahat, ang pagsusuri ng data sa napakalaking karamihan ng mga kaso ay bumababa sa pagsusuri ng ilang mga numerical indicator (katotohanan) sa ilang mga seksyon (mga sukat).
Sa kasong ito, ang mga koneksyon sa pagitan ng mga bagay ay itinatag sa anyo ng mga relasyon sa pagitan ng mga talahanayan gamit ang isang dayuhang key. Ito ay mukhang medyo natural, ngunit agad na humahantong sa unang limitasyon ng kakayahang umangkop - mahigpit na kahulugan ng kardinalidad ng mga koneksyon.
Nangangahulugan ito na sa yugto ng disenyo ng talahanayan, dapat mong tumpak na matukoy para sa bawat pares ng mga kaugnay na bagay kung maiuugnay ang mga ito bilang marami-sa-marami, o 1-sa-marami lang, at "saang direksyon". Direktang tinutukoy nito kung aling talahanayan ang magkakaroon ng pangunahing key at kung alin ang magkakaroon ng foreign key. Ang pagbabago sa saloobing ito kapag natanggap ang mga bagong kinakailangan ay malamang na hahantong sa muling paggawa ng base.
Halimbawa, kapag nagdidisenyo ng bagay na "resibo ng pera", ikaw, na umaasa sa mga panunumpa ng departamento ng pagbebenta, ay inilatag ang posibilidad ng pagkilos isang promosyon para sa ilang mga posisyon sa tseke (ngunit hindi kabaligtaran):
At pagkaraan ng ilang oras, ang mga kasamahan ay nagpakilala ng isang bagong diskarte sa marketing kung saan maaari silang kumilos sa parehong posisyon ilang mga promo sa parehong oras. At ngayon kailangan mong baguhin ang mga talahanayan sa pamamagitan ng paghihiwalay ng relasyon sa isang hiwalay na bagay.
(Ang lahat ng hinangong bagay kung saan isinasama ngayon ang pagsusuri sa promosyon ay kailangan ding pahusayin).
Mga Relasyon sa Data Vault at Anchor Model
Ang pag-iwas sa sitwasyong ito ay naging medyo simple: hindi mo kailangang magtiwala sa departamento ng pagbebenta upang gawin ito. lahat ng mga koneksyon ay unang naka-imbak sa magkahiwalay na mga talahanayan at iproseso ito bilang many-to-many.
Ang pamamaraang ito ay iminungkahi Dan Linstedt bilang bahagi ng paradigm Vault ng Data at ganap na suportado Lars RΓΆnnbΓ€ck Π² Modelo ng Anchor.
Bilang resulta, nakuha namin ang unang natatanging tampok ng mga nababaluktot na pamamaraan:
Ang mga ugnayan sa pagitan ng mga bagay ay hindi nakaimbak sa mga katangian ng mga pangunahing entity, ngunit isang hiwalay na uri ng bagay.
Π Vault ng Data tinatawag ang mga naturang linking table linkat sa Modelo ng Anchor - Itali. Sa unang sulyap, halos magkapareho sila, kahit na ang kanilang mga pagkakaiba ay hindi nagtatapos sa pangalan (na tatalakayin sa ibaba). Sa parehong mga arkitektura, maaaring mag-link ang mga talahanayan ng link anumang bilang ng mga entity (hindi naman 2).
Ang redundancy na ito, sa unang tingin, ay nagbibigay ng makabuluhang flexibility para sa mga pagbabago. Ang ganitong istraktura ay nagiging mapagparaya hindi lamang sa mga pagbabago sa cardinality ng mga umiiral na mga link, kundi pati na rin sa pagdaragdag ng mga bago - kung ngayon ang isang posisyon ng tseke ay mayroon ding link sa cashier na nakalusot dito, ang hitsura ng naturang link ay simpleng maging isang add-on sa mga kasalukuyang talahanayan nang hindi naaapektuhan ang anumang mga umiiral na bagay at proseso.
2. Pagdoble ng data
Ang pangalawang problema na nalutas sa pamamagitan ng nababaluktot na mga arkitektura ay hindi gaanong halata at likas sa unang lugar. Mga sukat ng uri ng SCD2 (dahan-dahang nagbabago ang mga sukat ng pangalawang uri), bagaman hindi lamang sila.
Sa isang klasikong warehouse, ang isang dimensyon ay karaniwang isang talahanayan na naglalaman ng isang kahalili na susi (bilang isang PK) at isang hanay ng mga susi at katangian ng negosyo sa magkakahiwalay na mga column.
Kung sinusuportahan ng isang dimensyon ang pag-bersyon, ang mga hangganan ng validity ng bersyon ay idaragdag sa karaniwang hanay ng mga field, at para sa isang row sa pinagmulan, maraming bersyon ang lalabas sa repositoryo (isa para sa bawat pagbabago sa mga attribute na may bersyon).
Kung ang isang dimensyon ay naglalaman ng hindi bababa sa isang madalas na nagbabagong bersyon na katangian, ang bilang ng mga bersyon ng naturang dimensyon ay magiging kahanga-hanga (kahit na ang natitirang mga katangian ay hindi na-bersyon o hindi kailanman nagbabago), at kung mayroong ilang mga naturang katangian, ang bilang ng mga bersyon ay maaaring lumaki nang husto mula sa kanilang bilang. Ang dimensyong ito ay maaaring tumagal ng isang malaking halaga ng espasyo sa disk, bagama't ang karamihan sa data na iniimbak nito ay mga duplicate lamang ng hindi nababagong mga halaga ng katangian mula sa iba pang mga hilera.
Kasabay nito, ito ay madalas ding ginagamit denormalisasyon β ang ilang mga katangian ay sadyang iniimbak bilang isang halaga, at hindi bilang isang link sa isang reference na libro o ibang dimensyon. Pinapabilis ng diskarteng ito ang pag-access ng data, na binabawasan ang bilang ng mga pagsasama kapag nag-a-access ng isang dimensyon.
Kadalasan ito ay humahantong sa ang parehong impormasyon ay naka-imbak nang sabay-sabay sa ilang mga lugar. Halimbawa, ang impormasyon tungkol sa rehiyon ng tirahan at kategorya ng kliyente ay maaaring sabay na maimbak sa mga dimensyon ng βKliyenteβ at ang mga katotohanang βPagbiliβ, βPaghahatidβ at βMga Tawag sa Call Center,β gayundin sa βClient - Client Manager β link table.
Sa pangkalahatan, nalalapat ang inilarawan sa itaas sa mga regular (hindi bersyon) na mga dimensyon, ngunit sa mga bersyon na maaaring magkaroon sila ng ibang sukat: ang hitsura ng isang bagong bersyon ng isang bagay (lalo na sa pagbabalik-tanaw) ay humahantong hindi lamang sa pag-update ng lahat ng nauugnay. mga talahanayan, ngunit sa mga cascading na hitsura ng mga bagong bersyon ng mga kaugnay na bagay - kapag ang Talahanayan 1 ay ginamit upang bumuo ng Talahanayan 2, at ang Talahanayan 2 ay ginagamit upang bumuo ng Talahanayan 3, atbp. Kahit na hindi isang solong katangian ng Talahanayan 1 ang kasangkot sa pagbuo ng Talahanayan 3 (at ang iba pang mga katangian ng Talahanayan 2 na nakuha mula sa iba pang mga mapagkukunan ay kasangkot), ang pag-bersyon sa konstruksiyon na ito ay hindi bababa sa hahantong sa karagdagang overhead, at sa maximum hanggang sa dagdag. mga bersyon sa Talahanayan 3. na walang kinalaman dito, at higit pa sa kadena.
3. Nonlinear complexity ng rework
Kasabay nito, ang bawat bagong storefront na itinayo batay sa isa pa ay nagpapataas ng bilang ng mga lugar kung saan ang data ay maaaring "mag-iba" kapag ang mga pagbabago ay ginawa sa ETL. Ito naman, ay humahantong sa pagtaas ng pagiging kumplikado (at tagal) ng bawat kasunod na rebisyon.
Kung inilalarawan ng nasa itaas ang mga system na may bihirang binagong mga proseso ng ETL, maaari kang mamuhay sa gayong paradigm - kailangan mo lang tiyakin na ang mga bagong pagbabago ay ginawa nang tama sa lahat ng nauugnay na bagay. Kung madalas mangyari ang mga pagbabago, ang posibilidad ng aksidenteng "nawawala" ang ilang koneksyon ay tumataas nang malaki.
Kung, bilang karagdagan, isasaalang-alang namin na ang "bersyon" na ETL ay higit na kumplikado kaysa sa "hindi bersyon", nagiging mahirap na maiwasan ang mga pagkakamali kapag madalas na ina-update ang buong pasilidad na ito.
Pag-iimbak ng mga bagay at attribute sa Data Vault at Anchor Model
Ang diskarte na iminungkahi ng mga may-akda ng nababaluktot na mga arkitektura ay maaaring mabalangkas tulad ng sumusunod:
Ito ay kinakailangan upang paghiwalayin kung ano ang mga pagbabago mula sa kung ano ang nananatiling pareho. Iyon ay, mag-imbak ng mga susi nang hiwalay sa mga katangian.
Gayunpaman, hindi dapat malito ang isa hindi bersyon katangian na may hindi nagbabago: hindi iniimbak ng una ang kasaysayan ng mga pagbabago nito, ngunit maaaring magbago (halimbawa, kapag nagwawasto ng error sa pag-input o tumatanggap ng bagong data); hindi nagbabago ang pangalawa.
Ang mga punto ng view ay naiiba sa kung ano ang eksaktong maituturing na hindi nababago sa Data Vault at sa Anchor Model.
Mula sa isang arkitektura punto ng view Vault ng Data, ay maaaring ituring na hindi nagbabago buong hanay ng mga susi - natural (TIN ng organisasyon, code ng produkto sa source system, atbp.) at kahalili. Sa kasong ito, ang natitirang mga katangian ay maaaring hatiin sa mga pangkat ayon sa pinagmulan at/o dalas ng mga pagbabago at Panatilihin ang isang hiwalay na talahanayan para sa bawat pangkat na may independiyenteng hanay ng mga bersyon.
Sa paradigm Modelo ng Anchor itinuturing na hindi nagbabago surrogate key lang kakanyahan. Ang lahat ng iba pa (kabilang ang mga natural na susi) ay isang espesyal na kaso lamang ng mga katangian nito. Kung saan lahat ng mga katangian ay independyente sa isa't isa bilang default, kaya para sa bawat katangian a hiwalay na mesa.
Π Vault ng Data Tinatawag ang mga talahanayan na naglalaman ng mga susi ng entity Hubami. Palaging naglalaman ang mga hub ng nakapirming hanay ng mga field:
- Mga Susi ng Likas na Entity
- Susi ng kahalili
- Link sa source
- Itala ang pagdaragdag ng oras
Mga post sa Hubs hindi magbabago at walang mga bersyon. Sa panlabas, ang mga hub ay halos kapareho sa mga talahanayan ng uri ng ID-map na ginagamit sa ilang system upang bumuo ng mga kahalili, gayunpaman, inirerekomendang gumamit ng hash mula sa isang hanay ng mga key ng negosyo bilang mga kahalili sa Data Vault. Pinapasimple ng diskarteng ito ang paglo-load ng mga relasyon at attribute mula sa mga source (hindi mo kailangang sumali sa hub para makakuha ng surrogate, kailangan mo lang kalkulahin ang hash ng isang natural na key), ngunit maaaring magdulot ng iba pang mga problema (kaugnay, halimbawa, sa mga banggaan , case at hindi napi-print na mga character sa mga string key, atbp. .p.), kaya hindi ito karaniwang tinatanggap.
Ang lahat ng iba pang mga katangian ng entity ay naka-imbak sa mga espesyal na talahanayan na tinatawag Mga satellite. Ang isang hub ay maaaring magkaroon ng ilang satellite na nag-iimbak ng iba't ibang hanay ng mga katangian.
Ang pamamahagi ng mga katangian sa mga satellite ay nangyayari ayon sa prinsipyo magkasanib na pagbabago β sa isang satellite ay maaaring maimbak ang mga hindi bersyon na mga katangian (halimbawa, petsa ng kapanganakan at SNILS para sa isang indibidwal), sa isa pa - bihirang baguhin ang mga bersyon (halimbawa, apelyido at numero ng pasaporte), sa pangatlo - madalas na nagbabago ng mga (halimbawa, address ng paghahatid, kategorya, petsa ng huling order, atbp.). Sa kasong ito, ang bersyon ay isinasagawa sa antas ng mga indibidwal na satellite, at hindi ang entity sa kabuuan, kaya ipinapayong ipamahagi ang mga katangian upang ang intersection ng mga bersyon sa loob ng isang satellite ay minimal (na binabawasan ang kabuuang bilang ng mga nakaimbak na bersyon. ).
Gayundin, upang ma-optimize ang proseso ng paglo-load ng data, ang mga katangiang nakuha mula sa iba't ibang mapagkukunan ay kadalasang kasama sa mga indibidwal na satellite.
Nakikipag-ugnayan ang mga satellite sa Hub sa pamamagitan ng dayuhang susi (na tumutugma sa 1-to-many cardinality). Nangangahulugan ito na maramihang mga halaga ng katangian (halimbawa, maraming numero ng telepono sa pakikipag-ugnayan para sa isang kliyente) ay sinusuportahan ng "default" na arkitektura na ito.
Π Modelo ng Anchor ang mga talahanayan na nag-iimbak ng mga susi ay tinatawag Mga anchor. At pinananatili nila:
- Mga surrogate key lang
- Link sa source
- Itala ang pagdaragdag ng oras
Ang mga natural na susi mula sa punto ng view ng Anchor Model ay isinasaalang-alang ordinaryong katangian. Ang pagpipiliang ito ay maaaring mukhang mas mahirap maunawaan, ngunit nagbibigay ito ng higit pang saklaw para sa pagtukoy sa bagay.
Halimbawa, kung ang data tungkol sa parehong entity ay maaaring magmula sa iba't ibang mga system, bawat isa ay gumagamit ng sarili nitong natural na key. Sa Data Vault, maaari itong humantong sa medyo masalimuot na istruktura ng ilang hub (isa sa bawat source + isang pinag-isang master version), habang sa Anchor model, ang natural na susi ng bawat source ay nahuhulog sa sarili nitong katangian at magagamit kapag naglo-load nang hiwalay sa lahat ng iba pa.
Ngunit mayroon ding isang mapanlinlang na punto dito: kung ang mga katangian mula sa iba't ibang mga sistema ay pinagsama sa isang entity, malamang na mayroong ilang mga patakaran ng "gluing", kung saan dapat maunawaan ng system na ang mga talaan mula sa iba't ibang pinagmulan ay tumutugma sa isang instance ng entity.
Π Vault ng Data ang mga patakarang ito ay malamang na matukoy ang pagbuo βsurrogate hubβ ng master entity at hindi sa anumang paraan nakakaimpluwensya sa mga Hub na nag-iimbak ng mga natural na source key at ang kanilang mga orihinal na katangian. Kung sa isang punto ay magbabago ang mga panuntunan sa pagsasama-sama (o ang mga katangian kung saan ito ginagampanan ay na-update), ito ay sapat na upang i-reformat ang mga kahaliling hub.
Π Modelo ng anchor malamang na maiimbak ang naturang entity ang tanging anchor. Nangangahulugan ito na ang lahat ng mga katangian, anuman ang pinagmulan ng mga ito, ay iuugnay sa parehong kahalili. Ang paghihiwalay ng mga maling pinagsamang tala at, sa pangkalahatan, ang pagsubaybay sa kaugnayan ng pagsasama sa naturang sistema ay maaaring maging mas mahirap, lalo na kung ang mga patakaran ay medyo kumplikado at madalas na nagbabago, at ang parehong katangian ay maaaring makuha mula sa iba't ibang mga mapagkukunan (bagaman ito ay tiyak na posible, dahil ang bawat bersyon ng katangian ay nagpapanatili ng isang link sa pinagmulan nito).
Sa anumang kaso, kung ang iyong system ay dapat na ipatupad ang pag-andar deduplication, pagsasama-sama ng mga talaan at iba pang elemento ng MDM, ito ay nagkakahalaga ng pagbibigay ng partikular na pansin sa mga aspeto ng pag-iimbak ng mga natural na susi sa maliksi na pamamaraan. Malamang na ang bulkier na disenyo ng Data Vault ay biglang magiging mas ligtas sa mga tuntunin ng mga error sa pagsasama.
Modelo ng anchor nagbibigay din ng karagdagang uri ng bagay na tinatawag Knot ito ay mahalagang espesyal degenerate na uri ng anchor, na maaaring maglaman lamang ng isang katangian. Ang mga node ay dapat na gamitin upang mag-imbak ng mga patag na direktoryo (halimbawa, kasarian, katayuan sa pag-aasawa, kategorya ng serbisyo sa customer, atbp.). Hindi tulad ng Anchor, the Knot ay walang nauugnay na mga talahanayan ng katangian, at ang tanging katangian nito (pangalan) ay palaging naka-imbak sa parehong talahanayan na may susi. Ang mga node ay konektado sa Mga Anchor sa pamamagitan ng mga tie table (Tie) sa parehong paraan kung paano ang mga Anchor ay konektado sa isa't isa.
Walang malinaw na opinyon tungkol sa paggamit ng Nodes. Halimbawa, , na aktibong nagpo-promote ng paggamit ng Anchor Model sa Russia, ay naniniwala (hindi hindi makatwiran) na para sa hindi isang solong reference na libro ay maaaring sabihin nang may katiyakan na ito laging ay magiging static at single-level, kaya mas mahusay na agad na gumamit ng isang ganap na Anchor para sa lahat ng mga bagay.
Ang isa pang mahalagang pagkakaiba sa pagitan ng Data Vault at ng Anchor model ay ang availability mga katangian ng mga koneksyon:
Π Vault ng Data Ang mga link ay ang parehong ganap na mga bagay tulad ng Hubs, at maaaring magkaroon sariling katangian. Sa Modelo ng anchor Ang mga link ay ginagamit lamang upang ikonekta ang mga Anchor at hindi maaaring magkaroon ng kanilang sariling mga katangian. Ang pagkakaibang ito ay nagreresulta sa makabuluhang magkakaibang mga diskarte sa pagmomodelo katotohanan, na tatalakayin pa.
Imbakan ng katotohanan
Bago ito, pangunahing pinag-usapan namin ang tungkol sa pagmomodelo ng pagsukat. Ang mga katotohanan ay medyo hindi gaanong malinaw.
Π Vault ng Data isang tipikal na bagay para sa pag-iimbak ng mga katotohanan ay Link, kung saan ang mga satellite ay idinagdag ang mga tunay na tagapagpahiwatig.
Ang diskarte na ito ay tila intuitive. Nagbibigay ito ng madaling pag-access sa mga nasuri na tagapagpahiwatig at sa pangkalahatan ay katulad ng isang tradisyonal na talahanayan ng katotohanan (ang mga tagapagpahiwatig lamang ang nakaimbak hindi sa talahanayan mismo, ngunit sa talahanayan ng "kapitbahay"). Ngunit mayroon ding mga pitfalls: isa sa mga tipikal na pagbabago ng modelo - pagpapalawak ng fact key - ay nangangailangan pagdaragdag ng bagong foreign key sa Link. At ito, sa turn, ay "sinisira" ang modularity at posibleng maging sanhi ng pangangailangan para sa mga pagbabago sa iba pang mga bagay.
Π Modelo ng anchor Ang isang koneksyon ay hindi maaaring magkaroon ng sarili nitong mga katangian, kaya ang diskarte na ito ay hindi gagana - ganap na lahat ng mga katangian at mga tagapagpahiwatig ay dapat na naka-link sa isang tiyak na anchor. Ang konklusyon mula dito ay simple - Ang bawat katotohanan ay nangangailangan din ng sarili nitong angkla. Para sa ilan sa kung ano ang nakasanayan nating isipin bilang mga katotohanan, ito ay maaaring magmukhang natural - halimbawa, ang katotohanan ng isang pagbili ay maaaring ganap na mabawasan sa bagay na "order" o "resibo", pagbisita sa isang site sa isang session, atbp. Ngunit mayroon ding mga katotohanan kung saan hindi napakadaling makahanap ng isang natural na "bagay ng carrier" - halimbawa, ang mga labi ng mga kalakal sa mga bodega sa simula ng bawat araw.
Alinsunod dito, ang mga problema sa modularity kapag nagpapalawak ng isang fact key sa Anchor model ay hindi lumitaw (ito ay sapat na upang magdagdag lamang ng isang bagong Relasyon sa kaukulang Anchor), ngunit ang pagdidisenyo ng isang modelo upang ipakita ang mga katotohanan ay hindi gaanong malabo; "artipisyal" na Mga Anchor ay maaaring lumitaw na nagpapakita ng modelo ng business object sa hindi malinaw na paraan.
Paano nakakamit ang flexibility
Ang resultang konstruksiyon sa parehong mga kaso ay naglalaman ng makabuluhang mas maraming mga talahanayankaysa sa tradisyonal na pagsukat. Ngunit maaaring tumagal makabuluhang mas kaunting espasyo sa disk na may parehong hanay ng mga naka-bersyon na katangian gaya ng tradisyonal na dimensyon. Naturally, walang magic dito - lahat ito ay tungkol sa normalisasyon. Sa pamamagitan ng pamamahagi ng mga katangian sa mga Satellite (sa Data Vault) o mga indibidwal na talahanayan (Modelo ng Anchor), binabawasan namin (o ganap na inaalis) pagdoble ng mga halaga ng ilang mga katangian kapag binabago ang iba.
Para sa Vault ng Data ang mga panalo ay depende sa pamamahagi ng mga katangian sa mga Satellite, at para sa Modelo ng anchor β ay halos direktang proporsyonal sa average na bilang ng mga bersyon sa bawat object ng pagsukat.
Gayunpaman, ang pagtitipid sa espasyo ay isang mahalaga, ngunit hindi ang pangunahing, bentahe ng pag-iimbak ng mga katangian nang hiwalay. Kasama ng hiwalay na pag-iimbak ng mga relasyon, ginagawa ng diskarteng ito ang tindahan modular na disenyo. Nangangahulugan ito na ang pagdaragdag ng parehong mga indibidwal na katangian at buong bagong mga lugar ng paksa sa naturang modelo ay kamukha superstructure sa isang umiiral na hanay ng mga bagay nang hindi binabago ang mga ito. At ito mismo ang gumagawa ng inilarawan na mga pamamaraan na nababaluktot.
Ito rin ay kahawig ng paglipat mula sa paggawa ng piraso hanggang sa paggawa ng masa - kung sa tradisyonal na diskarte ang bawat talahanayan ng modelo ay natatangi at nangangailangan ng espesyal na pansin, kung gayon sa mga nababaluktot na pamamaraan ito ay isang hanay ng mga karaniwang "bahagi". Sa isang banda, mayroong higit pang mga talahanayan, at ang mga proseso ng paglo-load at pagkuha ng data ay dapat magmukhang mas kumplikado. Sa kabilang banda, nagiging sila tipikal. Ibig sabihin baka meron awtomatiko at hinihimok ng metadata. Ang tanong na "paano natin ito ilalagay?", ang sagot kung saan maaaring tumagal ng isang mahalagang bahagi ng gawain sa pagdidisenyo ng mga pagpapabuti, ngayon ay hindi katumbas ng halaga (pati na rin ang tanong tungkol sa epekto ng pagbabago ng modelo sa mga proseso ng pagtatrabaho ).
Hindi ito nangangahulugan na ang mga analyst ay hindi kailangan sa ganoong sistema - kailangan pa rin ng isang tao na magtrabaho sa hanay ng mga bagay na may mga katangian at malaman kung saan at kung paano i-load ang lahat ng ito. Ngunit ang dami ng trabaho, pati na rin ang posibilidad at gastos ng isang error, ay makabuluhang nabawasan. Parehong sa yugto ng pagsusuri at sa panahon ng pagbuo ng ETL, na sa isang makabuluhang bahagi ay maaaring mabawasan sa pag-edit ng metadata.
Madilim na gilid
Ang lahat ng nasa itaas ay gumagawa ng parehong mga diskarte na tunay na nababaluktot, teknolohikal na advanced at angkop para sa umuulit na pagpapabuti. Siyempre, mayroon ding "barrel sa pamahid", na sa palagay ko ay maaari mo nang hulaan.
Ang pagkabulok ng data, na sumasailalim sa modularity ng mga nababagong arkitektura, ay humahantong sa pagtaas ng bilang ng mga talahanayan at, nang naaayon, overhead upang sumali kapag nagsa-sample. Upang makuha lang ang lahat ng mga katangian ng isang dimensyon, sa isang klasikong tindahan ay sapat na ang isang piliin, ngunit ang isang flexible na arkitektura ay mangangailangan ng isang buong serye ng mga pagsali. Bukod dito, kung ang lahat ng mga pagsasama na ito para sa mga ulat ay maaaring maisulat nang maaga, ang mga analyst na sanay sa pagsulat ng SQL sa pamamagitan ng kamay ay dobleng magdurusa.
Mayroong ilang mga katotohanan na nagpapadali sa sitwasyong ito:
Kapag nagtatrabaho sa malalaking sukat, ang lahat ng mga katangian nito ay halos hindi ginagamit nang sabay-sabay. Nangangahulugan ito na maaaring may mas kaunting mga pagsali kaysa sa tila sa unang tingin sa modelo. Maaari ding isaalang-alang ng Data Vault ang inaasahang dalas ng pagbabahagi kapag naglalaan ng mga katangian sa mga satellite. Kasabay nito, ang mga Hub o Anchor mismo ay kinakailangan pangunahin para sa pagbuo at pagmamapa ng mga kahalili sa yugto ng paglo-load at bihirang ginagamit sa mga query (ito ay totoo lalo na para sa Mga Anchor).
Ang lahat ng pagsali ay sa pamamagitan ng susi. Bilang karagdagan, ang isang mas "naka-compress" na paraan ng pag-iimbak ng data ay binabawasan ang overhead ng pag-scan ng mga talahanayan kung saan ito kinakailangan (halimbawa, kapag nag-filter ayon sa halaga ng katangian). Ito ay maaaring humantong sa katotohanan na ang pagsa-sample mula sa isang normalized na database na may isang bungkos ng mga pagsali ay magiging mas mabilis kaysa sa pag-scan ng isang mabigat na dimensyon na may maraming mga bersyon sa bawat hilera.
Halimbawa, dito sa Ang artikulo ay naglalaman ng isang detalyadong paghahambing na pagsubok ng pagganap ng modelo ng Anchor na may isang sample mula sa isang talahanayan.
Marami ang nakasalalay sa makina. Maraming mga modernong platform ang may panloob na mekanismo ng pag-optimize ng pagsali. Halimbawa, ang MS SQL at Oracle ay maaaring "laktawan" ang mga pagsali sa mga talahanayan kung ang kanilang data ay hindi ginagamit kahit saan maliban sa iba pang mga pagsasama at hindi nakakaapekto sa panghuling pagpili (pag-aalis ng talahanayan/pagsali), at MPP Vertica , ay napatunayang isang mahusay na makina para sa Anchor Model, na binigyan ng ilang manu-manong pag-optimize ng query plan. Sa kabilang banda, ang pag-iimbak ng Anchor Model, halimbawa, sa Click House, na may limitadong suporta sa pagsali, ay hindi pa mukhang isang napakagandang ideya.
Bilang karagdagan, para sa parehong mga arkitektura mayroong mga espesyal na galaw, na ginagawang mas madali ang pag-access ng data (parehong mula sa pananaw sa pagganap ng query at para sa mga end user). Halimbawa, Point-In-Time na mga talahanayan sa Data Vault o mga espesyal na function ng talahanayan sa modelo ng Anchor.
Sa kabuuan
Ang pangunahing kakanyahan ng itinuturing na nababaluktot na mga arkitektura ay ang modularity ng kanilang "disenyo".
Ang ari-arian na ito ay nagbibigay-daan sa:
- Pagkatapos ng ilang paunang paghahanda na nauugnay sa pag-deploy ng metadata at pagsulat ng mga pangunahing ETL algorithm, mabilis na ibigay sa customer ang unang resulta sa anyo ng isang pares ng mga ulat na naglalaman ng data mula sa ilang mga pinagmumulan na bagay. Hindi kinakailangang ganap na pag-isipan (kahit sa pinakamataas na antas) ang buong modelo ng bagay.
- Ang isang modelo ng data ay maaaring magsimulang gumana (at maging kapaki-pakinabang) sa 2-3 bagay lamang, at pagkatapos unti-unting lumalaki (tungkol sa modelo ng Anchor na si Nikolai magandang paghahambing sa mycelium).
- Karamihan sa mga pagpapabuti, kabilang ang pagpapalawak ng lugar ng paksa at pagdaragdag ng mga bagong mapagkukunan hindi nakakaapekto sa umiiral nang functionality at hindi nagdudulot ng panganib na masira ang isang bagay na gumagana na.
- Salamat sa agnas sa mga karaniwang elemento, ang mga proseso ng ETL sa mga ganitong sistema ay mukhang pareho, ang kanilang pagsulat ay nagbibigay ng sarili sa algorithmization at, sa huli, automation.
Ang presyo ng flexibility na ito ay pagganap. Hindi ito nangangahulugan na imposibleng makamit ang katanggap-tanggap na pagganap sa mga naturang modelo. Mas madalas kaysa sa hindi, maaaring kailangan mo lang ng higit na pagsisikap at atensyon sa detalye upang makamit ang mga sukatan na gusto mo.
apps
Mga uri ng entity Vault ng Data
Higit pang impormasyon tungkol sa Data Vault:
Mga uri ng entity Modelo ng Anchor
Higit pang mga detalye tungkol sa Anchor Model:
Talahanayan ng buod na may mga karaniwang tampok at pagkakaiba ng mga isinasaalang-alang na diskarte:
Pinagmulan: www.habr.com