Architecture OLAP / Client Léger et lourd NRJ renouvelable

[Ecosmose]

Bonjour,

Avant de me lancer dans ma 2ème création d'une base OLAP (j'en ai déjà fait uniquement en developpement, pas en conception ni déploiement), je souhaitais vous consulter pour profiter des expériences de chacunsur la pratqiue de la théorie de l'informatique décisionnelle et de ses solutions OLAP.
Je me permet donc de vous présenter mon projet OLAP pour que vous puissiez m'orienter vers une bonne résolution de mes besoins. J'espère que vous aurez des pistes ou des commentaires à m'exposer. Peut être que le domaine fonctionnelle suscitera votre curiosité ou votre interêt : c'est celui des énergies renouvelables.

Je vais (re)créer un système de pilotage et d'analyse de l'exploitation de nos parcs éoliens et solaire 'from scratch' (je travaille pour un concepteur, constructeur, exploitant et producteur). C'est à dire que je casse tout le boulot que a été fait avant 'en mode labyrinthe excel' et que je fais à ma sauce.
Le but est de construire un système capable d'agréger des données de production et d'exploitation qui formeront la population de la BD (ces données varient dans donc le temps ce qui engendre des statistiques différentes). ces données sont issus des journaux de pannes, des données comptage, des mains courantes, etc... donc de plusieurs sources de données hétérogènes et de plusieurs centrales. L'objectif est de fusionner et de présenter ces informations selon différentes dimensions et de proposer aux responsables des centrales des rapports analytiques pour optimiser leur pilotage (selon zone géo, type d'éolienne ou d'onduleur, vue temporelle, cumulée, énergétique etc...). En extrapolant, l'idéal serait un outil qui leur permette de générer leurs propres modèles de rapports (dynamiques) qu'ils pourraient décliner à volonté sur des dimensions choisies (temps, climat, zone, lieu, type de modèle de matériel, etc...). OLAP est bien taillé pour cela, n'est ce pas ?

Je pense utiliser SQL Server 2005 ou 2008 vu le peu d'utilisateurs concurrents, une volumétrie des données assez grosses (la durée de vie de nos centrales est d'au moins 20 ans, la période d'acquisition est 10min !). Le cout est aussi un facteur déterminant. MySQL ne garantie pas l'intégrité de la base (les structures de mes données d'entrées peuvent varier, par exemple un changement de Firmware des SCADA ou des datalogger)

Je suis tout seul à concevoir, développer et tester le projet. J'essaye donc de verrouiller une solution en déterminant un système et un EDI efficace, robuste et éprouvé pour ne pas dériver sur mon planning. L'utilisation d'"Integration Services" (MS SQL Server 2005 & 2008) parait tout indiquer pour l'import / export de sources de données externes (nous travaillons avec des csv, OPC server, fichier 'propriétaire' ). Cela me facilitera et accélèrera grandement cette tâche.

Des idées ? des exemples ?

[Ecosmose]

Je peine à choisir les Framework qui me feraient gagner du temps concernant les solutions Clients/Serveur. Plusieurs solution Business Intelligence offre une gestion des états / reports + ou - étoffée . La cible est une application client lourde puis par la suite, un greffon client léger pour nos collègues des DOM-TOM via le net. Pour ces derniers, un serveur Web rassemblera les données statistiques calculées tous les mois pour les représenter sous des tableaux de bord et graphiques multi-dimension (JFreeChart parait très adapté pour une solution lourde et légère). L'appli lourde quant à elle pourra générer dynamiquement ces rapports, toutes périodes confondues (et donc gros calculs en perspective ). En fonction des performances, nous verrons ce que nous pourrons proposer de + pour le client léger.

En ce moment, je recueille et rédige les besoins globaux, j'ai presque fini. En // je tache de choisir mon urbanisme logiciel (briques applicatives, services et frameworks) puisque mon architecture technique est quasi déterminée (un serveur BD, un ou des serveurs applicatifs, 2 types d'appli cliente dont un peu de SGI google map).

