Retour d’expérience sur … Datastage

Publié le par
1

Datastage fait partie de la suite WebSphere d’IBM ( maintenant Infosphere ), il fait partie des principaux ETL adoptés chez les grands comptes. Il possède son propre moteur de traitement ( Engine-based ), ainsi que son propre référentiel.

La version max que je connais est la 7.5.2

Un exemple de job :
Alimentation d'une table Oracle à partir d'une autre table Oracle en effectuant une jointure avec un fichier texte en référence
( Alimentation d’une table Oracle à partir d’une autre table Oracle en effectuant une jointure avec un fichier texte en référence )

Les + :

  • graphiquement attractif – de jolis dessins en 3d
  • on voit le cheminement/flux de la donnée ( sources/cibles, les différents traitements : tri, agrégation )
  • pas besoin de connaitre le SGBD ( fonctions sql, procédures )
  • les fichiers hash pour dédoublonner en ne gardant que le dernier enregistrement
  • les variables dans les transformer pour comparer avec les valeurs de la ligne précédente

Les – :

  • boîte noire – on ne sait pas trop comment il fonctionne
  • un nouveau langage à apprendre même s’il est estampillé basic …
  • les performances sont vite dégradées sur de grosses volumétries, car il fonctionne en mode curseur ( ligne par ligne )
  • analyse d’impact peu poussée
  • limites du basic

Le plus gros point faible pour moi concerne les performances. En effet on est vite amenés à tout coder en sql notamment pour les tris, les agrégations et les jointures. On se retrouve alors avec des jobs assez simples ( 3 stages : une source avec un sql complexe, un mapping et une cible )
Pour l’analyse d’impact, le lien avec les métadonnées est perdu lors du développement. Par exemple, on importe la structure d’une table T dans le référentiel, on crée un job et en source on prend la table T dont on importe la structure depuis le référentiel. Mais il n’y a pas de lien entre le job et la métadonnée dans le référentiel, si on change la structure de T dans les métadonnées il n’y a pas d’alerte sur le job qu’on a créé !!!
L’analyse d’impact se fait alors principalement par mot clé, ce qui pose problème avec des mots clés bateau qu’on retrouve partout !!!
Pour le basic, d’accord on est indépendant du SGBD mais on a un nouveau langage avec toutes ses subtilités.
Par exemple, pour extraire une chaine :
toto[4]  = les 4 derniers caractère du champ toto

pour avoir la date système au format DD/MM/YYYY HH24:MI:SS d’Oracle :
OCONV(Date(),"D-YMD[4,2,2]"):" ":Oconv(time(), "MTS")

D’autre part, certaines fonctions/opérateurs très pratiques ne sont pas écrites comme le NVL, BETWEEN, IN …
C’est dommage, car certains aspects du BASIC Datastage sont séduisants, comme l’utilisation indifférente des  » ou des ‘ pour définir une chaîne de caractères
( on peut écrire "toto", 'toto', "aujourd'hui" ou 'des "guillemets"' )

