ETL Talend Rapport

Informatique de gestion laboratoire bases de données

Projet Ecureuil – DataWarehouse CNIP

ETL avec Talend Travail de diplôme 2007

Yannick Perret Responsable de projet: Sylvie Bouchard Membre du groupe de projet: Julien Helbling

Yannick Perret / 27.09.2007

Rapport travail de diplôme 2007

1/70


1. Tables des matières 1. 2.

Tables des matières ............................................................................................ 2 Introduction.......................................................................................................... 5 2.1. Cahier des charges ...................................................................................... 7 2.1.1. Mandat de projet ................................................................................... 7 2.1.2. Organisation de projet........................................................................... 7 2.1.3. Origine du mandat................................................................................. 7 2.1.4. Objectifs ................................................................................................ 8 2.1.5. Tâches .................................................................................................. 8 2.1.6. Langages / Technologies / Outils .......................................................... 8 3. Partie théorique ................................................................................................... 9 3.1. Informatique décisionnelle............................................................................ 9 3.1.1. Datawarehouse ................................................................................... 10 3.1.2. Cube OLAP (OnLine Analytical Processing) ....................................... 11 3.1.3. Staging Area ....................................................................................... 11 3.2. Architecture du projet ................................................................................. 12 3.2.1. Situation actuelle................................................................................. 12 3.2.1.1. Extraction ..................................................................................... 12 3.2.1.2. Transformation............................................................................. 13 3.2.1.3. Transfert....................................................................................... 13 3.2.1.4. Création des cubes ...................................................................... 13 3.2.2. Objectif ................................................................................................ 14 3.2.2.1. MS Access ................................................................................... 14 3.2.2.2. Talend .......................................................................................... 14 3.2.2.3. Serveur PostgreSQL .................................................................... 15 3.2.2.4. Mondrian ...................................................................................... 15 3.2.2.5. Synthèse ...................................................................................... 15 3.3. Microsoft SQL Server 2005 ........................................................................ 15 3.4. Talend Open Studio ................................................................................... 16 3.4.1. Architecture ......................................................................................... 16 3.4.1.1. Repository.................................................................................... 17 3.4.1.1.1. Business Models...................................................................... 17 3.4.1.1.2. Job Designs ............................................................................. 17 3.4.1.1.3. Code ........................................................................................ 17 3.4.1.1.4. Metadata.................................................................................. 17 3.4.1.1.5. Documentation......................................................................... 18 3.4.1.1.6. Recycle bin .............................................................................. 18 3.4.1.2. Workspace ................................................................................... 19 3.4.1.3. Palette.......................................................................................... 20 3.4.1.3.1. Principaux outils utilisés........................................................... 20 3.4.1.4. Vues............................................................................................. 22 3.4.1.4.1. Properties ................................................................................ 22 3.4.1.4.2. Run Job ................................................................................... 22 3.4.1.4.3. Modules ................................................................................... 23 3.4.1.4.4. Scheduler................................................................................. 23 3.5. Autres logiciels ETL open source ............................................................... 23



2/70


4.

Partie pratique ................................................................................................... 24 4.1. Travail en commun..................................................................................... 24 4.1.1. Déploiement du projet Ecureuil : ......................................................... 24 4.2. Création des tables dans PostgreSQL ....................................................... 26 4.2.1. Principales différences ........................................................................ 27 4.2.1.1. Exemple: création de la table HISTO_Temps dans SQL Server 2005 28 4.2.1.2. Exemple: création de la table HISTO_Temps dans PostgreSQL. 28 4.3. Création des procédures stockées ............................................................. 29 4.4. Création de la vue esnig_dureeproductionfirstpart ..................................... 29 4.5. Connexions aux bases de données ........................................................... 30 4.5.1. Connexion à la base de données de production ................................. 31 4.5.2. Connexion à la base de données Staging Area .................................. 32 4.5.3. Connexion à la base de données datawarehouse .............................. 32 4.6. Schémas .................................................................................................... 33 4.7. Création des Jobs Designs ........................................................................ 35 4.7.1. Stratégie.............................................................................................. 35 4.7.2. Jobs Designs....................................................................................... 35 4.7.2.1. Esnig_ExecuteAll ......................................................................... 35 4.7.2.1.1. Dans SQL Server 2005............................................................ 35 4.7.2.1.2. Dans Talend ............................................................................ 36 4.7.2.2. Esnig_UpdateArchivageBdProd................................................... 37 4.7.2.2.1. Dans SQL Server 2005............................................................ 37 4.7.2.2.2. Dans Talend ............................................................................ 38 4.7.2.2.2.1. Structure des Jobs Designs............................................... 39 4.7.2.3. Esnig_LoadHistos ........................................................................ 40 4.7.2.3.1. Dans SQL Server 2005............................................................ 40 4.7.2.3.2. Dans Talend ............................................................................ 41 4.7.2.3.2.1. Structure des Jobs Designs............................................... 42 4.7.2.4. Esnig_LoadKeep.......................................................................... 43 4.7.2.4.1. Dans SQL Server 2005............................................................ 44 4.7.2.4.2. Dans Talend ............................................................................ 45 4.7.2.4.2.1. Structure des Jobs Designs............................................... 46 4.7.2.5. Esnig_ExecuteLoadDims ............................................................. 47 4.7.2.5.1. Dans SQL Server 2005............................................................ 47 4.7.2.5.2. Dans Talend ............................................................................ 48 4.7.2.5.2.1. Structure des Jobs Designs............................................... 48 4.7.2.6. Esnig_ExecuteLoadFacts ............................................................ 51 4.7.2.6.1. Dans SQL Server 2005............................................................ 51 4.7.2.6.2. Dans Talend ............................................................................ 51 4.7.2.6.2.1. Structure des Jobs Designs............................................... 52 4.7.2.7. Esnig_LoadDWFromSA ............................................................... 54 4.7.2.7.1. Dans SQL Server 2005............................................................ 54 4.7.2.7.2. Dans Talend ............................................................................ 55 4.7.2.7.2.1. Structure des Jobs Designs............................................... 55 4.7.3. Planification de l'exécution des Jobs Designs..................................... 57 4.8. Mise en commun des deux travaux de diplôme ......................................... 58



3/70


5. 6.

Conclusion......................................................................................................... 59 Guides d'installation .......................................................................................... 60 6.1. Installation serveur PostgreSQL................................................................. 60 6.1.1. Fichiers d'installation ........................................................................... 60 6.1.2. Installation ........................................................................................... 60 6.2. Installation Talend Open Studio ................................................................. 61 6.2.1. Prérequis............................................................................................. 61 6.2.1.1. Java ............................................................................................. 61 6.2.1.2. Perl............................................................................................... 63 6.2.2. Installation ........................................................................................... 64 6.3. Installation CRONw .................................................................................... 69 6.4. Bibliographie............................................................................................... 70



4/70


