ETL Tool of SQL

In een voorgaand artikel schreef ik over het voordeel van het afhandelen van wijzigingen binnen een dimensie volgens het Kimball Slowly Changing Dimension Type 2 principe, het aanmaken van een nieuwe rij binnen een dimensie. Er is uitgelegd wat de voordelen van deze methode zijn en hoe het werkt. Hieronder staat beschreven wat de voordelen zijn van het gebruik van T-SQL scripts ten opzichte van een ETL-Tool voor het bijwerken van een dimensie.

Wat controleer je?
Het bijwerken van een dimensie is saai. Negen van de tien keer doe je hetzelfde truukje opnieuw. Je pakt een datastroom uit een bronsysteem en een datastroom uit een dimensie. Deze houd je tegen elkaar aan en vervolgens controleer je altijd drie dingen:

• Zijn er wijzingen opgetreden;
• Zijn er deletes;
• Zijn er logische deletes.

Een wijziging is een verandering van een veld in een bronsysteem die impact heeft op een attribuut binnen een dimensie, bijvoorbeeld: de achternaam van een klant is veranderd doordat hij is getrouwd. Een delete is een record dat fysiek niet meer aanwezig is binnen een bronsysteem en een logische delete is een record dat met een markering als verwijderd is gekenmerkt.

Tool of SQL?
Voor het controleren van deze drie eigenschappen zijn verschillende methoden. Je kunt een ETL-tool gebruiken zoals SQL Server Integration Services of je kunt zelf een script bouwen / genereren die deze controle voor je doet. Ik ben altijd een voorstander geweest van tools. Tools zijn zelf-documenterend en nemen veel werk uit handen. Nu ik met een project bezig ben waarbij veel acties met SQL worden afgehandeld zonder tools zie ik steeds meer de voordelen van het links laten liggen van tools.

Voordelen:

• Voorkomt problemen met versieovergang
• Genereerbaar
• Werkt altijd
• Beheersbaarheid

Met de eerste bedoel ik de problemen die ontstaan wanneer de leverancier van een ETL-tool besluit een nieuwe versie op de markt te brengen die net iets beter is dan de vorige en dan na een tijdje besluit de oude versie niet meer te ondersteunen. Met SQL heb je dit niet. De basis van SQL blijft altijd hetzelfde, ook na een versieovergang. Met genereerbaar bedoel ik dat je met dynamische SQL objecten kunt genereren die het werk voor je doen. Denk aan een stored procedure. Wanneer ik SSIS (Integration Services) besluit in te zetten moet ik voor iedere dimensietabel een SSIS-package aanmaken (vanuit een template) en moet ik altijd handmatig dingen aanpassen. Een SSIS-package kun je NOOIT genereren! Daarnaast moet ik al die honderderen SSIS packages aanpassen als er iets veranderd (beheersbaarheid). Tot slot, SQL is betrouwbaar en werkt altijd, van SSIS is dat nog maar de vraag. Ik heb meerdere keren vage bugs en meldingen gezien die opeens ontstonden en opeens verdwenen!

Nadelen:

• Complexer en minder overzichtelijk
• Meer initieel ontwikkelwerk

ETL tools zijn zelf-documentered. Door gebruik te maken van tools zoals een Dataflowtask of een Derived Column zie je wat er gebeurd. Ook zijn tools sneller te begrijpen dan lappen code. Tot slot is het bouwen van je eigen ETL natuurlijk veel meer werk. Toch pluk je hier denk ik op langere termijn de vruchten van. Staat je oplossing eenmaal dan is het datawarehouse schaalbaarder en beter beheersbaar. Tot zover mijn mening over het gebruik van SQL vs TOOLS.