Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Krātuves izveide ir ilgs un nopietns darbs.

Daudz kas projekta dzīvē ir atkarīgs no tā, cik labi sākumā ir pārdomāts objekta modelis un bāzes struktūra.

Vispārpieņemtā pieeja ir bijusi un paliek dažādas iespējas, kā apvienot zvaigžņu shēmu ar treÅ”o normālo formu. Parasti pēc principa: sākotnējie dati - 3NF, vitrÄ«nas - zvaigzne. Å Ä« pieeja, kas ir pārbaudÄ«ta laika gaitā un ir atbalstÄ«ta ar lielu pētÄ«jumu apjomu, ir pirmā (un dažreiz arÄ« vienÄ«gā) lieta, kas pieredzējuÅ”am DWH speciālistam ienāk prātā, domājot par to, kādai vajadzētu izskatÄ«ties analÄ«tikas krātuvei.

No otras puses, bizness kopumā un jo Ä«paÅ”i klientu prasÄ«bas mēdz ātri mainÄ«ties, un datiem ir tendence augt gan ā€œdziļumāā€, gan ā€œplaŔā mērogāā€. Un Å”eit parādās galvenais zvaigznes trÅ«kums - ierobežots elastÄ«ba.

Un, ja savā klusajā un mājÄ«gajā DWH izstrādātāja dzÄ«vē pēkŔņi:

  • radās uzdevums ā€œvismaz kaut ko ātri izdarÄ«t, un tad jau redzēsā€;
  • parādÄ«jās strauji attÄ«stoÅ”s projekts, ar jaunu avotu pieslēgÅ”anu un biznesa modeļa pārstrādi vismaz reizi nedēļā;
  • ir parādÄ«jies klients, kuram nav ne jausmas, kādai sistēmai jāizskatās un kādas funkcijas tai galu galā jāveic, bet ir gatavs eksperimentēt un konsekventi pilnveidot vēlamo rezultātu, konsekventi tam tuvojoties;
  • Projekta vadÄ«tājs ieradās ar labām ziņām: "Un tagad mums ir veikls!"

Vai arÄ«, ja jÅ«s vienkārÅ”i vēlaties uzzināt, kā vēl varat izveidot noliktavas - laipni lÅ«dzam!

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Ko nozÄ«mē ā€œelastÄ«baā€?

Pirmkārt, definēsim, kādām Ä«paŔībām ir jābÅ«t sistēmai, lai to varētu saukt par ā€œelastÄ«guā€.

AtseviŔķi ir vērts pieminēt, ka aprakstÄ«tajām Ä«paŔībām vajadzētu Ä«paÅ”i attiekties uz sistēma, nevis process tās attÄ«stÄ«bu. Tāpēc, ja vēlies lasÄ«t par Agile kā izstrādes metodiku, labāk palasi citus rakstus. Piemēram, tieÅ”i tur, HabrĆ©, ir daudz interesantu materiālu (piemēram, pārskats Šø praktiskiUn problemātiska).

Tas nenozīmē, ka izstrādes process un datu noliktavas struktūra ir pilnīgi nesaistīti. Kopumā elastīgai arhitektūrai vajadzētu būt ievērojami vieglāk izstrādāt Agile repozitoriju. Tomēr praksē biežāk tiek piedāvātas klasiskā DWH Agile izstrāde saskaņā ar Kimbal un DataVault - saskaņā ar Waterfall, nevis laimīgas elastības sakritības divos tā veidos vienā projektā.

Tātad, kādām iespējām vajadzētu bÅ«t elastÄ«gai uzglabāŔanai? Å eit ir trÄ«s punkti:

  1. AgrÄ«na piegāde un ātra piegāde - tas nozÄ«mē, ka ideālā gadÄ«jumā pirmais biznesa rezultāts (piemēram, pirmie darba ziņojumi) ir jāiegÅ«st pēc iespējas agrāk, tas ir, vēl pirms visa sistēma ir pilnÄ«bā izstrādāta un ieviesta. Turklāt katrai nākamajai pārskatÄ«Å”anai vajadzētu aizņemt pēc iespējas mazāk laika.
  2. IteratÄ«vs precizējums - tas nozÄ«mē, ka katram nākamajam uzlabojumam ideālā gadÄ«jumā nevajadzētu ietekmēt funkcionalitāti, kas jau darbojas. TieÅ”i Å”is brÄ«dis nereti kļūst par lielāko murgu lielos projektos ā€“ agri vai vēlu atseviŔķi objekti sāk iegÅ«t tik daudz savienojumu, ka kļūst vieglāk pilnÄ«bā atkārtot loÄ£iku blakus esoÅ”ajā kopijā, nevis pievienot lauku esoÅ”ai tabulai. Un, ja esat pārsteigts, ka esoÅ”o objektu uzlabojumu ietekmes analÄ«ze var aizņemt vairāk laika nekā paÅ”i uzlabojumi, jÅ«s, visticamāk, vēl neesat strādājis ar lielām datu noliktavām banku vai telekomunikāciju jomā.
  3. PastāvÄ«gi pielāgojoties mainÄ«gajām biznesa prasÄ«bām - kopējā objekta struktÅ«ra jāveido, ne tikai ņemot vērā iespējamo paplaÅ”ināŔanu, bet ar cerÄ«bām, ka par Ŕīs nākamās paplaÅ”ināŔanas virzienu projektÄ“Å”anas stadijā pat nevarētu sapņot.

