Dezvoltarea unei instalații de depozitare este o întreprindere lungă și serioasă.
O mare parte din viața unui proiect depinde de cât de bine sunt gândite modelul obiectului și structura de bază la început.
Abordarea general acceptată a fost și rămâne diferite variante de combinare a schemei stelare cu a treia formă normală. De regulă, conform principiului: date inițiale - 3NF, vitrine - stea. Această abordare, testată în timp și susținută de o cantitate mare de cercetări, este primul (și uneori singurul) lucru care vine în minte unui specialist DWH cu experiență atunci când se gândește la cum ar trebui să arate un depozit analitic.
Pe de altă parte, afacerile în general și cerințele clienților în special tind să se schimbe rapid, iar datele tind să crească atât „în profunzime”, cât și „în lățime”. Și aici apare principalul dezavantaj al unei stele - limitat flexibilitate.
Și dacă în viața ta liniștită și confortabilă ca dezvoltator DWH brusc:
- sarcina a apărut „să facem măcar ceva repede și apoi vom vedea”;
- a apărut un proiect în dezvoltare rapidă, cu conectarea de noi surse și reelaborarea modelului de afaceri cel puțin o dată pe săptămână;
- a apărut un client care nu are idee cum ar trebui să arate sistemul și ce funcții ar trebui să îndeplinească în cele din urmă, dar este gata să experimenteze și să perfecționeze constant rezultatul dorit, în timp ce se apropie constant de el;
- Managerul de proiect a venit cu vestea bună: „Și acum avem agilitate!”
Sau dacă sunteți doar interesat să aflați cum altfel puteți construi spații de depozitare - bine ați venit la tăiere!
Ce înseamnă „flexibilitate”?
Mai întâi, să definim ce proprietăți trebuie să aibă un sistem pentru a fi numit „flexibil”.
Separat, merită menționat faptul că proprietățile descrise ar trebui să se refere în mod specific la sistem, nu să proces dezvoltarea acestuia. Prin urmare, dacă ați vrut să citiți despre Agile ca metodologie de dezvoltare, este mai bine să citiți și alte articole. De exemplu, chiar acolo, pe Habré, există o mulțime de materiale interesante (cum ar fi и Și ).
Acest lucru nu înseamnă că procesul de dezvoltare și structura depozitului de date nu sunt complet legate. În general, ar trebui să fie semnificativ mai ușor să dezvoltați un depozit Agile pentru o arhitectură agilă. Cu toate acestea, în practică, mai des există opțiuni cu dezvoltarea Agile a clasicului DWH conform Kimbal și DataVault - conform Waterfall, decât coincidențe fericite de flexibilitate în cele două forme pe un singur proiect.
Deci, ce capabilități ar trebui să aibă stocarea flexibilă? Există trei puncte aici:
- Livrare devreme și livrare rapidă - aceasta înseamnă că, în mod ideal, primul rezultat al afacerii (de exemplu, primele rapoarte de lucru) ar trebui să fie obținut cât mai curând posibil, adică chiar înainte ca întregul sistem să fie proiectat și implementat complet. În plus, fiecare revizuire ulterioară ar trebui să dureze cât mai puțin timp posibil.
- Rafinament iterativ - aceasta înseamnă că fiecare îmbunătățire ulterioară ar trebui, în mod ideal, să nu afecteze funcționalitatea care funcționează deja. Acest moment devine adesea cel mai mare coșmar pentru proiectele mari - mai devreme sau mai târziu, obiectele individuale încep să dobândească atât de multe conexiuni încât devine mai ușor să repeți complet logica într-o copie din apropiere decât să adaugi un câmp la un tabel existent. Și dacă sunteți surprins că analiza impactului îmbunătățirilor asupra obiectelor existente poate dura mai mult timp decât îmbunătățirile în sine, cel mai probabil nu ați lucrat încă cu depozite mari de date în domeniul bancar sau telecomunicații.
- Adaptare constantă la cerințele în schimbare ale afacerii - structura generală a obiectului ar trebui proiectată nu doar ținând cont de posibila extindere, ci cu așteptarea că direcția următoarei extinderi nu ar putea fi nici măcar visată în faza de proiectare.
Și da, îndeplinirea tuturor acestor cerințe într-un singur sistem este posibilă (desigur, în anumite cazuri și cu unele rezerve).
Mai jos voi lua în considerare două dintre cele mai populare metodologii de design agil pentru depozitele de date - Model ancoră и Seif de date. Sunt lăsate în afara parantezei tehnici atât de excelente precum, de exemplu, EAV, 6NF (în forma sa pură) și tot ce ține de soluțiile NoSQL - nu pentru că ar fi cumva mai proaste și nici măcar pentru că în acest caz articolul ar amenința să dobândească volumul dizertatorului mediu. Doar că toate acestea se referă la soluții dintr-o clasă puțin diferită - fie la tehnici pe care le poți folosi în cazuri specifice, indiferent de arhitectura generală a proiectului tău (cum ar fi EAV), fie la nivel global alte paradigme de stocare a informațiilor (cum ar fi bazele de date grafice). și alte opțiuni NoSQL).
Probleme ale abordării „clasice” și soluțiile acestora în metodologii flexibile
Prin abordare „clasică” mă refer la vechea stea bună (indiferent de implementarea specifică a straturilor subiacente, să mă ierte adepții lui Kimball, Inmon și CDM).
1. Cardinalitatea rigidă a conexiunilor
Acest model se bazează pe o împărțire clară a datelor în Dimensiune и fapte. Și asta, la naiba, este logic - la urma urmei, analiza datelor în majoritatea covârșitoare a cazurilor se rezumă la analiza anumitor indicatori numerici (fapte) în anumite secțiuni (dimensiuni).
În acest caz, conexiunile între obiecte sunt stabilite sub formă de relații între tabele folosind o cheie străină. Acest lucru pare destul de natural, dar duce imediat la prima limitare a flexibilității - definirea strictă a cardinalității conexiunilor.
Aceasta înseamnă că, în faza de proiectare a tabelului, trebuie să determinați cu precizie pentru fiecare pereche de obiecte înrudite dacă acestea se pot relaționa cât mai mulți-la-mulți sau doar 1-la-mulți și „în ce direcție”. Aceasta determină direct ce tabel va avea cheia primară și care va avea cheia externă. Schimbarea acestei atitudini atunci când se primesc noi cerințe va duce cel mai probabil la o reelaborare a bazei.
De exemplu, atunci când proiectați obiectul „chitanță de numerar”, dumneavoastră, bazându-vă pe jurămintele departamentului de vânzări, ați stabilit posibilitatea de acțiune o promoție pentru mai multe poziții de cec (dar nu invers):
Și după ceva timp, colegii au introdus o nouă strategie de marketing în care pot acționa pe aceeași poziție mai multe promoții în același timp. Și acum trebuie să modificați tabelele prin separarea relației într-un obiect separat.
(Toate obiectele derivate în care se alătură verificarea de promovare acum trebuie să fie îmbunătățite).
Relații în Data Vault și Anchor Model
Evitarea acestei situații s-a dovedit a fi destul de simplă: nu trebuie să aveți încredere în departamentul de vânzări pentru a face acest lucru. toate conexiunile sunt stocate inițial în tabele separate și procesează-l cât mai multe-la-mulți.
S-a propus această abordare Dan Linstedt ca parte a paradigmei Seif de date și pe deplin susținută Lars Rönnbäck в Model Ancoră.
Ca rezultat, obținem prima trăsătură distinctivă a metodologiilor flexibile:
Relațiile dintre obiecte nu sunt stocate în atributele entităților părinte, ci sunt un tip separat de obiect.
В Seif de date astfel de tabele de legătură sunt numite Link, și în Model Ancoră - Cravată. La prima vedere, sunt foarte asemănătoare, deși diferențele lor nu se termină cu denumirea (care va fi discutată mai jos). În ambele arhitecturi, tabelele de legături se pot lega orice număr de entităţi (nu neapărat 2).
Această redundanță, la prima vedere, oferă o flexibilitate semnificativă pentru modificări. O astfel de structură devine tolerantă nu numai la modificările cardinalității legăturilor existente, ci și la adăugarea altora noi - dacă acum o poziție de cec are și o legătură cu casieria care a spart-o, apariția unei astfel de legături va pur și simplu deveniți un supliment peste tabelele existente fără a afecta obiectele și procesele existente.
2. Dublarea datelor
A doua problemă rezolvată de arhitecturile flexibile este mai puțin evidentă și este inerentă în primul rând. măsurători de tip SCD2 (schimbând încet dimensiunile celui de-al doilea tip), deși nu numai ele.
Într-un depozit clasic, o dimensiune este de obicei un tabel care conține o cheie surogat (sub formă de PK) și un set de chei de afaceri și atribute în coloane separate.
Dacă o dimensiune acceptă versiunea, limitele de valabilitate a versiunii sunt adăugate la setul standard de câmpuri, iar pentru un rând din sursă apar mai multe versiuni în depozit (una pentru fiecare modificare a atributelor versionate).
Dacă o dimensiune conține cel puțin un atribut cu versiuni care se schimbă frecvent, numărul de versiuni ale unei astfel de dimensiuni va fi impresionant (chiar dacă atributele rămase nu sunt versionate sau nu se modifică niciodată), iar dacă există mai multe astfel de atribute, numărul de versiuni poate fi cresc exponențial din numărul lor. Această dimensiune poate ocupa o cantitate semnificativă de spațiu pe disc, deși multe dintre datele pe care le stochează sunt pur și simplu duplicate ale valorilor de atribute imuabile de pe alte rânduri.
În același timp, este și foarte des folosit denormalizare — unele atribute sunt stocate în mod intenționat ca valoare și nu ca link către o carte de referință sau o altă dimensiune. Această abordare accelerează accesul la date, reducând numărul de îmbinări la accesarea unei dimensiuni.
De obicei, acest lucru duce la aceeași informație este stocată simultan în mai multe locuri. De exemplu, informațiile despre regiunea de reședință și categoria clientului pot fi stocate simultan în dimensiunile „Client” și în datele „Achiziție”, „Livrare” și „Apeluri la centru de apel”, precum și în „Client - Manager de clienți”. ” tabel de linkuri.
În general, cele descrise mai sus se aplică dimensiunilor obișnuite (neversiuni), dar în cele cu versiuni pot avea o scară diferită: apariția unei noi versiuni a unui obiect (mai ales retrospectiv) duce nu numai la actualizarea tuturor tabele, dar la apariția în cascadă a noilor versiuni ale obiectelor înrudite - când Tabelul 1 este folosit pentru a construi Tabelul 2 și Tabelul 2 este folosit pentru a construi Tabelul 3 etc. Chiar dacă nici un singur atribut din Tabelul 1 nu este implicat în construcția Tabelului 3 (și sunt implicate alte atribute din Tabelul 2 obținute din alte surse), versiunea acestei construcție va duce cel puțin la supraîncărcare suplimentară și la maximum la un plus. versiuni din Tabelul 3. care nu are nimic de-a face cu asta, și mai jos în lanț.
3. Complexitatea neliniară a reprelucrării
În același timp, fiecare nouă vitrină construită pe baza alteia crește numărul de locuri în care datele pot „diverge” atunci când se fac modificări la ETL. Acest lucru, la rândul său, duce la o creștere a complexității (și a duratei) fiecărei revizuiri ulterioare.
Dacă cele de mai sus descriu sisteme cu procese ETL rar modificate, puteți trăi într-o astfel de paradigmă - trebuie doar să vă asigurați că noile modificări sunt făcute corect tuturor obiectelor asociate. Dacă revizuirile apar frecvent, probabilitatea de a „lips” accidental mai multe conexiuni crește semnificativ.
Dacă, în plus, ținem cont de faptul că ETL „versionizat” este semnificativ mai complicat decât cel „neversionat”, devine destul de dificil să evitați greșelile atunci când actualizați frecvent această întreagă facilitate.
Stocarea obiectelor și atributelor în Data Vault și Anchor Model
Abordarea propusă de autorii arhitecturilor flexibile poate fi formulată astfel:
Este necesar să se separe ceea ce se schimbă de ceea ce rămâne același. Adică stocați cheile separat de atribute.
Totuși, nu trebuie să confundăm neversiune atribut cu neschimbat: primul nu stochează istoricul modificărilor sale, dar se poate modifica (de exemplu, la corectarea unei erori de introducere sau la primirea de date noi); al doilea nu se modifică niciodată.
Punctele de vedere diferă cu privire la ceea ce poate fi considerat imuabil în Data Vault și Anchor Model.
Din punct de vedere arhitectural Seif de date, poate fi considerat neschimbat întreg set de chei - natural (TIN al organizației, cod de produs în sistemul sursă etc.) și surogat. În acest caz, atributele rămase pot fi împărțite în grupuri în funcție de sursa și/sau frecvența modificărilor și Mențineți un tabel separat pentru fiecare grup cu un set independent de versiuni.
În paradigmă Model Ancoră considerat neschimbat doar cheie surogat esență. Orice altceva (inclusiv cheile naturale) este doar un caz special al atributelor sale. în care toate atributele sunt independente unele de altele în mod implicit, deci pentru fiecare atribut a masa separata.
В Seif de date sunt apelate tabele care conțin chei de entitate Hubami. Hub-urile conțin întotdeauna un set fix de câmpuri:
- Chei de entitate naturală
- Cheie surogat
- Link către sursă
- Înregistrați timpul de adăugare
Postări în Hub-uri nu se schimbă niciodată și nu au versiuni. În exterior, hub-urile sunt foarte asemănătoare cu tabelele de tip ID-map utilizate în unele sisteme pentru a genera surogate, cu toate acestea, se recomandă utilizarea unui hash dintr-un set de chei de afaceri ca surogate în Data Vault. Această abordare simplifică încărcarea relațiilor și a atributelor din surse (nu este nevoie să vă alăturați hub-ului pentru a obține un surogat, doar să calculați hash-ul unei chei naturale), dar poate provoca alte probleme (legate, de exemplu, de coliziuni, caz și non-printable). caractere din tastele șir, etc. .p.), prin urmare nu este acceptat în general.
Toate celelalte atribute de entitate sunt stocate în tabele speciale numite Sateliți. Un hub poate avea mai mulți sateliți care stochează seturi diferite de atribute.
Distribuția atributelor între sateliți are loc conform principiului schimbarea comună — într-un satelit pot fi stocate atribute fără versiune (de exemplu, data nașterii și SNILS pentru o persoană), în altul - cele cu versiuni rar schimbate (de exemplu, numele de familie și numărul pașaportului), în al treilea - cele care se schimbă frecvent (de exemplu, adresa de livrare, categoria, data ultimei comenzi etc.). În acest caz, versiunea se realizează la nivelul sateliților individuali, și nu a entității în ansamblu, deci este recomandabil să distribuiți atributele astfel încât intersecția versiunilor în cadrul unui satelit să fie minimă (ceea ce reduce numărul total de versiuni stocate). ).
De asemenea, pentru optimizarea procesului de încărcare a datelor, atributele obținute din diverse surse sunt adesea incluse în sateliții individuali.
Sateliții comunică cu Hub-ul prin cheie externă (care corespunde cardinalității 1-la-mulți). Aceasta înseamnă că mai multe valori ale atributelor (de exemplu, mai multe numere de telefon de contact pentru un client) sunt acceptate de această arhitectură „implicit”.
В Model Ancoră sunt apelate tabele care stochează chei Ancore. Și ei păstrează:
- Doar chei surogat
- Link către sursă
- Înregistrați timpul de adăugare
Sunt luate în considerare cheile naturale din punctul de vedere al Modelului Ancoră atribute obisnuite. Această opțiune poate părea mai dificil de înțeles, dar oferă mult mai mult spațiu pentru identificarea obiectului.
De exemplu, dacă datele despre aceeași entitate pot proveni din sisteme diferite, fiecare dintre ele folosind propria sa cheie naturală. În Data Vault, acest lucru poate duce la structuri destul de greoaie ale mai multor hub-uri (unul per sursă + o versiune master unificatoare), în timp ce în modelul Anchor, cheia naturală a fiecărei surse se încadrează în propriul atribut și poate fi utilizată la încărcare independent de toate celelalte.
Dar există și un punct insidios aici: dacă atributele din sisteme diferite sunt combinate într-o singură entitate, cel mai probabil există unele reguli de „lipire”, prin care sistemul trebuie să înțeleagă că înregistrările din surse diferite corespund unei singure instanțe a entității.
В Seif de date aceste reguli vor determina cel mai probabil formarea „hub surogat” al entității master și nu influențează în niciun fel Hub-urile care stochează cheile sursei naturale și atributele lor originale. Dacă la un moment dat regulile de fuziune se modifică (sau se actualizează atributele prin care se realizează), va fi suficient să reformatați hub-urile surogat.
В Model ancoră o astfel de entitate va fi cel mai probabil stocată în singura ancora. Aceasta înseamnă că toate atributele, indiferent de ce sursă provin, vor fi legate de același surogat. Separarea înregistrărilor fuzionate eronat și, în general, monitorizarea relevanței comasării într-un astfel de sistem poate fi mult mai dificilă, mai ales dacă regulile sunt destul de complexe și se modifică frecvent, iar același atribut poate fi obținut din surse diferite (deși cu siguranță este posibil, deoarece fiecare versiune a atributului păstrează un link către sursa sa).
În orice caz, dacă sistemul dumneavoastră ar trebui să implementeze funcționalitatea deduplicarea, fuzionarea înregistrărilor și alte elemente MDM, merită să acordați o atenție deosebită aspectelor de stocare a cheilor naturale în metodologiile agile. Este probabil ca designul mai voluminos Data Vault să fie brusc mai sigur în ceea ce privește erorile de îmbinare.
Model ancoră oferă, de asemenea, un tip de obiect suplimentar numit Nod este în esență specială tip degenerat de ancoră, care poate conține un singur atribut. Nodurile ar trebui să fie folosite pentru a stoca directoare plate (de exemplu, gen, stare civilă, categoria serviciului clienți etc.). Spre deosebire de Ancoră, Nodul nu are tabele de atribute asociate, iar singurul său atribut (nume) este întotdeauna stocat în același tabel cu cheia. Nodurile sunt conectate la Ancore prin tabele de legătură (Tie) în același mod în care Ancorele sunt conectate între ele.
Nu există o opinie clară cu privire la utilizarea Nodurilor. De exemplu, , care promovează în mod activ utilizarea modelului Anchor în Rusia, consideră (nu în mod nerezonabil) că pentru nici o singură carte de referință se poate afirma cu certitudine că mereu va fi statică și cu un singur nivel, deci este mai bine să utilizați imediat o Ancoră cu drepturi depline pentru toate obiectele.
O altă diferență importantă între Data Vault și modelul Anchor este disponibilitatea atributele conexiunilor:
В Seif de date Legăturile sunt aceleași obiecte cu drepturi depline ca și Hub-urile și le pot avea atribute proprii. În Model ancoră Legăturile sunt folosite numai pentru a conecta Ancore și nu pot avea propriile lor atribute. Această diferență are ca rezultat abordări semnificativ diferite de modelare fapte, despre care se va discuta mai departe.
Stocarea faptelor
Înainte de aceasta, am vorbit în principal despre modelarea măsurătorilor. Faptele sunt puțin mai puțin clare.
В Seif de date un obiect tipic pentru stocarea faptelor este Legătură, în ai căror sateliți se adaugă indicatori reali.
Această abordare pare intuitivă. Oferă acces facil la indicatorii analizați și este în general similar cu un tabel tradițional de fapte (doar indicatorii sunt stocați nu în tabelul în sine, ci în tabelul „învecinat”). Dar există și capcane: una dintre modificările tipice ale modelului - extinderea cheii de fapt - necesită adăugarea unei noi chei externe la Link. Și acest lucru, la rândul său, „rupe” modularitatea și provoacă potențial nevoia de modificări la alte obiecte.
В Model ancoră O conexiune nu poate avea propriile atribute, așa că această abordare nu va funcționa - absolut toate atributele și indicatorii trebuie să fie legați de o ancoră specifică. Concluzia de aici este simplă - Fiecare fapt are nevoie și de propria sa ancora. Pentru unele dintre ceea ce suntem obișnuiți să percepem ca fapte, acest lucru poate părea natural - de exemplu, faptul unei achiziții poate fi redus perfect la obiectul „comanda” sau „chitanța”, vizitarea unui site la o sesiune etc. Dar există și fapte pentru care nu este atât de ușor să găsești un astfel de „obiect purtător” natural - de exemplu, resturile de mărfuri în depozite la începutul fiecărei zile.
În consecință, problemele cu modularitatea la extinderea unei chei de fapt în modelul Anchor nu apar (este suficient să adăugați pur și simplu o nouă Relație la Ancora corespunzătoare), dar proiectarea unui model pentru a afișa fapte este mai puțin clară; pot apărea Ancore „artificiale” care afișează modelul obiectului de afaceri într-un mod neclar.
Cum se obține flexibilitatea
Construcția rezultată în ambele cazuri conține mult mai multe tabeledecât măsurarea tradițională. Dar poate dura mult mai puțin spațiu pe disc cu același set de atribute versionate ca și dimensiunea tradițională. Desigur, aici nu există magie - totul este despre normalizare. Prin distribuirea atributelor pe sateliți (în seiful de date) sau tabele individuale (modelul ancora), reducem (sau eliminăm complet) duplicarea valorilor unor atribute la modificarea altora.
Pentru Seif de date câștigurile vor depinde de distribuția atributelor între Sateliți și pentru Model ancoră — este aproape direct proporțional cu numărul mediu de versiuni per obiect de măsurat.
Cu toate acestea, economiile de spațiu sunt un avantaj important, dar nu principalul, al stocării atributelor separat. Împreună cu stocarea separată a relațiilor, această abordare face magazinul design modular. Aceasta înseamnă că adăugarea atât a atributelor individuale, cât și a unor domenii întregi noi într-un astfel de model arată ca suprastructură peste un set existent de obiecte fără a le schimba. Și tocmai asta face ca metodologiile descrise să fie flexibile.
Acest lucru seamănă și cu trecerea de la producția de piese la producția de masă - dacă în abordarea tradițională fiecare tabel al modelului este unic și necesită o atenție specială, atunci în metodologiile flexibile este deja un set de „piese” standard. Pe de o parte, există mai multe tabele, iar procesele de încărcare și preluare a datelor ar trebui să pară mai complicate. Pe de altă parte, ei devin tipic. Ceea ce înseamnă că poate exista automatizat și bazat pe metadate. Întrebarea „cum o vom așeza?”, răspunsul la care ar putea ocupa o parte semnificativă din munca de proiectare a îmbunătățirilor, pur și simplu nu merită acum (la fel și întrebarea despre impactul schimbării modelului asupra proceselor de lucru ).
Acest lucru nu înseamnă că analiștii nu sunt deloc necesari într-un astfel de sistem - cineva trebuie încă să lucreze prin setul de obiecte cu atribute și să descopere unde și cum să le încarce pe toate. Dar cantitatea de muncă, precum și probabilitatea și costul unei erori sunt reduse semnificativ. Atât în etapa de analiză, cât și în timpul dezvoltării ETL, care într-o parte semnificativă se poate reduce la editarea metadatelor.
Partea întunecată
Toate cele de mai sus fac ambele abordări cu adevărat flexibile, avansate din punct de vedere tehnologic și potrivite pentru îmbunătățirea iterativă. Desigur, există și un „butoi în unguent”, despre care cred că puteți deja ghici.
Descompunerea datelor, care stă la baza modularității arhitecturilor flexibile, duce la creșterea numărului de tabele și, în consecință, deasupra capului să se îmbină la eșantionare. Pentru a obține pur și simplu toate atributele unei dimensiuni, într-un magazin clasic este suficientă o selectare, dar o arhitectură flexibilă va necesita o serie întreagă de îmbinări. Mai mult, dacă toate aceste îmbinări pentru rapoarte pot fi scrise în avans, atunci analiștii care sunt obișnuiți să scrie manual SQL vor suferi de două ori.
Există mai multe fapte care ușurează această situație:
Când lucrați cu dimensiuni mari, toate atributele sale nu sunt aproape niciodată utilizate simultan. Aceasta înseamnă că pot exista mai puține unități decât pare la prima vedere asupra modelului. Data Vault poate lua în considerare și frecvența așteptată de partajare atunci când alocați atribute sateliților. În același timp, hub-urile sau ancorele în sine sunt necesare în primul rând pentru generarea și maparea surogatelor în etapa de încărcare și sunt rareori utilizate în interogări (acest lucru este valabil mai ales pentru ancore).
Toate uniunile sunt prin cheie. În plus, un mod mai „comprimat” de stocare a datelor reduce supraîncărcarea tabelelor de scanare acolo unde este necesar (de exemplu, la filtrarea după valoarea atributului). Acest lucru poate duce la faptul că eșantionarea dintr-o bază de date normalizată cu o grămadă de îmbinări va fi chiar mai rapidă decât scanarea unei dimensiuni grele cu mai multe versiuni pe rând.
De exemplu, aici în Articolul conține un test comparativ detaliat al performanței modelului Anchor cu un eșantion dintr-un tabel.
Depinde foarte mult de motor. Multe platforme moderne au mecanisme interne de optimizare a îmbinării. De exemplu, MS SQL și Oracle pot „sări” îmbinări la tabele dacă datele lor nu sunt folosite nicăieri, cu excepția altor îmbinări și nu afectează selecția finală (eliminare tabel/join) și MPP Vertica , sa dovedit a fi un motor excelent pentru modelul Anchor, având în vedere o anumită optimizare manuală a planului de interogare. Pe de altă parte, stocarea modelului Anchor, de exemplu, pe Click House, care are suport limitat pentru asociere, nu pare încă o idee foarte bună.
În plus, pentru ambele arhitecturi există miscari speciale, facilitând accesul la date (atât din punct de vedere al performanței interogărilor, cât și pentru utilizatorii finali). De exemplu, Tabele punct în timp în Data Vault sau funcții speciale ale tabelului în modelul Anchor.
În total
Esența principală a arhitecturilor flexibile considerate este modularitatea „designului” acestora.
Aceasta este proprietatea care permite:
- După câteva pregătiri inițiale legate de implementarea metadatelor și scrierea algoritmilor ETL de bază, oferi rapid clientului primul rezultat sub forma unor rapoarte care conțin date de la doar câteva obiecte sursă. Nu este necesar să se gândească complet (chiar la nivelul superior) întregului model de obiect.
- Un model de date poate începe să funcționeze (și să fie util) cu doar 2-3 obiecte și apoi cresc treptat (referitor la modelul Anchor Nikolai frumoasa comparatie cu miceliul).
- Cele mai multe îmbunătățiri, inclusiv extinderea domeniului de subiect și adăugarea de noi surse nu afectează funcționalitatea existentă și nu prezintă riscul de a rupe ceva care funcționează deja.
- Datorită descompunerii în elemente standard, procesele ETL din astfel de sisteme arată la fel, scrierea lor se pretează la algoritmizare și, în cele din urmă, automatizare.
Prețul acestei flexibilități este productivitate. Acest lucru nu înseamnă că este imposibil să obțineți performanțe acceptabile pe astfel de modele. Cel mai adesea, este posibil să aveți nevoie pur și simplu de mai mult efort și atenție la detalii pentru a obține valorile dorite.
aplicaţii
Tipuri de entități Seif de date
Mai multe informații despre Data Vault:
Tipuri de entități Model Ancoră
Mai multe detalii despre modelul Anchor:
Tabel rezumat cu caracteristici comune și diferențe ale abordărilor luate în considerare:
Sursa: www.habr.com