Decideo - Actualités sur le Big Data, Business Intelligence, Data Science, Data Mining

Abonnez-vous gratuitement à Decideo !


Decideo

 


Comparatif entre Digdash et QlikView


Rédigé par par Jean-Marc DUPONT, 6IT le 13 Avril 2011

La nouvelle génération des outils de BI est en plein essor en ce moment. Qlikview a été l'un des précurseurs, mais ses concepts étaient apparamment en gestation chez ses concurrents car d'autres solutions n'ont pas tardé à voir le jour.



Jean-Marc DUPONT, fondateur de 6 IT
Jean-Marc DUPONT, fondateur de 6 IT
Rappelons d'abord les principes de ces nouveaux outils :
  • L'affichage des données n'est plus figé et conditionné à l'envoi de requêtes à une base de données (relationnelle ou OLAP) mais tout ou partie des données est chargée en mémoire (du poste client et/ou du serveur), ce qui donne une grande réactivité aux tableaux de bord et une interactivité qui permet d’accélérer l'analyse et la prise de décision.
  • Tout ou partie des axes d'analyse (ou des dimensions) est disponible pour l'utilisateur, qui va pouvoir progressivement raffiner son analyse.
    Un indicateur va pouvoir être analysé selon l'ensemble de ses axes d'analyse, à la demande.
  • Les tableaux de bord / graphiques / tableaux sont interactifs : un clic sur une zone d'un graphique va permettre de zoomer (descendre dans le détail) sur une donnée ou filtrer les informations sur cette donnée
    Associée à la disponibilité des données en mémoire, ceci permet à l'utilisateur d'analyser très rapidement ses informations et identifier les problèmes / axes d'amélioration
  • Des fonctions de simulation sont fournies qui permettent de faire varier un ou plusieurs paramètre et analyser en temps réel leur impact sur les autres indicateurs

En dehors de Qlikview, je travaille aujourd'hui avec la solution Digdash et j'ai voulu faire un comparatif entre les 2 outils qui se rapprochent assez en termes de fonctionnalités.
Je me suis également appuyé sur les compétences d'un partenaire intégrateur de Qlikview pour valider certains points de Qlikview que je ne connaissais pas forcément en détail.


Architecture technique

Il y a tout d'abord une grosse différence en termes d'architecture technique, qui peut être un premier facteur de choix en fonction du contexte de l'entreprise :
  • Qlikview repose sur une architecture Windows, que ce soit pour son client riche (logiciel Windows) ou ses serveurs applicatifs et Web (Windows Server / IIS)
    Ce qui le destine en priorité (mais pas seulement) aux entreprises ayant déployé leur SI sur une architecture Windows
    Si Qlikview est déployé sur un serveur Web IIS, les tableaux de bord sont disponibles sur navigateur web (Internet Explorer en priorité, mais aussi Firefox, Chrome et Safari, avec un moins bon rendu)
    A noter que toutes les fonctionnalités d'affichage ne sont pas disponibles sur tous les navigateurs Web.
    A noter également que Qlikview travaille actuellement sur un client web full HTML qui sera disponible sur les plate-formes mobiles (smartphones et tablettes).
  • Digdash repose sur un serveur applicatif développé en java, fonctionnant par défaut avec Tomcat et Apache comme serveur Web
    Le client fonctionne sur un navigateur web moderne (Firefox, Chrome, Safari et Internet Explorer 7, 8 et 9)
    L'ensemble est donc déployable au choix sur des serveurs Windows ou Linux et des terminaux Windows, Mac, iPad, Android, ...

Internationalisation

En termes de déploiement international, Digdash est conçu de base pour fonctionner en mode multilingue : l'ensemble des libellés (axes, indicateurs) peut être défini dans diverses langues et s'adapte en fonction de la langue de l'utilisateur. Les libellés des dates varient également en fonction de la langue de l'utilisateur.