Un jā, visu Å”o prasÄ«bu izpilde vienā sistēmā ir iespējama (protams, atseviŔķos gadÄ«jumos un ar dažām atrunām).

Tālāk es aplÅ«koÅ”u divas no populārākajām datu noliktavu veiklās projektÄ“Å”anas metodoloÄ£ijām - Enkura modelis Šø Datu glabātuve. Ārpus iekavām ir palikuÅ”as tādas izcilas tehnikas kā, piemēram, EAV, 6NF (tÄ«rā veidā) un viss, kas saistÄ«ts ar NoSQL risinājumiem - ne tāpēc, ka tie bÅ«tu kaut kā sliktāki, un pat ne tāpēc, ka Å”ajā gadÄ«jumā raksts draudētu iegÅ«t vidējā disertācijas apjoms. Tas viss attiecas tikai uz nedaudz atŔķirÄ«gas klases risinājumiem ā€” vai nu uz paņēmieniem, kurus varat izmantot konkrētos gadÄ«jumos neatkarÄ«gi no jÅ«su projekta vispārējās arhitektÅ«ras (piemēram, EAV), vai globāli citām informācijas glabāŔanas paradigmām (piemēram, grafiku datubāzēm). un citas iespējas NoSQL).

ā€œKlasiskāsā€ pieejas problēmas un to risinājumi elastÄ«gās metodoloÄ£ijās

Ar ā€œklasiskoā€ pieeju es domāju veco labo zvaigzni (neatkarÄ«gi no pamatā esoÅ”o slāņu konkrētās realizācijas, lai Kimball, Inmon un CDM sekotāji man piedod).

1. Savienojumu stingrā kardinalitāte

Å is modelis ir balstÄ«ts uz skaidru datu sadalÄ«jumu Izmērs Šø faktus. Un tas, sasodÄ«ts, ir loÄ£iski - galu galā datu analÄ«ze vairumā gadÄ«jumu nonāk lÄ«dz noteiktu skaitlisko rādÄ«tāju (faktu) analÄ«zei noteiktās sadaļās (dimensijās).

Šajā gadījumā savienojumi starp objektiem tiek izveidoti attiecību veidā starp tabulām, izmantojot ārējo atslēgu. Tas izskatās diezgan dabiski, taču nekavējoties noved pie pirmā elastības ierobežojuma - stingra savienojumu kardinalitātes definīcija.

Tas nozÄ«mē, ka tabulas izstrādes stadijā katram saistÄ«to objektu pārim ir precÄ«zi jānosaka, vai tie var bÅ«t saistÄ«ti tik daudz pret daudziem vai tikai viens pret daudziem un ā€œkurā virzienāā€. Tas tieÅ”i nosaka, kurai tabulai bÅ«s primārā atslēga un kurai bÅ«s ārējā atslēga. Å Ä«s attieksmes maiņa, saņemot jaunas prasÄ«bas, visticamāk, novedÄ«s pie bāzes pārstrādes.

Piemēram, veidojot ā€œkases čekaā€ objektu, jÅ«s, paļaujoties uz tirdzniecÄ«bas nodaļas zvērestu, noteicāt rÄ«cÄ«bas iespēju viena akcija vairākām čekas pozÄ«cijām (bet ne otrādi):

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām
Un pēc kāda laika kolēģi ieviesa jaunu mārketinga stratēģiju, kurā viņi var darboties tajā paŔā amatā vairākas akcijas vienlaikus. Un tagad jums ir jāmaina tabulas, atdalot attiecÄ«bas atseviŔķā objektā.

(Tagad arī ir jāuzlabo visi atvasinātie objekti, kuros ir pievienota veicināŔanas pārbaude).

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām
Attiecības datu glabātuvē un enkura modelī

IzvairÄ«Å”anās no Ŕīs situācijas izrādÄ«jās pavisam vienkārÅ”a: jums nav jāuzticas pārdoÅ”anas nodaļai, lai to izdarÄ«tu. visi savienojumi sākotnēji tiek saglabāti atseviŔķās tabulās un apstrādāt to kā daudzi pret daudziem.

