Rapport de stage de fin d’études

Stagiaire développement décisionnel au sein de BIPP Consulting

Responsable BIPP Consulting: Laurent-Xavier Gusse Tuteur UCBL: Mohand-Said Hacid

Etudiant: Mohamed Rouissi

27/08/2012 BIPP Consulting

Mohamed Rouissi

Page 2 sur 34

Remerciement :

Ce projet de fin d’études s’est déroulé au sein de l’entreprise BIPP Consulting dirigé par Mr Laurent-

Xavier GUSSE.

Je tiens à adresser mes remerciements aux membres de la société que j’ai pu côtoyer durant la

période de mon stage et qui ont su rendre mon travail agréable.

Plus particulièrement, je tiens à remercier Mr Laurent-Xavier GUSSE et Mr Mohand-Said HACID qui

m’ont co-encadré durant ce stage et qui m’ont apporté leur aide ainsi que des remarques précieuses

qui ont permis de faire aboutir ce travail.

J’exprime également mes vifs remerciements à mon enseignant Mr Fabien DUCHATEAU, pour

l’honneur qu’il m’a fait en présidant mon jury de mémoire de fin d’études.

Résumé :

En tant que stagiaire, j’ai eu l’occasion de participer à des projets de grande envergure en

développement spécifique SIAD (Système d’Information d’Aide à la Décision) dans différents

domaines d’activité tels que la pharmaceutique et le pneumatique.

Ce rapport présente donc l’entreprise d’accueil BIPP Consulting en précisant ses secteurs d’activité

dans sa spécialité qui est le pilotage de la performance. Durant le stage effectué au sein de cette

entreprise, j’ai travaillé sur la phase d’intégration de données dans les systèmes décisionnels en

utilisant l’ETL Talend dans sa version gratuite aussi bien que la version entreprise et qui seront

présentées en détail dans ce rapport ainsi que d’autres outils logiciels tels que SGBD (Oracle 11g,

MySql 5), SAP Business Object, SVN, Mantis, etc. Ces derniers ont permis de bien aboutir le travail

pendant les missions 1 et 2 de ce stage. Un exemple d’un traitement Talend de la première mission

sera présenté tout en indiquant les choix techniques (ex : utilisation de l’ODS, ELT, routines, etc.)

ainsi que les solutions retenues pour gérer les problèmes rencontrés.

Page 3 sur 34

Table des matières I. Introduction: .................................................................................................................................... 5

II. Contexte de stage : .......................................................................................................................... 6

III. Description de la société d’accueil : ............................................................................................ 7

IV. Environnement technique : ......................................................................................................... 8

III.1. Architecture de l’environnement technique : ......................................................................... 8

III.2.1 SVN : .............................................................................................................................. 10

III.2.3 SGBD .............................................................................................................................. 10

III.3.1 Qu’est-ce qu’un ETL ? .................................................................................................... 11

III.3.2 En quoi cela peut-il être utile pour une entreprise? ..................................................... 12

III.3.3 Pourquoi utiliser un ETL au lieu de coder dans le langage de son choix? ..................... 12

III.3.4 Choix de la solution Talend: .......................................................................................... 13

V. Missions effectuées : ..................................................................................................................... 15

IV.1 Mission 1 ............................................................................................................................... 15

V.1.2 Domaine d’activité : ...................................................................................................... 15

V.1.3 Déroulement de travail : ............................................................................................... 15

V.1.4 Traitements effectués et volumétrie des données : ..................................................... 16

V.1.5 Développement générique et conventions pratiques :................................................. 16

V.1.6 Réalisation de la documentation : ................................................................................. 16

V.1.7 Problèmes rencontrés : ................................................................................................. 17

V.1.8 Conclusion : ................................................................................................................... 18

IV.2 Mission 2 ............................................................................................................................... 19

IV.2.1 Domaine d’activité : ...................................................................................................... 19

IV.2.2 Déroulement de travail : ............................................................................................... 19

IV.2 .3 Optimisation des traitements :...................................................................................... 19

IV.2.4 Outils de travail : ........................................................................................................... 20

IV.2.5 Formation effectuée: ..................................................................................................... 20

IV.2.6 Problèmes rencontrés : ................................................................................................. 20

IV.2.7 Rédaction de la documentation : ........................................................................................ 21

IV.2.8 Conclusion : ................................................................................................................... 21

IV.3 Exemple détaillé : .................................................................................................................. 22

IV.3.1 Flux en entrée : .............................................................................................................. 22

IV.3.2 Les données source : ..................................................................................................... 22

IV.3.3 Description du job : ....................................................................................................... 22

Page 4 sur 34

IV.3.4 Gestion des rejets : ........................................................................................................ 24

IV.3.5 Utilisation d’une table temporaire (ODS) : .................................................................... 25

IV.3.6 Gestion des annule et remplace : .................................................................................. 28

IV.3.7 Alimentation des tables finales : ................................................................................... 28

IV.3.8 Variables de contexte utilisées : .................................................................................... 30

IV.3.9 Utilisation des routines Talend: ..................................................................................... 31

VI. Conclusion : ............................................................................................................................... 32

Page 5 sur 34

I. Introduction:

Afin de valider mon cursus universitaire et plus précisément mon master 2 Technologies de

l’information et web parcours professionnel, la réalisation d’un travail pratique d’au moins 5 mois est

indispensable, et c’est dans ce cadre que s’intègre mon stage réalisé au sein de la société BIPP

Consulting. Le travail relève essentiellement d’une application pratique des notions théoriques et

compétences acquises durant la formation universitaire.

Passionné par l’informatique décisionnelle, j’ai naturellement orienté ma recherche du stage

vers les sociétés spécialisées dans ce domaine. Et c’est au sein de la société BIPP Consulting que j’ai

