Archive

Archives pour 01/2010

Le conseil en amont des projets décisionnels (1/3) : l’Audit

Nous sommes nombreux à travailler sur les phases « de réalisation » des projets décisionnels, sans parfois avoir la visibilité sur comment ce projet a été lancé et pourquoi celui-là plutôt qu’un autre. Nous avons formalisé au sein d’Homsys Consulting trois offres autour du conseil en amont des projets décisionnels et je vous propose un petit aperçu de nos retours sur ces types de mission.
Le premier volet de cette trilogie concerne l’Audit des Systèmes d’Information Décisionnels.
La palette de missions d’audit est très large, de l’audit technologique (un audit de performances, par exemple) jusqu’à l’audit global sur le SID sponsorisé par la Direction Générale ou encore des audits de projets décisionnels, ajoutant des questions de méthodologie et d’organisation. Des points communs existent entre ces missions :

  • Une mission rapide permettant de confronter un SID existant avec l’état de l’art
  • Une nécessité d’impliquer les acteurs, malgré ce terme parfois très mal perçu d’ »audit »
  • Une étape permettant de dresser un premier plan d’actions et de lancer les chantiers prioritaires.

Un leitmotiv récurrent du conseil en amont des projets décisionnels est de proposer une vision synthétique et pédagogique de notre travail. Et comment mieux illustrer ces missions que par un petit schéma ? Voici le « carré magique » d’Homsys… Grâce à lui, nous présentons pédagogiquement la situation existante et quels types d’efforts devront être menés :

le "carré magique" homsys de l'audit

Le "carré magique" homsys de l'audit

Cette matrice met bien en avant un élément incontournable de ces missions : nous cherchons en permanence la valeur ajoutée (ROI) pour le SID.
C’est un autre socle fondateur de notre réflexion dans ces missions en amont des projets décisionnels.

Enfin, en guise de conclusion, je vous donne mon avis de consultant amené à dérouler ces missions :

  • Ce qui est dur dans ces missions :

Comme lors de tout audit, vos interlocuteurs principaux sont généralement ceux qui pourraient se sentir visés par les conclusions de la mission. La relation au quotidien doit être gérée avec tact et habileté … encore plus que dans n’importe quelle mission, en fait.

  • Mon principal intérêt dans ces missions :

Vous apportez en quelques jours un départ nouveau pour tous les acteurs du SID… en tout cas, c’est l’élan qu’il faut insuffler pour espérer une réussite de la mission !

Le prochain volet portera sur le conseil en Urbanisation du SID dans lequel nous retrouverons quelques principes d’ores et déjà énoncés.
Si vous avez, vous aussi, connu ce genre de situation ou si vous avez des précisions à apporter, n’hésitez pas !

SSAS : Aggréger des mesures de cube sous forme de médiane

Lors d’une récente mission chez un client nous avons été confronté au besoin d’agréger des mesures de cube sous forme de médiane.

Intérêt d’agréger une mesure en médiane

Concrètement, ce besoin revient à retourner la valeur médiane d’une mesure pour les dimensions en cours, plutôt que classiquement la somme ou la moyenne.  Sur un exemple basique, pour une mesure Chiffre d’Affaire, autour d’un axe d’analyse Région, le besoin client est de retourner la valeur médiane du CA de chacune des régions :

EX :    [Bretagne=10M€,   Sud Ouest=17M€, PACA=23M€,   Rhone Alpes=31M€,   IDF=51M€ ]

Le CA au niveau national sera la valeur médiane de la liste des valeurs régions, soit 23M€.

Fonctionnellement prendre la valeur médiane (plutôt que la valeur moyenne) a pour effet de minimiser l’impact des valeurs extrêmes, et donc de minimiser le « bruit » que pourrait provoquer des erreurs de saisie ou de chargement.

EX : Si l’on rajoute [Alsace=300M€] à la liste précédente (ce qui pourrait correspondre à une erreur de saisie – avec un zéro de trop)

La valeur médiane au niveau national est 27M€

=> L’impact de l’erreur de saisie de l’opérateur Alsacien sur le CA national est minimisé. Une agrégation en moyenne aurait « tiré vers le haut » le CA national (moyenne = 72M€)

Sur l’exemple donné – qui est volontairement simpliste – le bénéfice de l’agrégation en médiane est plutôt léger, mais sur une liste de valeurs plus importante, il y a de nombreux cas fonctionnels où la médiane d’une liste de valeurs est bien plus représentative (et intéressante pour l’utilisateur) que la moyenne .

Problématique