2. Introduction Le CNIP (Centre Neuchâtelois d'Intégration Professionnelle) est un établissement cantonal de formation professionnelle et est spécialisé dans la formation et l'aide à la réinsertion professionnelle d'adultes (ouvriers qualifiés ou non). Il est situé à Couvet dans l'ancien site Dubied et dispose de 3500 m2 de surface d'atelier de formation et de 900 m2 de salle de cours, ceci pour une capacité de 120 places. Il prodigue une formation modulaire individualisée à la carte en partenariat avec les secteurs de l'industrie et de l'artisanat et offre principalement à des adultes, par le biais de cours du jour ou du soir, l’opportunité d’intégrer et de réinvestir un univers professionnel en constante évolution. Le laboratoire de base de données de l'ESNIG (École Supérieure Neuchâteloise d'Informatique de Gestion) a développé une application Access afin que le CNIP puisse gérer la formation des ses apprenants. Le laboratoire a également mis en place un datawarehouse, sous le nom de projet Ecureuil, qui permet au CNIP de construire des cubes OLAP donnant la possibilité d'exporter les résultats des états Access vers des feuilles Excel ou de créer rapidement un graphique. Ce datawarehouse a été mis en place sous SQL Server 2000 lors du travail de diplôme de Julien Helbling. Il a été ensuite migré sous SQL Server 2005. Mais la documentation n'a pas été mise à jour. Le déroulement de ce travail de diplôme s'est fait en deux phases. Durant les trois premières semaines, j'ai travaillé en collaboration avec Fabien Airiau. Il nous a été demandé d'étudier et de comprendre un projet de datawarehouse, de déployer celui du CNIP sous SQL Server 2005 et de reprendre la documentation concernant SQL Server 2000 pour la mettre à jour. Nous avons également produit un document détaillant et décrivant l'enchaînement des lots. La deuxième partie du travail s'est faite seul. Le laboratoire de base de données de l'ESNIG souhaitant étudier la faisabilité d'un projet de datawarehouse de l'envergure du CNIP sur des outils open source, il m'a été confié de mettre en place toutes les procédures d'extraction, de transformation et de chargement des données à l'aide de l'outil Talend Open Studio pour le datawarehouse du CNIP et de stocker celui-ci dans une base de données PostgreSQL. L'objectif étant de fournir un datawarehouse contenant des données "propres" à Fabien Airiau dont le travail consiste à mettre en place les cubes d'analyse à partir de ces données, toujours à l'aide d'outils open source. Dans la partie théorique, j'ai tenté de passer en revue les notions essentielles concernant l'informatique décisionnelle. J'ai également présenté la structure actuelle du projet ainsi que celle qui est attendue en fin de projet. Enfin, j'ai présenté brièvement l'outil Talend Open Studio et ses principaux outils.



5/70


La partie pratique commence par la description de la partie commune du travail. Je me suis efforcé ensuite de faire le lien entre le travail ETL mis en place par Julien Helbling sous SQL Server et celui que j'ai effectué sous Talend Open Studio afin de pouvoir comparer au mieux le travail des deux logiciels. Dans la partie "Guides d'installation" se trouvent les marches à suivre afin d'installer tous les composants nécessaires à la bonne marche de ce travail. Les codes sources utilisés sont quant eux dans disponibles en annexe.



6/70


2.1. Cahier des charges 2.1.1.

Mandat de projet

Etude comparative de quelques outils open source d'extraction/transformation/chargement de données vers un datawarehouse. Mise en œuvre à l'aide de l'outil ETL Talend.

2.1.2.

Organisation de projet Mandant

Responsable de projet

Membres du groupe de projet

laboratoire bases de données

S. Bouchard

J. Helbling

Début du projet

Fin du projet

18 juin 2007

28 septembre 2007

2.1.3. • • •

Origine du mandat

Le laboratoire bases de données de l'ESNIG a développé un datawarehouse pour le CNIP Les développements ont été réalisés avec SQLServer 2000 puis migrés vers SQLServer 2005 Le laboratoire souhaite analyser la faisabilité d'un projet de cette envergure avec des outils du monde libre.



7/70


2.1.4. • • • • • •

Découvrir un projet de datawarehouse. Etudier la démarche de conception / développement d'un projet de datawarehouse à travers le travail réalisé par J. Helbling. Adapter une partie de la documentation du rapport de J. Helbling SQLServer 2000 pour SQLServer 2005. Déployer le datawarehouse du projet CNIP sur SQLServer 2005 en créant simultanément la documentation détaillée. Mettre en place les mêmes procédures d'extraction de données avec Talend / PostgreSQL. Mettre à disposition du laboratoire une documentation détaillée sur la mise en œuvre des outils ETL utilisés.

2.1.5. • • • • • • •

Tâches

Installer SQLServer 2005. Déployer et utiliser le datawarehouse développé dans SQLServer2005. Analyser de façon détaillée les procédures d'extraction de données. Effectuer une étude comparative de quelques outils ETL open source fonctionnalités/licences. Installer un serveur PostgreSQL dans un environnement Windows. Préparer la script de création des tables du datawarehouse pour PostgreSQL. Développer les procédures d'extraction avec Talend.

2.1.6. • • • • •

Objectifs

Langages / Technologies / Outils

Modèles dimensionnels. Talend. PostgreSQL. SQLServer 2005. MS-Access 2000 (données de production).



8/70


3. Partie théorique 3.1. Informatique décisionnelle L'informatique décisionnelle désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données d'une entreprise afin d'exploiter celles-ci dans le but d'aider la prise de décision des décideurs. Cela doit permettre d'aider à mieux comprendre la situation actuelle et à anticiper les actions futures pour un meilleur pilotage de l'entreprise. Les données qui vont être exploitées sont stockées dans un entrepôt de données, appelé aussi datawarehouse. Auparavant un outil ETL (Extract Transform Load) va extraire, préparer et charger les données provenant de diverses sources. L'informatique décisionnelle s'attache à mesurer un certain nombre d'indicateurs ou de mesures (que l'on appelle aussi les faits ou les métriques) restitués selon les axes d'analyse (les dimensions). Ce processus est réalisé à l'aide des cubes OLAP (OnLine Analytical Processing).



9/70


3.1.1.

Datawarehouse

Un datawarehouse est une base de données utilisée dans l'informatique décisionnelle et constituée afin d’analyser de gros volumes de données très détaillés, durables, en principe datés. Il centralise des informations extraites de différentes applications et bases de données rattachées à l'environnement de production, à l'activité commerciale, etc., pour faciliter la prise de décisions. Il est construit selon un modèle dimensionnel dénormalisé. Celui du CNIP a été crée selon un modèle en étoile. Un modèle en étoile est constitué d'une table de fait contenant les données à analyser ainsi que les clés étrangères vers les tables de dimensions qui se trouvent autour d'elle.

Exemple de modèle en étoile (appartenant au projet)



10/70


3.1.2.

Cube OLAP (OnLine Analytical Processing)

Un modèle dimensionnel permet l'analyse des mesures de la table de faits à partir de plusieurs axes. La création d'un cube OLAP est requise pour effectuer ces analyses. Le but des cubes étant de fournir des réponses rapides à des requêtes interrogeant une grande quantité de données et de permettre une interaction en temps réel avec ces données.

3.1.3.

Staging Area

La Staging Area est une base de données dans laquelle tous les traitements sur les données sont effectués avant leur transfert vers le datawarehouse qui ne contiendra que les données du modèle dimensionnel. Pour simplifier, on peut considérer que les données arrivent dans la Staging Area dans le même état que dans leur base de provenance et qu’elles ressortent prêtes à être chargées dans le datawarehouse. Elle est au cœur du travail ETL, car l’extraction des données se fait entre la ou les base(s) de données de production vers la Staging Area, la transformation est effectuée entre des tables stockées dans la base et le chargement n’est qu’une copie des tables du modèle dimensionnel qui est également stocké dans la Staging Area.

Parcours des données au sein d'un projet de Datawarehouse

Dans le projet Ecureuil, la Staging Area fonctionne de la façon suivante: • • •

Les tables HISTO, qui ont la même structure que les tables correspondantes dans la base de production, contiennent les mêmes tuples plus les données archivées. Les tables KEEP contiennent les clés primaires des tuples de la base de production afin de gérer les suppressions des tuples dana les tables HISTO Les tables de faits (FACT) et de dimensions (DIM) sont les mêmes que dans le datawarehouse. Elles sont alimentées par les tables HISTO. Une fois prêtes, les tables du datawarehouse peuvent être chargées à partir de cellesci.



11/70


3.2. Architecture du projet 3.2.1.

Situation actuelle

Actuellement, l'architecture du projet Ecureuil du CNIP est la suivante: les données de la base de production sont stockées dans une base de données MS Access. Ensuite tout le travail de création du datawarehouse et des cubes est effectué au sein de SQL Server 2005 à l’aide des outils de Business Intelligence. Il se divise en quatre phases:

Schéma de l'architecture actuelle du projet du CNIP

3.2.1.1.

Extraction

Les données utiles pour l'analyse multidimensionnelle sont d'abord chargées au sein de la base de données Staging Area depuis la base de production sans qu'aucun traitement ne soit effectué sur celles-ci.



12/70


3.2.1.2.

Transformation

Une fois les données chargées, on procède à l'alimentation dans la Staging Area de toutes les tables de faits et de dimensions constituant le modèle en étoile. Diverses transformations sont effectuées sur les données.

3.2.1.3.

Transfert

Lorsque celles-ci sont prêtes, on peut procéder au transfert des données de ces tables vers la base de données datawarehouse.

3.2.1.4.

Création des cubes

La création des cubes peut s'effectuer lorsque les données des tables du modèle en étoile sont prêtes au sein du datawarehouse. Les cubes sont créés à l'aide du serveur d'analyse ("Analysis Services") de SQL Server 2005 à partir des données contenues dans le datawarehouse.



13/70


3.2.2.

Objectif

Le laboratoire de base de données de l'ESNIG souhaiterait effectuer le même travail qu'actuellement à l'aide d'outils open source. La structure du projet serait quelque peu modifiée et l'ensemble du travail serait réparti sur plusieurs supports:

Schéma de l'architecture souhaitée

3.2.2.1.

MS Access

La base de données de production n'est pas touchée et reste stockée dans une base Access

3.2.2.2.

Talend

Les trois premières phases de travail de l'architecture actuelle du projet vont être exécutées à l'aide de l'outil ETL Talend (présenté plus en détail par la suite), à savoir l'extraction des données de la base de production vers la Staging Area, la transformation des données pour alimenter les tables du modèle en étoile et le transfert des données de ces tables vers le datawarehouse.



14/70


3.2.2.3.

Serveur PostgreSQL

Les bases de données Staging Area et datawarehouse sont stockées au sein d'un serveur PostgreSQL, qui est également un outil open source.

3.2.2.4.

Mondrian

La création des cubes est effectuée à l'aide de Mondrian, qui est un serveur OLAP, à partir des données du datawarehouse stockés au sein du serveur PostgreSQL.

3.2.2.5.

Synthèse

Pour arriver à cet objectif, le travail a été réparti en deux. Ma partie consiste à installer l'outil Talend et le serveur PostgreSQL, ainsi que de mettre en place les procédures d'extraction de manière à fournir des données cohérentes et à jour dans le datawarehouse. La deuxième partie du travail comprend l'installation du serveur OLAP Mondrian et la création des cubes à partir des données du datawarehouse. Cette deuxième partie est effectuée par Fabien Airiau.

3.3. Microsoft SQL Server 2005 Microsoft SQL Server 2005 est un SGBDR (Système de Gestion de Bases de Données Relationnelles) développé par Microsoft. Il permet entre autres : • •

Le déploiement de lots SSIS (SQL Server Integration Services) La gestion d'un serveur d'analyse (OLAP)

(Pour plus d'informations concernant notamment l'installation de Microsoft SQL Server 2005, consultez le document TD07_rapport_partieTheorique_UpdateHelbling fourni en annexe).



15/70


3.4. Talend Open Studio Talend Open Studio est un outil d’intégration de données utilisé pour l'ETL et l’intégration de données opérationnelle développé par Talend. Il est distribué sous licence GPL (General Public License). Talend Open Studio propose une interface permettant de concevoir graphiquement les connexions aux sources et les traitements sur les données. L'interface graphique utilise la plateforme Eclipse. Le travail sur les données est réalisé par des scripts générés. Depuis l'origine, Talend Open Studio génère du Perl. La version 2 a introduit la génération de code Java et SQL.

3.4.1.

Architecture

Talend Open Studio s'ouvre sur une fenêtre à zones multiples. Différentes vues composent cette fenêtre dont les principales fonctionnalités sont décrites ci-après.

Fenêtre à zones multiples de Talend Open Studio



16/70


3.4.1.1.

Repository

Le repository est un référentiel qui regroupe sous forme d'arborescence tous les éléments techniques disponibles pour la conception de Business Models ou de Job Designs. Il permet également l'accès à ceux-ci ainsi qu'à tous les différents éléments utilisés dans les projets.

Repository

3.4.1.1.1. Business Models Un Business Model est outil graphique permettant de modéliser un besoin métier de gestion de flux de données.

3.4.1.1.2. Job Designs Un Job Design représente la couche d'exécution d'un Business Model. Il permet de paramétrer les relations et les connexions entre les différents composants qui vont effectuer des opérations sur le flux de données. On peut considérer qu'un Job Design est plus ou moins équivalent à un lot dans SQL Server 2005.

3.4.1.1.3. Code Le dossier Code regroupe les routines. Une routine est un morceau de code comprenant diverses fonctions qui peuvent être utilisées dans les Job Designs. Le dossier System contient les routines Talend prédéfinies. Avec les routines, il est ainsi possible de créer des fonctions personnalisées pouvant effectuer diverses opérations sur les données.

3.4.1.1.4. Metadata Le dossier Metadata permet d’établir une connexion à source de données, soit à partir d’un fichier, soit à partir d’une base de données.



17/70


3.4.1.1.5. Documentation Le répertoire Documentation regroupe tout type de documents de tout format, tels que des spécifications ou la description d’un format technique particulier d’un fichier.

3.4.1.1.6. Recycle bin Le Recycle bin est la "corbeille" de Talend Open Studio. Tous les objets du Repository qui sont supprimés sont déplacés dans ce dossier. Tous les objets du Recycle bin peuvent être restaurés mais ils sont définitivement effacés une fois que celui-ci est vidé.



18/70


3.4.1.2.

Workspace

Le Workspace ou espace de modélisation est l'éditeur graphique qui permet de concevoir des Business Models et des Job Designs.

Workspace

Différents Business Models ou Job Designs peuvent être ouverts en même temps dans l'éditeur. Ceux-ci sont organisés sous forme d'onglets. Les composants qui vont permettre de construire les Business Models et les Job Designs se trouvent dans la Palette.



19/70


3.4.1.3.

Palette

L'onglet Palette contient tous les composants que l'on peut utiliser lors de la construction d'un Business Model ou d'un Job Design. Ces composants sont classés dans différentes catégories.

Palette

3.4.1.3.1. Principaux outils utilisés

•

Permet d’extraire des tuples d’une base de données Access à partir d’une reqête SQL.

•

Insère, met à jour ou supprime les tuples reçus dans une base de donnés Access.



20/70


•

Exécute une requête SQL dans une base de données Access.

•

Permet d’extraire des tuples d’une base de données PostgreSQL à partir d’une reqête SQL.

•

Insère, met à jour ou supprime les tuples reçus dans une base de donnés PostgreSQL.

•

Exécute une requête SQL dans une base de données PostgreSQL.

•

Permet d’effectuer diverses transformations sur les données ou de poser une ou des conditions pour le transfert des données.

•

Permet de définir et d'exécuter une partie de code java.

•

Permet d'exécuter une commande dans la console



21/70


3.4.1.4.

Vues

Différentes vues sont regroupées dans la partie inférieure de la fenêtre de Talend Open Studio. Comme toutes les vues ne me paraissent pas indispensables, voici uniquement une description des principales.

Vues

3.4.1.4.1. Properties Cet onglet affiche les propriétés de l'élément sélectionné dans l'éditeur graphique. Les propriétés peuvent varier selon le type de l'élément.

3.4.1.4.2. Run Job Il permet d'exécuter le Job Design courant. Il y a deux modes d'exécution: le mode normal et le mode debug qui permet de suivre l'exécution pas à pas. Différentes options d'affichage sont à disposition comme la durée d'exécution ou les statistiques.



22/70


3.4.1.4.3. Modules L'onglet Modules affiche les modules Perl ou Java (suivant l'encodage du projet) qui sont requis pour utiliser les composants correspondants. S'il y a un dans la colonne status, cela signifie que le module requis pour utiliser le composant est installé. Si c'est un triangle jaune d'avertissement, cela indique que le module est recommandé mais pas indispensable au fonctionnement du composant. Par contre, le cercle rouge à croix blanche montre que l'installation du module est obligatoire pour utiliser le composant.

