Het ontwikkelen van een opslagfaciliteit is een lange en serieuze onderneming.
Veel in de levensduur van een project hangt af van hoe goed het objectmodel en de basisstructuur in het begin zijn doordacht.
De algemeen aanvaarde aanpak was en blijft verschillende varianten van het combineren van het sterrenstelsel met de derde normaalvorm. In de regel volgens het principe: initiële gegevens - 3NF, vitrines - ster. Deze aanpak, beproefd en ondersteund door een grote hoeveelheid onderzoek, is het eerste (en soms het enige) dat in de geest van een ervaren DWH-specialist opkomt als hij nadenkt over hoe een analytische repository eruit zou moeten zien.
Aan de andere kant hebben het bedrijfsleven in het algemeen en de eisen van de klant in het bijzonder de neiging snel te veranderen, en hebben gegevens de neiging om zowel ‘in de diepte’ als ‘in de breedte’ te groeien. En dit is waar het grootste nadeel van een ster verschijnt: beperkt flexibiliteit.
En als je in je rustige en gezellige leven als DWH-ontwikkelaar ineens:
- de taak ontstond “om in ieder geval snel iets te doen, en dan zullen we zien”;
- er verscheen een zich snel ontwikkelend project, waarbij nieuwe bronnen werden aangesloten en het bedrijfsmodel minstens één keer per week werd herzien;
- er is een klant verschenen die geen idee heeft hoe het systeem eruit moet zien en welke functies het uiteindelijk moet vervullen, maar bereid is om te experimenteren en het gewenste resultaat consequent te verfijnen en er steeds dichter bij te komen;
- De projectmanager kwam langs met het goede nieuws: “En nu hebben we agile!”
Of als u gewoon wilt weten hoe u nog meer opslagfaciliteiten kunt bouwen: welkom bij de sectie!
Wat betekent ‘flexibiliteit’?
Laten we eerst definiëren welke eigenschappen een systeem moet hebben om “flexibel” genoemd te worden.
Afzonderlijk is het de moeite waard te vermelden dat de beschreven eigenschappen specifiek betrekking moeten hebben op systeem, niet naar proces zijn ontwikkeling. Als je dus meer wilt lezen over Agile als ontwikkelmethodologie, kun je beter andere artikelen lezen. Daar, op Habré, zijn er bijvoorbeeld veel interessante materialen (zoals и En ).
Dit betekent niet dat het ontwikkelingsproces en de structuur van het datawarehouse volledig los van elkaar staan. Over het geheel genomen zou het aanzienlijk eenvoudiger moeten zijn om een Agile repository voor een agile architectuur te ontwikkelen. In de praktijk zijn er echter vaker opties met Agile-ontwikkeling van de klassieke DWH volgens Kimbal en DataVault - volgens Waterfall - dan gelukkige toevalligheden van flexibiliteit in zijn twee vormen op één project.
Welke mogelijkheden moet flexibele opslag hebben? Er zijn hier drie punten:
- Vroege levering en snelle afhandeling - dit betekent dat idealiter het eerste bedrijfsresultaat (bijvoorbeeld de eerste werkrapporten) zo vroeg mogelijk moet worden verkregen, dat wil zeggen nog voordat het hele systeem volledig is ontworpen en geïmplementeerd. Bovendien moet elke volgende revisie ook zo min mogelijk tijd in beslag nemen.
- Iteratieve verfijning - dit betekent dat elke volgende verbetering idealiter geen invloed mag hebben op de functionaliteit die al werkt. Het is dit moment dat vaak de grootste nachtmerrie wordt bij grote projecten: vroeg of laat beginnen individuele objecten zoveel verbindingen te krijgen dat het gemakkelijker wordt om de logica volledig te herhalen in een kopie in de buurt dan om een veld aan een bestaande tabel toe te voegen. En als je verbaasd bent dat het analyseren van de impact van verbeteringen op bestaande objecten meer tijd kan kosten dan de verbeteringen zelf, dan heb je hoogstwaarschijnlijk nog niet met grote datawarehouses in de bank- of telecomsector gewerkt.
- Voortdurend aanpassen aan veranderende zakelijke vereisten - de algehele objectstructuur moet niet alleen worden ontworpen met inachtneming van mogelijke uitbreidingen, maar met de verwachting dat de richting van deze volgende uitbreiding in de ontwerpfase niet eens te dromen was.
En ja, het is mogelijk om aan al deze eisen in één systeem te voldoen (uiteraard in bepaalde gevallen en met enig voorbehoud).
Hieronder zal ik twee van de meest populaire agile ontwerpmethodologieën voor datawarehouses beschouwen: Ankermodel и Gegevenskluis. Buiten de haakjes zijn zulke uitstekende technieken als bijvoorbeeld EAV, 6NF (in zijn pure vorm) en alles wat met NoSQL-oplossingen te maken heeft - niet omdat ze op de een of andere manier slechter zijn, en zelfs niet omdat in dit geval het artikel zou dreigen te verwerven het volume van de gemiddelde disser. Het is alleen zo dat dit allemaal betrekking heeft op oplossingen van een iets andere klasse - hetzij op technieken die u in specifieke gevallen kunt gebruiken, ongeacht de algemene architectuur van uw project (zoals EAV), hetzij op globaal andere paradigma's voor informatieopslag (zoals grafische databases en andere opties NoSQL).
Problemen van de “klassieke” aanpak en hun oplossingen in flexibele methodologieën
Met “klassieke” aanpak bedoel ik de goede oude ster (ongeacht de specifieke implementatie van de onderliggende lagen, mogen de volgers van Kimball, Inmon en CDM mij vergeven).
1. Starre kardinaliteit van verbindingen
Dit model is gebaseerd op een duidelijke indeling van gegevens in Dimensie и feiten. En dit is, verdomd, logisch - data-analyse komt in de overgrote meerderheid van de gevallen immers neer op de analyse van bepaalde numerieke indicatoren (feiten) in bepaalde secties (dimensies).
In dit geval worden verbindingen tussen objecten tot stand gebracht in de vorm van relaties tussen tabellen met behulp van een externe sleutel. Dit lijkt heel natuurlijk, maar leidt meteen tot de eerste beperking van de flexibiliteit: strikte definitie van de kardinaliteit van verbindingen.
Dit betekent dat u in de tabelontwerpfase voor elk paar gerelateerde objecten nauwkeurig moet bepalen of ze een relatie kunnen hebben van veel-op-veel, of slechts 1-op-veel, en “in welke richting”. Dit bepaalt direct welke tabel de primaire sleutel zal hebben en welke de refererende sleutel zal hebben. Het veranderen van deze houding wanneer er nieuwe eisen worden gesteld, zal hoogstwaarschijnlijk leiden tot een herwerking van de basis.
Bij het ontwerpen van het object 'kassabon' hebt u bijvoorbeeld, vertrouwend op de eed van de verkoopafdeling, de mogelijkheid van actie vastgelegd één promotie voor meerdere controleposities (maar niet andersom):
En na verloop van tijd introduceerden collega’s een nieuwe marketingstrategie waarin ze vanuit dezelfde positie kunnen handelen meerdere promoties tegelijk. En nu moet u de tabellen aanpassen door de relatie in een afzonderlijk object te scheiden.
(Alle afgeleide objecten waarin de promotiecontrole is samengevoegd, moeten nu ook worden verbeterd).
Relaties in datakluis en ankermodel
Het vermijden van deze situatie bleek vrij eenvoudig: je hoeft de verkoopafdeling hiervoor niet te vertrouwen. alle verbindingen worden in eerste instantie in aparte tabellen opgeslagen en verwerk het als veel-op-veel.
Deze aanpak werd voorgesteld Dan Linstedt als onderdeel van het paradigma Gegevenskluis en volledig ondersteund Lars Ronnback в Ankermodel.
Als gevolg hiervan krijgen we het eerste onderscheidende kenmerk van flexibele methodologieën:
Relaties tussen objecten worden niet opgeslagen in attributen van bovenliggende entiteiten, maar vormen een afzonderlijk type object.
В Gegevenskluis dergelijke koppeltabellen worden genoemd Linken in Ankermodel - Binden. Op het eerste gezicht lijken ze erg op elkaar, hoewel hun verschillen niet eindigen bij de naam (die hieronder zal worden besproken). In beide architecturen kunnen koppelingstabellen worden gekoppeld een willekeurig aantal entiteiten (niet noodzakelijkerwijs 2).
Deze redundantie biedt op het eerste gezicht aanzienlijke flexibiliteit voor wijzigingen. Een dergelijke structuur wordt niet alleen tolerant ten aanzien van veranderingen in de kardinaliteit van bestaande koppelingen, maar ook ten aanzien van de toevoeging van nieuwe. Als nu ook een chequepositie een koppeling heeft met de kassier die deze heeft doorbroken, zal de verschijning van een dergelijke koppeling eenvoudigweg een add-on worden voor bestaande tabellen zonder bestaande objecten en processen te beïnvloeden.
2. Gegevensduplicatie
Het tweede probleem dat door flexibele architecturen wordt opgelost, ligt minder voor de hand en is in de eerste plaats inherent. Metingen van het SCD2-type (langzaam veranderende afmetingen van het tweede type), hoewel niet alleen zij.
In een klassiek magazijn is een dimensie doorgaans een tabel die een surrogaatsleutel (als PK) en een reeks bedrijfssleutels en attributen in afzonderlijke kolommen bevat.
Als een dimensie versiebeheer ondersteunt, worden er grenzen voor de geldigheid van versies toegevoegd aan de standaardset velden, en verschijnen er voor één rij in de bron meerdere versies in de repository (één voor elke wijziging in versiekenmerken).
Als een dimensie ten minste één vaak veranderend versie-attribuut bevat, zal het aantal versies van een dergelijke dimensie indrukwekkend zijn (zelfs als de resterende attributen geen versie hebben of nooit veranderen), en als er meerdere van dergelijke attributen zijn, kan het aantal versies exponentieel groeien ten opzichte van hun aantal. Deze dimensie kan een aanzienlijke hoeveelheid schijfruimte in beslag nemen, hoewel veel van de gegevens die erin worden opgeslagen eenvoudigweg duplicaten zijn van onveranderlijke attribuutwaarden uit andere rijen.
Tegelijkertijd wordt het ook heel vaak gebruikt denormalisatie — sommige attributen worden opzettelijk opgeslagen als een waarde, en niet als een link naar een naslagwerk of een andere dimensie. Deze aanpak versnelt de toegang tot gegevens, waardoor het aantal joins bij toegang tot een dimensie wordt verminderd.
Meestal leidt dit tot dezelfde informatie wordt op meerdere plaatsen tegelijkertijd opgeslagen. Informatie over de woonregio en de categorie van de klant kan bijvoorbeeld tegelijkertijd worden opgeslagen in de dimensies “Klant” en de feiten “Aankoop”, “Bezorging” en “Callcenteroproepen”, evenals in de rubriek “Klant - Klantmanager ” linktabel.
Over het algemeen is het hierboven beschreven van toepassing op reguliere (niet-versieversies) dimensies, maar in versieversies kunnen ze een andere schaal hebben: het verschijnen van een nieuwe versie van een object (vooral achteraf) leidt niet alleen tot het bijwerken van alle gerelateerde tabellen, maar aan de trapsgewijze verschijning van nieuwe versies van gerelateerde objecten - wanneer Tabel 1 wordt gebruikt om Tabel 2 samen te stellen, en Tabel 2 wordt gebruikt om Tabel 3 samen te stellen, enz. Zelfs als er geen enkel attribuut uit Tabel 1 betrokken is bij de constructie van Tabel 3 (en er wel andere attributen uit Tabel 2 uit andere bronnen bij betrokken zijn), zal het versiebeheer van deze constructie op zijn minst leiden tot extra overhead, en maximaal tot extra kosten. versies in Tabel 3. wat er helemaal niets mee te maken heeft, en verderop in de keten.
3. Niet-lineaire complexiteit van herbewerking
Tegelijkertijd vergroot elke nieuwe winkelpui die op basis van een andere wordt gebouwd het aantal plaatsen waar gegevens kunnen ‘uiteenlopen’ wanneer er wijzigingen in de ETL worden aangebracht. Dit leidt op zijn beurt tot een toename van de complexiteit (en duur) van elke volgende herziening.
Als het bovenstaande systemen beschrijft met zelden gewijzigde ETL-processen, kun je in zo'n paradigma leven - je hoeft er alleen maar voor te zorgen dat nieuwe wijzigingen correct worden aangebracht in alle gerelateerde objecten. Als er regelmatig revisies plaatsvinden, neemt de kans op het per ongeluk ‘missen’ van meerdere verbindingen aanzienlijk toe.
Als we er bovendien rekening mee houden dat “versiegebonden” ETL aanzienlijk ingewikkelder is dan een “niet-versiegebonden” ETL, wordt het behoorlijk moeilijk om fouten te vermijden bij het regelmatig bijwerken van deze hele faciliteit.
Objecten en attributen opslaan in Data Vault en Ankermodel
De door de auteurs van flexibele architecturen voorgestelde aanpak kan als volgt worden geformuleerd:
Het is noodzakelijk om onderscheid te maken tussen wat verandert en wat hetzelfde blijft. Dat wil zeggen: bewaar sleutels gescheiden van attributen.
Men moet echter niet verwarren niet versiebeheer attribuut mee onveranderd: de eerste bewaart de geschiedenis van zijn wijzigingen niet, maar kan veranderen (bijvoorbeeld bij het corrigeren van een invoerfout of het ontvangen van nieuwe gegevens); de tweede verandert nooit.
Over wat precies als onveranderlijk kan worden beschouwd in de Data Vault en het Ankermodel lopen de meningen uiteen.
Vanuit architectonisch oogpunt Gegevenskluis, kan als onveranderd worden beschouwd hele set sleutels - natuurlijk (FIN van de organisatie, productcode in het bronsysteem etc.) en surrogaat. In dit geval kunnen de resterende attributen in groepen worden verdeeld op basis van de bron en/of frequentie van wijzigingen en Zorg voor een aparte tabel voor elke groep met een onafhankelijke reeks versies.
In het paradigma Anker model onveranderd beschouwd enige surrogaatsleutel essence. Al het andere (inclusief natuurlijke sleutels) is slechts een speciaal geval van zijn attributen. Waarin alle attributen zijn standaard onafhankelijk van elkaar, dus voor elk attribuut a aparte tafel.
В Gegevenskluis tabellen met entiteitssleutels worden aangeroepen Hubami. Hubs bevatten altijd een vaste set velden:
- Natuurlijke entiteitssleutels
- Vervangende sleutel
- Link naar bron
- Registreer de toegevoegde tijd
Berichten in Hubs veranderen nooit en hebben geen versies. Extern lijken hubs sterk op ID-map-type tabellen die in sommige systemen worden gebruikt om surrogaten te genereren. Het wordt echter aanbevolen om een hash van een set bedrijfssleutels te gebruiken als surrogaten in Data Vault. Deze aanpak vereenvoudigt het laden van relaties en attributen uit bronnen (u hoeft zich niet bij de hub aan te sluiten om een surrogaat te krijgen, bereken gewoon de hash van een natuurlijke sleutel), maar kan andere problemen veroorzaken (bijvoorbeeld gerelateerd aan botsingen, hoofdletters en niet-afdrukbare tekens in tekenreekssleutels, enz. .p.), daarom wordt dit niet algemeen geaccepteerd.
Alle andere entiteitskenmerken worden opgeslagen in speciale tabellen, genaamd Satellieten. Eén hub kan meerdere satellieten hebben die verschillende sets attributen opslaan.
De verdeling van attributen over satellieten vindt plaats volgens het principe gezamenlijke verandering — in de ene satelliet kunnen attributen zonder versienummers worden opgeslagen (bijvoorbeeld geboortedatum en SNILS voor een individu), in een andere - zelden veranderende versies (bijvoorbeeld achternaam en paspoortnummer), in de derde - vaak veranderende (bijvoorbeeld afleveradres, categorie, datum laatste bestelling, etc.). In dit geval wordt versiebeheer uitgevoerd op het niveau van individuele satellieten, en niet op het niveau van de entiteit als geheel. Het is dus raadzaam om attributen zo te distribueren dat de intersectie van versies binnen één satelliet minimaal is (wat het totale aantal opgeslagen versies vermindert). ).
Om het gegevenslaadproces te optimaliseren, worden attributen verkregen uit verschillende bronnen vaak opgenomen in individuele satellieten.
Satellieten communiceren met de Hub via vreemde sleutel (wat overeenkomt met 1-op-veel kardinaliteit). Dit betekent dat meerdere attribuutwaarden (bijvoorbeeld meerdere telefoonnummers voor één klant) worden ondersteund door deze ‘standaard’ architectuur.
В Ankermodel tabellen waarin sleutels worden opgeslagen, worden aangeroepen Ankers. En ze houden:
- Alleen surrogaatsleutels
- Link naar bron
- Registreer de toegevoegde tijd
Natuurlijke sleutels worden bekeken vanuit het perspectief van het Ankermodel gewone attributen. Deze optie lijkt misschien moeilijker te begrijpen, maar biedt veel meer mogelijkheden om het object te identificeren.
Bijvoorbeeld als gegevens over dezelfde entiteit uit verschillende systemen kunnen komen, die elk hun eigen natuurlijke sleutel gebruiken. In Data Vault kan dit leiden tot nogal omslachtige structuren van meerdere hubs (één per bron + een verenigende masterversie), terwijl in het Anchor-model de natuurlijke sleutel van elke bron in zijn eigen attribuut valt en kan worden gebruikt bij het laden onafhankelijk van al de anderen.
Maar er is hier ook een verraderlijk punt: als attributen uit verschillende systemen in één entiteit worden gecombineerd, zijn er hoogstwaarschijnlijk enkele regels voor “lijmen”, waarbij het systeem moet begrijpen dat records uit verschillende bronnen overeenkomen met één exemplaar van de entiteit.
В Gegevenskluis deze regels zullen hoogstwaarschijnlijk de formatie bepalen “surrogaathub” van de masterentiteit en op geen enkele manier invloed hebben op de Hubs die natuurlijke bronsleutels en hun originele attributen opslaan. Als op een gegeven moment de samenvoegingsregels veranderen (of de attributen waarmee dit wordt uitgevoerd worden bijgewerkt), zal het voldoende zijn om de surrogaathubs opnieuw te formatteren.
В Ankermodel zo'n entiteit zal hoogstwaarschijnlijk worden opgeslagen het enige anker. Dit betekent dat alle attributen, ongeacht uit welke bron ze afkomstig zijn, gebonden zullen zijn aan hetzelfde surrogaat. Het scheiden van ten onrechte samengevoegde records en, in het algemeen, het monitoren van de relevantie van het samenvoegen in een dergelijk systeem kan veel moeilijker zijn, vooral als de regels vrij complex zijn en regelmatig veranderen, en hetzelfde attribuut uit verschillende bronnen kan worden verkregen (hoewel dit zeker het geval is). mogelijk, aangezien elke attribuutversie een link naar de bron behoudt).
In ieder geval als uw systeem de functionaliteit moet implementeren deduplicatie, het samenvoegen van records en andere MDM-elementenis het de moeite waard om bijzondere aandacht te besteden aan de aspecten van het opslaan van natuurlijke sleutels in agile methodologieën. Het is waarschijnlijk dat het omvangrijkere Data Vault-ontwerp plotseling veiliger zal zijn in termen van samenvoegfouten.
Ankermodel biedt ook een extra objecttype genaamd Knoop het is in wezen speciaal gedegenereerd type anker, die slechts één attribuut kan bevatten. De knooppunten zijn bedoeld om platte mappen op te slaan (bijvoorbeeld geslacht, burgerlijke staat, klantenservicecategorie, enz.). In tegenstelling tot het anker, de knoop heeft geen bijbehorende attributentabellen, en het enige attribuut (naam) wordt altijd opgeslagen in dezelfde tabel met de sleutel. Knooppunten zijn met ankers verbonden door middel van verbindingstabellen (Tie), op dezelfde manier als ankers met elkaar zijn verbonden.
Er bestaat geen duidelijke mening over het gebruik van Nodes. Bijvoorbeeld, , die het gebruik van het Ankermodel in Rusland actief promoot, meent (niet onredelijk) dat voor geen enkel naslagwerk met zekerheid kan worden gesteld dat het altijd zal statisch en één niveau zijn, dus het is beter om onmiddellijk een volwaardig anker voor alle objecten te gebruiken.
Een ander belangrijk verschil tussen Data Vault en het Anchor-model is de beschikbaarheid attributen van verbindingen:
В Gegevenskluis Links zijn dezelfde volwaardige objecten als Hubs, en kunnen dat ook hebben eigen attributen. In Ankermodel Links worden alleen gebruikt om ankers en kunnen geen eigen kenmerken hebben. Dit verschil resulteert in aanzienlijk verschillende modelleringsbenaderingen feiten, die verder zal worden besproken.
Feitenopslag
Hiervoor spraken we vooral over meetmodellering. De feiten zijn iets minder duidelijk.
В Gegevenskluis een typisch object voor het opslaan van feiten is Koppeling, in wiens satellieten echte indicatoren worden toegevoegd.
Deze aanpak lijkt intuïtief. Het biedt gemakkelijke toegang tot de geanalyseerde indicatoren en is over het algemeen vergelijkbaar met een traditionele feitentabel (alleen de indicatoren worden niet in de tabel zelf opgeslagen, maar in de “aangrenzende” tabel). Maar er zijn ook valkuilen: een van de typische aanpassingen van het model – uitbreiding van de feitensleutel – maakt het toevoegen van een nieuwe externe sleutel aan Link. En dit ‘breekt’ op zijn beurt de modulariteit en veroorzaakt mogelijk de behoefte aan aanpassingen aan andere objecten.
В Ankermodel Een verbinding kan geen eigen attributen hebben, dus deze aanpak zal niet werken: absoluut alle attributen en indicatoren moeten aan één specifiek anker worden gekoppeld. De conclusie hieruit is eenvoudig: Elk feit heeft ook zijn eigen anker nodig. Voor een deel van wat we gewend zijn als feiten waar te nemen, kan dit er natuurlijk uitzien - het feit van een aankoop kan bijvoorbeeld perfect worden gereduceerd tot het object "bestelling" of "ontvangst", het bezoeken van een site voor een sessie, enz. Maar er zijn ook feiten waarvoor het niet zo eenvoudig is om zo'n natuurlijk 'dragerobject' te vinden - bijvoorbeeld de overblijfselen van goederen in magazijnen aan het begin van elke dag.
Dienovereenkomstig doen zich geen problemen met modulariteit voor bij het uitbreiden van een feitsleutel in het Ankermodel (het is voldoende om simpelweg een nieuwe Relatie toe te voegen aan het corresponderende Anker), maar het ontwerpen van een model om feiten weer te geven is minder eenduidig; er kunnen ‘kunstmatige’ Ankers verschijnen. die het businessobjectmodel op een onduidelijke manier weergeven.
Hoe flexibiliteit wordt bereikt
De resulterende constructie bevat in beide gevallen aanzienlijk meer tafelsdan traditionele metingen. Maar het kan duren aanzienlijk minder schijfruimte met dezelfde set versiekenmerken als de traditionele dimensie. Natuurlijk is er hier geen sprake van magie; het draait allemaal om normalisatie. Door attributen te verdelen over satellieten (in de datakluis) of individuele tabellen (ankermodel), verminderen we (of elimineren we volledig) duplicatie van waarden van sommige attributen bij het veranderen van andere.
Voor Gegevenskluis de winsten zullen afhangen van de verdeling van de attributen onder de satellieten, en voor Ankermodel — is vrijwel recht evenredig met het gemiddelde aantal versies per meetobject.
Ruimtebesparing is echter een belangrijk, maar niet het belangrijkste voordeel van het afzonderlijk opslaan van attributen. Samen met het gescheiden opslaan van relaties maakt deze aanpak de winkel modulair ontwerp. Dit betekent dat het toevoegen van zowel individuele attributen als geheel nieuwe onderwerpgebieden in een dergelijk model eruit ziet bovenbouw over een bestaande reeks objecten zonder deze te wijzigen. En dit is precies wat de beschreven methodieken flexibel maakt.
Dit lijkt ook op de overgang van stukproductie naar massaproductie - als in de traditionele benadering elke tabel van het model uniek is en speciale aandacht vereist, dan is het in flexibele methodologieën al een reeks standaard "onderdelen". Aan de ene kant zijn er meer tabellen en moeten de processen voor het laden en ophalen van gegevens er ingewikkelder uitzien. Aan de andere kant worden ze typisch. Wat betekent dat die er misschien wel is geautomatiseerd en metadatagedreven. De vraag “hoe gaan we het leggen?”, waarvan het antwoord een aanzienlijk deel van het werk aan het ontwerpen van verbeteringen zou kunnen in beslag nemen, is nu simpelweg niet de moeite waard (evenals de vraag over de impact van het veranderen van het model op werkprocessen ).
Dit betekent niet dat analisten helemaal niet nodig zijn in een dergelijk systeem: iemand moet nog steeds door de reeks objecten met attributen werken en uitzoeken waar en hoe ze allemaal moeten worden geladen. Maar de hoeveelheid werk, evenals de kans op en de kosten van een fout, worden aanzienlijk verminderd. Zowel in de analysefase als tijdens de ontwikkeling van ETL, die voor een belangrijk deel kan worden herleid tot het bewerken van metadata.
Donkere kant
Al het bovenstaande maakt beide benaderingen echt flexibel, technologisch geavanceerd en geschikt voor iteratieve verbetering. Natuurlijk zit er ook een ‘vat in de zalf’, waar je volgens mij al naar kunt raden.
Data-decompositie, die ten grondslag ligt aan de modulariteit van flexibele architecturen, leidt tot een toename van het aantal tabellen en dienovereenkomstig overheadkosten om samen te voegen bij het bemonsteren. Om eenvoudigweg alle attributen van een dimensie te krijgen, is in een klassieke winkel één selectie voldoende, maar een flexibele architectuur vereist een hele reeks joins. Bovendien, als al deze samenvoegingen voor rapporten vooraf kunnen worden geschreven, zullen analisten die gewend zijn om SQL met de hand te schrijven dubbel lijden.
Er zijn verschillende feiten die deze situatie gemakkelijker maken:
Bij het werken met grote afmetingen worden bijna nooit alle attributen tegelijkertijd gebruikt. Dit betekent dat er mogelijk minder joins zijn dan op het eerste gezicht lijkt op het model. Data Vault kan ook rekening houden met de verwachte frequentie van delen bij het toewijzen van attributen aan satellieten. Tegelijkertijd zijn hubs of ankers zelf vooral nodig voor het genereren en in kaart brengen van surrogaten in de laadfase en worden ze zelden gebruikt in zoekopdrachten (dit geldt vooral voor ankers).
Alle verbindingen zijn per sleutel. Bovendien vermindert een meer “gecomprimeerde” manier om gegevens op te slaan de overhead van het scannen van tabellen waar dat nodig is (bijvoorbeeld bij het filteren op attribuutwaarde). Dit kan ertoe leiden dat het nemen van monsters uit een genormaliseerde database met een aantal joins zelfs sneller zal zijn dan het scannen van één zware dimensie met veel versies per rij.
Hier bijvoorbeeld Het artikel bevat een gedetailleerde vergelijkende test van de prestaties van het Anchor-model met een voorbeeld uit één tabel.
Veel hangt af van de motor. Veel moderne platforms hebben interne mechanismen voor het optimaliseren van joins. MS SQL en Oracle kunnen bijvoorbeeld joins naar tabellen “overslaan” als hun gegevens nergens anders worden gebruikt, behalve voor andere joins en dit heeft geen invloed op de uiteindelijke selectie (eliminatie van tabellen/joins), en MPP Vertica , heeft bewezen een uitstekende motor te zijn voor het Ankermodel, gezien enige handmatige optimalisatie van het queryplan. Aan de andere kant lijkt het opslaan van het Ankermodel op bijvoorbeeld Click House, dat beperkte join-ondersteuning biedt, nog geen goed idee.
Bovendien zijn er voor beide architecturen speciale bewegingen, waardoor gegevenstoegang eenvoudiger wordt (zowel vanuit het oogpunt van queryprestaties als voor eindgebruikers). Bijvoorbeeld, Point-In-Time-tabellen in Data Vault of speciale tafelfuncties in het Ankermodel.
In totaal
De belangrijkste essentie van de beschouwde flexibele architecturen is de modulariteit van hun “ontwerp”.
Het is deze eigenschap die het volgende mogelijk maakt:
- Na enige initiële voorbereiding met betrekking tot de implementatie van metadata en het schrijven van eenvoudige ETL-algoritmen, de klant snel het eerste resultaat bezorgen in de vorm van een paar rapporten met gegevens uit slechts enkele bronobjecten. Het is niet nodig om het hele objectmodel volledig door te denken (zelfs niet op het hoogste niveau).
- Een datamodel kan al werken (en nuttig zijn) met slechts 2-3 objecten, en dan geleidelijk groeien (met betrekking tot het Anchor-model Nikolai mooie vergelijking met mycelium).
- De meeste verbeteringen, waaronder het uitbreiden van het onderwerpgebied en het toevoegen van nieuwe bronnen heeft geen invloed op de bestaande functionaliteit en vormt geen risico op het kapot maken van iets dat al werkt.
- Dankzij de ontleding in standaardelementen zien ETL-processen in dergelijke systemen er hetzelfde uit, leent hun schrijfwijze zich voor algoritmen en, uiteindelijk, automatisering.
De prijs van deze flexibiliteit is производительность. Dit betekent niet dat het onmogelijk is om acceptabele prestaties op dergelijke modellen te bereiken. Vaak heeft u gewoon meer inspanning en aandacht voor detail nodig om de gewenste statistieken te bereiken.
Apps
Entiteitstypen Gegevenskluis
Meer informatie over DataVault:
Entiteitstypen Anker model
Meer details over het ankermodel:
Samenvattende tabel met gemeenschappelijke kenmerken en verschillen van de overwogen benaderingen:
Bron: www.habr.com