Qlikview ne gère pas nativement le multilingue. Il est cependant possible de mettre en place un mécanisme de traduction des libellés dans l'interface en les remplaçant par des fonctions retournant le texte.
Il vaut donc mieux prévoir cela dés le départ et seuls les textes sont traduits, pas les noms des champs ni des tables. On profite donc de la souplesse de l'outil pour compenser en partie une fonctionnalité importante qui manque.

Gestion des utilisateurs / des droits

Digdash gère les utilisateurs dans un annuaire LDAP embarqué ou dans l'annuaire de l'entreprise.
Les droits sont gérés sur 3 niveaux :
  • Les autorisations (Afficher un tableau de bord, Editer un tableau de bord, ...) peuvent être attribuées à un utilisateur
  • Les groupes d'autorisations permettent de regrouper des autorisations et les attribuer à un utilisateur
  • Les profils permettent de donner des accès aux sources de données (voir plus loin) et aux graphiques des tableaux de bord

Qlikview peut gérer la sécurité lui même ou se connecter à un annuaire d'entreprise (en gérant utilisateurs ou groupes).
On distinguera :
  • La sécurité au niveau du portail pour définir qui a accès à quelle application,
  • La sécurité au niveau des fonctions dans l'application (droit de rafraîchir, droit d'exporter...),
  • La sécurité pour la visibilité des éléments (affichage conditionnel des onglets ou des objets),
  • La sécurité des données pour masquer tout ou partie des informations de la base en mémoire, voir pour publier des applications réduites aux seules données autorisées.

Sources et modélisation des données

Digdash sépare clairement la notion de "Modèle de données" et la visualisation de ces données.

Les modèles de données décrivent :
  • La source des données (base de données, fichier CSV, Excel, ... mais aussi Rapport Business Objects ou Cognos, Cube OLAP),
  • les dimensions qui y sont définies (avec leurs hiérarchies éventuelles),
  • les indicateurs (bruts, ou calculés à partir des indicateurs bruts),
  • la fréquence de rafraîchissement de ces données.

Ces modèles de données sont ensuite utilisés dans les graphiques ou les tableaux. On définit ici :
  • le mode d'affichage (courbes, colonnes, camemberts, cartographie, ...),
  • les axes et indicateurs qui y seront affichés,
  • leurs paramètres d'affichage et de navigation (zoom, filtre, ...).

On assemble enfin les graphiques et les tableaux dans les pages du tableau de bord.

