Datawarehouse et MYSQL

[greatmaster1971]

Bonjour,

j'ai un projet dans lequel je dois construire un datawarehouse à partir des notes aux examens. Les bases sources sont sous Informix que j'attaque à partir de transformations ETL déjà construites avec KETTLE.

J'ai choisi MYSQL comme SGBD pour le datawarehouse, mais sans savoir exactement quelle configuration convient le mieux. MYSQL semble s'orienter de plus en plus vers le décisionnel.

Quelle configuration choisir ? Sachant que j'aurai à terme une table de faits contenant plus d'1 million de lignes, que certains utilisateurs devront faire des requetes avec GROUP BY ramenant plusieurs dizaines de milliers de lignes ...

Merci

Eric

[Maximilian]

Salut,

Ca dépend de comment sera alimenté le datawarehouse, quelle sera sa charge en lecture...

Quelques user cases pour te donner une idée :
http://www.mysql.com/customers/?dataWarehouse
http://mysqluc.com/cs/mysqluc2005/view/e_sess/6218

[Marco_SAP]

Bonjour,

Je n'ai pas de réponse à te donner mais ton projet m'intéresse, car je travaille sur un projet similaire alimenté à partir de SAP.
Du coté du poste client, j'ai testé des addins Excel comme Myreport de ReportOne et StarQuery de symtrax, mais je ne suis pas complétement convaincu. Et J'aimerais bien connaître ta solution.

Marco

[greatmaster1971]

Bonjour,
tout d'abord merci pour les liens et les réponses.

Quelques précisions :
-2 types d'utilisateurs
analystes : lance des requetes sur les tables de fait détaillées (requetes lourdes). Une dizaine d'utilisateurs.
utilisateur de base : lance des requetes sur les tables de fait agrégées. Potentiellement une centaine.

- La base cible :
Les tables de faits détaillées : 2 tables dont j'estime la volumétrie finale sur une historisation de 6 ans à 3 millions pour la 1ère et 300 000 pour la 2ème.
Les tables de fait agrégées : volumétrie que j'estime négigeable par rapport aux faits détaillés.
Les dimensions : 5 tables dont 4 ayant une volumétrie négligeable, la 5eme a une volumétrie equivalente au 2eme fait.

Compte tenu de ces paramètres j'aimerais trouver la config idéale pour le serveur MYSQL : quantité de mémoire physique, config MYSQL (cache ...). J'ai vu qu'il y avait un article sur le tuning de MYSQL mais il a l'air succcinct.
Si vous avez des suggestions je suis preneur !

Du coté du poste client, j'ai testé des addins Excel comme Myreport de ReportOne et StarQuery de symtrax, mais je ne suis pas complétement convaincu. Et J'aimerais bien connaître ta solution.

Je m'oriente coté client vers une solution de restitution à base d'OLAP (JPIVOT/ MONDRIAN http://mondrian.sourceforge.net) pour le coté analyse et à base de JASPERREPORTS http://jasperreports.sourceforge.net pour le côté reporting.
Pour plus de précisions tu peux éventuellement me contacter.

Eric

[chris81]

Envoyé par Marco_SAP

Bonjour,

Je n'ai pas de réponse à te donner mais ton projet m'intéresse, car je travaille sur un projet similaire alimenté à partir de SAP.
Du coté du poste client, j'ai testé des addins Excel comme Myreport de ReportOne et StarQuery de symtrax, mais je ne suis pas complétement convaincu. Et J'aimerais bien connaître ta solution.

Marco

Bonjour,
pourrais je savoir pourquoi myreport ne repond pas à tes attentes ou quelles sont ces points faibles d'aprés toi ?

[ygrim]

Salut tout le monde,
En ce qui concerne MySql, à moins que tu utilises la version pro (que je ne connais pas), MySql est loin de s'orienter vers le décisionnel (ils viennent d'intégrer les procédures stockées et les Triggers sont très mal gérés), on est loin des solutions payantes.
Quand à ton questionnement sur l'utilisation du Data Warehouse, et bien les DW ont été crées pour justement donner plus de liberté aux analystes, on ne les contraint plus avec des requêtes, c'est eux mêmes qui doivent explorer les données. Et la meilleur solution qu'on aient trouvé pour explorer des données librement... c'est OLAP.
Je ne suis pas grand connaisseur des technologies openSource en matière de BI, mais pour tes analystes, je te conseil de voir un outils qui permet de faire du OLAP sur des entrepôts de données. Pentaho pourrait être une piste

