Partenaire Microsoft : plus qu’un choix, un métier!

Via Chris Webb, un article de Frans Bouma sur l’évolution de la relation partenaire/éditeur avec Microsoft. Si l’article est récent le sujet ne l’est pas, Joel Spolsky en avait déjà parlé tantôt (il y a 12 ans !), et même moi par ici.

L’article est un peu long, je vous le résume (même s’il vaut le coup d’œil) :

Microsoft développe des logiciels. Pour rester dans le business l’éditeur crée beaucoup de nouveaux produits, sur des nouveaux périmètres ou en remplaçant des softs existants (qui marchaient ou pas). Nous, partenaires (consultants ou éditeurs à notre tour), faisons le choix d’utiliser ces produits, d’investir dans ces produits, et de là découle une dépendance à la technologie de Microsoft. Et si de tout temps, via cette dépendance, Microsoft nous faisait subir ses ruptures technologiques sans que nous ayons trop le choix (cela faisait partie du deal), désormais des alternatives existent et nous pouvons/devons-nous interroger sur l’opportunité de changer complétement d’environnement lorsqu’une nouvelle rupture survient.

Un très bon exemple de ça actuellement est la BI avec SQL Server, puisque nous sommes en train de subir une rupture technologique entre l’offre traditionnelle (SSIS/SSAS/SSRS) et la nouvelle génération d’outils (Power BI/HDInsight/Azure).

En tant que consultants, nos connaissances techniques sur les « anciens » produits ne se transposent au final que très peu sur les nouveaux produits (DAX, Hive, Pig). Au moment de dégager du temps de formation, on doit donc s’interroger, quitte à repartir de 0, sur l’opportunité de passer à une autre stack technologique : QlikView, Tableau, MicroStrategy… Voire carrément un domaine connexe : Machine Learning et Big Data via la stack Hadoop, statistiques via R ou Python, etc…

Bien choisir son outil de travail c'est crucial!

Bien choisir son outil de travail c’est crucial!

Dans le deux cas (autre éditeur, autre domaine) on ventile les risques : dans le premier on ventile ses dépendances sur 2 éditeurs,  dans le second on investit sur l’open source, qui traditionnellement véhicule des écosystèmes moins tyranniques que ceux reposant sur un éditeur unique.

Si de mon côté le choix est fait, je pense que tous ceux qui prennent leur carrière au sérieux doivent se poser sérieusement la question, autant d’un point de vue personnel (quel sera le prochain livre que vous allez ouvrir) que stratégique (quelle offre de service construire pour mon pôle décisionnel).

Par contre, si ici je mentionne les risques d’un partenariat avec Microsoft, il fallait également que je mentionne les avantages énormes qui en découle: entre autres, l’ensemble des Microsofties dont le métier à temps plein c’est de nous aider (merci les gens!),  le programme MVP dont je profite, ou encore les avantages en licences via le Microsoft Partner Network. Comparé aux autres éditeurs, nous sommes choyés!

Alors oui, je vous dis que pour moi le choix est fait, mais je fais monter le suspens, on en reparle plus tard 😉

Suspens!

Un peu de MDX de bon matin…

Je pique exceptionnellement le flambeau à François pour moi aussi vous causer MDX. Évidemment ça ne sera pas aussi pointu (voir piquant) que lui, mais pour une fois j’ai quelque chose à dire sur ce sujet…

A la base mon besoin était assez simple : créer un graph dans SSRS avec une date de départ et une date de fin fixées par des attributs de dimension de SSAS.

Typiquement : j’ai une dimension projet, dans cette dimension j’ai un attribut date de départ théorique (DDT), et un attribut date de fin théorique (DFT). Je veux que peu importent mes faits, mon graph couvre cette période théorique :

MDX - Le Besoin

