SSIS s'arrête-t-il là où commence votre entrepôt dans le cloud ?

SSIS a été conçu pour un monde où la source et l’entrepôt étaient tous deux SQL Server, souvent dans le même centre de données. Il excelle dans ce rôle. Les problèmes commencent quand l’entrepôt part vers Fabric, Snowflake, Databricks ou BigQuery, et que les packages doivent suivre.

Pourquoi SSIS s’arrête à la frontière de la plateforme

• Le package suppose SQL Server aux deux extrémités. Les cibles non Microsoft imposent des connecteurs tiers, chacun avec sa licence, sa version et son propre cycle de mises à jour.
• La transformation s’exécute sur la machine SSIS. Les données traversent le réseau jusqu’au serveur SSIS, passent par le buffer du data flow, puis retraversent le réseau jusqu’à l’entrepôt. La mémoire et les cœurs de ce serveur sont le plafond, et chaque chargement subit ce double transfert réseau.
• Le serveur ETL a besoin de sa propre licence. SSIS est livré avec SQL Server, donc la machine qui ne fait qu’exécuter des packages porte quand même une licence SQL Server, pour une charge de travail qui n’est ni la source ni l’entrepôt.
• Le chemin vers le cloud est un simple portage. L’Azure-SSIS Integration Runtime exécute les packages tels quels, sur Azure. Le parc arrive dans le cloud avec tout ce qu’il avait.

Rien de tout cela n’est la faute de SSIS. Il a été construit pour une seule plateforme et il la sert bien.

Où les chargements devraient se situer

• Dans le moteur cible. Fabric, Snowflake, Databricks et BigQuery sont des moteurs ensemblistes. Un chargement delta généré s’exécute à l’intérieur, sur leurs ressources de calcul, sans aucun serveur ETL entre les deux.
• Dans un modèle indifférent à la plateforme. Déclarez l’entrepôt une fois ; générez-le pour la plateforme que vous avez aujourd’hui et pour celle vers laquelle vous irez.
• Sans emmener les packages. Une migration est le moment d’arrêter de maintenir des centaines de chargements construits à la main, pas de les héberger ailleurs.

Ce qui change avec Datavault Builder

Datavault Builder génère l’entrepôt nativement pour SQL Server, Azure SQL, Fabric, Snowflake, Databricks, BigQuery, Oracle et PostgreSQL à partir d’un seul modèle, avec sa propre ingestion depuis des sources on premises et cloud.

• Les chargements s’exécutent dans l’entrepôt. Du SQL delta ensembliste compilé pour le moteur cible. Pas de serveur SSIS, pas de buffer de data flow, pas de licence supplémentaire pour une machine ETL.
• Les sources se connectent directement. En batch, en delta et en CDC depuis des bases, des fichiers, des API REST, des sources NoSQL et Python, avec des flux comme Kafka traités en micro batches. Aucune couche de connecteurs tiers.
• La plateforme est un système cible. Le même modèle génère pour SQL Server aujourd’hui et pour Fabric ou Snowflake demain, chacun dans son dialecte SQL et son schéma de chargement. Le déménagement est une régénération, pas une réécriture, et cela fonctionne aussi dans l’autre sens.
• Les packages sont retirés, pas hébergés. Chaque source mappée dans le modèle est un package qui n’a pas besoin d’une VM dans le cloud.
• Rien n’impose une bascule brutale. Les chargements qui restent entre systèmes on premises peuvent rester dans SSIS jusqu’à ce qu’ils soient mappés.

Ce qu’il faut décider

Listez les packages dont la cible est l’entrepôt qui déménage. Ce sont les chargements que le portage emmènerait tels quels, et les premiers à générer pour la nouvelle plateforme à la place.