eu l’occasion de réaliser ce stage et de découvrir le domaine de BI1 (Business Intelligence) ainsi que

ses activités d’un point de vue professionnel.

Les objectifs de ce stage étaient les suivants:

- Découvrir le monde professionnel

- L’application pratique des connaissances théoriques.

- Avoir une expérience valorisante dans le domaine de BI.

- Apprendre à travailler en équipe.

J’ai donc intégré une équipe de 6 personnes en tant que développeur, en charge de missions

suivantes :

- Acquérir des compétences en intégration des données sous l’ETL2 Talend.

- Participation à des projets décisionnels en interne ainsi qu’en externe (chez les clients).

- Rédaction de la documentation technique sur les activités traitées.

Dans ce document nous décrirons le contexte de stage dans lequel nous présenterons

l’informatique décisionnelle ainsi que la phase d’intégration de données. Ensuite, nous donnerons

une description globale de la société d’accueil BIPP Consulting et de ses activités. Puis, nous

détaillerons l’environnement technique et logiciel de travail et dans lesquels le développement a été

fait tout le long de stage. Après, nous aborderons les missions effectuées, et notamment nos

différentes réalisations avec les problèmes rencontrés et le savoir-faire que nous avons pu acquérir.

De plus, un exemple d’une réalisation faite pendant une des missions sera présenté en détail. Enfin,

nous terminerons par une conclusion dans laquelle nous mettrons en relief les acquis à l’issue de ce

stage.

1 Définition disponible dans le glossaire.

2 Définition disponible dans le glossaire.

Page 6 sur 34

II. Contexte de stage :

Dans le cadre de mon stage, je me suis intéressé à l’informatique décisionnelle ou BI (Business

Intelligence) qui est de plus en plus répandue sur le marché et qui représente l’une des spécialités de

l’informatique en forte croissance de nos jours. Ce fait s’explique par les applications importantes du

BI dans de nombreux domaines.

L’informatique décisionnelle est la science informatique qui permet aux responsables de la stratégie

d’une entreprise d’avoir une vue d’ensemble de leurs activités et de décider la stratégie dans le

moyen et le long terme. Elle consiste à collecter, intégrer et restituer les données matérielles ou

immatérielles d’une entreprise. Un système d’information décisionnel utilise en règle générale un

entrepôt de données (ou Data Warehouse3) pour stocker des données transverses provenant de

plusieurs sources hétérogènes.

Un projet décisionnel est généralement composé de 3 phases principales :

La phase de collecte qui consiste à chercher et collecter les données dans des sources

hétérogènes sous différents formats

La phase d’intégration qui à son tour permet d’extraire les données des sources et les insérer

après transformation dans l’entrepôt de données.

La phase de restitution de données qui permet d’exploiter les données du Data Warehouse

en offrant la possibilité de faire du reporting, des requêtes ainsi que de l’analyse

OLAP4(Online Analytical Processing) sur les données.

Dans le stage réalisé, j’ai travaillé sur la phase d’intégration des données, fonction permise par les

outils d’Extraction/Transformation/Loading (ETL). Dans notre cas nous avons utilisé l’outil Talend.

L’intégration est un prétraitement ayant pour but de faciliter l’accès aux données centralisées, aux

outils d'analyse et de restitution pour la prise de décision. Ainsi, l'intégration consiste à concentrer

les données collectées dans un espace unifié, dont le socle informatique essentiel est l'entrepôt de

données. Ce dernier est l’élément central du dispositif dans le sens où il permet aux applications

d’aide à la décision (par exemple l’analyse OLAP) de bénéficier d'une source d'information homogène,

commune et fiable. Cette centralisation permet surtout de s’abstraire de la diversité des sources de

données.

3 Définition disponible dans le glossaire.

4 Définition disponible dans le glossaire.

Page 7 sur 34

III. Description de la société d’accueil :

BIPP Consulting est une société de conseil et de service, spécialisée dans le domaine du pilotage de

la performance. Elle intervient sur l'ensemble des problématiques métiers (Contrôle gestion, vente,

RH, logistique...) et accompagne ses clients dans la mise en œuvre de leur solution de reporting,

pilotage, analyse, simulation et élaboration budgétaire.5

Figure 1 : Pilotage Performance - Elaboration budgétaire - Gestion de la relation Client (CRM) - Organisation Performance SI

Les services de pilotage de la performance offerts par BIPP Consulting permettent aux entreprises de

piloter leurs activités avec des indicateurs pertinents pour réussir la mise en œuvre de leur stratégie.

BIPP Consulting est présente sur Lyon et intervient sur le quart Sud Est de la France. Elle est

partenaire intégrateur des principales solutions décisionnelles sur le marché : QlikView, Cegid,

blueWay…

5 http://www.bipp-consulting.fr/index.php?option=com_content&view=article&id=26&Itemid=57

Pilotage Performance & Elaboration budgétaire

CRM

Organisation Performance du SI

Page 8 sur 34

BIPP Consulting se positionne comme le partenaire capable d'assister les directions fonctionnelles et

informatiques dans la définition, la refonte du processus de gestion opérationnelle et dans la réussite

de leur projet de pilotage de la performance.

À l’aide de sa forte expertise fonctionnelle et technologique, BIPP Consulting offre des services en

parfaite adéquation avec les attentes et les contraintes des principaux clients représentés par les

PME et Grands Comptes.

Parmi les attentes des clients assurées par BIPP Consulting on peut citer:

- Amélioration du processus décisionnel de la société en offrant des systèmes performants

qui aident à la prise de décision.

- Génération des rapports précis sur les différentes activités des sociétés clientes.

- Amélioration des relations avec les clients

- Augmentation des revenus

Après avoir fait une présentation globale de la société d’accueil BIPP Consulting, je vais parler dans le

