Bonnes pratiques Microsoft SSIS

Quelles sont les bonnes pratiques Microsoft SSIS ? Nous allons passer en revue quelques “Bests Practices” à appliquer lorsque l’on utilise Microsoft SSIS dans un projet pour mener à bien ses projets Microsoft BI, notamment en termes de temps de développement et de performances des chargements de données.

Ces méthodes que l’on peut inclure d’une manière plus large aux “Bests practices Microsoft”, sont à appliquer aux projets Microsoft Business Intelligence et ETL. Depuis la version 2008 et jusqu’aux versions 2012, 2014, 2016 et 2017. Même si certains nouveaux modules SQL Server 2012 sont spécifiques et ne sont pas abordés dans cet article.

 

Quelles sont les bonnes pratiques pour le développement de packages SSIS ?

Les bonnes pratiques SSIS à travers 4 axes :

  1. Structurer les packages SSIS
  2. Utiliser le composant Data Flow de manière efficace
  3. Traiter les des cubes SSAS depuis Integration Service
  4. Paramétrer les packages SSIS

 

1. Structurer les packages SSIS

Tout d’abord, le but est de faciliter le développement et les évolutions fonctionnelles et techniques dans un projet Microsoft SSIS.

Pour cela, organiser et regrouper dans plusieurs packages SSIS les développements, de façon logique. Chaque chargement d’une table de faits ou d’une dimension doit correspondre à un seul package SSIS tout comme le pilotage du chargement des dimensions. L’enchaînement des chargements des dimensions et des tables de faits correspond au pilotage global du projet décisionnel, c’est à dire le processus ETL complet.

Par ailleurs, systématiquement nommer tous les composants qui composent votre “Control Flow” ainsi que tous les “DataFlow”, avec des règles de nommages bien spécifiques. Dans le cas où vos installations “SQL Server et Integration Services” sont sur le même serveur, utiliser la destination SQL Server au lieu de la destination OLE DB de façon à ce que vous amélioriez les performances et les temps de chargement.

 

2. Utiliser le composant Data Flow de manière efficace

Toujours commenter votre code et bien définir les variables en ce qui concerne le chemin des fichiers ainsi que les paramètres de connexion. En ce qui concerne les colonnes, nommer les colonnes sources et les colonnes cible de la même façon afin que le “mapping” puisse se faire automatiquement.

Définir les bons types de données pour éviter de faire des conversions de données. Ne jamais sélectionner les colonnes non utilisées au niveau de la source, cela ne sert strictement à rien. Effectuer les conversions de types de données dans SQL.

 

3. Traiter les des cubes SSAS depuis Integration Service

Alimenter les tables de dimension en parallèle est une en les regroupant dans un container de type « séquence », surtout pour des chargements avec des volumes important de lignes. Mettre en place un partitionnement sur les tables de faits, charger les données dans une table temporaire sans aucun indexes, ni contraintes. Ensuite il faut indexer et ajouter les contraintes sur la table temporaire, intégrer la table temporaire dans la table avec partition, qui est la table cible de notre processus ETL.

Eviter au maximum les opérations bloquantes et en particuliers les tris qui sont très gourmands en temps et en ressources. Réaliser au maximum les tris au niveau du SGBD, c’est à dire en utilisant des requêtes SQL et configurer la source de données en activant l’option « source triée » dans les packages SSIS.

 

4. Paramétrer les packages SSIS

Afin d’être indépendant de l’environnement, définir une variable d’environnement pour spécifier le chemin physique du fichier de configuration dtsconfig.

Paramétrer tous les éléments variant d’un environnement à un autre. Comme le nom des serveurs, le nom des bases, le chemin des fichiers, etc. Si possible le nom des utilisateurs.

Enregistrer les paramètres de configuration des packages SSIS en base afin de faciliter le déploiement, la maintenance, l’exploitation et les évolutions futures sur les packages. Définir le lien vers la base de données à l’aide d’un fichier de configuration.

Le chemin permettant l’accès au fichier de configuration peut lui-même être défini à l’aide d’une variable d’environnement. Ainsi il est indépendant de la plateforme et facilite les changements d’environnements.

Soyez le premier à commenter

Laisser un commentaire