Après avoir eu la chance de réaliser un projet de migration Multidim vers Tabular sur des volumétries qui commencent à être raisonnables (cube tabulaire de 25 go, table de faits en M2M de 1,5 Milliard de lignes) je vais vous livrer mon ressenti pas tant en terme de performance mais plutôt en terme de confort d’utilisation de l’outil sur un vrai projet et pas en mode Maquette (POC) ou démo pour les JSS.
Le projet Tabular et son fichier unique
On attaque avec un point connu et déjà largement décrié dans la communauté, en mode tabular nous n’avons plus qu’un fichier. Si de prime abord on pense à l’impossibilité de travailler à plusieurs sur le projet, dans les faits on modifie rarement un projet de cube à plusieurs en même temps. Je situerais plutôt le problème sur un point que j’aborderai plus en détail par la suite, la perte de sémantique due à ce mode de fonctionnement.
Dans les projets sur lesquels j’interviens nous utilisons TFS (Team Fondation Serveur) et c’est là que les choses se corsent, un commentaire comme « Ajout du nom » ou « Ajout d’un champs de description » n’a pas le même impact si l’on voit qu’il est apposé à une modification sur la Dimension Produit (cas du multidim) ou sur le fichier .bim (cas du tabular) qui contient par ailleurs 100% de nos modifications. Dans le même domaine, revenir en arrière grâce à TFS sur un fichier unique … ce n’est pas la même histoire que de se dire « mince je n’aurais pas du faire ça sur ma dimension produit et restaurer uniquement celle-ci ».
La disparition de la sémantique dimensionnelle.
Avec le mode tabulaire vous faites fi des notions de tables de faits, de dimensions, et de tout ce qui tourne autour (role playing dimension, notion de cubes, dimension usage) au profit de tables, de colonnes et de calculs. Je ne reviendrai pas sur le drame que cela représente en terme de modélisation et de compréhension pour rester focaliser sur la pratique. Et en effet, en pratique, tout disposer sous forme de tables ce n’est pas sans effet de bord tel que :
- Obligation de préfixer les « tables » par Dim / Fact si l’on veut s’y retrouver.
- Lorsque le nombre de tables devient important, la navigation entre celles-ci devient une vraie galère (et le modèle tabulaire nous obligeant à ajouter plusieurs fois les même tables pour émuler des role-playing on y arrive vite).
Oui oui je parle bien des « … » où je dois cliquer pour retrouver mes tables manquantes. A l’usage, cela me rend fou ! - La tentation de se dire que puisque tout est sous forme de table la modélisation dimensionnelle ne sert à rien, et ça c’est grave !
« Dimension Usage » tu me manques 🙁
AH ce merveilleux onglet de SSAS qui représente une vue graphique de notre matrice de bus qui nous permet en un coup d’œil d’identifier les relations entre nos tables, d’utiliser plusieurs fois des dimensions (Date …) ainsi que la granularité et bien avec tabular c’est fini et c’est bien dommage, cela me manque …
La gestion des Many to Many
Ok, c’est faisable dans tabular à l’aide du DAX et ça marche plutôt pas mal le problème c’est plus qu’il faut écrire une requête DAX pour chaque mesure et franchement c’est horrible à gérer … (c’est pas compliqué, c’est chiant !)
Le DAX
Le DAX nous permet de délivrer le résultat attendu de manière très rapide, de même que les notions de tables, on s’en sort vite, on n’est pas bloqué car le comportement est assez fidèle à ce que l’on attend (Comment ça pas comme en MDX ?) c’est un bon point. Bon par contre nous n’avons pas d’éditeur de Dax, en 2014 nous sommes en train de remplir les formules en mode Excel et ça c’est très grave …
En conclusion, sur de plus petits projets (sans M2M, avec une dizaine de tables) je risque de re-partir sur un projet Tabulaire. Toutefois à l’avenir sur des projets plus industriels et si je ne veux pas me fourvoyer à oublier les préceptes de monseigneur Kimball, je ne repartirai pas sur du tabular, l’IDE n’est clairement pas encore à la hauteur des projets de taille importante avec des besoins de standardisation / industrialisation.
[Update du 23/10/2014]
Un post intéressant de Marco Russo sur l’adoption de tabular et le maintien des ventes de son ouvrage sur Multidim. http://sqlblog.com/blogs/marco_russo/archive/2014/10/23/the-state-of-multidimensional-and-tabular-adoption.aspx
[/Update]
5 Comments
Très bien ce retour, tu vas droit sur les sujets importants.
Je modèrerai juste le terme que tu as employé : « grave » (voire « très grave »). Ce n’est « pas bien » mais ce n’est certainement pas « grave ». Ce qui serait grave, ce serait de recruter des gens qui devraient travailler sous Visual Studio et qui ne comprendraient pas la différence… [entre une formule Excel et une mesure // entre une série de tables et une modélisation dimensionnelle].
Mais te connaissant, je suis sûr que c’est juste une question de sémantique. 😉
L’article concerne la praticité de SSAS Tabular dans un usage professionnel, dans ce contexte là, ne pas avoir un éditeur DAX digne de ce nom (Qui est quand même pire que bloc note …) je trouve ça très grave sans exagération. Surtout si l’on rapporte cela à l’effort nécessaire pour développer une semblant d’éditeur de DAX (ce qu’a fait SQLBI à travers DAXEditor pour Excel) et au temps qui passe (On est loin de la sortie de SQL2012 maintenant).
Pour compléter ton article, il ne faut pas oublier de dire que Tabular ne propose pas de mesure non additive telle que Last Non Empty et que tu peux le faire mais avec une formule de DAX un peu trop compliqué pour un End-User et pas assez industrielle pour un développeur.
Ensuite le fait qu’il n’y ait pas de SCOPE (pour faire de l’assignement) et de mode script (en natif) est un vrai handicap sur un mode projet corporate.
Pour le M2M, on peut quand même dire qu’on peut le bricoler malgré tout (comme le reste d’ailleurs) à base de LOOKUPVALUE (oui c’est moche) mais on peut produire le résultat escompté. Pour la maintenabilité on repassera. Mais le résultat sera là.
Donc tu as raison Charles-Henri, pour faire un POC, c’est sans doute la bonne techno. Après pour un projet robuste (corporate) avec un minimum de complexité, de volumétrie, de montée en charge, ce n’est pas la bonne techno.
Pour l’instant, je ne sais pas quelles sont les intentions de MS sur multidim et Tabular. Vont-il laisser mourrir multidim au profit de Tabular ? Dans ce cas, vont-il combler tous ces manquements pour au moins s’aligner sur les forces de futur feu multidim ? Ce serait pas mal de communiquer dessus. Où se situe la brique Tabular dans l’offre et quelles sont les ambitions de MS sur ce produit ?
[…] des cubes Tabular, mais nous verrons cela lors de la sortie (Les problèmes remontés ici seront-il corrigés […]
C’est drôle de relire cet article 5 ans après et constater que le Tabular est en train de tuer le Multidim et de combler tous les gaps que tu soulignais (à juste titre à l’époque).