A mon sens la grande méthode pour faire ça c’est de créer un set de dates allant de la DTD à la DTF. Ce set doit évidemment être composé d’éléments de la dimension Temps utilisée dans le groupe de mesure concerné, il va donc falloir passer des attributs de la dimension projet ([Projet].[DDT].&[…] et [Projet].[DDF].&[…]) à la dimension temps ([Temps].[Date].&[…]).

Le MDX étant un langage particulièrement efficace en termes de manipulation de chaînes de caractères (hur hur), ça va être un bonheur… Trêve de sarcasme, on peut utiliser quelques fonctions VBA en MDX qui vont ici nous sauver la mise (à adapter en fonction des formats de vos dates):

MDX - La requête qui en cast!

Ce n’est pas ultra élégant, mais ça marche… pas !

Le message d’erreur :  La fonction Axis1 attend une expression d’ensemble de tuples pour l’argument . Une expression de chaîne ou numérique a été utilisée.

Notez que la manipulation de projection des dates sur la dimension Temps marche, elle. C’est autre chose qui coince.

Le problème c’est qu’au moment où TimeSet est évalué, on n’a pas de CURRENTMEMBER sur la dimension Projet. En effet, en même temps (ON 1) qu’on essaye de résoudre TimeSet, on parcourt la dimension Projet, le CURRENTMEMBER n’est donc pas figé. On reçoit donc ALL dans le MEMBER_VALUE, que le STRTOMEMBER n’arrive pas à mapper correctement sur la dimension Temps. C’est le drame.

 

Tout ça parce que comme en SQL, en MDX le moteur interprète la requête dans un certain ordre. En faisant un gros raccourci, ici il commence par le FROM, puis le WHERE (slicer), puis les axes en itérant sur le 1 pour résoudre le 0. Dans une étape, tous les éléments sont interprétés en même temps : ça coince effectivement sur le TimeSet.

J’ai du mal à trouver des articles intéressants sur ce sujet, n’hésitez pas à soumettre les vôtres.

Pour comprendre le problème, on peut repartir d’une requête MDX plus simple, et basée sur AdventureWorks (je ne caste plus ma Start Date sur la dimension temps, je veux juste la faire apparaître en ON 1 comme dans mon cas réel):

WITH

    MEMBER Test1 AS [Product].[Start Date].CURRENTMEMBER.MEMBER_UNIQUE_NAME

 

SELECT

        [Measures].[Order Count] ON 0,

        STRTOMEMBER(Test1)

        *

        [Product].[Product].[Product].MEMBERS ON 1

 

FROM    [Adventure Works]

Le résultat, ma date est remplacée par ALL (« Tous les Produits ») dans le STRTOMEMBER(Test1) :

Mauvaise pioche

Si maintenant je filtre mon produit en slicer (typiquement l’endroit où on mettra le paramètre du rapport pour SSRS), la requête devient valide :

WITH

    MEMBER Test1 AS [Product].[Start Date].CURRENTMEMBER.MEMBER_UNIQUE_NAME

 

SELECT

        [Measures].[Order Count] ON 0,

        STRTOMEMBER(Test1) ON 1

       — *

       — [Product].[Product].[Product].MEMBERS ON 1

 

FROM    [Adventure Works]

WHERE    [Product].[Product].&[447]

La c'est bon!

Ici il existe un CURRENTMEMBER au moment où on évalue Test1, tout roule. La solution est trouvée pour mon rapport, à moi de placer mon STRTOMEMBER(@Parameter) dans le WHERE.

Mais oui mais vous voulez itérer en même temps sur le TimeSet/Test1 et les projets/produits ? Il va falloir siouxer et passer l’attribut dans une mesure.

WITH

    MEMBER [Measures].Test1 AS [Product].[Start Date].CURRENTMEMBER.MEMBER_UNIQUE_NAME

 

SELECT

      {[Measures].[Order Count],Test1} ON 0,   

        [Product].[Product].[Product].MEMBERS ON 1

 

FROM   [Adventure Works]

Ce qui donne:

Mouais

