Eva_Murray_600x448.jpg

Hoe u de uitdagingen van het gebruik van een gegevenskluis kunt overwinnen

Klik voor meer informatie over auteur Eva Murray.

Wat zijn de uitdagingen?

Van flexibiliteit tot schaalbaarheid en efficiëntie, het gebruik van een datakluis als uw datamodellering heeft vele voordelen. Maar tegelijkertijd zijn er uitdagingen waarvan u zich bewust moet zijn. In deze blog ga ik je door de beperkingen heen leiden en hoe je ze kunt overwinnen.

De benadering die een gegevenskluis volgt bij het modelleren van gegevens (iets waar ik verderop in zal ingaan) resulteert in een aanzienlijk grotere hoeveelheid gegevensobjecten in vergelijking met andere benaderingen. Deze objecten omvatten zaken als tabellen en kolommen, en de reden dat er zoveel meer zijn, is omdat een gegevenskluis informatietypen scheidt.

Als gevolg hiervan kan de inspanning voor het vooraf modelleren groter zijn om de resulterende voordelen – hierboven vermeld – als eindresultaat te accommoderen. Het betekent ook dat er tijdens het modelleerproces een groter aantal handmatige of mechanische taken betrokken kunnen zijn om het flexibele en gedetailleerde datamodel met al zijn componenten vast te stellen.

Hoe kunnen deze beperkingen worden aangepakt?

Om tijdrovende handmatige taken tijdens het modelleringsproces te vermijden, kunnen architecten delen van het model automatiseren, waardoor het efficiënter wordt om op de lange termijn te creëren, bij te werken en te onderhouden.

Hoe kunnen ze dat doen?

Binnen de datakluisbenadering zijn er bepaalde gegevenslagen. Deze variëren van de bronsystemen waar de gegevens vandaan komen, tot een verzamelplaats waar gegevens uit het bronsysteem arriveren, gemodelleerd volgens de oorspronkelijke structuur, tot het kerndatawarehouse, dat de onbewerkte kluis bevat, een laag die het mogelijk maakt om terug te gaan naar het origineel. bronsysteemgegevens en de zakelijke kluis, een semantische laag waar bedrijfsregels worden geïmplementeerd. Ten slotte zijn er datamarts, die zijn gestructureerd op basis van de eisen van het bedrijf. Er kan bijvoorbeeld een datamart voor financiën of een datamart voor marketing zijn, waar de relevante gegevens voor staan analyse doeleinden.

Van deze lagen zijn de verzamelplaats en de onbewerkte kluis het meest geschikt voor automatisering.

Wat zijn de kenmerken van gegevenskluismodellering?

De datakluis-modelleringstechniek zorgt voor ultieme flexibiliteit door de bedrijfssleutels, die elke bedrijfsentiteit uniek identificeren en niet vaak veranderen, te scheiden van hun attributen. Dit resulteert, zoals eerder vermeld, in veel meer data-objecten die in het model zitten, maar biedt ook een datamodel dat zeer snel kan reageren op veranderingen, zoals de integratie van nieuwe databronnen en business rules.

De basisstructuur van het model komt voort uit de bedrijfssleutels en de relaties daartussen. Hun stabiele karakter vormt het belangrijkste ingrediënt voor een robuust datamodel, maar betekent ook dat de sleutels zorgvuldig moeten worden gekozen, omdat ze de basis vormen waarvan al het andere is afgeleid.

Naven

De tabellen die de bedrijfssleutels bevatten, worden hubs genoemd in de datakluisbenadering. Naast het opslaan van de sleutels bevatten hubs ook surrogaatsleutels en metadata voor elke bedrijfssleutel. Ten slotte is in de hub ook de bron van elke business key te vinden, zodat informatie terug te herleiden is naar de oorsprong.

Links

Koppelingstabellen zijn veel-op-veel-samenvoegtabellen die verschillende bedrijfssleutels met elkaar verbinden. In linktabellen vindt u de informatie die u vindt de surrogaatsleutels voor de hubs die via de link zijn verbonden, evenals de surrogaatsleutel voor de link en de metadata over waar de associatie vandaan komt.

Satellieten

Met de hubs en links op hun plaats, wordt de structuur van het datakluis-model opgezet. Het bevat echter nog geen attributen. Dit is waar satellieten binnenkomen. Satelliettafels bevatten metagegevens die hen verbinden met hun bovenliggende hubs en koppelingstabellen. Ze bevatten ook metadata over de oorsprong van de attributen, evenals temporele attributen. Dit betekent dat data-architecten dankzij satellieten ervoor kunnen zorgen dat de geschiedenis met elk interval wordt geregistreerd, terwijl ze ook een audittrail en traceerbaarheid naar het bronsysteem bieden.

Hoe werkt een datakluis?

