Comment aborder une mission ETL?

Question

Je suis supposé effectuer une ETL où source est une base de données SQL 2k volumineuse et mal conçue et une base de données SQL 2k5 mieux conçue. Je pense que SSIS est la voie à suivre. Quelqu'un peut-il suggérer une liste de choses à faire ou une liste de contrôle ou des éléments à surveiller pour que je n'oublie rien? Comment devrais-je aborder cela pour qu'il ne me morde pas plus tard à l'arrière.

Answer 1

Eh bien, je développe un ETL pour la société dans laquelle je suis.

Nous travaillons avec SSIS. Utiliser l’API pour générer et construire nos propres packages Dtsx.

SSIS n'est pas convivial pour la gestion des erreurs. Parfois, vous obtenez un " Erreur OleDb " qui pourrait avoir beaucoup de significations différentes dépendant du contexte.

Lisez la documentation de l'API (ils ne disent pas grand chose).

Quelques liens pour vous aider à partir de là: http://technet.microsoft.com/de-de /library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library /ms345167.aspx

http://msdn.microsoft.com/en-us/library /ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr = 26 & amp; select = 2551674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki /ComponentErrorCodes.html

http: // www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library /ms187670.aspx

http: // msdn .microsoft.com / ja-jp / bibliothèque / microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http: // www .sqlis.com / post / Gestion des types de lignes différentes dans le même fichier.aspx

http://technet.microsoft.com/ en-us / library / ms135967 (SQL.90) .aspx

http://msdn.microsoft.com/ en-us / library / ms137709 (SQL.90) .aspx

http://msdn.microsoft.com/ en-us / library / ms345164 (SQL.90) .aspx

http://msdn.microsoft.com/en-us/library /ms141232.aspx

http://www.microsoft.com/technet/prodtechnol /sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http:

Answer 2

Quelques conseils généraux sur l'ETL

1. Envisagez de l'organiser en destination (par exemple, tous les code pour produire le client dimension vit dans le même module, quelle que soit la source). Ceci est parfois appelé ETL orienté sujet. Cela fait trouver des choses beaucoup plus facile et augmenter la maintenabilité de votre code.

2. Si la base de données SQL2000 est un désordre, vous trouverez probablement que SSIS les flux de données sont une façon maladroite de traiter avec les données. En règle générale, les outils ETL échelle mal avec la complexité; quelque chose comme la moitié de toutes les données projets d'entrepôt en finance les entreprises ont fini avec stocké code de procédure en tant qu'explicite décision architecturale - précisément pour cette raison. Si tu as mettre une grande quantité de code dans sprocs, envisagez de mettre tous les code dans les sprocs.
   
   Pour un système impliquant de nombreuses transformations ou transformations complexes, une approche 100% sproc est beaucoup plus facile à gérer car il s'agit du seul moyen possible de regrouper toutes les transformations et la logique métier. Avec les systèmes mixtes ETL / sproc, vous devez rechercher à plusieurs endroits pour suivre, dépanner, déboguer ou modifier la totalité de la transformation.

3. Le point fort des outils ETL réside dans les systèmes sur lesquels vous avez un plus grand nombre de sources de données avec des transformations relativement simples.

4. Faites en sorte que le code soit testable afin que vous puissiez séparer les composants et tester en isolation. Le code qui peut uniquement être exécuté à partir du milieu d’un flux de données complexe dans un outil ETL est beaucoup plus difficile à tester.

5. Rendre l'extrait de données muet sans logique métier, et copier dans un zone de transit. Si vous avez des affaires la logique répartie sur l'extrait et transformer des calques, vous aurez transformations qui ne peuvent pas être testées en vase clos et le rend difficile à traquer les bugs. Si la transformation est en cours d'exécution à partir d'une zone de transit vous réduire la forte dépendance sur le système source, encore amélioré testabilité. C’est une victoire particulière pour les architectures à base de sproc car elle permet une base de code presque totalement homogène.

6. Construisez un générique évoluant lentement gestionnaire de dimension ou utiliser l'un de la étagère si disponible. Cela le rend plus facile de tester ce fonctionnalité. Si cela peut être l'unité testé, les tests du système ne avoir à tester tous les cas d'angle, simplement si les données présentées à c'est correct. Ce n’est pas aussi complexe que cela en a l'air. Le dernier que j’ai écrit portait sur 600 ou 700 lignes de code T-SQL. Il en va de même pour toutes les fonctions de nettoyage génériques.

7. Chargez progressivement si possible.

