Het slagen van een datawarehouse-project hangt samen met verschillende factoren. Een veel aangehaalde reden voor het verliezen van momentum is dat het gewoonweg te lang duurt voordat de investering zich terugbetaalt. Verreweg de meeste tijd binnen een dergelijk project wordt besteed aan ETL werkzaamheden (Extract, Transform, Load). Een substantieel deel daarvan is repetitief van nature; het verplaatsen van inhoud van de ene tabel naar de andere. Dit werk kan bijzonder tijdrovend zijn. Een schijnbaar eenvoudige klus als het overzetten van een flink aantal tabellen naar de eerste staginglaag is niet snel te realiseren. Of het nu gaat om duizenden tabellen of slechts enkele tientallen. Laat staan als er vervolgens wijzigingen aan deze logica moeten worden doorgevoerd, of data historisch moet worden opgeslagen.
Ingegeven door het gebrek aan flexibiliteit en de lange lifecycle is er een stroming ontstaan die zweert bij Datawarehouse Automation. Kort gezegd: het automatisch genereren van ETL-code in de vorm van SQL, of voor ETL-tools geschikte metadata. Het groeiend aantal aanbieders van tooling omtrent DWH automation laat zien dat de markt sterk in ontwikkeling is. Ook Ensior onderkent al lange tijd de toegevoegde waarde van automatiseren en heeft verschillende eigen concepten ontwikkeld. Bijvoorbeeld een Staging Generator voor een ETL-tool als SAP BusinessObjects Data Services, maar ook concepten die zonder ETL-Tool ingezet kunnen worden. Op zo’n laatste concept zoomen we verder in.
Datawarehouse Automation: een praktijkvoorbeeld
Voor een datawarehouse op een Microsoft SQL Server platform hebben we enkel een verzameling Stored Procedures en Views aangemaakt, samen met gedegen Naming Convention en sturingstabellen. Dit concept werkt anders dan de meeste DWH Automation tooling, die veelal “model driven” werken en de regie vrijwel volledig overnemen. Het uiteindelijke DWH model moet daarbij volgens een heel specifieke gedachtengang worden ingericht. Daarbij worden voornamelijk de technische aspecten van zo’n model geautomatiseerd, waarbij de requirements van de business alsnog moeten worden geadresseerd. Bij onze oplossing zijn de business wensen juist geheel naar vrijheid in te vullen en direct te integreren, terwijl veel tijdsbesparing wordt behaald op de technische realisatie ervan.
Om een tipje van de sluier op te lichten laat onderstaande generieke Stored Procedure zien hoe via systeemtabellen (in dit geval INFORMATION_SCHEMA) andere Stored Procedures gegenereerd kunnen worden, met als doel het vullen van (in dit geval) tabellen in de historische staging-laag van de DWH omgeving.
Bij het uitvoeren van deze stored procedure wordt voor een op te geven tabel een nieuw Stored Procedure script gecreëerd met onderstaande inhoud (in dit geval voor TABLE_1).
Deze gegenereerde procedure kan vervolgens elke dag automatisch worden aangeroepen om de data daadwerkelijk over te zetten. De kracht van het aanroepen van de generieke Stored Procedure komt nu echt naar boven, omdat we deze ook in één keer voor alle tabellen kunnen draaien middels een specifieke “master procedure”. Het creeren en onderhouden van de ETL logica voor een flinke hoeveelheid tabellen is daardoor dus geen monnikenklus, maar een beheersbaar proces. Stel, we willen vervolgens voor alle tabellen logica voor de “nvarchar” kolommen aanpassen, dan is dit te realiseren met 1 enkele wijziging en 1 druk op de knop voor alle (bijvoorbeelden duizenden) tabellen!
Het geautomatiseerde proces houdt echter niet op na een staginglaag. De transformatieslagen voor het vullen van dimensietabellen en feitentabellen zijn ook te integreren. De specifieke business logica, waar je niet aan ontkomt, worden namelijk ondergebracht in views, die weer wordt aangeroepen door generiek te genereren Stored Procedures. Hier gaan we in een opvolgende blog verder op in, naast de meer complexe aspecten en randvoorwaarden van een dergelijke oplossing.