Pbs courants :

  • obligation de trier les colonnes dans un stage Aggregate … sinon plantage …
  • pbs de mémoire lorsqu’on utilise le stage de tri …
    –> on trie et on somme en sql :-(
  • le fichier hash dédoublonne sans prévenir …
    –> alertes non remontées
    Par exemple, on récupère les noms à partir d’un login, mais on a une évolution en source qui fait qu’on peut avoir différents noms pour 1 login
    En utilisant le fichier hash, on récupère un des noms … mais pas forcément le bon … et ce n’est pas remonté …
    En récupérant le nom via une requête, on aurait des doublons en entrée –> plantage
    Il faut donc toujours mettre une contrainte d’unicité en base sur les clés des fichiers hash pour éviter ce pb.
  • pas de remontée/warning des lignes non mises à jour
    ex : un job traite une volumétrie de 100 000 lignes, mais aucune ligne n’est mise à jour
    –> il n’y a aucune remontée, le job semble avoir maj les 100 000 lignes
  • pb ETL : il faut être vigilant qu’on fonctionne en mode curseur
    –> si on a un traitement qui met à jour les dossiers, et en entrée 10 fois le même dossier, on aura 10 mises à jour de la même ligne, sans remontée d’alerte !!!

Pbs énervants :

  • renommage colonne en amont –> il faut tout changer en aval :-(
  • les messages d’erreur laconiques ( pb des phantom … ), où on passe des heures à débuguer ligne par ligne pour trouver ce qui ne va vraiment pas !
    –> notamment sur les routines, quand on a du null en argument …

Quelques conseils :

  • résister à l’envie d’écrire un seul « gros » job qui fait tout ( même si c’est possible ). Il vaut mieux écrire des jobs « basiques », avec le minimum de stages – c’est plus simple à maintenir et à tester
  • éviter les stages tri et agrégat, ils amènenent souvent leurs lots d’erreurs incompréhensibles
  • les stages folder et rowsplitter donnent envie quand on a plusieurs fichiers à traiter, mais ils ne sont vraiement pas pratiques à débuguer – pensez à votre prochain, rester aux stages simples de fichier …

En conclusion :
Au début on trouve l’application géniale, c’est quand même plus sympa que les tristounets scripts sql lancés en batch… Et on déchante assez vite devant les performances et les problèmes rencontrés … Du coup on simplifie les jobs au maximum et on met tous les traitements dans les sql … en se demandant si on n’écrirait pas à la place des scripts sql qui seraient plus performants !!!

Pour moi Datastage fait partie des « anciennes » générations d’ETL qui n’ont pas vraiment su se renouveler.
La montée en version n’a pas apporté grand chose, à part un lifting graphique réussi.
La version 8 ne me semble pas plus innovatrice, IBM répondant au problème de performance avec du parralélisme … De plus l’offre devient plus floue, avec 2 versions de Datastage ( PX et Server ) dont celle correspondant à l’ancienne qui n’évolue plus !!!

Je lui préfère SunopsiS/ODI ou Talend pour les raisons que j’expliquerais plus tard dans un autre article ..

Enquête Gartner : Les utilisateurs jugent les éditeurs de BI et leurs plates-formes

Publié le par
Répondre

Un article intéressant sur le site du grand bi :

L’enquête Gartner incendie pour une fois les grands éditeurs comme SAP/BO, Oracle ou IBM sur les problèmes remontés par les utilisateurs …
Certes, on pourra critiquer ces résultats en supposant que le nombre de problèmes est aussi fonction du nombre d’utilisateurs – et comme peu de monde dans l’entreprise utilisent les produits gagnants de l’enquête – qui utilise Tableau Software ?
Mais c’est une avancée …

Conversion Datastage – Talend

Publié le par
Répondre

J’ai récemment étudié l’outil de conversion Datastage – Talend qu’on trouve sur

Les jobs simples ( 1 source, 1 cible et 1 transformer entre 2 ) sont bien convertis, mais les jobs plus complexes nécessitent certaines modifications …
Je n’ai ni le temps, ni la place pour exposer tout ça ici, mais je planche là-dessus pour donner plus de détails + tard !

La BI 2.0

Publié le par
Répondre

La BI existe maintenant depuis une vingtaine d’années, et repose sur des modèles solides comme l’OLAP, les modèles en étoile / flocons, les cubes etc …

La BI 2.0 est un terme à la mode qui caractérise les nouveaux outils qui se détachent des anciens modèles de la BI traditionnelle.

Les principales différences sont :

  • une mise en oeuvre simplifiée, quelques jours ( voire heures ) suffisent pour monter une solution BI
  • la rapidité, notamment due à des nouvelles technos comme l’analyse « in-memory »
  • l’autonomie des utilisateurs – par rapport à la dsi
  • la démocratisation – la BI est utilisée par tous, et non plus destinée à certains cadres dirigeants
  • la souplesse – pouvoir combiner des données qui n’étaient pas reliées entre elles avant, de sources différentes ( fichiers excel, bases de données, sites web )
  • le temps réel – du fait de pouvoir se connecter à n’importe quelle source
  • le travail collaboratif – génération web 2.0

Evidemment de par sa version la BI 2.0 est orientée Web 2.0, et elle adopte les technos du moment ( Cloud Computing, Saas, Paas, mobile etc )

Comme il suffit d’adopter une des caractéristiques citées ci-dessus, beaucoup d’applications sont estampillées « BI 2.0″, notamment les versions « OnDemand » des applications traditionnelles.

Quelques exemples concrets d’applis BI 2.0 :

  • Qlikview
  • Bime

Les problématiques que peut apporter la BI 2.0 :

  • des données publiées non certifiées
  • des process inexistants ( par exemple pour la maintenance … )
  • des limites aux traitements de la donnée

starschema vs snowflake

Publié le par
2

Que faut-il choisir entre Un modèle en étoile ou un modèle en flocons ?

On se pose tous la même question quand on commence la conception, sans avoir d’éléments de réponse.
Je vais essayer ici de donner les différences entre les deux types de modélisation, et mon point de vue sur la question.

Mais avant quelques rappels :

Le schéma en étoile :
Les dimensions sont dénormalisées afin de concentrer toutes les informations en une seule table. Cela implique qu’on y retrouve certaines colonnes ayant plusieurs fois les mêmes valeurs.
Elles sont disposées autour d’une table de faits, à la manière d’une étoile.
starschema

Le schéma en flocons :
Seules les dimensions changent par rapport au modèle en étoile.
Dans le schéma en flocons, elles sont normalisées. Au lieu de tout concentrer en une seule table on a plusieurs tables liées en une arborescence, chaque niveau de la hiérarchie donnant lieu à une table.
>snowflake

Les différences :

1/ Performances
Avantage : — étoile ? –
On dit souvent que le modèle en étoile est plus performant. Cela est dû au fait qu’il y a moins de jointures à faire que sur un modèle en flocons.
Je dirais que c’était vrai il y a quelques années, quand les SGBD étaient moins performants.
Mais actuellement la différence est minime, les SGBD gérant mieux les jointures multiples. De plus les jointures supplémentaires mettent en oeuvre généralement des tables à faible volumétrie. Cependant il suffit que les stats Oracle soient mal calculées pour obtenir des plans d’exécution erronés et plomber un modèle en flocons.

1bis/ Contre-performance :
Une table de dimension en jointure réflexive dans un modèle en flocons est à proscrire.
Par exemple si on a une table de hierarchie décrivant la structure de l’entreprise, une colonne « père » permettant de faire le lien sur la même table

Le SGBD va lire plusieurs fois la même table, les accès concurrents se faisant sur le même disque les performances seront très dégradées.
Il vaut mieux créer plusieurs tables différentes, chacune représentant un niveau de la hiérarchie.

2/ Volumétries
Avantage : — flocons –
Si la dimension a de nombreux attributs, on a une table qui prend plus d’espace pour le modèle en étoile.
Il vaut mieux choisir un modèle en étoile sur de grosses volumétries quand le ratio devient faible ( 1:50 ), sinon en aplatissant en une seule table les redondances seront trop nombreuses.

3/ Compréhension
Avantage : — flocons –
Certains disent que les modèles en étoile sont plus compréhensibles au premier abord car ils sont plus lisibles, aérés.
Pourtant les hiérarchies sont plus compréhensibles par les utilisateurs dans un modèle en flocons, puisqu’elles sont représentées par les jointures. Alors que dans un modèle en étoile on a plus de mal à voir quel attribut est avant l’autre …

4/ Modèles spécifiques
Avantage : — flocons –
Le modèle en flocons est plus adapté pour les relations n n.
Par exemple si on prend la dimension Compte/Client dans le secteur bancaire, 1 compte a 2 clients, et 1 client a plusieurs comptes …

5/ Tables agrégées
Avantage : — flocons –
Le modèle en flocons est adapté aux tables agrégées comme les vues matérialisées d’Oracle.
Prenons par exemple une table ventes à volumétrie importante.
Pour des raisons de performance on l’a agrégée suivant la semaine, le mois et l’année. Ainsi en fonction de la granularité utilisée, on utilisera la table à la plus faible volumétrie.
Avec le modèle en flocons, les jointures sur les dimensions se font simplement.
Par contre avec le modèle en étoile, avec une seule dimension calendrier ayant le jour en point d’entrée, il faudra :
Рsoit cr̩er des vues sur la table calendrier au niveau semaine, mois et ann̩e et qui d̩doublonneront les lignes ( avec un distinct ) pour ne pas multiplier les r̩sultats.
– soit bricoler les jointures dans l’applicatif de restitution ( par exemple lier une table agrégée au mois sur le 1er jour du mois )

6/ Attributs partagés
Avantage : — flocons –
On a souvent des niveaux partagés entre plusieurs dimensions comme le pays dans notre exemple.
Dans un modèle en étoile ces niveaux sont dupliqués dans chaque table, ce qui implique de bons process pour synchroniser les données dans toutes les tables.
Dans un modèle en flocons on n’a pas ce problème car on n’a qu’une seule table.

5/ Applicatifs
Avantage : — aucun –
Certaines applications comme Microstrategy DSS nécessite un modèle en flocons … J’ai vu un modèle en étoile sur lequel on définissait des vues pour le transformer en flocons … c’est dommage non ?

6/ SCD
Avantage : — flocons –
On peut scinder une dimension en SCD dans un modèle en flocons, ce qui est idéal pour de grosses volumétries ou une dimension avec de nombreux attributs.

7/ Simplicité
Avantage : — étoiles –
Le modèle en étoile est plus un modèle « de fainéants » …
Les requêtes SQL sont + faciles à écrire, puisqu’il y a moins de jointures. De même la modélisation est plus simple et plus rapide.

Conclusion
Il est difficile de choisir entre les 2 types de modèles quand il n’y a pas d’applicatifs ou de fonctionnements spécifiques.
D’expérience on part souvent sur un modèle en étoile à la Kimball qui est réputé performant et pratque en décisionnel. Et puis on revient sur des parties de dimension qui sont partagées, et qu’on « dénormalise » en parties de modèle en étoiles.
A mon avis c’est surement la meilleure solution, un modèle hybride qui fait du flocon sur des parties spécifiques ( SCD, niveaux partagés ) et de l’étoile pour le reste …

Recette avec les stats d’Oracle

Publié le par
Répondre

Voici un petit moyen de tester rapidement une table en recette.

Un des tests « génériques » pour voir si une colonne est bien chargée est de voir :
– si toutes les valeurs de la colonne ne sont pas nulles
Рsi on a des valeurs diff̩rentes dans la colonne

Pour cela, on peut écrire 2, voire une seule requête.
Par contre, si on a plusieurs colonnes, il faut soir écrire plusieurs requêtes, soit une seule requête très complexe.

Un autre moyen est d’utiliser les stats d’Oracle, qui vont effectuer ces calculs pour nous !

Tout d’abord, il faut calculer les stats ( attention, je dis bien calculer, et non estimer ) :

-- ( Oracle 10g )
analyze table &TABLE.&OWNER compute statistics;

Ensuite il suffit de requêter la table des stats :

SELECT
  column_name,  
  num_distinct "nb val distinctes",  
  num_nulls "nb val nulles",
  sample_size "nb lignes"
FROM all_tab_columns
WHERE table_name='&TABLE' and owner='&OWNER'
ORDER by column_id;

Filtrer sur num_nulls>0 ou num_distinct=1 par exemple.

Attention, il ne faut pas oublier après de recetter aussi les données fonctionnellement !!!

Invite dynamique Toutes Valeurs

Publié le par
Répondre

Les invites sous BO permettent de filtrer les résultats d’une requête en fonction d’une ou de plusieurs valeurs d’un champ.

C’est utile par exemple pour avoir un rapport qui donne le chiffre d’affaires d’une certaine région, qui est à choisir lors du rafraichissement du rapport.
Ce rapport sera donné au responsable de la région concernée.
Cependant on a généralement aussi un rapport qui lui s’applique sur toutes les régions, un rapport « global ».
La solution la plus simple est de dupliquer le rapport en enlevant l’invite, mais la maintenance sera double.
On peut aussi sélectionner toutes les valeurs dans l’invite, mais il faudra penser à modifier le rapport quand on rajoutera une région, pour rajouter la valeur de cette nouvelle région à l’invite.

Le plus simple est de rajouter une valeur spécifique pour l’invite, qui correspond à toutes les valeurs possibles.
Cela se traduit par le rajout d’une simple condition OU dans la requête.

Cela donne en SQL :
( maTable.region in @Variable('Region') or 'TOUT' in @Variable('Region') )

Ici si on entre TOUT pour l’invite, la requête prendra toutes les régions, en effet la 2ème condition sera toujours vérifiée.
Bien sûr, il n’y a pas de région « TOUT ».

Pour implémenter la 2ème solution sous BO, on peut :
– créer un objet spécifique, dont la formule est « TOUT », sans table associée
Рcr̩er un filtre pr̩d̩fini

conditions

Remarques :
– il existe d’autres solutions, mais je trouve que c’est la plus simple et la plus compréhensible pour une invite à valeurs multiples
Рil vaut mieux utiliser le @Prompt pour la compatibilit̩ avec Webi

Comment afficher plusieurs devises dans le même tableau sous BO ?

Publié le par
Répondre

On a par exemple des montants en Euro et en $ qui proviennent du même fournisseur de données.

La devise est donnée par un objet dimension « devise », qui vaut « EUR » ou « US ».
Le montant est un indicateur numérique.

On peut toujours afficher la devise dans une colonne supplémentaire :
le tableau avec la colonne devise

Mais on peut aussi changer le format du montant affiché en prenant le symbole de la devise avec un alerteur qui s’appuie sur la colonne devise :

conditions de l'alerteur

format de l'alerteur

Voilà, le symbole des montants diffère en fonction de la devise !!!

montants en format devise