Å Ä« pieeja tika ierosināta Dens LinÅ”teds kā daļa no paradigmas Datu glabātuve un pilnÄ«bā atbalstÄ«ts Larss Renbeks Š² Enkura modelis.

Rezultātā mēs iegÅ«stam pirmo elastÄ«go metodoloÄ£iju atŔķirÄ«go iezÄ«mi:

Attiecības starp objektiem netiek glabātas vecāku entītiju atribūtos, bet ir atseviŔķs objektu veids.

Š’ Datu glabātuve Ŕādas saistÄ«Å”anas tabulas sauc saiteun Enkura modelis Sākot no Kakla saite. No pirmā acu uzmetiena tie ir ļoti lÄ«dzÄ«gi, lai gan to atŔķirÄ«bas nebeidzas ar nosaukumu (kas tiks apspriests tālāk). Abās arhitektÅ«rās saiÅ”u tabulas var saistÄ«t jebkurÅ” vienÄ«bu skaits (nav obligāti 2).

Å Ä« atlaiÅ”ana, no pirmā acu uzmetiena, nodroÅ”ina ievērojamu elastÄ«bu modifikācijām. Šāda struktÅ«ra kļūst toleranta ne tikai pret esoÅ”o saiÅ”u kardinalitātes izmaiņām, bet arÄ« pret jaunu pievienoÅ”anu - ja tagad čeka pozÄ«cijai ir arÄ« saite uz kasieri, kurÅ” to izlauzis, Ŕādas saites parādÄ«Å”anās vienkārÅ”i kļūt par papildinājumu esoÅ”ajām tabulām, neietekmējot esoÅ”os objektus un procesus.

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

2. Datu dublēŔana

Otrā problēma, ko atrisina elastīgas arhitektūras, ir mazāk acīmredzama un, pirmkārt, ir raksturīga. SCD2 tipa mērījumi (pamazām mainās otrā tipa izmēri), lai gan ne tikai tie.

Klasiskā noliktavā dimensija parasti ir tabula, kurā ir ietverta aizstājējatslēga (kā PK) un biznesa atslēgu un atribÅ«tu kopa atseviŔķās kolonnās.

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Ja dimensija atbalsta versiju veidoÅ”anu, versijas derÄ«guma robežas tiek pievienotas standarta lauku kopai, un repozitorijā tiek parādÄ«tas vairākas versijas vienai avota rindai (viena katrai versijas atribÅ«tu maiņai).

Ja dimensijā ir vismaz viens bieži mainÄ«gs versijas atribÅ«ts, Ŕādas dimensijas versiju skaits bÅ«s iespaidÄ«gs (pat ja pārējie atribÅ«ti netiek versijas vai nekad nemainās), un, ja ir vairāki Ŕādi atribÅ«ti, versiju skaits var pieaug eksponenciāli no to skaita. Å Ä« dimensija var aizņemt ievērojamu vietu diskā, lai gan liela daļa tajā saglabāto datu ir vienkārÅ”i nemaināmu atribÅ«tu vērtÄ«bu dublikāti no citām rindām.

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Tajā paŔā laikā to izmanto arÄ« ļoti bieži denormalizācija ā€” daži atribÅ«ti tiek apzināti saglabāti kā vērtÄ«ba, nevis kā saite uz atsauces grāmatu vai citu dimensiju. Å Ä« pieeja paātrina piekļuvi datiem, samazinot savienojumu skaitu, piekļūstot kategorijai.

Parasti tas noved pie viena un tā pati informācija tiek glabāta vienlaikus vairākās vietās. Piemēram, informāciju par dzÄ«vesvietas reÄ£ionu un klienta kategoriju var vienlaikus glabāt dimensijās ā€œKlientsā€ un faktos ā€œPirkumsā€, ā€œPiegādeā€ un ā€œZvanu centra zvaniā€, kā arÄ« ā€œKlients - klientu menedžerisā€. ā€ saiÅ”u tabula.

Kopumā iepriekÅ” aprakstÄ«tais attiecas uz parastajiem (neversijās) izmēriem, taču versijās tiem var bÅ«t atŔķirÄ«gs mērogs: jaunas objekta versijas parādÄ«Å”anās (Ä«paÅ”i retrospektÄ«vi) noved pie ne tikai visu saistÄ«to datu atjaunināŔanas. tabulām, bet uz saistÄ«tu objektu jaunu versiju kaskādes izskatu - kad 1. tabulu izmanto 2. tabulas veidoÅ”anai, bet 2. tabulu izmanto 3. tabulas veidoÅ”anai utt. Pat ja 1. tabulas konstruÄ“Å”anā nav iesaistÄ«ts neviens 3. tabulas atribÅ«ts (un ir iesaistÄ«ti citi 2. tabulas atribÅ«ti, kas iegÅ«ti no citiem avotiem), Ŕīs konstrukcijas versijas noteikÅ”ana radÄ«s vismaz papildu pieskaitāmās izmaksas un maksimāli papildu izmaksas. versijas 3. tabulā, kam ar to vispār nav nekāda sakara, un tālāk ķēdē.

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

