mercredi 20 avril 2011

Le futur (proche ) de la BI chez Microsoft

Développée depuis une dizaine d’année environ, la solution BI Microsoft est aujourd’hui à un stade d’évolution mature depuis la version SQL SERVER 2005.

Elle s’articule autour d’une architecture classique de type ETL (SSIS integration services), Stockage relationnel et multidimensionnel (SQL SERVER OLTP et SSAS), et restitution (SSRS reporting services) pour la partie serveur et l’infrastructure SHAREPOINT et EXCEL pour les accès du client.

Cette architecture robuste et économique présente cependant quelques insuffisances constatées par les clients historiques, en particulier avec l’apparition des outils type BI personnelle, qui ne pourront être levées que par une évolution radicale  de l’architecture du produit.

Celle-ci est présentée dans le schéma ci-dessous et rompt avec l’architecture actuelle :















Figure 1 Le futur proche de la BI chez MICROSOFT 

On note en particulier la refonte de l’outil SSRS au sein du projet « Crescent » , l’apparition du moteur VERTIPAQ et du langage d’interrogation de données DAX associé, aussi bien en relationnel qu’un multidimensionnel et la mise en avant des applications POWERPIVOT.

L’éditeur distingue  2 types de cible clients BI en fonction du contexte :

1.       Environnement de forte volumétrie avec des besoins de capacité de stockage élevée  ou des besoins d’intégration de type « quasi temps réel » - Besoin d’intégrité fort - Ressources IT adaptée maîtrisant l’OLAP et le langage MDX – clients nombreux avec des exigences précises et peu évolutives et terme de reporting – complexité métier faible à moyenne : domaine de la BI institutionnelle de type groupe. L’architecture préconisée dans ce cas est SQL SERVER 2008 R2 dont SSAS avec l’utilisation du MDX pour la manipulation des données et un accès à SSRS au travers du portail SHAREPOINT 2010 ou EXCEL 2007 a minima.
2.       Environnement de volumétrie faible à moyenne – Besoin d’intégration non temps réel – Enrichissement progressif du modèle de données avec préemption de ce modèle par les utilisateurs métiers – ressources IT concentrée sur son cœur de métier à savoir l’administration technique et le suivi des performances – complexité  et évolutivité moyenne à forte des domaines métiers – besoin de reporting personnalisé et adapté en plus du reporting institutionnel : domaine de la BI personnelle de type département ou service.  L’architecture préconisée sera dans ce cas SQL SERVER 2008 R2 avec l’utilisation du moteur VertiPaq et du langage DAX au travers de POWERPIVOT pour EXCEL 2010 et de POWERPIVOT pour SHAREPOINT 2010, l’IT exerçant la surveillance des performances et l’administration des serveurs.

Version actuelle

Un certain nombre de points ont été relevés sur la version actuelle 
  • Manque de cohérence et d’étendue fonctionnelle des modèles sémantique UDM (unified data model modèles OLAP) et SMDL (modèles de rapport) - absence de capillarité de ces modèles sur toute la suite BI, la conséquence étant une administration double voire triple  sur l’ensemble de la suite (SSIS, SSAS, SSRS) lors des évolutions du modèle de données.
  • Complexité de la mise en œuvre et du maintien en condition opérationnelle de SSAS et manque d’agilité lors de l’enrichissement des modèles multidimensionnels, complexité du langage MDX pour la manipulation des cubes OLAP nécessitant  le maintien de ressources IT compétentes,
  • Manque de richesse fonctionnelle de l’outil SSRS Reporting Services et performance en retrait par rapport à des solutions de type « In memory »,
  • Autonomie des utilisateurs réduites en terme de conception de rapports moyennement complexes à très complexes, l’outil client lourd Report Builder 3.0 étant en dessous d’un outil de type SAP BO XI et assez peu déployé de manière opérationnelle dans les grandes organisations,
  • Forte demande des analystes et experts métiers du maintien d’EXCEL comme outil d’interrogation  des données mais également de conception et publication de rapports autres que les rapports institutionnels de l’entreprise.
