Yves de Montcheuil, Sunopsis
Naturellement, les principaux acteurs américains du marché ETL ont basé leur stratégie produit et leur positionnement sur le postulat que le SQL ne convenait pas répondre aux besoins en ETL. Ils ont ainsi promu des langages propriétaires et des solutions onéreuses comme les seules approches valables pour la réussite des projets ETL.
En réalité, les deux tiers des projets d’intégration de données reposent sur de l’écriture de code. En effet les équipes techniques s’appuient sur les capacités avancées du SQL des dernières versions de leur SGBD pour extraire, charger et transformer les données dans leur data warehouse.
Quelle est la bonne approche ? Le SQL serait il en passe de devenir un standard pour l’intégration de données en rendant obsolète les langages ETL propriétaires ?
En réalité, les deux tiers des projets d’intégration de données reposent sur de l’écriture de code. En effet les équipes techniques s’appuient sur les capacités avancées du SQL des dernières versions de leur SGBD pour extraire, charger et transformer les données dans leur data warehouse.
Quelle est la bonne approche ? Le SQL serait il en passe de devenir un standard pour l’intégration de données en rendant obsolète les langages ETL propriétaires ?
L’approche traditionnelle : les moteurs ETL
Depuis au moins 10 ans, la plupart des outils ETL ont été basés sur des moteurs propriétaires, et les éditeurs d’ETL traditionnels ont inondé le marché avec un message très fort. En effet, dans les années 90, les SGBDR les plus communément utilisés, comme Oracle, Ingres, Informix, Sybase et DB2, fournissaient des moyens efficaces pour stocker, et accéder à de grands volumes de données sans avoir à définir le chemin physique qui permettait ces actions. Mais les langages SQL des SGBDR des années 90 n’étaient pas assez riches pour supporter les besoins en transformations complexes requises par le data warehousing. De plus, durant cette décennie, les logiciels d’ETL n’étaient pas capables d’utiliser le SQL et les SGBDR comme des moteurs pour exécuter des transformations complexes.
Le coût d’intégration d’une solution ETL traditionnelle est tel que seulement 25% des projets de data warehouse ont choisi de les utiliser. Comme souvent sur les marchés en croissance, les solutions propriétaires dominent d’abord le marché, généralement à un niveau de prix élevé, jusqu’à l’émergence d’un standard de l’industrie. Lorsque ce standard devient prêt à répondre à la majorité des demandes client, il devient alors largement utilisé et les solutions propriétaires disparaissent ou se recentrent sur des niches. C’est ce scénario qui est en train de se dérouler, avec le SQL devenant le standard de l’industrie pour l’intégration de données.
Le coût d’intégration d’une solution ETL traditionnelle est tel que seulement 25% des projets de data warehouse ont choisi de les utiliser. Comme souvent sur les marchés en croissance, les solutions propriétaires dominent d’abord le marché, généralement à un niveau de prix élevé, jusqu’à l’émergence d’un standard de l’industrie. Lorsque ce standard devient prêt à répondre à la majorité des demandes client, il devient alors largement utilisé et les solutions propriétaires disparaissent ou se recentrent sur des niches. C’est ce scénario qui est en train de se dérouler, avec le SQL devenant le standard de l’industrie pour l’intégration de données.
Projets ETL développés en SQL : croissance ou déclin?
En fait il y a deux aspects derrière cette question : pourquoi les équipes informatiques choisiraient-elles le développement de code pour un projet d’intégration de données, et pourquoi arrêteraient-elles de coder et commenceraient-elles à utiliser un outil d’intégration de données à un prix raisonnable ?
Les réponses obtenues, lorsque la question du développement de code a été posée à des personnes impliquées dans des projets ETL, ne sont pas surprenantes. Ils ont opté pour cette solution pour 2 raisons principales : 1) La taille du projet. Typiquement, le projet couvrait initialement une vingtaine de tables et le coût d’un ETL était trop élevé – sans compter le besoin en formation. Ou bien 2) parce qu’ils avaient été déjà échaudés par les performances d’un ETL faisant des mises à jour ligne à ligne.
En revanche, les raisons qui les avaient poussés à arrêter le développement de code et à acquérir un outil d’ETL étaient principalement les suivantes :
La productivité des développements. Même si le SQL des principaux SGBD est aujourd’hui extrêmement puissant – jusqu’à 20 fois plus riche et puissant qu’il y a 10 ans, qui plus est intégrant des fonctions dédiées à l’ETL – le développement en SQL est encore très consommateur en temps et les projets écrits à la main sont souvent en retard. La maintenance des processus ETL codés manuellement est, elle aussi, très coûteuse, surtout lorsque plusieurs développeurs sont impliqués. La plupart des outils ETL fournissent quant à eux un environnement de développement dédié, qui inclut la gestion des méta données, et surtout une interface graphique puissante qui permet de développer jusqu’à cinq fois plus vite qu’à la main : les objets peuvent être réutilisés, le code est indépendant de la plateforme, et des modèles peuvent être définis pour faciliter le codage.
La sophistication des processus ETL. La plupart du code écrit à la main est du SQL générique, et nombre de fonctions avancées réalisées par un ETL sont difficiles à implémenter en écrivant manuellement des scripts. On peut citer entre autres :
• Le contrôle de la qualité des données : il fait partie intégrante du processus d’intégration et est l’un des aspects les plus importants dans le data warehousing. Le contrôle des données inclut la vérification de l’intégrité des données (clés primaires, clés étrangères, et règles utilisateurs). Dans les projets d’intégration de données, le contrôle des données est souvent négligé à cause de sa complexité de mise en œuvre.
• Le traitement de sources et cibles hétérogènes, incluant les jointures entre des tables réparties sur des bases différentes, la conversion des types de données et la concaténation/répartition des données entre différentes sources et cibles. L’hétérogénéité crée des problématiques complexes, dont le besoin d’utiliser plusieurs langages, d’assurer l’iso fonctionnalité entre les plateformes et d’utiliser un espace de travail pour exécuter les jointures.
• Les mises à jour intelligentes, les dimensions à évolution lentes : ne charger ou ne modifier que les données insérées ou mises à jour depuis la dernière itération, ou gérer les dimensions à évolution lente sont deux fonctionnalités quasiment impossibles à écrire à la main.
• Les mises à jour en temps réel : la détection des changements dans les sources et leur propagation en temps réel ou quasi réel dans les bases cibles. Les mises à jour en temps réel sont des challenges très complexes à mettre en œuvre manuellement.
Maintenance. Le SQL développé manuellement est difficilement maintenable. Aucune gestion des erreurs ou fonction de déboguage ne sont disponibles lorsque les scripts sont écrits à la main. L’utilisation d’un outil aide à l’homogénéisation du code.
Sécurité. Les scripts manuels nécessitent de gérer les droits des utilisateurs sur tous les serveurs de développement, sans avoir une vue d’ensemble de leurs droits et privilèges : systèmes d’exploitation, bases de données, accès à distance – tout est administré séparément. Développer ces fonctions de sécurité est en soit un projet important.
Gestion de projet. Il est difficile pour un chef de projet de suivre au jour le jour les développements manuels. Il ne peut pas avoir une vue d’ensemble de son projet. Les outils d’ETL fournissent un référentiel centralisé et des outils pour l’analyse et le reporting. Ils gèrent aussi de faire les sauvegardes pour pouvoir faire face aux éventuels problèmes, et assurent le suivi des versions.
La gestion des exceptions. Les projets écrits à la main ne prennent pas en compte la gestion des erreurs. L’identification et la gestion des exceptions sont donc souvent laissées de côté dans un planning déjà chargé. Un bon outil d’ETL peut isoler les enregistrements invalides, et, si besoin, automatiser la gestion des erreurs.
Et pourtant, l’obstacle principal pour les équipes informatiques pour passer de l’écriture manuelle du code à un outil ETL est la souplesse que le développeur perd en utilisant un logiciel. Les équipes informatiques qui développent leurs propres scripts d’intégration de données avec du code adapté à leurs besoins doivent pouvoir conserver une partie de leurs développements afin de garder la flexibilité qu’ils ont connu. C’est typiquement un vrai challenge, les outils d’ETL traditionnels n’offrant pas les mêmes fonctionnalités avec leurs langages propriétaires. Seul un outil d’ETL basé sur une technologie de génération de code natif fournit la souplesse voulue pour passer des développements manuels à la génération automatique sans avoir à éliminer tous les développements antérieurs.
Les réponses obtenues, lorsque la question du développement de code a été posée à des personnes impliquées dans des projets ETL, ne sont pas surprenantes. Ils ont opté pour cette solution pour 2 raisons principales : 1) La taille du projet. Typiquement, le projet couvrait initialement une vingtaine de tables et le coût d’un ETL était trop élevé – sans compter le besoin en formation. Ou bien 2) parce qu’ils avaient été déjà échaudés par les performances d’un ETL faisant des mises à jour ligne à ligne.
En revanche, les raisons qui les avaient poussés à arrêter le développement de code et à acquérir un outil d’ETL étaient principalement les suivantes :
La productivité des développements. Même si le SQL des principaux SGBD est aujourd’hui extrêmement puissant – jusqu’à 20 fois plus riche et puissant qu’il y a 10 ans, qui plus est intégrant des fonctions dédiées à l’ETL – le développement en SQL est encore très consommateur en temps et les projets écrits à la main sont souvent en retard. La maintenance des processus ETL codés manuellement est, elle aussi, très coûteuse, surtout lorsque plusieurs développeurs sont impliqués. La plupart des outils ETL fournissent quant à eux un environnement de développement dédié, qui inclut la gestion des méta données, et surtout une interface graphique puissante qui permet de développer jusqu’à cinq fois plus vite qu’à la main : les objets peuvent être réutilisés, le code est indépendant de la plateforme, et des modèles peuvent être définis pour faciliter le codage.
La sophistication des processus ETL. La plupart du code écrit à la main est du SQL générique, et nombre de fonctions avancées réalisées par un ETL sont difficiles à implémenter en écrivant manuellement des scripts. On peut citer entre autres :
• Le contrôle de la qualité des données : il fait partie intégrante du processus d’intégration et est l’un des aspects les plus importants dans le data warehousing. Le contrôle des données inclut la vérification de l’intégrité des données (clés primaires, clés étrangères, et règles utilisateurs). Dans les projets d’intégration de données, le contrôle des données est souvent négligé à cause de sa complexité de mise en œuvre.
• Le traitement de sources et cibles hétérogènes, incluant les jointures entre des tables réparties sur des bases différentes, la conversion des types de données et la concaténation/répartition des données entre différentes sources et cibles. L’hétérogénéité crée des problématiques complexes, dont le besoin d’utiliser plusieurs langages, d’assurer l’iso fonctionnalité entre les plateformes et d’utiliser un espace de travail pour exécuter les jointures.
• Les mises à jour intelligentes, les dimensions à évolution lentes : ne charger ou ne modifier que les données insérées ou mises à jour depuis la dernière itération, ou gérer les dimensions à évolution lente sont deux fonctionnalités quasiment impossibles à écrire à la main.
• Les mises à jour en temps réel : la détection des changements dans les sources et leur propagation en temps réel ou quasi réel dans les bases cibles. Les mises à jour en temps réel sont des challenges très complexes à mettre en œuvre manuellement.
Maintenance. Le SQL développé manuellement est difficilement maintenable. Aucune gestion des erreurs ou fonction de déboguage ne sont disponibles lorsque les scripts sont écrits à la main. L’utilisation d’un outil aide à l’homogénéisation du code.
Sécurité. Les scripts manuels nécessitent de gérer les droits des utilisateurs sur tous les serveurs de développement, sans avoir une vue d’ensemble de leurs droits et privilèges : systèmes d’exploitation, bases de données, accès à distance – tout est administré séparément. Développer ces fonctions de sécurité est en soit un projet important.
Gestion de projet. Il est difficile pour un chef de projet de suivre au jour le jour les développements manuels. Il ne peut pas avoir une vue d’ensemble de son projet. Les outils d’ETL fournissent un référentiel centralisé et des outils pour l’analyse et le reporting. Ils gèrent aussi de faire les sauvegardes pour pouvoir faire face aux éventuels problèmes, et assurent le suivi des versions.
La gestion des exceptions. Les projets écrits à la main ne prennent pas en compte la gestion des erreurs. L’identification et la gestion des exceptions sont donc souvent laissées de côté dans un planning déjà chargé. Un bon outil d’ETL peut isoler les enregistrements invalides, et, si besoin, automatiser la gestion des erreurs.
Et pourtant, l’obstacle principal pour les équipes informatiques pour passer de l’écriture manuelle du code à un outil ETL est la souplesse que le développeur perd en utilisant un logiciel. Les équipes informatiques qui développent leurs propres scripts d’intégration de données avec du code adapté à leurs besoins doivent pouvoir conserver une partie de leurs développements afin de garder la flexibilité qu’ils ont connu. C’est typiquement un vrai challenge, les outils d’ETL traditionnels n’offrant pas les mêmes fonctionnalités avec leurs langages propriétaires. Seul un outil d’ETL basé sur une technologie de génération de code natif fournit la souplesse voulue pour passer des développements manuels à la génération automatique sans avoir à éliminer tous les développements antérieurs.
Les avantages des générateurs de code
Maintenant que le SQL est assez riche pour répondre aux besoins en ETL, les fournisseurs de générateurs de code SQL fournissent des arguments incontournables pour l’adoption de leur approche innovante :
• Un cycle d’apprentissage court – il n’y a pas besoin de se former à de nouveaux langages.
• Pas de besoin de rajouter du logiciel ou du matériel à l’infrastructure informatique de production.
• Le code SQL natif est généré pour les SGBDR, sans codage manuel.
• Coût plus faible que les outils ETL traditionnels.
• Flexibilité importante du processus ETL.
• Support efficace de tous les SGBDR.
• Haut niveau de performances.
• Utilisation de toutes les fonctionnalités des SGBDR (architecture massivement parallèle, clusters, etc.).
• Un cycle d’apprentissage court – il n’y a pas besoin de se former à de nouveaux langages.
• Pas de besoin de rajouter du logiciel ou du matériel à l’infrastructure informatique de production.
• Le code SQL natif est généré pour les SGBDR, sans codage manuel.
• Coût plus faible que les outils ETL traditionnels.
• Flexibilité importante du processus ETL.
• Support efficace de tous les SGBDR.
• Haut niveau de performances.
• Utilisation de toutes les fonctionnalités des SGBDR (architecture massivement parallèle, clusters, etc.).
Conclusion
La disponibilité des outils ETL des SGBDR a définitivement changé le paysage du marché de l’intégration de données, promouvant SQL comme le langage standard pour l'intégration de données. Cette solution montre que les SGBD et le SQL ont la puissance d'exécuter n'importe quel type d'intégration de données et que les générateurs de code SQL seront la base pour les générations à venir des solutions d'intégration de données. Ils ont en fait préparé le terrain pour des produits beaucoup plus puissants, qui permettent aux tâches complexes d'intégration de données d'être exécutées en mode batch ou temps réel, sans aucune écriture de code. Ce tournant important du marché de l’intégration de données devient maintenant évident.