chapitre suivant de l’environnement technique de travail mis en place dans la société et dans lequel

le travail était réalisé.

IV. Environnement technique : Dans ce chapitre, on présente la composition et l’architecture de l’environnement technique de

travail, ainsi qu’une description des logiciels utilisés tout le long de mon stage.

III.1. Architecture de l’environnement technique :

Avant de commencer un projet informatique il est nécessaire de définir l’environnement de travail.

Pour les projets dans lesquels je suis intervenu le long de mon stage, le travail a été réalisé sur trois

environnements différents à savoir, l’environnement de développement (DEV), de pré production

(PREPROD) et de production (PROD).

L’environnement de développement: C’est un serveur Windows, sur lequel sont effectués

les développements et les premiers tests sur une base de test. Il n’est accessible que par les

développeurs au sein de l’entreprise. L’avantage avec ce type de développement est que le

projet reste localisé, sur un endroit unique ce qui permet l’accessibilité et la sécurité des

données dans le cas d’une panne matérielle.

L’environnement de pré-production: C’est un serveur distant qui stocke les premières

livraisons des versions du projet ainsi qu’une base de données de qualifications.

L’environnement de production: C’est un serveur distant dans lequel seront livrées les

versions finales des jobs, il est accessible par le client.

La figure suivante présente l’architecture de l’environnement de travail :

Page 9 sur 34

Figure 2 : Architecture de l'environnement de travail

Il est possible de définir plus d’environnement, suivant les besoins, comme par exemple un

environnement de performance (PERF) où serait testé le projet avec un maximum de données pour

vérifier la montée en charge.

développeur

développeur

développeur

Serveur de code

checkIn/checkOut

commit

Environnement de développement

Intégration continue ou nocturneDéploiements

Développement des premières versions et réalisation des tests

Déploiements

Réalisation des tests sur une base de qualification dans un environnement le plus

similaire possible à celui du client

Mise en production

Livraison des versions finales, cet environnement est accessible par le client

Environnement de pré production

Environnement de production

Client

Testeurs

Testeurs

Testeurs

Livraison

Commit: sauvegarder les changements sur le projet, tout le monde peut désormais voir les

modifications réalisées

Page 10 sur 34

III.2 Technologies logicielles utilisées : Parmi les logiciels utilisés pendant le stage :

III.2.1 SVN :

Nous avons utilisé SVN (SubVersioN) comme système de gestion de versions (versionning) pour la

gestion de versions centralisée. Cela permet de travailler à plusieurs sur un même code sans souci de

perte de code si un même fichier est modifié par plusieurs personnes en même temps.

Le développement s’effectue dans le dossier « trunk ».

À chaque contribution, les modifications effectuées sont répercutées sur le trunk tout en traçant les

modifications effectuées par rapport à la version précédente. Il est ainsi possible de revenir à tout

moment à une version antérieure du programme car à chaque contribution sur le serveur centralisé

est associé un numéro de version SVN.

III.2.2 Mantis

Mantis est un système de suivi de bug open source sous licence GPL (GNU General Public License). Il

permet d’enregistrer tout dysfonctionnement de l’application, qu’il soit d’origine fonctionnelle ou

technique, que ce soit un problème graphique ou une simple coquille.

Les tickets créés dans Mantis sont par la suite affectés à des développeurs pour procéder à la

détection de l’origine du dysfonctionnement et à la mise en œuvre de corrections nécessaires. L’état

du ticket évolue alors progressivement d’un état « nouveau » à un état « fermé » en passant par

exemple par les états « affecté », « résolu » et « livré».

Mantis permet aussi d’obtenir automatiquement un « changelog » (liste des bugs corrigés par

version du logiciel) ainsi que des statistiques qui peuvent concerner le nombre de bugs soumis ou

corrigés par utilisateur, temps moyen de résolution des bugs, ou l’efficacité de la résolution des bugs

(les bugs peuvent être rouverts si la correction est erronée).

III.2.3 SGBD

a) Oracle 11g :

C’est l’un des deux SGBD utilisés pendant mon stage. C’est un SGBDR très puissant utilisé pour

stocker et gérer les données de l’entrepôt de données dans le système d’information décisionnel. Il

propose aux professionnels de l’informatique des outils de base permettant de fournir efficacement

un volume important d’informations avec une meilleure qualité de service.

b) MySQL 5 :

Un SGBD open source utilisé pour créer et gérer des bases de données dans le système d’information

décisionnel.

Page 11 sur 34

Il est devenu l’un des SGBD open source le plus populaire en raison de ses performances, de sa

fiabilité et de sa simplicité d’utilisation6.

III.3 Plateforme ETL :

III.3.1 Qu’est-ce qu’un ETL ?

ETL, est l’acronyme d’Extract, Transform, Load:

Extract : extraire les données de multiples sources de données qui peuvent être hétérogènes (Base

de données, CSV, XLS, ERP, web service …)

Transform : transformer les données provenant des sources (ex : modifier le format de la date).

Load : charger les données dans n’importe quel format. (Base de données

Oracle/MySQL/PostgreSQL/…, Fichier Excel/CSV/…)

Figure 3 : Schéma d’un ETL, et de son fonctionnement

6 http://www.mysql.fr/why-mysql/white-papers/

Page 12 sur 34

III.3.2 En quoi cela peut-il être utile pour une entreprise?

L’utilisation des traitements ETL dans une entreprise peut s’avérer importante, en raison même de la multitude des besoins. Des exemples d’utilisation sont :

Récupération des données sur un site internet de façon automatisée et leur insertion dans une base de données.

Centralisation et consolidation des données en éliminant celles qui sont invalides.

Alimentation d’une base de données ou d’un entrepôt de données d’un système d’information décisionnel par des données qui proviennent de sources hétérogènes.

