Avantages de l'utilisation des packages SSIS par rapport aux procédures stockées?
Si je peux répondre aux exigences ETL requises à l'aide de procédures stockées, quels sont les avantages d'utiliser des packages SSIS? Mes affaires sur l'ETL n'ont rien de majeur.
J'ai l'impression d'utiliser une vieille technologie. J'aime le SQL. L’ancienne technologie n’est pas toujours obsolète, car les procédures stockées ne disparaîtront pas de si tôt.
Si votre ETL est principalement composé de E et de L, avec très peu de T, et si vous pouvez écrire vos SP pour qu'ils ne s'appuient pas sur des curseurs, opter pour la voie réservée aux SP suffit probablement.
Pour les processus plus complexes, en particulier ceux qui impliquent des transformations lourdes, des dimensions à évolution lente, des recherches dans l'exploration de données, etc., SSIS présente trois avantages.
Premièrement, il gère très efficacement la mémoire, ce qui peut entraîner de grandes améliorations des performances par rapport à T-SQL seul.
Deuxièmement, l'interface graphique vous permet de créer des transformations volumineuses, complexes et fiables beaucoup plus facilement que T-SQL fabriqué à la main.
Et troisièmement, SSIS vous permet d’interagir plus facilement avec des sources externes supplémentaires, ce qui peut être très pratique pour le nettoyage de données, par exemple.
J'ai vécu au pays des procédures stockées ETL pour un entrepôt de données SQL Server de plusieurs téraoctets. Cette décision a été prise en 2001, alors que .NET était à 1.0, VB6 était donc l'alternative du langage de programmation, et SSIS n'était pas encore disponible - c'était DTS. Je peux vous dire qu'il y avait des avantages et des inconvénients, comme n'importe quoi.
Quelques considérations:
- Si tous les membres de votre équipe comprennent le langage SQL, il est facile de creuser dans les processus stockés. SQL est une compétence largement connue qui peut être un avantage si vous avez beaucoup d'écrivains/lecteurs d'ETL. Vous devez être plus qu'un utilisateur occasionnel de SSIS pour comprendre ce qu'il fait. Le flux graphique de haut niveau est agréable pour la documentation, mais si quelqu'un a besoin d'entrer dans les tripes, il serait préférable qu'il connaisse bien SSIS.
- SQL est une douleur à modulariser. Si vous utilisez des fonctions définies par l'utilisateur, vous allez subir une énorme perte de performances. Vous écrivez du code similaire à plusieurs endroits et vous vous détestez pour le faire, mais souvent dans les scénarios ETL, les performances sont primordiales. SSIS vous aidera à modulariser et à factoriser vos tâches.
- Ne vous attendez pas à pouvoir utiliser facilement le contrôle de source avec SSIS. SQL - pas de problème. SSIS utilise des fichiers XML terribles qui peuvent être archivés, mais bonne chance avec les versions précédentes pour voir ce qui a changé et quand.
- Vous devez penser à vos SP de manière modulaire, même s'il est difficile de les rendre aussi modulaires que vous le souhaitez. Utilisez des tables temporaires pour répartir votre traitement. Placez des index sur ces tables temporaires avant de les utiliser. N'essayez pas de faire trop à la fois. Tout commenter.
- Si vous utilisez des curseurs, vous le faites mal. N'ayez pas peur de chaîner une application de console externe que vous avez écrite dans la langue de votre choix pour faire certaines choses pour lesquelles SQL n'était tout simplement pas fait.
BTW - après avoir quitté cette société, ils ont finalement mis à niveau la base de données de SQL 2000 à 2008 et sont passés lentement des processus stockés à SSIS. Dans ma nouvelle société, nous possédons SSIS, mais après l’avoir utilisé, nous avons tous convenu que nos ETL .NET personnalisés sont mieux adaptés à nos besoins. Chacun prend son propre chemin. La décision doit trouver un équilibre entre maintenance et performances, entre les compétences de votre équipe et celles du bassin d'emplois de votre région.
Je suis en train de supprimer nos packages SSIS et d'utiliser des procédures stockées. Pour nous, les procs stockés sont bien meilleurs: 1) Ils sont beaucoup plus faciles à gérer, nous n'avons pas besoin d'enchères, nous n'avons pas besoin de créer de projets ni d'importer de packages dans les offres. changes . 2) Tous nos packages actuels tronquent les données d’une table, puis les repeupler à partir de plusieurs autres tables sur le même serveur avec des mappages directs. Très facile Insérer/sélectionner SQL à écrire . 3) Ils courent beaucoup plus vite. Nous n'avons pas de curseurs, pas de structures en boucle, juste du SQL droit . 4) Nous n'avons pas besoin de passer tout notre temps à cliquer avec le bouton droit de la souris et à travailler dans de petites fenêtres d'enchères pour essayer de suivre le flux de la logique. Nous connaissons tous les TSQL de base et cela suffit pour nos tâches.
Je dirais que cela dépend en partie de ce que vous faites. Toutefois, d’après mon expérience, il reste encore beaucoup à faire pour améliorer les packages SSIS. Nous avons constaté une amélioration de 10 fois de l’environnement de notre entrepôt de données lorsque nous avons pris quelques-unes des procédures stockées très lourdes et les avons placées dans des packages SSIS. L'utilisation de la mémoire de SSIS (dans cette situation de toute façon) faisait toute la différence.
Je tiens à répéter qu'il est important de savoir ce que vous faites. Par exemple, une instruction SQL surperforme généralement un flux de données SSIS lorsque la transformation de données se fait table à table sur le même serveur.
Le mieux est de choisir un SP ou deux, de les créer dans SSIS et de les tester tous les deux.
On dirait que la réponse à toutes les questions SQL commence par, cela dépend ...
Nous utilisons une méthode combinée pour exploiter au mieux deux mondes: Nous utilisons SSIS pour extraire des données de sources externes et les charger en parallèle dans la base de données Staging Nous utilisons ensuite des packages SSIS pour orchestrer des pipelines et déclencher les SP appropriés dans le flux de contrôle. .
Toute logique de transformation est incorporée dans les SP car les flux de données sont difficiles à gérer/modifier et ne procurent aucun avantage significatif: 1) Il est plus facile de modifier et de dépanner SP qu'un package 2) aucun moyen de réutiliser facilement des composants dans SSIS excepté l'appel de packages externes 3) Les différences SVN de SP fonctionnent, les différences de package SSIS sont terribles :)
En outre, nous utilisons SSIS pour exécuter des SP en parallèle afin d'améliorer les performances globales.
L’utilisation de SSIS a permis de réaliser d’énormes gains de performances. C’est particulièrement utile si vous avez des procédures stockées utilisant des serveurs liés, car ils utilisent davantage de puissance de traitement et les serveurs liés ont tendance à mettre en mémoire la totalité de la table avant de limiter les lignes nécessaires à un serveur. joindre. Nous avions une procédure stockée qui prenait plus de 7 heures à s'exécuter. Je l'ai décomposée en données de chaque serveur, puis j'ai configuré une source de données locale pour chaque unité dans SSIS, permettant ainsi au traitement de se dérouler localement pour chaque source de données, via un serveur lié. le travail prend maintenant 6 minutes à courir, je dirais que c'est un gain énorme.
Caralyn
Il manque certaines fonctionnalités de base à SSIS. Il ne dispose pas d'un package de type Informatica permettant le développement à l'aide d'une instruction SQL sur des fichiers texte bruts et le serveur SQL manque cruellement de consignation DML des erreurs comme Oracle. Lorsque Microsoft a annoncé l’ajout de la déclaration Merge, j’ai bien pensé qu’ils implémenteraient bien évidemment le compartiment des erreurs, qui est l’une de ses fonctionnalités les plus importantes. Le traitement des erreurs au niveau de la ligne est important et si vous utilisez une instruction SQL pour ajouter des lots de données si un enregistrement échoue, ce lot entier est annulé.
J'ai essayé certaines fonctionnalités de SSIS et je n'étais pas satisfait de chacune d'entre elles . J'ai précisé le flux de données et je n'étais pas vraiment satisfait de la performance que j'ai vue. Ce que j’ai finalement fini par développer, c’est de développer des packages SSIS dotés d’un flux de contrôle de tâches SQL exécutant chacun une procédure stockée.
Cela garantissait que le serveur SQL utilisait la plupart des serveurs E, T et L. Je pense que lorsque vous utilisez le composant de flux de données, les données sont transférées d'un serveur SQL à une machine exécutant le package, ce qui le rend moins efficace.
Cela dit, je pense que j'aurais essayé d'optimiser le truc Dataflow (ça fait un moment que je travaille dessus) si je devais interagir avec des applications/bases de données/systèmes tiers.
Je ne vois aucune limite technique évidente. La procédure stockée est peut-être plus difficile à suivre qu'un package SSIS pour des opérations ETL complexes, mais cela ne sera pas vrai pour tous les scénarios. J'ai également constaté que les packages (SSIS et DTS) sont plus facilement reconnus comme des "travaux" - les procédures stockées exécutées par des travaux planifiés sont souvent ignorées par les développeurs car ils ne peuvent pas voir les travaux planifiés.
Cela dit, j’ai vu ETL exécuté à la fois par des procédures stockées et des packages DTS/SSIS et, tant que la procédure stockée n’est pas un fouillis de code enchevêtré, elle semble appropriée. Je n'ai pas vu une méthode fonctionner mieux ou de manière plus fiable qu'une autre (mais je n'ai pas vu de procédures stockées effectuant des ETL complexes).
Je travaille avec SQL Server depuis la version 6.5 - ça fait longtemps! Et d’après mon expérience, la plupart des ETL sont assez simples pour que T-SQL fonctionne parfaitement et fonctionne non seulement bien mais aussi très bien - une programmation simple, rapide, fiable et structurée. Je crois que tout ce qui peut être fait dans SSIS peut être fait dans T-SQL par quelqu'un qui sait ce qu'il fait.
D'après mon expérience, la plupart des gros pro-SSIS sont des développeurs inexpérimentés qui ont grandi avec des outils graphiques et ne savent pas vraiment programmer.
Les performances seront plus rapides que la normale sp. Vous n'avez pas besoin de créer une table temporaire complexe, un curseur, une indexation pour récupérer des données.
Le nettoyage des données est un avantage de SSIS.
La gestion incrémentielle n’est possible que dans les SSIS.
Nous pouvons créer un fichier de configuration de package et le déployer sur n’importe quel serveur. L'utilisateur peut fournir les détails du serveur et les informations de connexion.
Interface utilisateur graphique.
La journalisation, la gestion des erreurs est préférable en SSIS.
Pour les petits projets, si vous avez de solides compétences en SQL et une compréhension des besoins de l’entreprise, allez-y!
Sinon, si vous faites face à l'extraction complexe de données, de lourdes tâches de transformation. SSIS ou un autre outil ETL suffira.
à votre santé