Je suis un habitué des méthodes agile, avec des cycle spiral (méthode MACAO de mon directeur de recherches, Mr Crampes ex-doyen de l'université de Toulouse que je remercie au passage). Un des buts est de jalonner au plus fin mon travail pour que les utilisateurs bénéficie au mieux des foinctionnalités pour affiner de + en + leurs besoins (un jalon pour le cycle specs/conception/dev./test/validation qui se résumera certainement à une fonctionnalité à la fois). Une mutualisation du travail du client lourd sur le client léger serait aussi idéal pour ne pas refaire sur l'un ce qui a déjà été fait sur l'autre (je pense aux générations d'état et des graphiques associés)

Je m'oriente petit à petit vers une appli lourde Java exploitant des services JasperReport pour la présentation des rapports.

Voila, pour mon projet. Si vous avez des pistes de solution...

En espérant vous faire partager le fruit de mes recherches et de mon travail par la suite (je suis très orienté open source où je participe à quelques projets). Et pourquoi pas un travail collaboratif pour les + intéressés ?

Merci pour vos présentations et vos futures réponses.

[Ecosmose]

Re !

Je suis en train de tester plusieurs combinaisons opérationnel et de developpement. Je m'oriente vers

SGBD : SQL Server 2005 (NBous avons déjà des licences).

OLAP BI : Microsoft Services, IcCUbe, QlikView, Jasper -> Je priviligie l'open source vue le budget de ce projet

Client lourd : JAVA

Client léger : JSP / PHP

Server Web : A voir selon le choix du Olap, il existe des solutions intégré de Web Service d'après ce que j'ai lu des OLAP.

EDI : NetBEans ou Eclipse -> J'ai tendance à travailler avec les 2.
NetBEans pour les interfaces et appli clients avec son beau designer.
Eclipse pour les batchs ou serveur applicatif
Je fais la modélisation avec les deux selon le projet.

Y a t il des benchmark comparatif ?
Des idées ?

[Marc Polizzi]

Envoyé par Ecosmose

Client léger : JSP / PHP
Des idées ?

Avec icCube, il y a la possiblité d'écrire des "pages webs" directement; une API Javascript permettant de se connecter pour executer du MDX par exemple. Voici une page (http://www.iccube.com/products/iccub...-web-reporting) qui vous donne une idée; cette page va très prochainement être remplacée par une version qui se connecte directement sur un serveur icCube; l'utilisation de différents charts (e.g., Google Visualization, ProtoVis, etc..) sera démontrée ainsi que l'ajout d'actions de drilldown et navigation entre les charts.

Envoyé par Ecosmose

Server Web : A voir selon le choix du Olap, il existe des solutions intégré de Web Service d'après ce que j'ai lu des OLAP.
Des idées ?

icCube intègre un serveur web mais nous conseillons en production de le placer derrière Apache par exemple. La prochaine version (1.3) facilitera cette intégration.

[Prjprj]

Si vous avez déjà des licences SQL-Server, vous avez normalement les outils BI Microsoft avec :
SSIS (SQL Server Integration Services), SSAS (SQL Server Analysis Services), SSRS (SQL Server Reporting Services). La version R2 de SQL-Server 2008 est tout à fait convaincante.

Sinon, dans les outils open-source, il existe aussi BIRT qui dispose d'un plug-in Eclipse.
Il existe un viewer JSP déployable assez facilement sur un serveur Tomcat.

Mon opinion personnelle est que si vous avez dejà des licences M$, c'est la solution la plus simple à mettre en place, tous les outils s'intègrent facilement.
Par contre, pour du client léger, cela impose du .Net.

[Jester]

Je dirais que c'est très axé technique. C'est pas un tord, mais ce n'est pas forcément optimal. Le besoin ne me semble pas très clair. Remplacer un labyrinthe excel n'est pas un besoin.

1 - quels sont les besoins? Avoir des données à 10 minutes c'est bien, mais s'ils ont un excel pour l'instant j'en déduis qu'ils ne sont pas à 10 minutes d'interval.

2 - quels sont les clients? Si c'est l'upper management, peu de chance qu'ils veulent une application, ni même un rapport qu'ils ont à chercher, ni même un rapport automatisé. Si c'est du contrôle de gestion, ils voudront du Excel pour trifouiller.

