Begint jouw analytics-dataketen met de zwakste schakel?

De bron van data

Business Intelligence richt zich op het presenteren van analyses en inzichten voor de business. In veel gevallen bevindt een datawarehouse-applicatie zich tussen de brongegevens en de dashboards en rapportages die de informatie presenteren. Veel boeken en blogs hebben de datawarehouse enterprise laag en de presentatielaag als hoofdonderwerpen. In deze blog gaan we ons richten op de datalevering van het bronsysteem aan een datawarehouse. Het is een onderschat onderdeel (“geef me gewoon alle data”), maar belangrijk onderdeel van de analytics oplossing omdat de dataketen zo sterk is als de zwakste schakel.

Om data in het datawarehouse te laden is het goed om te weten hoe de aangeleverde data eruitziet, wat de kenmerken zijn van de dataset. Het is nog beter om te weten hoe de gegevens het beste geschikt zijn om in het datawarehouse te laden. Wacht niet tot een dataset door het bronsysteem wordt geleverd om te analyseren hoe deze in het datawarehouse kan worden geladen. Aangezien aanlevering van de brondata de eerste schakel is in de business intelligence dataketen, moeten het bronsysteem- en de datawarehouse-experts hier samen aan werken. 

In deze blog worden drie richtlijnen gegeven die het beste werken voor het laden van gegevens in een datawarehouse, gemodelleerd met Data Vault*. Deze principes zijn geldig voor élke datawarehouse-oplossing.

Dataverwerking: push versus pull en time versus event

We onderscheiden twee manieren waarop de gegevens beschikbaar kunnen komen voor het datawarehouse. De gegevens kunnen van de bronsystemen naar de staging laag van het datawarehouse worden gepusht door het bronsysteem, of de datawarehouse-toepassing haalt de gegevens op uit de bronsystemen (pull) via vooraf gedefinieerde query’s. Vaak is het moment om de gegevens van de bron naar de staging laag te laden gepland op een rustig moment voor het bronsysteem. Dit om onvolledige gegevenssets als gevolg van database locking te voorkomen en de impact op de performance van het bronsysteem te minimaliseren. Het kan echter lastig zijn voor de datawarehouse applicatie om te weten wanneer de bron hier klaar voor is, waardoor vaak extra tijdmarges worden ingebouwd. Dit kan leiden tot het uitstellen van de dagelijkse laadactie van gegevens tot een veel later moment dan het bronsysteem beschikbaar is voor extractie. Door deze vertraging is dit niet de beste methode om de data in het datawarehouse te krijgen en daarna snel beschikbaar te maken voor de gebruiker.

Ontwerp de dataketen op basis van gebeurtenissen (events) in plaats van op basis van tijd

Wanneer het bronsysteem de gegevens naar het datawarehouse pusht, heeft het bronsysteem de controle over het moment van extractie. Het heeft kennis over de status van het systeem en kan de extractie starten zodra de dagelijkse bedrijfsprocessen zijn voltooid en de database locking geen probleem is. Vervolgens moet de datawarehouse-applicatie beginnen met het laden van de gegevens uit de staging laag zodra de data daar is aangeboden. Het moet zo worden ontworpen dat het gebaseerd is op events, dat wil zeggen dat op het moment dat de gegevens binnenkomen, de verwerking van de data in het datawarehouse begint. In moderne dataplatforms kan er een extra data lake-laag zijn tussen de bronsystemen en het datawarehouse. Dan moet de verwerking in deze laag op dezelfde event-gedreven manier worden vormgegeven. Alleen op deze manier kunnen de gegevens op een snelle manier aan de gebruikers worden verstrekt, zonder vertraging en zonder onzekerheid of de gegevens op tijd beschikbaar waren.

Datasets samen ontwerpen

Brongegevens worden meestal geleverd in gegevenssets met behulp van bestanden of database views. De gegevens in die datasets kunnen sterk genormaliseerd zijn of juist zeer gedenormaliseerd zijn, afhankelijk van de manier waarop het bronsysteem gegevensextracties ondersteunt. Voorbeelden van een sterk genormaliseerde dataset kan de levering van tabeldata van een ERP-systeem zijn. Informatie rond een bedrijfsobject wordt verstrekt in meerdere datasets, die vaak alleen kunnen worden gekoppeld met behulp van technische surrogaatsleutels in plaats van bijvoorbeeld de klantnummers die bekend zijn en door de business worden gebruikt. 

