Contrôle de version dans un grand projet SSL ETL

Question

Nous sommes sur le point de transformer des données d'un système à un autre en utilisant SSIS. Nous sommes quatre personnes qui travailleront continuellement sur ce sujet pendant deux ans et nous avons donc besoin d'un système de gestion des versions. Nous ne pouvons pas utiliser la fondation d'équipe. Nous sommes en train de configurer un serveur SVN, mais en y regardant de plus près, j'ai vu de gros risques.

Il semble qu'une solution est stockée dans un fichier XML énorme. Cela doit être un énorme problème dans un environnement combiné de code/glisser-déposer comme SSIS, car il sera impossible pour SVN de fusionner les changements correctement, et chaque fois que nous obtenons une erreur lors de la validation, nous devrons regarder dans ce gros fichier XML corriger les erreurs manuellement.

Une façon de résoudre ce problème consiste à créer de nombreux projets de solution dans SSIS. Cependant, ce n'est pas vraiment la configuration que nous voulons car nous créons un gros monstre qui aura 2 jours pour s'exécuter et nous voulons suivre sa progression pendant son exécution. Si nous devons créer plusieurs solutions, y a-t-il des moyens de lier leur exécution et d'avoir toujours un aperçu visuel de ce qui se passe et de la qualité de l'exécution?

Est-ce que quelqu'un a eu des problèmes similaires et/ou avez-vous des suggestions pour les résoudre?

Answer 1

La plupart des projets ETL que je travaille utilisent SVN comme référentiel de contrôle de source. La meilleure méthode que j'ai trouvée consiste à décomposer chaque projet ou solution en paquets plus petits, distincts (et souvent exécutables indépendamment). Par exemple, disons que vous aviez un processus appelé ManufacturingImport, cela pourrait être votre projet. Dans ce cas, vous auriez un paquet Master, qui a ensuite appelé d'autres paquets selon les besoins. Cela signifie que les membres de l'équipe peuvent travailler sur des paquets ou des travaux distincts, plutôt que de tenter d'éditer le même paquet et de se retrouver dans des situations difficiles avec la fusion.

Answer 2

De combien de paquets parlez-vous? Si c'est des centaines de paquets, alors quel est le problème spécifique que vous essayez d'éviter? Voici quelques choses que vous pourriez essayer d'éviter en fonction de votre message:

1. solution lente et le temps de chargement au démarrage projet dans BIDS. Je suppose que cela pourrait être irritant de temps en temps. Mais si vous gardez BIDS ouvert toute la journée, cela semble être une fois par jour.

2. Solution lente et temps de chargement du projet lorsque vous obtenez la dernière définition de solution de votre système de contrôle de version. Encore une fois, je suppose que cela pourrait être irritant de temps en temps, mais à quelle fréquence avez-vous besoin de rafraîchir toute la solution? Si vous divisez la solution en projets distincts, vous devez uniquement actualiser un projet. Vous n'auriez besoin d'actualiser la solution complète que si vous souhaitez accéder à un nouveau projet dans la solution.

Qu'entendez-vous par "un fichier XML énorme"? Le fichier de solution est un fichier XML qui conserve la trace des projets. Chaque fichier de projet est un fichier XML qui garde la trace de ses paquets SSIS. Donc, si vous avez 1 000 paquets SSIS répartis uniformément entre 10 projets dans une solution, chaque fichier ne devrait pas contenir plus de 100 objets à suivre. Je peux vous dire par expérience que j'ai eu des projets de Reporting Services avec plus de fichiers RDL que cela et que cela n'a pris que quelques secondes pour charger la solution correctement dans BIDS. Et comme @revelator l'a souligné, les paquets SSIS réels sont leurs propres fichiers XML individuels. Tout système de contrôle de version doit suivre chacun de ces fichiers en tant que fichiers distincts et ne les combine pas en un «fichier XML énorme». Si vous clarifiez ce que vous voulez dire par là, je pense que vous obtiendrez une meilleure aide sur la question. Si vous exécutez un paquet ou 1 000 paquets, vous ne le ferez pas interactivement depuis BIDS. Vous allez probablement déployer les packages sur le serveur, puis demander au serveur d'exécuter les packages.Si c'est le cas, vous devrez probablement appeler les packages avec un travail SQL Server Agent. Si vous enchaînez les paquets en faisant en sorte que chaque paquet appelle un autre paquet ou si vous enchaînez les paquetages en demandant que le paquet appelle chaque paquet en tant qu'étape de travail séparée, vous pouvez toujours suivre où vous êtes dans la chaîne avec la journalisation. Si vous appelez les packages avec des travaux, vous pouvez également effectuer le suivi des étapes du travail. Je cours un entrepôt de données qui a des dizaines de paquets et je compte principalement sur la séparation des processus en tâches qui contiennent chacune un ou plusieurs paquets. J'enchaîne également les tâches avec les commandes de travail de démarrage afin de pouvoir surveiller plus facilement les performances des groupes logiques de charges. De plus, chaque paquet montre son temps d'exécution dans l'historique du travail au niveau de l'étape. De plus, j'ai une connexion personnalisée dans chaque procédure stockée et paquet qui montre combien de secondes et de lignes un chargement de données individuel ou une procédure stockée a pris afin que je puisse résoudre les goulets d'étranglement de performance. Quoi que vous fassiez, ne comptez pas sur l'exécution interactive de paquets pour suivre les performances! Vous n'obtiendrez pas de performances optimales en exécutant ETL sur votre machine, et encore moins en l'exécutant avec une interface graphique. Exécutez des packages dans des travaux sur des serveurs et non sur des postes de travail. L'exécution interactive de paquets est juste leur pour aider à construire et dépanner des paquets individuels, pas pour administrer ETL quotidien.

Si vous générez des packages génériques qui modifient leurs cibles et leurs sources en fonction de paramètres, vous devez probablement créer une table de contrôle dans une base de données pour suivre la progression. Si vous déplacez simplement les données d'un grand système vers un autre en tant qu'événement ponctuel, vous allez probablement diviser la charge en petits ensembles de paquets et avoir des tâches distinctes pour chacun afin de pouvoir gérer plus facilement la récupération après des échecs. Si vous avez l'intention de construire quelque chose qui fonctionne régulièrement pour déplacer des données, alors comment deux jours de fonctionnement continu pour un processus peuvent-ils avoir du sens? Il semble que les données sous-jacentes changent sur vous dans les 2 jours ...

Si vous êtes préoccupé par le système de contrôle de version à utiliser pour la gestion des projets de paquetage SSIS, alors je peux dire que tout le monde le fera. J'ai utilisé Visual SourceSafe et Perforce dans différentes sociétés et les deux ont les mêmes fonctionnalités de base pour l'archivage et l'extraction de paquets individuels. Je suis sûr que n'importe quel système de contrôle de version qui s'intègre avec Visual Studios le fera pour vous.

J'espère que vous trouverez quelque chose d'utile dans ce qui précède et bonne chance avec votre projet.

Answer 3

Le contrôle de version permet d'avoir plusieurs personnes développant ensemble et travaillant sur le même projet. Si je travaille sur quelque chose, un développeur ETL ne pourra pas le vérifier et y apporter des modifications tant que mes modifications ne seront pas terminées et que je ne les aurai pas réintégrées. Cela résout la situation courante où l'artefact et le code du projet d'un développeur changent clober celui d'un autre développeur par accident.

http://blog.sqlauthority.com/2011/08/10/sql-server-who-needs-etl-version-control/