On conçoit donc plusieurs modèles de données (qu'on pourrait appeler "cubes") élémentaires et indépendants et on les utilise au gré des besoins au sein du tableau de bord.
Le lien entre les différentes sources de données se fera, si besoin, par le nom des axes d'analyse communs aux sources de données.
La conception et la maintenance s'en trouvent grandement simplifiées.

Qlikview, quand à lui, va un peu loin dans la partie alimentation des données, à l'aide d'un langage propriétaire de scripting.
Les relations entre les données sont faites principalement par le nom des "colonnes" de chaque "table" ou requête. L'unicité des noms des colonnes dans le modèle doit être assuré ou résolu à l'aide d'alias.
Pour des modèles de données sources complexes, le script à écrire peut vite représenter plusieurs pages, qu'il faudra bien prendre garde de commenter sous peine de maintenance difficile.
Le schéma des données ainsi constitué définit la source des futurs graphiques et tableaux de bord. On ne définit pas à ce niveau les colonnes qui constitueront les axes (dimensions) et les indicateurs. Cela devra être fait dans chaque objet du tableau de bord.
De même, les éventuels indicateurs calculés devront être dupliqués s'il y a besoin de les afficher dans plusieurs graphiques ou tableaux.
A noter que les formules de calculs utilisées dans les graphiques ou tableaux peuvent être mutualisées sous forme de variable (un peu à la façon de macro). C'est là aussi profiter de la souplesse du produit mais ce n'est pas une fonctionnalité mise en avant.

Visualisation des données

Les possibilités de paramétrage offertes par Qlikview sont beaucoup plus riches que celles de Digdash. On sent que le logiciel a pas mal d'années d'expérience et que les paramètres ont été ajoutés au fur et à mesure.
Ils sont répartis dans une dizaine d'onglets.
Le logiciel aurait à mon avis besoin d'un nettoyage car il n'y a pas toujours de logique dans le positionnement des paramètres dans les onglets et en fonction du graphique utilisé, le choix des paramètres est tellement riche qu'on ne sait plus trop quel paramètre choisir pour réaliser le besoin. On s'habitue petit à petit mais la prise en mains s'en trouve ralentie.

Digdash, au contraire, est plus simpliste : il lui manque certains paramètres mais c'est en contrepartie la garantie d'une productivité plus grande et d'une prise en mains plus rapide.

Les 2 outils proposent des listes permettant de filtrer les données sur les différents axes d'analyse disponibles dans le modèle. Ces listes sont positionnables dans les pages.
Digdash propose également, par défaut, d'afficher les listes dans une "barre de filtres", en haut de la page. Les filtres affichés dans cette barre sont paramétrables. Si une hiérarchie a été définie sur l'axe d'analyse (ex : année / mois / jour), les différents niveaux d'analyse sont disponibles sur une même liste.

Il est également possible, dans Digdash, de spécifier un filtre pour chaque objet graphique ou tableau, qui sera utilisé à lors du premier affichage de la page, libre ensuite à l'utilisateur de modifier le filtre.
Il n'y a pas d'équivalence dans Qlikview car tous les objets sont liés entre eux donc filtrés ensemble (sauf exception car on peut verrouiller des objets simplement ou utiliser les fonctions de filtrage : cf. ci dessous)

La comparaison de 2 membres d'un même niveau de hiérarchie (ex : mois M vs mois M-1), passe dans les 2 cas par la création d'indicateurs calculés :
  • dans Digdash, cela se fait à l'aide d'un assistant graphique qui permet de définir le filtre pour chaque indicateur calculé (=> "mois M" = mois en cours, "mois M-1" = mois en cours - 1)
  • dans Qlikview, cela se fait à l'aide d'une syntaxe de formule (les fameux "set analysis"), qui n'est pas triviale et peut rapidement devenir difficilement maintenable
    Par exemple (cas très simple) : Sum({$<cpt_mois={"-1"}>} CA)

Digdash intègre un graphique cartographique, lié à une dimension hiérarchique de type géographie (ex : Département, Région, Pays), que l'on paramètre en reliant chaque niveau de la hiérarchie à un niveau de la cartographie.
La carte est de fait interactive : elle permet de zoomer par exemple sur un pays, d'afficher le détail par région, puis par département d'une région.

Qlikview passe par une intégration de cartes Google Maps, sur lesquelles on affiche des symboles, plus ou moins gros ou de couleurs différentes en fonction de la valeur d'un indicateur.
Il est également possible de zoomer sur la carte et on peut aussi mettre en place un système de choix de la granularité (département, région, pays, ...), mais avec Google Maps ce dernier mécanisme demande un peu de travail préparatoire et ici encore c'est la souplesse du produit qui le permet mais pas une fonctionnalité native.
Il existe également des solutions externes telles que celle proposée par GeoQlik, par exemple, qui propose plus de fonctionnalités mais est un module payant, venant ainsi alourdir la facture.

Enfin, les 2 outils fournissent des fonctions de simulation, en définissant des variables, qui vont entrer dans le calcul d'indicateurs calculés, ces indicateurs étant ensuite affichés dans des graphiques ou tableaux.
La seule différence sur ce point est que la définition des variables et indicateurs calculés va se faire, pour Digdash, dans les sources de données et être utilisé dans un ou plusieurs graphiques ou tableaux, alors que pour Qlikview, la définition des indicateurs calculés va se faire dans chaque graphique / tableau qui doit afficher cet indicateur.

Un des avantages de Qlikview aujourd'hui réside dans sa fonction de recherche dans les axes d'analyse, que ne propose pas Digdash. Mais j'ai cru comprendre que cette fonction était dans la roadmap de Digdash, reste à savoir comment elle va être implémentée ...

Conclusion

On se rend compte que les 2 outils sont assez proches en termes de fonctionnalités mais diffèrent sur quelques points majeurs :

  • L'architecture technique : plus ouverte pour Digdash que pour Qlikview
  • L'internationalisation : native chez Digdash, disponible chez Qlikview en le prévoyant dés le départ et en développant les fonctionnalités à l'aide de son langage de scripting
  • Structuration des développements :
- chez Digdash : Séparation claire de la partie Modèle de données (incluant la définition des axes d'analyse et des indicateurs) et de la partie Visualisation des données
- chez Qlikview : partie alimentation des données plus riche (attention à la maintenance) mais nécessité de définir dans chaque graphique / tableau quelle colonne est un axe ou un indicateur et risque de dupliquer les règles de calcul des indicateurs calculés
  • Visualisation des données : palette de types d'affichage et de paramètres beaucoup plus riche (trop ?) chez Qlikview, en contrepartie prise en mains et productivité plus grande sur Digdash

En termes de prise en main par les utilisateurs des entreprises, je dirais que si un travail de préparation, structuré et rigoureux, a été mené par les équipes techniques, Qlikview est un outil très riche en fonctionnalités et simple de prise en main.
Digdash, quand à lui, est plus frustre en termes de fonctions graphiques, mais sa structuration et ses fonctions natives et assistées permettent de monter une plate-forme de manière très productive voire de déléguer aux utilisateurs une bonne partie de l'architecture (modèles axes d'analyse / indicateurs notamment).




Commentaires
Du plus récent au plus ancien | Du plus ancien au plus récent

1.Posté par scog le 14/04/2011 08:06 (depuis mobile)
Merci pour ce comparatif instructif et courageux tellement il est délicat de contester le maître Qlik !

2.Posté par Tarek Demiati le 14/04/2011 12:11
Excellent article, par contre au niveau du back end, existe t-il un outil qui permet de boostez la productivité en générant automatiquement le code SQL, MDX, création des tables, champs, dimensions ... Car c'est souvent le manque d’industrialisation lors la création du datawarehouse qui consomme le plus de temps dans les projets BI.

Encore trop peu d'outil propose de la génération de code à partir d'une interface intuitive...

3.Posté par Jean-Marc Dupont le 15/04/2011 11:13
Twitter
Bonjour,

@Sébastien (opentoile) : Je te laisse maître de tes opinions ;-)
mais je ne vois pas de contestation dans cet article, simplement une comparaison factuelle entre 2 outils

