[SSIS] Structure des lots en BI

L’utilisation de SSIS pour la BI est une discipline assez mal standardisée. On admettra que chacun a émis ses propres recommandations, et qu’à l’intérieur même de la galaxie Microsoft les avis divergent sur la marche à suivre. Cette série a pour but de donner quelques conseils issus de mon expérience. Cette fois ci nous parlons donc de la structure générale du ou des lots.

L’alimentation d’un data warehouse obéit a une logique propre et commune à tous les ETL du marché – nul besoin d’aller chercher Ralph Kimball à ce stade:

  1. Il faut d’abord et avant tout charger les dimensions: de part leurs contraintes d’intégrité elles doivent être existantes au chargement des lots.
  2. Puis vient le chargement des tables de faits, obéissant lui même à un ordre interne lié aux contraintes pouvant exister.

Ces quelques bases rappellées, on en arrive à la base de la discussion: comment structurer son lot. Les MOC – Microsoft Official Courses, cours Microsoft que j’anime en tant que MCT – ont tendance à privilégier une structure que j’appelle « monopackage » qui tire partie de la structuration algorithmique par blocs et contraintes de précédence du ControlFlow pour effectuer les traitements.

Autant le dire tout de suite, hormis pour des petits projets, je ne suis pas un grand fanatique de ce mode de développement. Je lui préfère lun découpage en plusieurs lot, et une utilisation modérée des capacités logiques du moteur de Control Flow. Je ne pense pas que – dans le cadre du chargement d’une étoile – il y ait lieu d’utiliser ces potentialités, et ce pour trois raisons:

  1. La première est la évolutivité du lot: un DW est conçu en permanence selon les besoins du client fonctionnel, en fonction du reporting nécessaire. L’imaginer statique durant le projet est une gageure: il va évoluer, se floconner et poser de nouvelles contraintes qui affecteront par exemple l’ordre de chargement des dimensions et faits. Il y a alors nécessité de réordonner les tâches au niveau ControlFlow, ce qui peut dans des cas d’utilisation avancée types contraintes expressives ou boucles dynamiques, peut être rendu relativement complexe.
  2. La seconde est la modularité du lot: un lot unique est difficilement partageable dans le cadre d’une équipe. Augmenter le nombre d’éléments permet de profiter entièrement de suites telles SourceSafe ou Team Foundation Server pour du développement collaboratif. Cela permet aussi la réutilisabilité du code produit par découpage en unité atomiques. On retrouve ici un des principes qui m’est cher qui est l’analogie entre le développement ETL et applicatif.
  3. La troisième est plus conceptuelle, c’est la indépendance des DataFlows qui, comme un morceau de code procédural, se réalise en réduisant au minimum les dépendances avec les autres éléments de l’ensemble. On aura tendance, dans une configuration mono-package, à mettre en place des liens entre Data Flows qui n’ont pas de nécessité théorique et témoignent d’un design ETL bancal.

En conséquence je conseille un mode de développement ou chaque table de faits et dimension dispose de son propre package. Un package global, que j’appelle « orchestrateur », ordonnance le tout et permet de s’adapter aux évolutions des contraintes via des ExecutePackageTasks


En ce qui concerne les relations entre packages, elles sont assurés:

  • Les données sont passées par des variables, en utilisant la fonctionnalité de configurations de type ParentPackageVariable

  • Le mode transationnel DTC est quant à lui nativement passé de package en package

De plus, en utilisant les fonctionnalités de Package Templates – sans oublier de regénérer les GUID😉 – on permet une uniformisation des ConnectionManager utilisés, et donc des configurations SQL ou XML.

En résumé: l’orchestration de tâches atomiques dans le chargement de Data Warehouse permet de développer de manière collaborative et induit une modularité du lot global, sans pour autant sacrifier aux fonctionnalités

Un petit webcast sympa pour résumer tout ça: MSDN Architecture Webcast: Using SQL Server 2005 Integration Services to Populate a Kimball Method Data Warehouse.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s