3.4.1.4.4. Scheduler Scheduler est un outil de planification d’exécution basé sur la commande crontab, couramment utilisée sous Unix et systèmes d’exploitation similaires. Cette commande cron peut également être installée sur Windows.

3.5. Autres logiciels ETL open source Voici quelques logiciels ETL open source. Il est difficile de se faire une opinion précise de forces et faiblesses de chaque outil sans le tester. Quant aux fonctionnalités, elles ne diffèrent que très peu selon les outils. •

Enhydra Octopus: outil ETL basé sur du code java. Il peut se connecter à n'importe quelle source de données JDBC. Les transformations sur les données sont définies dans un fichier XML.

•

Clover.ETL et KETL: possèdent plus ou moins les mêmes caractéristiques qu'Octopus.

•

JasperETL: outil ETL développé par Talend. Il vient compléter la JBIS (JasperSoft Business Intelligence Suite) qui comprend également JasperServer, JasperAnalysis, JasperReports et iReport. Cette suite offre donc des outils complets de Business Intelligence open source.



23/70


4. Partie pratique 4.1. Travail en commun 4.1.1.

Déploiement du projet Ecureuil :

Durant les trois premières semaines de travail, Fabien Airiau et moi-même avons travaillé ensemble afin d'analyser et de comprendre l'architecture et le fonctionnement d'un projet de datawarehouse, en l'occurrence celui du CNIP. Avant de se lancer dans le vif du sujet, nous avons pris le soin de nous documenter sur le projet Ecureuil grâce au site de documentation du CNIP ainsi que sur l'informatique décisionnelle. Après cela nous avons suivi le document écrit par Julien Helbling décrivant comment opérer à un déploiement de lots SSIS (SQL Server Integration Services). Cela nous a permis de reproduire le système actuellement en fonctionnement au sein du CNIP. Nous avons mis à jour cette documentation sous la forme du document TD07_deploiement_SSIS.pdf, décrivant la marche à suivre pour déployer des lots SSIS sous SQL Server 2005. Ce document peut être consulté dans les annexes. Remarque : Chaque lot SSIS est associé à un fichier de configuration. L'emplacement de ce fichier est indiqué dans le code de chaque lot. Comme nous avons déplacé les fichiers de configuration dans un répertoire qui leur est dédié, il faut modifier manuellement leur emplacement dans chaque lot. Pour faciliter cette tâche, nous avons développé un programme java qui met à jour les chaînes de connexion. Il suffit juste de saisir l'emplacement du répertoire contenant les fichiers de configuration et le programme se charge de le remplacer dans tous les lots. Le code source de ce programme peut être consulté dans les annexes.