Si ça marche pour le cas simple, on perd le cas d’application premier avec le TimeSet. Je n’ai malheureusement pas de solution à l’instant T. Si ça me vient je compléterai.

On a donc vu deux choses : comment passer d’un attribut d’une dimension à une autre grâce aux commandes VBA, et l’ordre d’exécution d’une requête MDX et comment il peut casser vos jolies sets et membres calculés. J’aimerai en rajouter une troisième, la propagation des contraintes sur les attributs dans les dimensions. François en avait parlé aux derniers JSS, j’en remets rapidement une couche ici.

Si quand vous passez votre filtre en WHERE vous utilisez la clef de la dimension, ça marche :

WITH

    MEMBER Test1 AS [Product].[Start Date].CURRENTMEMBER.MEMBER_UNIQUE_NAME

 

SELECT

        [Measures].[Order Count] ON 0,

        STRTOMEMBER(Test1) ON 1

 

FROM    [Adventure Works]

WHERE    [Product].[Product].&[447]

Ca marche!

Par contre si vous utilisez un attribut de plus haut niveau, ça ne marchera pas :

WITH

    MEMBER Test1 AS [Product].[Start Date].CURRENTMEMBER.MEMBER_UNIQUE_NAME

 

SELECT

        [Measures].[Order Count] ON 0,

        STRTOMEMBER(Test1) ON 1

 

FROM    [Adventure Works]

WHERE    [Product].[Model Name].&[Cable Lock]

Ca ne marche plus :/

En effet, si on affiche les relations entre les attributs de la dimension (via SSDT BI), on verra que le Model Name ne contraint pas la Start Date, puisque si les contraintes peuvent remonter l’arbre (Model Name vers Product), elles ne le redescendent pas à partir de là (Product vers Start Date).

La classe ce SSDT BI 2012!A vous d’utiliser les bons attributs, et de bien construire vos cubes, pour que les requêtes fonctionnent bien.

Utilisation du VBA, ordre de résolution des requêtes, propagation des contraintes sur les attributs… Pfiou, c’était du lourd tout ça ! Heureusement que le DAX arrive pour simplifier tout ça (hur hur).

Spéciale dédicace à Jordan Mootoosamy, qui a bien souffert avec moi sur cette requête 😉

Petites nouvelles en ce début d’été

En vrac :

  • Vous avez pu constater la mise à jour du design de la BI ça vous gagne (n’hésitez pas à venir voir un coup si vous suivez par flux RSS). Moi je le trouve plutôt joli, beaucoup plus lisible, et puis j’ai pu inclure un plugin Twitter dans la colonne de droite. Globalement c’est cool, non ?
  • En parlant de RSS, suite à la fermeture de Google Reader je suis passé sur feedbin.me. L’interface web est plutôt clean et il est compatible avec Reeder sur iPhone. Malheureusement dans la bataille j’ai perdu Reeder pour Mac, qu’aucun service ne couvre. Vous êtes passé sur quoi de votre côté ?
  • En parlant de Mac, je me tâte pour changer de MacBook Air à la rentrée, profiter des nouveaux SSD et de 8Go de RAM. Je sais que Charly va s’acheter une bête de course portable d’ici peu. Quand je vois ses stats j’hésite à repasser sur PC. Mais le poids, le bruit et la qualité des finitions du MBA me retiennent encore… Ça plus le fait d’avoir un OS par usage, Windows 8 pour le professionnel et OS X pour le personnel, ça m’arrange quand même bien. Je doute.
  • Cette fois sans transition, je vous encourage à vous inscrire au SQL Saturday 251, le samedi 14 septembre au campus EPITA à Paris, organisé par la fine équipe du GUSS (z’avez vu le nouveau site web ?). C’est un samedi donc pas d’excuses de planning 😉 Et d’ailleurs vous pouvez profiter du même lien pour soumettre vos sessions. C’est l’occasion de se faire connaître un peu, profitez-en ! Attention la deadline pour les speakers est bientôt là, et il me semble qu’on cherchait plutôt des sessions techniques niveau 300, si vous voulez maximiser vos chances.
  • Côté Microsoft, si vous avez raté l’annonce sachez que les produits Self-Service BI viennent d’être regroupés dans une offre marketing cohérente : Power BI. Cela inclut Power Pivot, Power View, Power Map (ex Geoflow) et Power Query (ex Data Explorer – le produit BI de l’année). Également dans le pack, la mise à disposition d’un mini portail BI pour partager ses fichiers et ses sources de connexions, directement sur Office 365, et d’autres goodies. Reste à connaître les tarifs et toutes les contraintes entre les systèmes. N’hésitez pas à lire l’avis de Chris Webb sur la question.