@tarek :
sur Digdash : il existe un assistant pour gérer la structure des fichiers source, et un assistant pour la définition des axes d'analyse et des indicateurs (bruts et calculés), des objectifs, ...
Par contre, les requêtes SQL sur les bases de données se font directement (en SQL) dans l'outil
Libre à vous d'utiliser un outil de construction de requêtes (j'utilise pour ma part l'excellent Navicat)
sur Qlikview : il y a un assistant permettant de décrire la structure des fichiers source et un assistant pour générer le script, qui se limite à des ordres SQL Select pour chaque table concernée
Le reste est écrit avec le langage de script propriétaire Qlikview.
A noter qu'il existe un outil externe de génération de scripts : QsGen

4.Posté par Alexandre Schneider le 15/04/2011 11:38
Jean Marc,
Merci pour cet article très intéressant et riche d'enseignements. Il est vrai que des comparatifs (objectifs) entre les outils de BI de nouvelle générations sont rares.
Pourquoi ne pas aussi faire des comparaisons avec Tableau software, BI Board, Prelytis... ? Cela serait une bonne idée, qu'en pensez vous?
En tant qu'éditeur, je ne peux malheureusement pas le faire pour des raisons évidentes.
Cordialement

5.Posté par Jean-Marc Dupont le 15/04/2011 11:58
Twitter
Oui, cela serait effectivement très bien de comparer d'autres outils équivalents.

