Varastointikehitys on pitkä ja vakava asia.
Projektin elämässä riippuu paljon siitä, kuinka hyvin objektimalli ja perusrakenne on mietitty alussa.
Yleisesti hyväksytty lähestymistapa on ollut ja on edelleen erilaisia tähtiskeeman yhdistelmiä kolmanteen normaalimuotoon. Pääsääntöisesti periaatteen mukaan: lähtötiedot - 3NF, vitriinit - tähti. Tämä aika-testattu ja monien tutkimusten tukema lähestymistapa on ensimmäinen (ja joskus ainoa) asia, joka tulee kokeneelle DWH-asiantuntijalle mieleen, kun hän miettii, miltä analyysivaraston pitäisi näyttää.
Toisaalta liiketoiminta yleensä ja erityisesti asiakkaiden vaatimukset muuttuvat nopeasti, kun taas data kasvaa sekä "syvyyteen" että "leveyteen". Ja tässä näkyy tähden tärkein haittapuoli - rajoitettu joustavuus.
Ja jos hiljaisessa ja mukavassa elämässäsi DWH-kehittäjänä yhtäkkiä:
- tehtävä syntyi "tehdä ainakin jotain nopeasti, ja sitten nähdään";
- ilmestyi nopeasti kehittyvä projekti, jossa uusia lähteitä yhdistettiin ja liiketoimintamallia muutettiin vähintään kerran viikossa;
- ilmaantui asiakas, jolla ei ole aavistustakaan, miltä järjestelmän pitäisi näyttää ja mitä toimintoja sen tulisi lopulta suorittaa, mutta on valmis kokeiluihin ja johdonmukaiseen halutun tuloksen jalostukseen johdonmukaisella lähestymistavalla;
- projektipäällikkö katsoi sisään hyvillä uutisilla: ”Ja nyt meillä on ketterää!”.
Tai jos olet vain kiinnostunut oppimaan kuinka muuten voit rakentaa säilytystilaa - tervetuloa kissalle!
Mitä "joustavuus" tarkoittaa?
Aluksi määritellään, mitä ominaisuuksia järjestelmällä on oltava, jotta sitä voidaan kutsua "joustavaksi".
Erikseen on syytä mainita, että kuvatut ominaisuudet tulisi viitata erityisesti järjestelmä, ei käsitellä asiaa sen kehitystä. Siksi, jos haluat lukea ketterästä kehitysmetodologiasta, on parempi lukea muita artikkeleita. Esimerkiksi siellä, Habrélla, on paljon mielenkiintoista materiaalia (esim и Ja ).
Tämä ei tarkoita, että kehitysprosessi ja tietovaraston rakenne olisivat täysin riippumattomia. Yleisesti ottaen ketterän tallennustilan ketterän kehittämisen pitäisi olla paljon helpompaa. Käytännössä Klassisen DWH:n ketterässä kehityksessä Kimbalin ja DataVaultin mukaan on kuitenkin enemmän vaihtoehtoja - vesiputouksen mukaan kuin joustavuuden onnellisia yhteensattumia sen kahdessa muodossa yhdessä projektissa.
Mitä ominaisuuksia joustavan varastoinnin pitäisi siis olla? Tässä on kolme kohtaa:
- Varhainen toimitus ja nopea valmistuminen - tämä tarkoittaa sitä, että ihanteellisesti ensimmäinen liiketulos (esimerkiksi ensimmäiset työraportit) tulisi saada mahdollisimman aikaisin, eli jo ennen kuin koko järjestelmä on suunniteltu ja otettu käyttöön. Samanaikaisesti jokaisen myöhemmän tarkistuksen tulisi myös viedä mahdollisimman vähän aikaa.
- Iteratiivinen tarkennus - tämä tarkoittaa, että jokaisen myöhemmän version ei ihannetapauksessa pitäisi vaikuttaa jo toimiviin toimintoihin. Juuri tästä hetkestä tulee usein suurin painajainen suurissa projekteissa - ennemmin tai myöhemmin yksittäiset objektit alkavat hankkia niin paljon suhteita, että on helpompi toistaa logiikka kokonaan kopiossa rinnakkain kuin lisätä kenttä olemassa olevaan taulukkoon. Ja jos olet yllättynyt siitä, että parannusten vaikutusten analysointi olemassa oleviin objekteihin voi kestää kauemmin kuin itse versio, et todennäköisesti ole työskennellyt suurten tietovarastojen kanssa pankki- tai telekommunikaatioalalla.
- Jatkuva sopeutuminen muuttuviin liiketoiminnan vaatimuksiin - Yleistä kohderakennetta ei tulisi suunnitella pelkästään mahdollista laajennusta huomioiden, vaan sillä odotuksella, että tämän seuraavan laajennuksen suuntaa ei suunnitteluvaiheessa voitu edes haaveilla.
Ja kyllä, kaikkien näiden vaatimusten noudattaminen yhdessä järjestelmässä on mahdollista (tietysti tietyissä tapauksissa ja tietyin varauksin).
Alla tarkastellaan kahta suosituinta ketterän suunnittelun menetelmää HD:lle − ankkuri malli и Data Vault. Sulujen ulkopuolella on sellaisia loistavia temppuja, kuten esimerkiksi EAV, 6NF (puhdas muodossa) ja kaikki mikä liittyy NoSQL-ratkaisuihin - ei siksi, että ne olisivat jotenkin huonompia, eikä edes siksi, että artikkeli tässä tapauksessa uhkaisi hankkia volyymin keskiverto väitöskirjasta. Kaikki tämä vain viittaa hieman eri luokan ratkaisuihin - joko tekniikoihin, joita voit soveltaa tietyissä tapauksissa projektisi yleisestä arkkitehtuurista riippumatta (kuten EAV), tai globaalisti erilaisiin tiedontallennusparadigmoihin (kuten graafitietokannat). ja muut vaihtoehdot). NoSQL).
"Klassisen" lähestymistavan ongelmat ja niiden ratkaisut joustavissa metodologioissa
"Klassisella" lähestymistavalla tarkoitan vanhaa hyvää tähteä (riippumatta alla olevien kerrosten erityisestä toteutuksesta, anteeksi Kimballin, Inmonin ja CDM:n kannattajat).
1. Liitosten jäykkä kardinaalisuus
Tämä malli perustuu tiedon selkeään jakoon mitat (mitta) и tosiasiat (fakta). Ja tämä, helvetti, on loogista - loppujen lopuksi tietojen analysointi on suurimmassa osassa tapauksia tiettyjen numeeristen indikaattoreiden (faktien) analysointi tietyissä osissa (ulottuvuuksissa).
Samaan aikaan linkit objektien välillä luodaan linkkien muodossa taulukoiden välillä vieraalla avaimella. Tämä näyttää varsin luonnolliselta, mutta johtaa heti ensimmäiseen joustavuuden rajoitukseen − tiukka määritelmä suhteiden kardinaalisuudesta.
Tämä tarkoittaa, että taulukoiden suunnitteluvaiheessa on määritettävä kullekin toisiinsa liittyvälle objektiparille, voidaanko ne liittyä niin monta-moneen vai vain 1-moneen ja "minne suuntaan". Se riippuu suoraan siitä, millä taulukoista on ensisijainen avain ja missä vierasavain. Tämän suhteen muuttaminen uusien vaatimusten tullessa johtaa todennäköisesti pohjan uudelleenkäsittelyyn.
Esimerkiksi "kassakuitti"-objektia suunnitellessasi myyntiosaston vannottuihin vakuutuksiin luottaen asetit toimintamahdollisuuden yksi ylennys useista tarkistuspaikoista (mutta ei päinvastoin):
Ja hetken kuluttua kollegat esittelivät uuden markkinointistrategian, jossa useita tarjouksia samanaikaisesti. Ja nyt sinun on viimeisteltävä taulukot korostamalla suhde erillisessä objektissa.
(Kaikki johdetut objektit, joihin promo-tarkistus liittyy, on nyt myös parannettavaa).
Linkit Data Vaultissa ja ankkurimallissa
Sellaisen tilanteen välttäminen osoittautui melko yksinkertaiseksi: myyntiosastoon ei tarvitse luottaa, se riittää kaikki suhteet tallennetaan aluksi erillisiin taulukoihin ja käsitellä niin monta-monelle.
Tätä lähestymistapaa on ehdotettu Dan Linstedt osana paradigmaa Data Vault ja täysin tuettu Lars Rönnbäck в Ankkuri malli.
Tämän seurauksena saamme joustavien menetelmien ensimmäisen erottuvan piirteen:
Objektien välisiä suhteita ei tallenneta emokokonaisuuksien attribuutteihin, vaan ne ovat erityyppisiä objekteja.
В Data Vault sellaisia taulukoita kutsutaan Linkkija sisään Ankkuri malli - Solmio. Ensi silmäyksellä ne ovat hyvin samankaltaisia, vaikka niiden erot eivät tyhjennä nimessä (josta keskustellaan jäljempänä). Molemmissa arkkitehtuureissa linkkitaulukot voivat linkittää mikä tahansa määrä kokonaisuuksia (ei välttämättä 2).
Tämä ensisilmäyksellä redundanssi antaa olennaisen joustavuuden valmistumisen yhteydessä. Tällainen rakenne kestää paitsi olemassa olevien linkkien kardinaalisuuden muuttamisen, myös uusien lisäämisen - jos nyt sekkipositiossa on myös linkki sen rikkoneeseen kassaan, tällaisen linkin ilmestyminen on yksinkertaisesti päällysrakenne olemassa olevien taulukoiden päälle vaikuttamatta olemassa oleviin objekteihin ja prosesseihin.
2. Tietojen kopiointi
Toinen joustavilla arkkitehtuureilla ratkaistava ongelma on ensinnäkin vähemmän ilmeinen ja luontainen. mittaustyyppi SCD2 (hitaasti muuttuvat toisen tyypin mitat), vaikkakaan eivät vain ne.
Perinteisessä tallennustilassa ulottuvuus on yleensä taulukko, joka sisältää korvaavan avaimen (PK:na) ja joukon yritysavaimia ja attribuutteja erillisissä sarakkeissa.
Jos ulottuvuus tukee versiointia, versioiden aikarajat lisätään vakiokenttien joukkoon, ja arkistossa näkyy useita versioita lähdekoodin riviä kohden (yksi jokaista versiomuotoisten attribuuttien muutosta kohden).
Jos ulottuvuus sisältää vähintään yhden versioidun attribuutin, joka muuttuu usein, tällaisen ulottuvuuden versioiden määrä on vaikuttava (vaikka muita attribuutteja ei versioita tai ne eivät koskaan muutu), ja jos tällaisia attribuutteja on useita, versioiden määrä voivat kasvaa eksponentiaalisesti niiden lukumäärästä. Tällainen ulottuvuus voi viedä huomattavan määrän levytilaa, vaikka suurin osa siihen tallennetusta tiedosta on yksinkertaisesti kopiot muuttumattomista attribuuttiarvoista muilta riveiltä.
Samalla sitä käytetään myös usein denormalisointi - jotkin attribuutit on tallennettu tarkoituksella arvoiksi, ei viittauksiksi tietokirjaan tai muuhun ulottuvuuteen. Tämä lähestymistapa nopeuttaa tietojen käyttöä vähentämällä liitosten määrää ulottuvuutta käytettäessä.
Tyypillisesti tämä johtaa samat tiedot tallennetaan samanaikaisesti useaan paikkaan. Esimerkiksi tiedot asuinalueesta ja asiakaskategorian kuulumisesta voidaan tallentaa samanaikaisesti mittoihin ”Asiakas” ja faktat ”Osto”, ”Toimitus” ja ”Puhelinkeskuksen yhteystiedot” sekä linkkitaulukko “Asiakas - Asiakaspäällikkö”.
Yleisesti ottaen yllä oleva koskee tavallisia (versioimattomia) mittauksia, mutta versioiduissa mittauksissa niillä voi olla eri mittakaava: objektin uuden version ilmestyminen (etenkin jälkikäteen ajatellen) ei johda pelkästään kaikkien asiaan liittyvien taulukoiden päivittämiseen, vaan toisiinsa liittyvien objektien uusien versioiden peräkkäiseen ilmestymiseen - kun taulukkoa 1 käytetään taulukon 2 rakentamiseen ja taulukkoa 2 taulukon 3 rakentamiseen ja niin edelleen. Vaikka taulukon 1 rakentamiseen ei liity yhtään taulukon 3 attribuuttia (ja muita muista lähteistä saatuja taulukon 2 attribuutteja on mukana), tämän konstruktion versiointi johtaa ainakin ylimääräisiin yleiskustannuksiin ja korkeintaan lisäversiot taulukossa 3, joka ei yleensä liity siihen, ja ketjun alempana.
3. Jalostuksen epälineaarinen monimutkaisuus
Samanaikaisesti jokainen uusi myymälä, joka rakennetaan toisen päälle, lisää paikkojen määrää, joissa tiedot voivat "poistua", kun ETL:ään tehdään muutoksia. Tämä puolestaan johtaa jokaisen myöhemmän version monimutkaisuuteen (ja kestoon).
Jos yllä oleva koskee järjestelmiä, joissa on harvoin muokattuja ETL-prosesseja, voit elää tällaisessa paradigmassa - varmista vain, että uudet parannukset tehdään oikein kaikkiin liittyviin objekteihin. Jos muutoksia tehdään usein, useiden linkkien vahingossa "puuttumisen" todennäköisyys kasvaa merkittävästi.
Jos lisäksi otamme huomioon, että "versioitu" ETL on paljon monimutkaisempi kuin "versioimaton", on melko vaikeaa välttää virheitä koko tämän talouden jatkuvan jalostamisen aikana.
Objektien ja attribuuttien tallentaminen Data Vaultiin ja ankkurimalliin
Joustavien arkkitehtuurien tekijöiden ehdottama lähestymistapa voidaan muotoilla seuraavasti:
On tarpeen erottaa se, mikä muuttuu, siitä, mikä pysyy muuttumattomana. Tämä tarkoittaa avainten tallentamista erillään määritteistä.
Älä kuitenkaan sekoita ei versioitu attribuutti kanssa muuttumattomana: ensimmäinen ei tallenna muutoshistoriaansa, mutta voi muuttua (esimerkiksi syöttövirheen korjaamisen tai uutta dataa vastaanotettaessa), toinen ei muutu koskaan.
Näkemykset siitä, mitä tarkalleen ottaen voidaan pitää muuttumattomana Data Vault- ja Anchor-mallissa, eroavat.
Arkkitehtuurin kannalta Data Vault, voidaan pitää ennallaan koko avainsarja — luonnollinen (organisaation TIN-koodi, tuotekoodi lähdejärjestelmässä jne.) ja korvike. Samanaikaisesti loput attribuutit voidaan jakaa ryhmiin muutosten lähteen ja/tai tiheyden mukaan ja Pidä jokaiselle ryhmälle erillinen pöytä itsenäisellä versiosarjalla.
Samassa paradigmassa Ankkuri malli pidetään ennallaan vain korvaava avain kokonaisuuksia. Kaikki muu (mukaan lukien luonnolliset avaimet) on vain erikoistapaus sen attribuuteista. Jossa kaikki attribuutit ovat oletusarvoisesti riippumattomia toisistaan, joten jokaiselle määritteelle on luotava erillinen pöytä.
В Data Vault entiteettiavaimet sisältävät taulukot kutsutaan Hubami (keskitin). Keskittimet sisältävät aina kiinteän joukon kenttiä:
- Luonnollisen kokonaisuuden avaimet
- Korjaava avain
- Linkki lähteeseen
- Tallennusaika
Merkinnät Hubsissa ei koskaan muutu eikä niillä ole versioita. Ulkoisesti keskittimet ovat hyvin samankaltaisia kuin ID-karttataulukot, joita käytetään joissakin järjestelmissä korvikkeiden luomiseen, mutta on suositeltavaa käyttää Data Vaultin korvikkeena ei kokonaislukusekvenssiä, vaan tiivistettä yritysavainjoukosta. Tämä lähestymistapa yksinkertaistaa linkkien ja attribuuttien lataamista lähteistä (ei tarvitse liittyä keskittimeen korvikkeen saamiseksi, vain laskee hash luonnollisesta avaimesta), mutta se voi aiheuttaa muita ongelmia (esimerkiksi törmäyksissä, kirjainkoolla ja ei- merkkien tulostaminen merkkijononäppäimissä jne. .p.), joten sitä ei yleisesti hyväksytä.
Kaikki muut entiteettiattribuutit tallennetaan erityisiin taulukoihin nimeltä Satelliitit (satelliitti). Yhdessä keskittimessä voi olla useita satelliitteja, jotka tallentavat erilaisia attribuutteja.
Attribuuttien jakautuminen satelliittien kesken tapahtuu periaatteen mukaisesti yhteinen muutos - yhteen satelliittiin voidaan tallentaa versioimattomia määritteitä (esimerkiksi henkilön syntymäaika ja SNILS), toiseen - harvoin muuttuvat versiot (esim. sukunimi ja passin numero), kolmanteen - usein muuttuvat (esimerkiksi toimitusosoite, luokka, viimeinen tilauspäivä jne.). Versiointi suoritetaan tässä tapauksessa yksittäisten satelliittien, ei kokonaisuuden tasolla, joten attribuutit on suositeltavaa jakaa siten, että versioiden leikkaus yhden satelliitin sisällä on minimaalinen (mikä vähentää kokonaismäärää tallennetuista versioista).
Lisäksi tietojen latausprosessin optimoimiseksi eri lähteistä saadut attribuutit sijoitetaan usein eri satelliitteihin.
Satelliitit kommunikoivat Hubin kanssa vieras avain (joka vastaa 1-moneen kardinaliteettia). Tämä tarkoittaa, että tämä "oletusarkkitehtuuri" tukee useita attribuuttiarvoja (esimerkiksi useita saman asiakkaan yhteyshenkilön puhelinnumeroita).
В Ankkuri malli avaimet tallentavia taulukoita kutsutaan Ankkurit. Ja he pitävät:
- Vain korvaavat avaimet
- Linkki lähteeseen
- Tallennusaika
Luonnolliset avaimet ankkurimallin näkökulmasta otetaan huomioon tavallisia ominaisuuksia. Tämä vaihtoehto saattaa tuntua vaikeammin ymmärrettävältä, mutta se antaa paljon enemmän tilaa kohteen tunnistamiseen.
Esimerkiksi, jos tietoa samasta entiteetistä voi tulla eri järjestelmistä, joista jokainen käyttää omaa luonnollista avaimeansa. Data Vaultissa tämä voi johtaa useiden keskittimien melko hankalia rakenteita (yksi lähdettä kohti + yhdistävä pääversio), kun taas Anchor-mallissa kunkin lähteen luonnollinen avain kuuluu omaan attribuuttiinsa ja sitä voidaan käyttää latauksessa itsenäisesti. kaikki muut.
Mutta tässä piilee yksi salakavala hetki: jos eri järjestelmien attribuutteja yhdistetään yhdeksi kokonaisuudeksi, todennäköisesti niitä on liimasäännöt, jolla järjestelmän on ymmärrettävä, että eri lähteistä tulevat tietueet vastaavat yhtä kokonaisuuden esiintymää.
В Data Vault nämä säännöt määräävät todennäköisesti muodostumisen pääkokonaisuuden "korvauskeskus". eikä millään tavalla vaikuta keskittimiin, jotka tallentavat lähteiden luonnolliset avaimet ja niiden alkuperäiset attribuutit. Jos yhdistämisen säännöt (tai yhdistämiseen käytetyt attribuutit) muuttuvat jossain vaiheessa, riittää, että muodostetaan korvaavat keskittimet uudelleen.
В ankkuri malli tällainen kokonaisuus todennäköisesti tallennetaan yksittäinen ankkuri. Tämä tarkoittaa, että kaikki attribuutit, riippumatta siitä, mistä lähteestä ne on saatu, sidotaan samaan korvikkeeseen. Virheellisesti yhdistettyjen tietueiden erottaminen ja yleensä yhdistämisen merkityksen seuraaminen tällaisessa järjestelmässä voi olla paljon vaikeampaa, varsinkin jos säännöt ovat melko monimutkaisia ja muuttuvat usein ja sama attribuutti voidaan saada eri lähteistä (vaikka se on ehdottomasti mahdollista, koska jokainen määriteversio säilyttää viittauksen alkuperäänsä).
Joka tapauksessa, jos järjestelmäsi on tarkoitus toteuttaa toiminnallisuus duplikoinnin poistaminen, tietueiden yhdistäminen ja muut MDM-elementit, sinun tulee erityisen huolellisesti lukea luonnollisten avainten tallentamiseen liittyvät näkökohdat joustaviin menetelmiin. Ehkä Data Vaultin raskaampi muotoilu on yhtäkkiä turvallisempi yhdistämisvirheiden kannalta.
ankkuri malli tarjoaa myös ylimääräisen objektityypin nimeltä Solmu itse asiassa se on erikoista degeneroitunut ankkurityyppi, joka voi sisältää vain yhden määritteen. Solmuja on tarkoitus käyttää tasaisten hakemistojen tallentamiseen (esimerkiksi sukupuoli, siviilisääty, asiakaspalveluluokka jne.). Toisin kuin Anchor, Knot ei liity määritetaulukoita, ja sen ainoa attribuutti (nimi) on aina tallennettu samaan taulukkoon avaimen kanssa. Solmut on linkitetty ankkureihin sidostaulukoilla (Tie) samalla tavalla kuin ankkurit on kytketty toisiinsa.
Solmujen käytöstä ei ole yksiselitteistä mielipidettä. Esimerkiksi, , joka edistää aktiivisesti Ankkurimallin käyttöä Venäjällä, uskoo (ei kohtuuttomasti), että yhdestä hakuteoksesta on mahdotonta sanoa, että hän aina on staattinen ja yksitasoinen, joten on parempi käyttää täysimittaista ankkuria kaikille kohteille kerralla.
Toinen tärkeä ero Data Vaultin ja Anchor Modelin välillä on läsnäolo linkkien attribuutit:
В Data Vault Linkit ovat samoja täysimittaisia objekteja kuin Hubit, ja niillä voi olla omat attribuutit. Sisään ankkuri malli Linkkejä käytetään vain yhdistämään Ankkurit ja ei voi olla omia ominaisuuksiaan. Tämä ero johtaa merkittävästi erilaisiin mallinnusmenetelmiin. tosiasiat, josta keskustellaan seuraavaksi.
Faktan tallennus
Toistaiseksi olemme puhuneet lähinnä mallintamisesta mittaamisesta. Tosiasiat ovat hieman epäselvempiä.
В Data Vault tyypillinen objekti tosiasioiden tallentamiseen − Linkki, jonka satelliitteihin on lisätty todellisia indikaattoreita.
Tämä lähestymistapa näyttää olevan intuitiivinen. Se tarjoaa helpon pääsyn analysoituihin indikaattoreihin ja on yleensä samanlainen kuin perinteinen tietotaulukko (vain indikaattoreita ei tallenneta itse taulukkoon, vaan "viereiseen taulukkoon"). Mutta on myös sudenkuoppia: yksi mallin tyypillisistä parannuksista - tosiasiaavaimen laajentaminen - tekee sen välttämättömäksi uuden vierasavaimen lisääminen linkkiin. Ja tämä puolestaan "rikkoo" modulaarisuuden ja mahdollisesti aiheuttaa parannuksia muihin objekteihin.
В ankkuri malli Linkillä ei voi olla omia attribuuttejaan, joten tämä lähestymistapa ei toimi - ehdottomasti kaikki attribuutit ja indikaattorit on linkitettävä yhteen tiettyyn ankkuriin. Johtopäätös tästä on yksinkertainen - jokainen tosiasia tarvitsee myös oman ankkurin. Joillekin asioille, joita olemme tottuneet pitämään tosiasioina, tämä voi tuntua luonnolliselta - esimerkiksi ostotapahtuma pelkistyy täydellisesti kohteeseen "tilaus" tai "kuitti", sivustolla käynti pelkistyy istuntoksi jne. Mutta on myös tosiasioita, joille ei ole niin helppoa löytää sellaista luonnollista "kuljetuskohdetta" - esimerkiksi tavaratase varastoissa jokaisen päivän alussa.
Vastaavasti modulaarisuuden kanssa ei ole ongelmia laajennettaessa fakta-avainta Ankkurimallissa (riittää vain lisätä uusi suhde vastaavaan ankkuriin), mutta mallin suunnittelu näyttämään tosiasiat on vähemmän yksinkertaista, "keinotekoisia" ankkureita saattaa ilmestyä. jotka heijastavat yrityksen objektimallia, eivät ole ilmeisiä.
Miten joustavuus saavutetaan
Tuloksena oleva rakenne molemmissa tapauksissa sisältää huomattavasti enemmän pöytiäkuin perinteinen mittaus. Mutta se voi kestää huomattavasti vähemmän levytilaa jossa on samat versioidut attribuutit kuin perinteisessä ulottuvuudessa. Luonnollisesti tässä ei ole taikuutta - kyse on normalisoinnista. Jakamalla attribuutteja satelliiteille (Data Vaultissa) tai yksittäisille taulukoille (ankkurimalli), vähennämme (tai poistamme kokonaan) joidenkin attribuuttien arvojen kopioiminen toisia muuttaessaan.
varten Data Vault vahvistus riippuu attribuuttien jakautumisesta satelliittien kesken ja ankkuri malli — on lähes suoraan verrannollinen versioiden keskimääräiseen lukumäärään mittauskohdetta kohti.
Tilan vieminen on kuitenkin tärkeä, mutta ei tärkein etu attribuuttien tallentamisesta erikseen. Yhdessä linkkien erillisen tallennuksen kanssa tämä lähestymistapa tekee tallennuksen modulaarinen muotoilu. Tämä tarkoittaa, että sekä yksittäisten attribuuttien että kokonaan uusien aihealueiden lisääminen tällaiseen malliin näyttää päällysrakenne olemassa olevan objektijoukon päälle muuttamatta niitä. Ja juuri tämä tekee kuvatuista menetelmistä joustavia.
Se muistuttaa myös siirtymistä kappaletuotannosta massatuotantoon - jos perinteisessä lähestymistavassa jokainen mallitaulukko on ainutlaatuinen ja vaatii erillistä huomiota, niin joustavissa metodologioissa se on jo joukko tyypillisiä "yksityiskohtia". Toisaalta taulukoita on enemmän, tietojen lataus- ja hakuprosessien pitäisi näyttää monimutkaisemmalta. Toisaalta niistä tulee tyypillinen. Tämä tarkoittaa, että niitä voi olla automatisoitu ja hallinnoitu metatietojen avulla. Kysymys "miten aiomme laatia sen?", johon vastaus voisi viedä merkittävän osan parannusten suunnittelutyöstä, ei nyt yksinkertaisesti ole sen arvoinen (kuten kysymys mallin muuttamisen vaikutuksista työprosessit).
Tämä ei tarkoita, että analyytikot tällaisessa järjestelmässä eivät ole ollenkaan tarpeen - jonkun on silti tehtävä joukko objekteja attribuutteineen ja selvitettävä, missä ja miten se ladataan. Mutta työn määrä sekä virheen todennäköisyys ja kustannukset vähenevät merkittävästi. Sekä analyysivaiheessa että ETL:n kehitysvaiheessa, joka voidaan suurelta osin rajoittua metatietojen muokkaamiseen.
Pimeä puoli
Kaikki yllä oleva tekee molemmista lähestymistavoista todella joustavia, valmistavia ja sopivia iteratiiviseen jalostukseen. Tietysti on myös "tervatynnyri", josta luulen jo tietävän.
Joustavien arkkitehtuurien modulaarisuuden taustalla oleva tiedon hajoaminen johtaa taulukkojen määrän kasvuun ja vastaavasti yläpuolella liitoksia haettaessa. Jotta dimension kaikki attribuutit saadaan yksinkertaisesti, yksi valinta riittää klassiseen tallennustilaan, ja joustava arkkitehtuuri vaatii useita liitoksia. Lisäksi, jos raportteja varten kaikki nämä liitokset voidaan kirjoittaa etukäteen, analyytikot, jotka ovat tottuneet kirjoittamaan SQL:ää käsin, kärsivät kaksinkertaisesti.
On olemassa useita tosiasioita, jotka helpottavat tilannetta:
Kun työskentelet suurilla mitoilla, melkein kaikkia sen ominaisuuksia ei käytetä koskaan samanaikaisesti. Tämä tarkoittaa, että liitoksia voi olla vähemmän kuin miltä mallista ensi silmäyksellä näyttää. Data Vaultissa voit myös ottaa huomioon odotetun jakamistiheyden, kun määrität määritteitä satelliiteille. Samanaikaisesti itse keskittimiä tai ankkureita tarvitaan ensisijaisesti korvikkeiden luomiseen ja kartoittamiseen latausvaiheessa, ja niitä käytetään harvoin kyselyissä (tämä pätee erityisesti ankkureihin).
Kaikki liitokset avaimella. Lisäksi "pakattu" tapa tallentaa tietoja vähentää taulukoiden skannauskustannuksia siellä, missä sitä tarvitaan (esimerkiksi attribuutin arvon perusteella suodatettaessa). Tämä voi johtaa siihen, että noutaminen normalisoidusta tietokannasta, jossa on joukko liitoksia, on jopa nopeampaa kuin yhden raskaan ulottuvuuden skannaus, jossa on paljon versioita riviä kohden.
Esimerkiksi täällä artikkelissa on yksityiskohtainen vertaileva Anchor-mallin suorituskykytesti valinnalla yhdestä taulukosta.
Paljon riippuu moottorista. Monilla nykyaikaisilla alustoilla on sisäiset mekanismit liitosten optimoimiseksi. Esimerkiksi MS SQL ja Oracle voivat "ohittaa" liitokset taulukoihin, jos niiden tietoja ei käytetä missään muualla paitsi muissa liitoksissa, eivätkä ne vaikuta lopulliseen valintaan (taulukon/liitoksen eliminointi), kun taas MPP Vertica , osoittautui erinomaiseksi moottoriksi ankkurimallille, kyselysuunnitelman manuaalisella optimoinnilla. Toisaalta Anchor Modelin tallentaminen esimerkiksi Click Houseen, jolla on rajallinen tuki liittymiselle, ei vaikuta vielä hyvältä ajatukselta.
Lisäksi molemmille arkkitehtuureille on olemassa erikoisia temppuja, jotka helpottavat tietojen käyttöä (sekä kyselyn suorituskyvyn että loppukäyttäjien kannalta). Esimerkiksi, Point-in-time taulukot Data Vaultissa tai erityisiä taulukkotoimintoja ankkurimallissa.
Yhteensä
Tarkastettujen joustavien arkkitehtuurien pääolemus on niiden "suunnittelun" modulaarisuus.
Tämä ominaisuus mahdollistaa:
- Metatietojen käyttöönottoon ja ETL-perusalgoritmien kirjoittamiseen liittyvän alustavan valmistelun jälkeen antaa asiakkaalle nopeasti ensimmäisen tuloksen muutaman raportin muodossa, jotka sisältävät tietoja vain muutamista lähdeobjekteista. Tätä varten ei ole välttämätöntä ajatella (edes huipputasolla) koko objektimallia.
- Tietomalli voi alkaa toimia (ja hyödyllinen) vain 2-3 objektin kanssa ja sitten kasvaa vähitellen (koskien Anchor-mallia Nikolay kaunis vertailu myseeliin).
- Useimmat parannukset, mukaan lukien aihealueen laajentaminen ja uusien lähteiden lisääminen ei vaikuta olemassa oleviin toimintoihin eikä aiheuta vaaraa rikkoa jotain jo toimivaa.
- Standardielementeiksi hajotuksen ansiosta ETL-prosessit näyttävät tällaisissa järjestelmissä samalta, niiden kirjoittaminen soveltuu algoritmisointiin ja viime kädessä automaatio.
Tämän joustavuuden hinta on tuottavuus. Tämä ei tarkoita, että tällaisilla malleilla olisi mahdotonta saavuttaa hyväksyttävää suorituskykyä. Useimmiten saatat tarvita enemmän vaivaa ja huomiota yksityiskohtiin haluttujen mittareiden saavuttamiseksi.
Sovellukset
Entiteettityypit Data Vault
Lisätietoja Data Vaultista:
Entiteettityypit Ankkuri malli
Lisää Anchor-mallista:
Yhteenvetotaulukko, jossa on yhteisiä piirteitä ja eroja harkittujen lähestymistapojen välillä:
Lähde: will.com