Et vous alors ? Ça va ? Quoi de neuf ? 🙂

PowerPivot, BISM, Analysis Services et Marco Russo

Comme je vous le disais tantôt, la semaine dernière j’ai assisté au séminaire de 2 jours de Marco Russo sur PowerPivot.

Ce n’est pas difficile, c’est la meilleure formation a laquelle j’ai eu la chance d’assister, quel que soit le sujet. Que ce soit sur le contenu (précis, clair et exhaustif) ou la présentation (pédagogie, connaissance du sujet, passion), Marco Russo a fait un score parfait. Jusqu’à présent je voyais PowerPivot comme un gadget futur remplaçant d’Access, il m’a bien ouvert les yeux sur ses énormes capacités et le fait que ce soit bien le futur de SSAS. Job well done 🙂

Et hasard du calendrier, c’est justement la semaine dernière que Microsoft a fait le point sur la roadmap de sa plateforme BI pour les années à venir:

En cherchant un peu vous trouverez surement beaucoup d’autres articles sur le sujet (certains en français) et tout autant de discussions.

Moi j’ai eu de la chance, Marco Russo a pris le temps de nous expliquer en direct ce qu’il allait se passer. Chouette non? 😉

Pour la faire en court: SSAS va changer d’architecture pour s’organiser autour d’un modèle dénommé « BISM » (Business Intelligence Semantic Model – Modèle sémantique décisionnel).

Ce BISM comprendra 3 niveaux, chaque niveau pouvant être implémenté de plusieurs façons différentes:

  • Un modèle de données : en multidimensionnel (cf SSAS actuel) ou tabulaire (cf PowerPivot ou une base SQL classique)
  • Un langage de requête : MDX ou DAX
  • Un moteur d’accès aux données : MOLAP (SSAS actuel), VertiPaq (cf PowerPivot) ou un accès direct aux données d’où qu’elles viennent

Notez que lorsqu’on parle ici de modèle de données, on parle de l’implémentation technique (de l’encodage dans une solution informatique) du modèle de données fonctionnel (schéma en étoile, en flocon, ou autre). Mon premier est une suite de 0 et de 1 qui répondent à des contraintes informatiques, mon second est un dessin sur un papier qui répond à des contraintes métiers. Je précise parce qu’au début j’étais perdu: je me demandais à quoi pouvait bien ressembler un modèle de données BI tabulaire? Marco Russo m’a donné la réponse : à un schéma en étoile!

En image, le BISM et ses 3 éléménts ça donne ça:

BISM : l'avenir de SSAS

BISM : l'avenir de SSAS

La première bonne nouvelle c’est que bien que pour la v1.0 les deux piles (Multidim/MDX/MOLAP et Tabulaire/DAX/Vertipaq) soient étanches – on choisit soit une pile soit l’autre, dans le futur on devrait pouvoir choisir de construire la pile que l’on veut avec n’importe quelle brique (Tabulaire/MDX/Vertipaq par exemple). Le choix se faisant alors uniquement en fonction des contraintes métiers / utilisateurs et non de contraintes techniques.

