Vybudovanie skladovacieho zariadenia je dlhá a seriózna záležitosť.
Veľa v živote projektu závisí od toho, ako dobre sú na začiatku premyslené objektový model a základná štruktúra.
Všeobecne akceptovaným prístupom boli a zostávajú rôzne varianty kombinovania hviezdnej schémy s treťou normálnou formou. Spravidla podľa princípu: počiatočné údaje - 3NF, vitríny - hviezda. Tento prístup, overený časom a podporený veľkým množstvom výskumov, je prvá (a niekedy aj jediná) vec, ktorá skúsenému DWH špecialistovi napadne, keď uvažuje o tom, ako by malo vyzerať analytické úložisko.
Na druhej strane, podnikanie vo všeobecnosti a požiadavky zákazníkov obzvlášť majú tendenciu sa rýchlo meniť a údaje majú tendenciu rásť „do hĺbky“ aj „do šírky“. A práve tu sa objavuje hlavná nevýhoda hviezdy – obmedzenosť flexibilita.
A ak vo svojom tichom a útulnom živote vývojára DWH zrazu:
- vznikla úloha „urobiť aspoň niečo rýchlo a potom uvidíme“;
- objavil sa rýchlo sa rozvíjajúci projekt s pripojením nových zdrojov a prepracovaním obchodného modelu aspoň raz týždenne;
- objavil sa zákazník, ktorý netuší, ako by mal systém vyzerať a aké funkcie by mal v konečnom dôsledku plniť, ale je pripravený experimentovať a dôsledne dolaďovať požadovaný výsledok a zároveň sa k nemu dôsledne približovať;
- Projektový manažér prišiel s dobrou správou: "A teraz máme agilné!"
Alebo ak máte len záujem zistiť, ako inak môžete vybudovať skladovacie priestory - vitajte v strihu!
Čo znamená „flexibilita“?
Najprv si definujme, aké vlastnosti musí mať systém, aby bol nazývaný „flexibilný“.
Samostatne stojí za zmienku, že opísané vlastnosti by sa mali konkrétne týkať systém, nie do proces jeho rozvoj. Preto, ak ste si chceli prečítať o Agile ako metodike vývoja, je lepšie prečítať si ďalšie články. Napríklad práve tam, na Habré, je veľa zaujímavých materiálov (napr и A ).
To neznamená, že proces vývoja a štruktúra dátového skladu spolu úplne nesúvisia. Celkovo by malo byť výrazne jednoduchšie vyvinúť agilné úložisko pre agilnú architektúru. V praxi sú však častejšie možnosti s Agilným vývojom klasického DWH podľa Kimbala a DataVault - podľa Waterfalla, ako šťastné náhody flexibility v jej dvoch podobách na jednom projekte.
Aké možnosti by teda flexibilné úložisko malo mať? Sú tu tri body:
- Skoré dodanie a rýchle vybavenie - to znamená, že v ideálnom prípade by mal byť prvý obchodný výsledok (napríklad prvé pracovné správy) získaný čo najskôr, teda ešte predtým, ako je celý systém úplne navrhnutý a implementovaný. Okrem toho by každá následná revízia mala zabrať čo najmenej času.
- Iteratívne zdokonaľovanie - to znamená, že každé ďalšie zlepšenie by v ideálnom prípade nemalo ovplyvniť funkčnosť, ktorá už funguje. Práve tento moment sa často stáva najväčšou nočnou morou veľkých projektov – skôr či neskôr začnú jednotlivé objekty získavať toľko spojení, že je jednoduchšie úplne zopakovať logiku v kópii v blízkosti, ako pridať pole do existujúcej tabuľky. A ak vás prekvapuje, že analýza vplyvu vylepšení na existujúce objekty môže zabrať viac času ako samotné vylepšenia, s najväčšou pravdepodobnosťou ste ešte nepracovali s veľkými dátovými skladmi v bankovníctve alebo telekomunikáciách.
- Neustále sa prispôsobovať meniacim sa obchodným požiadavkám - celková štruktúra objektu by mala byť navrhnutá nielen s ohľadom na možné rozšírenie, ale s očakávaním, že o smerovaní tohto ďalšieho rozšírenia sa v štádiu projektovania nedalo ani len snívať.
A áno, splnenie všetkých týchto požiadaviek v jednom systéme je možné (samozrejme v určitých prípadoch as určitými výhradami).
Nižšie zvážim dve z najpopulárnejších metodológií agilného dizajnu pre dátové sklady - Model kotvy и Dátový trezor. Zo zátvoriek sú vynechané také vynikajúce techniky ako napríklad EAV, 6NF (v čistej forme) a všetko, čo súvisí s NoSQL riešeniami - nie preto, že by boli nejako horšie, a dokonca ani preto, že by v tomto prípade hrozilo, že článok získa objem priemernej diser. Ide len o to, že toto všetko súvisí s riešeniami trochu inej triedy – buď s technikami, ktoré môžete použiť v špecifických prípadoch, bez ohľadu na celkovú architektúru vášho projektu (ako EAV), alebo s globálne inými paradigmami ukladania informácií (ako sú grafové databázy a ďalšie možnosti NoSQL).
Problémy „klasického“ prístupu a ich riešenie vo flexibilných metodikách
„Klasickým“ prístupom mám na mysli starú dobrú hviezdu (bez ohľadu na konkrétnu implementáciu podkladových vrstiev, nech mi prívrženci Kimballa, Inmona a CDM odpustia).
1. Pevná mohutnosť spojov
Tento model je založený na jasnom rozdelení údajov na Rozmer и faktov. A to je, sakra, logické - veď analýza dát v drvivej väčšine prípadov spočíva v analýze určitých číselných ukazovateľov (faktov) v určitých sekciách (dimenziách).
V tomto prípade sa spojenia medzi objektmi vytvárajú vo forme vzťahov medzi tabuľkami pomocou cudzieho kľúča. Vyzerá to celkom prirodzene, ale okamžite to vedie k prvému obmedzeniu flexibility - prísne vymedzenie mohutnosti spojení.
To znamená, že vo fáze návrhu tabuľky musíte pre každý pár súvisiacich objektov presne určiť, či sa môžu vzťahovať toľko k mnohým alebo iba 1 k mnohým a „akým smerom“. To priamo určuje, ktorá tabuľka bude mať primárny kľúč a ktorá cudzí kľúč. Zmena tohto postoja pri prijatí nových požiadaviek s najväčšou pravdepodobnosťou povedie k prepracovaniu základne.
Napríklad pri navrhovaní objektu „pokladničný doklad“, spoliehajúc sa na prísahy obchodného oddelenia, ste stanovili možnosť konania jedno povýšenie pre niekoľko kontrolných pozícií (ale nie naopak):
A po nejakom čase kolegovia predstavili novú marketingovú stratégiu, v ktorej môžu pôsobiť na rovnakej pozícii niekoľko akcií súčasne. A teraz musíte upraviť tabuľky oddelením vzťahu do samostatného objektu.
(Všetky odvodené objekty, v ktorých je spojený šek povýšenia, je teraz tiež potrebné vylepšiť).
Vzťahy v Data Vault a Anchor Model
Ukázalo sa, že je celkom jednoduché vyhnúť sa tejto situácii: nemusíte dôverovať obchodnému oddeleniu. všetky pripojenia sú spočiatku uložené v samostatných tabuľkách a spracovať to ako many-to-many.
Tento prístup bol navrhnutý Dan Linstedt ako súčasť paradigmy Dátový trezor a plne podporované Lars Rönnbäck в Model kotvy.
Výsledkom je, že získame prvú charakteristickú črtu flexibilných metodík:
Vzťahy medzi objektmi nie sú uložené v atribútoch nadradených entít, ale sú samostatným typom objektu.
В Dátový trezor takéto spojovacie tabuľky sa nazývajú odkazA Model kotvy - tie. Na prvý pohľad sú si veľmi podobné, aj keď ich rozdiely nekončia názvom (o ktorom bude reč nižšie). V oboch architektúrach sa spojovacie tabuľky môžu spájať ľubovoľný počet subjektov (nie nevyhnutne 2).
Táto zdanlivo nadbytočnosť poskytuje značnú flexibilitu úprav. Takáto štruktúra sa stáva tolerantnou nielen k zmenám v mohutnosti existujúcich odkazov, ale aj k pridávaniu nových - ak teraz pozícia šeku obsahuje aj odkaz na pokladníka, ktorý ho otvoril, vzhľad takéhoto odkazu sa jednoducho stane doplnok nad existujúcimi tabuľkami bez ovplyvnenia akýchkoľvek existujúcich objektov a procesov.
2. Duplikácia údajov
Druhý problém, ktorý riešia flexibilné architektúry, je menej zrejmý a je v prvom rade vlastný. Merania typu SCD2 (pomaly sa meniace rozmery druhého typu), hoci nielen ich.
V klasickom sklade je dimenzia zvyčajne tabuľka, ktorá obsahuje náhradný kľúč (ako PK) a sadu obchodných kľúčov a atribútov v samostatných stĺpcoch.
Ak dimenzia podporuje vytváranie verzií, do štandardnej sady polí sa pridajú hranice platnosti verzie a v archíve sa objaví niekoľko verzií pre jeden riadok v zdroji (jedna pre každú zmenu v atribútoch verzií).
Ak dimenzia obsahuje aspoň jeden často sa meniaci atribút verzie, počet verzií takejto dimenzie bude pôsobivý (aj keď zostávajúce atribúty nemajú verziu alebo sa nikdy nemenia), a ak existuje niekoľko takýchto atribútov, počet verzií môže rastú exponenciálne z ich počtu. Táto dimenzia môže zaberať značné množstvo miesta na disku, hoci väčšina údajov, ktoré ukladá, sú jednoducho duplikáty nemenných hodnôt atribútov z iných riadkov.
Zároveň sa veľmi často používa denormalizácia — niektoré atribúty sú zámerne uložené ako hodnota, a nie ako odkaz na referenčnú knihu alebo inú dimenziu. Tento prístup urýchľuje prístup k údajom a znižuje počet spojení pri prístupe k dimenzii.
Typicky to vedie k rovnaké informácie sú uložené súčasne na viacerých miestach. Napríklad informácie o regióne bydliska a kategórii klienta je možné súčasne ukladať do dimenzií „Klient“ a faktov „Nákup“, „Doručenie“ a „Volania do call centra“, ako aj do „Klient – manažér klienta“. ” tabuľka odkazov.
Vo všeobecnosti platí vyššie uvedené pre bežné (neverzované) dimenzie, ale vo verziovaných môžu mať inú mierku: objavenie sa novej verzie objektu (najmä pri spätnom pohľade) vedie nielen k aktualizácii všetkých súvisiacich tabuľky, ale ku kaskádovému vzhľadu nových verzií súvisiacich objektov – keď sa tabuľka 1 použije na zostavenie tabuľky 2 a tabuľka 2 sa použije na zostavenie tabuľky 3 atď. Aj keď sa do konštrukcie tabuľky 1 nezúčastňuje ani jeden atribút tabuľky 3 (a sú zahrnuté ďalšie atribúty tabuľky 2 získané z iných zdrojov), verzovanie tejto konštrukcie povedie minimálne k dodatočnej réžii a maximálne k dodatočným nákladom. verzie v tabuľke 3. ktorý s tým nemá vôbec nič spoločné a ďalej v reťazci.
3. Nelineárna zložitosť prepracovania
Každý nový výklad postavený na základe iného zároveň zvyšuje počet miest, kde sa údaje môžu „rozchádzať“ pri zmenách v ETL. To následne vedie k zvýšeniu zložitosti (a trvania) každej nasledujúcej revízie.
Ak vyššie uvedené popisuje systémy so zriedkavo modifikovanými procesmi ETL, môžete žiť v takejto paradigme - musíte sa len uistiť, že nové úpravy sú správne vykonané vo všetkých súvisiacich objektoch. Ak sa revízie vyskytujú často, výrazne sa zvyšuje pravdepodobnosť náhodného „chýbania“ niekoľkých spojení.
Ak navyše vezmeme do úvahy, že „verzovaný“ ETL je podstatne komplikovanejší ako „bezverziovaný“, je dosť ťažké vyhnúť sa chybám pri častej aktualizácii celého tohto zariadenia.
Ukladanie objektov a atribútov v Data Vault a Anchor Model
Prístup navrhovaný autormi flexibilných architektúr možno formulovať takto:
Je potrebné oddeliť to, čo sa mení, od toho, čo zostáva rovnaké. To znamená, že kľúče ukladajte oddelene od atribútov.
Človek by sa však nemal zamieňať nie je verzovaný atribút s nezmenené: prvý neuchováva históriu svojich zmien, ale môže sa meniť (napríklad pri oprave vstupnej chyby alebo prijímaní nových údajov), druhý sa nikdy nemení.
Názory na to, čo presne možno považovať za nemenné v dátovom trezore a modeli kotvy, sa líšia.
Z architektonického hľadiska Dátový trezor, možno považovať za nezmenené celá sada kľúčov - prirodzené (DIČ organizácie, kód produktu v zdrojovom systéme atď.) a náhradné. V tomto prípade možno zvyšné atribúty rozdeliť do skupín podľa zdroja a/alebo frekvencie zmien a Udržujte samostatnú tabuľku pre každú skupinu s nezávislým súborom verzií.
V paradigme Model kotvy považované za nezmenené iba náhradný kľúč esencia. Všetko ostatné (vrátane prirodzených kľúčov) je len špeciálny prípad jeho atribútov. V čom všetky atribúty sú štandardne navzájom nezávislé, takže pre každý atribút a samostatná tabuľka.
В Dátový trezor volajú sa tabuľky obsahujúce kľúče entít Hubami. Huby vždy obsahujú pevnú množinu polí:
- Kľúče prirodzených entít
- Náhradný kľúč
- Odkaz na zdroj
- Zaznamenajte čas pridania
Príspevky v Hubs nikdy sa nemenia a nemajú žiadne verzie. Navonok sú huby veľmi podobné tabuľkám typu mapy ID, ktoré sa používajú v niektorých systémoch na generovanie náhrad, odporúča sa však použiť hash zo sady obchodných kľúčov ako náhrady v Data Vault. Tento prístup zjednodušuje načítanie vzťahov a atribútov zo zdrojov (na získanie náhrady sa nemusíte pripojiť k hubu, stačí vypočítať hash prirodzeného kľúča), ale môže spôsobiť ďalšie problémy (súvisiace napríklad s kolíziami , veľké a malé písmená a netlačiteľné znaky v kľúčoch reťazcov atď. .p.), preto nie je všeobecne akceptovaný.
Všetky ostatné atribúty entity sú uložené v špeciálnych tabuľkách tzv Satelity. Jeden hub môže mať niekoľko satelitov s rôznymi súbormi atribútov.
Rozdelenie atribútov medzi satelity prebieha podľa princípu spoločná zmena — na jednom satelite môžu byť uložené neverzované atribúty (napríklad dátum narodenia a SNILS pre jednotlivca), na inom - zriedka sa meniace verzie (napríklad priezvisko a číslo pasu), na treťom - často sa meniace (napríklad dodacia adresa, kategória, dátum poslednej objednávky a pod.). Verzia sa v tomto prípade vykonáva na úrovni jednotlivých satelitov, a nie entity ako celku, preto je vhodné distribuovať atribúty tak, aby prelínanie verzií v rámci jedného satelitu bolo minimálne (čo znižuje celkový počet uložených verzií ).
Pre optimalizáciu procesu načítania dát sú v jednotlivých satelitoch často zahrnuté aj atribúty získané z rôznych zdrojov.
Satelity komunikujú s Hubom cez cudzí kľúč (čo zodpovedá mohutnosti 1 ku mnohým). To znamená, že táto „predvolená“ architektúra podporuje viacero hodnôt atribútov (napríklad viacero kontaktných telefónnych čísel pre jedného klienta).
В Model kotvy sa nazývajú tabuľky, ktoré uchovávajú kľúče Kotvy. A zachovávajú:
- Iba náhradné kľúče
- Odkaz na zdroj
- Zaznamenajte čas pridania
Uvažované sú prirodzené kľúče z pohľadu Anchor Model bežné atribúty. Táto možnosť sa môže zdať zložitejšia na pochopenie, ale poskytuje oveľa väčší priestor na identifikáciu objektu.
Napríklad, ak údaje o tej istej entite môžu pochádzať z rôznych systémov, z ktorých každý používa svoj vlastný prirodzený kľúč. V Data Vault to môže viesť k dosť ťažkopádnym štruktúram niekoľkých uzlov (jeden na zdroj + zjednocujúca master verzia), zatiaľ čo v modeli Anchor spadá prirodzený kľúč každého zdroja do vlastného atribútu a možno ho použiť pri načítavaní nezávisle od všetky ostatné.
Ale je tu aj jeden zákerný bod: ak sa atribúty z rôznych systémov kombinujú v jednej entite, s najväčšou pravdepodobnosťou existujú pravidlá "lepenia", čím systém musí pochopiť, že záznamy z rôznych zdrojov zodpovedajú jednej inštancii entity.
В Dátový trezor tieto pravidlá s najväčšou pravdepodobnosťou určia formáciu „náhradný uzol“ hlavnej entity a žiadnym spôsobom neovplyvňujú rozbočovače, ktoré uchovávajú prirodzené zdrojové kľúče a ich pôvodné atribúty. Ak sa v určitom bode zmenia pravidlá zlučovania (alebo sa aktualizujú atribúty, ktorými sa vykonáva), bude stačiť preformátovať náhradné uzly.
В Model kotvy takáto entita bude s najväčšou pravdepodobnosťou uložená v jediná kotva. To znamená, že všetky atribúty, bez ohľadu na to, z akého zdroja pochádzajú, budú viazané na rovnakého zástupcu. Oddeľovanie chybne zlúčených záznamov a vo všeobecnosti sledovanie relevantnosti zlučovania v takomto systéme môže byť oveľa náročnejšie, najmä ak sú pravidlá pomerne zložité a často sa menia a rovnaký atribút je možné získať z rôznych zdrojov (aj keď je to určite možné, pretože každá verzia atribútu si zachováva odkaz na svoj zdroj).
V každom prípade, ak má váš systém implementovať funkčnosť deduplikácia, zlučovanie záznamov a ďalšie prvky MDM, stojí za to venovať osobitnú pozornosť aspektom ukladania prirodzených kľúčov v agilných metodológiách. Je pravdepodobné, že objemnejší dizajn Data Vault bude zrazu bezpečnejší, pokiaľ ide o chyby zlučovania.
Model kotvy poskytuje aj ďalší typ objektu, tzv Uzol je to v podstate zvlastne degenerovaný typ kotvy, ktorý môže obsahovať iba jeden atribút. Uzly majú slúžiť na ukladanie plochých adresárov (napríklad pohlavie, rodinný stav, kategória služieb zákazníkom atď.). Na rozdiel od kotvy, uzla nemá žiadne priradené tabuľky atribútov, a jeho jediný atribút (názov) je vždy uložený v rovnakej tabuľke s kľúčom. Uzly sú spojené s kotvami pomocou spojovacích stolov (Tie) rovnakým spôsobom, ako sú navzájom spojené kotvy.
Neexistuje jednoznačný názor na používanie uzlov. Napríklad, , ktorý aktívne propaguje používanie kotevného modelu v Rusku, sa (nie bezdôvodne) domnieva, že ani pri jednej referenčnej knihe nemožno s istotou tvrdiť, že vždy bude statická a jednoúrovňová, preto je lepšie okamžite použiť plnohodnotnú Anchor pre všetky objekty.
Ďalším dôležitým rozdielom medzi Data Vault a Anchor modelom je dostupnosť atribúty spojení:
В Dátový trezor Odkazy sú rovnaké plnohodnotné objekty ako Huby a môžu mať vlastné atribúty. V Model kotvy Odkazy sa používajú iba na pripojenie kotiev a nemôže mať svoje vlastné atribúty. Tento rozdiel má za následok výrazne odlišné prístupy k modelovaniu faktov, o ktorej sa bude ďalej diskutovať.
Ukladanie faktov
Predtým sme hovorili hlavne o modelovaní meraní. Fakty sú o niečo menej jasné.
В Dátový trezor typickým objektom na ukladanie faktov je Odkaz, v ktorých satelitoch sú pridané reálne ukazovatele.
Zdá sa, že tento prístup je intuitívny. Poskytuje jednoduchý prístup k analyzovaným ukazovateľom a je vo všeobecnosti podobný tradičnej tabuľke faktov (len ukazovatele nie sú uložené v samotnej tabuľke, ale v „susednej“ tabuľke). Existujú však aj úskalia: jedna z typických úprav modelu – rozšírenie kľúča faktov – si vyžaduje pridanie nového cudzieho kľúča do Link. A to zase „narušuje“ modularitu a potenciálne spôsobuje potrebu úprav iných objektov.
В Model kotvy Spojenie nemôže mať svoje vlastné atribúty, takže tento prístup nebude fungovať - absolútne všetky atribúty a ukazovatele musia byť spojené s jednou konkrétnou kotvou. Záver z toho je jednoduchý - Každá skutočnosť potrebuje aj svoju kotvu. Pre niektoré z toho, čo sme zvyknutí vnímať ako fakty, to môže vyzerať prirodzene – napríklad skutočnosť nákupu možno dokonale zredukovať na objekt „objednávka“ alebo „potvrdenie“, návšteva stránky na reláciu atď. Existujú však aj skutočnosti, pre ktoré nie je také ľahké nájsť taký prirodzený „nosný predmet“ - napríklad zvyšky tovaru v skladoch na začiatku každého dňa.
V súlade s tým nevznikajú problémy s modularitou pri rozširovaní kľúča faktov v modeli Anchor (stačí jednoducho pridať nový vzťah k zodpovedajúcej kotve), ale návrh modelu na zobrazenie faktov je menej jednoznačný, môžu sa objaviť „umelé“ kotvy. ktoré zobrazujú model obchodného objektu nejasným spôsobom.
Ako sa dosahuje flexibilita
Výsledná konštrukcia v oboch prípadoch obsahuje podstatne viac stolovako tradičné meranie. Ale môže to trvať výrazne menej miesta na disku s rovnakou sadou verziovaných atribútov ako tradičná dimenzia. Prirodzene, nie je tu žiadna mágia - je to všetko o normalizácii. Distribúciou atribútov naprieč satelitmi (v Data Vault) alebo jednotlivými tabuľkami (Anchor Model) znižujeme (alebo úplne eliminujeme) duplikácia hodnôt niektorých atribútov pri zmene iných.
pre Dátový trezor výhry budú závisieť od rozloženia atribútov medzi satelitmi a pre Model kotvy — je takmer priamo úmerná priemernému počtu verzií na objekt merania.
Úspora miesta je však dôležitou, no nie hlavnou výhodou samostatného ukladania atribútov. Spolu s oddeleným ukladaním vzťahov tento prístup robí obchod modulárny dizajn. To znamená, že pridanie jednotlivých atribútov aj celých nových tematických oblastí do takéhoto modelu vyzerá nadstavba nad existujúcou množinou objektov bez ich zmeny. A práve to robí popisované metodiky flexibilnými.
To tiež pripomína prechod z kusovej výroby na hromadnú výrobu - ak je v tradičnom prístupe každá tabuľka modelu jedinečná a vyžaduje si osobitnú pozornosť, potom vo flexibilných metodológiách je to už súbor štandardných „súčiastok“. Jednak je tam viac tabuliek a aj procesy načítavania a získavania dát by mali vyzerať komplikovanejšie. Na druhej strane sa stávajú typický. Čo znamená, že môže existovať automatizované a riadené metadátami. Otázka „ako to položíme?“, odpoveď na ktorú by mohla zabrať značnú časť práce na navrhovaní vylepšení, teraz jednoducho nestojí za to (rovnako ako otázka o vplyve zmeny modelu na pracovné procesy ).
To neznamená, že analytici v takomto systéme vôbec nie sú potrební – niekto sa predsa potrebuje prepracovať cez množinu objektov s atribútmi a zistiť, kde a ako to všetko načítať. Množstvo práce, ako aj pravdepodobnosť a náklady na chybu sa však výrazne znížia. Ako vo fáze analýzy, tak aj počas vývoja ETL, ktorý je možné z veľkej časti zredukovať na úpravu metadát.
Temná strana
Vďaka všetkému vyššie uvedenému sú oba prístupy skutočne flexibilné, technologicky vyspelé a vhodné na opakované zlepšovanie. Samozrejmosťou je aj “sud v masti”, čo si myslím, že už tušíte.
Dekompozícia údajov, ktorá je základom modularity flexibilných architektúr, vedie k zvýšeniu počtu tabuliek, a teda k nad hlavou pripojiť sa pri odbere vzoriek. Aby ste jednoducho získali všetky atribúty rozmeru, v klasickom obchode stačí jeden výber, ale flexibilná architektúra bude vyžadovať celý rad spojení. Navyše, ak všetky tieto spojenia pre správy môžu byť napísané vopred, potom analytici, ktorí sú zvyknutí písať SQL ručne, budú trpieť dvojnásobne.
Existuje niekoľko faktov, ktoré túto situáciu uľahčujú:
Pri práci s veľkými rozmermi sa takmer nikdy nepoužívajú všetky jeho atribúty súčasne. To znamená, že spojení môže byť menej, ako sa na prvý pohľad na model zdá. Data Vault môže pri prideľovaní atribútov satelitom brať do úvahy aj očakávanú frekvenciu zdieľania. Samotné rozbočovače alebo kotvy sú zároveň potrebné predovšetkým na generovanie a mapovanie náhrad vo fáze načítania a zriedka sa používajú v dopytoch (to platí najmä pre kotvy).
Všetky spojenia sú na kľúč. Navyše „komprimovanejší“ spôsob ukladania údajov znižuje réžiu skenovania tabuliek tam, kde je to potrebné (napríklad pri filtrovaní podľa hodnoty atribútu). To môže viesť k tomu, že vzorkovanie z normalizovanej databázy s množstvom spojení bude ešte rýchlejšie ako skenovanie jednej ťažkej dimenzie s mnohými verziami na riadok.
Napríklad tu v Článok obsahuje podrobný porovnávací test výkonu modelu Anchor s ukážkou z jednej tabuľky.
Veľa závisí od motora. Mnoho moderných platforiem má interné mechanizmy na optimalizáciu spojenia. Napríklad MS SQL a Oracle môžu „preskočiť“ spojenia s tabuľkami, ak ich údaje nie sú nikde použité okrem iných spojení a neovplyvňujú konečný výber (eliminácia tabuľky/spájania), a MPP Vertica , sa ukázal ako vynikajúci nástroj pre model Anchor, vzhľadom na určitú manuálnu optimalizáciu plánu dotazov. Na druhej strane, uložiť Anchor Model napríklad na Click House, ktorý má obmedzenú join support, zatiaľ nevyzerá ako veľmi dobrý nápad.
Navyše pre obe architektúry existujú špeciálne pohyby, čím sa zjednoduší prístup k údajom (z hľadiska výkonu dotazov aj pre koncových používateľov). Napríklad, Point-In-Time tabuľky v Dátovom trezore resp špeciálne funkcie tabuľky v modeli Anchor.
Celkom
Hlavnou podstatou uvažovaných flexibilných architektúr je modularita ich „dizajnu“.
Práve táto vlastnosť umožňuje:
- Po počiatočnej príprave súvisiacej s nasadením metadát a napísaním základných algoritmov ETL, rýchlo poskytnúť zákazníkovi prvý výsledok vo forme niekoľkých správ obsahujúcich údaje len z niekoľkých zdrojových objektov. Nie je potrebné úplne premyslieť (ani na najvyššej úrovni) celý objektový model.
- Dátový model môže začať fungovať (a byť užitočný) len s 2-3 objektmi a potom rastú postupne (pokiaľ ide o model Anchor Nikolai pekné porovnanie s mycéliom).
- Väčšina vylepšení vrátane rozšírenia oblasti témy a pridania nových zdrojov neovplyvňuje existujúcu funkčnosť a nepredstavuje riziko rozbitia niečoho, čo už funguje.
- Vďaka rozkladu na štandardné prvky vyzerajú ETL procesy v takýchto systémoch rovnako, ich zápis sa hodí na algoritmizáciu a v konečnom dôsledku, automatizácie.
Cena tejto flexibility je produktivita. To neznamená, že na takýchto modeloch nie je možné dosiahnuť prijateľný výkon. Častejšie možno budete potrebovať viac úsilia a pozornosti venovanej detailom, aby ste dosiahli požadované metriky.
Aplikácie
Typy entít Dátový trezor
Viac informácií o Dátovom trezore:
Typy entít Model kotvy
Ďalšie podrobnosti o modeli Anchor:
Súhrnná tabuľka so spoločnými vlastnosťami a rozdielmi uvažovaných prístupov:
Zdroj: hab.com