Jag är en lat programmerare! Det var en viktig detalj som jag lärde mig av Roelant Vos under hans utbildning förra veckan. Men det fanns många andra intressanta ämnen. En personlig sammanfattning av en tredagarskurs om Data Warehouse Design Patterns.
Förra veckan hade jag möjlighet att delta i kursen Data Warehouse Design Patterns av Roelant Vos. Jag har sett Roelant i presentationer på datamodelleringskonferenser och jag uppskattar hans blogg med mycket användbar information om Data Warehouse-arkitektur och Data Vault-implementering. Så när jag fick information från mina Trivadis-kollegor om att han skulle hålla en utbildning i Zürich tog jag chansen att delta i denna tredagarskurs.
Jag kommer inte att skriva en detaljerad recension av hela kursen i det här blogginlägget. Men på följande rader hittar du några anteckningar om tre ämnen som var – ur min synvinkel – viktiga i denna utbildning: En typisk datalagerarkitektur består av flera lager för att ladda, integrera och presentera affärsinformation från olika källsystem. Lagrens antal och namn kan variera i varje system, men i de flesta miljöer kopieras data från ett lager till ett annat med ETL-verktyg eller rena SQL-anvisningar. Med en bra arkitektur är mönstren för att omvandla och ladda data till ett visst lager alltid lika. Detta gör det lättare (och snabbare) att utveckla ETL-processerna, eftersom de upprepbara mönstren kan genereras med verktyg för automatisering av datalager (DWA). På Roelants blogg finns en översikt över hans ramverk för dataintegration. Kodexempel finns på GitHub.
Varför är jag en lat programmerare? Liksom många andra utvecklare gillar jag inte att skriva repetitiv kod. Roelant är också en lat programmerare. Därför har han lagt ner mycket tid på att utveckla verktyg och metoder för att påskynda utvecklingsuppgifterna genom att generera SQL-koden för att bygga och ladda datalager. Under kursen förklarade han många designmönster med SQL-generatorn VDW (Virtual Data Warehouse). Den kan laddas ner gratis från hans webbplats och är användbar för snabba prototyper och regressionstester av mönsterändringar.
Persistent Staging Area
Ett viktigt lager i den föreslagna arkitekturen är PSA (Persistant Staging Area). Även om detta område i staginglagret är frivilligt är det mycket praktiskt och rekommenderas starkt, särskilt när verksamhetskraven ännu inte är klara i början av projektet. PSA är ett historiskt arkiv för data från källsystemen och ersätter det klassiska flyktiga Staging Area. PSA laddas antingen med CDC-mekanismer (Change Data Capture) eller med en deltadetektering mellan källsystemet och den aktuella versionen av PSA. Det beständiga stagingområdet är den unika källan för att ladda tabellerna i datavalvet (nav, länkar och satelliter) i integrationsskiktet.
Fördelen med ett beständigt stagingområde är att endast de delar av informationen som för närvarande krävs behöver laddas in i tabellerna i datavalvet. Vi behöver inte bry oss om framtida krav, eftersom de ursprungliga uppgifterna fortfarande finns tillgängliga i PSA och kan laddas om när de behövs. Jag har sett och använt det här tillvägagångssättet i flera kundprojekt, och det är en bra försäkring mot okända affärskrav.
Virtual Data Warehouse
När jag såg Roelant Vos för första gången på konferensen Data Modeling Zone 2017 i Düsseldorf, blev jag mycket imponerad över ett intressant arkitektoniskt tillvägagångssätt som han förklarade: Det enda persistenta lagret i ett datalager är PSA, och allt annat implementeras ovanpå PSA-tabellerna med vyer. Detta är den konsekventa implementeringen av ett virtuellt datalager som stöds av Roelants VDW-programvara. Jag har sett detta i teorin och i vissa presentationer, men aldrig i sin fulla form i ett verkligt projekt.
Denna ”NoETL”-strategi har flera fördelar: 1. Det är mycket enkelt att ändra omvandlingslogiken utan att ladda om alla lager i ditt datalager. 2. Så snart nya data laddas i PSA-skiktet är de omedelbart synliga i alla efterföljande lager. 3. Det är ett slags schema-on-read datalager där du vid frågetillfället kan bestämma hur källdata ska tolkas. Allt detta låter väldigt trevligt, men jag ser fortfarande en utmaning i form av god frågeprestanda. Jag tror att i de flesta situationer måste åtminstone de data som används ofta persisteras. Men med view-ansatsen kan detta göras utan större ansträngning, till exempel med materialized views.
Den 3-dagars kurs har mer än uppfyllt mina förväntningar. Även om jag redan använde en del av koncepten själv (om jag ska vara ärlig så var det mesta som Roelant förklarade redan bekant för mig), gillade jag verkligen den stegvisa uppbyggnaden av en datalagerarkitektur med hjälp av många kodexempel och live-demonstrationer. Eller som jag sa som spontan feedback i slutet av kursen: ”Det var roligt”.