Modélisation BI - Dénormalisation/Vues et performances

[Mascareigne]

Bonjour,

Je suis actuellement en poste côté maîtrise d'ouvrage décisionnelle, et suis confronté à des problèmes de performances, de modélisation et d'accès aux données, mais surtout de conflits d'architecture avec l'équipe de DEV.

La configuration de mon environnement BI:
Oracle 10G, Business Objects, QlikView, et.... PL/SQL pour l'ETL.

Nous souhaitons changer notre architecture, mais sommes confrontés à une équipe de DEV particulièrement têtue qui nous impose ses choix techniques et son architecture désuète qui fonctionne comme ceci:

Tous les jours, des fichiers sont extraits en PL/SQL de nos diverses sources.
Ces fichiers sont chargés en SQL LOADER dans une base ODS, et l'on garde une trace de ces chargement dans une table dédiée à cet effet.

Il y a éventuellement quelques transformations (champs numériques et date, une ou deux jointures pour récupérer des libellés de temps en temps), mais c'est très rare, la plupart des calculs étant faits précédemment lors de l'extraction en PL/SQL.
Ces fichiers chargés dans nos tables d'ODS sont ensuite chargés dans la base quotidienne de chargement, après que les données de la veille aient été insérées dans nos tables d'historique, toujours dans la base de chargement.
Nous sommes donc, depuis le début, dans du truncate/insert, sauf pour les tables historiques, qui elles, sont en insert simple.

Une fois toutes ces tables chargées dans notre base "de chargement", on copie notre tablespace en export/import vers une base de données de restitution.
Nous avons donc, dans notre base de restitution, deux types de tables:
des tables quotidiennes, et les mêmes qui contiennent les données historiques.
Ces tables sont ensuite jointes par des vues en union all.

Notre premier problème est le suivant:
Nous n'avons pas le droit, en tant que maîtrise d'ouvrage d'accéder aux tables, et ne voyons que les vues. Or ces vues ont (souvent) des performances déplorables, et sont composées, pour certaines, de 32 (oui, 32!!) union all, et de centaines de millions de lignes.
Nos outils de restitutions se comportent de façon déplorable avec ces vues, alors que soit disant les unions all "sont très rapides".
Nous souhaiterions des tables partitionnées avec des vraies étoiles décisionnelles, dénormalisées.
Quels sont vos arguments?

Deuxième problème:
Pour suivre les chargements, faire des tables de rejets, planifier, utiliser les métadonnées à des fins de reporting et de suivi, nous souhaiterions utiliser un ETL, en l'occurence Talend. Or l'équipe de DEV ne souhaite pas utiliser d'ETL et s'obstine à utiliser le PL/SQL, et à remplir le suivi des chargements à la main, arguant du fait que cela aurait des conséquences néfastes sur les performances de chargement.
Auriez-vous des arguments contre cette architecture désuette?
Nous souhaiterions mettre en place une architecture DWH classique:
Extraction "simple" de fichiers vers un ODS, qui serait historisé, transformation des données dans cet ODS, le données ne matchant pas étant stockées dans des tables de rejet, puis transfert des données calculées vers les étoiles décisionnelles du dataware.

Qu'en pensez-vous?
Merci d'avance pour votre réponse, et d'avoir lu ce loong message ;-)

[DevNico]

Bonjour,

Ces problématiques sont assez standard, mais j'aurais dit aussi un peu dépassées. (Aujourd'hui on se bat plutôt autours des concepts BI 2.0 qui sont sensés donner plus de souplesses aux utilisateurs...)


Ce que je dirais :
Premier point : Vous avez déjà donné les arguments. La solution mise en place ne répond pas au besoin.
Vous souhaitez pouvoir faire des restitutions avec des temps de réponse corrects. La solution de base pour y parvenir est d'utiliser un modèle adapté aux restitutions.
Là dessus, je ne vois pas trop quel pourrait-être la raison de ne pas souhaiter évoluer vers un tel modèle.

Deuxième point : Là encore, d'après ce que je comprends la solution ne répond pas à votre besoin de suivre les traitements et les rejets.
Si votre MOE n'est pas capable de vous fournir ce service avec leurs traitements PL/SQL, alors ils doivent adapter leurs outils.
La réticence au changement est toujours quelque chose à gérer avec délicatesse, peut-être faut-il leur suggérer de réaliser un prototype avec Talend par exemple ? Histoire de lever les éventuels risques sur les temps de chargement.

Une fois qu'ils auront mis le nez dedans, ce sera gagné. Je ne pense pas avoir jamais vu quelqu'un regretter de s'être lancé sur un ETL après être sorti du PL/SQL ou du Java.
De même concernant les temps de traitement, les temps de développement, la maintenabilité logicielle ou l'exploitation des traitement, vous pouvez y aller les yeux fermés. Faites-vous aider au début par des gens qui connaissent, vous constaterez rapidement les avantages d'un ETL par rapport au PL/SQL.

Nicolas

[Jester]

Votre équipe de dev semble composé de DBA et de dev Oracle et il n'y a pas de data warehouse.

Pour des gens de l'univers décisionnel comme nous c'est un problème. Mais en soit, ce n'est pas le problème principal ici.