3 - quels sont les moyens? Mettre en place des appli Java ça demande du temps. Pareil pour le data warehouse. Cela demandera aussi du temps en maintenance. Le projet est bien, mais il faut voir ce qui est important dans le présent et ce qui serait cool mais pas vital.

[Ecosmose]

Merci Jester, Marc et Prjprj

Envoyé par Jester

Je dirais que c'est très axé technique. C'est pas un tord, mais ce n'est pas forcément optimal. Le besoin ne me semble pas très clair. Remplacer un labyrinthe excel n'est pas un besoin.

1 - quels sont les besoins? Avoir des données à 10 minutes c'est bien, mais s'ils ont un excel pour l'instant j'en déduis qu'ils ne sont pas à 10 minutes d'interval.

Remplacer un Labyrinthe est toujours un besoin lorsque l'on ne dispose plus d'un fil d'Ariane... ou que l'on ne connait pas les plans et surtout quand plusieurs personnes utilisent les mêmes fichiers sans forcément connaitre leur fonctionnement. le besoin est avéré fonctionnellement, c'est la technique qui me bloque car notre domaine est en plein essor et je souhaiterais que les décisionnaires et responsables centrales puissent créer et générer eux-mêmes lerus états/rapports. pour les partager aux autres responsables et les décliner chaque mois et sur chaque centrale.

-> En effet, sur Excel, ce serait trop lourd (pas assez de lignes) sur une longue période, les méandres de ce labyrinthe se répètent de mois en moins uniquement sur les données du mois passé. Les résultats sont stockés dans des synthèses mensuelles (un des rapports que je dois générer par exemple).

Je pensais que mon besoin avait correctement été défini , je ne peux pas te déposer le cahier des charges, je pense que tu n'aurais pas le temps de le lire ^^. Plus sérieux, le but est de collecter les données opérationnelles pour générer les informations décisionnelles. A partir des données de production et des données climatiques, on obtient le rendement ou le comportement des centrales proportionnellement au climat (soleil, vent). On pourra ensuite rapprocher ces informations par rapport à des abaques théoriques de production, on rapprochera les disponibilités des machines selon leur plan de maintenance, observer et comparer la production des machines, anticiper les maintenances en constatant un nombre trop récurent de défaut (selon la centrales (dimension géographique) mais aussi selon les modèles de machine qui peuvent être installée sur plusieurs centrales (dimension machine).

Envoyé par Jester

2 - quels sont les clients? Si c'est l'upper management, peu de chance qu'ils veulent une application, ni même un rapport qu'ils ont à chercher, ni même un rapport automatisé. Si c'est du contrôle de gestion, ils voudront du Excel pour trifouiller.

3 - quels sont les moyens? Mettre en place des appli Java ça demande du temps. Pareil pour le data warehouse. Cela demandera aussi du temps en maintenance. Le projet est bien, mais il faut voir ce qui est important dans le présent et ce qui serait cool mais pas vital.[/QUOTE]

Les moyens ? c'est moi plus sérieusement, je dispose d'un petit budget car la filière a été durement touché par le moratoire de début d'année. Je dirais que ce n'est pas la mise en place JAVA qui demande du temps mais leur création. Je suis d'accord avec toi pour aller à l'essentiel. Il faut cependant que je pose la bonne architecture pour faire évoluer le système sans entrevoir tout de suite d'éventuelles migrations...

[Ecosmose]

Envoyé par Prjprj

Si vous avez déjà des licences SQL-Server, vous avez normalement les outils BI Microsoft avec :
SSIS (SQL Server Integration Services), SSAS (SQL Server Analysis Services), SSRS (SQL Server Reporting Services). La version R2 de SQL-Server 2008 est tout à fait convaincante.

Sinon, dans les outils open-source, il existe aussi BIRT qui dispose d'un plug-in Eclipse.
Il existe un viewer JSP déployable assez facilement sur un serveur Tomcat.

Mon opinion personnelle est que si vous avez dejà des licences M$, c'est la solution la plus simple à mettre en place, tous les outils s'intègrent facilement.
Par contre, pour du client léger, cela impose du .Net.