[chris81]

Certes OLAP est une technologie merveilleuse mais les produits l'utilisant sont extrêmement cher. Beaucoup d'autres produits aussi rapide et dynamique existe et sont beaucoup moins cher comme MyReport de Report-one.

[ygrim]

Merci pour MyReport, je vais y jetter un coup d'oeil, je veux surtout savoir sur quelle technologie il se base ??? si il execute des requêtes SQL sur l'entrepôt directement, sa va poser des problèmes de performance pour les gros entrepôts...
Sinon je sais que Pentaho possède un outil OLAP open source, certes c'est du ROLAP mais ça fait quand même l'affaire.

[Jean_Paul_XX]

Bonjour à tous

Je voudrais apporter quelques précisions :

Concernant MySQL :
Je n'ai pas remarqué une orientation particulière vers le Décisionnel. Je note cependant que Sun s'étant porté acquéreur, nous pourions assister à un élan vers le décisionnel. Ce ne sera pas de trop, je corrobore en effet les remarques de Ygrim : on est loin encore des solutions payantes, tout a un coût.

Concernant le DWH et la technologie OLAP :
Il ne faut pas tout mélanger : donner de la liberté aux utilisateurs finaux, c'est bien et c'est effectivement un des objets de la BI. Ce n'est cependant pas le DWH qui permet cette facilité. Il se 'contente' de mettre en ligne les informations de manière structurée afin qu'un produit de restitution puisse aller les extraire.
Donc, il existe une couche sémantique dans l'outil de BI qui permet d'une part de décrire de manière 'fonctionnelle' les informations en les regroupant par domaines 'Métier'. Elles sont ensuite présentées à l'utilisateur final dans un vocabulaire usuel, non-technique. Cet aspect contribue grandement à la facilité de mise en oeuvre d'un rapport, donc à des gains de productivité évidents.
D'autre part, cet outil va assurer toute la mécanique de l'interrogation, en construisant les requêtes suivant la syntaxe adéquate (MDX dans le cas du multidimensionnel physique, ou bien SQL das le cas justement du ROLAP). C'est également lui qui va autoriser les déplacements dynamiques dans la structure multidimensionnelle (drill, swap et slice).

En conclusion, si l'on note que l'outil de restitution proprement-dit a une grande importance également, il faut le resituer dans un contexte général ou l'on tiendra globalement compte :
- De l'environnement matériel
- De la volumétrie
- Des modules applicatifs mis en oeuvre
- De la capacité de l'équipe MOE à bien administrer techniquement et fonctionnellement le projet.

Pour conclure, j'aimerais savoir dans Report-one, ou se trouve cette couche sémantique ? Comment sont gérées les fonctionnalités OLAP citées ci-dessus ? Si c'est dans Excel, il va falloir que Ted Codd revoie sa définition du concept OLAP...

JPP

[ygrim]