24/70


Etapes du déploiement du projet Ecureuil. Une fois le déploiement effectué, nous avons produit un document décrivant les différents lots utilisés dans le cadre du déploiement du projet Ecureuil ainsi que leur ordre d'enchainement. Nous avons également modifié la partie théorique du rapport de travail de diplôme de Julien Helbling afin qu'elle soit adaptée pour SQL Server 2005. Ces documents font également partie des annexes (TD07_description_lots et TD07_rapport_partieTheorique)



25/70


Base de données de production

ETL (Talend)

Base de données multidimensionnelle (entrepôt de données)

Yannick Perret

Interrogation de l'entrepôt de données

Serveur OLAP (Mondrian)

Cubes d'analyse OLAP

Fabien Airiau

Répartition du projet Ecureuil pour les travaux de diplômes de Fabien Airiau et de moi-même.

Après ces 3 semaines de travail en commun, chacun de nous s'est occupé de reproduire une partie du projet Ecureuil à l'aide d'outils open source. Je me suis chargé de construire l'entrepôt de données grâce aux outils ETL fournis par Talend alors que Fabien Airiau s'est occupé d'interroger cet entrepôt de données via des cubes OLAP produits avec Mondrian.

4.2. Création des tables dans PostgreSQL Le datawarehouse et la Staging Area vont être contenus dans un serveur PostgreSQL. Avant de commencer le travail d'extraction des données, il faut donc créer les tables de ces deux bases de données. Pour cela, j'ai repris les scripts de création des tables qui ont été réalisés pour SQL Server dans le cadre du travail de diplôme de Julien Helbling et je les ai adaptés pour PostgreSQL.



26/70


4.2.1.

Principales différences

•

Les crochets placés entre les noms de schémas, de tables, de champs et de type de champs ne doivent pas être mis dans les scripts pour PostgreSQL car la syntaxe ne le permet pas. Ils ne sont d'ailleurs pas obligatoires dans SQL Server 2005.

•

Le nom de la table est à chaque à fois préfixé du nom du schéma auquel appartient à cette table. Jusqu'à SQL Server 2000, les objets appartenaient aux utilisateurs. Depuis la version 2005, chaque objet appartient à un schéma de la base de données. Dans PostgreSQL, chaque objet fait également partie d'un schéma. Dans les deux serveurs, il est possible de préfixer le nom de l'objet par le nom du schéma sinon c'est le schéma courant qui est utilisé par défaut. Le schéma par défaut dans PostgreSQL (public) sera utilisé pour stocker les tables créées, ce qui évitera de préfixer le nom des objets.

•

Les types de données ne sont pas tous désignés de la même façon dans SQL Server et PostgreSQL. Il faut donc veiller à utiliser la bonne correspondance de type de données. Il y a trois types différents utilisés dans les scripts: numeric, varchar et datetime pour SQL Server. Les deux premiers sont identiques dans PostgreSQL. Par contre, le type datetime dans SQL Server (ex: 22.08.2007 11:00:00) n'est pas le même dans PostgreSQL. Il correspond au type timestamp.

•

Certains champs sont suivis de la clause COLLATE. Elle est appliquée à la définition de ces champs pour définir le classement. Cet attribut n'existe pas dans PostgreSQL et comme il n'est pas indispensable, je le supprimerai et ne mettrai pas d'équivalent.

•