Les licences de SQL Server sont des standard 2005 (et non 2008). Les outils BI n'y sont pas intégrés comme la version Entreprise.

EN effet, j'ai reçu le devis d'une licence SQL Server 2008 R2 + 5 CAL = 1700 € HT. je pense que ce sont les seuls crédits que l'on m'accordera... on verra.

Niveau technique, j'ai estimé la volumétrie de nos centrales actuelles avec 10 ans de données , c'est presque 200 Gigas avec données opérationnelles et décisionnelles. Je cherche une solution qui pourrait permettre aux users de créer des modèles de rapports , j'ai vu que crystal reports avait bien cibler de besoin de scinder logique technique et logique décisionnelle. Un développeur n'a pas forcément les connaissances du métier qui lui permette d'utiliser ou de calculer les indicateurs pertinents de la profession. C'est un peu mon cas, même si je monte bien en compétence dans les NRJ renouvelables, je n'en suis pas moins devenu un électrotechnicien.

La fusion Crystal et SQL server Services parait à priori correcte mais cela m'oriente vers du .NET pour le léger et le lourd (cela ne me dérange pas) alors que j'aurais voulu + m'orienter vers de l'open source et un travail collaboratif.

[Jester]

Postgresql est une base de données solide que je préfère à SQL Server 2008 (je n'ai pas testé la R2). Par contre après ce sera plus galère pour la partie report dynamique.

Pour l'ETL, j'utilise Kettle qui est tout à fait correct. Le bulk loading dans Postgresql est vraiment très rapide.

> La puissance des outils BI actuels leur permet d'exporter des données selon plusieurs formats dont Excel.

Cela veut dire qu'il y a déjà une infra BI dans l'entreprise?

L'avenir de Crystal est assez sombre. Microsoft a sa solution et BO aussi. Mais je ne connais pas assez le logiciel pour avoir un avis sur sa qualité.

[Prjprj]

Envoyé par Ecosmose

Niveau technique, j'ai estimé la volumétrie de nos centrales actuelles avec 10 ans de données , c'est presque 200 Gigas avec données opérationnelles et décisionnelles. Je cherche une solution qui pourrait permettre aux users de créer des modèles de rapports , j'ai vu que crystal reports avait bien cibler de besoin de scinder logique technique et logique décisionnelle. Un développeur n'a pas forcément les connaissances du métier qui lui permette d'utiliser ou de calculer les indicateurs pertinents de la profession. C'est un peu mon cas, même si je monte bien en compétence dans les NRJ renouvelables, je n'en suis pas moins devenu un électrotechnicien.

Hum, 200 Go c'est pas un petit entrepôt de données que l'ont fait sur le pouce, il y a besoin d'une infra assez lourde et d'une architecture assez solide. Sans investissement de la part de vos managers, c'est franchement risqué...

[Ecosmose]

Envoyé par Prjprj

Hum, 200 Go c'est pas un petit entrepôt de données que l'ont fait sur le pouce, il y a besoin d'une infra assez lourde et d'une architecture assez solide. Sans investissement de la part de vos managers, c'est franchement risqué...

Je suis d'accord. L'infrastructure va monter progressivement en puissance tant au niveau matériel que la couverture fonctionnelle.

Dans un premier temps, nous délimiterons le périmètre pour ne considérer que certaines données opérationnelles... c'est à mon avantage pour que je puisse monter en compétence sur BI et pour je puisse fixer la bonne solution technologique.

Les questions d'architecture et de structure dépendront forcément de ce périmètre fonctionnel, mais je reste surtout désireux de pouvoir offrir une création de rapport réutilisable par les utilisateurs et non pas par programmation. Il semblerait que Crystal soit une bonne option mais ma philosophie et celle de l'entreprise est + orientée open source pour pouvoir participer au travail collaboratif. Je me penche actuellement sur une intégration d'iReport car l'appli cliente parait simple et légère...

Que me conseilleriez vous pour l'emploi d'un client d'édition et de création de modèle d'état utilisé par les utilisateurs finaux ? peut on l'intégré dans une appli ?

Merci.

[Prjprj]

L'optique de Crystal c'est du Reporting de masse développé par un développeur et les utilisateurs se contentent de recevoir les rapports et les consulter.

Si l'on suit cette optique, je pense que Jasper Reports est le plus indiqué (l'outil de dev c'est IReport).
Il y a aussi BIRT dans cette optique mais c'est dédié à des rapports plus complexes et l'outil de développement est moins facile d'accès.

Pour que les utilisateurs réalisent eux-mêmes leurs rapports, il faut une solution propriétaire :
BO/Cognos/OBIEE pour des outils en client léger/semi léger (en navigateur, via applet Java ou non)
Qlikview/Microsoft SSRS pour des clients lourds assez faciles d'accès (la couche accès aux données est à réaliser par des développeurs, la partie présentation peut se faire par n'importe qui)