3. PārstrādāŔanas nelineāra sarežģītība

Tajā paŔā laikā katra jauna veikala mājvieta, kas veidota, pamatojoties uz citu, palielina vietu skaitu, kur dati var ā€œatŔķirtiesā€, kad tiek veiktas izmaiņas ETL. Tas savukārt palielina katras nākamās pārskatÄ«Å”anas sarežģītÄ«bu (un ilgumu).

Ja iepriekÅ” minētais apraksta sistēmas ar reti modificētiem ETL procesiem, jÅ«s varat dzÄ«vot Ŕādā paradigmā - jums tikai jāpārliecinās, ka visos saistÄ«tajos objektos ir pareizi veiktas jaunas modifikācijas. Ja pārskatÄ«Å”ana notiek bieži, ievērojami palielinās iespēja nejauÅ”i ā€œpazaudētā€ vairākus savienojumus.

Ja piedevām ņemam vērā, ka ā€œversijuētaisā€ ETL ir ievērojami sarežģītāks par ā€œneversijuā€, tad, bieži atjauninot visu Å”o iekārtu, ir diezgan grÅ«ti izvairÄ«ties no kļūdām.

Objektu un atribūtu uzglabāŔana Data Vault un Enchor Model

ElastÄ«go arhitektÅ«ru autoru piedāvāto pieeju var formulēt Ŕādi:

Ir jānodala tas, kas mainās no tā, kas paliek nemainÄ«gs. Tas ir, glabājiet atslēgas atseviŔķi no atribÅ«tiem.

Tomēr nevajadzētu sajaukt nav versijas atribūts ar nemainīgs: pirmais nesaglabā savu izmaiņu vēsturi, bet var mainīties (piemēram, labojot ievades kļūdu vai saņemot jaunus datus); otrais nekad nemainās.

Viedokļi atŔķiras par to, ko tieÅ”i datu krātuvē un enkura modelÄ« var uzskatÄ«t par nemainÄ«gu.

No arhitektÅ«ras viedokļa Datu glabātuve, var uzskatÄ«t par nemainÄ«gu viss atslēgu komplekts - dabiskais (organizācijas TIN, produkta kods avota sistēmā utt.) un aizstājējs. Tādā gadÄ«jumā atlikuÅ”os atribÅ«tus var iedalÄ«t grupās pēc izmaiņu avota un/vai biežuma un Saglabājiet atseviŔķu tabulu katrai grupai ar neatkarÄ«gu versiju komplektu.

Paradigmā Enkura modelis uzskatÄ«ts par nemainÄ«gu tikai surogāt atslēga bÅ«tÄ«ba. Viss pārējais (ieskaitot dabiskās atslēgas) ir tikai Ä«paÅ”s tā atribÅ«tu gadÄ«jums. Kurā visi atribÅ«ti pēc noklusējuma ir neatkarÄ«gi viens no otra, tāpēc katram atribÅ«tam a atseviŔķs galds.

Š’ Datu glabātuve tiek izsauktas tabulas, kas satur entÄ«tiju atslēgas Hubami. Centrmezglos vienmēr ir fiksēta lauku kopa:

  • Dabiskās entÄ«tijas atslēgas
  • Surogāt atslēga
  • Saite uz avotu
  • Ierakstiet pievienoÅ”anas laiku

Ziņas vietnē Hubs nekad nemainās un nav versiju. Ārēji centrmezgli ir ļoti lÄ«dzÄ«gi ID kartes tipa tabulām, ko dažās sistēmās izmanto surogātu Ä£enerÄ“Å”anai, tomēr ir ieteicams izmantot jaucēju no biznesa atslēgu kopas kā aizstājējus Data Vault. Å Ä« pieeja vienkārÅ”o attiecÄ«bu un atribÅ«tu ielādi no avotiem (jums nav jāpievienojas centrmezglam, lai iegÅ«tu surogātu, jums vienkārÅ”i jāaprēķina dabiskās atslēgas jaucējvārds), taču var rasties citas problēmas (piemēram, ar sadursmēm). , burtus un nedrukājamas rakstzÄ«mes virknes taustiņos utt. .p.), tāpēc tas nav vispārpieņemts.

Visi pārējie entÄ«tiju atribÅ«ti tiek glabāti Ä«paŔās tabulās, ko sauc SatelÄ«ti. Vienam centrmezglam var bÅ«t vairāki satelÄ«ti, kas glabā dažādas atribÅ«tu kopas.

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