La propriété IDENTITY dans la définition d'un champ va créer une colonne d'identité. Elle va permettre d'incrémenter le champ automatiquement. Ses deux arguments sont la première valeur et l'incrémentation entre chaque ligne. Pour incrémenter automatiquement un champ dans PostgreSQL, il faut créer une séquence et ensuite attribuer cette séquence au champ. Dans les propriétés de la séquence, il faut préciser la valeur de départ et l'incrémentation (1 étant la valeur par défaut).



27/70


4.2.1.1. Exemple: création de la table HISTO_Temps dans SQL Server 2005

4.2.1.2. Exemple: création de la table HISTO_Temps dans PostgreSQL



28/70


4.3. Création des procédures stockées Le datawarehouse doit obtenir des données "propres" de la Staging Area. Pour obtenir ces données, divers traitements sont effectués. Seulement certains de ces traitements ne peuvent se faire à l'aide de simples requêtes SQL. C'est pourquoi des procédures stockées avaient été créées en langage Transact-SQL sous SQL Server car elles offrent de plus grandes possibilités de traitement. Conformément à l'objectif du travail qui est d'effectuer les mêmes opérations que sous SQL Server, j'ai repris toutes ces procédures stockées pour les entreposer dans PostgreSQL. Il faut donc adapter celles-ci au langage PL/pgSQL qui est le langage de procédures de PostgreSQL. Le code de ces procédures se trouve en annexe. Pour avoir des commentaires sur le code, se référer au travail de Julien Helbling. •

Esnig_AlimenteHistoTempsIncremental: permet d'ajouter les nouveaux jours dans la table HISTO_Temps au même rythme que la table Calendriers de la base de production. Permet également de mettre à jour le champ EstJourTravail.

•

Esnig_InsertValuesIntoHistoTemps: permet d'insérer les valeurs dans la table HISTO_Temps en recevant en paramètre une date.

•

Esnig_UpdateDimApprenants: permet d'ajouter "Formation terminée" et "Formation en cours".

•

Esnig_InsertValuesIntoFactOccupationsFirstPart: permet de remplir la table FACT_Occupations

•

Esnig_InsertValuesIntoFactOccupationsSecondPart: permet de remplir la table FACT_Occupations

la

distinction

entre

4.4. Création de la vue esnig_dureeproductionfirstpart La vue esnig_dureeproductionfirstpart est utilisée lors de l'exécution de la procédure Esnig_InsertValuesIntoFactOccupationsSecondPart. Le code de la vue se trouve en annexe.



29/70


4.5. Connexions aux bases de données Pour créer une connexion à une base de données, il faut aller dans le Repository, développer le dossier Metadata et faire un clic droit sur Db Connections. Il faut ensuite sélectionner Create connection. • Première étape: il faut nommer la connexion. Il y a également la possibilité de remplir divers champs facultatifs (description, auteur, …). • Deuxième étape: il s'agit des paramètres de connexion. Il faut choisir le type de base de données à laquelle on veut se connecter, ensuite les champs à remplir diffèrent selon le choix de la base. • Troisième étape: après avoir rempli tous les champs demandés, il est possible de contrôler si la connexion est établie à l'aide du bouton Check.



30/70


4.5.1. Connexion à la base de données de production La connexion à la base de données de production est très simple à réaliser. Après avoir choisi le type Access dans la liste DB Type, il suffit juste d'indiquer le chemin du fichier .mdb contenant les données de la base de production. La chaîne de connexion est établie automatiquement.

Configuration de la connexion : base de données de production (Access)



31/70


4.5.2. Connexion à la base de données Staging Area La connexion à la base de données Staging Area nécessite un peu plus d'informations. Après avoir indiqué le type de base de données – en l'occurrence PostgreSQL – il faut indiquer tout d'abord son nom d'utilisateur et son mot de passe du serveur de base de données, puis l'endroit où est stocké le serveur et le port utilisé. Le nom de la base de données est renseigné à l'aide du champ Sid et il faut également préciser le schéma dans lequel les tables qui nous intéressent sont stockées. La chaîne de connexion est toujours établie automatiquement.

Configuration de la connexion : base de données Staging Area (PostgreSQL)

4.5.3. Connexion à la base de données datawarehouse Même démarche que pour la base de données Staging Area, sauf pour le nom de la base de données évidemment.



32/70


4.6. Schémas Les schémas sont utilisés lors de chaque opération effectuée sur une base de données et doivent correspondre à la structure des données qui sont traitées. Par exemple, lorsqu'on va chercher des tuples dans une base à l'aide d'une requête, la structure de la requête doit correspondre au schéma utilisé lors l'opération. Si on sélectionne trois champs dans une requête, le schéma doit également contenir trois champs du même type. Lorsque l'on a établi une connexion avec une base de données, il est possible de générer les schémas correspondants aux tables peuplant cette base. Il faut pour cela faire un clic droit dans la connexion souhaitée dans le dossier Metadata/Db Connections et sélectionner Retrieve Schema. Cela permet d'éviter de créer des schémas lors de chaque opération effectuée dans les bases de données.



33/70


Lors de l'utilisation de schémas générés automatiquement à partir des bases de données, il faut bien contrôler le type de données que Talend a appliqué aux champs (colonne Type) car ils ne correspondent pas toujours à ceux des bases de données (colonne DB Type) et cela peut créer des erreurs lors de l'exécution d'un travail. Il faut donc contrôler et modifier le type de champ dans la colonne Type au cas où ceux-ci ne concordent pas.

Exemple de schéma généré automatiquement : les champs entourés en rouge ne correspondent pas, ceux de la colonne Type doivent être modifiés



34/70


4.7. Création des Jobs Designs 4.7.1.

Stratégie

C’est donc à travers les Jobs Designs que l’on effectue le travail d’extraction, de transformation et de chargement des données dans Talend. L’objectif est de reproduire le même travail que celui effectué par les packages SSIS dans SQL Server 2005. Pour cela j’ai essayé de garder la même structure au niveau de l’enchaînement des lots et de conserver les mêmes noms.

4.7.2.

Jobs Designs

4.7.2.1.

Esnig_ExecuteAll

Esnig_ExecuteAll est le lot / Job qui se trouve en haut de la hiérarchie. C'est lui qui va lancer les autres lots / Jobs principaux qui eux-mêmes vont lancer d'autres lots / Jobs.

4.7.2.1.1. Dans SQL Server 2005

Esnig_ExecuteAll : sous SQL Server 2005

Ce lot n’effectue aucun travail spécifique dans SQL Server. Sa seule fonction est d’exécuter d’autres lots.



35/70


4.7.2.1.2. Dans Talend

Esnig_ExecuteAll : sous Talend Open Studio

Le Job Esnig_ExecuteAll de Talend a exactement la même fonction et la même structure que son collègue de SQL Server 2005 (sauf pour les deux derniers lots dans SQL Server qui concernent la construction des cubes). Son seul travail est d’exécuter d’autres Jobs Designs. Les deux dernières tâches concernent le vidage du cache de Mondrian. Mondrian utilise le cache serveur afin de stocker les données agrégées. Seulement Mondrian ne gère pas la mise à jour du cache. Il a donc fallu mettre en place une procédure permettant de vider et de reconstituer le cache afin d'offrir aux utilisateurs la possibilité de traiter des données actuelles. Une fois que les données ont été chargées dans le datawarehouse, les données agrégées sont également vidées et rechargées dans le cache. Pour plus d'informations sur ces deux tâches, se référer au rapport de Fabien Airiau.



