Mon retour sur le SQLSaturday Paris 2014

SQLSAT323_webIl y a des moments dans la vie où on est heureux d’avoir accompli quelque chose.
Des évènements, nous en organisons depuis un moment et, là, j’ai l’impression d’avoir fait quelque chose d’exceptionnel.

Évidemment, vous pouvez vous dire qu’il n’y a rien d’exceptionnel à recevoir des gens, leur donner un badge et des cadeaux et d’avoir des sessions. Après tout, il y a des tas d’évènements comme celui-là, je pense au TechDays par exemple (qui est à une échelle bien supérieure d’ailleurs).

Mais là, il s’agit d’un évènement communautaire, organisé par des personnes bénévoles, qui ont fait tout cela soir et week-end.
Il s’agit de speakers qui ont pris l’avion ou le train à leurs frais (pour certains depuis l’autre côté de l’Atlantique) pour offrir à la communauté leur savoir.
Il s’agit de vous qui avez “sacrifié” un samedi pour vous perfectionner sur les technologies Data de Microsoft.
Il s’agit des sponsors qui nous suivent alors que nous ne sommes qu’une petite association sans garantie ni engagement.

La communauté et l’écosystème autour de la plateforme de données Microsoft (que l’on appelle de façon courte la communauté SQL), c’est vous, c’est nous et nous devons être fiers de ce que nous avons accompli.

Bien sûr, il y a des choses à améliorer et on espère que vous nous le remonterez dans les jours qui viennent. Mais dites nous également ce que vous avez aimé. C’est important car, d’une part ça nous fait plaisir, mais aussi car nous comprenons ainsi mieux vos attentes.

Donc merci, merci, merci la communauté SQL Server pour avoir joué le jeu de ce SQLSaturday.

Je tiens tout particulièrement à remercier David Joubert, Grégory Boge, Philippe Geiger et Charles-Henri Sauget. Ils ont abattu un boulot formidable lors des nombreux mois de préparation mais aussi le jour J, où, même si ça passe toujours inaperçu, il y a des dizaines de choses à traiter.
Merci à vous les gars !

Je terminerai avec un mot sur les pré-conférences. Pour nous, c’est une véritable réussite. Sans aller jusqu’à dire que nous n’y croyions pas du tout (nous ne les aurions pas tentées), nous étions sceptiques sur un tel format en France. Ailleurs dans le monde, dépenser quelques euros et passer une journée avec un expert, c’est tout à fait normal car c’est investir pour soi-même. En France, on le réclame comme un dû et on tombe vite dans le volume subventionné plutôt que la qualité et l’objectif initial.
Et pourtant, les professionnels SQL ont répondu présents…
Vous étiez 35 à venir nous écouter parler de nos domaines d’expertise et c’est au-delà de ce que nous attendions. J’espère que vous avez trouvé ce format, à mi-chemin entre la conférence et la journée de formation, adapté et intéressant.
Nous espérons le renouveler par la suite alors dites nous ce qu’on doit améliorer.

 

Sachez que moi j’ai pris un réel plaisir à organiser ce SQLSaturday. Parce que ces moments de communauté sont importants pour mon travail quotidien, pour partager un peu de moi, mais aussi parce que je fais ça avec les copains et néanmoins confrères (et inversement).

 

Le retour à la vie réelle est compliqué. C’est ce qu’on appelle l’effet boomerang où tout ce que vous avez mis en attente depuis 2 semaines vous revient dans la tête… Mais je ferai prochainement un article pour vous remonter quelques chiffres (après tout, on fait aussi de la BI au GUSS) ainsi qu’un article où je reviendrai plus spécialement sur mes sessions sur Power BI et le Data Stewardship.

Merci !

 

image

Une petite vue de la Tour Montparnasse à la sortie du déjeuner lors de la pré-conférence du vendredi

-

Propriété Slice dans le partitionnement de cube

Lors de la mise en place d’une évolution sur un cube que j’avais fait il y a un moment, j’en profite pour ajouter un peu de partitionnement étant donné que le cube avait bien grossi. Voulant aller vite, je crée 3 partitions, je déploie et paf, une erreur :

3240034361 : Erreurs dans le moteur de stockage OLAP : Les restrictions imposées sur un secteur de partition n’ont pas été respectées

(en anglais : Errors in the OLAP storage engine: The restrictions imposed on partition slice where violated)

Le problème vient de la propriété Slice de mes partitions que j’ai mis un peu hâtivement.

Explications en repartant du début…

 

Définir les partitions

Première chose à faire, définir les partitions. Pour cet article, je vais prendre la base Contoso (un AdventureWorks un peu plus épais) et je vais partitionner par Magasin (StoreKey).