AtribÅ«tu sadalÄ«jums starp satelÄ«tiem notiek pēc principa locÄ«tavu maiņa - vienā satelÄ«tā var saglabāt neversētus atribÅ«tus (piemēram, dzimÅ”anas datums un SNILS indivÄ«dam), citā - reti maināmus versijas (piemēram, uzvārds un pases numurs), treÅ”ajā - bieži mainÄ«gie. (piemēram, piegādes adrese, kategorija, pēdējā pasÅ«tÄ«juma datums utt.). Å ajā gadÄ«jumā versiju noteikÅ”ana tiek veikta atseviŔķu satelÄ«tu, nevis visas entÄ«tijas lÄ«menÄ«, tāpēc ieteicams atribÅ«tus izplatÄ«t tā, lai versiju krustoÅ”anās vienā satelÄ«tā bÅ«tu minimāla (kas samazina kopējo saglabāto versiju skaitu ).

Tāpat, lai optimizētu datu ielādes procesu, atseviŔķos satelÄ«tos bieži tiek iekļauti no dažādiem avotiem iegÅ«ti atribÅ«ti.

SatelÄ«ti sazinās ar centrmezglu, izmantojot sveÅ”a atslēga (kas atbilst kardinalitātei 1 pret daudziem). Tas nozÄ«mē, ka Ŕī ā€œnoklusējumaā€ arhitektÅ«ra atbalsta vairākas atribÅ«tu vērtÄ«bas (piemēram, vairākus kontakttālruņa numurus vienam klientam).

Š’ Enkura modelis tiek izsauktas tabulas, kurās glabājas atslēgas Enkuri. Un viņi saglabā:

  • Tikai surogāt atslēgas
  • Saite uz avotu
  • Ierakstiet pievienoÅ”anas laiku

Tiek aplÅ«kotas dabiskās atslēgas no Enkura modeļa viedokļa parastie atribÅ«ti. Å Ä« opcija var Ŕķist grÅ«tāk saprotama, taču tā sniedz daudz plaŔākas iespējas objekta identificÄ“Å”anai.

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Piemēram, ja dati par vienu un to paÅ”u entÄ«tiju var nākt no dažādām sistēmām, no kurām katra izmanto savu dabisko atslēgu. Programmā Data Vault tas var novest pie diezgan apgrÅ«tinoŔām vairāku centrmezglu struktÅ«rām (viens katram avotam + vienojoÅ”a galvenā versija), savukārt Anchor modelÄ« katra avota dabiskā atslēga ietilpst tā atribÅ«tā un to var izmantot, ielādējot neatkarÄ«gi no visi pārējie.

Bet Å”eit ir arÄ« viens mānÄ«gs punkts: ja atribÅ«ti no dažādām sistēmām tiek apvienoti vienā entÄ«tijā, visticamāk, ir daži "lÄ«mÄ“Å”anas" noteikumi, ar kuru sistēmai jāsaprot, ka ieraksti no dažādiem avotiem atbilst vienam entÄ«tijas gadÄ«jumam.

Š’ Datu glabātuve Å”ie noteikumi, visticamāk, noteiks veidojumu galvenās entÄ«tijas ā€œaizstājējs centrsā€. un nekādā veidā neietekmē centrmezglus, kas glabā dabiskās avota atslēgas un to sākotnējos atribÅ«tus. Ja kādā brÄ«dÄ« sapludināŔanas noteikumi mainās (vai tiek atjaunināti atribÅ«ti, ar kuriem tā tiek veikta), pietiks ar aizstājējcentrmezglu pārformatÄ“Å”anu.

Š’ Enkura modelis Ŕāda vienÄ«ba, visticamāk, tiks saglabāta vienÄ«gais enkurs. Tas nozÄ«mē, ka visi atribÅ«ti, neatkarÄ«gi no tā, no kāda avota tie nāk, bÅ«s saistÄ«ti ar vienu un to paÅ”u aizstājēju. Kļūdaini sapludinātu ierakstu atdalÄ«Å”ana un kopumā sapludināŔanas atbilstÄ«bas uzraudzÄ«ba Ŕādā sistēmā var bÅ«t daudz grÅ«tāka, it Ä«paÅ”i, ja noteikumi ir diezgan sarežģīti un bieži mainās, un vienu un to paÅ”u atribÅ«tu var iegÅ«t no dažādiem avotiem (lai gan tas noteikti ir iespējams, jo katra atribÅ«ta versija saglabā saiti uz savu avotu).

Jebkurā gadÄ«jumā, ja jÅ«su sistēmai ir jāīsteno funkcionalitāte dublÄ“Å”anās, ierakstu un citu MDM elementu sapludināŔana, ir vērts pievērst Ä«paÅ”u uzmanÄ«bu dabisko atslēgu glabāŔanas aspektiem veiklās metodoloÄ£ijās. Iespējams, ka apjomÄ«gākais Data Vault dizains pēkŔņi bÅ«s droŔāks sapludināŔanas kļūdu ziņā.