36/70


4.7.2.2.

Esnig_UpdateArchivageBdProd

Le rôle d’Esnig_UpdateArchivageBdProd est d’archiver les tuples extraits de la base de données de production vers le datawarehouse. Les tuples qui doivent être archivés ont leur champ DateArchivage rempli avec la date du jour par un utilisateur autorisé du CNIP. La nuit suivante, lorsqu’Esnig_UpdateArchivageBdProd est exécuté, il va repérer ces tuples grâce au champ DateArchivage et les modifier. Le champ LuEtArchive est notamment noté à 1. Les tuples modifiés sont ensuite mis à jour dans la table HISTO correspondante de la Staging Area à l’aide du package / Job Esnig_LoadHistos. L’utilisateur du CNIP peut ensuite supprimer définitivement tous les tuples de la base de production dont le champ LuEtArchive vaut 1.


Esnig_UpdateArchivageBdProd : sous SQL Server 2005

Le lot Esnig_UpdateArchivageBdProd va directement effectuer ce travail pour chaque table de la base de production.



37/70



Esnig_UpdateArchivageBdProd : sous Talend Open Studio

Le Job va effectuer le même travail mais d’une manière légèrement différente pour des raisons pratiques, car il n’est pas possible de regrouper le travail pour une table dans une seule opération. Esnig_UpdateArchivageBdProd va lancer un Job pour chaque table de la base de production. Ces Jobs vont ensuite effectuer le travail pour la table correspondante.



38/70


4.7.2.2.2.1. Structure des Jobs Designs

Structure des Jobs exécutés par Esnig_UpdateArchivageBdProd : ex : Update_PersoPaquets

Détail de Transformation : ex : Update_PersoPaquets

Tous les Jobs lancés par Esnig_UpdateArchivageBdProd effectuent le même travail sur leur table respective et ont donc tous la même structure. Access_Find va effectuer une requête dans la table de la base de production concernée par le Job en sélectionnant les tuples dont le champ DateArchivage est égal à la date d'hier. Il envoie ces tuples à Transformation qui va transformer les données pour chaque tuple reçu. Les champs suivant sont modifiés : • LuEtArchive : marqué avec la valeur 1 • MOUSER : rempli avec la chaîne « DataWarehouse » • MODATE : marqué avec la date d’hier • MOCOUNT : incrémenté de 1 Tous les tuples modifiés sont ensuite envoyés à Access_Update qui va mettre à jour ceux-ci dans la table correspondante de la base de production. •

Requête d'Access_Find:



39/70


4.7.2.3.

Esnig_LoadHistos

Le rôle d’Esnig_LoadHistos est de mettre à jour les tables HISTO de la Staging Area. Pour cela il va parcourir les tuples de la base de production et repérer ceux qui ont été insérés ou modifiés depuis son dernier passage. Les tuples insérés le sont également et ceux modifiés sont mis à jour dans la table HISTO correspondante.


Esnig_LoadHistos : sous SQL Server 2005

Esnig_LoadHistos : détail de l’exécution

Pour chaque table HISTO de la Staging Area, le travail est effectué de la même manière. Seule la table HISTO_Temps travaille différemment. Celle-ci est mise à jour à travers l’exécution de la procédure stockée Esnig_AlimenteHistoTempsIncremental. Yannick Perret / 27.09.2007


40/70



Esnig_LoadHistos : sous Talend Open Studio

Le Job Esnig_LoadHistos va effectuer le même travail tout en étant structuré d’une manière légèrement différente. Il va lancer pour chaque table HISTO un job qui va effectuer le travail de mise à jour. Sauf pour la table HISTO_Temps qui est également mise à jour à travers la procédure stockée Esnig_AlimenteHistoTempsIncremental.



41/70



Structure des Jobs exécutés par Esnig_LoadHistos

Les jobs exécutés par Esnig_LoadHistos ont la structure suivante : Access_SelectAJDATE va sélectionner tous le tuples de la table de la base de production dont le champ AJDATE est égal à la date d'hier, c'est-à-à-dire les tuples insérés la veille. Il envoie ensuite les ceux-ci à Postgres_InsertNew qui va les insérer dans la table HISTO correspondante dans la Staging Area se trouvant sous PostgreSQL. Ensuite Access_SelectMODATE va sélectionner les tuples de la base de production dont le champ MODATE est égal à la date d'hier (les tuples modifiés la veille) et les envoyer à Postgres_UpdateModif qui va mettre à jour les tuples correspondants dans la table HISTO de la Staging Area. •

Requête d'Access_SelectAJDATE

•

Requête d'Access_SelectMODATE



42/70


4.7.2.4.

Esnig_LoadKeep

Le rôle d’Esnig_ExecuteLoadKeep est de gérer les suppressions de données dans les tables HISTO de la Staging Area. Pour cela, on s’appuie sur le fait qu’une table de la base de production et la table HISTO correspondante dans la Staging Area ont la même structure. Le même tuple aura donc la même clé primaire. On utilise donc une table KEEP, mise à jour quotidiennement, qui va contenir les clés primaires des tuples se trouvant dans la base de production. Ainsi un tuple d’une table HISTO dont la clé primaire ne se trouve pas dans la table KEEP correspondante doit être supprimé. Note : Les tables HISTO_PersoHoraires, HISTO_PersoModules, HISTO_Intervenants, HISTO_PersoModulesProductions et HISTO_Formations conservent des données archivées. Il faut donc tester le champ DateArchivage sur ces tables pour éviter de supprimer des données archivées.



43/70



Esnig_LoadKeep : sous SQL Server 2005

Le même travail en trois étapes est effectué pour chaque table. • On efface toutes les données de la table KEEP. • On repeuple la table KEEP en allant chercher les clés primaires de la table de la base de production. • On supprime les tuples de la table HISTO dont la clé primaire ne se trouve pas dans la table KEEP (et qui n’ont pas été archivé pour les tables conservant ce type de données)



44/70



Esnig_LoadKeep : sous Talend Open Studio

Le Job Esnig_LoadKeep est divisé en "sous-jobs" qui vont chacun effectuer le même travail pour toutes les tables. La division en "sous-jobs" permet d’avoir un peu plus de clarté dans la structure.



45/70



Structure des Jobs exécutés par Esnig_LoadKeep : Ex : LieuxDeFormations

Pour commencer Access_SelectPK_Histo va séléctionner toutes les clés primaires des tuples de la table de la base de production et va envoyer celles-ci à Postgres_InsertPK_InKeep qui va les insérer dans la table KEEP correspondante. La table KEEP est vidée au début de la tâche Postgres_InsertPK_InKeep. Ceci est réalisé en cochant l’option Clear data in table. Finalement, Postgres_DeleteHistoNoPK va exécuter la requête qui demande de supprimer les tuples de la table HISTO dont la clé primaire ne se trouve pas dans la table KEEP. •

Requête d'Access_SelectPK_Histo

•

Requête de Postgres_DeleteHistoNoPK



46/70


4.7.2.5.

Esnig_ExecuteLoadDims

Esnig_ExecuteLoadDims s'occupe de remplir les tables de dimensions de la Staging Area à partir des données des tables HISTO. Les données pour une table de dimensions proviennent souvent de plusieurs tables HISTO, elles sont donc récupérées par sous-requêtes.


Esnig_ExecuteLoadDims: sous SQL Server 2005