Version future

Fort de ces constats, l’éditeur a donc annoncé qu’il souhaite faire évoluer radicalement et rapidement son produit, notamment sous la pression de produits concurrents proposant des solutions plus simples et plus économiques, voire plus performantes (solution du type « In Memory »).

Cette approche, partiellement amorcée par le lancement de l’offre conjointe SQL SERVER 2008 R2, SHAREPOINT 2010 et POWERPIVOT for EXCEL ou SHAREPOINT sera définitivement adoptée sur la version SQL SERVER 2011 code DENALI et présentera une architecture radicalement nouvelle avec notamment l’apparition : 
  • Du BI Semantic model (BISM) sous Visual Studio 2010 proposé en parallèle du modèle UDM actuel non évolutif. Il s’agit d’un modèle sémantique couvrant cette fois ci toutes les briques des outils et simplifiant avantageusement le développement,
  • Du projet CRESCENT refondant profondément l’outil Reporting Services en offrant une richesse fonctionnelle au niveau des meilleurs outils actuels, 
  • Du langage de manipulation de données DAX (Data Analysis Expression), très proche en terme de syntaxe du langage macro d’EXCEL et en alternative au MDX pour les usages des analystes et experts métiers permettant un transfert progressif de l’administration et l’enrichissement des modèles métiers de l’IT vers les utilisateurs avancés.
Figure 2 Architecture Microsoft BI selon les 3 couches

On distingue donc désormais et de manière séparée :

La couche modèle de données qui est exposé à des applications clientes et qui traite à la fois les données relationnelles comme les données multidimensionnelles 
La couche règle métier (business Logic) : la logique métier est définie par les utilisateurs métier  en utilisant le modèle DAX (Data Analysis Expression)  ou MDX (Multidimensional Expressions). DAX est un langage d'expression basé sur des formules de calcul Excel qui a été introduit par  PowerPivot et construit sur des concepts relationnels. Il n'offre pas la puissance et la même souplesse que le MDX, mais il est plus simple à utiliser et nécessite un réglage minimal. Il y aura toujours des applications complexes de BI qui nécessiteront la puissance de calculs du MDX mais l’utilisation du  BI Semantic Model s’appuiera  préférentiellement sur DAX.
La couche accès aux données qui intègre des données provenant de diverses sources - bases de données relationnelles, applications d'entreprise, des fichiers plats, Data RSS, etc. Il y a deux options pour l'accès aux données : le mode mise en cache et  le mode temps réel. Le mode mis en cache extrait les données des sources et les stocke dans la mémoire en colonne dans la zone de stockage mémoire VertiPaq. VertiPaq est une technologie qui utilise des  algorithmes de compression  performants avec les processeurs multi-thread pour des  requêtes sophistiquées et qui est optimisé pour les derniers chipsets multi-core, délivrant ainsi de performances exceptionnelles sans avoir besoin de mettre en œuvre des stratégies élaborées d'indexation, d'agrégats ou de réglage. 
Le mode temps réel, d'autre part, est le mode classique qui exécute les traitement des requêtes et d'évaluation des logiques métier jusqu'à la source de données, en exploitant ainsi les capacités du serveur et en évitant le besoin de copier les données dans la zone de stockage mémoire VertiPaq du client. Le choix du meilleur compromis d'utilisation reste du ressort du client.
Il est entendu que dans le cas d’un réseau suffisamment dimensionné et de mémoire disponible importante, le mode mise en cache offre des performances nettement supérieures.

A titre indicatif, les maquettes réalisées offrent des performances plus de  100% supérieures sous POWEPIVOT sous EXCEL par rapport à SSRS sous SQL SERVER 2008 R2 avec des fonctionnalités de filtrage (utilisation des segments, filtres d’en tête de lignes et de colonnes) nettement supérieures. 
Toutefois, cette architecture nécessite par principe une quantité de mémoire vive plus importante, aussi bien sur le serveur que sur le poste client (dans le cas d’utilisation de POWERPIVOT pour EXCEL 2010).