Élimination des erreurs provenant des sources de données et nettoyage de ces dernières à l’aide d’un système automatisé.

Synchronisation des données avec d’autres sources.

Alimentation d’une base de données d’analyses OLAP pour une utilisation décisionnelle.

III.3.3 Pourquoi utiliser un ETL au lieu de coder dans le langage de son choix?

Le codage dans le langage de son choix semble être une solution intéressante, car elle

permet de rester au plus près des spécificités métiers des donnés à traiter, tout en

s’affranchissant des contraintes liées à l’achat et l’utilisation d’un ETL propriétaire.

Malheureusement on se rend vite compte sur un gros projet que les coûts de débogage et

surtout de maintenance sont beaucoup plus importants qu’un traitement fait sous ETL.

Comme tout bon programmeur le sait, inutile de réinventer la roue! L’ETL offre une panoplie

de composants remplaçant de nombreuses lignes de code.

Exemple de composants Talend:

- Les composants de connexion à une base de données (tOracleConnection,

tMysqlConnection...)

- Les composants de mappage tMap qui offrent la possibilité de diriger les données

d’une ou plusieurs sources vers une ou plusieurs sorties. Il permet aussi de réaliser

les jointures.

- Les composants de lecture et d’écriture d’un fichier. Etc.

L’ETL donne une vision graphique du job (un traitement est appelé job sous Talend) et permet ainsi en un coup d’œil de comprendre le but du traitement ainsi que de repérer l’endroit où appliquer une modification quelconque si le traitement respecte bien les conventions de développement ETL. Voici quelques conventions sur les bonnes pratiques de développement sous l’ETL Talend:

Quelques conventions :

- Les lignes d’un traitement vont de gauche à droite (horizontal).

Page 13 sur 34

- Tous les composants doivent être nommés.

- Les composants d’entrée ou de sortie d’une base de données (ex : tOracleInput,

tOracleOutput) prennent le nom de la table correspondante.

- Les liaisons entre les blocs du type OnSubjobOK ou OnComponentOK vont de haut en bas. Etc.

L’utilisation d’un ETL permet d’avoir un gain de temps énorme et c’est pour cela que les grands du marché ont adopté ces solutions.

III.3.4 Choix de la solution Talend:

Talend est une plateforme d’intégration de données puissante offrant de bonnes performances sur le

marché des ETL.

Talend propose une suite logicielle écrite en Java permettant de bien gérer l’intégration de données.

Les logiciels proposés par Talend:

Talend Open Studio (outil de base)

Talend Integration Suite (fonctionnalités plus avancées que TOS, travail collaboratif, etc.)

Talend On Demand (Intégration de données en mode Saas)

Talend Open Profiler (fonctionnalités avancées pour l’analyse et le profilage de données)

Talend Data Quality (facilite le travail de nettoyage des données : doublons, suppression de données erronées)

Pour les versions utilisées au développement pendant le stage sont :

a) TIS (Talend Integration Suite):

C’est la version entreprise de l’ETL Talend, Studio enrichi fonctionnellement

Gestion des environnements et des déploiements

Référentiel partagé

Page 14 sur 34

Supervision

Version avancée MDx et RTx

Module qualité de données

Open Profiler : représentation en amont, indicateurs

Data Quality: Correction, nettoyage, enrichissement, rapport

b) TOS (Talend Open Studio):

C’est une version gratuite très complète qui permet aux entreprises ne nécessitant que très peu de

traitements de les développer sur la version gratuite.

Page 15 sur 34

V. Missions effectuées :

IV.1 Mission 1

Après avoir acquis quelques compétences sur l’ETL Talend chez la société d’accueil, je suis parti en

une mission chez un client qui a duré 2 mois. Dans cette mission j’ai réalisé un projet d’intégration de

données dans un entrepôt de données MySql au sein d’un gros projet décisionnel.

V.1.2 Domaine d’activité :

La société cliente travaille pour le compte d’un grand producteur des produits pneumatiques.

V.1.3 Déroulement de travail :

J’ai réalisé une première réunion avec le chef de projet, un administrateur système et développeur

SI, dans laquelle ils m’ont fait une description générale de projet à savoir, le type des données à

intégrer, le projet dans lequel s’intègre le travail, les conventions de développement et une vue

globale du modèle de données (schéma conceptuel, contraintes …).

Vu l’absence d’un document de spécification détaillé ou d’un cahier des charges qui aurait pu

faciliter le développement des jobs d’intégration, j’ai été amené à rédiger un document de

spécification qui précise les contrôles de chargement ainsi que les actions à faire dans chaque cas de

test. Ce document a été transmis au maître d’ouvrage pour qu’il puisse le valider.

Durant mon intervention dans le projet, j’ai fait des réunions hebdomadaires avec le client (Lundi de

chaque semaine) durant lesquelles on a mis le point sur l’avancement de travail et ce qu’il reste à

faire, ainsi que les éventuelles évolutions des données telles que : la modification de la structure,

l’ajout d’un fichier, l’ajout d’une contrainte sur les données etc.

Après avoir reçu la validation du document de spécification de la part du client, j’ai entamé le

développement des jobs d’intégration des flux sources par la création du job de paramétrage de la

base de données. Voici un petit descriptif de ce job :

Flux en entrée : Fichier Excel (CONTEXT_ALL_ALL_ALL_20120605.xls)

Description :

Ce job permet d’alimenter les tables de paramétrage dans la base de données, il est constitué de

plusieurs blocs.

Chaque bloc charge une table à partir d’une feuille du fichier Excel en entrée.

Contrôle du chargement :

- Contrôle sur le type des données (Date valide, type numérique, nom du flux valide…)

- Contrôle sur les champs nuls.

- Rejet des lignes qui contiennent des champs non nullable qui sont nuls à savoir les clefs