Enkura modelis nodroÅ”ina arÄ« papildu objekta tipu, ko sauc Mezgls tas bÅ«tÄ«bā ir Ä«paÅ”s deÄ£enerēts enkura veids, kurā var bÅ«t tikai viens atribÅ«ts. Mezglus paredzēts izmantot, lai saglabātu vienotus direktorijus (piemēram, dzimums, Ä£imenes stāvoklis, klientu apkalpoÅ”anas kategorija utt.). AtŔķirÄ«bā no Enkura, Mezgls nav saistÄ«tu atribÅ«tu tabulu, un tā vienÄ«gais atribÅ«ts (nosaukums) vienmēr tiek saglabāts vienā tabulā ar atslēgu. Mezgli ir savienoti ar enkuriem ar saiÅ”u tabulām (Tie) tādā paŔā veidā, kā Enkuri ir savienoti viens ar otru.

Nav skaidra viedokļa par mezglu izmantoÅ”anu. Piemēram, Nikolajs Golovs, kurÅ” aktÄ«vi veicina Enkura modeļa izmantoÅ”anu Krievijā, uzskata (ne nepamatoti), ka ne par vienu uzziņu grāmatu var droÅ”i apgalvot, ka vienmēr bÅ«s statisks un vienlÄ«meņa, tāpēc labāk nekavējoties izmantot pilnvērtÄ«gu Enchor visiem objektiem.

Vēl viena svarÄ«ga atŔķirÄ«ba starp Data Vault un Anchor modeli ir pieejamÄ«ba savienojumu atribÅ«ti:

Š’ Datu glabātuve Saites ir tādi paÅ”i pilnvērtÄ«gi objekti kā Hubs, un tiem var bÅ«t paÅ”u atribÅ«ti. Uz Enkura modelis Saites tiek izmantotas tikai, lai savienotu Enkurus un nevar bÅ«t savas Ä«paŔības. Å Ä« atŔķirÄ«ba rada ievērojami atŔķirÄ«gas modelÄ“Å”anas pieejas faktus, kas tiks apspriests tālāk.

Faktu glabāŔana

Pirms tam mēs galvenokārt runājām par mērÄ«jumu modelÄ“Å”anu. Fakti ir nedaudz mazāk skaidri.

Š’ Datu glabātuve tipisks faktu glabāŔanas objekts ir Saite, kuras satelÄ«tos tiek pievienoti reālie rādÄ«tāji.

Å Ä« pieeja Ŕķiet intuitÄ«va. Tas nodroÅ”ina ērtu piekļuvi analizētajiem rādÄ«tājiem un kopumā ir lÄ«dzÄ«gs tradicionālajai faktu tabulai (tikai rādÄ«tāji tiek glabāti nevis paŔā tabulā, bet ā€œkaimiņuā€ tabulā). Bet ir arÄ« nepilnÄ«bas: viena no modeļa tipiskām modifikācijām - faktu atslēgas paplaÅ”ināŔana - rada nepiecieÅ”amÄ«bu pievienojot saitei jaunu ārējo atslēgu. Un tas, savukārt, ā€œsalaužā€ modularitāti un, iespējams, rada nepiecieÅ”amÄ«bu veikt izmaiņas citos objektos.

Š’ Enkura modelis Savienojumam nevar bÅ«t savi atribÅ«ti, tāpēc Ŕī pieeja nedarbosies ā€“ absolÅ«ti visiem atribÅ«ti un rādÄ«tājiem jābÅ«t saistÄ«tiem ar vienu konkrētu enkuru. Secinājums no tā ir vienkārÅ”s - Katram faktam ir vajadzÄ«gs arÄ« savs enkurs. Dažiem no tā, ko esam pieraduÅ”i uztvert kā faktus, tas var izskatÄ«ties dabiski - piemēram, pirkuma faktu var lieliski reducēt uz objektu ā€œpasÅ«tÄ«jumsā€ vai ā€œsaņemÅ”anaā€, vietnes apmeklējums uz sesiju utt. Bet ir arÄ« fakti, kuriem nav tik viegli atrast tik dabisku ā€œnesējobjektuā€ - piemēram, preču atliekas noliktavās katras dienas sākumā.

AttiecÄ«gi problēmas ar modularitāti, paplaÅ”inot faktu atslēgu enkura modelÄ«, nerodas (pietiek vienkārÅ”i pievienot jaunu relāciju attiecÄ«gajam enkuram), taču modeļa projektÄ“Å”ana faktu attēloÅ”anai ir mazāk viennozÄ«mÄ«ga; var parādÄ«ties ā€œmākslÄ«gieā€ enkuri. kas parāda biznesa objekta modeli neskaidrā veidā.