Le package en lui-même n'effectue aucun travail spécifique. Il s'occupe uniquement de lancer les lots pour chaque table de dimensions. Les lots d'Esnig_ExecuteLoadDims sont tous construits de la même manière. Une première tâche commence par effacer les valeurs actuelles de la table puis la deuxième insère les nouvelles données qu'elle aura été cherchée au moyen d'une requête. • Le lot ExecuteDIM_Apprenants effectue une tâche supplémentaire qui vérifie et met à jour l'état de la formation (terminée – en cours). Cette vérification se fait en exécutant la procédure stockée Esnig_UpdateDimAppprenants.



47/70



Esnig_ExecuteLoadDims : sous Talend Open Studio

Esnig_ExecuteLoadDims est construit exactement de la même manière que sous SQL Server 2005. Chaque table de dimensions sera traitée par son propre Job. 4.7.2.5.2.1. Structure des Jobs Designs

Structure des Jobs exécutés par Esnig_ExecuteLoadDims

Les Jobs exécutés par Esnig_ExecuteLoadDims sont structurés de la façon suivante: Postgres_SelectHISTO va séléctionner les tuples nécessaires à la table de dimensions (provenant parfois de plusieurs tables HISTO). Il va ensuite envoyer ces tuples à Postgres_InsertDIM qui va les insérer dans la table de dimensions correspondante. Celle-ci est vidée au début de la tâche Postgres_InsertDIM juste avant l’insertion des données à l’aide de l’option Clear data in table.



48/70


•

Requêtes de Postgres_SelectHISTO

Esnig_LoadDimDemandeursDeFormations

Esnig_LoadDimDomainesFormations

Esnig_LoadDimLieux

Esnig_LoadDimModules

Esnig_LoadDimPeriodesEnseignements

Esnig_LoadDimTemps



49/70


Structure du Job Esnig_LoadDimApprenants

Le Job Esnig_LoadDimApprenants est légèrement différent et possède deux tâches supplémentaires. La tâche Transformation a été rajoutée pour permettre la concaténation des champs Nom et Prenom à l'intérieur de la table de dimensions. La deuxième tâche additionnelle est Execute_Esnig_UpdateDimApprenants qui, comme dans SQL Server 2005, va vérifier et mettre à jour au moyen de la procédure stockée Esnig_UpdateDimApprenants, l'état de la formation d'un apprenant. •

Requête de Postgres_SelectHISTO



50/70


4.7.2.6.

Esnig_ExecuteLoadFacts

Le travail d'Esnig_ExecuteLoadFacts est de remplir les tables de faits à partir des tables HISTO.


Esnig_ExecuteLoadFacts: sous SQL Server 2005

Le package lance un lot par table de faits. Ce sont eux qui vont s'occuper de remplir les tables. Premièrement, les données actuelles des tables sont supprimées. Ensuite, les nouvelles données sont insérées dans les tables. Par une requête pour la table FACT_Absenteisme et au moyen des procédures stockées InsertValuesIntoFactOccupationsFirstPart et InsertValuesIntoFactOccupationsSecondPart pour la table FACT_Occupations. Le champ EstAbsent est ensuite mis à jour (de -1 à 1) dans la table FACT_Absenteisme pour permettre des calculs aisés de cumul de périodes d'absence. Dans la table FACT_Occupations, les tuples où le champ NbPersonnesPlanifiees est à 0 sont supprimés car cela signifie que l'atelier est fermé.


Esnig_ExecuteLoadFacts : sous Talend Open Studio

Le Job Esnig_ExecuteLoadFacts a la même structure que celui de SQL Server 2005.



51/70



Structure du Job Esnig_LoadFactAbsenteismes Esnig_LoadFactAbsenteismes fonctionne de la manière suivante: Postgres_SelectInHisto va rechercher les tuples (à partir de plusieurs tables HISTO) nécessaires à la table de faits et les envoyer à Postgres_InsertInFactAbsenteismes qui va les insérer dans la table de faits qui est vidée auparavant, l’option Clear data in table étant activée. Finalement, Posgres_UpdateEstAbsent met à jour le champ EstAbsent de -1 à 1 au moyen d'une requête. •

Requête de Postgres_SelectInHisto



52/70


•

Requête de Postgres_UpdateEstAbsent

Structure du Job Esnig_LoadFactOccupations

Esnig_LoadFactOccupations est construit différemment. La tâche Postgres_DeleteFactOccupations commence par vider la table de faits. Ensuite Execute_InsertValuesIntoFactOccupationsFirstPart et Execute_InsertValuesIntoFactOccupationsSecondPart vont exécuter les procédures stockées du même nom qui vont de la sélection et de l'insertion des données. Finalement, Postgres_DeleteNbPlanifZero va supprimer les tuples dont le champ NbPersonnesPlanifiees est à 0 au moyen d'une requête. •

Requête de Postgres_DeleteFactOccupations

•

Requête de Postgres_DeleteNbPlanifZero



53/70


4.7.2.7.

Esnig_LoadDWFromSA

Le rôle d’Esnig_LoadDWFromSA est de charger les données du datawarehouse – c’est-à-dire des tables de faits et de dimensions – à partir de la Staging Area.


Esnig_LoadDWFromSA : sous SQL Server 2005



54/70


Le package est divisé en deux phases. La première concerne le chargement des tables de dimensions, la deuxième le chargement des tables de faits. Pour toutes les tables, le même travail est effectué. Tout d’abord, les données de la table dans le datawarehouse sont supprimées. Ensuite, la table est chargée à partir de celle construite dans la Staging Area.


Esnig_LoadDWFromSA : sous Talend Open Studio

Le Job Esnig_LoadDWFromSA va effectuer le même travail quasiment de la même manière. Le Job va exécuter deux "sous-jobs", un qui va s’occuper des tables de dimensions et un autre qui va s’occuper des tables de faits. 4.7.2.7.2.1. Structure des Jobs Designs

Structure des Jobs exécutés par Esnig_LoadDWFromSA : chargement des tables de faits

Toutes les tables sont traitées de la même manière. PostgresSelect_NomTable_FromSA va sélectionner toutes les données de la table concernée dans la Staging Area et les envoyer à PostgresInsert_NomTable_InDW qui va insérer tous ces tuples dans la table du datawarehouse après avoir l’avoir vidée grâce à l’option Clear data in table.



55/70


• Requête de PostgresSelect_FACT_NomTable_FromSA

• Requêtes de PostgresSelect_DIM_NomTable_FromSA DIM_Lieux

DIM_Modules

DIM_Apprenants

DIM_DemandeursDeFormations

DIM_Temps

DIM_DomainesFormations

DIM_PeriodesEnseignements



56/70


4.7.3. Planification de l'exécution des Jobs Designs La vue Scheduler permet d’automatiser l’exécution d’un Job. Pour l’utiliser, il faut que CRONw soit installé et que le service cron soit démarré.

Open Scheduler : planification du Job Esnig_ExecuteAll

Pour créer une tâche, il faut cliquer sur la croix verte dans la vue Scheduler. Une fenêtre s’ouvre et permet de paramétrer la planification. Il faut ensuite choisir le job à exécuter, la fréquence ainsi que l’heure d’exécution. Une fois tous les champs remplis, le Scheduler va générer automatiquement la commande correspondante qui sera fournie au service cron.



57/70


4.8. Mise en commun des deux travaux de diplôme La dernière semaine, Fabien Airiau et moi-mêmes nous sommes assurés du bon fonctionnement des deux projets mis bout à bout. Il a principalement été question de la vérification de la structure de l'entrepôt de données et du format des données. Nous avons modifié ensuite toutes les chaînes de connexion qui pointaient sur l'entrepôt de données que Fabien Airiau avait dû construire par copie pour les faire pointer sur l'entrepôt de données construit et peuplé par moi-même grâce aux outils ETL de Talend, afin de s'assurer du bon fonctionnement de l'ensemble.



