Disvolvi stokejon estas longa kaj serioza entrepreno.
Multe en la vivo de projekto dependas de kiom bone la objektomodelo kaj bazstrukturo estas pripensitaj komence.
La ĝenerale akceptita aliro estis kaj restas diversaj variaĵoj de kombinado de la stelskemo kun tria normala formo. Kiel regulo, laŭ la principo: komencaj datumoj - 3NF, montrofenestroj - stelo. Ĉi tiu aliro, temp-testita kaj subtenata de granda kvanto da esplorado, estas la unua (kaj foje la sola) afero, kiu venas en la menson de sperta DWH-specialisto kiam pensas pri kia analiza deponejo devus aspekti.
Aliflanke, komerco ĝenerale kaj klientpostuloj precipe tendencas ŝanĝiĝi rapide, kaj datumoj emas kreski kaj "profunde" kaj "larĝe". Kaj ĉi tie aperas la ĉefa malavantaĝo de stelo - limigita fleksebleco.
Kaj se en via trankvila kaj komforta vivo kiel DWH-programisto subite:
- la tasko ekestis "fari almenaŭ ion rapide, kaj tiam ni vidos";
- aperis rapide evoluanta projekto, kun kunligo de novaj fontoj kaj reverkado de la komerca modelo almenaŭ unufoje semajne;
- aperis kliento, kiu ne havas ideon, kiel la sistemo devus aspekti kaj kiajn funkciojn ĝi devus finfine plenumi, sed estas preta eksperimenti kaj konstante rafini la deziratan rezulton dum konstante alproksimiĝante al ĝi;
- La projektestro eniris kun la bona novaĵo: "Kaj nun ni havas lertajn!"
Aŭ se vi nur interesiĝas ekscii kiel alie vi povas konstrui stokejojn - bonvenon al la tranĉo!
Kion signifas "fleksebleco"?
Unue, ni difinu kiajn ecojn devas havi sistemon por esti nomata "fleksebla".
Aparte, indas mencii, ke la priskribitaj propraĵoj devus rilati specife al sistemo, ne al procezo ĝia evoluo. Tial, se vi volis legi pri Agile kiel disvolva metodiko, estas pli bone legi aliajn artikolojn. Ekzemple, ĝuste tie, sur Habré, estas multaj interesaj materialoj (kiel и , kaj ).
Ĉi tio ne signifas, ke la evoluprocezo kaj la strukturo de la datumstokejo estas tute senrilataj. Ĝenerale, devus esti signife pli facile evoluigi Agile-deponejon por lerta arkitekturo. Tamen, en la praktiko, pli ofte estas ebloj kun Agile-disvolviĝo de la klasika DWH laŭ Kimbal kaj DataVault - laŭ Waterfall, ol feliĉaj koincidoj de fleksebleco en ĝiaj du formoj en unu projekto.
Do, kiajn kapablojn havu fleksebla stokado? Estas tri punktoj ĉi tie:
- Frua livero kaj rapida turniĝo - tio signifas, ke ideale la unua komerca rezulto (ekzemple, la unuaj laborraportoj) devus esti akirita kiel eble plej frue, tio estas, eĉ antaŭ ol la tuta sistemo estas plene desegnita kaj efektivigita. Krome, ĉiu posta revizio ankaŭ devus preni kiel eble plej malmulte da tempo.
- Ripetema rafinado - tio signifas, ke ĉiu posta plibonigo ideale ne tuŝu la funkciojn, kiuj jam funkcias. Estas ĉi tiu momento, kiu ofte fariĝas la plej granda koŝmaro en grandaj projektoj - baldaŭ aŭ malfrue, individuaj objektoj komencas akiri tiom da ligoj, ke fariĝas pli facile tute ripeti la logikon en kopio apude ol aldoni kampon al ekzistanta tabelo. Kaj se vi estas surprizita, ke analizi la efikon de plibonigoj sur ekzistantaj objektoj povas preni pli da tempo ol la plibonigoj mem, vi plej verŝajne ankoraŭ ne laboris kun grandaj datumstokejoj en bankado aŭ telekomunikado.
- Konstante adaptiĝante al ŝanĝiĝantaj komercaj postuloj - la ĝenerala objektostrukturo devus esti desegnita ne nur konsiderante eblan vastiĝon, sed kun la atendo, ke la direkto de ĉi tiu sekva ekspansio eĉ ne povus esti sonĝita en la projektetapo.
Kaj jes, plenumi ĉiujn ĉi tiujn postulojn en unu sistemo eblas (kompreneble, en certaj kazoj kaj kun iuj rezervoj).
Malsupre mi konsideros du el la plej popularaj lertaj dezajnaj metodaroj por datumstokejoj - Ankromodelo и Datuma Trezorejo. Forlasitaj el la krampoj estas tiaj bonegaj teknikoj kiel, ekzemple, EAV, 6NF (en ĝia pura formo) kaj ĉio rilata al NoSQL-solvoj - ne ĉar ili estas iel pli malbonaj, kaj eĉ ne ĉar ĉi-kaze la artikolo minacus akiri. la volumeno de la meza disanto. Estas nur, ke ĉio ĉi rilatas al solvoj de iomete malsama klaso - ĉu al teknikoj kiujn vi povas uzi en specifaj kazoj, sendepende de la ĝenerala arkitekturo de via projekto (kiel EAV), aŭ al tutmonde aliaj informoj pri konservado de paradigmoj (kiel grafikaj datumbazoj). kaj aliaj opcioj NoSQL).
Problemoj de la "klasika" aliro kaj iliaj solvoj en flekseblaj metodaroj
Per "klasika" aliro mi celas la bonan malnovan stelon (sendepende de la specifa efektivigo de la subaj tavoloj, la sekvantoj de Kimball, Inmon kaj CDM pardonu min).
1. Rigida kardinaleco de ligoj
Ĉi tiu modelo baziĝas sur klara divido de datumoj en Dimensio и faktoj. Kaj ĉi tio, diablo, estas logika - finfine, datuma analizo en la superforta plimulto de kazoj venas al la analizo de certaj nombraj indikiloj (faktoj) en certaj sekcioj (dimensioj).
En ĉi tiu kazo, ligoj inter objektoj estas establitaj en la formo de rilatoj inter tabeloj uzante fremdan ŝlosilon. Ĉi tio aspektas tute nature, sed tuj kondukas al la unua limigo de fleksebleco - strikta difino de la kardinaleco de ligoj.
Ĉi tio signifas, ke en la tabela desegna stadio, vi devas precize determini por ĉiu paro de rilataj objektoj ĉu ili povas rilati kiel multaj-al-multaj, aŭ nur 1-al-multaj, kaj "en kiu direkto". Ĉi tio rekte determinas, kiu tablo havos la ĉefan ŝlosilon kaj kiu havos la fremdan ŝlosilon. Ŝanĝi ĉi tiun sintenon kiam novaj postuloj estos ricevitaj, plej verŝajne kondukos al reverkado de la bazo.
Ekzemple, kiam vi desegnas la objekton "kontantan kvitancon", vi, fidante je la ĵuroj de la venda fako, fiksis la eblecon de agado. unu promocio por pluraj ĉekpozicioj (sed ne inverse):
Kaj post iom da tempo, kolegoj enkondukis novan merkatan strategion en kiu ili povas agi sur la sama pozicio plurajn promociojn samtempe. Kaj nun vi devas modifi la tabelojn disigante la rilaton en apartan objekton.
(Ĉiuj derivitaj objektoj en kiuj la reklama kontrolo estas kunigita nun ankaŭ devas esti plibonigitaj).
Rilatoj en Data Vault kaj Anchor Model
Eviti ĉi tiun situacion montriĝis sufiĉe simpla: vi ne devas fidi la vendan fakon por fari tion. ĉiuj ligoj estas komence konservitaj en apartaj tabeloj kaj procesi ĝin kiel multaj-al-multaj.
Ĉi tiu aliro estis proponita Dan Linstedt kiel parto de la paradigmo Datuma Trezorejo kaj plene subtenata Lars Rönnbäck в Ankro-Modelo.
Kiel rezulto, ni ricevas la unuan karakterizaĵon de flekseblaj metodaroj:
Rilatoj inter objektoj ne estas stokitaj en atributoj de gepatraj unuoj, sed estas aparta speco de objekto.
В Datuma Trezorejo tiaj ligaj tabeloj estas nomitaj ligilokaj en Ankro-Modelo - kravato. Unuavide, ili estas tre similaj, kvankam iliaj diferencoj ne finiĝas per la nomo (kiu estos diskutita sube). En ambaŭ arkitekturoj, ligotabeloj povas ligi ajna nombro da estaĵoj (ne nepre 2).
Ĉi tiu redundo, unuavide, provizas gravan flekseblecon por modifoj. Tia strukturo fariĝas tolerema ne nur al ŝanĝoj en la kardinaleco de ekzistantaj ligiloj, sed ankaŭ al aldono de novaj - se nun ĉekpozicio ankaŭ havas ligon al la kasisto, kiu trarompis ĝin, la aspekto de tia ligo simple estos. fariĝi aldonaĵo super ekzistantaj tabloj sen tuŝi iujn ajn ekzistantajn objektojn kaj procezojn.
2. Duobligo de datumoj
La dua problemo solvita per flekseblaj arkitekturoj estas malpli evidenta kaj estas eneca en la unua loko. SCD2-tipaj mezuradoj (malrapide ŝanĝiĝantaj dimensioj de la dua tipo), kvankam ne nur ili.
En klasika magazeno, dimensio estas tipe tablo kiu enhavas anstataŭan ŝlosilon (kiel PK) kaj aron de komercaj ŝlosiloj kaj atributoj en apartaj kolumnoj.
Se dimensio subtenas versionadon, limoj de versivalideco estas aldonitaj al la norma aro de kampoj, kaj por unu vico en la fonto, pluraj versioj aperas en la deponejo (unu por ĉiu ŝanĝo en versionitaj atributoj).
Se dimensio enhavas almenaŭ unu ofte ŝanĝantan versionitan atributon, la nombro da versioj de tia dimensio estos impona (eĉ se la ceteraj atributoj ne estas versionitaj aŭ neniam ŝanĝiĝas), kaj se ekzistas pluraj tiaj atributoj, la nombro da versioj povas kreskas eksponente de ilia nombro. Ĉi tiu dimensio povas okupi signifan kvanton da diskospaco, kvankam multe de la datumoj kiujn ĝi stokas estas simple duplikatoj de neŝanĝeblaj atributvaloroj de aliaj vicoj.
Samtempe, ĝi ankaŭ estas tre ofte uzata malnormaligo — iuj atributoj estas intence konservitaj kiel valoro, kaj ne kiel ligo al konsultlibro aŭ alia dimensio. Ĉi tiu aliro akcelas datuman aliron, reduktante la nombron da kuniĝoj dum aliro al dimension.
Tipe ĉi tio kondukas al la sama informo estas konservita samtempe en pluraj lokoj. Ekzemple, informoj pri la loĝregiono kaj la kategorio de la kliento povas esti samtempe konservitaj en la dimensioj "Kliento" kaj la faktoj "Aĉeto", "Liveraĵo" kaj "Vokaj Centro-Vokoj", same kiel en la "Kliento - Kliento-Manaĝero". ” ligtabelo.
Ĝenerale, la supre priskribita validas por regulaj (ne-versiaj) dimensioj, sed en versionitaj ili povas havi malsaman skalon: la apero de nova versio de objekto (precipe retrorigarde) kondukas ne nur al la ĝisdatigo de ĉiuj rilataj. tabeloj, sed al la kaskada aspekto de novaj versioj de rilataj objektoj - kiam Tabelo 1 estas uzata por konstrui Tabelon 2, kaj Tablo 2 estas uzata por konstrui Tabelon 3, ktp. Eĉ se ne unu atributo de Tablo 1 estas implikita en la konstruado de Tabelo 3 (kaj aliaj atributoj de Tablo 2 akiritaj de aliaj fontoj estas implikitaj), versionado de ĉi tiu konstruo minimume kondukos al plia ŝarĝo, kaj maksimume al ekstra. versioj en Tabelo 3. kiu tute ne rilatas al ĝi, kaj pli malsupre en la ĉeno.
3. Nelinia komplekseco de relaboro
Samtempe, ĉiu nova butikfasado konstruita surbaze de alia pliigas la nombron da lokoj kie datumoj povas "diverĝi" kiam ŝanĝoj estas faritaj al la ETL. Ĉi tio, siavice, kondukas al pliigo de la komplekseco (kaj daŭro) de ĉiu posta revizio.
Se la supre priskribas sistemojn kun malofte modifitaj ETL-procezoj, vi povas vivi en tia paradigmo - vi nur bezonas certigi, ke novaj modifoj estas ĝuste faritaj al ĉiuj rilataj objektoj. Se revizioj okazas ofte, la verŝajneco de hazarde "mankas" pluraj ligoj signife pliiĝas.
Se, krome, ni konsideras, ke "versionita" ETL estas signife pli komplika ol "ne-versiita", fariĝas sufiĉe malfacile eviti erarojn kiam ofte ĝisdatigas ĉi tiun tutan instalaĵon.
Stoki objektojn kaj atributojn en Data Vault kaj Anchor Model
La aliro proponita de la verkintoj de flekseblaj arkitekturoj povas esti formulita jene:
Necesas apartigi tion, kio ŝanĝiĝas de tio, kio restas sama. Tio estas, stoki ŝlosilojn aparte de atributoj.
Tamen oni ne konfuzu ne versionita atributo kun senŝanĝe: la unua ne konservas la historion de ĝiaj ŝanĝoj, sed povas ŝanĝiĝi (ekzemple, kiam oni korektas eraron de enigo aŭ ricevas novajn datumojn); la dua neniam ŝanĝiĝas.
Vidpunktoj malsamas pri tio, kio precize povas esti konsiderata neŝanĝebla en la Datuma Trezorejo kaj la Ankora Modelo.
El arkitektura vidpunkto Datuma Trezorejo, povas esti konsiderata senŝanĝa tuta aro da ŝlosiloj - natura (TIN de la organizo, produktokodo en la fontsistemo, ktp.) kaj surogato. En ĉi tiu kazo, la ceteraj atributoj povas esti dividitaj en grupojn laŭ la fonto kaj/aŭ ofteco de ŝanĝoj kaj Konservu apartan tablon por ĉiu grupo kun sendependa aro de versioj.
En la paradigmo Ankro-Modelo konsiderata senŝanĝa nur anstataŭa ŝlosilo esenco. Ĉio alia (inkluzive de naturaj ŝlosiloj) estas nur speciala kazo de ĝiaj atributoj. Kie ĉiuj atributoj estas sendependaj unu de la alia defaŭlte, do por ĉiu eco a aparta tablo.
В Datuma Trezorejo tabeloj enhavantaj entoŝlosilojn estas nomitaj Hubami. Naboj ĉiam enhavas fiksan aron de kampoj:
- Naturaj Entaj Ŝlosiloj
- Surogata ŝlosilo
- Ligo al fonto
- Registru aldonanta tempon
Afiŝoj en Hubs neniam ŝanĝi kaj ne havas versiojn. Ekstere, naboj estas tre similaj al ID-mapaj tabeloj uzataj en iuj sistemoj por generi surogatojn, tamen oni rekomendas uzi haŝiŝon de aro de komercaj ŝlosiloj kiel anstataŭantoj en Data Vault. Ĉi tiu aliro simpligas ŝarĝi rilatojn kaj atributojn de fontoj (ne necesas aliĝi al la nabo por akiri surogaton, nur kalkulu la haŝon de natura ŝlosilo), sed povas kaŭzi aliajn problemojn (rilatajn, ekzemple, al kolizioj, kazo kaj ne-preseblaj). signoj en ĉenklavoj, ktp. .p.), tial ĝi ne estas ĝenerale akceptita.
Ĉiuj aliaj entaj atributoj estas konservitaj en specialaj tabeloj nomitaj Satelitoj. Unu nabo povas havi plurajn satelitojn stokantajn malsamajn arojn de atributoj.
La distribuo de atributoj inter satelitoj okazas laŭ la principo komuna ŝanĝo — en unu satelito ne-versiaj atributoj povas esti stokitaj (ekzemple naskiĝdato kaj SNILS por individuo), en alia - malofte ŝanĝantaj versioj (ekzemple, familia nomo kaj pasporta numero), en la tria - ofte ŝanĝantaj. (ekzemple, livera adreso, kategorio, dato de lasta mendo, ktp.). En ĉi tiu kazo, versionado estas efektivigita je la nivelo de individuaj satelitoj, kaj ne de la ento kiel tuto, do estas konsilinde distribui atributojn tiel ke la intersekco de versioj ene de unu satelito estu minimuma (kio reduktas la totalan nombron de stokitaj versioj). ).
Ankaŭ, por optimumigi la datumŝarĝadprocezon, atributoj akiritaj de diversaj fontoj ofte estas inkluditaj en individuaj satelitoj.
Satelitoj komunikas kun la Nabo per fremda ŝlosilo (kiu respondas al 1-al-multaj kardinaleco). Ĉi tio signifas, ke pluraj atributaj valoroj (ekzemple, pluraj kontaktaj telefonnumeroj por unu kliento) estas subtenataj de ĉi tiu "defaŭlta" arkitekturo.
В Ankro-Modelo tabeloj kiuj stokas ŝlosilojn estas nomitaj Ankroj. Kaj ili konservas:
- Nur surogataj ŝlosiloj
- Ligo al fonto
- Registru aldonanta tempon
Naturaj ŝlosiloj el la vidpunkto de la Ankora Modelo estas konsiderataj ordinaraj atributoj. Ĉi tiu opcio povas ŝajni pli malfacile komprenebla, sed ĝi donas multe pli da amplekso por identigi la objekton.
Ekzemple, se datumoj pri la sama ento povas veni de malsamaj sistemoj, ĉiu el kiuj uzas sian propran naturan ŝlosilon. En Data Vault, tio povas konduki al sufiĉe ĝenaj strukturoj de pluraj naboj (unu per fonto + unueciga majstra versio), dum en la Anchor-modelo, la natura ŝlosilo de ĉiu fonto falas en sian propran atributon kaj povas esti uzata dum ŝarĝo sendepende de ĉiuj aliaj.
Sed estas ankaŭ unu insida punkto ĉi tie: se atributoj de malsamaj sistemoj estas kombinitaj en unu ento, plej verŝajne estas iuj. reguloj de "gluado", per kiu la sistemo devas kompreni ke rekordoj de malsamaj fontoj egalrilatas al unu kazo de la unuo.
В Datuma Trezorejo ĉi tiuj reguloj plej verŝajne determinos la formadon "surogata nabo" de la majstra ento kaj neniel influas la Nabojn, kiuj stokas naturajn fontŝlosilojn kaj iliajn originalajn atributojn. Se iam la kunfandaj reguloj ŝanĝiĝas (aŭ la atributoj per kiuj ĝi estas farita estas ĝisdatigitaj), sufiĉos reformatigi la anstataŭajn nabojn.
В Ankromodelo tia ento plej verŝajne estos konservita en la sola ankro. Ĉi tio signifas, ke ĉiuj atributoj, negrave de kiu fonto ili venas, estos ligitaj al la sama anstataŭanto. Apartigi erare kunfanditajn rekordojn kaj, ĝenerale, kontroli la gravecon de kunfandiĝo en tia sistemo povas esti multe pli malfacila, precipe se la reguloj estas sufiĉe kompleksaj kaj ŝanĝiĝas ofte, kaj la sama atributo povas esti akirita de malsamaj fontoj (kvankam ĝi certe estas ebla, ĉar ĉiu la atribua versio konservas ligon al sia fonto).
Ĉiukaze, se via sistemo devas efektivigi la funkciecon deduplikado, kunfandado de rekordoj kaj aliaj MDM-elementoj, indas atenti precipe la aspektojn de stokado de naturaj ŝlosiloj en lertaj metodaroj. Verŝajnas, ke la pli dika Data Vault-dezajno subite estos pli sekura laŭ kunfandaj eraroj.
Ankromodelo ankaŭ disponigas kroman objektospecon nomitan Nodo ĝi estas esence speciala degenerita tipo de ankro, kiu povas enhavi nur unu atributon. La nodoj estas supozeble uzataj por stoki platajn adresarojn (ekzemple, sekso, edzeca stato, klientserva kategorio ktp.). Male al la Ankro, la Nodo ne havas rilatajn atributajn tabelojn, kaj ĝia nura atributo (nomo) estas ĉiam konservita en la sama tabelo kun la ŝlosilo. Nodoj estas ligitaj al Ankroj per ligaj tabloj (Tie) en la sama maniero kiel Ankroj estas ligitaj unu al la alia.
Ne ekzistas klara opinio pri la uzo de Nodoj. Ekzemple, , kiu aktive antaŭenigas la uzon de la Ankro-Modelo en Rusio, opinias (ne senracie) ke por ne unu konsultlibro oni povas certe konstati, ke ĝi ĉiam estos senmova kaj ununivela, do estas pli bone tuj uzi plenrajtan Ankron por ĉiuj objektoj.
Alia grava diferenco inter Data Vault kaj la Anchor-modelo estas la havebleco atributoj de ligoj:
В Datuma Trezorejo Ligiloj estas la samaj plenrajtaj objektoj kiel Hubs, kaj povas havi propraj atributoj. la Ankromodelo Ligiloj estas uzataj nur por konekti Ankrojn kaj ne povas havi siajn proprajn atributojn. Tiu diferenco rezultigas signife malsamajn modeligajn alirojn faktoj, pri kiu oni diskutos plu.
Stokado de faktoj
Antaŭ tio, ni parolis ĉefe pri mezurmodelado. La faktoj estas iom malpli klaraj.
В Datuma Trezorejo tipa objekto por stoki faktojn estas Ligo, en kies satelitoj estas aldonitaj veraj indikiloj.
Ĉi tiu aliro ŝajnas intuicia. Ĝi disponigas facilan aliron al la analizitaj indikiloj kaj ĝenerale similas al tradicia faktabelo (nur la indikiloj estas konservitaj ne en la tabelo mem, sed en la "najbara" tabelo). Sed ekzistas ankaŭ faŭltoj: unu el la tipaj modifoj de la modelo - pligrandigo de la faktoŝlosilo - necesigas aldonante novan fremdan ŝlosilon al Link. Kaj ĉi tio, siavice, "rompas" la modularecon kaj eble kaŭzas la bezonon de modifoj al aliaj objektoj.
В Ankromodelo Konekto ne povas havi siajn proprajn atributojn, do ĉi tiu aliro ne funkcios - absolute ĉiuj atributoj kaj indikiloj devas esti ligitaj al unu specifa ankro. La konkludo el tio estas simpla - Ĉiu fakto ankaŭ bezonas sian propran ankron. Por iuj el tio, kion ni kutimas percepti kiel faktojn, tio povas aspekti natura - ekzemple, la fakto de aĉeto povas esti perfekte reduktita al la objekto "mendo" aŭ "kvitanco", viziti retejon al sesio, ktp. Sed estas ankaŭ faktoj, por kiuj ne estas tiel facile trovi tian naturan "portilon" - ekzemple restaĵojn de varoj en magazenoj komence de ĉiu tago.
Sekve, problemoj kun modulareco dum vastigado de fakŝlosilo en la Ankro-modelo ne ekestas (sufiĉas simple aldoni novan Rilaton al la ekvivalenta Ankro), sed dizajni modelon por montri faktojn estas malpli malambigua; "artefaritaj" Ankroj povas aperi. kiuj montras la komercan objektomodelon en neklara maniero.
Kiel fleksebleco estas atingita
La rezulta konstruo en ambaŭ kazoj enhavas signife pli da tabelojol tradicia mezurado. Sed ĝi povas preni signife malpli da diskospaco kun la sama aro de versionitaj atributoj kiel la tradicia dimensio. Kompreneble, ĉi tie ne estas magio - ĉio temas pri normaligo. Distribuante atributojn tra Satelitoj (en la Datuma Trezorejo) aŭ individuaj tabeloj (Ankora Modelo), ni reduktas (aŭ tute forigas) duobligo de valoroj de iuj atributoj ŝanĝante aliajn.
Por Datuma Trezorejo la gajnoj dependos de la distribuo de atributoj inter la Satelitoj, kaj por Ankromodelo — estas preskaŭ rekte proporcia al la averaĝa nombro da versioj per mezurobjekto.
Tamen, spacŝparoj estas grava, sed ne la ĉefa avantaĝo de stokado de atributoj aparte. Kune kun aparta stokado de rilatoj, ĉi tiu aliro faras la vendejon modula dezajno. Ĉi tio signifas, ke aldonante ambaŭ individuajn atributojn kaj tutajn novajn temojn en tia modelo aspektas superkonstruaĵo super ekzistanta aro de objektoj sen ŝanĝi ilin. Kaj ĝuste ĉi tio fleksigas la priskribitajn metodikojn.
Ĉi tio ankaŭ similas la transiron de pecoproduktado al amasproduktado - se en la tradicia aliro ĉiu tablo de la modelo estas unika kaj postulas specialan atenton, tiam en flekseblaj metodaroj ĝi jam estas aro de normaj "partoj". Unuflanke, estas pli da tabloj, kaj la procezoj de ŝarĝo kaj reakiro de datumoj devus aspekti pli komplikaj. Aliflanke, ili fariĝas tipa. Kio signifas ke povas esti aŭtomatigita kaj metadatenoj movita. La demando "kiel ni metos ĝin?", kies respondo povus okupi gravan parton de la laboro pri desegnado de plibonigoj, nun simple ne valoras ĝin (same kiel la demando pri la efiko de ŝanĝi la modelon sur laborprocezoj. ).
Ĉi tio ne signifas, ke analizistoj tute ne estas bezonataj en tia sistemo - iu ankoraŭ devas labori tra la aro da objektoj kun atributoj kaj eltrovi kie kaj kiel ŝargi ĉion. Sed la kvanto de laboro, same kiel la verŝajneco kaj kosto de eraro, estas signife reduktitaj. Kaj en la analiza stadio kaj dum la evoluo de ETL, kiu en signifa parto povas esti reduktita al redaktado de metadatenoj.
Malluma flanko
Ĉio ĉi-supra faras ambaŭ alirojn vere flekseblaj, teknologie progresintaj kaj taŭgaj por ripeta plibonigo. Kompreneble, estas ankaŭ "barelo en la ungvento", pri kiu mi pensas, ke vi jam povas diveni.
Datenmalkomponado, kiu subestas la modularecon de flekseblaj arkitekturoj, kondukas al pliigo de la nombro da tabloj kaj, sekve, superkostoj al kuniĝoj dum specimenigo. Por simple akiri ĉiujn atributojn de dimensio, en klasika vendejo sufiĉas unu elekto, sed fleksebla arkitekturo postulos tutan serion da kuniĝoj. Krome, se ĉiuj ĉi tiuj kuniĝoj por raportoj povas esti skribitaj anticipe, tiam analizistoj, kiuj kutimas skribi SQL permane, suferos duoble.
Estas pluraj faktoj, kiuj faciligas ĉi tiun situacion:
Kiam oni laboras kun grandaj dimensioj, ĉiuj ĝiaj atributoj preskaŭ neniam estas uzataj samtempe. Ĉi tio signifas, ke eble estas malpli da kuniĝoj ol ŝajnas unuavide ĉe la modelo. Data Vault ankaŭ povas enkalkuli la atendatan frekvencon de kundivido dum asignado de atributoj al satelitoj. Samtempe, Naboj aŭ Ankroj mem estas bezonataj ĉefe por generi kaj mapadi surogatojn ĉe la ŝarĝa stadio kaj malofte estas uzataj en demandoj (ĉi tio validas precipe por Ankroj).
Ĉiuj kuniĝoj estas per ŝlosilo. Krome, pli "kunpremita" maniero konservi datumojn reduktas la superkompeton de skanado de tabeloj kie ĝi estas bezonata (ekzemple, kiam oni filtras laŭ atributvaloro). Ĉi tio povas konduki al la fakto, ke specimenigo de normaligita datumbazo kun amaso da kuniĝoj estos eĉ pli rapida ol skanado de unu peza dimensio kun multaj versioj por vico.
Ekzemple, ĉi tie en La artikolo enhavas detalan komparan teston de la agado de la modelo Anchor kun specimeno de unu tablo.
Multe dependas de la motoro. Multaj modernaj platformoj havas internajn kunigajn optimumigajn mekanismojn. Ekzemple, MS SQL kaj Oracle povas "salti" kuniĝojn al tabeloj se iliaj datenoj ne estas uzataj ie ajn krom por aliaj kuniĝoj kaj ne influas la finan elekton (tablo/kunigelimino), kaj MPP Vertica. , pruvis esti bonega motoro por la Ankro-Modelo, donita iun mana optimumigo de la demanda plano. Aliflanke, konservi la Ankro-Modelon, ekzemple, en Klaku Domo, kiu havas limigitan aligsubtenon, ankoraŭ ne aspektas kiel tre bona ideo.
Krome, por ambaŭ arkitekturoj ekzistas specialaj movoj, igante datuman aliron pli facila (kaj de demanda rendimento vidpunkto kaj por finaj uzantoj). Ekzemple, Punkto-En-Tempo-tabeloj en Data Vault aŭ specialaj tabelaj funkcioj en la Anchor-modelo.
Tuta
La ĉefa esenco de la konsideritaj flekseblaj arkitekturoj estas la modulareco de ilia "dezajno".
Estas ĉi tiu propraĵo kiu permesas:
- Post iu komenca preparo rilate al metadatenoj-deplojo kaj verkado de bazaj ETL-algoritmoj, rapide havigu al la kliento la unuan rezulton en la formo de paro da raportoj enhavantaj datumojn de nur kelkaj fontobjektoj. Ne necesas tute pripensi (eĉ ĉe la supra nivelo) la tutan objektomodelon.
- Datuma modelo povas ekfunkcii (kaj esti utila) kun nur 2-3 objektoj, kaj poste kreski iom post iom (pri la Ankora modelo Nikolai bela komparo kun micelio).
- Plej multaj plibonigoj, inkluzive de vastigado de la temo kaj aldono de novaj fontoj ne influas ekzistantan funkciecon kaj ne prezentas riskon rompi ion, kio jam funkcias.
- Danke al malkomponiĝo en normajn elementojn, ETL-procezoj en tiaj sistemoj aspektas same, ilia skribo pruntedonas al algoritmo kaj, finfine, aŭtomatigo.
La prezo de ĉi tiu fleksebleco estas agado. Ĉi tio ne signifas, ke estas neeble atingi akcepteblan agadon sur tiaj modeloj. Pli ofte ol ne, vi simple bezonas pli da penado kaj atento al detaloj por atingi la metrikojn, kiujn vi volas.
Приложения
Tipoj de entoj Datuma Trezorejo
Pliaj informoj pri Data Vault:
Tipoj de entoj Ankro-Modelo
Pliaj detaloj pri Anchor Model:
Resuma tabelo kun komunaj trajtoj kaj diferencoj de la pripensitaj aliroj:
fonto: www.habr.com