Van spaghetti naar lasagne
Een nieuwe BI architectuur bij Waterschap De Dommel
Huidige situatie
Op dit moment is de BI architectuur bij De Dommel relatief eenvoudig van opzet. Er is sprake van een centrale portal omgeving (BusinessObjects InfoView) waarin rapportages aangeboden worden.
Bronsystemen zijn ontsloten via een universe (een metadata laag van BusinessObjects waarin business logica verwerkt wordt zoals relaties, filters een naamgevingen). Op deze universe worden rapportages gebouwd.
Kortom, er wordt direct op de bron gerapporteerd. Rapportages zijn niet bronsysteem-overstijgend. Er is dus een lage mate van integratie. Er zijn momenteel geen andere ontsluitingsvormen dan rapportages.
Business logica zit verwerkt in de universe. Voor andere ontsluitingsvormen zijn we dus afhankelijk van BO. Enerzijds, omdat we gebruik moeten maken van de universe (immers bevindt daar onze business logica; anders moeten we dezelfde logica ergens anders dubbel bouwen en onderhouden), anderzijds omdat het Business Objects portaal alleen Business Objects content ontsluit. We zijn dus gebonden aan één leverancier.
Uitdagingen
Onze huidige BI omgeving loopt tegen zijn beperkingen aan. De volgende problemen en uitdagingen voelen wij en zien wij op ons af komen:
- Informatiebehoefte wordt complexer
Hoewel het informatieaanbod beperkt systeemgrensoverschrijdend is, wordt de vraag naar geïntegreerde informatie steeds groter.
Voorbeeld: projecten worden in systeem A gemanaged, uren worden in systeem B geschreven. Voor een projectmanager zijn zowel projectkosten (euro’s) als ook door projectleden geschreven uren van belang voor de projectsturing. Temeer, omdat uren gekapitaliseerd dienen te worden. D.w.z. uren drukken direct op het budget van het project. Waar vroeger duidelijk twee losse activiteiten bestonden (projectmanagement en urenmanagement) is hier nu een groot raakvlak ontstaan. De behoefte naar geïntegreerde informatie (gebudgetteerde en gerealiseerde euro’s en uren per project) is groter dan ooit.
- Leveranciersafhankelijkheid
Wij willen onafhankelijker worden van leveranciers. We willen kunnen kiezen voor de beste tools per geval; en niet gebonden zijn aan het aanbod van één leverancier. We willen kunnen switchen naar andere oplossingen zonder omvangrijke herinvesteringen. Dit vereist een gelaagde architectuur waarin bepaalde problemen (zoals het vashouden van historie, het integreren van gegevens of het toepassen van business logica) centraal worden opgelost.
- Professionaliteit
Wij willen business logica en andere metadata professioneler beheren. De broneigenaar is eigenaar van de data, de business wordt eigenaar van de business logica. Het BICC is eigenaar van het proces dat leidt tot informatie. Dit moet middels traceerbaarheid aan te tonen zijn. De BI architectuur wordt daardoor auditeerbaar.
- Flexibiliteit
Wij willen lage beheerslasten voor de BI omgeving; ook in de toekomst waarin er steeds meer bronnen worden ontsloten en de informatiebehoefte groeit. Het moet mogelijk zijn om veranderingen (wijzigingen van business logica, wijzigingen van bronsystemen, toevoegen van systemen) snel door te voeren met een te overziene en lage impact.
- Real Time Data en Master Data Management
Met ontwikkelingen als de OverheidsDataBase (ODB) komt real-time data op ons af. Basisgegevens zullen middels een service bus worden aangeboden. Dit wordt een uitdaging, niet alleen op BI gebied. Maar ook qua gegevens beheer. Deze gegevensstroom zal moeten worden opgevangen, bewaard, en worden gedistribueerd naar bestaande systemen. Kortom, master data management (MDM) activiteiten moeten worden ontplooid. Onze visie is dat dit met eenzelfde fundament verwezenlijkt kan worden als het fundament van een BI omgeving. Wij zien dit niet als twee losstaande problemen.
Om deze uitdagingen aan te kunnen is een nieuwe BI architectuur ontworpen. Deze architectuur kenmerkt zich door gelaagdheid. Grofweg kunnen de lagen in 3 soorten ingedeeld worden: data acquisitie, data beheer en data levering, vrij naar het Corporate Information Factory model van Inmon [1].
De lagen zijn in de praktijk gestapeld; de volgende lagen worden onderkend:
Bronsystemen zijn de ontsloten operationele systemen, dit kunnen databases zijn van applicaties, maar ook minder gestructureerde data of real time data op basis van services.
Een staging area zorgt voor gemak van verdere verwerking van de data, data wordt batchgewijs 1 op 1 uit de verschillende bronsystemen op een uniforme manier op een uniforme locatie opgeslagen en vanaf daar door de volgende laag opgepikt. De staging area wordt gegenereerd, zowel qua structuur als qua laadroutines.
De Source Data Vault (sDV) draagt zorg voor historie vastlegging. Het betreft een volgens Data Vault Modeling[2] gemodelleerde laag waarbij het bronmodel leidend is. Het bronmodel uit de staging area wordt omgezet in een data vault model. Elk bronsysteem heeft zijn eigen sDV. De sDV houdt historie vast, er wordt alleen maar data toegevoegd. Wordt er dus een wijziging gedetecteerd in het bronsysteem, wordt het bestaande record in de sDV afgesloten en een nieuw record aangemaakt (start geldigheid datum). Wordt data verwijderd, wordt het record in de sDV afgesloten.
In de sDV worden geen transformaties uitgevoerd. Cleansing en integratie vindt bewust later, benedenstrooms plaats. Hierdoor is traceability en auditability gewaarborgd. De staat van een bronsysteem is immers voor een willekeurig peilmoment te reconstrueren vanuit de sDV.
De sDV wordt gegenereerd, zowel qua structuur als qua laadroutines. De bouw van de sDV is dus aanbod-gestuurd.
Bovenop de verschillende sDV’s bevindt zich één Business Data Vault (bDV). Het doel van deze laag is het toepassen van herhaalbare business logica. Deze laag wordt gemodelleerd met een ‘business bril’.
Als eerste zorgt deze laag voor begrijpbaarheid. Het bDV model wordt volgens de business ontworpen. Entiteiten krijgen herkenbare namen (bijv. ‘costcntr_hub’ in de sDV wordt ‘kostenplaats_hub’ in de bDV). Alleen elementen die gebruikt worden volgens de business worden gemodelleerd. De bouw van de bDV is dus vraag-gestuurd.
Ten tweede zorgt deze laag voor business key integratie. Dit houdt in dat entiteiten die in verschillende systemen geregistreerd worden (in de praktijk zichtbaar als unieke business keys) in één bDV-entiteit geïntegreerd worden. Als voorbeeld: als medewerkers in systeem A (entiteit ‘employee’) en systeem B (entiteit ‘person’) geregistreerd worden, worden de bijbehorende sDV entiteiten in de bDV samengevoegd als één entiteit (entiteit ‘medewerker’) door het toepassen van business logica (bijv: employeenumber in systeem A moet gelijk zijn aan personcode in systeem B).
Er wordt niet direct gerapporteerd op de sDV of bDV. Gebruikers hebben geen toegang tot deze lagen. Hiervoor worden data marts ontworpen.
De data marts worden waar mogelijk gebouwd als views bovenop de bDV. Het creëren van deze views is eenvoudig. De data marts bestaan uit een stermodel met feiten en dimensies. Een feitentabel wordt opgebouwd uit een bDV-link (plus bijbehorende satelliet), een dimensie wordt opgebouwd uit een bDV-hub (plus bijbehorende satelliet). Heeft de eindgebruiker de behoefte aan een slowly changing dimension (SCD) wordt historie uit de satelliet meegenomen. Zo niet, worden alleen actuele records geselecteerd. Historie wordt immers al in de sDV vastgelegd. Herhaalbare business logica is reeds toegepast in de bDV.
Data marts worden hierdoor dus wegwerpbaar (disposable): ze zijn niet ‘duur’ om te maken. Een DM is puur een afleiding van de bDV. Een DM is snel gecreëerd en kan dus ook weer snel weggegooid worden als er geen noodzaak meer voor is. Er gaat geen data verloren, deze zit immers in de data vault. Desgewenst kan er specifieke business logica worden toegepast in deze DM, bijvoorbeeld wanneer er gevraagd wordt om specifieke filtering. Hierdoor zijn we niet gebonden aan een ‘single version of the truth’, die in de praktijk veelal niet bestaat.
Desgewenst kunnen data marts uiteraard ook met behulp van ETL tooling gerealiseerd worden, bijvoorbeeld wanneer de complexiteit de mogelijkheden van views overstijgt. Denk aan aggregatie of complexe rekenregels.
Front end tools worden gebruikt door de eindgebruiker. De tools halen hun data uit de zeer gestructureerde data marts. Deze tools kunnen bestaan uit rapportages, maar ook dashboards, analyse (OLAP) en data mining toepassingen.
Automatiseren waar mogelijk
Ons Enterprise Data Warehouse (EDW, van staging tot en met data marts) kenmerkt zich door een hoge mate van automatisering. Handwerk kost tijd en is foutgevoelig, en wordt waar mogelijk geautomatiseerd.
Een belangrijke eigenschap van een data vault model is herhaalbaarheid. De patronen van een data vault (entiteiten, laadroutines) zijn herhaalbaar en dus te automatiseren. Zeker in het geval van een sDV. Wij reverse engineeren bronmodellen en zetten deze om naar een data vault model. Zowel de structuur als de laadroutines van de sDV worden volledig gegenereerd. Slechts in het geval dat het bronsysteem geen keys en/of relaties heeft gedefinieerd (foreign key constraints) is er een eenmalige handmatige actie nodig (het aangeven van de sleutelvelden en definiëren van de relaties).
De laadroutines (ETL) en structuur (DDL) van de sDV zijn SQL statements (ANSI SQL compatible) en daarmee dus databaseonafhankelijk. Deze SQL wordt gegenereerd aan de hand van templates. Deze templates kunnen worden aangepast indien gewenst.
De bDV wordt handmatig gemaakt. Bij ons wordt de bDV niet fysiek geïmplementeerd. Dat wil zeggen: de bDV is in onze eerste opzet gebouwd als een verzameling views (wederom SQL) bovenop de sDV’s. Ook de data marts (DM’s) zijn in de eerste opzet een views, maar dan bovenop de bDV.
Deze views zijn eenvoudig van opzet. Alle complexe handelingen, zoals het vasthouden van historie, zijn immers al in onderliggende lagen opgelost. Handwerk is hierdoor voor ons geen bezwaar. De bouw van de bDV en de DM’s verloopt daardoor snel. Alle business logica hebben wij in wezen centraal; het zij gedefinieerd in verschillende views. De business logica wordt bij ons centraal gedocumenteerd (in een Wiki van het BICC).
Een entiteit in een data mart (DM) haalt dus gegevens uit de business data vault (bDV) die weer gegevens uit de source data vault (sDV) haalt. Het voordeel is dat de sDV op een willekeurig moment bijgewerkt kan worden, zonder verstoringen benedenstrooms. We zijn dus niet afhankelijk van batchverwerkingen die alleen ’s nachts plaats kunnen vinden.
Een nadeel zou performance kunnen zijn. Wij ervaren dit niet, o.a. omdat de views gebruik maken van de onderliggende indexen en wij momenteel geen gigantische hoeveelheden data hebben. Mocht performance een probleem worden, kan een view vrij eenvoudig fysiek gemaakt worden (materialized views). Ook zou hiervoor een ETL tool ingezet kunnen worden.
Tools en techniek
Het genereren van staging en source data vault doen wij met behulp van een open source data warehouse managementtool, Quipu [3].
Uitvoeren van de ETL doen wij met een open source data integratie tool: Pentaho Data Integration (PDI, voorheen Kettle) [4].
Beide tools hebben wij geïntegreerd. Zo wordt de door Quipu gegenereerde SQL door PDI uitgevoerd. Ook hebben we een template ontwikkeld die staging ETL genereert voor PDI. PDI voert deze ETL uit.
Daarmee hebben we een duidelijke scheiding aangebracht. Quipu gebruiken we voor het beheer van ons data warehouse (genereren) en PDI om daadwerkelijk data te laden en te transformeren (uitvoeren). Beide tools doen dus waar ze voor gemaakt zijn, maar zijn wel gekoppeld. PDI haalt zijn benodigde ETL direct uit de repository van Quipu. Daardoor ontbreekt ook hier handwerk.
Deze ontwikkelde toevoegingen en verbeteringen aan Quipu zijn teruggegeven aan de community en komen dus voor anderen beschikbaar.
Als databaseplatform wordt MS SQL 2008 gebruikt, dit is voor ons namelijk een standaardplatform dat centraal beheerd wordt en waarvan we genoeg kennis in huis hebben. Omdat de gegenereerde SQL voldoet aan een open standaard (ANSI SQL), is ons EDW echter onafhankelijk van een bepaald databaseplatform. Bijv. Oracle of PostgreSQL als platform zouden dus geen probleem moeten zijn.
Planning
Het EDW wordt in releases ontwikkeld.
Na het bedenken van de architectuur is in augustus 2010 begonnen met de bouw van release 1 van het EDW. De bouw wordt uitgevoerd door de 2 FTE van ons BICC. Hierbij gaat het niet om fulltime inzet, omdat de huidige BI omgeving ook nog beheerd en ondersteund dient te worden (de winkel moet open blijven tijdens de verbouwing).
Op dit moment wordt er reeds gewerkt aan de bDV, waarop later de DM’s worden gebouwd. De planning is dat dit jaar de belangrijkste DM’s gereed zijn, en volgend jaar begonnen kan worden met de ontsluiting (front-end tools). Halverwege 2011 willen we release 1 afronden.
In de eerste release worden vier bronsystemen ontsloten:
- CODA, ons boekhoudsysteem
- Ultimo, waarin we projecten managen en het inkoopproces plaatsvindt
- TIM, waarin uren gebudgetteerd en geschreven worden
- Beaufort, het HRM systeem van P&O (voor personen, afdelingen en dienstverbanden)
Samenvattend
In het begin van dit stuk werden een aantal uitdagingen genoemd. Onze BI architectuur dient de huidige problemen op te lossen en de toekomstige uitdagingen aan te kunnen.
- Informatiebehoefte wordt complexer
Geïntegreerde managementinformatie wordt eenvoudig mogelijk. Integratie wordt immers verzorgd door onze bDV. De data marts waarop gerapporteerd wordt, zijn bronsysteem overstijgend.
- Leveranciersafhankelijkheid
Het vasthouden van historie en het toepassen van business logica (integratie, transformatie) is centraal opgelost, in het EDW. De uiteindelijke data marts zijn zeer leesbaar en eenvoudig van opzet. Hierdoor kan met willekeurige rapportagetools gewerkt worden. Ook andere tools, zoals dashboards en interactieve analyse, kunnen eenvoudig aansluiten op deze data marts. We zijn dus niet meer afhankelijk van de producten van één leverancier.
Het centrale EDW is gebaseerd op open standaarden en maakt gebruik van open source software.
- Professionaliteit
Auditeerbaarheid en traceerbaarheid worden geboden door de data vault aanpak. Business logica krijgt een rechtmatige eigenaar: de business. Documentatie hiervan vindt ook centraal plaats, in een Wiki van het BICC.
- Flexibiliteit
Een belangrijke eigenschap van een data vault model is dat toevoegingen géén impact hebben op bestaande fysieke data vault structuren, er ontstaan alleen nieuwe data vault elementen. Bestaande elementen veranderen niet. Met andere woorden, de impact van toevoegingen is duidelijk te overzien. Komt er (een deel van) een bronsysteem bij, genereren we eenvoudigweg de bijbehorende staging en de sDV. Daarna wordt de bDV uitgebreid. Bestaande DM’s merken hier niets van.
Omdat de business logica centraal en eenmalig toegepast wordt (bDV), zijn ook wijzigingen in business logica eenvoudig door te voeren. Dit in tegenstelling tot een traditioneel DWH (Kimball) waarin business logica en historie verweven zijn.
Kortom, het EDW wordt lineair uitbreidbaar. Daardoor kan desgewenst klein worden begonnen.
- Real Time Data en Master Data Management
Een data vault is een ideale basis om real-time binnenkomende data vast te leggen. Berichtenverkeer kan getransformeerd worden naar een data vault model. Binnenkomende data wordt vastgelegd, inclusief historie. Transacties hoeven niet volledig te zijn om geladen te kunnen worden, in tegenstelling tot een traditioneel DWH (Kimball).
Een binnenkomende service of bus krijgt zijn eigen sDV. Dit is de rauwe ‘fact store’. Deze data wordt omgezet in een business model (bDV) en geïntegreerd met bestaande bronnen, daarbij rekening houdend met afspraken over welke systemen leidend zijn. Vanaf daar kan eenvoudig data worden gedistribueerd naar bestaande systemen (ETL). Dit kan allemaal in onze bestaande BI architectuur met de bestaande tools. We hoeven dus geen nieuwe, aparte activiteiten op te starten.
[1] Corporate Information Factory (CIF), Bill Inmon, http://www.inmoncif.com/home/
[2] Data Vault Modeling, Dan Linstedt, http://danlinstedt.com/about/data-vault-basics/
[3] Quipu, http://www.datawarehousemanagement.org/
[4] Pentaho Data Integration, http://kettle.pentaho.com/
Hoi Johannes,
ReplyDeleteGoeie post, dat belooft nog veel.
Groeten,
JJ.
Leuk artikel. Een vraag over jullie Data Vault. Gebruik je daar de originele brontabelnamen of zet je die gelijk om naar betekenisvolle namen? Ik kan me voorstellen dat het weinig zin heeft om de originele namen te behouden. Je slaat immers de SOURCENAME ook al op in je records (herleidbaarheid).
ReplyDeleteNog een vraag. Quipu genereert zoals je zegt SQL en slaat de SQL op in zijn database. Vervolgens moet je hier ETL van maken, bijvoorbeeld een Stored Procedure of SSIS package. Begrijp ik goed dat je daarvoor een tool gebruikt die dit de SQL omzet in ETL ?
Grts. Ronald
Oja nog wat. Je zegt voor je Data Mart gebruik te maken van View op je Business Vault. Ik kan mij voorstellen dat bepaalde FACT tabellen zo complex zijn dat je wel een fysieke tabel moet gebruiken. Neem bijvoorbeeld KPI tabellen met complexe business Logica. Maken jullie hiervoor een fysieke laag of los je dit anders op?
ReplyDeleteJohannes, mooie post, gefeliciteerd!
ReplyDeleteRonald, de SQL generatie gaat samen met de generatie van de ETL. Dit soort "mode-driven ETL" of "dynamic SQL" is iets dat door PDI/Kettle redelijk gemakkelijk te doen is omdat de ETL zelf ook puur bestaat uit model (ETL metadata).
Ik persoonlijk ben uitermate blij met software als Quipu omdat het uiteindelijk doet waar ik jaren geleden van droomde toen ik Kettle schreef.
Groeten,
Matt
Ronald,
ReplyDelete1) In de sDV gebruiken we de originele tabelnamen. Pas in de bDV hernoemen we entiteiten. Heb je in de bron een tabel 'Employee', wordt dit in de sDV 'Employee_h' en in de bDV creëren we een medewerker_h. Op deze manier kunnen we de sDV volledig genereren in Quipu. Zo lang tabelnamen in de bronsystemen niet wijzigen (wat niet zomaar zou mogen), blijft de sDV gelijk. Het hernoemen (oftewel interpreteren) van entiteiten zien wij als het toepassen van business logica; iets dat volgens onze visie in de bDV hoort.
2) De SQL statements om onze data vault te laden (vanuit de staging) worden door Quipu gegenereerd en opgeslagen in de Quipu repository (ook een database). Wij hebben een Kettle job gemaakt die deze statements in de goede volgorde uit de repository haalt en afvuurt op de EDW database. Simpel en effectief. Hierover zal ik later nog een blogpost schrijven incl. de Kettle transformaties.
Voor het laden van de staging hebben we een aparte template geschreven specifiek voor Kettle. Deze genereert Kettle transformaties (die op XML gebaseerd zijn). Ook hiervoor hebben we in Kettle een job gebouwd die deze transformaties direct uit de Quipu repository haalt en uitvoert.
Dat dit allemaal mogelijk is geeft m.i. de enorme kracht en flexibiliteit van Kettle/PDI aan.
3) Wanneer data marts te complex worden kunnen we inderdaad ETL gebruiken. Geen probleem. In dat geval bouwen we Kettle transformaties om data marts te vullen. Ons EDW bevindt zich in één database en is ingedeeld in schema's. Een data mart kent zijn eigen schema. Fysieke data mart tabellen worden daar dan aan toegevoegd, naast de evt. reeds aanwezige views.
Johannes,
ReplyDeletePrachtig artikel, mijn complimenten zowel voor jou als je werkgever om dergelijke visies ook uit te mogen voeren.
Ik heb echter veel vragen, hieronder een deel van die vragen. Zie de vragen niet als kritiek, ik wil leren, discussie en fun!
Ik ben nog steeds zeer sceptisch over een source data vault. Ik snap zijn bestaansreden nog steeds niet goed. Het lijkt een soort technische interface te zijn - maar is het bronmodel dat ook al niet? Wat voor waarde brengt deze laag in het totale plaatje? En waarom niet gewoon de data vanuit de staging (of deze zelfs overslaan) naar een Data Vault brengen waar de Hubs zijn gekozen vanuit een bedrijfsgegevens model? Klopt mijn veronderstelling dat nagenoeg elke entiteit in het bronsysteem nu een Hub is? Laatste vraag in dit kader; hoe zie jij in jullie architectuur de ontkoppeling met de bron, waar is die ontkoppeling nu?
Nu begrijp ik dat je de vertaling naar het bedrijfs gegevens model in de Business Data Vault doet (ik neem aan met name bij de Hubs?)? Is dat zo? Want je schrijft dat de bestaansreden van de bDV de herhaalbare business logica is. Dat is niet hetzelfde als het bedrijfs gegevens model. Verder, mag een datamart alleen gebouwd worden vanuit de bDV? of mag je deze laag ook overslaan? Er zal tenslotte niet altijd sprake zijn van herhaalbare business logica?
Datamarts maak je met views, maar hoe ga je dan om met de aardig complexe tijdslijnen die complexer worden naarmate een dimensie bestaat uit meerdere hubs en sats? De onderliggende views zijn aardig complex dan neem ik aan? Het zou ook kunnen dat je alleen type 1 dimensies maakt - dat zou het aanzienlijk versimpelen, maar dan ben ik heel benieuwd hoe je type 2 gaat aanbieden? Biedt of ga je die aanbieden?
Klopt de veronderstelling dat je alle data integratie wil doen tussen sDV en bDV? Zie je geen data integratie tussen bDV en datamart? Ik wel…..;-)
Verder zie ik veel views - hoe draag je zorg voor de lineage? Verbergen views die lineage niet?
Ik zie dat je totnogtoe bedrijfsvoerings systemen ontsluit, waaronder Beaufort. Nu ken ik dit systeem een beetje...en het is modelmatig een ramp. Hoe hier qua generatie ordentelijke soep van kan worden gekookt is mij een raadsel. Ik zou dat graag eens bij je willen bekijken ;-)
Verder zeg je ook zelf dat het volume nu nog meevalt, ik ben wel benieuwd wat volume voor een effect heeft op deze architectuur (vooral qua beheerbaarheid op termijn). Met name zou ik zorgen hebben over de processturing van de data logistiek.
Nogmaals dank voor je artikel - zet mij ook weer op scherp of vele verschillende aspecten. Het bovenstaande is een zeer kleine greep daaruit.
Groet!
Ronald Damhof
Ronald Damhof
Even een opmerking over Ronald D. z'n views: Views zijn dè manier om relationeel je linaging te implementeren. Het probleem zit hem in de gebrekkige implementatie van afgeleide relaties in SQL DBMSen. Er zijn wel truukjes om de lineaging uit je views te halen, maar de meeste architecturen genereren vanwege dit probleem juist hun views op basis van linaging ipv andersom.
ReplyDeleteRonald,
ReplyDeleteDank je! Vooraf: ik ben erg blij met je vragen, dat zet mij ook weer aan het denken. Een data vault kun je zoals je weet op verschillende manieren ontwerpen, zo lang je je aan de modelleringsregels houdt is het in principe OK, zo hoeft de ene manier niet 'slecht' te zijn en de andere 'goed'. Een dergelijke discussie houdt voor mij de redenen om de ene manier boven de andere te verkiezen, scherp. En dat is alleen maar goed.
Om terug te komen op je vragen; ik hoop dat ik ze allemaal beantwoord:
1) Redenen voor een sDV
Quipu leest een bronmodel in, samen met primary key en foreign key constraints. Deze informatie gebruikt Quipu om een data vault model af te leiden. Als voorbeeld: een entiteit in het bronmodel met foreign keys wordt standaard een link. Zonder fk's een hub. Deze afleidingsregels zijn in Quipu te volgen en zelfs te beïnvloeden.
Wanneer je dus een bron hebt die 'netjes' alle constraints heeft gedefiniëerd, kun je volledig geautomatiseerd een data vault creëren. Het voordeel hiervan is dat je met weinig moeite een data vault gebouwd hebt die historie vasthout van je bron. Dit gaat echt ontzettend snel. Je kunt hierdoor dus aanbod-gedreven ontwikkelen. Zo hoeft je bedrijfsgegevensmodel nog niet bekend te zijn om dit al te kunnen doen. Je bDV (die je vraag-gedreven ontwikkelt) kun je later eenvoudig uitbreiden; een data vault met historie heb je immers al. Je hoeft deze alleen nog te vertalen naar het bedrijfsmodel.
Je sDV is dus ook niet meer gevoelig voor veranderingen in het bedrijfsgegevensmodel. Als voorbeeld; verandert de definitie van een business-entiteit, passen we deze aan in de bDV. Dit heeft ook geen consequenties voor bestaande historie. Deze hebben we immers al opgebouwd in de sDV. Je bedrijfsmodel ligt dus als een soort meta-laag over je bronmodel heen.
2) Waarom niet staging overslaan
Onze bronsystemen draaien op verschillende platforms. Quipu genereert data vault ETL als "INSERT INTO .. SELECT .." SQL statements op één database. Wij zetten Kettle/PDI in als ETL tool, Quipu beoogt bewust geen ETL tool te zijn. Platformoverstijgende zaken doen we dus met een tool die daar goed in is: Kettle.
Overigens is zo'n aparte fysieke staging area niet strict noodzakelijk. Op SQL Server bijv. zou je mogelijk kunnen volstaan met linked servers naar de bronsystemen toe. Die zou je dan kunnen zien als staging laag. Vanaf daar laad je de data vault. Ik heb dit niet geprobeerd, maar zou wel een interessante mogelijkheid kunnen zijn.
3) Herhaalbare business logica
In de bDV passen we herhaalbare business logica (logica die vaker toegepast wordt en tussen DV en DM dus niet op zijn plaats is) toe. Tevens doen we de vertaling naar het bedrijfs gegevens model (dank je voor dit begrip, een veel betere omschrijving).
[vervolg antwoord voor Ronald]
ReplyDelete4) Data marts
Een data mart zal in de meeste gevallen zijn gegevens uit de bDV halen. Dat hoeft echter niet. Ik kan me gevallen voorstellen waarin je data uit de sDV wil halen richting de DM. Bijv. als de herhaalbare business logica niet geldt. Één van de manieren om meerdere versies van de waarheid te kunnen leveren als dat noodzakelijk is. En ja, er kan ook data integratie plaatsvinden tussen de bDV en DM. Zodra deze herhaalbaar is, vindt hij echter tussen sDV en bDV plaats.
Het niet toestaan van data die uit de sDV laag direct omhoog groeit naar de DM laag hebben wij overigens 'worteldoek' gedoopt :-).
5) Lineage
Ik kan het niet beter verwoorden dan Martijn, dank daarvoor. Praktijkvoorbeeldje voor MS SQL 2008: ik kan een bDV entiteit (bijv. hub) openen en via 'View dependencies' precies zien in welke links deze gebruikt wordt, welke sat's deze heeft, etc. Dit RDBMS gaat dus vrij slim om met views en hergebruikt de constraints van de onderliggende fysieke tabellen. Maak ik de bDV fysiek, ben ik deze kwijt.
6) Beaufort
Je observatie klopt. Modelmatig een ramp is nog een understatement :). Ik moet zeggen dat ik de database inmiddels behoorlijk goed ken omdat ik deze al eerdere keren ontsloten heb. Je bent welkom :-)
Het hebben van een source data vault dient meerdere zaken, waaronder:
ReplyDelete1. semantische integratielaag zonder transformatie (tbv traceability)
2. basis voor informatie uitwisseling op basis van een communicatie model
zie ook: http://www.nippur.nl/Blog/tabid/57/EntryId/14/Information-hub-serving-many-purposes.aspx
Hallo Johannes,
ReplyDeleteIk wil reageren op punt 1: sdv. Wat je als alternatief kunt doen is een historical staging area opzetten die letterlijk alle historie gaat opslaan vanuit je bronsysteem. Op deze manier pas je ook geen logica toe maar bouw je toch historie op, ook van de zaken waarvan je nog niet weet of je die ooit nodig gaat hebben! Zodra de business vraagt om gegeven X die nog niet in je datavault zit kun je deze eenvoudig opnemen door de data uit je historical staging area te laden. Voordeel hiervan is dat je nog geen model hoeft te genereren maar gewoon 1:1 je bron overneemt, dat scheelt een stap. Het nadeel vind ik zelf dat, indien je enorme bronsystemen hebt, je veel (onnodige) opslag gaat genereren. Het voordeel is dat je wel alle historie hebt en dus aan de businessvragen kunt voldoen. Een HSA kun je ook genereren als je de juiste scripts hebt. Zo zie je maar, mogelijkheden te over :-)
Succes met je DBM artikel.
grts. Ronald
Hallo Johannes,
ReplyDeleteBeetje laat. Maar het is voor het eerst dat ik dit artikel onder ogen heb gekregen. Interessant hoe jullie dat aanpakken. Heeft mij aan het denken gezet over het project waar ik zelf momenteel aan werk. Mogelijk kan Quipu het aantal handmatige acties wat terugbrengen. Gaan we onderzoeken!
Dank daarvoor!
Hello,
ReplyDeleteWe facilitate the provision of independent analysis to support expert testimony, regulatory or legislative engagements. Frequently, this work includes economic, financial and statistical studies of varying data analysis, technical and http://www.stlouisbridal.com.