primaires ou étrangères.

- Alimentation de la table de rejet t_rejected_context dans le cas d’un test invalide

Page 16 sur 34

Figure 4 Bloc d'alimentation de la table t_market_zone

Afin de faciliter l’analyse des rejets et en plus des données de la ligne, on stocke aussi un code

d’erreur et un message d’erreur significatif, qui seront affichés sur des rapports pour l’utilisateur final.

Connexion à la base de données :

Deux connexions à la base de données sont utilisées, une pour la table de rejet et l’autre pour les

autres tables. Ce mécanisme nous a permis de décider le rejet ou non du fichier à la fin du

chargement.

V.1.4 Traitements effectués et volumétrie des données :

Le projet réalisé contient trois grandes parties, à savoir :

- Intégration des flux historiques

- Intégration des flux non historique

- Documentation technique du travail

Au total le nombre de jobs Talend réalisé est 17, et le nombre de lignes par fichier a atteint des

millions de lignes dans quelques flux historiques qui contiennent des données s’étalant sur 4 ans ou

plus.

V.1.5 Développement générique et conventions pratiques :

Afin d’assurer la généricité des jobs et une éventuelle exécution sur différentes plates-formes

(Windows, Unix, Mac OS), j’ai eu recours à l’utilisation des traitements contextuels avec l’utilisation

des variables de contexte qui seront chargées directement à partir des fichiers texte.

Par ailleurs, le respect des conventions et des bonnes pratiques de développement sous l’ETL Talend

a permis d’avoir des jobs clairs et lisibles qui offrent la possibilité de comprendre en un coup d’œil le

but du traitement ainsi de repérer l’endroit où appliquer la modification.

V.1.6 Réalisation de la documentation :

Comme dans n’importe quel projet informatique, la documentation est indispensable puisqu’elle

permet de comprendre le travail réalisé avec plus de détails, et aide aussi les autres intervenants sur

le projet à suivre le travail ou l’améliorer dans le cas d’un besoin particulier.

Page 17 sur 34

En se basant sur des exemples de documentation déjà faites, j’ai livré à la fin de mon intervention sur

le projet un document décrivant les traitements réalisés en détail et en incluant des exemples

d’utilisation de chaque job.

V.1.7 Problèmes rencontrés :

Parmi les problèmes rencontrés durant le travail dans la première mission :

Lors de développement des jobs, il n’y avait pas suffisamment de contrôle sur les données

source fournies par le client, ce qui a augmenté énormément la charge de contrôle réalisé

par les jobs, et a donné un taux de rejet énorme dans chaque flux.

Résultats inattendus

Une perte de temps considérable

Les flux en entrée ne sont pas structurés et contiennent des données hétérogènes même s’il

s’agissait du même type de flux, et cela dû au fait que les fichiers proviennent directement

du client sans être mis sous le contrôle du responsable.

En plus, au début de mon intervention je n’ai pas suivi une bonne méthodologie de travail, c'est-à-

dire qu’après des jours de travail je n’ai pas mis au courant le responsable du projet sur l’état de la

base de données (Lignes intégrées, lignes rejetées, taux d’intégration…).

Résultat inattendu au niveau du nombre de lignes intégrées.

Travail intensif pour récupérer le retard.

Remonté du problème au responsable.

Export régulier de la base de données à la fin de chaque modification pour éviter « l’effet

Tunnel », ce qui a provoqué une pression importante par le client.

L’autre élément qui m’a posé quelques problèmes est la mise en place tardive des serveurs

de développement. Parce qu’il faut signaler que j’ai commencé le travail en local sur ma

machine, chose qui m’a empêché d’effectuer des tests sur des gros volumes de données.

Tests insuffisants

Plantage de la machine qu’elle n’a pas suffisamment de mémoire vive.

Non-centralisation du projet et le risque de perte des versions.

Modifications importantes sur les données source et la structure des flux par le client qui ont

engendré des impacts remarquables sur les jobs d’intégration.

Maintenance couteuse

Page 18 sur 34

Perte du temps remarquable

V.1.8 Conclusion :

La première mission était un vrai lancement dans l’environnement professionnel pendant laquelle j’ai

amélioré mes capacités en matière de relationnel avec le client puisque j’étais en contact direct avec

lui dans les réunions ou par e-mail.

Après avoir fini ma mission, je suis resté à disposition du client afin de maintenir les éventuels bugs

identifiés lors de la phase de test.

Page 19 sur 34

IV.2 Mission 2

La deuxième mission était une intervention sur un projet dans la société d’accueil BIPP Consulting.

Ma tâche dans le projet était la réalisation des traitements d’intégration des données sous l’ETL

Talend la version entreprise TIS dans un entrepôt de données Oracle 11g.

IV.2.1 Domaine d’activité :

Le projet était la réalisation d’un système d’information décisionnel pour le compte d’un client dont

le domaine d’activité est la pharmaceutique.

IV.2.2 Déroulement de travail :

J’ai réalisé une réunion avec l’équipe de projet, pendant laquelle on m’a expliqué le contexte du

projet, en plus j’ai appris quelques connaissances sur l’environnement de travail et l’architecture du

système en cours de construction.

Ensuite, j’ai lu des documentations sur les traitements ETL d’intégration de données déjà réalisés

pour que je puisse comprendre la tâche qui m’a été accordée afin de l’aborder correctement.

Il s’agit d’un projet dont la réalisation est en interne dans une équipe qui contient des experts Talend,

ce qui était très bénéfique pour moi en termes de support technique. Par ailleurs, le travail se

déroulait suivant une méthode Agile.

Travail collaboratif : davantage l’interaction avec les personnes que les processus et les

outils.

Réunions régulières avec le client : davantage la collaboration avec le client.

