ETL: extraire de 200 tables - Flux de données SSIS ou T-SQL personnalisé?

Sur la base de mon analyse, un modèle dimensionnel complet pour notre entrepôt de données nécessitera l'extraction de plus de 200 tables source. Certaines de ces tables seront extraites dans le cadre d'une charge incrémentielle et d'autres seront une charge complète.

A noter, nous avons environ 225 bases de données sources toutes avec le même schéma.

D'après ce que j'ai vu, la création d'un flux de données simple dans SSIS avec une source OLE DB et une destination OLE DB nécessite que les colonnes et les types de données soient déterminés au moment de la conception. Cela signifie que je finirai par me retrouver avec plus de 200 flux de données uniquement pour l'extraction.

Du point de vue de la maintenabilité, cela me semble être un gros problème. Si j'avais besoin d'apporter une sorte de changement radical au code d'extraction, je devrais modifier 200 flux de données différents.

Une option alternative, j'ai écrit un petit script qui lit les bases de données source, les noms de table et les colonnes que je veux extraire d'un ensemble de tables de métadonnées. Le code s'exécute en plusieurs boucles et utilise du SQL dynamique pour extraire des tables source via un serveur lié et OPENQUERY.

D'après mes tests, ce n'est toujours pas aussi rapide que d'utiliser un flux de données SSIS avec une source et une destination OLEDB. Je me demande donc quel genre d'alternatives j'ai. Jusqu'à présent, les réflexions portent sur:

1. Utilisation d' EZAPI pour générer par programme des packages SSIS avec un flux de données simple. Les tables et colonnes à extraire proviendraient des mêmes tables de métadonnées mentionnées précédemment.
2. Acheter un logiciel tiers (composant de flux de données dynamique)

Quelle est la meilleure façon d'aborder cela? En ce qui concerne la programmation .NET, je suis un débutant, donc le temps nécessaire pour accélérer uniquement avec les bases est également une préoccupation.

Je ne voudrais pas avoir 200 flux de données dans un seul package. Le temps qu'il faudrait pour s'ouvrir et valider vous ferait vieillir avant votre temps.

EzAPI est amusant, mais si vous êtes nouveau sur .NET et SSIS, oh non, vous n'en voulez pas. Je pense que vous passerez beaucoup plus de temps à vous familiariser avec le modèle objet SSIS et peut-être à gérer COM que de travailler réellement.

Puisque je suis paresseux, je vais brancher le BIML comme une option gratuite que vous n'avez pas listée. D'après une réponse sur SO /programming/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604

• Biml est une bête intéressante. Varigence se fera un plaisir de vous vendre une licence à Mist mais elle n'est pas nécessaire. Tout ce dont vous avez besoin est BIDSHelper , puis parcourez BimlScript et recherchez une recette qui correspond à vos besoins. Une fois que vous avez cela, cliquez sur le bouton de menu contextuel dans BIDSHelper et whoosh, il génère des packages.

Je pense que cela pourrait aussi être une approche pour vous. Vous définissez votre BIML qui décrit le comportement de vos packages, puis vous les générez. Dans le scénario, vous décrivez où vous apportez une modification et devez corriger N packages, non, vous corrigez votre définition du problème et régénérez les packages.

Ou si vous vous êtes suffisamment familiarisé avec le framework, utilisez quelque chose comme EzAPI pour réparer tous les problèmes. Heck, puisque vous avez marqué cela comme 2005, vous pouvez également essayer PacMan si vous avez besoin d'apporter des modifications en masse aux packages existants.

Considérations de conception SSIS

D'une manière générale, j'essaie de faire en sorte que mes packages se concentrent sur la résolution d'une seule tâche (charger les données de vente). Si cela nécessite 2 flux de données, tant pis. Ce que je déteste hériter est un package de l'assistant d'importation et d'exportation avec de nombreux flux de données non liés dans un seul package. Les décomposer en quelque chose qui résout un problème très spécifique. Cela rend les améliorations futures moins risquées car la surface est réduite. Un avantage supplémentaire est que je peux travailler sur le chargement DimProductspendant que mon serviteur s'occupe du chargement du SnowflakeFromHellpaquet.

Utilisez ensuite des packages principaux pour orchestrer les flux de travail enfants. Je sais que vous êtes en 2005, mais la version de SQL Server 2012 de SSIS est le pyjama du chat. J'adore le modèle de déploiement de projet et l'intégration étroite qu'il permet entre les packages.

TSQL vs SSIS (mon histoire)

Quant à l'approche TSQL pure, dans un travail précédent, ils ont utilisé un travail en 73 étapes pour répliquer toutes leurs données Informix dans SQL Server. Cela prenait généralement environ 9 heures, mais pouvait s'étendre à environ 12 heures. Après avoir acheté un nouveau SAN, il est tombé à environ 7 heures et plus. Même processus logique, réécrit dans SSIS était un sous 2 heures cohérent. Le parallélisme "gratuit" que nous avons obtenu avec SSIS a été le plus grand facteur de ralentissement. Le travail de l'agent a exécuté toutes ces tâches en série. Le package maître a essentiellement divisé les tables en unités de traitement (5 ensembles parallèles de tâches sérialisées de "exécuter la table de réplication 1", la table 2, etc.) où j'ai essayé de diviser les compartiments en unités de travail de taille quasi égale. Cela a permis à la soixantaine de tables de référence de recherche d'être remplies rapidement, puis le traitement a ralenti à mesure qu'il entrait dans le "

Un autre avantage pour moi en utilisant SSIS est que j'obtiens une configuration, une journalisation et un accès «gratuits» aux bibliothèques .NET pour les données carrées que je dois creuser dans un trou rond. Je pense qu'il peut être plus facile de maintenir (faire passer la maintenance) un paquet SSIS qu'une approche TSQL pure en raison de la nature graphique de la bête.

Comme toujours, votre kilométrage peut varier.

Vous avez mentionné que vous disposez de 200 tables source et 225 bases de données. Je suppose que les 200 tables source sont un décompte de toutes les tables des 225 bases de données (car si vous aviez 200 tables dans chaque base de données, votre nombre total de tables sera de 45 000). Vous avez également mentionné que le schéma de la base de données est le même pour les 225 bases de données.

Vous pouvez d'abord créer les packages SSIS pour la seule base de données 1, puis lorsque vous planifiez vos travaux, vous pouvez simplement modifier la chaîne de connexion à la base de données à l'aide de la configuration du package (si votre SQL 2005, vous utiliserez le modèle de déploiement de package). Comme mentionné dans les réponses précédentes, SQL 2012 propose de nouvelles façons de configurer vos paramètres à l'aide du modèle de déploiement de projet.

Vous pouvez obtenir plus d'informations sur la configuration des packages avec SSIS ici http://www.sql-server-performance.com/2007/package-configuration-2005/

Vous pouvez obtenir plus d'informations sur l'utilisation des paramètres de projet à partir d'ici, /programming/15206184/how-to-configure-ssis-2012-project-to-run-under-different-environment-configurat