Opzet en architectuur van ETL

ETL staat voor Extractie, Transformatie en Laden en is de programmatuur voor het vullen van het datawarehouse. Het ontwikkelen van ETL is de grootste kostenpost van een datawarehouse. 70% van de initiele investering gaat hierin zitten.

Op dit moment zitten we in een overgangssituatie: Traditioneel wordt het grootste deel van de ETL handmatig ontwikkeld, we gaan naar een situatie toe waarin zo weinig mogelijk handmatig wordt geprogrammeerd, dankzij wizards, generatoren en scriptingtalen. Er is volop discussie onder de experts of het haalbaar en wenselijk is om volledig te genereren.

Voordelen hiervan zijn:

Snellere resultaten
Lagere ontwikkelkosten
Flexibeler kunnen inspelen op wijzigingen in bronsystemen of business vraag
Het zwaartepunt verschuift meer van de techniek naar de business vraag
Beter te onderhouden en beheren

Alle toolleveranciers zijn hier druk mee bezig en de eerste producten zijn er al, waarmee helemaal niets meer handmatig hoeft te worden geprogrammeerd. Dit betekent dat de ETL-architectuur hier rekening mee moet houden, aangezien je op enig moment mee wilt gaan met deze trend. Volgens mij het liefst nu, maar daar is dus nog de nodige discussie over.

Hiervoor is een hoge mate van standaardisatie nodig. Vergelijkbare laadprocessen moeten ALTIJD op dezelfde manier worden uitgevoerd, via dezelfde tussenstappen en dezelfde type bewerkingen. In de praktijk zie je dat organisaties steeds weer in de verleiding komen om van de standaarden af te wijken. Een organisatie heeft bijvoorbeeld als standaard dat data aangeleverd wordt via een tekstbestand en dat deze data onbewerkt in een staging tabel in de database wordt opgeslagen, voordat er bewerkingen plaatsvinden. Vaak bestaat de neiging om de opslag in een stagingtabel over te slaan, omdat er toch geen bewerking plaatsvindt op de data. Dat is niet handig. Het maakt de processen minder duidelijk en als er later toch nog een bewerking plaatsvindt, wordt dan meestal niet alsnog een staging tabel aangemaakt. (Zo gaat het in uw organisatie natuurlijk niet!)

Wat zijn de voordelen van een strikte standaardisatie:

processen worden simpeler
vergelijkbare processen verlopen op vergelijkbare manier
De technische infrastructuur is gemakkelijk te beheren vanwege bovenstaand punt
Performance tuning is eenvoudiger vanwege de eerste twee punten
Er is minder documentatie nodig (dataflow = gekozen standaardmethode, beschrijving bron en target, bron - targetmapping en motivatie voor de gekozen oplossingen )
Het maakt het genereren van laadprocessen mogelijk

Genereren van laadprocessen heeft alle bovenstaande voordelen en daar bovenop:

Je kunt de standaardoplossing aanpassen en in een keer toepassen op alle gevallen, bijvoorbeeld een wijziging van standaard naamgeving, veldgroottes, technische kenmerken.
Je kunt extra controles inbouwen. Vanwege de hoge investering en de lage frequentie van fouten wil je bijvoorbeeld niet handmatig een check op alle velddefinities inbouwen (numeriek, datum, veldlengte etc.). Als je genereert wil je dat wel.

Strikte standaardisatie betekent niet dat alle laadprocessen op dezelfde manier plaats moeten vinden. Een bron met 100 miljoen nieuwe transacties per dag zal je niet op dezelfde manier kunnen en willen verwerken als een bron met 50 records.

Mijn aanpak voor de opzet en ontwikkeling van ETL is als volgt:

Bij voorkeur een tool gebruiken waarmee ETL automatisch wordt gegenereerd, bijvoorbeeld BIReady of Powerpack van BI-quest.
Een geschikte keuze maken voor een beperkt aantal standaard oplossingen. Hierbij gaat het zowel om functionaliteit als om de technische uitwerking. De juiste keuze scheelt een heleboel problemen bij productie en onderhoud.
Met behulp van wizards, generatoren of scripts genereren van de laadprocessen mogelijk maken.
De standaarden strikt handhaven.
Als er geen geschikte standaard lijkt te zijn voor een laadproces, is het verstandig terug te gaan naar de tekentafel. Vaak is er sprake van een minder handig ontwerp. Als het echt nodig is, voeg dan een nieuwe standaard toe.
Regelmatig evalueren of de standaarden nog voldoen.
En het allerbelangrijkste: Blijven controleren of iedereen echt aan de standaarden voldoet.