Stößt SSIS dort an seine Grenzen, wo Ihr Cloud-Warehouse beginnt?

SSIS wurde gebaut, um Daten zwischen On-Premises SQL Server Instanzen zu bewegen. Wenn das Warehouse nach Fabric, Snowflake, Databricks oder BigQuery umzieht, sind die Optionen, die Packages auf eine Azure-SSIS Integration Runtime zu heben, Drittanbieter-Connectoren zu kaufen oder neu zu schreiben. Ein Modell, das nativ für die neue Plattform generiert, ist die vierte Option, und die einzige, die Ihre Altlasten nicht mitschleppt.

Stößt SSIS dort an seine Grenzen, wo Ihr Cloud-Warehouse beginnt?

Die Data-Warehouse-Automationsplattform, der Datenteams aus vielen Branchen vertrauen

Petr Beles Petr Beles Co-Founder · Veröffentlicht in Lösungen für ETL-Tool-Herausforderungen LinkedIn

Kommt Ihnen das bekannt vor?

  • Das Warehouse zieht nach Fabric oder Snowflake um, und der Plan für die Packages ist eine VM in der Cloud, die sie wie bisher ausführt.
  • Eine Nicht-Microsoft Quelle oder ein solches Ziel zu laden heißt ein Drittanbieter-Connector mit eigener Lizenz und eigenem Upgrade Zyklus.
  • Große Loads laufen durch den SSIS Data-Flow-Buffer auf einem Server, und der Server ist die Grenze.
  • Die ETL-Engine braucht eine eigene SQL-Server-Lizenz, für eine Arbeitslast, die weder die Quelle noch das Warehouse ist.

SSIS wurde für eine Welt entwickelt, in der Quelle und Warehouse beide SQL Server waren, oft im selben Rechenzentrum. Darin ist es sehr gut. Die Probleme beginnen, wenn das Warehouse nach Fabric, Snowflake, Databricks oder BigQuery umzieht und die Packages folgen müssen.

Warum SSIS an der Plattformgrenze scheitert

  • Das Package setzt SQL Server an beiden Enden voraus. Nicht-Microsoft-Ziele bedeuten Drittanbieter-Connectoren, jeder mit eigener Lizenz, eigener Version und eigenem Upgrade Zyklus.
  • Die Transformation läuft auf der SSIS Maschine. Daten überqueren das Netzwerk zum SSIS Server, fließen dort durch den Data-Flow-Buffer und überqueren das Netzwerk erneut zum Warehouse. Speicher und Kerne des Servers sind die Obergrenze, und jeder Load bezahlt die zwei Hops.
  • Der ETL Server braucht seine eigene Lizenz. SSIS wird mit SQL Server ausgeliefert, die Maschine, die nur Packages ausführt, trägt also weiterhin eine SQL-Server-Lizenz für eine Arbeitslast, die weder Quelle noch Warehouse ist.
  • Ein reiner Lift-and-Shift-Ansatz ist eine Sackgasse. Die Azure-SSIS Integration Runtime führt die Packages so aus, wie sie sind, auf Azure. Der Bestand kommt in der Cloud mit allem an, was er hatte.

Das ist kein Designfehler von SSIS. Es wurde für eine Plattform gebaut und dient dieser Plattform gut.

Wo die Loads hingehören

  • In die Zielengine. Fabric, Snowflake, Databricks und BigQuery sind mengenbasierte Engines. Ein generierter Delta-Load läuft in ihnen, auf ihrem Compute, ohne ETL Server dazwischen.
  • In ein plattformunabhängiges Modell. Das Data Warehouse einmal zentral definieren und es für die Plattform generieren, die Sie jetzt haben, und für die, auf die Sie umziehen.
  • Ohne die Packages mitzunehmen. Eine Migration ist der Moment, aufzuhören, Hunderte von Hand gebaute Loads zu pflegen, nicht, sie woanders zu hosten.

Was sich mit Datavault Builder ändert

Datavault Builder generiert das Warehouse nativ für SQL Server, Azure SQL, Fabric, Snowflake, Databricks, BigQuery, Oracle und PostgreSQL aus einem Modell, mit eigener Ingestion aus On-Premises und Cloud-Quellen.

  • Die Loads laufen im Warehouse. Mengenbasiertes Delta-SQL, kompiliert für die Zielengine. Kein SSIS-Server, kein Data-Flow-Buffer, keine zusätzliche Lizenz für eine ETL-Engine.
  • Quellen verbinden sich direkt. Batch, Delta und CDC aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka als Micro-Batches. Keine Drittanbieter Connector Schicht.
  • Die Plattform ist nur ein austauschbares Zielsystem. Dasselbe Modell generiert heute für SQL Server und morgen für Fabric oder Snowflake, jeweils im eigenen SQL-Dialekt und Lademuster. Der Umzug ist eine Neugenerierung, kein Neuschreiben, und er funktioniert auch in die andere Richtung.
  • Die Packages werden stillgelegt, nicht gehostet. Jede im Modell gemappte Quelle ist ein Package, das keine VM in der Cloud braucht.
  • Kein Risiko durch einen Big-Bang-Umstieg. Loads, die zwischen On-Premises Systemen bleiben, können in SSIS bleiben, bis sie gemappt sind.