In u beschikt over een database waarmee u flexibel kunt werken met een overvloed aan tools en methodologieën, zodat u de juiste aanpak voor uw bedrijf en overkoepelend kunt kiezen analytische strategie.

Wij ondersteunen u volledig bij het kiezen van de datamodelleringstechniek die het beste bij uw strategie past. Dit betekent dat u eenvoudig kunt profiteren van de voordelen van een datakluis.

Partners zoals Datavault Builder en Wherescape hebben tools voor datamodellering en magazijnautomatisering ontwikkeld die moeiteloos met de database kunnen worden geïntegreerd.

U kunt uw datamodel ook rechtstreeks in onze database bouwen met behulp van het UDF Framework.

Breng prestaties naar uw gegevenskluis gemodelleerde gegevens

Het modelleren van uw gegevens in een datakluis kan ertoe leiden dat complexe SQL-query’s worden uitgevoerd in uw datawarehouse. Onze architectuur en puur ontwerp zorgen ervoor dat de uitstekende prestaties die we u beloven gedurende de gehele levenscyclus van gegevens behouden blijven, inclusief uw gegevensmodellering en warehousing processen.

U kunt historische queryresultaten snel en efficiënt controleren en reproduceren, terwijl u ook al uw grote datavolumes in het magazijn laadt en uw analisten en datawetenschappers uitnodigt om hun workflows, analyses en analytische modellen rechtstreeks in het datawarehouse uit te voeren zonder in te boeten aan snelheid en betrouwbaarheid.

Partnerschappen zijn gericht op het verbeteren van de gebruikerservaring, daarom is feedback en gezamenlijk werken aan de continue ontwikkeling en integratie van producten cruciaal.

Je kan kijken deze video om een ​​indruk te krijgen van een samenwerking met een team dat effectief een datakluis gebruikt.

Thomas-Frisendal_300x224.png

Leren van complexe datamodelleringspraktijken

Klik voor meer informatie over auteur Thomas Frisendal.

Dit is een goed moment om te kijken naar best practices in databaseontwerp voor SQL-databases. Zijn er dingen die gemakkelijker hadden kunnen worden gedaan als de SQL-ontwerpers een absolute vooruitziende blik hadden gehad? Het antwoord is natuurlijk ja. Maar het belangrijkste is wat echt een groot verschil had kunnen maken.

De evolutie van SQL – op welke eigenschappen wachten we?

Over het algemeen is de SQL-standaard gegroeid door veel problemen te omarmen die zich in de loop der jaren hebben voorgedaan. Ik noem alleen XML, tijddatatypes en multidimensionaal als voorbeelden van nuttige aanpassingen. Voor “brood en boter” -databases werkt SQL over het algemeen prima, maar er zijn enkele dingen die de moeite waard zijn om te bespreken:

  • De behoefte voor surrogaatsleutels evenals de complexiteit van het omgaan met aaneengeschakelde (zakelijke) sleutels geven aan dat de concepten van sleutels en het bereik van dergelijke sleutels mogelijk een make-over nodig hebben
  • De omvang van de sleutels is ook een discussie waard – in de grafiekruimte zijn mensen best tevreden met het RDF-concept van IRI’s (Internalized Resource Identifiers). IRI’s worden veel gebruikt, met een globaal bereik. In de SQL-communities worden GUID’s voor vergelijkbare doeleinden gebruikt
  • (Buitenlandse) belangrijkste relaties zou een sterkere rol kunnen spelen in het SQL-paradigma – eigenlijk zijn het niet de relaties tussen sleutels, maar de relaties tussen typen bedrijfsobjecten die er toe doen
  • Dit raakt de zaken van normalisatie
    (en gecontroleerde denormalisatie), die in hoge mate deel uitmaken van best practices in het ontwerpen van SQL-databases

Tussen de vier verschillende probleemgroepen die hierboven zijn genoemd, is er één gemeenschappelijke noemer: tijdelijkheid. Dit zou ook in meer alledaagse termen kunnen worden omschreven als ‘correct omgaan met gegevens in de loop van de tijd’ – gericht op zakelijke behoeften die we hebben geprobeerd op te lossen door middel van datawarehouses en datameren in veeleisende, gegevensintensieve sectoren zoals de overheid, farmaceutica, technologie en wetenschap.

Datakluizen en ankermodellen – Ensemble

Veel zware databases in veeleisende industrieën hebben hun weg gevonden naar twee enigszins verwante modellering benaderingen:

  • Modellering van gegevenskluis: Oorspronkelijk ontwikkeld door Dan Linstedt voor de Amerikaanse defensie
  • Anker modellering: Open source-project afkomstig uit Zweden, door Lars Rönnbäck

Tegenwoordig presenteren de twee gemeenschappen (meer dan 5000 DV-modelbouwers) en een 3-cijferig aantal ankermodelmakers (voornamelijk in Zweden en Nederland) zichzelf als onderdeel van het “Ensemble – Modelling voor het moderne datawarehouse”.

