Kutengeneza kituo cha kuhifadhi ni kazi ndefu na nzito.
Mengi katika maisha ya mradi inategemea jinsi mfano wa kitu na muundo wa msingi hufikiriwa mwanzoni.
Mbinu inayokubalika kwa ujumla imekuwa na inabakia chaguzi mbalimbali za kuchanganya mpango wa nyota na fomu ya tatu ya kawaida. Kama sheria, kulingana na kanuni: data ya awali - 3NF, maonyesho - nyota. Mbinu hii, iliyojaribiwa kwa wakati na kuungwa mkono na kiasi kikubwa cha utafiti, ni jambo la kwanza (na wakati mwingine pekee) ambalo huja akilini mwa mtaalamu wa DWH mwenye ujuzi wakati anafikiria juu ya jinsi hazina ya uchambuzi inapaswa kuonekana.
Kwa upande mwingine, biashara kwa ujumla na mahitaji ya wateja hasa huwa na mabadiliko ya haraka, na data huelekea kukua "kwa kina" na "kwa upana". Na hapa ndipo hasara kuu ya nyota inaonekana - mdogo kubadilika.
Na ikiwa katika maisha yako tulivu na ya starehe kama msanidi wa DWH ghafla:
- kazi iliondoka "kufanya angalau kitu haraka, na kisha tutaona";
- mradi unaokua haraka ulionekana, na unganisho la vyanzo vipya na urekebishaji wa mtindo wa biashara angalau mara moja kwa wiki;
- mteja ametokea ambaye hajui jinsi mfumo unapaswa kuonekana na ni kazi gani unapaswa kufanya hatimaye, lakini yuko tayari kufanya majaribio na kuboresha mara kwa mara matokeo yanayohitajika huku akiikaribia mara kwa mara;
- Msimamizi wa mradi aliingia na habari njema: "Na sasa tuna wepesi!"
Au ikiwa una nia ya kujua jinsi nyingine unaweza kujenga vifaa vya kuhifadhi - karibu kwenye kata!
Je, "kubadilika" inamaanisha nini?
Kwanza, hebu tufafanue ni mali gani ambayo mfumo lazima uwe nayo ili kuitwa "kubadilika".
Kwa kando, inafaa kutaja kuwa mali iliyoelezewa inapaswa kuhusishwa haswa mfumo, si kwa mchakato maendeleo yake. Kwa hivyo, ikiwa ungetaka kusoma juu ya Agile kama mbinu ya ukuzaji, ni bora kusoma nakala zingine. Kwa mfano, pale pale, kwa Habre, kuna nyenzo nyingi za kuvutia (kama ΠΈ Na ).
Hii haimaanishi kuwa mchakato wa maendeleo na muundo wa ghala la data hauhusiani kabisa. Kwa jumla, inapaswa kuwa rahisi sana kukuza hazina ya Agile kwa usanifu wa kisasa. Walakini, katika mazoezi, mara nyingi kuna chaguzi na ukuzaji wa Agile wa DWH ya kawaida kulingana na Kimbal na DataVault - kulingana na Maporomoko ya maji, kuliko bahati mbaya ya kubadilika katika aina zake mbili kwenye mradi mmoja.
Kwa hivyo, uhifadhi rahisi unapaswa kuwa na uwezo gani? Kuna pointi tatu hapa:
- Utoaji wa mapema na ubadilishaji wa haraka - hii ina maana kwamba matokeo ya biashara ya kwanza (kwa mfano, ripoti za kwanza za kazi) inapaswa kupatikana mapema iwezekanavyo, yaani, hata kabla ya mfumo mzima haujaundwa na kutekelezwa kikamilifu. Zaidi ya hayo, kila marekebisho yanayofuata yanapaswa kuchukua muda mfupi iwezekanavyo.
- Uboreshaji wa kurudia - hii inamaanisha kuwa kila uboreshaji unaofuata haupaswi kuathiri utendakazi ambao tayari unafanya kazi. Ni wakati huu ambao mara nyingi huwa ndoto kubwa zaidi kwenye miradi mikubwa - mapema au baadaye, vitu vya mtu binafsi huanza kupata viunganisho vingi hivi kwamba inakuwa rahisi kurudia kabisa mantiki katika nakala iliyo karibu kuliko kuongeza shamba kwenye meza iliyopo. Na ikiwa unashangaa kuwa kuchambua athari za marekebisho kwenye vitu vilivyopo kunaweza kuchukua muda zaidi kuliko marekebisho yenyewe, uwezekano mkubwa bado haujafanya kazi na maghala makubwa ya data katika benki au mawasiliano ya simu.
- Kubadilika kila wakati ili kubadilisha mahitaji ya biashara - muundo wa jumla wa kitu unapaswa kutengenezwa sio tu kwa kuzingatia upanuzi unaowezekana, lakini kwa matarajio kwamba mwelekeo wa upanuzi huu unaofuata hauwezi hata kuota katika hatua ya kubuni.
Na ndiyo, kufikia mahitaji haya yote katika mfumo mmoja inawezekana (bila shaka, katika hali fulani na kwa kutoridhishwa).
Hapo chini nitazingatia mbinu mbili maarufu za muundo wa ghala za data - Mfano wa nanga ΠΈ Hifadhi ya data. Imeachwa nje ya mabano ni mbinu bora kama, kwa mfano, EAV, 6NF (katika hali yake safi) na kila kitu kinachohusiana na suluhisho za NoSQL - sio kwa sababu ni mbaya zaidi, na hata kwa sababu katika kesi hii kifungu kinaweza kutishia kupata. kiasi cha disser wastani. Ni kwamba haya yote yanahusiana na suluhisho za darasa tofauti kidogo - ama kwa mbinu ambazo unaweza kutumia katika hali maalum, bila kujali usanifu wa jumla wa mradi wako (kama EAV), au dhana zingine za uhifadhi wa habari ulimwenguni (kama vile hifadhidata za grafu. na chaguzi zingine za NoSQL).
Matatizo ya mbinu ya "classical" na ufumbuzi wao katika mbinu rahisi
Kwa mtazamo wa "classical" ninamaanisha nyota nzuri ya zamani (bila kujali utekelezaji maalum wa matabaka ya msingi, naomba wafuasi wa Kimball, Inmon na CDM wanisamehe).
1. Kadinali kali ya viunganisho
Mfano huu unategemea mgawanyiko wazi wa data ndani Dimension ΠΈ ukweli. Na hii, damn it, ni mantiki - baada ya yote, uchambuzi wa data katika idadi kubwa ya kesi huja chini ya uchambuzi wa baadhi ya viashiria namba (ukweli) katika sehemu fulani (vipimo).
Katika kesi hii, uhusiano kati ya vitu huanzishwa kwa namna ya mahusiano kati ya meza kwa kutumia ufunguo wa kigeni. Hii inaonekana ya asili kabisa, lakini mara moja husababisha kizuizi cha kwanza cha kubadilika - ufafanuzi mkali wa kardinali ya viunganisho.
Hii ina maana kwamba katika hatua ya usanifu wa jedwali, lazima uamue kwa usahihi kwa kila jozi ya vitu vinavyohusiana ikiwa vinaweza kuhusisha vingi kwa vingi, au 1 hadi vingi tu, na "katika mwelekeo gani". Hii huamua moja kwa moja ni jedwali gani litakuwa na ufunguo msingi na lipi litakuwa na ufunguo wa kigeni. Kubadilisha mtazamo huu wakati mahitaji mapya yanapokelewa kuna uwezekano mkubwa kusababisha urekebishaji wa msingi.
Kwa mfano, wakati wa kubuni kitu cha "risiti ya pesa", wewe, ukitegemea viapo vya idara ya mauzo, uliweka uwezekano wa kuchukua hatua. kukuza moja kwa nafasi kadhaa za hundi (lakini si kinyume chake):
Na baada ya muda, wenzake walianzisha mkakati mpya wa uuzaji ambao wanaweza kuchukua hatua kwa msimamo sawa matangazo kadhaa kwa wakati mmoja. Na sasa unahitaji kurekebisha meza kwa kutenganisha uhusiano katika kitu tofauti.
(Vipengee vyote vinavyotokana ambavyo hundi ya ofa imeunganishwa sasa pia vinahitaji kuboreshwa).
Uhusiano katika Vault ya Data na Mfano wa Anchor
Kuepuka hali hii iligeuka kuwa rahisi sana: sio lazima uamini idara ya uuzaji kufanya hivi. miunganisho yote hapo awali huhifadhiwa kwenye meza tofauti na kuichakata kama nyingi hadi nyingi.
Mbinu hii ilipendekezwa Dan Linstedt kama sehemu ya dhana Hifadhi ya data na kuungwa mkono kikamilifu Lars RΓΆnnbΓ€ck Π² Mfano wa Anchor.
Kama matokeo, tunapata kipengele cha kwanza cha kipekee cha mbinu rahisi:
Mahusiano kati ya vitu hayahifadhiwa katika sifa za vyombo vya wazazi, lakini ni aina tofauti ya kitu.
Π Hifadhi ya data meza za kuunganisha vile zinaitwa Link, na ndani Mfano wa Anchor - tie. Kwa mtazamo wa kwanza, zinafanana sana, ingawa tofauti zao haziishii na jina (ambalo litajadiliwa hapa chini). Katika usanifu wote wawili, meza za kiungo zinaweza kuunganisha idadi yoyote ya vyombo (sio lazima 2).
Upungufu huu, kwa mtazamo wa kwanza, hutoa kubadilika muhimu kwa marekebisho. Muundo kama huo unakuwa mvumilivu sio tu kwa mabadiliko katika kardinali ya viungo vilivyopo, lakini pia kwa kuongezwa kwa mpya - ikiwa sasa nafasi ya hundi pia ina kiunga cha cashier aliyeifungua, kuonekana kwa kiunga kama hicho kutakuwa tu. nyongeza juu ya jedwali zilizopo bila kuathiri vitu na michakato yoyote iliyopo.
2. Data rudufu
Tatizo la pili kutatuliwa na usanifu rahisi ni chini ya dhahiri na ni asili katika nafasi ya kwanza. Vipimo vya aina ya SCD2 (inabadilisha polepole vipimo vya aina ya pili), ingawa sio wao tu.
Katika ghala la kawaida, kipimo kwa kawaida ni jedwali ambalo lina ufunguo mbadala (kama PK) na seti ya funguo za biashara na sifa katika safu wima tofauti.
Ikiwa kipimo kinatumia uchapishaji, mipaka ya uhalali wa toleo huongezwa kwa seti ya kawaida ya sehemu, na matoleo kadhaa huonekana kwenye hazina kwa safu mlalo moja katika chanzo (moja kwa kila badiliko la sifa zilizotolewa).
Ikiwa kipimo kina angalau sifa moja inayobadilishwa mara kwa mara, idadi ya matoleo ya kipimo kama hicho itakuwa ya kuvutia (hata kama sifa zilizobaki hazijatolewa au hazibadiliki kamwe), na ikiwa kuna sifa kadhaa kama hizo, idadi ya matoleo inaweza. kukua kwa kasi kutoka kwa idadi yao. Kipimo hiki kinaweza kuchukua nafasi kubwa ya diski, ingawa data nyingi inayohifadhi ni nakala za thamani za sifa zisizoweza kubadilika kutoka safu mlalo nyingine.
Wakati huo huo, pia hutumiwa mara nyingi sana kupunguza hali ya kawaida - baadhi ya sifa huhifadhiwa kimakusudi kama thamani, na si kama kiungo cha kitabu cha marejeleo au kipimo kingine. Mbinu hii inaharakisha ufikiaji wa data, kupunguza idadi ya viungio wakati wa kufikia kipimo.
Kwa kawaida hii inasababisha habari sawa huhifadhiwa wakati huo huo katika maeneo kadhaa. Kwa mfano, taarifa kuhusu eneo la makazi na kategoria ya mteja inaweza kuhifadhiwa kwa wakati mmoja katika vipimo vya "Mteja" na ukweli wa "Ununuzi", "Uwasilishaji" na "Simu za Kituo cha Simu", na vile vile katika "Mteja - Meneja wa Mteja." β jedwali la kiungo.
Kwa ujumla, ilivyoelezwa hapo juu inatumika kwa vipimo vya kawaida (zisizo za toleo), lakini katika matoleo yanaweza kuwa na kiwango tofauti: kuonekana kwa toleo jipya la kitu (hasa katika retrospect) husababisha si tu kwa sasisho la yote yanayohusiana. meza, lakini kwa kuonekana kwa kasi ya matoleo mapya ya vitu vinavyohusiana - wakati Jedwali 1 linatumiwa kujenga Jedwali la 2, na Jedwali la 2 linatumiwa kujenga Jedwali la 3, nk. Hata kama hakuna sifa moja ya Jedwali 1 inayohusika katika ujenzi wa Jedwali 3 (na sifa zingine za Jedwali 2 zilizopatikana kutoka kwa vyanzo vingine zinahusika), utayarishaji wa ujenzi huu utaongoza kwa ziada ya ziada, na kwa kiwango cha juu hadi ziada. matoleo katika Jedwali 3. ambayo haina uhusiano wowote nayo kabisa, na zaidi chini ya mlolongo.
3. Utata usio na mstari wa rework
Wakati huo huo, kila mbele ya duka mpya iliyojengwa kwa msingi wa nyingine huongeza idadi ya mahali ambapo data inaweza "kutofautiana" wakati mabadiliko yanafanywa kwa ETL. Hii, kwa upande wake, husababisha kuongezeka kwa utata (na muda) wa kila marekebisho yanayofuata.
Ikiwa hapo juu inaelezea mifumo iliyo na michakato ya ETL iliyobadilishwa mara chache, unaweza kuishi katika dhana kama hiyo - unahitaji tu kuhakikisha kuwa marekebisho mapya yanafanywa kwa usahihi kwa vitu vyote vinavyohusiana. Ikiwa marekebisho hutokea mara kwa mara, uwezekano wa "kukosa" miunganisho kadhaa kwa bahati mbaya huongezeka kwa kiasi kikubwa.
Ikiwa, kwa kuongeza, tutazingatia kwamba ETL "iliyobadilishwa" ni ngumu zaidi kuliko "isiyo ya toleo", inakuwa ngumu sana kuzuia makosa wakati wa kusasisha kituo hiki kizima mara kwa mara.
Kuhifadhi vitu na sifa katika Vault ya Data na Mfano wa Anchor
Mbinu iliyopendekezwa na waandishi wa usanifu rahisi inaweza kutengenezwa kama ifuatavyo:
Inahitajika kutenganisha mabadiliko kutoka kwa yale ambayo yanabaki sawa. Hiyo ni, funguo za kuhifadhi kando na sifa.
Hata hivyo, mtu haipaswi kuchanganya haijatolewa sifa na bila kubadilika: ya kwanza haihifadhi historia ya mabadiliko yake, lakini inaweza kubadilika (kwa mfano, wakati wa kusahihisha kosa la kuingiza au kupokea data mpya); ya pili haibadiliki kamwe.
Maoni yanatofautiana juu ya kile ambacho kinaweza kuzingatiwa kuwa kisichobadilika katika Vault ya Data na Modeli ya Nanga.
Kutoka kwa mtazamo wa usanifu Hifadhi ya data, inaweza kuchukuliwa kuwa haijabadilika seti nzima ya funguo - asili (TIN ya shirika, msimbo wa bidhaa katika mfumo wa chanzo, nk) na surrogate. Katika kesi hii, sifa zilizobaki zinaweza kugawanywa katika vikundi kulingana na chanzo na / au mzunguko wa mabadiliko na Dumisha meza tofauti kwa kila kikundi na seti huru ya matoleo.
Katika dhana Mfano wa Anchor kuchukuliwa bila kubadilika ufunguo wa surrogate tu kiini. Kila kitu kingine (ikiwa ni pamoja na funguo za asili) ni kesi maalum ya sifa zake. Ambapo sifa zote ni huru kutoka kwa kila mmoja kwa chaguo-msingi, kwa hivyo kwa kila sifa a meza tofauti.
Π Hifadhi ya data meza zilizo na funguo za chombo zinaitwa Hubami. Hubs daima huwa na seti isiyobadilika ya sehemu:
- Funguo za Kiumbe Asilia
- Ufunguo wa mbadala
- Unganisha kwa chanzo
- Rekodi wakati wa kuongeza
Machapisho katika Hubs usibadilike na hauna matoleo. Kwa nje, vitovu vinafanana sana na jedwali za aina ya ramani ya kitambulisho zinazotumiwa katika baadhi ya mifumo kutengeneza waigizaji, hata hivyo, inashauriwa kutumia heshi kutoka kwa seti ya funguo za biashara kama mbadala katika Data Vault. Njia hii hurahisisha upakiaji uhusiano na sifa kutoka kwa vyanzo (hakuna haja ya kujiunga na kitovu ili kupata mbadala, tu kuhesabu heshi ya ufunguo wa asili), lakini inaweza kusababisha shida zingine (zinazohusiana, kwa mfano, na migongano, kesi na isiyoweza kuchapishwa. herufi katika funguo za kamba, n.k. .p.), kwa hivyo haikubaliwi kwa ujumla.
Sifa nyingine zote za chombo zimehifadhiwa katika meza maalum zinazoitwa Satelaiti. Kitovu kimoja kinaweza kuwa na satelaiti kadhaa zinazohifadhi seti tofauti za sifa.
Usambazaji wa sifa kati ya satelaiti hutokea kulingana na kanuni mabadiliko ya pamoja - katika satelaiti moja sifa zisizo za toleo zinaweza kuhifadhiwa (kwa mfano, tarehe ya kuzaliwa na SNILS kwa mtu binafsi), kwa mwingine - mara chache kubadilisha matoleo (kwa mfano, jina la mwisho na nambari ya pasipoti), katika tatu - kubadilisha mara kwa mara. (kwa mfano, anwani ya utoaji, kategoria, tarehe ya agizo la mwisho, nk). Katika kesi hii, toleo hufanywa kwa kiwango cha satelaiti za kibinafsi, na sio chombo kwa ujumla, kwa hivyo inashauriwa kusambaza sifa ili makutano ya matoleo ndani ya satelaiti moja iwe ndogo (ambayo inapunguza idadi ya matoleo yaliyohifadhiwa. )
Pia, ili kuboresha mchakato wa upakiaji wa data, sifa zinazopatikana kutoka kwa vyanzo mbalimbali mara nyingi hujumuishwa kwenye satelaiti za kibinafsi.
Satelaiti huwasiliana na Hub kupitia ufunguo wa kigeni (ambayo inalingana na kardinali 1 hadi nyingi). Hii inamaanisha kuwa thamani nyingi za sifa (kwa mfano, nambari nyingi za simu za mteja mmoja) zinaauniwa na usanifu huu "chaguo-msingi".
Π Mfano wa Anchor meza zinazohifadhi funguo zinaitwa Nanga. Na wanashika:
- Funguo za mbadala pekee
- Unganisha kwa chanzo
- Rekodi wakati wa kuongeza
Vifunguo vya asili kutoka kwa mtazamo wa Mfano wa Anchor huzingatiwa sifa za kawaida. Chaguo hili linaweza kuonekana kuwa gumu zaidi kuelewa, lakini linatoa wigo zaidi wa kutambua kitu.
Kwa mfano, ikiwa data kuhusu huluki moja inaweza kutoka kwa mifumo tofauti, ambayo kila moja hutumia ufunguo wake wa asili. Katika Vault ya Data, hii inaweza kusababisha miundo migumu ya vitovu kadhaa (moja kwa kila chanzo + toleo kuu la kuunganisha), wakati katika mfano wa Anchor, ufunguo wa asili wa kila chanzo huanguka katika sifa yake mwenyewe na inaweza kutumika wakati wa kupakia bila kujitegemea. wengine wote.
Lakini pia kuna jambo moja la hila hapa: ikiwa sifa kutoka kwa mifumo tofauti zimejumuishwa katika chombo kimoja, kuna uwezekano mkubwa kuwa kuna zingine. sheria za "gluing", ambayo mfumo lazima uelewe kuwa rekodi kutoka vyanzo tofauti zinalingana na mfano mmoja wa huluki.
Π Hifadhi ya data sheria hizi zina uwezekano mkubwa wa kuamua malezi "kitovu mbadala" cha chombo kikuu na si kwa njia yoyote ile kuathiri Hubs zinazohifadhi funguo asilia na sifa zao asili. Ikiwa wakati fulani sheria za kuunganisha zinabadilika (au sifa ambazo zinafanywa zinasasishwa), itatosha kurekebisha vitovu vya mbadala.
Π Mfano wa nanga chombo kama hicho kina uwezekano mkubwa wa kuhifadhiwa ndani nanga pekee. Hii ina maana kwamba sifa zote, bila kujali zinatoka kwa chanzo gani, zitafungwa kwa mbadala mmoja. Kutenganisha rekodi zilizounganishwa kimakosa na, kwa ujumla, ufuatiliaji wa umuhimu wa kuunganishwa katika mfumo kama huo inaweza kuwa ngumu zaidi, haswa ikiwa sheria ni ngumu sana na zinabadilika mara kwa mara, na sifa hiyo hiyo inaweza kupatikana kutoka kwa vyanzo tofauti (ingawa ni hakika. inawezekana, kwa kuwa kila toleo la sifa huhifadhi kiunga cha chanzo chake).
Kwa hali yoyote, ikiwa mfumo wako unapaswa kutekeleza utendakazi kupunguzwa, kuunganisha rekodi na vipengele vingine vya MDM, inafaa kulipa kipaumbele maalum kwa vipengele vya kuhifadhi funguo za asili katika mbinu za agile. Kuna uwezekano kwamba muundo mkubwa zaidi wa Data Vault utakuwa salama ghafla katika suala la makosa ya kuunganisha.
Mfano wa nanga pia hutoa aina ya ziada ya kitu kinachoitwa Fundo kimsingi ni maalum aina iliyoharibika ya nanga, ambayo inaweza kuwa na sifa moja tu. Nodi zinatakiwa kutumika kuhifadhi saraka tambarare (kwa mfano, jinsia, hali ya ndoa, kitengo cha huduma kwa wateja, n.k.). Tofauti na Nanga, Fundo haina majedwali ya sifa zinazohusiana, na sifa yake pekee (jina) huhifadhiwa kila wakati kwenye jedwali moja na ufunguo. Nodes zimeunganishwa na Anchors na meza za kufunga (Tie) kwa njia sawa na Anchors zimeunganishwa kwa kila mmoja.
Hakuna maoni wazi kuhusu matumizi ya Nodes. Kwa mfano, , ambaye anahimiza kikamilifu matumizi ya Mfano wa Anchor nchini Urusi, anaamini (sio bila sababu) kwamba hakuna kitabu kimoja cha kumbukumbu kinachoweza kutajwa kwa uhakika kwamba daima itakuwa tuli na ya kiwango kimoja, kwa hivyo ni bora kutumia Anchor iliyojaa mara moja kwa vitu vyote.
Tofauti nyingine muhimu kati ya Vault ya Data na mfano wa Anchor ni upatikanaji sifa za uhusiano:
Π Hifadhi ya data Viungo ni vitu vilivyojaa sawa na Hubs, na vinaweza kuwa sifa mwenyewe. Katika Mfano wa nanga Viungo hutumiwa tu kuunganisha Anchors na hawawezi kuwa na sifa zao wenyewe. Tofauti hii husababisha njia tofauti za uundaji ukweli, ambayo itajadiliwa zaidi.
Hifadhi ya ukweli
Kabla ya hili, tulizungumza hasa juu ya modeli ya kipimo. Ukweli uko wazi kidogo.
Π Hifadhi ya data kitu cha kawaida cha kuhifadhi ukweli ni Kiungo, ambao viashiria vya kweli vinaongezwa kwenye satelaiti.
Mbinu hii inaonekana intuitive. Inatoa upatikanaji rahisi kwa viashiria vilivyochambuliwa na kwa ujumla ni sawa na meza ya ukweli wa jadi (viashiria tu vinahifadhiwa si kwenye meza yenyewe, lakini katika meza ya "jirani"). Lakini pia kuna mitego: moja ya marekebisho ya kawaida ya mfano - upanuzi wa ufunguo wa ukweli - unahitajika. kuongeza ufunguo mpya wa kigeni kwenye Kiungo. Na hii, kwa upande wake, "inavunja" moduli na inaweza kusababisha hitaji la marekebisho kwa vitu vingine.
Π Mfano wa nanga Uunganisho hauwezi kuwa na sifa zake, kwa hivyo mbinu hii haitafanya kazi - sifa zote na viashiria lazima viunganishwe na nanga moja maalum. Hitimisho kutoka kwa hili ni rahisi - Kila ukweli pia unahitaji nanga yake. Kwa baadhi ya yale ambayo tumezoea kuyaona kama ukweli, hii inaweza kuonekana asili - kwa mfano, ukweli wa ununuzi unaweza kupunguzwa kikamilifu kwa kitu "agizo" au "risiti", kutembelea tovuti kwenye kikao, nk. Lakini pia kuna ukweli ambao sio rahisi kupata "kitu cha kubeba" asili - kwa mfano, mabaki ya bidhaa kwenye ghala mwanzoni mwa kila siku.
Ipasavyo, shida za urekebishaji wakati wa kupanua ufunguo wa ukweli katika mfano wa Anchor hazitokei (inatosha tu kuongeza Uhusiano mpya kwa Anchor inayolingana), lakini kubuni kielelezo cha kuonyesha ukweli sio ngumu sana; Nanga "bandia" zinaweza kuonekana. inayoonyesha muundo wa kitu cha biashara kwa njia isiyo wazi.
Jinsi kubadilika kunapatikana
ujenzi kusababisha katika kesi zote mbili ina kwa kiasi kikubwa meza zaidikuliko kipimo cha jadi. Lakini inaweza kuchukua kwa kiasi kikubwa nafasi ndogo ya diski na seti sawa ya sifa zilizotolewa kama kipimo cha jadi. Kwa kawaida, hakuna uchawi hapa - yote ni juu ya kuhalalisha. Kwa kusambaza sifa kwenye Setilaiti (katika Hifadhi ya Data) au jedwali mahususi (Mfano wa Nanga), tunapunguza (au kuondoa kabisa) kurudia kwa maadili ya sifa fulani wakati wa kubadilisha zingine.
Kwa Hifadhi ya data ushindi utategemea usambazaji wa sifa kati ya Satelaiti, na kwa Mfano wa nanga - inakaribia sawia moja kwa moja na wastani wa idadi ya matoleo kwa kila kitu cha kipimo.
Hata hivyo, uhifadhi wa nafasi ni muhimu, lakini sio kuu, faida ya kuhifadhi sifa tofauti. Pamoja na uhifadhi tofauti wa mahusiano, mbinu hii hufanya duka muundo wa msimu. Hii inamaanisha kuwa kuongeza sifa za mtu binafsi na maeneo mapya ya somo katika modeli kama hii inaonekana kama muundo mkuu juu ya seti iliyopo ya vitu bila kuzibadilisha. Na hii ndiyo hasa hufanya mbinu zilizoelezwa kubadilika.
Hii pia inafanana na mpito kutoka kwa uzalishaji wa kipande hadi uzalishaji wa wingi - ikiwa kwa njia ya jadi kila jedwali la mfano ni la kipekee na linahitaji umakini maalum, basi katika mbinu rahisi tayari ni seti ya "sehemu" za kawaida. Kwa upande mmoja, kuna meza zaidi, na taratibu za kupakia na kurejesha data zinapaswa kuonekana kuwa ngumu zaidi. Kwa upande mwingine, wanakuwa kawaida. Ambayo ina maana kunaweza kuwa kiotomatiki na metadata inayoendeshwa. Swali "tutawekaje?", Jibu ambalo linaweza kuchukua sehemu kubwa ya kazi ya kubuni maboresho, sasa haifai (pamoja na swali juu ya athari za kubadilisha mtindo kwenye michakato ya kufanya kazi." )
Hii haimaanishi kuwa wachambuzi hawahitajiki katika mfumo kama huo kabisa - mtu bado anapaswa kufanya kazi kupitia seti ya vitu vilivyo na sifa na kujua wapi na jinsi ya kupakia yote. Lakini kiasi cha kazi, pamoja na uwezekano na gharama ya kosa, hupunguzwa sana. Wote katika hatua ya uchambuzi na wakati wa maendeleo ya ETL, ambayo kwa sehemu kubwa inaweza kupunguzwa kwa metadata ya kuhariri.
Nuru ya giza
Yote yaliyo hapo juu hufanya mbinu zote mbili ziwe rahisi kubadilika, za kiteknolojia na zinafaa kwa uboreshaji unaorudiwa. Kwa kweli, pia kuna "pipa kwenye marashi", ambayo nadhani unaweza tayari kukisia.
Mtengano wa data, ambayo ni msingi wa usanifu wa usanifu rahisi, husababisha kuongezeka kwa idadi ya meza na, ipasavyo, juu kujiunga wakati wa kuchukua sampuli. Ili tu kupata sifa zote za mwelekeo, katika duka la classic moja kuchagua ni ya kutosha, lakini usanifu rahisi itahitaji mfululizo mzima wa kujiunga. Zaidi ya hayo, ikiwa viungo hivi vyote vya ripoti vinaweza kuandikwa mapema, basi wachambuzi ambao wamezoea kuandika SQL kwa mkono watateseka mara mbili.
Kuna mambo kadhaa ambayo hurahisisha hali hii:
Wakati wa kufanya kazi na vipimo vikubwa, sifa zake zote karibu hazitumiwi wakati huo huo. Hii inamaanisha kuwa kunaweza kuwa na viunga vichache kuliko inavyoonekana mwanzoni mwa mfano. Data Vault pia inaweza kuzingatia mzunguko unaotarajiwa wa kushiriki wakati wa kugawa sifa kwa satelaiti. Wakati huo huo, Hubs au Anchors wenyewe zinahitajika kwa ajili ya kuzalisha na kuchora waigizaji katika hatua ya upakiaji na hutumiwa mara chache katika maswali (hii ni kweli hasa kwa Anchors).
Viunga vyote ni kwa ufunguo. Kwa kuongeza, njia "iliyobanwa" zaidi ya kuhifadhi data inapunguza sehemu ya juu ya meza za skanning ambapo inahitajika (kwa mfano, wakati wa kuchuja kwa thamani ya sifa). Hii inaweza kusababisha ukweli kwamba sampuli kutoka kwa hifadhidata iliyorekebishwa na rundo la viungio itakuwa haraka zaidi kuliko kuchanganua kipimo kimoja kizito na matoleo mengi kwa kila safu.
Kwa mfano, hapa ndani Nakala hiyo ina jaribio la kina la kulinganisha la utendaji wa mfano wa Anchor na sampuli kutoka kwa jedwali moja.
Mengi inategemea injini. Majukwaa mengi ya kisasa yana njia za uboreshaji wa kujiunga kwa ndani. Kwa mfano, MS SQL na Oracle zinaweza "kuruka" viungio kwenye jedwali ikiwa data yao haitumiki popote isipokuwa viungio vingine na haiathiri uteuzi wa mwisho (kuondoa jedwali/kujiunga), na MPP Vertica. , imethibitisha kuwa injini bora kwa Mfano wa Anchor, ikizingatiwa uboreshaji wa mwongozo wa mpango wa hoja. Kwa upande mwingine, kuhifadhi Mfano wa Anchor, kwa mfano, kwenye Bofya House, ambayo ina usaidizi mdogo wa kujiunga, bado haionekani kuwa wazo nzuri sana.
Kwa kuongeza, kwa usanifu wote kuna hatua maalum, kurahisisha ufikiaji wa data (kutoka kwa mtazamo wa utendaji wa hoja na kwa watumiaji wa mwisho). Kwa mfano, Majedwali ya Wakati-wakati katika Vault ya Data au kazi maalum za meza katika mfano wa Anchor.
Katika jumla ya
Kiini kikuu cha usanifu unaozingatiwa kuwa rahisi ni modularity ya "muundo" wao.
Ni mali hii ambayo inaruhusu:
- Baada ya matayarisho ya awali yanayohusiana na upelekaji wa metadata na kuandika algoriti za msingi za ETL, haraka kutoa mteja na matokeo ya kwanza katika mfumo wa ripoti kadhaa zilizo na data kutoka kwa vyanzo vichache tu. Sio lazima kufikiria kabisa (hata kwa kiwango cha juu) mfano wa kitu kizima.
- Mfano wa data unaweza kuanza kufanya kazi (na kuwa muhimu) na vitu 2-3 tu, na kisha kukua hatua kwa hatua (kuhusu mfano wa Anchor Nikolai kulinganisha nzuri na mycelium).
- Maboresho mengi, ikiwa ni pamoja na kupanua eneo la somo na kuongeza vyanzo vipya haiathiri utendakazi uliopo na haileti hatari ya kuvunja kitu ambacho tayari kinafanya kazi.
- Shukrani kwa mtengano katika vipengele vya kawaida, michakato ya ETL katika mifumo kama hiyo inaonekana sawa, uandishi wao unajitolea kwa algorithmization na, hatimaye, otomatiki.
Bei ya kubadilika hii ni utendaji. Hii haina maana kwamba haiwezekani kufikia utendaji unaokubalika kwenye mifano hiyo. Mara nyingi zaidi, unaweza kuhitaji juhudi zaidi na umakini kwa undani ili kufikia vipimo unavyotaka.
Programu
Aina za huluki Hifadhi ya data
Habari zaidi kuhusu Vault ya data:
Aina za huluki Mfano wa Anchor
Maelezo zaidi kuhusu Anchor Model:
Jedwali la muhtasari na sifa za kawaida na tofauti za mbinu zinazozingatiwa:
Chanzo: mapenzi.com