En étudiant les données, je vois qu’elles ne sont pas distribuées également ; quelques magasins sortent du lot.

image

Je vais donc définir un schéma de partitionnement non linéaire en créant 7 partitions.

image

image

Je déploie, je process, tout va bien. Sauf qu’en testant, on peut voir que les partitions ne sont pas correctement utilisées dans les requêtes MDX.

image

Avec une requête sur un Magasin précis, on voit avec le Profiler que plusieurs partitions sont lues.

SELECT
[Measures].[Sales Amount] ON 0
,[Calendar].[Year].Children ON 1
FROM  [Contoso]
WHERE ([Stores].[Store].&[310])

Rappelons toutefois qu’il y a 2 avantages au partitionnement :

  • Optimisation des requêtes (on vient d’en parler)
  • Optimisation du Process en ne traitant que la “dernière” partition

Ce second point peut à lui seul justifier la mise en place de partitions. A ce propos, Microsoft recommande de partitionner à partir de 2 millions de lignes.

Propriété Slice

Si le moteur ne pointe pas directement sur la bonne partition, c’est parce que, dans mon partitionnement, je dois lui indiquer sur quel critère.

En SSAS multidim, cette clé de partitionnement s’appelle un Slice (traduit par “tranche” dans les outils en français). On trouve cette propriété Slice sur l’objet Partition.

image
(cliquer pour agrandir)

Cette propriété attend une expression en MDX qui renvoie un Tuple ou un Set. Ainsi pour notre partitionnement par Magasin, on aura une instruction comme celle-ci :

{[Stores].[Store].&[199],[Stores].[Store].&[200]}

Etant donné que j’ai plus de 300 magasins sur 7 partitions, je pars sur un Range (avec un : entre mes bornes) :

{[Stores].[Store].&[201]:[Stores].[Store].&[305]}

Et pour la première et la dernière partition,

{null:[Stores].[Store].&[198]}
{[Stores].[Store].&[311]:null}

En testant dans une requête MDX, cela fonctionne très bien.

SELECT
[Measures].[Sales Amount] ON 0
,{null:[Stores].[Store].&[199]} ON 1
FROM  [Contoso]

Sauf que c’est ce Range qui est à l’origine de l’erreur au Processing !

Pourquoi ?

Au traitement, Analysis Services utilise ce que vous avez mis dans la propriété Slice dans une instruction StrToMember(“propriété slice”, CONSTRAINED). Et la fonction StrToMember, en mode CONSTRAINED, ne supporte pas les Range… Triste

image
(cliquer pour agrandir)

Quelques références sur les limitations de STRTOMEMBER :

La solution ?

Elle est simple, il vous faut indiquer TOUS les membres de la partitions dans votre Set. Ou encore créer plus de partitions.  C’est pourquoi la gestion des partitions est souvent automatisée (PowerShell avec AMO, SSIS), mais ça, ce sera pour un prochain article.

Pour conclure, une fois les slices correctement définis sur les partitions, ma requête MDX requête la bonne partition, et uniquement celle-ci.

image

AutoSlice

Si vous avez correctement suivi, vous avez dû remarquer qu’il y a un truc qui ne colle pas. J’ai 7 partitions et quand j’ai requêté sans les Slices définis, il n’a scanné que 4 partitions. Pourquoi ?

Tout simplement car Analysis Services essaye quand même de déduire le critère de partitionnement au moment du Processing. Dans ces métadonnées, il indique les valeurs min et max de chaque dimension.

image
(cliquer pour agrandir)

C’est pour cela qu’il arrive à se débrouiller pour retrouver les partitions éligibles. Mais comme vous avez pu le voir, ce n’est pas parfait (principalement car il peut y avoir de l’overlap).

Pour creuser l’AutoSlice, je vous renvoie à l’article de Shabnam Watson : http://shabnamwatson.wordpress.com/2013/06/27/setting-the-slice-for-ssas-partitions/

 

-

Session sur le Data Stewardship au #SQLBits

Voilà, ça c’est fait ! Notre tournée internationale en tant que speakers s’achève avec une session au SQLBits, en Angleterre.

Le SQLBits, c’est la plus grosse conférence SQL Server en Europe. Organisée depuis 2007 par la communauté du Royaume-Uni (très riche et très active), ils en sont à leur 12 édition, gage de sérieux. Je participais à mon premier SQLBits et je dois dire que j’ai été bluffé par la qualité et l’importance de l’événement.

  • 1300 participants (!!)
  • 3 jours de conférences dont 1 journée gratuite consacrée à la communauté
  • 8 tracks, + de 100 sessions
  • 1 “Distingued Engineer” de l’équipe SQL Server en Keynote : Niguel Ellis
  • Des speakers venus des 4 coins du monde
  • 1 soirée absolument A-WE-SO-ME !!

 