Kā tiek panākta elastība

IegÅ«tā konstrukcija abos gadÄ«jumos satur ievērojami vairāk tabulunekā tradicionālie mērÄ«jumi. Bet tas var aizņemt ievērojami mazāk vietas diskā ar tādu paÅ”u versiju atribÅ«tu kopu kā tradicionālā dimensija. Protams, Å”eit nav nekādas maÄ£ijas - viss ir saistÄ«ts ar normalizÄ“Å”anu. Izplatot atribÅ«tus pa satelÄ«tiem (Datu glabātuvē) vai atseviŔķām tabulām (enkura modelis), mēs samazinām (vai pilnÄ«bā likvidējam) dažu atribÅ«tu vērtÄ«bu dublÄ“Å”anās, mainot citus.

Par Datu glabātuve laimests bÅ«s atkarÄ«gs no atribÅ«tu sadalÄ«juma starp SatelÄ«tiem, un par Enkura modelis ā€” ir gandrÄ«z tieÅ”i proporcionāls vidējam versiju skaitam uz vienu mērÄ«jumu objektu.

Tomēr vietas ietaupÄ«jums ir svarÄ«ga, bet ne galvenā priekÅ”rocÄ«ba, uzglabājot atribÅ«tus atseviŔķi. Kopā ar atseviŔķu attiecÄ«bu uzglabāŔanu Ŕī pieeja padara veikalu modulārais dizains. Tas nozÄ«mē, ka Ŕādā modelÄ« izskatās gan atseviŔķu atribÅ«tu, gan visu jaunu priekÅ”metu jomu pievienoÅ”ana virsbÅ«ve pār esoÅ”u objektu kopu, tos nemainot. Un tieÅ”i tas padara aprakstÄ«tās metodikas elastÄ«gas.

Tas arÄ« atgādina pāreju no gabalražoÅ”anas uz masveida ražoÅ”anu - ja tradicionālajā pieejā katra modeļa tabula ir unikāla un prasa Ä«paÅ”u uzmanÄ«bu, tad elastÄ«gās metodikās tas jau ir standarta ā€œdetaļuā€ komplekts. No vienas puses, tabulu ir vairāk, un datu ielādes un izguves procesiem vajadzētu izskatÄ«ties sarežģītākiem. No otras puses, viņi kļūst tipisks. Kas nozÄ«mē, ka var bÅ«t automatizēta un balstÄ«ta uz metadatiem. Jautājums ā€œkā mēs to liksim?ā€, uz kuru atbilde varētu aizņemt ievērojamu daļu no uzlabojumu izstrādes darba, tagad vienkārÅ”i nav tā vērts (kā arÄ« jautājums par modeļa maiņas ietekmi uz darba procesiem ).

Tas nenozÄ«mē, ka analÄ«tiÄ·i Ŕādā sistēmā nemaz nav vajadzÄ«gi ā€“ kādam tomēr ir jāpārstrādā objektu kopa ar atribÅ«tiem un jāizdomā, kur un kā to visu ielādēt. Taču ievērojami samazinās darba apjoms, kā arÄ« kļūdas iespējamÄ«ba un izmaksas. Gan analÄ«zes stadijā, gan ETL izstrādes laikā, ko lielā mērā var reducēt uz metadatu rediģēŔanu.

TumŔā puse

Viss iepriekÅ” minētais padara abas pieejas patiesi elastÄ«gas, tehnoloÄ£iski progresÄ«vas un piemērotas iteratÄ«vai uzlaboÅ”anai. Protams, ir arÄ« ā€œmuca ziedēā€, par kuru, manuprāt, jau var nojaust.

Datu dekompozīcija, kas ir elastīgu arhitektūru modularitātes pamatā, izraisa tabulu skaita palielināŔanos un attiecīgi virs galvas pievienojas izlases laikā. Lai vienkārŔi iegūtu visus dimensijas atribūtus, klasiskajā veikalā pietiek ar vienu atlasi, bet elastīgai arhitektūrai būs nepiecieŔama vesela virkne savienojumu. Turklāt, ja visus Ŕos atskaiŔu savienojumus var uzrakstīt iepriekŔ, analītiķi, kuri ir pieraduŔi rakstīt SQL ar roku, cietīs divreiz.

Ir vairāki fakti, kas atvieglo Ŕo situāciju:

Strādājot ar lieliem izmēriem, visi tā atribÅ«ti gandrÄ«z nekad netiek izmantoti vienlaikus. Tas nozÄ«mē, ka var bÅ«t mazāk savienojumu, nekā Ŕķiet, no pirmā acu uzmetiena uz modeli. PieŔķirot atribÅ«tus satelÄ«tiem, Data Vault var ņemt vērā arÄ« paredzamo koplietoÅ”anas biežumu. Tajā paŔā laikā paÅ”i centrmezgli vai enkuri ir nepiecieÅ”ami galvenokārt surogātu Ä£enerÄ“Å”anai un kartÄ“Å”anai ielādes stadijā, un tos reti izmanto vaicājumos (tas jo Ä«paÅ”i attiecas uz enkuriem).