jeudi 9 septembre 2010

Google instant palmares

Rien à voir mais après avoir découvert aujourd'hui google instant, je me suis amusé à établir le palmares des mots clés pour chaque lettre de l'alphabet. Le résultat, parfois surprenant est le suivant:

A ANPE ALLO CINE AIR FRANCE AMAZON

B BUT BNP BADOO BON COIN
C CAF CDISCOUNT CARREFOUR CONFORAMA
D DEEZER DARTY DAILY MOTION DECATHLON
E EBAY EUROSPORT EDF EQUIPE
F FACEBOOK FNAC FREE
G GMAIL GOOGLE MAP GO SPORT
H HOTMAIL HABBO HSBC
I IKEA IMPOTS ITUNES
J JEUX
K KIABI KOREUS KILOUTO
L LE BON COIN LA REDOUTE LCL
M METEO MAPPY MSN
N NRJ NORAUTO NEUF
O ORANGE OM OPODO
P PAGES JAUNES PROGRAMME TV POLE EMPLOI
Q QUELLE QUICK
R RATP REVERSO RMC
S SNCF
T TF1 TRDUCTEUR TELECHARGER
U UGC UTUBE UCPA URSSAF
V VIA MICHELIN VDM VOILA
W WAT WIKIPEDIA W9
X XBOX XE XANAKA
Y YOUTUBE YAHOO
Z ZARA

jeudi 8 juillet 2010

mardi 5 janvier 2010

Stratégies de management des feuilles de calculs en entreprise

Ce document est une reprise des résultats de diverses enquêtes conduites notamment par le DTWI (data warehouse institute) sur le phénomène classique de prolifération des feuilles de calculs (spreadmarts) dans les entreprises conduisant à la spécialisation et la dissémination des pratiques métiers générant des risques et des pertes difficiles à quantifier mais significatives. Ce phénomène va généralement à l’encontre du principe de « l’unicité et du partage de la vérité », aussi bien en terme d’informations que de pratiques métiers et conduit souvent à la remise en cause des efforts de centralisation du capital informationnel de l’entreprise. Plutôt que d’adopter une attitude intransigeante, aussi bien du côté de l’équipe de direction que du département IT consistant à viser leur éradication dans les processus clefs de l’entreprise, il convient de s’interroger sur leur nature et leur utilité, sur leur rôle exact auprès des analystes avant d’envisager de mettre en place des outils fédérateurs et mieux pilotés. La composante conduite du changement des pratiques est aussi importante que la composante technologique dans ce type de projet.


Les différentes approches possibles du problème sont analysées, avec leurs avantages et inconvénients et quelques suggestions de solutions d’éditeurs sont présentées.

Ayant eu à conduire plusieurs projets de ce type, j’ai agrémenté ce documents de remarques issues de réflexions personnelles sur l’efficacité des diverses approches possibles. Il s’agit donc en quelque sorte d’un petit traité de non-prolifération des feuilles de calculs dans l’entreprise.

Quelques stratégies de management des feuilles de calculs en entreprise

vendredi 20 novembre 2009

Installation de PowerPivot sur un serveur sharepoint 2010

Quelques subtilités dans l'installation de PowerPivot sur une serveur sharepoint 2010. Instructions ici pour une installation standalone:
Single Server Install

DAX (Data Analysis Extensions) pour EXCEL 2010 (suite)



D'après un article publié sur http://blogs.msdn.com/powerpivot/
Remerciements à Howie Dickermann [MSFT]

DAX est un langage basé sur la syntaxe des formules d'EXCEL. Il est capable d'adresser plusieurs tables et comprend des fonctions permettant d'invoquer des bases relationnelles. Il comprend également des fonctionnalités permettant de créer dynamiquement des aggrégations, ce qui permet d'envisager d'afficher des valeurs calculées dans un TCD. Au grand bonheur des utilisateurs d'EXCEL, DAX reprend une partie des bibliothèques de fonctions d'EXCEL et beaucoup de fonctions sont identiques.

