L’ETL (Extract Transform and Load) un ensemble de composants logiciels capable d’extraire, de Transformer et de charger des données d’une source vers cible à priori diverses (Fichiers à plats, SGBDR, …). On distingue généralement trois types ou architectures d'ETL :
I ETL Moteur
L’ETL moteur est l’ETL par excellence. Il est monté sur un Serveur du milieu (Serveur ETL). Ainsi toutes les transformations sont traitées par lui. Généralement la persistance des métadonnées est gérée par SGBDR (C’est le référentiel). Comme exemple d’ETL de cette famille nous pouvons citer : 1- Informatica PowerCenter
2- IBM Ascential
3- Hummingbird Genio
4- Business Objects Data Integrator
5- DataMiror Transformation Server 6- Ab InItio Software Ab InItio 7- open source : Octopuss, KETL, Talend, ...
I-1 Avantages
Possibilités d’effectuer des opérations « mutibases ». Par exemple jointure entre une table Sybase et une autre table Oracle. Notons quand même que dans bon nombre de projets DataWareHouse, on préfère résoudre le problème de « jointure multibase » dans un ODS. Ce qui me paraît plus souple, mais plus long. En effet il faut au préalable charger les deux tables Sybase et Oracle dans un ODS Oracle par exemple. Ensuite effectuer l’opération de jointure dans l’ODS
I-2 Inconvénients
- Le côut. Ce dernier est souvent fonction du nombre de connecteurs et de machines « moteurs ».
- Le côté « boite noire » du moteur. En effet les Transformations faites par le moteur ne sont pas accessibles. Donc la seule optimisation possible est celle fournie par le moteur lui-même !!! Ci-après une synoptique de l'architure
II ETL Base L’ETL Base est encore appelé ETL générateur de code ou ELT (Extract Load and Transform). En effet ici les transformations sont quasiment toutes déportés dans les SGBDR. Ainsi l’ETL se chargeant juste de générer le code SQL idoine. Donc pas besoin d’une machine devant héberger l’ETL, Juste une machine supportant un ordonnateur qui est là pour vérifier les relations d’ordre entre process SQL .Généralement la persistance des métadonnées est gérée par SGBDR (C’est le référentiel).
1- Sunospis (Rachété depuis fin 2006 par Oracle)
2- Oracle WareHouse Builder
3- DB2 Warehouse Manager 4- …
II-1 Avantages
- Le côté « boite blanche» du moteur. En effet les Transformations générées par le moteur sont accessibles ((SQL, PL/SQL, T-SQL, …) et à fortiori optimisable.
- Le prix. Les ETL Base sont les moins chers du marché. II-2 Inconvénients
- Ici on suppose que toutes les opérations sont transformables et optimisable par sur un SGBDR. Eh ben Je suis de ceux qui pensent qu’il y a des opérations qui de part leur nature sont moins performantes sur un SGBDR
Ci-après une synoptique de l'architure
III ETL Moteur et Base
L’ETL moteur et base que j’appelle volontiers ETTL (Extract Transform and Transform and Load). Les deux « T » se justifiant par la double transformation. En effet ici les transformations peuvent être faites dans le moteur ETL ou (inclusif) dans les SGBDR.
Généralement la persistance des métadonnées est gérée par SGBDR (C’est le référentiel). Comme exemple d’ETL de cette famille nous pouvons citer : 1- Hummingbird Genio (Mon favoris)
2- Informatica PowerCenter
3- De manière générale, les ETL Moteur convergent aujourd'hui preque tous vers des ETTL.
III-1 Avantages
Possibilités de répartir des traitements. Tout n’est pas possible avec le SQL. Par exemple ramener la nième ligne d’une requête est une opération dont la difficulté est fonction du SGBDR. Or elle se retrouve facilitée avec un moteur ETL (puisqu’il suffit de boucler sur les lignes résultats pour ramener la ligne recherchée)
III-2 Inconvénients - Le côut. Ce dernier est souvent fonction du nombre de connecteurs et de machines « moteurs ». - Le côté « boite noire » du moteur. En effet les Transformations faites par le moteur ne sont pas accessibles. Donc la seule optimisation possible est celle fournie par le moteur lui-même !!!
Ci-après une synoptique de l'architure
Tout ou Partie de cet article ne peut reproduit sans autorisation écrite de M. Benjamin EPEE
| Novembre 2009 | ||||||||||
| L | M | M | J | V | S | D | ||||
| 1 | ||||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | ||||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | ||||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | ||||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | ||||
| 30 | ||||||||||
|
||||||||||
Bravo pour cette synthèse.
Un mot pour ajouter les ETL historiques générateur de COBOL
Pour abonder dans votre sens dans la partie II-2: les moteurs des SGBDR sont opimisés pour le transactionnel par pour les traitement de masse. A noter cependant que certains outils comme Power Center utilisent plutôt les outils de migration disponibles sur les plateformes comme DB2 Unload par exemple.
cordialement,
BD
Bonjour,
En ce qui concerne la partie II (ETL Base), une précision s'impose, les ETL de Base (comme vous les appellez) n'ont pas forcément besoin d'une base de données pour le Traitement de transformation. Si vous utilisez ETI extract (qui est pour moi l'ETL Base par excelence) vous travaillerez aussi bien en fichier qu'en base (DB2, Oracle, Informix, etc ), sur différente plateforme (MVS, Unix, GCOS8, et autre), en différent langage ( Sql, cobol, pl/sql, perl, etc ).
De plus, sur votre shéma L'ETL est présent dans l'archecture, or cela n'est pas correcte. Les scripts sont déposés sur les différentes plateforme sources et sont gérés par les scheduleurs des différentes machines.
Dont l'inconvenient n'est d'optimisation tombe. Par contre un administrateur de l'ETL est nécessaire et son cout peut être un incovénient si l'on ne prend en compte que la mise ne place de l'outil. Par contre les couts de développement peuvent être largement réduits.
Cordialement RV