58/70


5. Conclusion Ce projet m'a permis de découvrir l'analyse multidimensionnelle, un sujet qui n'avait pas été vu lors des cours. J'ai pu m'apercevoir à quel point la mise en place d'un projet de datawarehouse était complexe et combien le travail d'analyse est grand. En ce qui concerne Talend Open Studio, l'outil permet de reproduire toutes les procédures mises en place dans SQL Server 2005. Le processus est identique et permet de construire un datawarehouse contenant des données "propres". Seulement, je me suis retrouvé confronté à d'énormes problèmes de performances dès qu'il faut effectuer des insertions, suppressions ou mises à jour d'un grand nombre de tuples dans une table. Cela concerne principalement toutes les tâches effectuées sur les tables liées à PersoHoraires et le chargement des tables de faits. Pourtant, j'ai essayé d'optimiser au mieux les requêtes le fait, par exemple, de vider et de repeupler une table de plus de 600'000 tuples prend un temps fou. Le fait que tous les outils, notamment la base de données PostgreSQL, soient stockés sur mon poste a peut-être joué un rôle et il serait bon d'effectuer à l'avenir de nouveau tests de performances. Si l'on peut résoudre ces problèmes de performances, on peut considérer que Talend est une alternative tout à fait envisageable à SQL Server 2005 au niveau du travail ETL.



59/70


6. Guides d'installation 6.1. Installation serveur PostgreSQL 6.1.1. • • •

Les fichiers relatifs à l'installation du serveur se trouvent à l'adresse suivante : o http://www.postgresql.org/ftp/binary/v8.2.4/win32/ Télécharger le fichier postgresql-8.2.3-1.zip Choisir un miroir pour le téléchargement

6.1.2. • • • • • •

• • •

Fichiers d'installation

Installation

Extraire tous les fichiers dans un répertoire temporaire Exécuter le fichier postgresql-8.2.msi Dans les options d'installation, installer tout sur le disque dur local sauf l'extension spatiale PostGIS, le PL/Java et les fichiers de développement Installer Postgres dans un autre répertoire que celui proposé par défaut (en raison des espaces présents dans le chemin) o par exemple dans C:\postgres824 Créer un compte de service qui permettra de démarrer le service Postgres o Définir un compte et un mot de passe Créer le compte superutilisateur qui permettra d'être administrateur du serveur Postgres o Définir un compte et un mot de passe et modifier le codage du serveur en UTF-8 Activer les langages de procédures. Le PL/pgsql est suffisant. Dans l'activation des modules de contribution, laisser les options par défaut. Lancer l'installation



60/70


6.2. Installation Talend Open Studio 6.2.1.

Prérequis

6.2.1.1.

Java

Pour que Talend Open Studio puisse fonctionner correctement, il faut qu'il y ait au minimum la version 1.5 de JVM (Java Virtual Machine) installée sur la machine. Pour contrôler la version actuelle de Java installée, lancer l'invite de commande et taper la commande java –version.

Résultat de la commande java -version



61/70


Si la version installée est antérieure à 1.5, aller dans Démarrer>Paramètres>Panneau de Configuration>Java>Mise à jour et cliquer dans Mettre à jour maintenant.

Mise à jour de Java



62/70


6.2.1.2.

Perl

Autre prérequis nécessaire à la bonne marche de Talend Open Studio: Perl. Celui-ci n'est pas installé par défaut sur les machines Windows. Vous pouvez télécharger Perl à l'adresse suivante: •

http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl

Télécharger l'exécutable correspondant à votre système d'exploitation. Une fois cette opération terminée, lancer l'exécutable et sauvegarder toute la distribution dans le dossier C:\Perl. Lorsque l'installation est terminée, contrôler qu'elle s'est déroulée correctement en lançant l'invite de commande et tapant perl –v qui indiquera la version de Perl installée sur votre machine.

Résultat de la commande perl -v

Si le résultat de la commande est identique à l'écran ci-dessus, cela signifie que l'installation de Perl s'est parfaitement déroulée.



63/70


6.2.2.

Installation

Les fichiers relatifs l'installation de Talend Open Studio se trouvent dans une archive à télécharger à l'adresse suivante: •

http://www.talend.com/download.php

Choisir la version et la plateforme (Windows ou Unix) désirées et démarrer le téléchargement. Une fois celui-ci terminé, il faut extraire les fichiers de l'archive. Lorsque cette opération est achevée, lancer l'exécutable TalendOpenStudio.exe. Après avoir accepté le contenu de la licence, le formulaire d'enregistrement s'affiche. Vous pouvez remplir ce formulaire pour recevoir des informations sur Talend Open Studio par e-mail. Cette étape est facultative.

Formulaire d'enregistrement



64/70


Ensuite, lors de la première utilisation, vous devez configurer les paramètres de connexion (locale ou distante) en cliquant sur le bouton marqué de trois points.

Choix de la connexion



65/70


Il faut remplir le champ User E-mail en saisissant une adresse e-mail valable. Cette adresse servira de login lors de la connexion. Remplir ensuite, si nécessaire, le champ User Password. Celui-ci ne doit pas être saisi lors d'une connexion locale. Cliquer sur OK.

Configuration de la connexion

Comme il s'agit de la première utilisation, il n'y a encore pas de projet existant dans liste. Il faut donc créer un projet en cliquant sur le bouton Create.



66/70


Il faut donner obligatoirement un nom au projet. Attention, celui-ci n'est pas sensible à la casse. Il est possible de donner une description du projet mais cela n'est pas requis. Choisir ensuite le langage de génération du code (Perl ou Java). Lorsque ces informations ont été correctement saisies, cliquez sur le bouton Finish.

Création d'un projet



67/70


Vous pouvez maintenant vous connecter à Talend Open Studio en cliquant sur OK.

Connexion à Talend Open Studio



68/70


6.3. Installation CRONw CRONw doit être installé pour utiliser le planificateur de Jobs (Scheduler). Avant de commencer l’installation de CRONw, il faut contrôler qu’il ait au minimum la version 5.8 de Perl installée sur la machine. Pour cela il suffit de taper la commande perl –v dans l’invite de commande. Si ce n’est pas le cas, il faut procéder à l’installation de Perl (voir le point 6.2.1.2.). L’archive, contenant les fichiers relatifs à l’installation, se trouve à l’adresse suivante : http://sourceforge.net/project/showfiles.php?group_id=87160&package_id=106736 • • • • •

Extraire les fichiers de l’archive (va créer le dossier CRONw). Ouvrir l’invite de commande et se placer dans le dossier CRONw. Installer les modules Perl complémentaires en tapant la commande perl installer.pl Taper la commande perl cronHelper.pl --install. Démarrer le service cron avec la commande NET START CRON.



69/70


6.4. Bibliographie • •

Travail de diplôme 2005 de Julien Helbling, "DataWarehouse et analyse multidimensionnelle" Site de documentation du CNIP

• • • • • • • • •

http://www.talend.com/ http://www.postgresql.org/ http://technet.microsoft.com/ http://www.enhydra.org/ http://www.cloveretl.org/ http://www.ketl.org/ http://www.jasperforge.org/ http://cronw.sourceforge.net/ http://fr.wikipedia.org/



70/70

ETL Talend Rapport

Recommend Documents