La librairie D3.js pour la visualisation des données: nouvelle réference

Jusqu’à présent Jasper-report régnait en force sur les solutions de visualisation de données dans le monde du décisionnel opensource.

 Une restitution Jasper-report  est construite sur le serveur puis elle est envoyée au client.
Or, la visualisation est avant tout une affaire de client. C'est bien l'utilisateur via son navigateur qui  doit pouvoir   manipuler et enrichir les  données. Aussi logiquement, le javascript prend toute son importance comme acteur majeur dans la chaîne  des restitutions.

Plusieurs bibliothèques sont présentes sur ce domaine. Mais dans lot une librairie se dégage : d3.js

Comme jquery dans le domaine de la navigation  d3.js prend le chemin de devenir le composant de référence.

(illustration tirée d'une présentation de d3.js lien ici)


Il est à la base du projet ndvd3.js .

Ou encore rickshaw

D'autres liens ici.

#nosql , decisionnel et #forumdecideo

Je suis intervenu au forum decideo lien ici , cet évenement a été d'une très grande qualité et très bien organisé (philippe Nieuwbourg) . Un intervenant avant moi : renaud FINAZ de Micropole Univers a fait une intervention brillante sur l'état de l'art dans le domaine du stockage des données au sens large du terme.

Je partage son analyse dans les grandes lignes:

Le volume de stockage n'est plus un problème : le Tera est accessible à tous pour moins de 100 euros.

Le volume d'information produit pour Internet en deux ans (2009/2009) est plus important que tout le volume d'information existant (X 5)


(source http://gigaom.com/2010/03/16/northscale/)

Toute cette information est en grande partie déstructurée.

Ainsi, ce n'est plus la donnée qui fait la richesse d'une entreprise c'est sa faculté de traiter cette donnée.

Le problème des performances.

Il y a deux point de contention possibles: alimentation et l'indexation (structuration) pour la restitution.

L'alimentation.
L'alimentation d'une base de données /entrepôt à partir des différentes sources de données.
Comment intégrer, contrôler , agréger des millions de lignes de données. Actuellement ces fonctions sont traités par des programmes en mode itératifs ligne par ligne ou en mode ensembliste par des opérations portant sur un ensemble de données.

Il es possible de paralléliser les traitements à conditions mais il faut le prévoir au préalablement. Ce parallélisme est rudimentaire : j'ai N sources de données je vais les traiter par N programmes lancés en même temps. Cette méthode est naïve car elle ne fait que déplacer le problème sur le moteur de la base qui lui traite les opérations en mode file d'attente (voir page sur ACID)

Il faut donc utiliser un système d'alimentation basé sur des traitements fortement 'concurrents' qui traitent avec des bases de données qui respectent le modèle ACID mais tout en étant capable de s'affranchir du modèle file d'attente (voir le théorème de CAP) de Brewer






Concernant les langages à utiliser.
Il n'y a pas de secret , regardons ce qui se fait chez les entreprise full web 2.0 (Facebook, twitter , amazon et google).

Les langages fonctionnels: Haskell mais surtout Erlang qui nativement est capable de travailler sur plusieurs nœuds de machine et de gérer la perte de serveur.
Scala le langage fonctionnel de twitter basé sur une JVM

Les langages hybrides: Ruby et Python

Tous ces langages possèdent des fonctions puissantes de MAP/REDUCE


L'indexation et la structuration des données.

Le calcul des agrégats ou la création des index est réalisable au moment du chargement des données ou a posteriori . Pour les agrégats et les index , il sera possible de paralléliser massivement les opérations de Map /Reduce.

Les bases à utiliser.



Tout sera fonction du type d'information à stocker .

• Pour des restitutions de documents!: CouchDB ou mongoDB (plutot hierarchique)
• Pour des cubes: prendre des bases orientées colonnes : cassandra, htable..

Les applications de gestion grignotent le secteur du décisionnel

(jasper ireport)

L'informatique décisionnelle a toujours été considérée comme un monde à part, avec ses éditeurs institutionnels (COGNOS/ SAS / BO / Microsoft)qui se partagent un filon hight-tech. Le décisionnel était le secteur informatique qui transformerait le plomb en or, aussi bien du point de vue des éditeurs que des clients. Ces dernières années, la frontière entre application de gestion et application décisionnelle est devenu floue. Le besoin de restitutions des applications de gestion a été comblé par l'utilisation des outils de restitutions livrés avec les suites décisionnelles. Ces suites étant fermées, c'est par terra de terra que des données ont été transférées ou même dupliquées vers des entrepôts de données uniquement pour des besoins de restitutions. Le mouvement est en train de s'inverser pour des raisons économiques : le décisionnel coute cher et stratégiques: d'autres secteurs empiètent sur ces terres.


Lorsqu'une application de gestion a besoin de restitutions nombreuses ou complexes, elle se heurte à l'organisation de ses données orientée gestion et non pas restitution. Il y a plusieurs solutions de contournement:
Sans duplication des données
* Faire cohabiter un deuxième modèle de données dans la même base. Ce deuxième modèle hébergera des tables en étoiles ou en flocon. Cette architecture est lourde et impacte directement les données de gestion.
* Faire héberger le modèle en étoile sur un deuxième serveur en utilisant des dblink (supportés par oracle et PostgreSQL )

Avec duplication des données.
* Utiliser des tables dénormalisées CAD qui ne respectent pas les trois formes normales , elles sont appelées aussi : tables dégénérées , dénaturées. Elles permettent de s'affranchir des jointures et introduisent de la redondance pour accélérer les restitutions.
* Utiliser des base de données clé/valeur au lieu d'un SGBDR. Le modèle en étoile est remplacé par un table unique entièrement indexée :solution basée sur couchdb , mongodb


Ces systèmes seront complétés par des outils de restitutions comme jaspereport , openflashchart et maintenant google chart.

(google)


(jasper ireport)



Il existe une nouvelle solution à tester : la base de données virtuelle. C'est ce que propose le projet TEIID de jboss.



Il permet d'offrir une vue différente et virtuelle de votre modèle de base de données.

En conclusion: les éditeurs de l'informatique décisionnelle ont mangé leur pain blanc. Leurs concurrents sont : SAP , leader de la gestion RH qui se lance dans une stratégie d'encerclement : réseaux sociaux, administration et BI. Mais aussi Google , qui maitrise tous les maillons de la chaine: stockage , moteur ,restitutions.
Pris en tenaille, les utilisateurs ont tout intérêt à se tourner vers des solutions opensource comme penthao , spagoBI ou jasper.

Le choix des restitutions pour du décisionnel

Ce schéma aide à choisir le meilleur type de graphisme pour des restitutions en décisionnel.

Décisionnel vs gestion : définir une application décisionnelle.

Où est la frontière entre une application décisionnelle et une application de gestion? . Qu'est ce qui peut définir une application décisionnelle ?. Voici les questions posées, place aux réponses.

Dans le cadre de mon travail, je suis confronté à ces deux familles d'application et je note une confusion dans leur classification. La question n'est pas anodine car elle conditionne souvent le choix des technologies à utiliser : soit une plateforme décisionnelle, soit un simple framework. Les conséquences ne sont pas neutres.

Les concepts qualifiant le plus souvent le décisionnel sont:

• La source des données
• Le caractère multidimensionnel
• Les restitutions
• Les simulations
  

La source des données.

La présence d'une multitude de source de données, hétérogènes n'est pas à lui seul un critère discriminant. Par contre la collecte de type aspiration ('pumping') des données qui seront contrôlées puis injectées dans un entrepôt de données est un élément fondateur d'un système décisionnel. La donnée sera intégrée puis historisée dans un processus qui fournira de la 'traçabilité' sur la donnée. Un vrai entrepôt doit permettre de suivre tout le cycle de vie de la donnée.
Cette notion de 'pumping' s'oppose à la notion de 'mashup' qui elle, n'intègre pas la fonction de prise en charge de la donnée. Dans le décisionnel, la granularité n'est pas la même que dans une application de gestion. Souvent le directeur financier va manipuler des agrégats en Keuros. Dans le même ordre d'idée, le processus d'intégration dans l'entrepôt sera tolérant sur la présence ou le format d'une donnée, alors que pour une application de gestion, la donnée doit etre exactement calibrée et présente.


Le caractère multidimensionnel.
Le cube avec un système OLAP est l'élément clé du décisionnel. Un tel système offre la possibilité de définir des axes d'analyse, à commencer par l'axe temporel
A partir de là, l'analyste pourra explorer son cube dans les dimensions souhaitées.
Un requêteur 'universel' viendra compléter la boite à outil mise à disposition.
C'est l'utilisateur final qui choisit la requête et son domaine et non plus le concepteur de l'application. Tel un peintre qui mélange ses couleurs à partir d'un nuancier: l'entrepôt de données.

Les restitutions.

L'utilisateur final doit pouvoir choisir son format de restitution à partir d'une liste de composant . Cela peut aller du radar en passant par l'histogramme en 3D jusqu'au simple fichier csv.

Un tableau de bord aussi sophistiqué qu'il soit n'est pas le propre d'une application décisionnelle. L'utilisateur doit pouvoir choisir ses indicateurs KPI, le format d'affichage etc.
Une application de statistiques ne relève pas non plus forcement du décisionnel, elle peut etre 'immunable' sans interaction possible.

Les simulations.
Enfin, la simulation est une fonction importante demandée par les décideurs. Comment va évoluer le marché ? , quelles seront les projections dans un an ou deux ?. Il faut pour répondre à ces questions, embarquer dans le système toutes une panoplie d'outil de modélisation mathématiques.


Ainsi le critère de classification repose en grande partie sur le type de l'utilisateur final. Dans le cas du décisionnel ,c'est l'utilisateur qui compose son application, il y aura autant de forme d'application que d'utilisateur. Le nombre d'utilisateur ayant les compétences pour tirer parti d'un système décisionnel est forcement limité.

En conclusion: Les éditeurs du décisionnel cherchent à prendre des parts de marché aux éditeurs traditionnels et réciproquement : voir l'exemple de SAP qui propose du décisionnel dans son ERP. Le parc d'application décisionnelle doit normalement être marginal par rapport à celui des applications de gestion.

Cubes MONDRIAN et ses clients

Dans l'informatique décisionnelle, les cubes sont des composants importants. Ils permettent de visualiser les données suivant des dimensions prédéfinies et de réaliser des transformations. Il est possible de 'creuser' les données jusqu'au niveau de détail , de les faire pivoter autour d'axes temporels ou géographiques.
Dans le domaine du logiciel libre MONDRIAN est le projet phare pour l'agrégation des données en cube. Si MONDRIAN fournit cette structure en cube, il faut lui adjoindre un programme qui lance des requêtes sur ces cubes et qui en restitue les résultats.

Exemple de cube :


Les requetes
Le SQL n'est pas aussi puissant ni adapté pour une structure multi-dimensionnelle, Le langage MDX (Multidimensional Expression) est utilisé comme interface d'interrogation.
Exemple de requête MDX :

SELECT { [Measures].[Store Sales] } ON COLUMNS, { [Date].[2002], [Date].[2003] } ON ROWS FROM Sales WHERE ( [Store].[USA].[CA] ) (source wikipedia)

Il est à noter que le langage MDX a été spécifié par un employé de Microsoft.
Le langage MDX peut etre encapsulé dans du XML devenant ainsi du XML/A (A pour Analyse)

Mondrian est donc un serveur de requete MDX et XML/A. Il transforme une requetes MDX en une série d'instruction SQL pour fournir un cube en réponse.
Mondrian est donc un moteur R-OLAP (R pour relationnel).

Les moteurs OLAP.

On distingue 3 familles de moteur OLAP: les R-OLAP , les M-OLAP et les H-OLAP

• Les R-OLAP : Relational Online Analytical Processing , ils s'appuient sur des bases de données relationnelles pour produire les cubes. Pour obtenir des temps de traitement corrects,il est nécessaire de recourir à des tables dites 'pivots' (en étoile ou en flocon) . Un pivot représentant un axe du cube (exemples: l'axes temporel , l'axe géographique )

Une table pivot contient une série de clé étrangère et des données agrégées.

Mondrian qui est de type R-OLAP propose d'utiliser en plus des "tables d'agrégation" contenant des données déja pré-calculeés. Le but étant toujours d'obtenir des temps de réponse corrects.

• Les M-OLAP : Multidimensional Online Analytical Processing. Dans ces moteurs, les cubes ne sont pas issus d'une base de données relationnelle mais directement d'un système capable de stocker et de restituer des données multidimensionnelles. Une requete MDX ne générera pas de SQL.

• Les H-OLAP : Hybrid Online Analytical Processing. C'est une combinaison de deux modes précédent. Le cube, issu d'une agrégation de table relationnelle est stocké pour restitution dans un format plus adapté à l'analyse multidimensionnelle.

Les clients OLAP.
Le rôle du client est de générer de requêtes MDX ou XML/A , d'afficher le cube résultat et d'offrir des outils de manipulation des cubes.

JPIVOT
Il existe plusieurs projets open-source de client OLAP dont le plus connu est jpivot (suivre ce lien vers le projet).

Voici une copie d'écran de jpivot:


Une description des modifications du cube est donnée sur le blog de cedric Carbone (suivre le lien ici).

(extrait de l'article)



1e : Ajouter ou enlever des champs
2e : Editer la requete MDX
3e : Trier
4e : sauvegarde (dans spago BI uniquement)
5e et 6e :fusion de colonne
7e : a completer
8e : Supprimer des lignes blanches
9e : Intervertir les lignes et les colonnes
10e 11e 12e 13e: Drill (zoomer ,agreger,detailler)
14e 15e : Générer des graphismes
Les 3 derniers icônes permettent de définir les options d’impression PDF et d’exporter en PDF ou en XLS (MS Excel ou openoffice).

JPIVOT est avant tout une librairie de TAG JSP et c'est à l'administrateur de développer son interface graphique.

JPALO



Jpalo est une surcouche à jpivot. Il est moins puissant que ce dernier.

Il est aussi disponible en plugin Eclipse



Pentaho Analysis Tool (PAT)

Outil proposé dans la suite BI Pentaho, il est possible de le faire fonctionner sans Pentaho.


Le projet n'est pas très actif (suivre ce lien).

Jrubik

(site du projet)
Basé aussi sur les librairie de jpivot, son architecture est la suivante:




Quelques exemples







Le client à construire: rpivot.

Il serait possible de faire une synthèse des projets suivants en proposant l'architecture suivante:

La partie restitution: Rails (exemple rpivot) : Cette interface permettrait de generer des requete XML/A vers un serveur Mondrian. Avec une bonne dose d'AJAX pour les fonctions de mise en forme et de navigation.


La partie protocole : XML/A

La partie cache: L'utilisation de couchDB comme système de cache aurait deux objectifs: Transformer MONDRIAN en modèle Hybride sans toucher au coeur du produit. Pour cela c'est la partie cliente qui serait responsable de la gestion du cache. En plus couchDB par le biais de ses procédures embarquées pourrait servir à faire des calculs locaux (moyenne) . CouchDB propose des fonctions comme MAP et REDUCE.