Architecture BI - Demande d'avis

Salut à tous,

j'aimerais avoir un avis sur notre architecture de BI, dont j'ai "hérité" mais que je trouve assez complexe à maintenir.

Je travaille dans une société de ecommerce, dont la prod repose sur un système LAMP (Linux apache Mysql PHP).

Toutes les nuits :
- les données de notre base de données de prod (mysql) sont extraites via Talend et mise dans une autre base de données Mysql, que nous appelons DWH (datawarehouse)
- les données de ce DWH sont ensuite extraites par Jedox/Palo pour alimenter des cubes OLAP qui eux mêmes sont utilisés par Excel via un plugin pour les restitutions
- les données de ce DWH sont aussi accédées via des rapports Access/Excel pour les rapports one-shot, mais cela fonctionne assez mal

Dès que nous souhaitons modifier un traitement ou créer un nouveau rapport, cela fait beaucoup d'étapes et de technos à utiliser :
- création du job Talend pour extraire la donnée
- modification du schéma du DWH
- création du job Jedox pour extraire la donnée vers les cubes
- modification du schéma du cube si besoin
- création du fichier excel afin de fournir un rapport

C'est donc assez puissant, mais très lourd aussi ... N'ayant pas bcp d'expérience en BI, j'aimerais avoir l'avis de personnes qui en ont ... En espérant ne pas avoir été trop long/chiant ...

Merci beaucoup !

La question que je me pose en lisant ton archi est quel est ton moteur OLAP et jedox est utilisé seulement en tant que ETL ?

Le moteur OLAP est Jedox, l'ETL principal est Talend mais nous utilisons aussi l'ETL Jedox pour charger les cubes OLAP Jedox.
Jedox fait aussi la partie reporting/restitution.

Hello,

Je ne connais pas jedox/palo donc je ne me prononcerai pas dessus.

Par contre s'il faut créer un nouveau rapport normalement il y a juste de l'excel à faire, voire un peu d'OLAP.
Si ce n'est pas le cas c'est que le DWH est mal conçu, il doit pouvoir répondre aux besoins futurs de restitution sans être modifié (enfin, dans la majorité des cas).

Pour éviter de modifier les cubes une solution est d'avoir un SDBD en colonnes / inmemory qui offre des temps de réponse impressionnants (proches ou égaux à ceux d'un cube OLAP) sans devoir perdre du temps à alimenter un cube. C'est le cas de Sybase IQ, SAP HANA et bientôt Oracle 12c avec l'option inmemory. Si tu utilises mysql tu peux regarder du coté de infinidb.

Sinon c'est une architecture standard en BI. Il faut une base de données, un ETL et un outil de restit au minima.
On peut s'affranchir de l'ETL avec une réplication SGBD standard, mais dans ce cas on n'a plus de vrai DWH ...

Salut,

merci pour ton retour, c'est intéressant. J'ai qq questions additionnelles.

Citation:

---

Envoyé par doc malkovich

Hello,
Pour éviter de modifier les cubes une solution est d'avoir un SDBD en colonnes / inmemory qui offre des temps de réponse impressionnants (proches ou égaux à ceux d'un cube OLAP) sans devoir perdre du temps à alimenter un cube. C'est le cas de Sybase IQ, SAP HANA et bientôt Oracle 12c avec l'option inmemory. Si tu utilises mysql tu peux regarder du coté de infinidb.

---

J'ai un peu regardé infinidb et ce que j'en comprend c'est que c'est une base mysql hyperrapide en consultation, cependant, ca ne propose pas vraiment d'outil de restitution non ?
Ou le verrais tu dans notre architecture ?

Merci !

Hello,

En effet c'est une base de données, point.
C'est pour remplacer la base MySQL + les cubes OLAP.
Et du coup PALO et Jedox seraient à mettre à la benne c'est ça ? 8-)
Je ne connais pas PALO, je ne sais pas s'il peut accéder à autre chose que ses cubes ?

Côté restitution tu peux y accéder à partir de Excel (enfin je pense, je n'ai pas vérifié).
Après il existe d'autres outils de restit bien plus polyvalents que PALO, comme BIRT par ex en opensource ou SAP Business Objects en payant.

A+

Bonjour,

Concernnat une architecture BI traditionnelle, il faut comme outils :

• Un ETL
• Une base de données relationnelle
• Un outil de restitution

Dans ton architecture tu possèdes :
2 ETL

• Talend
• Jedox_ETL pour l'alimentation du cube PALO)

2 serveurs de base de données

• MySQL comme SGBD-R du DWH
• PALO comme SGBD-M

Pour l'ETL, et en vue d'uniformiser l'architecture, on pourrait tout faire depuis Talend qui sait s'interfacer avec Palo.

Pour les serveurs de base de données, cela dépend des Usages qui sont nécessaires.
Pour la partie reporting, tu évoques Excel qui vient donc interroger les cubes PALO. Pour moi ce n'est plus du reporting, c'est de l'analyse. Je m'explique, si l'utilisateur dans Excel a la possibilité de se promener dans ces données via le menu de navigation (un peu comme avec un tableau croisé), je parle d'Analyse. Le reporting pour moi est plus cantonné a des informations statiques comme on l'a généralement avec un PDF.

Donc :

1. Si les besoins des utilisateurs se rapprochent de l'analyse, alors ton architecture de restitution est parfaite. MySQL > ETL(Jedox_etl) > Palo > Excel
2. Si les besoins se rapprochent du reporting, alors on peut se demander pourquoi un moteur OLAP tel que PALO, et Excel qui n'est pas bien positionné. Dans ce cas je verrai plus un outil de reporting tel que Jasper ou Birt.

Comme ton architecture semble reposé sur des produits Open Source, je ne te parlerai pas des offres avec des licences payantes.

Cdlt