Appel à la bonne volonté des consultants connaisseurs / utilisateurs des solutions énoncées ci-dessus

On pourrait regrouper tout cela dans un comparatif => contactez moi

6.Posté par seif eddine le 15/04/2011 14:51
Bonne comparaison , bien que je sens que vous êtes un peu orienté vers digdash.
Pour moi deux points très intéressant ont été omis .
*Le modèle associatif sur le quel se base qlikview pour le stockage des données et la recommandation des filtres d'analyse.
*Qlikview est in-memory , je vois pas réellement une comparaison entre la performance d'un cube et la performance de données existant en mémoire.
Enfin digdash est apparemment un outils de restitution (comme SSRS par exemple) , Qlikview est un outil BI à part entiere qui a entre autre l'avantage de ne pas passer par le processus décisionnelle habituel du data warehousing couplé à cube olap


7.Posté par rchaumais le 15/04/2011 16:39
Twitter
Bonjour et merci pour votre article qui permet de découvrir DigDash et de le mettre en perspective de QlikView.

Je ne connais pas du tout DigDaash, mais en tant qu'expert QlikView, je dois néanmoins souligner que votre article comporte beaucoup d'erreurs sur QlikView qui témoigne d'une certaine méconnaissance de cette solution et qui souligne un peu trop votre parti pris pour DigDash.

Je ne peux pas reprendre votre article en entier mais voici les principales erreurs relevées. J'espère que vous pourrez ainsi corriger votre article pour le rendre plus conforme à la réalité.

- QlikView Serveur ne fonctionne effectivement que sur un serveur Windows. Par contre, il n'est pas obligatoire d'utiliser IIS. QlikView serveur embarque aussi son propre serveur Web. C'est au choix du client d'utiliser l'un ou l'autre

- QlikView gère parfaitement et avec un rendu strictement identique tous les navigateurs web modernes (comme DigDash). Il gère aussi parfaitement le vieux IE6 via un plugin activeX. je dois vous avouer que je suis d'ailleurs impressionné par la qualité des interactions en mode web.

- QlikView gère parfaitement les smartphones et Tablettes. C'est encore plus vrai aujourd'hui avec la nouvelle version pour Ipad: Voir la vidéo. C'est magnifique http://bit.ly/gckESV

- Le scripting QlikView doit être perçu comme le travail nécessaire à la mise en place d'un Datamart ou d'un Datawarehouse bien organisé. C'est donc une sorte de mini ETL + une base de données. Si les sources de données pour QlikView sont correctement organisées, le script dechargement des données dans QlikView sera généré quasiment automatiquement grâce aux assistants. Si ce n'est pas le cas, un ensemble de transformations sur les données sources pourra être réalisé avec le scripting. Des scripts de plusieurs pages sont souvent l'explication de sources de données multiples, hétérogènes et mal structurées.

- Si des indicateurs doivent être utilisés dans plusieurs graphiques et tableaux, ils faut alors les déclarer dans des variables QlikView pour avoir à éviter de les dupliquer.

- Il existe dans QlikView un assistant pour faire en quelques clics des comparaisons M/M-1, A/A-1, mais aussi 3 mois glissants par rapport au 3 mois glissant du semestre précédent etc. L'assistant est vraiment très puissant. S'il faut aller plus loin ou pour des comparaisons autres que sur l'axe temps, il existe effectivement les Set Analysis qui permettent de contextualisé une analyse. Je conviens que la syntaxe n'est pas aussi simple qu'un If Then Else (mais plus puissante) par contre, votre exemple est faut et ne fonctionne pas.