Satisfaction : le client est mis au centre de la démarche et les personnes impliquées sur le

projet visent la satisfaction réelle du besoin.

Anticipation : développement souple qui anticipe les éventuels changements des besoins.

En plus, j’ai fait des réunions régulières avec le chef de projet après chaque avancement pour valider

ce qui a été fait, analyser les problèmes rencontrés et discuter la prochaine tâche à réaliser.

IV.2 .3 Optimisation des traitements :

Etant donnée la grande masse de données en entrée qui a atteint des centaines de millions de lignes,

l’optimisation des traitements était indispensable pour réduire le temps d’exécution.

Parmi les actions réalisées dans ce cadre est :

- Utilisation du principe de l’ODS (Operational Data Store) qui fait office de structure

intermédiaire destinée à stocker les données issues des systèmes de production

opérationnelle. Ce sont en quelque sorte des zones de préparation avant l’intégration des

Page 20 sur 34

données dans l’entrepôt de données: données qualifiées, premier niveau de filtrage et

d’agrégat.

- Utilisation du traitement ELT (Extract Load Transform) qui n’utilise pas la JVM au moment de

l’exécution mais utilise les capacités de traitement des bases de données qu’il exploite.

Autrement dit, les données sont traitées par la base de données et non plus par Talend et

donc Java ce qui peut améliorer les performances lors de gros traitement.

IV.2.4 Outils de travail :

Le développement était centralisé dans un serveur de développement qui avait des bonnes capacités

et qui servait à la réalisation des tests sur des gros volumes de données. Et en ce qui concerne les

outils de travail, l’utilisation de la version entreprise TIS de Talend m’a offert plus de fonctionnalités

qui m’ont permis d’optimiser de plus en plus les traitements tels que, l’utilisation des Joblets et la

supervision des jobs, chose n’est pas offerte dans la version gratuite TOS.

Aussi, l’utilisation de la gestion des versions des jobs est gérée par le gestionnaire de version SVN qui

nous a permis d’avoir un historique de versions ainsi qu’un accès simultané sur un même traitement

par plusieurs développeurs.

Il faut noter que dans un travail collaboratif, la mise en place d’un gestionnaire d’erreur est

indispensable, dans ce cadre, l’outil Mantis Bug Traker a été mis en place dans le projet, il nous a

permis d’avoir un historique d’erreurs et de partager les informations sur les bugs rencontrés ainsi

que les membres du groupe impactés par le bug.

IV.2.5 Formation effectuée:

Afin de partager les connaissances sur les outils techniques utilisés dans le projet et assurés par

l’entreprise, j’ai assisté à une formation sur l’outil de restitution de données SAP Business Objects.

IV.2.6 Problèmes rencontrés :

Parmi les problèmes rencontrés tout le long de ce projet :

Vu que le projet dans lequel je suis intervenu existe depuis plus d’un an, donc il m’a fallu se

documenter et analyser les jobs existants pour comprendre la logique et les conventions de

développement.

Temps remarquable avant de commencer le développement de jobs

Première manipulation de la version entreprise de Talend TIS

Capacité du poste local limité surtout sur les grandes masses de données.

Page 21 sur 34

IV.2.7 Rédaction de la documentation :

Afin de rendre les jobs d’intégration de données compréhensibles et faciliter un éventuel suivi de

développement, j’ai réalisé la documentation de toutes les tâches réalisées. Cette documentation

effectuée à la fin de chaque action contient une description détaillée des traitements ainsi que la

logique suivie pendant le développement et le principe de fonctionnement des jobs.

IV.2.8 Conclusion :

Le projet dans la deuxième mission est un projet de type forfait, c'est-à-dire qu’il possède un

document de spécification détaillé et un cahier des charges qui fixe les limites du projet. En plus, les

données sont de bonne qualité en termes de typage et de taille etc. Par ailleurs, les fichiers source

sont bien structurés et bien formatés, ce qui permet d’avoir un gain énorme en termes de temps de

développement puisqu’il y aura moins de traitements dans les jobs pour contrôler la validité des

données en entrée.

En plus des compétences acquises sur l’ETL Talend, j’ai amélioré mes connaissances en base de

données Oracle en manipulant les transactions différentes à travers des requêtes tout en respectant

les contraintes sur les tables de la base de données.

Page 22 sur 34

IV.3 Exemple détaillé :

Dans cette partie, je vais présenter un exemple détaillé du traitement (job Talend) fait lors de la

première mission.

Le job réalisé dans cet exemple prend en entrée un flux CSV contenant 16 colonnes et un nombre de

lignes qui peut atteindre 10 millions de lignes dans le cas d’un flux historique. En appliquant le

traitement, les données TSD (Taux de Satisfaction de la Demande) seront stockées dans l’entrepôt de

données formé d’une table de faits et des différentes dimensions nécessaire à l’analyse décisionnelle.

IV.3.1 Flux en entrée :

TS_FRANCE_TC_SUMMER_20120601_01.csv

IV.3.2 Les données source :

Les données source se présentent sous différents types tels que : Chaîne, Date, Numérique (Entier,

Réel, Double), Pourcentage.

Le nom de flux dans cette phase contient plusieurs champs séparés par « _ » :

- Le type de flux (CONTEXT, INIT, CO, TS, MO, SE)

- Le nom du pays

- Le code de la ligne produit

- Le code de la saison

- Une date sous le format yyyyMMdd.

- Identifiant unique du nom de fichier

D’où le nom TS_FRANCE_TC_SUMMER_20120601_01.csv

IV.3.3 Description du job :

Ce job se charge de l’intégration des données TSD et de la création des dimensions de pneus de type

TS.

Dans le schéma qui suit, un diagramme d’activité qui décrit le processus Talend:

Page 23 sur 34

