A tároló fejlesztése hosszú és komoly vállalkozás.
Egy projekt életében sok múlik azon, hogy az objektummodellt és az alapstruktúrát mennyire gondolták át az elején.
Az általánosan elfogadott megközelítés a csillagséma és a harmadik normálforma kombinálásának különféle változatai volt és marad. Általános szabály, hogy az elv szerint: kezdeti adatok - 3NF, vitrinek - csillag. Ez az időben tesztelt és nagy mennyiségű kutatás által támogatott megközelítés az első (és néha az egyetlen), ami egy tapasztalt DWH-specialista eszébe jut, amikor egy elemzési adattárnak ki kell néznie.
Másrészt az üzlet általában, és különösen az ügyfelek igényei általában gyorsan változnak, és az adatok „mélységben” és „szélességben” egyaránt növekednek. És itt jelenik meg a csillag fő hátránya - korlátozott rugalmasság.
És ha csendes és hangulatos életében DWH fejlesztőként hirtelen:
- felmerült a feladat, hogy „legalább valamit gyorsan csináljunk, aztán meglátjuk”;
- gyorsan fejlődő projekt jelent meg, új források bevonásával, az üzleti modell átdolgozásával hetente legalább egyszer;
- megjelent egy ügyfél, akinek fogalma sincs arról, hogyan nézzen ki a rendszer és milyen funkciókat kell végül ellátnia, de kész kísérletezni és következetesen finomítani a kívánt eredményt, miközben következetesen közelebb kerül hozzá;
- A projektmenedzser a jó hírrel jelentkezett: „És most agilisak vagyunk!”
Vagy ha csak azt szeretné megtudni, hogyan építhet máshol tárolót - üdvözöljük!
Mit jelent a "rugalmasság"?
Először is határozzuk meg, milyen tulajdonságokkal kell rendelkeznie egy rendszernek ahhoz, hogy „rugalmasnak” nevezzük.
Külön érdemes megemlíteni, hogy a leírt tulajdonságoknak kifejezetten vonatkozniuk kell rendszer, nem folyamat a fejlődését. Ezért, ha az Agile-ről, mint fejlesztési módszerről szeretne olvasni, jobb, ha más cikkeket olvas. Például ott, a Habrén sok érdekes anyag található (pl и És ).
Ez nem jelenti azt, hogy a fejlesztési folyamat és az adattárház felépítése teljesen független. Összességében lényegesen egyszerűbbnek kell lennie egy Agilis tároló fejlesztésének egy agilis architektúrához. A gyakorlatban azonban gyakrabban van lehetőség a klasszikus DWH agilis fejlesztésére a Kimbal és a DataVault szerint - a Waterfall szerint, mint a rugalmasság boldog egybeesései annak két formájában egy projektben.
Tehát milyen képességekkel kell rendelkeznie a rugalmas tárolásnak? Itt három pont van:
- Korai szállítás és gyors átfutás - ez azt jelenti, hogy ideális esetben az első üzleti eredményt (például az első munkajelentéseket) a lehető legkorábban meg kell szerezni, vagyis még azelőtt, hogy az egész rendszert teljesen megtervezték és implementálták volna. Ezenkívül minden további felülvizsgálatnak a lehető legkevesebb időt kell igénybe vennie.
- Iteratív finomítás - ez azt jelenti, hogy minden további fejlesztés ideális esetben nem érintheti a már működő funkcionalitást. Ez a pillanat gyakran a legnagyobb rémálom a nagy projekteknél - előbb-utóbb az egyes objektumok olyan sok kapcsolatot kezdenek el megszerezni, hogy könnyebb lesz a logikát teljesen megismételni egy közeli másolatban, mint egy mezőt hozzáadni egy meglévő táblázathoz. És ha meglep, hogy a fejlesztések meglévő objektumokra gyakorolt hatásának elemzése több időt vehet igénybe, mint maguk a fejlesztések, akkor valószínűleg még nem dolgozott nagy banki vagy távközlési adattárházakkal.
- Folyamatosan alkalmazkodik a változó üzleti követelményekhez - a teljes tárgyszerkezetet nemcsak az esetleges bővítések figyelembevételével kell megtervezni, hanem úgy, hogy a következő bővítés irányáról még a tervezési szakaszban még csak álmodni sem lehetett.
És igen, mindezen követelmények egy rendszerben való teljesítése lehetséges (természetesen bizonyos esetekben és bizonyos fenntartásokkal).
Az alábbiakban megvizsgálom az adattárházak két legnépszerűbb agilis tervezési módszerét - Horgonyos modell и Data Vault. Kimaradtak a zárójelekből olyan kiváló technikák, mint például az EAV, a 6NF (a maga tiszta formájában) és minden, ami a NoSQL-megoldásokhoz kapcsolódik - nem azért, mert valahogy rosszabbak, és még csak azért sem, mert ebben az esetben a cikk megszerzésével fenyegetne. az átlagos disszertáció kötete. Mindez csak egy kicsit más osztályba tartozó megoldásokra vonatkozik – vagy olyan technikákra, amelyeket konkrét esetekben használhat, függetlenül a projekt általános architektúrájától (például az EAV), vagy globálisan más információtárolási paradigmákhoz (például gráf adatbázisokhoz). és egyéb lehetőségek NoSQL).
A „klasszikus” megközelítés problémái és megoldásaik rugalmas módszertanokban
A „klasszikus” megközelítés alatt a jó öreg sztárt értem (függetlenül a mögöttes rétegek konkrét megvalósításától, bocsásson meg nekem Kimball, Inmon és CDM követői).
1. A kapcsolatok merev számossága
Ez a modell az adatok egyértelmű felosztásán alapul Dimenzió и tények. És ez, a fenébe, logikus is - elvégre az adatelemzés az esetek túlnyomó többségében bizonyos számszerű mutatók (tények) bizonyos szakaszokban (dimenziókban) történő elemzésére vezethető vissza.
Ebben az esetben az objektumok közötti kapcsolatok táblák közötti kapcsolatok formájában jönnek létre idegen kulcs használatával. Ez teljesen természetesnek tűnik, de azonnal a rugalmasság első korlátozásához vezet - az összefüggések számosságának szigorú meghatározása.
Ez azt jelenti, hogy a táblázat tervezési szakaszában pontosan meg kell határoznia minden egyes kapcsolódó objektumpárhoz, hogy a sok-sokhoz viszonyulhatnak-e, vagy csak az 1-től a sokhoz, és „melyik irányban”. Ez közvetlenül meghatározza, hogy melyik tábla lesz az elsődleges kulcs és melyik az idegen kulcs. Ezen hozzáállás megváltoztatása új követelmények beérkezésekor nagy valószínűséggel az alap átdolgozásához vezet.
Például a „pénztárbizonylat” objektum megtervezésekor Ön az értékesítési osztály esküjére támaszkodva lefektette a cselekvés lehetőségét egy promóció több csekk pozícióért (de nem fordítva):
Egy idő után a kollégák egy új marketingstratégiát vezettek be, amelyben ugyanazon a pozícióban tevékenykedhetnek több promóció egyszerre. Most pedig módosítania kell a táblákat úgy, hogy a kapcsolatot külön objektummá választja.
(Az összes származtatott objektumot, amelyben az előléptetési ellenőrzés csatlakozik, szintén javítani kell).
Kapcsolatok az adattárolóban és a horgonymodellben
A helyzet elkerülése meglehetősen egyszerűnek bizonyult: nem kell az értékesítési osztályra bíznia ezt. kezdetben minden kapcsolat külön táblázatokban van tárolva és feldolgozza a sok-sok.
Ezt a megközelítést javasolták Dan Linstedt paradigma részeként Data Vault és teljes mértékben támogatott Lars Rönnbäck в Horgony modell.
Ennek eredményeként megkapjuk a rugalmas módszertanok első megkülönböztető jegyét:
Az objektumok közötti kapcsolatokat a rendszer nem a szülő entitások attribútumaiban tárolja, hanem egy külön típusú objektum.
В Data Vault az ilyen összekötő táblákat nevezzük Link, és be Horgony modell - Nyakkendő. Első pillantásra nagyon hasonlóak, bár különbségeik nem érnek véget a névvel (amiről az alábbiakban lesz szó). Mindkét architektúrában a linktáblázatok linkelhetnek tetszőleges számú entitás (nem feltétlenül 2).
Ez a redundancia első pillantásra jelentős rugalmasságot biztosít a módosításokhoz. Egy ilyen struktúra nemcsak a meglévő linkek kardinalitásában bekövetkező változásokkal szemben válik toleránssá, hanem újak hozzáadásával is - ha most egy csekkpozíciónak is van linkje az azt áttörő pénztároshoz, akkor egy ilyen hivatkozás megjelenése egyszerűen kiegészítővé válhat a meglévő táblákhoz anélkül, hogy ez bármilyen objektumra és folyamatra hatással lenne.
2. Adatmásolás
A rugalmas architektúrák által megoldott második probléma kevésbé nyilvánvaló, és elsősorban velejárója. SCD2 típusú mérések (a második típus lassan változó méretei), bár nem csak őket.
A klasszikus raktárban a dimenzió általában egy tábla, amely egy helyettesítő kulcsot (PK-ként) és üzleti kulcsok és attribútumok készletét tartalmazza külön oszlopokban.
Ha egy dimenzió támogatja a verziószámítást, a verzióérvényességi határok hozzáadódnak a szabványos mezőkészlethez, és a forrás egy sorához több verzió jelenik meg a lerakatban (egy a verziózott attribútumok minden változásához).
Ha egy dimenzió legalább egy gyakran változó verziójú attribútumot tartalmaz, egy ilyen dimenzió verzióinak száma lenyűgöző lesz (még akkor is, ha a fennmaradó attribútumok nem verziózottak, vagy soha nem változnak), és ha több ilyen attribútum van, a verziók száma számuktól exponenciálisan nőnek. Ez a dimenzió jelentős mennyiségű lemezterületet foglalhat el, bár az általa tárolt adatok nagy része egyszerűen más sorok megváltoztathatatlan attribútumértékeinek másolata.
Ugyanakkor nagyon gyakran használják denormalizáció — egyes attribútumok szándékosan értékként vannak tárolva, nem pedig hivatkozásként egy hivatkozási könyvhöz vagy más dimenzióhoz. Ez a megközelítés felgyorsítja az adatok elérését, csökkentve az összekapcsolások számát egy dimenzió elérésekor.
Ez jellemzően ahhoz vezet ugyanazt az információt egyszerre több helyen tárolják. Például a lakóhely régiójával és az ügyfél kategóriájával kapcsolatos információk egyidejűleg tárolhatók az „Ügyfél” dimenziókban és a „Vásárlás”, „Kézbesítés” és „Call Centerhívások” tényekben, valamint az „Ügyfél - Ügyfélmenedzser” részben. ” link táblázat.
Általánosságban elmondható, hogy a fent leírtak a normál (nem verziószámú) méretekre vonatkoznak, de a verzióknál eltérő léptékűek lehetnek: egy objektum új verziójának megjelenése (főleg utólag) nem csak az összes kapcsolódó frissítéshez vezet. táblák, hanem a kapcsolódó objektumok új verzióinak lépcsőzetes megjelenésére – amikor az 1. táblázatot használjuk a 2. táblázat, a 2. táblázatot pedig a 3. tábla felépítéséhez stb. Még ha az 1. táblázat egyetlen attribútuma sem vesz részt a 3. táblázat felépítésében (és a 2. táblázat egyéb, más forrásokból származó attribútumai is érintettek), ennek a konstrukciónak a verziószáma legalább többletköltséget, legfeljebb pedig többletköltséget eredményez. verziók a 3. táblázatban. aminek egyáltalán semmi köze hozzá, és lejjebb a láncban.
3. Az átdolgozás nemlineáris összetettsége
Ugyanakkor minden új kirakat egy másik alapján megnöveli azon helyek számát, ahol az adatok „eltérhetnek” az ETL módosításakor. Ez viszont az egyes további felülvizsgálatok bonyolultságának (és időtartamának) növekedéséhez vezet.
Ha a fentiek olyan rendszereket írnak le, amelyek ritkán módosított ETL-folyamatokkal rendelkeznek, akkor egy ilyen paradigmában élhet - csak meg kell győződnie arról, hogy az összes kapcsolódó objektumon az új módosítások megfelelően történnek. Ha a felülvizsgálatok gyakran előfordulnak, jelentősen megnő annak a valószínűsége, hogy véletlenül több kapcsolat "elmarad".
Ha ezen felül figyelembe vesszük, hogy a „verziós” ETL lényegesen bonyolultabb, mint a „nem verziójú”, akkor az egész szolgáltatás gyakori frissítése során meglehetősen nehéz elkerülni a hibákat.
Objektumok és attribútumok tárolása a Data Vault és a horgonymodellben
A rugalmas architektúrák szerzői által javasolt megközelítés a következőképpen fogalmazható meg:
El kell választani, hogy mi változik, és ami változatlan marad. Vagyis a kulcsokat az attribútumoktól elkülönítve tárolja.
Nem szabad azonban összekeverni nem verziózva tulajdonsággal változatlan: az első nem tárolja a változástörténetét, de változhat (például beviteli hiba javításakor vagy új adatok fogadásakor), a második soha nem változik.
A nézőpontok eltérnek arról, hogy pontosan mi tekinthető megváltoztathatatlannak a Data Vault és a Horgonymodellben.
Építészeti szempontból Data Vault, változatlannak tekinthető teljes kulcskészlet - természetes (a szervezet TIN-je, termékkód a forrásrendszerben stb.) és helyettesítő. Ebben az esetben a fennmaradó attribútumok a változások forrása és/vagy gyakorisága szerint csoportokba oszthatók, ill Vezessen külön táblázatot minden csoporthoz független változatkészlettel.
A paradigmában Horgony modell változatlannak tekinthető csak pótkulcs lényeg. Minden más (beleértve a természetes kulcsokat is) csak az attribútumainak egy speciális esete. Ahol alapértelmezés szerint minden attribútum független egymástól, tehát minden attribútumhoz a külön asztal.
В Data Vault az entitáskulcsokat tartalmazó táblákat hívjuk meg Hubami. A hubok mindig tartalmaznak egy rögzített mezőkészletet:
- Természetes entitás kulcsok
- Helyettesítő kulcs
- Link a forráshoz
- Hozzáadási idő rögzítése
Bejegyzések a Hubokban soha ne változzon, és nincsenek verziói. Külsőleg a hubok nagyon hasonlítanak az egyes rendszerekben helyettesítők generálására használt ID-map típusú táblákhoz, azonban ajánlatos üzleti kulcskészletből származó hash-t használni helyettesítőként a Data Vaultban. Ez a megközelítés leegyszerűsíti a kapcsolatok és attribútumok forrásból való betöltését (nem kell csatlakozni a hubhoz, hogy helyettesítőt kapjon, csak kiszámítja a természetes kulcs hash-jét), de egyéb problémákat is okozhat (például ütközésekkel, kisbetűkkel és nem nyomtatható karakterek karakterlánckulcsokban stb. .p.), ezért nem általánosan elfogadott.
Az összes többi entitásattribútum speciális táblákban, úgynevezett Műholdak. Egy hubnak több műholdja is lehet, amelyek különböző attribútumkészleteket tárolnak.
Az attribútumok eloszlása a műholdak között az elv szerint történik közös változás - az egyik műholdban nem változatos attribútumok tárolhatók (például egy személy születési dátuma és SNILS), a másikban - ritkán változó verziójúak (például vezetéknév és útlevélszám), a harmadikban - gyakran változóak (például szállítási cím, kategória, utolsó rendelés dátuma stb.). Ebben az esetben a verziókészítés az egyes műholdak szintjén történik, nem pedig az entitás egészének szintjén, ezért tanácsos az attribútumokat úgy elosztani, hogy a verziók metszéspontja egy műholdon belül minimális legyen (ami csökkenti a tárolt verziók teljes számát ).
Ezenkívül az adatbetöltési folyamat optimalizálása érdekében a különböző forrásokból származó attribútumokat gyakran beépítik az egyes műholdakba.
A műholdak ezen keresztül kommunikálnak a Hubbal idegen kulcs (ami 1-a-sok kardinalitásnak felel meg). Ez azt jelenti, hogy ez az „alapértelmezett” architektúra több attribútumértéket (például több kapcsolati telefonszámot egy ügyfélhez) támogat.
В Horgony modell a kulcsokat tároló táblázatokat hívják Horgonyok. És megtartják:
- Csak pótkulcsok
- Link a forráshoz
- Hozzáadási idő rögzítése
A horgonymodell szempontjából természetes kulcsokat veszünk figyelembe hétköznapi attribútumok. Ez az opció nehezebben érthetőnek tűnhet, de sokkal nagyobb teret enged az objektum azonosítására.
Például, ha ugyanarra az entitásra vonatkozó adatok származhatnak különböző rendszerekből, amelyek mindegyike saját természetes kulcsot használ. A Data Vaultban ez több hubból álló meglehetősen nehézkes struktúrákhoz vezethet (forrásonként egy + egységesítő főverzió), míg az Anchor modellben az egyes források természetes kulcsa a saját attribútumába esik, és a betöltéstől függetlenül használható. az összes többi.
De van itt egy alattomos pont is: ha a különböző rendszerek attribútumait egy entitásban egyesítik, valószínűleg vannak olyanok, a "ragasztás" szabályai, amellyel a rendszernek meg kell értenie, hogy a különböző forrásokból származó rekordok az entitás egy példányának felelnek meg.
В Data Vault ezek a szabályok nagy valószínűséggel meghatározzák a formációt a fő entitás „helyettesítő központja”. és semmilyen módon nem befolyásolja a természetes forráskulcsokat és azok eredeti attribútumait tároló Hubokat. Ha egy ponton az összevonási szabályok megváltoznak (vagy frissítik az attribútumokat, amelyek alapján végrehajtják), akkor elegendő a helyettesítő hubok újraformázása.
В Horgonyos modell egy ilyen entitást nagy valószínűséggel tárolnak az egyetlen horgony. Ez azt jelenti, hogy minden attribútum, függetlenül attól, hogy milyen forrásból származik, ugyanahhoz a helyettesítőhöz lesz kötve. A hibásan összevont rekordok szétválasztása és általában az egyesítés relevanciájának figyelemmel kísérése egy ilyen rendszerben sokkal nehezebb lehet, különösen, ha a szabályok meglehetősen összetettek és gyakran változnak, és ugyanaz az attribútum különböző forrásokból beszerezhető (bár ez minden bizonnyal lehetséges, mivel mindegyik attribútum-verzió megtartja a forrásra mutató hivatkozást).
Mindenesetre, ha a rendszernek meg kell valósítania a funkcionalitást deduplikáció, rekordok és egyéb MDM elemek összevonása, érdemes különösen odafigyelni a természetes kulcsok tárolásának szempontjaira az agilis módszertanokban. Valószínű, hogy a nagyobb Data Vault kialakítás hirtelen biztonságosabb lesz az egyesítési hibák tekintetében.
Horgonyos modell nevű további objektumtípust is biztosít Csomó lényegében különleges degenerált típusú horgony, amely csak egy attribútumot tartalmazhat. A csomópontokat állítólag lapos könyvtárak tárolására kell használni (például nem, családi állapot, ügyfélszolgálati kategória stb.). A Horgonytól eltérően a Csomó nincs társított attribútumtáblázata, és az egyetlen attribútuma (név) mindig ugyanabban a táblában van tárolva a kulccsal. A csomópontok kötőtáblákkal (Tie) csatlakoznak a horgonyokhoz, ugyanúgy, mint a horgonyok egymáshoz.
Nincs egyértelmű vélemény a csomópontok használatával kapcsolatban. Például, , aki aktívan népszerűsíti a horgonymodell használatát Oroszországban, úgy véli (nem alaptalanul), hogy egyetlen kézikönyvről sem állítható biztosan, hogy mindig statikus és egyszintű lesz, ezért jobb, ha azonnal teljes értékű horgonyot használunk minden objektumhoz.
Egy másik fontos különbség a Data Vault és az Anchor modell között a rendelkezésre állás kapcsolatok attribútumai:
В Data Vault A hivatkozások ugyanazok a teljes értékű objektumok, mint a Hubok, és rendelkezhetnek is velük saját attribútumok. -Ban Horgonyos modell A hivatkozások csak a Horgonyok és a nem lehetnek saját tulajdonságaik. Ez a különbség jelentősen eltérő modellezési megközelítéseket eredményez tények, amiről még lesz szó.
Ténytárolás
Ezt megelőzően főként mérési modellezésről beszéltünk. A tények egy kicsit kevésbé egyértelműek.
В Data Vault a tények tárolásának tipikus tárgya az Link, amelynek műholdjaiban valós mutatók vannak hozzáadva.
Ez a megközelítés intuitívnak tűnik. Könnyű hozzáférést biztosít az elemzett mutatókhoz, és általában hasonló a hagyományos ténytáblázathoz (csak a mutatók nem a táblázatban, hanem a „szomszéd” táblázatban tárolódnak). De vannak buktatók is: a modell egyik tipikus módosítása - a ténykulcs kiterjesztése - szükségessé teszi új idegen kulcs hozzáadása a Linkhez. Ez pedig „megtöri” a modularitást, és potenciálisan szükségessé teszi más objektumok módosításait.
В Horgonyos modell Egy kapcsolatnak nem lehetnek saját attribútumai, ezért ez a megközelítés nem fog működni – abszolút minden attribútumot és mutatót egy adott horgonyhoz kell kapcsolni. Ebből egyszerű a következtetés: Minden ténynek saját horgonyra is szüksége van. Néhány dolog esetében, amit tényként szoktunk felfogni, ez természetesnek tűnhet – például a vásárlás ténye tökéletesen redukálható a „megrendelésre” vagy „átvételre”, egy webhely látogatására egy munkamenetre stb. De vannak olyan tények is, amelyek esetében nem olyan könnyű megtalálni egy ilyen természetes „hordozó tárgyat” - például az áruk maradványai a raktárakban minden nap elején.
Ennek megfelelően nem merülnek fel modularitási problémák a ténykulcs kiterjesztésekor a horgonymodellben (elegendő egy új relációt egyszerűen hozzáadni a megfelelő horgonyhoz), de a tények megjelenítésére szolgáló modell tervezése kevésbé egyértelmű; megjelenhetnek „mesterséges” horgonyok. amelyek homályosan jelenítik meg az üzleti objektummodellt.
Hogyan érhető el a rugalmasság
Az így kapott konstrukció mindkét esetben tartalmazza lényegesen több táblázatmint a hagyományos mérés. De eltarthat lényegesen kevesebb lemezterület ugyanazzal a verziózott attribútumkészlettel, mint a hagyományos dimenzió. Természetesen itt nincs varázslat - minden a normalizálásról szól. Az attribútumok műholdak (az Adattárolóban) vagy egyedi táblák (horgonymodell) közötti elosztásával csökkentjük (vagy teljesen megszüntetjük) egyes attribútumok értékeinek megkettőzése mások megváltoztatásakor.
mert Data Vault a nyeremény az attribútumok szatellitek közötti eloszlásától függ, és Horgonyos modell — szinte egyenesen arányos a mérési objektumonkénti verziók átlagos számával.
A helytakarékosság azonban fontos, de nem fő előnye az attribútumok elkülönített tárolásának. A kapcsolatok külön tárolásával együtt ez a megközelítés teszi a boltot moduláris felépítés. Ez azt jelenti, hogy az egyes attribútumok és a teljes új tématerületek hozzáadása egy ilyen modellhez úgy néz ki felépítmény meglévő objektumok halmazán anélkül, hogy megváltoztatná azokat. És éppen ez teszi rugalmassá a leírt módszertanokat.
Ez is hasonlít a darabgyártásról a tömeggyártásra való átmenetre - ha a hagyományos megközelítésben a modell minden egyes táblázata egyedi és különös figyelmet igényel, akkor a rugalmas módszertanokban ez már szabványos „alkatrészek” halmaza. Egyrészt több tábla van, és az adatok betöltésének és lekérésének folyamatai bonyolultabbnak tűnhetnek. Másrészt válnak tipikus. Ami azt jelenti, hogy lehet automatizált és metaadatvezérelt. A „hogyan fogjuk felrakni?” kérdés, amelynek megválaszolása a fejlesztések tervezési munkája jelentős részét igénybe veheti, most egyszerűen nem éri meg (ahogy a modellváltás hatását a munkafolyamatokra ).
Ez nem jelenti azt, hogy egyáltalán nincs szükség elemzőkre egy ilyen rendszerben – valakinek még át kell dolgoznia az attribútumokkal rendelkező objektumok halmazát, és ki kell találnia, hogy hol és hogyan töltse be az egészet. De a munka mennyisége, valamint a hiba valószínűsége és költsége jelentősen csökken. Mind az elemzési szakaszban, mind az ETL fejlesztése során, ami jelentős részben metaadatok szerkesztésére redukálható.
Sötét oldal
A fentiek mindegyike valóban rugalmassá, technológiailag fejlettsé és iteratív fejlesztésre alkalmassá teszi mindkét megközelítést. Persze van „hordó a kenőcsben” is, amiről szerintem már sejthető.
Az adatfelbontás, amely a rugalmas architektúrák modularitásának hátterében áll, a táblák számának növekedéséhez vezet, és ennek megfelelően felső hogy csatlakozzon mintavételkor. Ahhoz, hogy egy dimenzió összes attribútuma egyszerűen megszerezhető legyen, egy klasszikus üzletben elegendő egy kijelölés, de a rugalmas architektúrához egy egész sor illesztés szükséges. Sőt, ha a jelentések összes összeillesztése előre megírható, akkor azok az elemzők, akik hozzászoktak az SQL kézi írásához, kétszeresen szenvednek.
Több tény is megkönnyíti ezt a helyzetet:
Ha nagy méretekkel dolgozik, annak minden attribútuma szinte soha nem kerül felhasználásra egyszerre. Ez azt jelenti, hogy kevesebb csatlakozás lehet, mint amennyinek első pillantásra tűnik a modellről. A Data Vault figyelembe tudja venni a megosztás várható gyakoriságát is, amikor attribútumokat rendel a műholdakhoz. Ugyanakkor magukra a hubokra vagy horgonyokra elsősorban a helyettesítők generálásához és leképezéséhez van szükség a betöltési szakaszban, és ritkán használják őket lekérdezésekben (ez különösen igaz a horgonyokra).
Minden csatlakozás kulccsal történik. Ezen túlmenően az adatok „tömörítettebb” tárolási módja csökkenti a táblák vizsgálatának többletköltségét ott, ahol szükség van rá (például attribútumérték szerinti szűréskor). Ez oda vezethet, hogy a mintavételezés egy csomó csatlakozással rendelkező normalizált adatbázisból még gyorsabb lesz, mint egy nehéz dimenzió vizsgálata soronként sok verzióval.
Például itt A cikk az Anchor modell teljesítményének részletes összehasonlító tesztjét tartalmazza egy táblázatból vett mintával.
Sok múlik a motoron. Sok modern platform rendelkezik belső csatlakozás-optimalizálási mechanizmusokkal. Például az MS SQL és az Oracle képes „kihagyni” a táblák összekapcsolását, ha az adataikat más összekapcsolások kivételével sehol nem használják, és ez nem befolyásolja a végső kiválasztást (tábla/csatlakozás megszüntetése), és az MPP Vertica , kiváló motornak bizonyult az Anchor Model számára, tekintettel a lekérdezési terv manuális optimalizálására. Másrészt az Anchor Model tárolása például a korlátozott csatlakozási támogatással rendelkező Click House-on még nem tűnik túl jó ötletnek.
Ezen kívül mindkét architektúra esetében létezik különleges mozdulatok, ami megkönnyíti az adatok elérését (mind a lekérdezési teljesítmény szempontjából, mind a végfelhasználók számára). Például, Pont-Idő táblázatok a Data Vault vagy speciális táblázatfunkciók az Anchor modellben.
Összességében
A vizsgált rugalmas architektúrák fő lényege a „design” modularitása.
Ez a tulajdonság lehetővé teszi:
- A metaadatok telepítésével és az alapvető ETL-algoritmusok írásával kapcsolatos kezdeti előkészítés után gyorsan biztosítsa az ügyfélnek az első eredményt néhány forrásobjektumból származó adatokat tartalmazó jelentés formájában. Nem szükséges teljesen átgondolni (még a legfelső szinten sem) a teljes objektummodellt.
- Egy adatmodell elkezdhet működni (és hasznos lehet) mindössze 2-3 objektummal, majd ezután fokozatosan növekedni (ami az Anchor modellt illeti Nikolai szép összehasonlítás a micéliummal).
- A legtöbb fejlesztés, beleértve a témakör bővítését és új források hozzáadását nem befolyásolja a meglévő funkcionalitást, és nem jelent veszélyt a már működő dolgok eltörésére.
- A szabványos elemekre való bontásnak köszönhetően az ilyen rendszerekben az ETL folyamatok ugyanúgy néznek ki, írásuk alkalmas az algoritmizálásra, és végső soron automatizálás.
Ennek a rugalmasságnak az ára teljesítmény. Ez nem jelenti azt, hogy lehetetlen elfogadható teljesítményt elérni az ilyen modelleken. Gyakran előfordulhat, hogy egyszerűen több erőfeszítésre és a részletekre való odafigyelésre van szüksége a kívánt mutatók eléréséhez.
Apps
Entitástípusok Data Vault
További információ a Data Vaultról:
Entitástípusok Horgony modell
További részletek az anchor modellről:
Összefoglaló táblázat a vizsgált megközelítések közös jellemzőivel és különbségeivel:
Forrás: will.com