- QlikView gère très simplement la cartographie Google. Il ne faut pas plus de 2mn pour mettre des valeurs, des points et des densités de couleurs sur une google map. C'est aussi interactif puisque vous pouvez sélectionner et filtrer directement dans les cartes. GeoClic est un vrai SIG qui s'intègre à QlikView. Je ne crois pas que l'on puisse comparer les fonctionnalités de GeoQlik avec la cartographie de DigDash

- Il n'y a effectivement pas d'équivalent de la fonction vidéo de DigDash. Par contre, les objets QlikView peuvent être intégrés en mode actif dans PowerPoint, Word, Excel etc. Cela signifie que vous pouvez réaliser des analyses QlikView en live lors d'une présentation. C'est assez sympa et cela fait de l'effet :-)

Je dois aussi souligner que les points majeurs de QlikView n'ont pas été évoqués :

- Analyses associatives : C'est la clé de la réussite de QlikView. Cela change totalement la façon dont on navigue dans les données. C'est pour cela que QlikView est aujourd'hui dans le carré des leaders pour le Gartner.

- Interfaces utilisateurs finaux très intuitives et hyper simple pour réaliser des analyses complexes (Clic And View)

-Performance et rapidité d'analyse sur des très gros volumes de données (plusieurs centaines de millions de lignes). Nous avons chez ysance réalisé des applications avec plus de 2 milliard de lignes.

- Pas de besoin de serveur d'application ni de base de données. Architecture très peu intrusive.

Encore une fois, je vous remercie pour votre article qui me donne envie de tester DigDash. Je ne suis pas en mesure d'estimer la productivité de cet outil. Mais je peux aujourd'hui affirmer qu'avec QlikView, on va généralement deux fois plus vite pour réaliser un projet d'analyse et de dashboarding qu'avec les outils classiques. J'ai donc hate de voir ce que l'on peut faire avec DigDash.

J'espère que vous prendrez le temps de corriger votre article afin d'avoir un comparatif précis des deux solutions.

Merci

Romain Chaumais

8.Posté par Jean-Marc Dupont le 15/04/2011 16:41
Twitter
Encore une fois, je suis factuel, pas orienté vers un outil ou l'autre.

J'ai parlé rapidement du modèle associatif dans la partie "Modèle de données" mais sans m'y attarder c'est vrai (souci de ne pas faire trop long).

Les 2 outils sont "in memory", avec cependant une différence :
- Digdash répartit les données entre la mémoire du serveur et la mémoire du client web, en fonction du volume de données à afficher, ce qui a l'avantage d'éviter des allers-retours client/serveur sur le réseau lorsqu'il n'y a pas trop de données (c'est le client web qui traite les données sur le poste de l'utilisateur)
- Qlikview charge l'ensemble des données sur la mémoire du serveur (ou sur le poste client si l'on n'est pas en configuration client/serveur)

Concernant le stockage, Digdash et Qlikview fonctionnent là encore de la même manière : ils vont chercher les données source (partie "alimentation") et les stockent dans un fichier propriétaire puis les envoient vers la mémoire.
Digdash n'est pas pas plus un outil de restitution que ne l'est Qlikview.

9.Posté par rchaumais le 15/04/2011 16:52
Twitter
Merci pour ces précisions.

Je pense qu'il serai assez sympa que nous organisions des Coding Parties sur ces outils de nouvelles générations en BI. On se retrouve tous le temps d'une journée ou d'une soirée dans un endroit sympa, chacun avec sa solution "fétiche".

On se prend une bonne source de données pour un projet BI bien trapu et on partage notre passion pour le décisionnel en essayant de développer la plus belle application de dashboarding et d'analyse possible. Cela peut être vraiment enrichissant.

Je mettrai bien dans la place DigDash, Tableau, Prelytis, ReportOne, GoodData, PivotTable, QlikView. Si vous en voyez d'autre, la porte est grande ouverte.

Qu'en pensez-vous ? Des volontaires ?

10.Posté par rchaumais le 15/04/2011 16:54
Twitter
Ysance prête les locaux pour cette première BI Coding Partie à Paris :-)

1 2
Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.