De belangrijkste motivatie om databases op deze manieren te modelleren, kan in drie woorden worden samengevat:

  • Schaalbaarheid (petabyte-niveaus)
  • Tijdelijkheid (uni-, bi- en meer)
  • Veerkracht (ten opzichte van structurele en terminologische veranderingen)

Anker modellering

Ik zal me concentreren op het modelleren van gegevenskluizen, maar voordat ik dat doe – enkele opmerkingen over ankermodellering:

  • Anchor-modellering heeft een goede website als referentie
  • Er is een gratis online modelleertool hier
  • U kunt online training krijgen hier

Anchor-modellering is beschreven door Lars Rönnbäck vindt dit leuk:

“Ankermodellering is een open source-databasemodelleringstechniek die is gebaseerd op het uitgangspunt dat de omgeving rond een datawarehouse voortdurend verandert. Een grote verandering aan de buitenkant van het model zal resulteren in een kleine verandering aan de binnenkant. De techniek omvat de natuurlijke concepten van objecten, attributen en relaties, waardoor het gemakkelijk te gebruiken en te begrijpen is. Het is gebaseerd op de zesde normaalvorm, wat resulteert in een sterk afgebroken implementatie, die veel van de valkuilen vermijdt die gepaard gaan met traditionele databasemodellering. Dankzij het modulaire karakter ondersteunt de techniek het scheiden van zorgen en vereenvoudigt het projectscoping. Je kunt klein beginnen met prototyping en later uitgroeien tot een enterprise datawarehouse zonder dat je je eerdere werk opnieuw hoeft uit te voeren. “

“Hoewel de oorsprong ligt bij de eisen die aan datawarehousing worden gesteld, is het een generieke modelleringsaanpak, ook geschikt voor andere typen systemen. Elke wijziging wordt geïmplementeerd als een onafhankelijke niet-destructieve uitbreiding in het bestaande model. Hierdoor blijven alle huidige applicaties onaangetast. Veranderingen in de invoer naar en uitvoer van de database kunnen daardoor asynchroon worden afgehandeld, en alle versies van een applicatie kunnen worden uitgevoerd tegen dezelfde evoluerende database. Elke eerdere versie van het databasemodel bestaat nog steeds als een subset binnen een ankermodel. “

Modellering van gegevenskluis: een kort overzicht

Hoewel bij het modelleren van gegevenskluizen een andere terminologie wordt gebruikt en verschillende weergaven worden gebruikt, zijn de bedoelingen vrijwel hetzelfde. Een goede (hoewel ietwat oude) vergelijking is te vinden hier.

Het gezaghebbende bronboek voor gegevenskluis is Een schaalbaar datawarehouse bouwen met Data Vault 2.0 door Daniel Lindstedt en Michael Olschimke (Morgan Kaufmann, 2016).

Ik raad aan om deze drie websites te bezoeken om een ​​overzicht te krijgen van het modelleren van gegevenskluizen:

De basisbouwstenen zijn:

  • ‘Hubs’ (de kern van het record van een bedrijfsobjecttype)
  • “Satellieten” (informatie over kenmerken van typen bedrijfsobjecten)
  • “Links” (verbindingen tussen hubs en satellieten)

Hier is een diagram van een eenvoudig gegevenskluismodel (voorbeelden op DDL-niveau volgen):

Afbeeldingsbron: De Hans Blog

Hans Hultgren is een bekende datafluis-trainer en “evangelist” die samenwerkt met Genesee Academy en anderen.

Let daar op:

  • Er kunnen meerdere hubs zijn voor een bepaald type bedrijfsobject (als het afkomstig is uit meer dan één systeem)
  • Er kunnen meerdere satellieten zijn voor een bepaald type bedrijfsobject (als er meerdere bronsystemen zijn en / of meerdere patronen van verandering ertussen). De gegevenskluis probeert over het algemeen gegevens te “bundelen”, die updatepatronen (en tijdlijnen) in één tabel delen
  • Alle hubs, links en satellieten zijn afzonderlijke tabellen in SQL
  • Databases van gegevenskluizen werken doorgaans met hashkeys om versies enz. Te isoleren.

(Bij ankermodellering is de keuze altijd de zesde normale vorm met individuele tabellen voor alles – en bij “concurrent-temporele” modellering worden alleen inserts gedaan in de database).

Lees voor een goede intro Dan Linstedt’s bericht over de Northwind-database die wordt weergegeven als een gegevenskluis. Als dat niet genoeg voor je is, dan zou ik HET boek over datakluis aanbevelen, Een schaalbaar datawarehouse bouwen met Data Vault 2.0, hierboven vermeld.

