Vos packages SSIS sont-ils plus nombreux que les gens capables de les comprendre ?

SSIS a été la bonne réponse pendant deux décennies d’entrepôts SQL Server, et un parc mature le montre : des centaines de packages, construits par de nombreuses mains au fil des années, qui s’ouvrent un à la fois dans Visual Studio. Les packages tournent toujours. Ce sont les modifications qui posent problème.

Pourquoi le parc est difficile à faire évoluer

• Un package par table, chacun construit à la main. Le même control flow et le même data flow, reconstruits pour chaque source, dans le style de celui qui avait le ticket cette semaine-là.
• Les packages anciens portent leur propre configuration. Les paramètres de projet et les connection managers partagés existent depuis 2012 ; les packages hérités construits avant, ou sans eux, contiennent encore des chaînes de connexion et des chemins en dur.
• Un changement de schéma est une tournée des packages. Ajouter une colonne à l’entrepôt oblige à ouvrir chaque package qui la touche. L’estimation se compte en semaines parce que la modification se trouve dans des centaines de data flows.
• Une colonne élargie casse un data flow. Les métadonnées d’un data flow sont typées et figées au moment de la conception, donc une colonne source qui grandit ou change de type met le composant en échec jusqu’à ce que quelqu’un la remappe dans Visual Studio.
• Personne ne sait ce qui est en production. Les packages sont planifiés depuis SQL Agent, depuis SSISDB, depuis d’autres packages, et personne ne veut être celui qui a supprimé le mauvais.

Rien de tout cela n’est la faute de SSIS. Un package est une bonne façon de construire un chargement et une mauvaise façon de décrire un entrepôt.

Où la structure devrait se situer

• Dans un modèle, pas dans des packages. Les clés métier, les relations et les attributs déclarés une seule fois, avec les chargements qui en dérivent.
• Générée, pour que chaque chargement ait la même structure. Pas de style propre à chaque développeur, pas de package que seul son auteur sait lire.
• Sur la plateforme que vous exploitez déjà. SQL Server et Azure SQL sont des cibles de premier rang, et Fabric est là quand le moment de bouger arrive.

Ce qui change avec Datavault Builder

Datavault Builder décrit l’entrepôt dans un modèle visuel et en génère les chargements de staging, d’historisation et de livraison, nativement pour SQL Server, Azure SQL et Fabric.

• Le package par table disparaît. Les hubs, les links, les satellites et leurs chargements sont générés à partir du modèle. Il n’y a plus rien à ouvrir dans Visual Studio.
• Une colonne est un changement de mapping. Mappez-la, régénérez, et chaque structure dépendante est mise à jour de façon cohérente. Les colonnes manquantes se chargent à null avec un avertissement ; les colonnes qui grandissent sont élargies.
• Chaque chargement a la même structure. C’est le générateur qui les écrit, donc il n’y a pas de dérive de style et aucun package que seul son auteur comprend.
• Le modèle est l’inventaire. Ce qui est chargé, depuis où, vers quoi, avec le lineage, est visible en un seul endroit. Plus besoin de fouiller dans les jobs SQL Agent.
• Rien n’a besoin de quitter SQL Server. L’entrepôt généré tourne là où tournaient les packages, et passe à Fabric par un simple changement de cible le jour où vous le décidez.

Ce qu’il faut décider

Auditez le parc et comptez les packages qui n’existent que pour charger une table depuis une source vers le staging ou l’entrepôt. Ce nombre donne la taille de la couche qu’un modèle devrait générer. Triée par source, cette même liste indique dans quel ordre retirer les packages.