La deuxième bonne nouvelle c’est que si on peut requêter en MDX et en DAX les 2 modèles de données, alors on devrait pouvoir utiliser n’importe quel front end (SSRS, Crescent, PowerPivot…) indépendamment de l’architecture de stockage. Cela lève le doute sur la compatibilité descendante entre Crescent (futur SSRS en DAX) et les cubes SSAS actuels, ça rassure!

Evidemment reste la question de comment faire le choix entre les 2 architectures, et là aussi Marco Russo nous a donné quelques éléments de réponses:

  • Avant tout, que ce soit pour le multidim ou le tabulaire, le schéma en étoile reste la méthode de modélisation des données.
  • Le multidimensionnel sera l’outil de choix pour travailler sur des données fortement hiérarchisées, utilisant des calculs mathématiques sur ces hiérarchies (par exemple sur le temps), avec des relations complexes (many to many) et où l’importance des données réside dans les chiffres (qui a dit finance dans le fond?)
  • Le tabulaire (avec Vertipaq et la compression en colonne) est ultra efficace sur les calculs en distinct et distinct count, même sur des très très gros volumes de données, il manipule bien les chaînes de caractères et est beaucoup plus facile à comprendre pour les utilisateurs (on dirait Access!)

En terme de proportions, Marco Russo nous a dit qu’il voyait les futurs projets ventilés en:

  • 30% ne pouvant être réalisés qu’avec du Multidim
  • 10% ne pouvant être réalisés qu’avec du Tabulaire
  • 60% au choix, avec beaucoup de Tabulaire puisque plus facile à implémenter

Personnellement je retrouve l’enthousiasme sur le futur de la BI Microsoft. Même si on est encore un peu déshabillé point de vue reporting, l’offre Microsoft est vraiment très belle point de vue moteur. Entre le dB Engine SQL, MOLAP et Vertipaq, on a de très belles technologies, partiellement recouvrantes mais pas redondantes, qui ont du sens et qui pulsent point de vue performance. Avoir des bons outils c’est essentiel pour bien faire son job, là je me sens bien équipé. C’est cool 🙂

Pour les gros joueurs

Chris Webb nous avertit dans cet article de la sortie d’un whitepaper qui porte sur l’intérêt du mode de stockage ROLAP dans SSAS pour les cubes qui pèsent plusieurs téras. C’est rédigé par l’équipe de SQL CAT, et ça se télécharge ici. Personnellement je n’ai jamais eu l’opportunité de bosser sur ce genre de volumétrie, ça m’a l’air plutôt éclatant!

Tant qu’on y est, j’ai également récupéré le lien d’un e-book pour apprendre le PowerShell. C’est écrit par Tobias Weltner, MVP PowerShell, et ça se télécharge là. Je n’ai pas encore eu le temps de le lire, mais ça m’a été recommandé donc je forward!

…et un cube pour les diriger tous!

Chris Webb (pour rappel, l’auteur de la bible des cubes SSAS) reprend la discussion sur la question : faut il monter tous ses groupes de mesures dans un seul gros cube ou dans plein de petits cubes?

Le débat a repris suite à une question posée sur le technet, et Mister Webb fait le point dans cet article.

Je vous donne son avis en version courte, avis auquel j’adhère à 100% :

  • Il faut mieux démarrer avec un seul gros cube afin d’accéder à toutes les mesures dans tous les rapports.
  • Deux exceptions:
    • Dès le départ, si les groupes de mesures sont complétement disjoints (ils n’utilisent que très peu de dimensions en commun), cela ne présente pas d’intérêt de les mélanger,
    • Plus tard, en cas de problème de performances, cela a du sens de créer des petits cubes qui feront des zooms sur les sujets critiques.

C’est ce que je pratique et personnellement je n’ai jamais eu de problème!

Ps: Suis-je seul à systématiquement enlever la deuxième syllabe à « cube » dès que je l’entends dans une phrase pour voir si ça devient cochon? Je suis sûr que non… 😉