Pour ma part, je présentais une session avec Florian Eiden (b|t) sur le Data Stewardship : “Fasten your seat belt and listen to the (Data) Steward

image

Nous avons parlé de Self-Service BI et de Gouvernance des données en entreprise autour de Power BI (et au delà). Nous avons apporté un éclairage sur le profil et le rôle d’un Data Steward dans une organisation qui développe la BI personnelle pour ses utilisateurs.

 

imageimageimage

Etant donné que la session était tôt le matin (8h15) et le sujet non-technique, la salle était peu remplie mais nous sommes ravis d’avoir pu partager notre approche et notre expérience. Et le tout…en anglais ; et je dois dire que ça a été la partie la plus compliquée, n’étant pas bilingues. Mais on a fait le job et on s’excuse encore pour les fautes de grammaire, le vocabulaire pas forcément précis et notre French-accent Sourire.

Je remercie fortement les organisateurs de nous avoir fait confiance pour cette session.

SSRS sur Power Pivot dans SharePoint – Configuration Kerberos

Dans l’article précédent, je présentais un scénario de Self-Service BI : faire des rapports Reporting Services sur des modèles Power Pivot.

Techniquement, c’est un peu comme ouvrir un classeur Power Pivot dans SharePoint dont vous avez le schéma d’exécution ci-dessous. En requêtant le fichier XLSX, ce sont d’abord les services Excel qui répondent puis passent le relai au service Power Pivot.

image
source MSDN

Dans le cadre d’un appel via EWA (Excel Web Access), la sécurité est gérée par SharePoint lui-même. En effet, la sécurité est au niveau du classeur et dès que EWA l’a vérifié, c’est lui qui fait le boulot et s’arrange avec l’instance SSAS de PowerPivot (je l’ai fait courte).

Avec SSRS en tête de chaine, c’est un peu différent puisque que SSRS se présente avec l’identité de l’utilisateur directement au service Power Pivot (après avoir que EWA ait fait le forwarde vers les Web Services Power Pivot). Le problème c’est que le service Power Pivot est configuré pour fonctionner en NTLM et là, on est confronté au problème du double-hop si SSAS et la ServiceApp sont sur des machines différentes de la ferme.

 

Kerberos ?

Oui, la réponse est Kerberos, comme j’ai déjà pu en parler lors de différentes conférences.

Les étapes (en résumé) :

  1. Configurer le service Power Pivot pour supporter Kerberos
  2. Créer les SPN et les délégations entre la ServiceApp Power Pivot et l’instance SSAS

 

Le point noir, c’est que la première étape nécessite la modification de fichier Web.config  dans la ferme, chose que les administrateurs SharePoint autorisent rarement…

 

Sources :

http://blogs.msdn.com/b/johndesch/archive/2012/04/23/using-powerpivot-workbooks-from-a-mid-tier-server-configured-for-kerberos-authentication.aspx
http://sharepointalldocs.blogspot.fr/2011/12/ssrs-reports-or-excel-services.html

Rapports SSRS sur un modèle Power Pivot dans SharePoint

Un pur scénario de Self-Service BI

Un scénario que j’aime beaucoup dans une plate-forme BI est la possibilité de créer des rapports Reporting Services (SSRS) avec comme source de données un classeur Power Pivot.

Ce scénario est essentiel dans un cadre de Self-Service BI puisqu’il permet à un utilisateur métier de rapidement mettre en ligne un modèle multidimensionnel (ou tout simplement une table de données) et de disposer d’un outil de reporting mature (ou Old-School selon le point de vue Sourire).

Bien évidemment, en 2014, on cible plutôt des tableaux de bord réalisés avec Excel Services ou Power View mais SSRS couvre un certain type de reporting :

  • mise en forme précise / dynamique
  • positionnement précis / dynamique
  • cartographie (avec des shapes ou des fonds de cartes personnalisées)
  • impression, export PDF
  • abonnements, data alerts
  • etc.

Qu’on se le dise, je ne fais pas de plébiscite pour SSRS au détriment de Power View ou Excel. Chacun a son propre usage de prédilection, ses avantages et ses inconvénients. Ils doivent être dans la boite à outils des architectes BI comme des utilisateurs.

 

Comment faire  ?

C’est super simple :

  1. Téléchargez votre classeur Power Pivot dans une bibliothèque de documents (pas forcément dans la galerie Power Pivot)
  2. Créez un nouveau rapport avec Report Builder
  3. Créez une source de données de type Analysis Services (Power Pivot pour SharePoint est un serveur SSAS)
  4. Dans la chaîne de connexion, indiquez l’URL du classeur Power Pivot