[Ecosmose]

Yes yes yes, PrjPrj, ça se précise...

Et concernant des API de création de rapport qui s'intègre dans des clients légers ou lourds ? attention, je ne parle pas d'intégrer l'API dans une simple fenêtre mais de bénéficier d'une bibliothèque qui propose d'implémenter un concepteur graphique d'état...

Ouai, c'est assez spécifique mais l'emploi de framework me ferait gagner un temps. Sinon, c'est une de mes prochianes taches que de fabriquer un concepteur d'état où j'utiliserais un Bi open source pour permettre aux utilisateurs de créer leurs états... ça peut être aussi très formateur finalement.

[Prjprj]

Hum, développer un outil de design pour un projet de ce genre me parait équivalent à chasser la mouche au bazooka...

Enfin bon, pourquoi pas

Pour ce qui est de l'API Jasper, je passe mon tour, j'y connais rien

[Ecosmose]

Envoyé par Prjprj

Hum, développer un outil de design pour un projet de ce genre me parait équivalent à chasser la mouche au bazooka...

ça résume bien le personnage aussi

Plus sérieux, je vois aussi pour l'avenir, on est sur une solution BI, à terme,il n'y a pas que ces données opérationnelles qui seront introduites, nous espérons construire encore d'autres centrales renouvelables (on se dirige aussi vers la biomasse et marée motrice) même si le contexte actuel est compliqué. Des solutions technologiques vont aussi apparaitre ou d'autres, indépendantes pour l'instant , pourront être raccorder par extrapolation (stockage, prévision de production par rapport à la météo, cartographie des vents etc...). Se basant sur des énergies naturelles fluctuantes (vents, soleil,etc...), les statistiques sont très demandées et utilisées dans notre domaine.

Pour Jester
> La puissance des outils BI actuels leur permet d'exporter des données selon plusieurs formats dont Excel.

Pardon, c'était à mettre au conditionnel
> La puissance des outils BI actuels leur permettrait d'exporter des données selon plusieurs formats dont Excel.

[Jester]

C'est vrai que ce n'est pas un petit projet. Néanmoins, on aimerait tous que l'utilisateur fasse ses propres reports, histoire d'aller faire du golf.

Pour ma part je n'y crois pas trop. Faire un report est un art qui se travaille. Surtout c'est chiant à réaliser techniquement (j'ai utilisé Cognos, BO et BIRT).

Tel que je le vois je ferais juste un/des cube(s) visualisé par excel pour que les gens puissent extraire les parties qui les intéressent (du genre je voudrais pour chaque 10 minutes cet indicateurs sur la semaine 36 de l'an dernier). Bref juste pour faire des extraction en excel qu'il travaillent ensuite manuellement.

D'un autre coté faire des reports analytiques (comparatif production réelle, production théorique de l'abaque, tracking des events), bref des reports informatifs en pdf pour que ça soit en bonne résolution.

Les cas où j'ai vu des reporting en self services, ça demandait beaucoup de support et générait beaucoup d'erreurs. De plus les utilisateurs vont toujours vouloir un truc qui n'est pas encore disponible en self service. Non le plus simple c'est que ce soit la BI qui dirige l'entreprise ... ah je vais trop loin là?