Le problème vient du fait que les agrégation de type médiane n’est pas supporté nativement par Analysis Services.

Type d'agrégation supportés par SSAS

Types d'agrégation supportés par SSAS

Solution

La solution que nous avons proposée est d’utiliser la fonction MDX  MEDIAN(). C’est une fonction mathématique de base qui retourne la valeur médiane d’une mesure pour un « set » donné.

Elle doit être appelée avec 2 paramètres :

  • L’ensemble de valeurs sur lequel « ventiler » la valeur médiane, le « set »
  • et la mesure à agréger

Dans le cas du CA par région cela donnerait une mesure calculée du style  :

CA_National =     MEDIAN( [Geography].[Region].Members, (= liste de valeurs)
[Measures].[CA]) (= mesure à agréger)

=> Cette solution fonctionne et retourne effectivement la valeur médiane du CA de chaque région

En allant plus loin

On remarquera qu’en réalité la solution proposée n’agrège pas – à proprement parler – en médiane : elle calcule la valeur médiane d’une mesure existante. Et ce n’est pas tout à fait la même chose ! Car cette mesure existante a son propre type d’agrégation…

C’est à dire, qu’elle calcule la valeur médiane, d’une liste de valeurs qui restent à leur type d’agrégation par défaut. Dans l’exemple, la formule d’agrégation ne fonctionne qu’au niveau national : la valeur retournée est la médiane des valeurs CA au niveau région, valeurs qui sont elle même agrégées… dans leur type d’agrégation par défaut définit dans SSAS (c’est à dire Somme, Moyenne etc…)

Le besoin de notre client était plus complexe que cela : il souhaitait une valeur médiane d’une mesure quelque soit l’axe d’analyse et quelque soit le niveau de navigation dans la dimension.

Par exemple sur une mesure DélaisRésolutionIncident, le souhait est de voir retournée la valeur médiane (de toute les valeurs disponibles) quelque soit l’axe d’analyse : que ce soit au niveau d’un mois, d’une année, d’un service, d’une région, d’une sous région etc.

Nous avons proposé une solution calée sur la précédente : utiliser la fonction MEDIAN en passant cette fois comme « set »  l’ensemble des lignes  de faits disponibles. Cela donne quelque chose comme :

MEDIAN_DelaisResIncident =     MEDIAN( [DimFait].[DimFait hierarchy].[DimFait fact line].Members, (= ensemble des lignes de fait)
[Measures].[ValDelaisResolutionIncident]) (= mesure à agréger)

Pour cette formule nous avons du créer dans le cube – via le DSV – une dimension de fait dont le nombre de lignes au niveau le plus fin est exactement le même que celui de la table de fait. Cette dimension « virtuelle » ne sert qu’à définir le « set » de valeurs.

=> Cette solution fonctionne et permet une réelle agrégation de mesure sous forme de médiane.

PS : Ce second exemple illustre bien l’intérêt de la médiane évoqué en introduction : si par exemple un incident est resté non clôturé plusieurs mois, alors que généralement ils le sont en quelques minutes, cette anomalie « pourrira » l’indicateur de moyenne. L’indicateur de médiane en revanche sera bien plus pertinent pour l’utilisateur.

Temps de réponse

Si la solution proposée fonctionne sur le papier et avec nos jeux de tests, elle s’est révélée un peu décevante dans la pratique. Avec l’augmentation du nombre de lignes de faits, le temps de réponse du cube explose lorsque l’on fait appel à la mesure utilisant la médiane.

En effet, avec un nombre de ligne de l’ordre de plusieurs dizaines de milliers d’enregistrements, le temps de réponse dépasse les 2 minutes (le « time out » de notre outil de restitution). A titre de comparaison, l’agrégation classique en moyenne, sur les mêmes données met moins d’une seconde…

=> Cette solution est donc à utiliser avec précaution.

Analyse

Mais pourquoi cela prend-t-il autant de temps ?

Cette fonction MDX  MEDIAN est à l’origine une fonction mathématique, pas une fonction d’agrégation. Les valeurs ne sont donc pas pré-calculées avec cette médiane comme elles le seraient avec les agrégations en Moyenne ou en Somme. La solution proposée est en réalité une utilisation détournée de la fonction MEDIAN

Dans tous les exemples d’utilisation que l’on trouve de cette fonction,  le premier paramètre (le « set ») est de cardinalité très faible. Alors que dans le cas exposé ci-dessus l’ensemble de « ventilation » est l’ensemble des lignes de faits, donc un ensemble à cardinalité plutôt élevée.