Bonjour,
Tout à fait d'accord avec ce que vous dites.
À ce point près que des outils se basant sur SQL (je pense que c'est le cas pour ReportOne) ne peuvent techniquement pas assurer les spécifications de CODD pour OLAP et, surtout, les besoins des analystes. Car c'est pour eux finalement que les outils d'analyse et de Mining existent.


Les Entrepôt sont effectivement des structures de données, rien de plus, mais organiser les données en dimensions et en faits permet l'utilisation des technologies OLAP (MDX). Donc on peut dire que les entrepôts sont la meilleure manière que les gens ont trouvé pour stocker leurs données et OLAP, la meilleure façon de les explorer. De ce fait les DWH sont, malgré eux, le meilleur moyen d'accéder facilement aux données.


Quand à ROLAP, et bien j'ai cherché à comprendre l'avantage de modéliser des cubes en utilisant SQL et j'ai trouvé que les performances étaient la seulement si on ne passaient pas d'un gros niveau de détail à un gros niveau d'agrégation...Mais n'est ce pas la valeur ajoutée d'une solution BI ? Permettre une analyse, en ligne et en continue, de toutes les données à tous les niveaux. Ne doit on pas parler d'une solution de Reporting dans le cas contraire. Les gens (décideurs) ne font souvent pas la différence entre les deux concepts.

[Jean_Paul_XX]

Envoyé par ygrim

...
Les Entrepôt sont effectivement des structures de données, rien de plus, mais organiser les données en dimensions et en faits permet l'utilisation des technologies OLAP (MDX)...

Attention : OLAP ne signifie pas obligatoirement MDX. Le MDX est lié à la structure physique des données, donc au M-OLAP.
De fait, une solution de restitution peut interroger une base multidimensionnelle physique (dans ce cas on parle effectivement de MDX) ou bien virtuelle (qui peut également être modélisée en étoile).

Envoyé par ygrim

...
Quand à ROLAP, et bien j'ai cherché à comprendre l'avantage de modéliser des cubes en utilisant SQL et j'ai trouvé que les performances étaient la seulement si on ne passaient pas d'un gros niveau de détail à un gros niveau d'agrégation...

Il n'y a pas une solution meilleure qu'une autre, simplement deux solutions différentes qui présentent des avantages et des inconvénients propres, et qui s'adaptent à une situation donnée.
Un post intéressant décrit les structures et les avantages des deux techniques : http://www.developpez.net/forums/sho...d.php?t=400288

Envoyé par ygrim

...
Mais n'est ce pas la valeur ajoutée d'une solution BI ? Permettre une analyse, en ligne et en continue, de toutes les données à tous les niveaux. Ne doit on pas parler d'une solution de Reporting dans le cas contraire. Les gens (décideurs) ne font souvent pas la différence entre les deux concepts.

Oui, Oui, et fortement Oui !
Le Reporting permet la consultation d'informations sous forme de constat. L'Analyse (comme son nom l'indique) offre des moyens de compréhension de ce constat. La technologie OLAP qui autorise les déplacements dynamiques, en est un.

[thbar]

Hello,

pour apporter quelques éléments j'ai développé il y a peu un datawarehouse qui utilise Activewarehouse (librairie ruby) et rentre les données dans MySQL (voir mon article pour les références complètes).

J'ai choisi de m'organiser en créant des vues qui sont des jointures entre une table de fait d'une part et une ou plusieurs dimensions d'autre part, et en mettant en façade ou bien un Excel avec un pont ODBC, ou bien Tableau Software (voir le lien plus haut).

Les utilisateurs (non techniques) se servent ensuite de tableau croisé dynamique Excel sur les vues (ou bien avec Tableau s'ils l'ont sous la main, c'est encore plus simple).

Les temps de réponses sont tout à fait acceptables dans mon cas (avec des tables de faits avec 300k lignes et trois jointures dessus), en particulier quand on passe par Tableau Software, pourtant la machine est une desktop station tout à fait banale et je n'ai réalisé aucun tuning.

Je t'encourage à faire un prototype (disons sur un ou deux jours) en simulant le volume, si ça se trouve tu obtiendras une performance suffisante avec MySQL!

voilà, j'espère t'avoir apporté quelques éléments utiles.

Thibaut Barrère / LoGeek
--
http://blog.logeek.fr - about writing software
http://evolvingworker.com - tools for a better day