Jeg er en doven programmør! Det var en vigtig detalje, som jeg lærte af Roelant Vos i hans træning i sidste uge. Men der var mange andre interessante emner. Et personligt resumé af et 3-dages kursus om Data Warehouse Design Patterns.
I sidste uge havde jeg mulighed for at deltage i undervisningen Data Warehouse Design Patterns af Roelant Vos. Jeg har set Roelant i præsentationer på datamodelleringskonferencer, og jeg sætter pris på hans blog med en masse nyttige oplysninger om Data Warehouse arkitektur og Data Vault implementering. Så da jeg fik information fra mine Trivadis-kolleger om, at han vil give et kursus i Zürich, tog jeg chancen og deltog i dette 3-dages kursus.
Jeg vil ikke skrive en detaljeret gennemgang af hele kurset i dette blogindlæg. Men i de følgende linjer finder du nogle noter om tre emner, der – set fra mit synspunkt – var vigtige i denne uddannelse: Pattern Based Design, Persistent Staging Area og Virtual Data Warehouse.
En typisk datawarehouse-arkitektur består af flere lag til indlæsning, integration og præsentation af forretningsoplysninger fra forskellige kildesystemer. Antallet og navnene på lagene kan variere i de enkelte systemer, men i de fleste miljøer kopieres dataene fra et lag til et andet med ETL-værktøjer eller rene SQL-angivelser. Med en god arkitektur er mønstrene til at transformere og indlæse dataene i et bestemt lag altid ens. Dette gør det lettere (og hurtigere) at udvikle ETL-processerne, fordi de gentagelige mønstre kan genereres med et datawarehouse-automatiseringsværktøj (DWA-værktøj). På Roelant’s blog kan man finde en oversigt over hans Data Integration Framework. Kodeeksempler er tilgængelige på GitHub.
Hvorfor er jeg en doven programmør? Som mange andre udviklere kan jeg ikke lide at skrive gentagende kode. Roelant er også en doven programmør. Derfor har han brugt meget tid på at udvikle værktøjer og metoder til at fremskynde udviklingsopgaverne ved at generere SQL-koden til at opbygge og indlæse datawarehouses. I løbet af kurset forklarede han mange designmønstre med SQL-generatoren VDW (Virtual Data Warehouse). Den kan downloades gratis fra hans hjemmeside og er nyttig til hurtige prototyper og regressionstests af mønsterændringer.
Persistent Staging Area
Et vigtigt lag i den foreslåede arkitektur er PSA (Persistant Staging Area). Selv om dette område i staging-laget er valgfrit, er det meget praktisk og stærkt anbefalet, især når forretningskravene endnu ikke er klare i begyndelsen af projektet. PSA er et historisk arkiv af data fra kildesystemerne og erstatter det klassiske flygtige Staging Area. PSA’en indlæses enten med CDC-mekanismer (Change Data Capture) eller med en delta-detektion mellem kildesystemet og den aktuelle version af PSA’en. Det vedvarende stagingområde er den unikke kilde til indlæsning af Data Vault-tabellerne (hubber, links og satellitter) i integrationslaget.
Førdelen ved et vedvarende stagingområde er, at kun de aktuelt nødvendige dele af oplysningerne skal indlæses i Data Vault-tabellerne. Vi behøver ikke at bekymre os om fremtidige krav, fordi de oprindelige data stadig er tilgængelige i PSA’en og kan genindlæses, når der er behov for dem. Jeg har set og brugt denne tilgang i flere kundeprojekter, og det er en god forsikring mod ukendte forretningskrav.
Virtual Data Warehouse
Da jeg så Roelant Vos for første gang på konferencen Data Modeling Zone 2017 i Düsseldorf, blev jeg meget imponeret over en interessant arkitekturtilgang, som han forklarede: Det eneste persistente lag i et datawarehouse er PSA’en, og alt andet er implementeret oven på PSA-tabellerne med views. Dette er den konsekvente implementering af et Virtual Data Warehouse, som understøttes af Roelant’s VDW-software. Jeg har set dette i teorien og i nogle præsentationer, men aldrig i sin fulde form i et reelt projekt.
Denne “NoETL”-tilgang har flere fordele: 1. Det er meget nemt at ændre transformationslogikken uden at genindlæse alle lag i dit datawarehouse. 2. Så snart nye data er indlæst i PSA-laget, er de straks synlige i alle efterfølgende lag. 3. Det er en slags schema-on-read data warehouse, hvor du på forespørgselstidspunktet kan bestemme, hvordan kildedataene skal fortolkes. Det lyder alt sammen meget fint, men jeg ser stadig udfordringen i forhold til god query performance. Jeg mener, at i de fleste situationer skal i det mindste de almindeligt anvendte data persisteres. Men med view-tilgangen kan dette gøres uden den store indsats, f.eks. med materialiserede views.
Det 3-dages kursus har mere end indfriet mine forventninger. Selv om jeg allerede selv brugte nogle af koncepterne (for at være ærlig, så var det meste af det Roelant forklarede mig allerede bekendt), kunne jeg virkelig godt lide den trinvise opbygning af en datawarehouse-arkitektur ved hjælp af mange kodeeksempler og live demoer. Eller som jeg sagde som spontan feedback i slutningen af kurset: “Det var sjovt”.