Comment aborder une mission ETL ?

Quelques conseils ETL généraux

1. Envisagez de l'organiser par destination (par exemple, tout le code pour produire la dimension Client réside dans le même module, quelle que soit la source). C'est ce qu'on appelle parfois l'ETL orienté sujet. Cela rend la recherche de choses beaucoup plus facile et augmentera la maintenabilité de votre code.

2. Si la base de données SQL2000 est en désordre, vous constaterez probablement que les flux de données SSIS sont une manière maladroite de traiter les données. En règle générale, les outils ETL s'adaptent mal à la complexité ; près de la moitié de tous les projets d'entrepôt de données dans les sociétés financières sont réalisés avec du code de procédure stockée en tant que décision architecturale explicite - précisément pour cette raison. Si vous devez mettre une grande quantité d'insprocs de code, pensez à mettre tous du code dans les sprocs.
   
   Pour un système impliquant de nombreux nettoyages ou transformations complexes, une approche 100 % sproc est beaucoup plus facile à gérer car c'est le seul moyen possible de regrouper toutes les transformations et la logique métier au même endroit. Avec les systèmes mixtes ETL/sproc, vous devez chercher à plusieurs endroits pour suivre, dépanner, déboguer ou modifier l'ensemble de la transformation.

3. Le point idéal des outils ETL se trouve sur les systèmes où vous disposez d'un plus grand nombre de sources de données avec des transformations relativement simples.

4. Rendez le code testable, afin de pouvoir séparer les composants et tester de manière isolée. Le code qui ne peut être exécuté qu'au milieu d'un flux de données complexe dans un outil ETL est beaucoup plus difficile à tester.

5. Rendez l'extraction de données muette sans logique métier et copiez-la dans une zone de mise en scène. Si vous avez une logique métier répartie sur les couches d'extraction et de transformation, vous aurez des transformations qui ne peuvent pas être testées de manière isolée et il sera difficile de détecter les bogues. Si la transformation s'exécute à partir d'une zone intermédiaire, vous réduisez la dépendance matérielle vis-à-vis du système source, ce qui améliore à nouveau la testabilité. C'est une victoire particulière sur les architectures basées sur sproc car cela permet une base de code presque complètement homogène.

6. Construisez un gestionnaire de dimension générique à évolution lente ou utilisez-en un standard si disponible. Cela facilite le test unitaire de cette fonctionnalité. Si cela peut être testé à l'unité, le test du système n'a pas à tester tous les cas extrêmes, simplement si les données qui lui sont présentées sont correctes. Ce n'est pas aussi complexe qu'il y paraît - Le dernier que j'ai écrit était d'environ 600 ou 700 lignes de code T-SQL. Il en va de même pour toutes les fonctions de nettoyage génériques.

7. Charger progressivement si possible.

8. Instrumentez votre code - faites-le créer des entrées de journal, enregistrant éventuellement des diagnostics tels que des totaux ou des comptages de vérification. 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 cela (le nombre de lignes dans une ligne égale compte-t-il dans b, la relation A:B est-elle vraiment 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 s'aligner - pas de valeurs nulles. Pour les erreurs, "non enregistré", créez des entrées spécifiques "erreur" ou "non enregistré" dans la table de dimension et faites-les correspondre.

10. Si vous construisez un magasin de données opérationnelles (objet de nombreuses guerres de religion), ne recyclez pas les clés ODS dans les schémas en étoile. Bien sûr, joignez-vous aux clés ODS pour construire des dimensions, mais faites correspondre sur une clé naturelle. Cela vous permet de supprimer et de recréer arbitrairement l'ODS - éventuellement en modifiant sa structure - sans perturber les schémas en étoile. Avoir cette capacité est un véritable gain de maintenance, car vous pouvez modifier la structure ODS ou effectuer un redéploiement brutal de l'ODS à tout moment.

Les points 1-2 et 4-5 signifient que vous pouvez construire un système où tous du code d'un sous-système donné (par exemple, une seule dimension ou table de faits) vit à un et un seul endroit du système. Ce type d'architecture est également préférable pour un grand nombre de sources de données.

Le point 3 est un contrepoint au point 2. Fondamentalement, le choix entre les outils SQL et ETL est fonction de la complexité de la transformation et du nombre de systèmes source. Plus les données sont simples et le nombre de sources de données est grand, plus les arguments en faveur d'une approche basée sur les outils sont solides. Plus les données sont complexes, plus il est important de passer à une architecture basée sur des procédures stockées. Généralement il vaut mieux utiliser exclusivement ou presque exclusivement l'un ou l'autre mais pas les deux.

Le point 6 rend votre système plus facile à tester. Le test des SCD ou de toute fonctionnalité basée sur les modifications est fastidieux, car vous devez être en mesure de présenter plusieurs versions des données source au système. Si vous déplacez la fonctionnalité de gestion des modifications dans le code d'infrastructure, vous pouvez la tester de manière isolée avec des ensembles de données de test. C'est une victoire dans les tests, car cela réduit la complexité des exigences de test de votre système.

Le point 7 est un conseil général sur les performances que vous devrez observer pour les gros volumes de données. Notez que vous n'aurez peut-être besoin d'un chargement incrémentiel que pour certaines parties d'un système ; pour les tables de référence et les dimensions plus petites, vous n'en aurez peut-être pas besoin.

Le point 8 est pertinent pour tout processus sans tête. Si ça monte pendant la nuit, vous voulez avoir une chance de voir ce qui ne va pas le lendemain. Si le code n'enregistre pas correctement ce qui se passe et détecte les erreurs, vous aurez beaucoup plus de mal à le dépanner.

Le point 9 donne à l'entrepôt de données une vie propre. Vous pouvez facilement ajouter et supprimer des systèmes source lorsque l'entrepôt possède ses propres clés. Les clés d'entrepôt sont également nécessaires pour mettre en œuvre des dimensions qui changent lentement.

Le point 10 est une victoire en matière de maintenance et de déploiement, car l'ODS peut être restructuré si vous devez ajouter de nouveaux systèmes ou modifier la cardinalité d'un enregistrement. Cela signifie également qu'une dimension peut être chargée à partir de plusieurs endroits dans l'ODS (pensez :ajouter des ajustements comptables manuels) sans dépendre des clés ODS.