Le problème c'est les performances. L'union all est en effet invisible (à part en MySQL), ce n'est pas le problème. Le problème c'est qu'il n'y a pas de partionnement qui permettrais de ne pas tout lire. Le problème c'est qu'il n'y a pas de tables d'agrégations.
Vu qu'ils font des traitements dans le script qui tourne sur la prod, j'ai des doutes quand à leur argument de performance. Clairement, il n'ont pas envie de refaire ce qu'ils ont passé du temps à faire et qui marche bien (pour eux du moins).

Vous avez deux solutions :
1- Vouloir une architecture décisionnelle. Ce n'est pas forcément une mauvaise idée, mais c'est risqué et depend de votre place et de votre expérience. Clairement ce n'est pas les bonnes personnes. Cela prendra aussi du temps.
2- Vouloir une solution au problème présent. Vous pouvez demander des vues matérialisées par exemple pour avoir des agrégations. Mettre des contraintes sur les tables d'historique (date entre d1 et d2) devrait permettre de ne pas lire les tables d'historique pas utiles (sur ce point je ne suis pas sur, mais je pense que Oracle sait gérer ça).
Certes ce sera toujours le bordel derrière vos vues d'accès, mais au moins vous aurez une solution et vous proposez des solutions Oracles à des gens Oracle qui seront donc plus enclins à l'accepter.

[Feyrehr]

Bonjour,
Je suis en mission AMOA, et je connais la même problématique. Je maîtrise les sujets techniques, et je constate que notre MOE ne fait pas du bon travail. Ni dans leur travail, ni dans leur conseil.
Dès que l'on abordre un sujet technique, de choix des outils, on nous rétorque que ca n'est pas nos affaires, que l'AMOA n'a pas à prendre position sur le choix d'un outil purement IT (et ils ont raison).

Il faut donc raisonner en vase clos. A savoir, l'AMOA a une demande précise, la MOE fournit un travail fini. Ce sont les exigences qui feront peut-être pencher la balance.
Dans ton cas, exige par exemple des temps de traitement inférieurs à une seconde. Des temps de mise à disposition des données de moins de 1 heure, etc...
Dans cette configuration, tu restes distant de leur problèmes. Si ils annoncent des retards, ils devront justifier. Bref, il faut faire entrer le sujet sur le terrain politique. Et ne pas hésiter à impliquer les directions.

[Mascareigne]

Bonjour à tous,
Merci pour vos réponses. Nous préparons une synthèse de vos réponses, et de nos questionnements, pour vous les soumettre et essayer de faire une super argumentation pour la suite.
En tous les cas, la phrase de Jester m'a bien fait rire:
"Votre équipe de dev semble composé de DBA et de dev Oracle et il n'y a pas de data warehouse" , c'est tellement vrai!!!
Je commence à être désespéré (et nos utilisateurs aussi) de voir le datawarehouse tomber car il n'y a pas (ou peu) de contrôles en entrée.

En fait, à l'heure actuelle, le principal problème, c'est que la MOA est dirigée par la DAF, et que la MOE, est dirigée par le SI, donc deux directions différentes, donc forcément des problèmes politiques qui font que chaque direction essaie de défendre becs et ongles son équipe.

En tous les cas, l'idée des Vues matérialisées demande à être creusée, nous allons essayer d'opter pour ça, à minima.
Nous allons, par le biais d'un poc problablement, demander à ce que Talend soit utilisé, et que les transformations soient faites non pas à l'extraction sur la prod, mais dans l'ods, pour que nous puissions les contrôler (quand je dis "nous", je veux dire tant la MOE que la MOA, et non pas l'équipe qui gère la prod).

Enfin, l'idée de mettre l'équipe face à ses responsabilités en terme de disponibilité des données est à creuser, bien qu'elle risque de nous mener tout droit au clash.

[kalyparker]

Une fois toutes ces tables chargées dans notre base "de chargement", on copie notre tablespace en export/import vers une base de données de restitution.
Nous avons donc, dans notre base de restitution, deux types de tables:
des tables quotidiennes, et les mêmes qui contiennent les données historiques.

Si je comprends bien votre base de restit est la même que la base "de chargement" ?
Si c'est le cas je rejoins Jester sur l'optim des index et partitionnement qui peut être une bonne piste pour l'amélioration des temps de réponse dans un premier temps.
Et avec les vues matérialisés il est aussi possible de demander des tables d'aggregats qui permettrait de réduire la volumétrie et donc le temps de réponse.

Ensuite pour ce qui est de mettre en place un data warehouse avec un modèle en étoile en flocon ... ça peux effectivement être une piste, mais demande énormément d'investissement !

[doc malkovich]

Pour info le partitionnement est une option payante sous Oracle, c'est surement pour ça qu'ils bidouillent des vues avec des union
Mettre en place un ETL est judicieux, mais à mon avis votre MOE peut argumenter qu'elle a des experts en PL/SQL et pas en ETL ... Dans ce cas il faut vous faire accompagner d'experts ETL qui vous donneront les avantages de ce type d'outil.

Par contre dans votre projet vous ne pouvez pas négocier un budget d'audit ? Au risque de vexer la DSI, mais au moins vous serez sûrs de l'état des lieux