8. Instrumentez votre code - faites-le entrer dans le journal, en enregistrant éventuellement des diagnostics tels que les totaux de contrôle ou les comptes. Sans cela, le dépannage est presque impossible. En outre, la vérification des assertions est un bon moyen de penser à la gestion des erreurs pour cette opération (le nombre de lignes dans un nombre égal de lignes dans b, est-il une relation A: B réellement 1: 1).

9. Utilisez des clés synthétiques. L'utilisation de clés naturelles à partir des systèmes source lie votre système aux sources de données et rend difficile l'ajout de sources supplémentaires. Les clés et les relations dans le système doivent toujours être alignées - pas de valeurs NULL. Pour les erreurs, "non enregistré", effectuez une entrée spécifique "erreur" ou "non enregistrée" dans la table de dimension et faites-la correspondre.

10. Si vous construisez un magasin de données opérationnelles (sujet de nombreuses guerres de religion), ne recyclez pas les clés ODS dans les schémas en étoile. Associez-vous sur des clés ODS pour construire des dimensions, mais sur une clé naturelle. Cela vous permet de supprimer et de recréer de manière arbitraire l'ODS - en modifiant éventuellement sa structure - sans perturber les schémas en étoile. Avoir cette capacité est un réel avantage en termes de maintenance, car vous pouvez modifier la structure de l'ODS ou redéployer brutalement l'ODS à tout moment.

Les points 1-2 et 4-5 signifient que vous pouvez créer un système où tout du code pour un sous-système donné (par exemple, une seule variable).

Answer 3

J'ai de l'expérience dans les processus ETL, qui consiste à extraire quotidiennement, hebdomadairement, mensuellement et annuellement des données de plus de 200 bases de données distribuées vers une base de données centrale. Il s'agit d'une quantité énorme de données et nous avons eu de nombreux problèmes spécifiques à notre situation. Mais à mon avis, il y a plusieurs points à considérer indépendamment de la situation:

• Assurez-vous de prendre en compte les verrous de fichiers, tant du côté source que du côté destination. Il est important de s’assurer que les fichiers ne sont pas verrouillés dans les autres processus (il est donc important de supprimer ces verrous si nécessaire).

• verrouiller les fichiers pour vous-même. Assurez-vous, en particulier sur la source, que vous verrouillez les fichiers tout en extrayant les données de manière à ne pas obtenir des données à moitié mises à jour.

• si possible, extrayez les deltas, pas toutes les données. Obtenez une copie des données et n'extrayez que les lignes qui ont changé au lieu de tout. Plus votre ensemble de données est grand, plus cela devient important. Examinez les revues et les déclencheurs si nécessaire, mais comme il devient de plus en plus important de disposer de ces données, il s’agit probablement du premier conseil que je vous donnerais. Même si cela prend beaucoup de temps au projet.

• journal d'exécution. Assurez-vous de savoir quand cela a fonctionné et quand cela n'a pas fonctionné. Le fait de lancer des erreurs spécifiques dans le processus peut vraiment aider au débogage.

• document, document, document. Si vous construisez ce droit, vous allez le construire et ensuite ne pas y penser pendant longtemps. Mais vous pouvez être assuré que vous ou une autre personne devrez y revenir à un moment ou à un autre pour l’améliorer ou corriger un bogue. La documentation est essentielle dans ces situations.

HTH, je vais le mettre à jour si je pense à autre chose.

Answer 4

Nous procédons à un énorme ETL (transfert d'un client d'applications héritées AS400 vers Oracle EBS), et nous avons en fait un processus que je peux recommander (avec des modifications):

1. Identifiez la cible critique tables / champs.
2. Identifiez le critique tables / champs source.
3. Travailler avec le les utilisateurs professionnels de mapper la source sur cible.
4. Analyser les données source pour problèmes de qualité.
5. Déterminez qui est responsable des problèmes de qualité des données identifié.
6. avoir des parties responsables nettoyer les données dans la source.
7. Développez l'ETL réel en fonction des informations des étapes 1 à 3.

Les étapes les plus délicates sont 2 & amp; 3 selon mon expérience - il est parfois difficile d’obtenir des utilisateurs professionnels qu’ils identifient correctement tous les bits dont ils ont besoin en un seul passage, et il peut être encore plus difficile d’identifier correctement la provenance exacte des données (bien que cela puisse avoir un rapport avec la cryptographie). noms de fichiers et de champs que je vois!). Toutefois, ce processus devrait vous aider à éviter les erreurs majeures.

Answer 5

Ce fil est ancien, mais je voudrais attirer votre attention sur la réponse de ConcernedOfTunbridgeWells. C'est un très bon conseil, sur tous les points. Je pourrais en répéter quelques-unes, mais cela diminuerait le reste et elles méritent toutes une étude attentive.