Figure 5: Diagramme d'activité

Vérification de la validité du nom de flux

Vérification de la correspondance entre la date qui figure dans le nom

du flux et celle dans le flux

Identification des lignes rejetées et alimentation de la table de rejet

Alimentation de la table temporaire

Gestion des annules et remplaces

Alimentation des tables finales

Validation(Commit)

invalide

valide

Rejet du fichier

Rejet du fichier

invalide

valide

Nbr_lignes_rejetées > 0

Nbr_lignes_rejetées = 0

Rejet du fichier

Vérification

Suppression/Rejet

Alimentation

Validation

Page 24 sur 34

IV.3.4 Gestion des rejets :

Identification des erreurs de chargement et alimentation de la table de rejet t_file_rejected_ts.

Dans le tableau qui suit, quelques contrôles de chargement traités dans le job :

Colonne Test Validé Non Validé

dt_trt Format date valide Rejet de la ligne

pays_lib Existe dans la table t_country Rejet de la ligne

MRQ_LIB Existe dans la table t_brand(Name_in_TSD) Rejet de la ligne

CAT_LIB Existe dans t_etrma_category(Name_in_TSD) Rejet de la ligne

SAI_LIB Existe dans t_market_season(Name_in_TSD) Rejet de la ligne

IVIT_C Numérique et existe dans t_speed_Index (Code) Rejet de la ligne

HB_C Numérique et existe dans t_generic_dimension (geometric_box_ratio)

Rejet de la ligne

BOUD_C Numérique et existe dans t_generic_dimension (geometric_box_width)

Rejet de la ligne

ICH_C Numérique et existe dans t_generic_dimension (load_index_code)

Rejet de la ligne

RSEAT_C Numérique et existe dans t_generic_dimension (geometric_box_diameter)

Rejet de la ligne

DATE_SOUHAITEE MM/YYYY Rejet de la ligne

Quantité demandée retenue(SUM_ATF_RET_DEM_QT)

Numérique Rejet de la ligne

Quantité livrée conforme(SUM_ATF_LIV_CFRM_QT)

Numérique Rejet de la ligne

Season + Type Existe dans Generic_Segment type TS Rejet de la ligne

IVIT_C + Rseat_C Existe dans Generic_dimension type TS Création

(Season + Type) + (SI + Seat)

Existe dans t_tsd_element Création

Tableau 1 : Contrôles de chargement

Dans la table de rejet on stocke la ligne rejetée, le numéro de la ligne dans le fichier, un code d’erreur

et un message d’erreur qui explique la cause de rejet.

La table de rejet sera utilisée par le système BI comme support de données à l’aide de duquel un

rapport détaillé sera généré pour l’utilisateur final sur les éventuelles erreurs provenant de la source.

Le bloc qui assure cette phase de contrôle est représenté par la figure 6 qui suit.

Page 25 sur 34

IV.3.5 Utilisation d’une table temporaire (ODS) :

On stocke les données provenant du fichier source dans une table temporaire (tmp_file_ts) sans

prendre en compte le typage des données et en réalisant toutes les jointures possibles.

Le passage par cette table diminue énormément le temps d’exécution du job, puisque

l’alimentation des tables définitives se fera directement à partir de la table temporaire (sans

refaire les jointures).

Cette table de données temporaires est tronquée à chaque lancement du job.

Le bloc qui assure l’alimentation de la table temporaire est représenté par la figure 7.

Page 26 sur 34

Figure 6 : Bloc de la gestion des rejets

Vérifie les champs nuls, la taille des champs

Duplication du schéma en entrée

Sauvegarde les lignes rejetées

Page 27 sur 34

Figure 7 : Bloc d'alimentation de l'ODS

Le fichier en entrée

Dossier contenant les flux

Commit: Validation de la transaction

Page 28 sur 34

IV.3.6 Gestion des annule et remplace :

Ce bloc permet de supprimer et remplacer les volumes existant dans la table nommée

t_tsd_volume_by_month par les nouvelles valeurs si le fichier en cours de traitement porte le même

nom qu’un flux déjà traité.

Le bloc responsable de cette action est représenté par la figure 8.

Figure 8 : Suppression des volumes existants

IV.3.7 Alimentation des tables finales :

En se basant sur les données qui existent dans la table temporaire, on alimente directement les

tables finales.

Le bloc qui permet l’alimentation des tables finales est représenté par la figure 9.

Page 29 sur 34

Figure 9 : Alimentation des tables finales

Page 30 sur 34

IV.3.8 Variables de contexte utilisées :

Nom Fonction Type Valeur par défaut Obligatoire

error_code_field_null Code de rejet d’une ligne dans le cas d’un champ nul.

String nul oui

error_code_join Code de rejet d’une ligne dans le cas d’une jointure échouée.

String nul oui

filename_context Nom du flux en entrée. String nul oui

pcp_AdditionalParams String noDatetimeStringSync=true

oui

pcp_Database String [Nom de la base] oui

pcp_login Nom d’utilisateur String root oui

pcp_password Mot de passe String oui

pcp_port Le numéro de port String 3306 oui

pcp_server Hôte String localhost oui

DIR_ARCHIVE Dossier contenant les fichiers déjà traités.

String nul oui

DIR_CONF Dossier contenant les fichiers de configuration.

DIR_DATA Dossier contenant le flux de contexte.

String oui

DIR_FILE_IN Dossier contenant les flux en entrée.

String oui

DIR_FILE_OUT Dossier contenant les fichiers créés.

String oui

DIR_FILE_REJECTED Dossier contenant les flux rejetés.

String oui

file_country Le nom de pays récupéré du nom de flux.

String nul oui

file_date La date qui figure dans le nom de flux.

String nul oui

year L’année qui figure dans le nom du fichier en entrée.

String nul oui