Quelques exemples:
= [First Name] & “ “ & [Last Name] formule de concaténation de texte classique
= SUM(Sales[Amount]) la fonction SUM somme sur une colonne plutôt que sur une plage de cellules
= RELATED (Product[Cost]) permet de référer la table produit dans un tableau basé sur la table SaleOrderDetails par exemple

Quand utiliser DAX ?

En partant du principe que l'utilsateur a chargé grâce à POWERPIVOT un certain nombre de tables, il est probable qu'il ne dispose pas de toutes les valeurs nécessaires dans ces tables.

Il peut être alors nécessaire de faire appel à 2 types d'objet de calcul pour poursuivre l'analyse:

les colonnes calculées et les mesures (ce vocabulaire est propre à la sémantique de l'analyse multidimensionnelle).

Colonnes calculées:

Elles sont identiques à celles d'EXCEL et il n'y a pas de nouveau concept sous jacent
Lorsque vous entrez une formule pour définir une colonne calculée, la formule est évaluée pour chaque cellule et vous disposez immédiatement du résultat.
Par exemple, si vous avez une colonne [Quantite] et une colonne [Prix], vous pouvez créer une colonne [Montant] qui est simplement [Quantite]*[Prix]
Les valeurs ainsi crées dans des colonnes calculées peuvent être exploitées dans le TCD de diverses façons. Une colonne calculée peut contenir:


  • Des valeurs numériques qui peuvent être agrégées dans la zone "Valeurs" de votre TCD
  • Des valeurs qui peuvent à leur tour constituer les lignes ou les colonnes de votre TCD
  • Des valeurs qui peuvent être utilisées dans un "slicer" pour découper le résultat de votre TCD

Mesures:

Les mesures dans Powerpivot sont des formules qui sont placées dans la zone "Valeurs" de votre TCD. Elles sont évaluées pour chaque cellule de la zone "Valeur". Chaque évaluation est le résultat résultant de la combinaison unique d'un colonne, d'un ligne et d'un filtre associé à cette cellule.

Il y a 2 types de mesures dans PowerPivot: les mesures "implicites" et les mesures "DAX".

Mesures "implicites: si vous cochez une valeur numérique dans la liste des champs disponibles de votre TCD, Powerpivot va automatiquement créer une mesure "somme de MonChamp" et cette mesure sera automatiquement placée dans la zone de valeur du TCD (voir diapo). Vous pouvez bien sûr changer le type d'agrégation en COUNT, AVERAGE, MIN ou MAX. Nous les appelerons les mesures "implicites" car il n'est pas nécessaire de sélectionner un champ (colonne) et un type d'agrégation. La formule associée à ce type de mesure est implicite et sera toujours une simple agrégation à partir d'un croisement de lignes et de colonnes.

Mesures DAX: quand vous créez une mesure en utilisant la boîte de dialogue "Nouvelle mesure", vous pouvez nommer la mesure et lui attribuer la formule DAX souhaitée. Vous n'êtes cette fois plus limité à une simple aggrégation de colonnes mais vous pouvez vous livrer à des traitements un peu plus sophistiqués.

Il faut cependant bien comprendre que lorsque vous saisissez une formule pour définir une mesure, celle ci n'est pas évaluée immédiatement. C'est lorsque votre mesure sera déposée dans la zone de valeurs de votre TCD qu'elle sera évaluée.

Bien sûr, que vous cochiez un champs pour en faire une mesure implicite ou que vous choisissiez "Nouvelle mesure" et entriez une formule DAX, votre mesure sera ajoutée à votre TCD.

Quelque exemples de colonnes calculées comprenant des fonctions DAX basiques



Le schéma de Sales dans AdvetureWorks

A partir de la table Sales, on définit une colonne [Amount] = [OrderQty] * [UnitPrice]

Vue dans Powepivot


vue dans SQL SERVER Management studio


A partir de la table Product, il est possible de récupérer le UnitCost pour l'intégrer dans notre tableau en utilisant la fonction RELATED().
UnitCost= RELATED('Product'[StandardCost]))

