Heute mal wieder ein paar Gedanken zur Architektur einer ETL Lösung. Genaugenommen sind wir bei der Klärung von einigen grundlegenden Fragestellungen. Welche können das beim Einsatz von Integration Services (SSIS) als ETL Lösung sein?

Viele Fragestellungen bzw. Herausforderungen, welche ich im Rahmen von Coachings gestellt bekommen habe bzw. wir als Team in Projekten angetroffen haben, lassen sich auf einige grundlegende Missverständnisse und inkonsequente Entscheidungen zurückführen. Dabei geht es nicht um technische Details.

Ist tatsachlich die Entscheidung für eine echte ETL Lösung getroffen worden?

ETL heißt nicht, dass ein bestimmtes Tool verwendet wird! Also, wir verwenden die Integration Services heißt nicht automatisch, dass man da von ETL sprechen kann oder sollte. ETL ist für mich die konsequente Verfolgung eines Konzeptes. Und es heißt viel mehr als nur in Extract, Transform und Load zu denken, denn das trifft auch auf die meisten üblichen Schnittstellen zu.

ETL heißt u. a., dass alle Beteiligen sehr wahrscheinlich in Zukunft in Datenpaketen denken müssen. Und damit ist nicht gemeint, dass SSIS Task in Paketen organisiert werden, sondern "wieder" klassische Batchverarbeitung von Datensätzen angesagt ist. Aber nur mit diesen einfachen aber effektiven Methoden können Datenmengen in Enterprise Umgebungen auch nachhaltig bewältigt werden.

Ist jemand im Team, der schon mal ein echtes Data Warehouse gesehen hat?

Ok, provokant, aber leider eine berechtigte Frage! Denn mit Integration Services zu arbeiten heißt nicht, dass man später nur noch mit bunten Pfeilen Kästchen verbinden darf und alles andere ist dann von ganz allein im Lot. Viel zu häufig erlebe ich, dass die SSIS unterschätzt werden. Das grundlegende Konzept ist ja auch sehr einfach. Da kommt dann gerne mal im Workshop oder Proof-of-Concept viel zu schnell ein "Schnittstelle, verstanden, lassen Sie uns jetzt bitte mit diesen Würfeln weitermachen.". Daher, da muss jemand ins Team, der das Ziel kennt.

Ist eine Entscheidung für den Einsatz des Datenflusstasks getroffen worden?

Was soll das denn jetzt? Der Datenflusstask ist doch das Herz der Integration Services! Korrekt, aber ich kenne einige sehr erfolgreiche und durchaus komplexe BI Projekte, welche komplett auf den Datenfluss Task verzichtet haben. Warum? Ja, weil einfach die Anforderung für den Einsatz fehlte. Zwar wurde der Bewirtschaftungsprozess komplett in SSIS gekapselt, aber es wurden konsequent SQL Statements für die Verarbeitung der Daten eingesetzt.

Den Datenflusstask einzusetzen heißt, dass sich das Team bewusst dazu entscheidet ab sofort neben einem "Thinking in Sets" (ja, ich meine damit auch das Buch von Joe Celko) mit der Prämisse "Thinking in Rows" zu leben. Den Datenflusstask einzusetzen heißt auch eine nicht unerhebliche Lernkurve mitzumachen.  Dann hat das Team eine äußerst leistungsfähige Technologie zur Hand, um wirkliche Massendaten bei jedem Lauf des Prozesses zu bewegen. Wenn es aber wie so häufig um wenige 100.000 Sätze pro Tag geht, dann sollte vorher entschieden werden, ob sich der Aufwand beim Einsatz lohnt. Wichtig ist mir hier der Hinweis, dass es da kein Richtig oder Falsch gibt! Es gilt immer die Fallentscheidung.

Sind die politischen Aspekte eines solchen Projektes klar?

Natürlich ist jedes Projekt irgendwie politisch. Wer kennt das Spiel um die Förmchen und Schäufelchen nicht aus eigener Erfahrung. ETL Projekte, also wenn wir von einem echten sprechen (s.o.), sind anders, denn hier nehmen wir allen den Sand aus dem Sandkasten weg, um ihn erst mal richtig gut durchzuwaschen, zu sieben und dann färben wir den Sand auch der Größe der Körner nach ein. Und dann wird auch noch entschieden wer ab sofort mit dem blauen, roten und grünen Sand spielen darf. Vielleicht werden im Zuge des Projektes auch noch die liebgewonnen Eimer und Siebe standardisiert. Mit diesem Bild vor Augen sollte jedem die Situation und Herausforderung klar sein, in die er sich da begibt. Mein Ratschlag: Nehmen wir viele Lollies mit, welche dann vom Business Intelligence Competence Center verteilt werden sollten. Nicht ohne Grund ist die Gründung eines BICC häufig ein Teil eines ETL/DWH Projektes, um den Anwendern das Ganze schmackhaft zu machen.