file_market_season La saison qui figure dans le nom du fichier.

String nul oui

file_product_line La ligne produit récupérée du nom de fichier.

String nul oui

filename_init Le nom du fichier INIT String nul oui

filename_in Nom de flux en entrée. String nul Oui Tableau 2 : Liste des variables de contexte

Page 31 sur 34

IV.3.9 Utilisation des routines Talend:

Pour remédier à des problèmes spécifiques dans la transformation des données, j’ai eu recours à

l’utilisation des routines Talend.

Une routine est une classe java ayant que des méthodes statiques, d’où la puissance de l’ETL Talend

parce qu’en plus des possibilités énormes de transformation offertes par défaut, on a la possibilité de

créer nos propres traitements (routines), ce qui offre un niveau de flexibilité, de souplesse et de

performance.

Page 32 sur 34

VI. Conclusion :

Durant ce stage de six mois chez BIPP Consulting, mes attentes en termes d’acquisitions de

compétences techniques telles que le développement sur l’ETL Talend et la manipulation des SGBD

(Oracle 11g, MySql5) ainsi qu’en termes de découverte du monde professionnel en développement

des systèmes d’information décisionnels ont été satisfaites.

Mon affectation à des projets utilisant un panel riche en outils largement demandés sur le marché de

l’informatique décisionnel (Talend, Oracle, Business Objects, etc.) m’a permis d’avoir une expérience

recherchée de nos jours.

En plus des compétences techniques acquises et utilisées lors de mes interventions sur les deux

projets durant mon stage, la formation sur l’outil Business Objects à laquelle j’ai assisté m’a permis

de découvrir un autre environnement important dans le domaine BI. De plus, le contact direct avec le

client m’a servi d’améliorer mon relationnel avec le maître d’ouvrage.

Par ailleurs, le travail collectif dans une équipe pluridisciplinaire suivant une bonne méthodologie de

travail était une expérience très intéressante qui m’a aidé à élargir mes connaissances en gestion de

projet.

Page 33 sur 34

Références

http://www.bipp-consulting.fr

http://fr.wikipedia.org

http://fr.talend.com/index.php

http://www710.univ-lyon1.fr/~elghazel/BI/

http://www.wtdev.fr

http://www.journaldunet.com/solutions/intranet-extranet/business-intelligence/

http://www.lirmm.fr/~libourel/FMIN206/cours11_BDS-OlapSolap.pdf

Liste des acronymes

BI: Business Intelligence

SI: Système d’information

SIAD: Système d’Information d’Aide à la Décision

ETL: Extract Transform Load

DW: Data Warehouse

ODS: Operational Data Store

OLAP: Online Analytical Processing

ERP: Enterprise Resource Planning

SAP: Systems, Applications, and Products for data Processing

JVM: Java Virtual Machine

TOS: Talend Open Studio

TIS: Talend Integration Suite

ELT: Extract Load Transform

TSD: Taux de Satisfaction de la Demande

SGBD : Système de Gestion des Base de Données.

Glossaire

[1] BI : « La Business Intelligence (BI), également « intelligence d'affaires » ou « informatique

décisionnelle », englobe les solutions informatiques apportant une aide à la décision avec, en bout de

chaîne, rapports et tableaux de bord de suivi à la fois analytiques et prospectifs. Le but est de

consolider les informations disponibles au sein des bases de données de l'entreprise. »7

7 http://www.journaldunet.com/solutions/intranet-extranet/business-intelligence/

Page 34 sur 34

[2] ETL : « « Extract-Transform-Load » est connu sous le terme ETL (ou parfois : datapumping). Il s'agit d'une technologie informatique intergicielle permettant d'effectuer des synchronisations massives d'information d'une banque de données vers une autre. Selon le contexte, on traduira par « alimentation », « extraction », « transformation », « constitution » ou « conversion », souvent combinés. »8 [3] Data Warehouse : « Un entrepôt de données (data warehouse) est une collection de données intégrées, non volatiles et historisées pour la prise de décisions » (Bill Inmon1990)

[4] OLAP : « Il s’agit d’une catégorie de logiciels axés sur l’exploration et l’analyse rapide des données selon une approche multidimensionnelle à plusieurs niveaux d’agrégation » (Caron, 1998)9

Table des figures FIGURE 1 : PILOTAGE PERFORMANCE - ELABORATION BUDGETAIRE - GESTION DE LA RELATION CLIENT (CRM) - ORGANISATION

PERFORMANCE SI ................................................................................................................................................ 7

FIGURE 2 : ARCHITECTURE DE L'ENVIRONNEMENT DE TRAVAIL ............................................................................................... 9

FIGURE 3 : SCHEMA D’UN ETL, ET DE SON FONCTIONNEMENT ............................................................................................ 11

FIGURE 4 BLOC D'ALIMENTATION DE LA TABLE T_MARKET_ZONE ......................................................................................... 16

FIGURE 5: DIAGRAMME D'ACTIVITE ............................................................................................................................... 23

FIGURE 6 : BLOC DE LA GESTION DES REJETS .................................................................................................................... 26

FIGURE 7 : BLOC D'ALIMENTATION DE L'ODS .................................................................................................................. 27

FIGURE 8 : SUPPRESSION DES VOLUMES EXISTANTS ........................................................................................................... 28

FIGURE 9 : ALIMENTATION DES TABLES FINALES ................................................................................................................ 29

Table de tableaux TABLEAU 1 : CONTROLES DE CHARGEMENT ..................................................................................................................... 24

TABLEAU 2 : LISTE DES VARIABLES DE CONTEXTE ............................................................................................................... 30

8 http://www.dwfacile.com/Portail_etl.htm

9 http://www.lirmm.fr/~libourel/FMIN206/cours11_BDS-OlapSolap.pdf