Visi savienojumi ir ar atslēgu. Turklāt ā€œsaspiestāksā€ datu glabāŔanas veids samazina tabulu skenÄ“Å”anas izmaksas, kur tas ir nepiecieÅ”ams (piemēram, filtrējot pēc atribÅ«ta vērtÄ«bas). Tas var novest pie tā, ka paraugu ņemÅ”ana no normalizētas datu bāzes ar virkni savienojumu bÅ«s pat ātrāka nekā vienas smagas dimensijas skenÄ“Å”ana ar daudzām versijām katrā rindā.

Piemēram, Å”eit Å”is Rakstā ir detalizēts salÄ«dzinoÅ”ais Anchor modeļa veiktspējas tests ar paraugu no vienas tabulas.

Daudz kas ir atkarÄ«gs no dzinēja. Daudzām mÅ«sdienu platformām ir iekŔējie savienojuma optimizācijas mehānismi. Piemēram, MS SQL un Oracle var ā€œizlaistā€ savienojumus ar tabulām, ja to dati netiek izmantoti nekur, izņemot citus savienojumus, un tie neietekmē galÄ«go atlasi (tabulas/savienojuma likvidÄ“Å”ana), un MPP Vertica Avito kolēģu pieredze, ir izrādÄ«jies lielisks Enchor Model dzinējs, ņemot vērā vaicājumu plāna manuālu optimizāciju. No otras puses, Anchor Model glabāŔana, piemēram, Click House, kuram ir ierobežots pievienoÅ”anās atbalsts, pagaidām neizskatās pēc ļoti labas idejas.

Turklāt abām arhitektÅ«rām ir Ä«paÅ”as kustÄ«bas, atvieglojot piekļuvi datiem (gan no vaicājuma veiktspējas viedokļa, gan galalietotājiem). Piemēram, Point-In-Time tabulas programmā Data Vault vai Ä«paÅ”as tabulas funkcijas enkura modelÄ«.

Kopā

Aplūkoto elastīgo arhitektūru galvenā būtība ir to "dizaina" modularitāte.

TieŔi Ŕis īpaŔums ļauj:

  • Pēc sākotnējās sagatavoÅ”anās, kas saistÄ«ta ar metadatu izvietoÅ”anu un pamata ETL algoritmu rakstÄ«Å”anu, ātri nodroÅ”ināt klientam pirmo rezultātu pāris atskaiÅ”u veidā, kas satur datus tikai no dažiem avota objektiem. Nav nepiecieÅ”ams pilnÄ«bā (pat augstākā lÄ«menÄ«) pārdomāt visu objekta modeli.
  • Datu modelis var sākt darboties (un bÅ«t noderÄ«gs) tikai ar 2ā€“3 objektiem un pēc tam augt pakāpeniski (attiecÄ«bā uz Enkura modeli Nikolaju piemērots jauks salÄ«dzinājums ar micēliju).
  • Lielākā daļa uzlabojumu, tostarp tēmas paplaÅ”ināŔana un jaunu avotu pievienoÅ”ana neietekmē esoÅ”o funkcionalitāti un nerada risku salauzt kaut ko, kas jau darbojas.
  • Pateicoties sadalÄ«Å”anai standarta elementos, ETL procesi Ŕādās sistēmās izskatās vienādi, to rakstÄ«Å”ana ir piemērota algoritmizÄ“Å”anai un galu galā automatizācija.

Å Ä«s elastÄ«bas cena ir sniegumu. Tas nenozÄ«mē, ka Ŕādos modeļos nav iespējams sasniegt pieņemamu veiktspēju. Biežāk nekā nē, lai sasniegtu vēlamos rādÄ«tājus, iespējams, vienkārÅ”i bÅ«s jāpieliek vairāk pūļu un uzmanÄ«bas detaļām.

progr

Entītiju veidi Datu glabātuve

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

PlaŔāka informācija par Data Vault:
Dan Lystadt vietne
Viss par Data Vault krievu valodā
Par Data Vault vietnē HabrĆ©

Entītiju veidi Enkura modelis

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Sīkāka informācija par enkura modeli:

Anchor Model veidotāju vietne
Raksts par Enchor Model ievieŔanas pieredzi Avito

Kopsavilkuma tabula ar aplÅ«koto pieeju kopÄ«gām iezÄ«mēm un atŔķirÄ«bām:

Pārskats par Agile DWH projektÄ“Å”anas metodoloÄ£ijām

Avots: www.habr.com

Pievieno komentāru