Het datakluis 2.0-boek (waarnaar hierboven wordt verwezen) heeft een aantal uitbreidingen op de tot dusver gepresenteerde terminologie. Hier volgt een lijst met de belangrijkste met indien nodig een toelichting.

Er zijn nog veel meer specifieke termen en constructies voor datakluis, maar het formaat van een blogbericht biedt er geen ruimte voor! Volg de bovenstaande links en lees het boek dat in dit bericht wordt genoemd voor meer informatie.

Datakluizen worden vaak gebouwd door middel van op sjablonen gebaseerde datakluisgeneratoren die op de markt beschikbaar zijn – hier zijn er een handvol:

  • Vaultspeed
  • WhereScape
  • Visuele gegevenskluis
  • Datavault Builder
  • TEAM

In het hierboven genoemde gegevenskluisboek (2.0, de huidige versie van het boek), kunnen gegevenskluizen worden geconstrueerd (met behulp van ‘punt in tijd’-tabellen) om updates (van bijvoorbeeld de einddatumtijden) te elimineren, wat leidt tot het invoegen van alleen ladingen, die het meest performant zijn.

Data Vault DDL-voorbeelden

Het gegevenskluisboek waarnaar we verschillende keren hebben verwezen, Een schaalbaar datawarehouse bouwen met Data Vault 2.0, heeft een bijbehorende site waar u een grote verzameling code kunt downloaden. U moet het boek kopen om toegang te krijgen. Ik heb hieronder een paar voorbeelden van CREATE TABLE-statements uitgekozen om u een idee te geven van de complexiteit van de tabeldefinities in een gegevenskluis:

Een simpele hub (ankerpunt voor AirlineID):

Een enigszins complexe hub (ondersteunt een aaneengeschakelde bedrijfssleutel):

Een ‘payload’-satelliet die de luchthavens van herkomst beschrijft:

Een koppelingstabel (vluchten, vervoerders, vliegtuigen, datums, vertrekpunten en bestemmingen koppelen):

Een effectiviteitssatelliet:

Lessen die zijn getrokken uit het bouwen van grote databases in SQL

Om dit af te ronden: wat kunnen we dan overnemen als aanvullende zakelijke vereisten om een ​​nog betere databasetaal te maken dan wat SQL tegenwoordig is?

Het is duidelijk dat de constructie van de basisgegevenskluis, waarbij een bedrijfsentiteit wordt gescheiden in hub (s) en satellieten, verschillende problemen aanpakt met betrekking tot:

  • Sleutels
  • Updates (mogelijk in verschillende bronsystemen)

De expliciete ondersteuning van relaties als fysieke tabellen (“links”) is ook gericht op het afhandelen van sleutels (vreemd in SQL-termen) en updates (mogelijk ook in verschillende bronsystemen).

Het is eerlijk om te zeggen dat we kunnen concluderen dat we de problemen met betrekking tot het omgaan met sleutels moeten oplossen:

  • Identiteit en uniekheid
  • Aanhoudende sleutels
  • Aaneengeschakelde bedrijfssleutels
  • Vreemde sleutels en hun relatie tot relaties

Er moet een gerichte, intuïtieve en flexibele aanpak worden ontworpen (in plaats van de problemen op te splitsen in verschillende fysieke database-objecten).

Tijdelijkheid is ook een belangrijke drijfveer achter datakluis en ankermodellering:

  • Laad datetime-stempels
  • Verander detectie
  • Zoals versus vanaf (versies)
  • Effectief van en naar
  • Afhandeling van schemawijzigingen

En tot slot komt het bijhouden van gegevens ook expliciet aan de orde in de complexe datamodelleringspraktijken die hierboven zijn beschreven:

  • Laad datetime-stempels
  • Bron volgen
  • Verander detectie
  • Laad geschiedenis

Niet expliciet zichtbaar, maar zeker een belangrijke drijfveer achter datakluis is de behoefte aan snelheid bij het laden van data. Gebruikers hebben behoefte aan databases op petabyte-schaal, en ze dringen aan op snel laden en snelle zoekopdrachten.

Een interessante gedachte is dat de metadatamodellen in die datakluisgeneratoren waarschijnlijk relatief veel lijken op (delen van) een 6e normaalvorm datamodel. Dat geldt zeker ook voor ankermodellering.

Kunnen we deze uitdagingen op nieuwe manieren oplossen? Ja dat kunnen we! Een nieuwe taal (zoals de komende Graph Query Language, GQL) kan worden ontworpen om de hierboven genoemde modelleerproblemen op een ongecompliceerde, to-the-point constructies te ondersteunen die intuïtief zijn en effectief met die vereisten omgaan, achter de schermen en met goede prestaties. Parallel met de fysieke databaseobjecten moet het DBMS zich bewust zijn van de “diepe structuren” van semantiek die erachter schuilen het datamodel.