Een voorbeeld van een gedenormaliseerde dataset is het gebruik van een rapportage-view van het bronsysteem om gegevens aan het datawarehouse te leveren. Deze gegevenssets zijn oorspronkelijk ontworpen voor rapporten en combineren meerdere bedrijfsobjecten in één gegevensset. Vaak worden de bedrijfsobjecten slechts gedeeltelijk opgenomen en zijn andere gegevenssets nodig om alle gegevenselementen van een bedrijfsobject te verzamelen. Bij het laden van de gegevens naar het datawarehouse resulteert dit, voor één gegevensset, in het uitsplitsen naar veel verschillende Data Vault-tabellen. Beide uitersten van datasets moeten zoveel mogelijk worden vermeden. Neem contact op met de bronsysteemexpert om de mogelijkheden te bespreken en de gegevensuitwisseling naar het datawarehouse zorgvuldig in te richten.

Data-integratie: bedrijfssleutels

Vaak modelleren we datawarehouses met behulp van de Data Vault-methodologie. Data Vault organiseert gegevens rond bedrijfsobjecten. De bedrijfssleutels (business keys) worden gebruikt om informatie van bedrijfsobjecten te identificeren, te volgen en te lokaliseren. Bedrijfssleutels hebben betekenis voor de business. Bedrijfssleutels kunnen breed gebruikt worden binnen een organisatie, bijvoorbeeld dezelfde bedrijfssleutel van de klant wordt gebruikt in het CRM-systeem en in het ordersysteem. Het biedt het eerste niveau van gegevensintegratie tussen CRM en ordergegevens in de Data Vault. Het tegenovergestelde van bedrijfssleutels zijn surrogaatsleutels (technical keys) die door operationele systemen worden gebruikt om het bedrijfsobject te identificeren. Deze sleutels zijn intern in het systeem en worden niet weergegeven of gebruikt door de business. Deze sleutels worden ook niet gedeeld met andere applicaties. Om data rondom de bedrijfssleutels in de Raw Vault te kunnen organiseren, is het belangrijk dat het bronsysteem data aanlevert met de bedrijfssleutel. Ook wanneer een dataset verwijzingen bevat naar andere datasets (een refererende sleutel) moet het bronsysteem deze referentie voorzien van de bedrijfssleutel en niet van de surrogaatsleutel!

Als het bronsysteem de bedrijfssleutel voor deze referenties niet kan / wil leveren en alleen de surrogaatsleutels levert, is de enige optie om de gegevens in de Raw Vault (eerste deel van de Data Vault) te laden met behulp van de surrogaatsleutel als bedrijfssleutel. Alleen in de Business Vault (tweede deel van de Data Vault waarin data wordt bewerkt volgens bedrijfsregels) kan het worden gecorrigeerd om de gegevens rond de bedrijfssleutels te integreren. Het is niet aan te raden om te proberen de surrogaatsleutels te vervangen door bedrijfssleutels in de staging laag. Hierdoor ontstaat namelijk een afhankelijkheid tussen gegevenssets in de staging laag, voordat de gegevens in het datawarehouse kunnen worden geladen. Het vereist ook dat volledige sets worden geleverd, want als alleen deltasets worden geleverd, is het onwaarschijnlijk dat het opzoeken van de bedrijfssleutel in een andere delta-dataset alle benodigde waarden zal vinden. De oplossing ligt dus óf bij het bronsysteem (aanlevering met bedrijfssleutels) óf door nabewerking in de Business Vault.

Conclusie

De drie bovenstaande richtlijnen zijn niet de enige belangrijke bij het ontwerpen van de dataketen. Maar, ze worden gemakkelijk over het hoofd gezien door bijvoorbeeld het eerste voorstel van elke brongegevenslevering als vanzelfsprekend te beschouwen. De belangrijkste boodschap van deze blog is om samen met experts van het bronsysteem naar het datawarehouse de gegevenslevering van het bronsysteem te ontwerpen. Deel de behoeften, wensen en moeilijkheden van beide kanten om een optimale interface en datalevering te ontwerpen en zorg ervoor dat jouw dataketen start met een sterke schakel.

*Deze blog veronderstelt dat de lezer enige kennis heeft over Data Vault-modellering en de concepten kent van Hubs om bedrijfssleutels op te slaan, Links om relaties tussen bedrijfssleutels op te slaan en Satellieten om de wijzigingsgeschiedenis van attributen die behoren bij een bedrijfssleutel op te slaan.

Verder met data

Is stilstaan niks voor jou? Wil jij iedere dag leren en kunnen sparren met vakgenoten? Neem gerust contact op, ik vertel je er graag meer over. Of bekijk de vacatures.

Verder lezen?

Ontdek meer verhalen van Sogeti collega’s!