Gibt es mehr SSIS-Packages als Entwickler, die sie noch durchschauen?

SSIS war zwei Jahrzehnte lang die richtige Antwort für SQL Server Warehouses, und ein gewachsener Bestand zeigt das: Hunderte Packages, gebaut von vielen Händen über viele Jahre, jedes einzeln in Visual Studio zu öffnen. Die Packages laufen noch. Sie zu ändern ist das Problem.

Warum der Bestand schwer zu ändern ist

• Ein Package pro Tabelle, jedes ein handgebautes Unikat. Derselbe Control Flow und Data Flow, für jede Quelle neu erstellt, im Stil dessen, der in der Woche das Ticket hatte.
• Alt-Packages tragen ihre Konfiguration noch selbst. Projektparameter und geteilte Connection Manager gibt es seit 2012; geerbte Packages, die davor oder ohne sie gebaut wurden, halten weiterhin Connection-Strings und Pfade in sich.
• Eine Schema-Änderung bedeutet, jedes betroffene Package einzeln zu öffnen. Um eine Spalte im Warehouse zu ergänzen, müssen Sie jedes Package öffnen, das sie berührt. Die Schätzung ist in Wochen, weil die Bearbeitung in Hunderten Data-Flows steckt.
• Eine breitere Spalte ist ein gebrochener Data Flow. Data-Flow-Metadaten sind typisiert und zur Entwurfszeit fixiert, eine Quellspalte, die wächst oder den Typ ändert, lässt die Komponente also scheitern, bis jemand sie in Visual Studio neu mappt.
• Es fehlt die Übersicht über den Produktivbestand. Packages werden aus dem SQL-Agent, aus der SSISDB und aus anderen Packages eingeplant, und niemand will derjenige sein, der das falsche gelöscht hat.

Das ist kein Designfehler von SSIS. Ein Package ist ein guter Weg, einen Load zu bauen, und ein schlechter Weg, ein Warehouse zu halten.

Wo die Struktur hingehört

• In ein zentrales Modell statt in einzelne Packages. Business-Keys, Beziehungen und Attribute einmal deklariert, mit den Loads daraus abgeleitet.
• Generiert, damit jeder Load eine Form hat. Kein Stil pro Entwickler, kein Package, das nur sein Autor lesen kann.
• Auf der Plattform, die Sie bereits betreiben. SQL Server und Azure SQL sind erstklassige Ziele, und Fabric ist da, wenn der Umzug kommt.

Was sich mit Datavault Builder ändert

Datavault Builder hält das Warehouse in einem visuellen Modell und generiert daraus die Staging, Historisierungs- und Auslieferungs-Loads, nativ für SQL Server, Azure SQL und Fabric.

• Das Package pro Tabelle verschwindet. Hubs, Links, Satelliten und ihre Loads werden aus dem Modell generiert. Es gibt nichts, was in Visual Studio zu öffnen wäre.
• Eine neue Spalte ist ein Mapping-Update. Mappen, neu generieren, und jede abhängige Struktur wird konsistent aktualisiert. Fehlende Spalten werden als Null mit Warnung geladen; wachsende Spalten werden verbreitert.
• Jeder Load hat dieselbe Form. Der Generator schreibt sie, es gibt also keine Stil-Drift und kein Package, das nur sein Autor versteht.
• Das Modell ist das Inventar. Was geladen wird, woher, wohin, mit Lineage, ist an einem Ort sichtbar. Kein Suchen durch SQL-Agent-Jobs.
• Ihre bestehende Infrastruktur bleibt erhalten. Das generierte Warehouse läuft dort, wo die Packages liefen, und zieht als Zielwechsel nach Fabric um, wenn Sie das entscheiden.

Was zu entscheiden ist

Analysieren Sie Ihren Paketbestand und zählen Sie die Packages, die nur existieren, um eine Tabelle aus einer Quelle ins Staging oder ins Warehouse zu laden. Diese Zahl zeigt, wie groß der Anteil ist, den ein Modell generieren sollte. Nach Quelle sortiert ergibt dieselbe Liste die Reihenfolge, in der Sie die Packages ablösen können.