ETL : gardez les spaghettis pour le dîner

L'une des première décisions technologiques à prendre dans les projets de mise en place de data warehouse est le choix de la méthode qui sera utilisée pour effectuer les tâches d'extraction, de transformation et de chargement des données (ETL).

Devant une telle décision, on est évidemment confronté à la classique question du Build vs Buy (Acheter un outils du marché ou fabriquer en interne) et même si on est tenté d'y répondre par : "ça dépend!", cette réponse est dangereuse car elle sert d'excuse pour fabriquer son propre ETL.

Selon un sondage privé réalisé par Forrester Research et TDWI en 2007, 45% des entreprises utilisent des applications codées à la main pour leurs tâches ETL, bien devant la première suite ETL (Informatica) qui arrive juste après avec seulement 13% de parts.

Qu'est-ce qu'y pousse les entreprises à vouloir coder leur ETL ?

D'abord examinons les principales motivations qui poussent les entreprises à envisager de coder leur ETL à la main :

1. Le coût : beaucoup d'entreprises choisissent (ou sont poussées par la réalité des budgets) à coder leurs tâches ETL car au démarrage de leur projet de Data Warehouse, le coût des suites ETL professionnelles dont elles ont entendu parler est bien au-delà du budget dont elles disposent. De plus, elles sont tentées d'utiliser pour cela leurs ressources de programmeurs déjà disponibles en interne ; alors qu'il faudrait former des développeurs à l'outils ou faire appel à des prestataires externes dans le cas de l'acquisition d'une suite ETL.

2. La flexibilité : certaines tâches qui n'entrent pas dans l'approche "classique" des ETL peuvent être très compliqués voir impossible à réaliser par certains outils, coder son propre ETL permet de s'affranchir des contraintes inhérentes aux capacités de l'outils et obtenir ainsi une flexibilité virtuellement sans limite. De plus, les programmeurs habitués aux tests unitaires automatisés pratiqués dans les approches de développement logiciel se retrouveront frustrés avec les outils ETL.

3. Performances : il peut sembler judicieux, dans un soucis de performance, de coder ses tâches ETL dans un langage de programmation en code natif comme le C ou directement dans le SGBD à l'aide de procédures stockées. Cette dernière approche appelée ELT (Extract, Load, Transform) est d'ailleurs très répondue du fait que les projets de data warehousing sont souvent confiés à des développeurs SQL qui sont très peu familiés avec les outils ETL mais qui ont écrit des certaines de procédures stockés par le passé.

Comme conséquence, les entreprises qui choisissent cette option se retrouvent avec un vaste plat de spaghettis de code, tout y est : du C, du shell, du PL/SQL, le tout habilement entrelassé. 

Les choses ont changés

Ces motivations étaient justifiés il y'a quelques années, cependant, les choses ont changés et les arguments d'hier ne sont plus valables aujourd'hui. 

L'émergence d'ETL Open Sources de classe professionnelle et l'incorporation d'outils ETL sans surcoût dans les offres de certains éditeurs de bases de données ont fait tombé la barrière du prix des licences et permettent aux entreprises de disposer d'alternatives à fiables et abordables, qui peuvent convenir à de nombreux projets d'intégration de données de moyenne taille voire certains projets d'envergure.

Tous ou quasiment tous les ETL de classe professionnelle offrent la possibilité de prolonger leurs fonctionnalités avec des modules codés dans un langage de programmation sous-jacent, Cela peut être un langage de script propriétaire ou un langage populaire comme Java pour Talend ou .Net pour SSIS.

Enfin, croire qu'un ETL maison codé en C ou des procédures stockés offrent de meilleurs performance d'un outils ETL n'est plus vrai. L'une des principales différentiations qui existent entre les produits ETL est leur capacité à monter en charge et traiter de gros volumes de données à travers des mécanismes de parallélisme, cache ou traitements en-mémoire. 

La valeur ajoutée d'un ETL

En plus de la flexibilité et performances qui font désormais jeu égal voir meilleur jeu que les ETL maison, la valeur ajoutée des outils du marché est est multiple.

La méthodologie : les outils ETL apporte à l'entreprise une méthodologie standard pour les processus d'intégration de données, cette approche est construite sur un moteur de règles cohérentes avec les principes du data warehousing (les travaux de Kimball sur le sujet l'ont amené à identifié 38 tâches requises dans la majorité des processus d'alimentation de data warehouse). Ce cadre très structurant rend la maintenance plus facile y compris pour les personnes qui ne font pas partie de l'équipe de développement originale.

La productivité : les suites ETL intègrent nativement des composants de connexion pour les sources de données et composants pour l'ensemble des tâches de transformation récurrentes (recherche, branchements conditionnels, dimensions à variation lente, fait à arrivé tardive...) sans oublier certaines fonctionnalités avancées comme l'analyse d'impact, l'audit des données, la recherche floue... Ce qui permet aux développeurs de se concentrer sur la logique de transformation elle-même au lieu de devoir réimplantation les composants qui leurs permettront de la faire. De plus ils offrent des interfaces utilisateur très graphiques qui donne une idée visuelle du flux de transformation. 

Une indépendance vis-à-vis du SGBD : l'implémentation de routines ELT en procédures stockées limitent les possibilités de changement de SGBD lorsque celui-ci n'est plus adapté à la volumétrie des données.

Retour sur investissement : les gains en productivité obtenus grâce aux outils ETL conduisent à des mise en oeuvre plus rapides et des temps de développement et de maintenance plus courts. Si l'on devait réfléchir en TCO, l'utilisation de suite ETL offre une meilleure rentabilité que les développement spécifiques dans les projets d'envergure. Sans oublier que l'outils pourra être utilisé dans d'autres tâches comme la migration de données et interfaçage inter-applicatif.

Et la réalité dans tout ça ?

Si comme 45% des entreprises, vous avez des systèmes d'alimentation maison hérités, plus que trois stratégies possibles :

- Le remplacement : mais qui en aurait le courage et surtout est-ce vraiment rentable ?
- L'endiguement
- La co-existence

Mais surtout, avant de choisir l'option de fabriquer votre ETL, posez-vous les questions : comment faire lorsque le volume des données et l'envergure du projet aura pris une autre ampleur ? lorsque le dernier des développeurs originaux de l'application aura quitté l'entreprise ? combien de temps cela prendra-il de développer les évolutions nécessaires  ?