vue dans SQL SERVER Management studio

Il

Vue dans Powerpivot

Il existe également une fonction RELATEDTABLE() qui permet de permet de renvoyer l'ensemble des lignes liées à la table d'origine. Par exemple, à partir d'un tableau basé sur la table Product, il est possible de récupérer l'ensemble des ventes des produits:
=SUMX(RELATEDTABLE([SalesOrderDetails],SalesOrderDetails[UnitPrice])

Vue dans Powerpivot


Notons dans cet exemple que nous avans utilisé la fonction SUMX plutôt que la fonction SUM. La fonction SUMX prend 2 arguments: la table dans laquelle nous allons chercher les valeurs et une expression à retourner pour chaque ligne de cette table.

Dans notre exemple, nous retournons dans notre tableau le montant des ventes par produit dans notre TCD.

DAX ne se réfère pas aux emplacement des cellules pour référencer des données

Dans DAX, il n'existe pas de notion d'adressage de cellule pour une données. Les données ne sont pas identifiés par leur emplacement dans la feuille de calcul. DAX ne se réfère qu'aux colonnes dans la table. Plutot que de considérer une plage de cellules, il faut concevoir les données comme un jeu de tables constituées de colonnes et de lignes

Fonctions d'agrégation DAX

DAX inclut de nombreuses fonctions d'agrégations d'EXCEL dont les fonctions SUM, AVERAGE, MIN, MAX, COUNT mais ces fonctions prennent pour arguments des colonnes. Il existe également de nouvelles fonctions d'agrégation capable d'agréger n'importe quel expression à partir de lignes d'une table:

  • SUMX (Table, Expression)
  • AVERAGEX (Table, Expression)
  • COUNTAX (Table, Expression)
  • MINX (Table, Expression)
  • MAXX (Table, Expression)

Fonctions de table DAXDAX ne dispose pas de fonctions permettant de retourner une table. La formule qui définit la valeur d'une colonne calculée doit renvoyer une valeur scalaire afin de pouvoir être placée en colonne. Mais disposer de fonctions qui permettent de retourner des tables de données est très utiles surtout si vous souhaitez utiliser ces résultats intermédiaires pur les passer en arguments à d'autres fonctions. L'exemple ci dessus illustre ce mécanisme où l'on renvoie l'ensemble des lignes de la table SalesOrderDetails et qu'elles sont agrégées via la fonction SUMX pour être enfin renvoyées à la table Product.

Cette notion de fonctions renvoyant des tables peut être nouvelle pour un utilisateur d'EXCEL mais c'est un concept facile à assimiler. Quelques exemples de fonctions renvoyant des tables:

  • RelatedTable (Table) renvoie la table contenant les données liées
  • Filter (Table, Condition) renvoie la table filtrée par la condition
  • Distinct (Column) renvoie une colonne de la table par valeur distincte

En conclusion, les fonctionnalités puissantes mis en oeuvre grâce à DAX pourront dérouter les utilisateurs d'EXCEL mais ceux ci pourront rapidement en tirer bénéfice en terme de performance mais également ( et surtout) en terme de clarté et de maintenabilité de leurs multiples sources de données. Finies les macros alambiqués pour tenter d'improbables et de périlleuses jointures entre leurs feuilles de calcul. Fini le joyeux mélange entre données stockées et calculées. Fini les hasardeuses mises à jour en cascade de formules entre feuilles et fichiers. Désormais, toutes les données résident en tables dans Powerpivot avec une gestion relationnelle propre. L'interface classique d'EXCEL 2010 devient uniquement le client du fournisseur de données Powerpivot et peut être utilisé à plein régime pour l'analyse. Nul doute qu'à terme analystes et spécialistes IT s'y retrouvent.