La fonction Median ne permet pas de pré-aggrégation dans la mesure ou son algorithme de résolution nécessite 2 « passages » sur la liste de valeur (là où la Moyenne n’en nécessite qu’un) : un passage pour trier toutes les valeurs, un autre pour prendre la moyenne des deux valeurs du milieu de la liste triée.

Dans le premier exemple avec le CA par région, en réalité le cube se base sur les pré-agrégations sous forme de Somme du CA stockées pour chaque région, et calcule ensuite la médiane de ces pré-agrégations. L’algorithme des 2 « passages » n’est en fait déroulé que sur une liste de 22 valeurs. Tandis que dans notre cas il est déroulé sur le nombre de lignes de fait.

=> La fonction MDX  MEDIAN n’est donc à utiliser pour agréger une mesure que sur des tables de faits de faible population.

Homsys vous souhaite une bonne année

voeuxHomsysObjetDirect2010

Categories: Divers Tags:

SSIS : Lenteurs extrêmes à l’ouverture/exécution de BIDS

Vous avez peut-être déjà rencontré un problème d’extrème lenteur à l’ouverture de BI Developement Studio (BIDS), lors de développement de flux SSIS.

Symptômes :

Le problème se manifeste par un « blocage technique » de Visual Studio (avec perte de la main) d’une durée de 8 à 15 minutes lorsque :

  • l’on ouvre un fichier de flux SSIS (*.dtsx)
  • l’on lance une exécution de flux SSIS (*.dtsx) en mode debug, (l’attente déclenchant généralement un timeout sur le « fork » du processus de debug de Visual Studio cf. ci-après)

Ce blocage est indépendant du processus (normal) de vérification des lots du package, qui intervient une fois les 8/15 minutes de blocage technique passées.

Ce problème persiste :

  • au changement de user
  • au changement de machines
  • à la bascule des fichiers et/ou bases de données en local

Le retard à l’exécution est parfois tellement important que le « fork » du thread de debug par rapport au thread de Visual Studio, passe en « time out », provoquant le message d’erreur suivant :

071708_1347_SSISLenteur1

Une fois que le « fork » a échoué une fois, toute les autres tentatives échoueront venant s’ « empiler » par process ID :

071708_1347_SSISLenteur2

Pour qu’un nouveau test d’exécution de flux en mode debug soit de nouveau effectif, il faut réinitialiser les paramètres utilisateur de Visual Studio :

  • Menu Démarrer -> Exécuter -> ‘devenv /resetsettings

Analyse :

Une analyse poussée du problème a permis de se rendre compte :

  • lorsque le problème se manifeste, une connexion HTTP est effectuée vers un serveur distant de Microsoft (crl.microsoft.com) visible avec la commande MS-DOS NETSTAT
  • cette connexion est bloquée en attente de réponse (statut SYN_SENT) (voir la copie d’écran ci-jointe)
  • au bout des 10 à 15 minutes d’attente cette connexion se ferme et le fichier s’ouvre/s’exécute -> cette connexion en attente est à l’origine du problème
  • CRL veut dire « Certificate Revocation List« , et cette connexion automatique est une vérification de licence/certificat
  • une ouverture/exécution de flux à partir d’une connexion avec un compte local (hors domaine) sur les machines concernées par le problème, ne pose pas de souci -> avec un compte local la vérification de licence n’est pas effectuée

pic1

Il semble donc qu’il s’agisse soit d’un problème de domaine utilisateur, soit de proxy/firewall qui refuse la connexion HTTP vers le site de vérification de licence.
Le compte local doit être considéré comme « suffisamment sûr » par Microsoft pour ne pas effectuer de vérification de certificat.

En attendant, l’installation du SP2 de SQL-Server 2005 sur le poste ne change rien au problème ci-dessus.

Solution/Palliatif :

Au final on peut désactiver cette vérification de certificat en effectuant les opérations suivantes :

  1. Dans les options avancées d’Internet Explorer décocher les cases « Vérification de révocations des certificats »
  2. Changer la valeur de la base de registre [HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]< de ‘23c00‘ à ‘23e00

(source : http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125768 )

Ces manipulations, semblent corriger définitivement le problème (par contre la première est à effectuer pour chaque utilisateur utilisant le poste). En attente d’une plus ample utilisation pour confirmation.
Les utilisateurs appartenant à des domaines sont probablement configurés pour faire ces vérifications de certificats par défaut, tandis que les utilisateurs locaux ne les font pas, ce qui peut expliquer les différences que nous constations.

Sources :

Categories: Trucs & astuces Tags: , , , ,