image

 

Documentation MSDN : http://msdn.microsoft.com/fr-fr/library/ff713974.aspx

 

Mais attention, sur une ferme SharePoint (ie. plusieurs serveurs) il vous faudra configurer quelques points (en lien avec Kerberos indeed Sourire). Mais ce sera l’objet de l’article suivant.

Utilisation de Power Map avec un proxy

Power Map utilise les cartes de Bing Maps pour le géo-coding (ie. trouver les coordonnées latitude/longitude d’une adresse) et le rendu (fonds de carte). C’est le point principal qui explique la nécessité d’avoir une connexion Internet pour que Power Map fonctionne.

image

Comme dans beaucoup de société, il est possible qu’un proxy se trouvent entre Power Map (ie. Excel) et les API de Bing Maps. Dans la plupart des cas (que j’ai pu constater), il n’y a rien à faire, Power Map se basant sur la configuration par défaut, c’est à dire celle d’IE. Mais dans quelques cas, vous allez devoir paramétrer les informations du proxy.

Pour cela, il vous faut créer un fichier de configuration (façon .NET) avec la section afférente au Proxy.

 

<?xml version="1.0" encoding="utf-8" ?> 
< configuration> 
  <system.net> 
    <defaultProxy useDefaultCredentials="true" /> 
  </system.net> 
< /configuration>

 

Pour trouver la bonne configuration, referez vous à la documentation XML : http://msdn.microsoft.com/en-us/windows/dkwyc043(v=vs.71).aspx

 

Reste à savoir comment nommer le fichier et où le placer.

Le fichier est le fichier de configuration d’Excel, il doit donc se nommer excel.exe.config et se trouver dans le même dossier qu’Excel.exe (C:\Program Files\Microsoft Office 15\root\office15).

Toutefois, certains articles font état du dossier de Power Query (C:\Program Files\Microsoft Power Query for Excel\bin) et le nom du fichier de configuration sera microsoft.mashup.container.exe.config.
Note : Je n’ai pas rencontrer ce cas mais par souci d’exhaustivité, je le retrace ici.

 

Source : http://social.technet.microsoft.com/Forums/en-US/577d7263-4d09-4550-b0fc-3592cd465a55/power-map-and-internet-connectivity?forum=powermap

Retour sur le SQLSaturday Rheinland

imageSamedi dernier avait lieu le SQLSaturday Rheinland en Allemagne, plus précisément à Sankt-Augustin, entre Cologne et Bonn.

La communauté française y était bien représentée puisque nous sommes 4 speakers (2 binômes) à y être allé : Florian Eiden, David Joubert et Jordan Mootoosamy.

Je félicite les organisateurs Oliver Engels, Tillmann Eitelberg et Kostja Klein, nos homologues allemands, pour cette superbe conférence.

Les points clés :

  • Beaucoup de speakers internationaux (dont des français)
  • Beaucoup de sponsors (20 !)
  • Beaucoup de cadeaux (cf. sponsors)
  • Un hackathon Big Data organisé la veille
  • Un lieu adapté (une université)
  • Un dîner speakers/sponsors vraiment agréable
  • Une visite touristique le dimanche (nous avions le train tôt et nous n’avons pas pu y participer)

image
©Dirk Hondong

C’est à chaque fois un réel plaisir de revoir la #SQLFamily (européenne) et de tisser ou consolider les liens avec nos homologues. On espère qu’ils seront aussi enchantés que nous lors de notre SQLSaturday à Paris en septembre.

image
©Dirk Hondong

 

Power Query v. SSIS

David et moi présentions une session plutôt technique (90% de démos) sur la bataille des ETLs.

Représentant Power Query dans le coin vert, j’ai sorti mes plus belles démos pour pousser les limites du Self-Service ETL.
Représentant le poids lourd SSIS dans le coin rouge, David a montré les capacités des packages.

Slide sur Slideshare : http://fr.slideshare.net/djeepy1/sqlsaturday-rheinland-2014-power-query-vs-ssis

Code des démos : OneDrive de Djeepy1

image

Certes, on a fait une fin à l’école des fans mais comme nous concluons, ”it’s a matter of Philosophy”

image

 

 

Agile Datawarehousing

Florian et Jordan ont présenté quant à eux une superbe session sur la BI Agile. L’agilité étant la marotte de Florian, je ne doutais pas une seule seconde de l’intérêt de la session et je n’ai pas été déçu. L’approche est excellente et je partage totalement tous les principes évoqués !!