Was zu entscheiden ist

Listen Sie die Packages auf, deren Ziel das Warehouse ist, das umzieht. Das sind die Loads, die der Lift unverändert mitnehmen würde, und die ersten, die stattdessen für die neue Plattform generiert werden sollten.

Erleben Sie es live mit Ihren eigenen Datenquellen

Buchen Sie eine kostenlose Demo und bringen Sie den Connector mit, der Sie am meisten kostet, an Geld oder an Zeit.

Kostenlose Demo buchen

In drei Schritten zu einer Pipeline, die Sie kontrollieren

  1. Die Packages nach Ziel auflisten

    Welche Loads landen in dem Warehouse, das umzieht. Das sind die, die der Lift unverändert mitnehmen würde.

  2. Sie für die neue Plattform modellieren

    Business-Keys, Beziehungen und Attribute kommen ins Datavault Builder Modell. Die Loads werden für Fabric, Snowflake, Databricks oder BigQuery generiert.

  3. SSIS für das behalten, was on premises bleibt

    Loads zwischen On-Premises SQL Server Systemen können in SSIS bleiben, bis auch sie gemappt sind. Kein Risiko durch einen Big-Bang-Umstieg.

Wie Datavault Builder die Reibungsverluste in der Ingestion beseitigt

  • Ingestion ist eingebaut

    Batch-, Delta- und CDC-Ladevorgänge aus Datenbanken, Dateien, REST-APIs, NoSQL und Python-Quellen, mit Streams wie Kafka, die als Micro-Batches ankommen. Dieselbe Plattform, die das Warehouse generiert, keine zweite Rechnung.

  • Ihr Schema, nicht das des Anbieters

    Quelltabellen werden auf ein Data-Vault-2.0-Modell gemappt, das Sie entworfen haben. Eine neue Spalte oder eine umbenannte Tabelle ändert ein Mapping, keine Kette von Skripten nach dem Load.

  • Nur Deltas bewegen sich

    Hubs, Links und Satelliten laden, was sich geändert hat. Vollständige Ladevorgänge bleiben im Staging, statt jede Nacht weiter unten neu verarbeitet zu werden.

  • Historie wird von Haus aus behalten

    Jede Änderung wird so festgehalten, wie sie eintrifft. Historien- und Stichtagsabfragen funktionieren also auch dort, wo die Quelle ihre eigenen Zeilen überschreibt.

  • Code, den Sie nie von Hand schreiben

    Laden, Historisierung und Lineage werden in Echtzeit aus dem Modell generiert und laufen nativ auf Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle oder PostgreSQL.

  • Eine Plattform, bis zu neun Tools weniger

    Modellierung, ETL, CI/CD, Dokumentation und Lineage an einem Ort. Das ist es, was 14,7 Minuten von der Anforderung bis zur Produktion möglich macht.

Ausgezeichnet von BARC im Data Fabric Survey 26

Sprechen Sie mit unserem Experten

Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrem Stack passt.

Matt Collett

Matt Collett

Sales Director

Was suchen Sie?

Mit dem Absenden stimmen Sie unserer Datenschutzerklärung.

Weitere Probleme in dieser Serie

  • Lift and Shift

    SSIS-Schwachstellen: Warum das Verlagern der Packages in die Cloud nur die Altlasten mitnimmt

    SSIS-Altlasten haben drei Probleme, die eine Cloud-VM nicht löst: ein Package pro Tabelle, das niemand öffnen will, Releases, die DevOps nicht erreicht, und ein Design, das bei SQL Server aufhört. Die Azure-SSIS Integration Runtime trägt alle drei unverändert in die Cloud. Ein Modell, das das Warehouse generiert, macht sie stattdessen überflüssig.

  • Deployment und CI/CD

    Ist SSIS der letzte Teil Ihres Stacks, der sich CI/CD verwehrt?

    Eine .dtsx Datei ist XML, das sich schlecht vergleichen und noch schlechter mergen lässt, arbeiten zwei Engineers an einem Package, endet das im Neuaufbau. Umgebungen leben in von Hand gepflegten SSISDB-Variablen-Mappings. Moderne DevOps-Praxis stößt beim SSIS-Projekt an ihre Grenzen. Releases sollten aus einem Modell generiert werden, pro Umgebung, mit dem Rollback inklusive.

  • Package-Altlasten

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

    Hunderte .dtsx-Packages, eines pro Tabelle, jedes in Visual Studio gebaut von dem, der gerade das Ticket hatte, mit Control-Flows und Data-Flows, die sich nur einzeln öffnen lassen. Um eine Spalte zu ergänzen, müssen Sie die Packages eines nach dem anderen öffnen. Die Lösung ist kein Package-Template, sondern ein Modell, das die Loads generiert, nativ auf SQL Server, Azure SQL oder Fabric.

Fragen und Antworten