Vous pouvez donc me retrouver à l'adresse suivante (mettez à jour vos favoris, si jamais j'y étais :p)
vendredi 20 juin 2014
Migration vers Wordpress
Juste avant l'été et histoire de faire comme les petits copains de la communauté, je migre mon blog vers Wordpress.
Vous pouvez donc me retrouver à l'adresse suivante (mettez à jour vos favoris, si jamais j'y étais :p)
Vous pouvez donc me retrouver à l'adresse suivante (mettez à jour vos favoris, si jamais j'y étais :p)
jeudi 12 juin 2014
[Big Data] Installation Hortonworks Data Platform (HDP) sur Windows en mode multi noeuds
Pour faire suite à mon article précédent qui présentait l'installation d'HDP en mode simple noeud, on va s'intéresser ici à l'installation en mode multi-noeuds (histoire de ne pas usurper l'appellation cluster :p)
L'idée du test est d'avoir une machine maître et 2 machines esclaves.
Pour cela, en premier lieu, on se crée un réseau dans Azure afin d'y faire communiquer nos 3 machines (On peut vraiment créer beaucoup de choses dans Azure, je n'avais jusque là pas trop pratiqué, mais je suis déjà fan de la plateforme)
Petite attention : je vous conseille de les créer sur le même service cloud histoire de faciliter la résolution de noms dans Azure :
http://msdn.microsoft.com/fr-fr/library/azure/jj156088.aspx
C'est un conseil plus que recommandé, car sur les tests que j'ai pu faire, l'installation fonctionne beaucoup mieux avec les hostnames qu'avec des IP :p
J'ai pris le même sizing que dans l'article précédent (format de base, A2, Windows Server 2012, etc)
Les noms des machines et leurs IP :
CH-MASTER : 192.168.0.4
CH-SLAVE1 : 192.168.0.5
CH-SLAVE2 : 192.168.0.6
Les points d'attention d'une installation simple noeud restent vrais : variables d'environnements pour Java, exécutable pour Python.
Pour une machine de test et ne pas se créer de souci supplémentaire, on désactive aussi les firewall de toutes les machines, dans la vraie vie, il conviendrait de mapper les ports.
Pour cela, on a besoin du fichier clusterproperties.txt suivant :
On exécute ensuite la commande suivante :
Attention le /qn qui permet de passer outre l'interface graphique est obligatoire, sinon votre fichier clusterproperties ne sera pas utilisé. Et je n'ai pas réussi à passer de la configuration multi-noeuds avec cette interface.
L'autre point gênant, c'est que cette commande rend la main dès son exécution : on ne sait donc pas où en est l'avancement de l'installation à moins de fouiller dans les logs (qui ne sont pas toujours explicites)
L'installation est finie lorsque sur le bureau, vous avez un raccourci vers les 3 pages web de suivi du cluster et un raccourci vers une invite de commande hadoop.
Cette commande est à exécuter sur les 3 machines avec le même fichier de configuration.
Il ne reste plus qu'à lancer les services par la commande suivante sur les 3 machines :
A noter qu'il existe une commande start_remote_hdp_services.cmd à exécuter sur le noeud maitre pour lancer les services sur les noeuds esclaves. Mais je ne suis pas parvenu à la faire fonctionner. J'ai différentes pistes :
- la première est qu'elle ne fonctionnait pas sur d'anciennes versions d'HDP et je ne sais pas si cela a été corrigé (http://hortonworks.com/community/forums/topic/cant-start-on-windows/)
- la deuxième serait sur un problème d'exécution de powershell à distance (http://hortonworks.com/community/forums/topic/install-ok-but-trouble-validating/). Je n'ai pas eu beaucoup de succès dans mes essais de configuration à ce sujet, et je n'ai pas eu le courage d'installer un contrôleur de domaine pour aller plus loin.
Toujours est-il que le cluster est fonctionnel :
Il ne vous reste qu'à lancer un Run-SmokeTests.cmd pour vérifier que tout marche bien :
L'idée du test est d'avoir une machine maître et 2 machines esclaves.
Pour cela, en premier lieu, on se crée un réseau dans Azure afin d'y faire communiquer nos 3 machines (On peut vraiment créer beaucoup de choses dans Azure, je n'avais jusque là pas trop pratiqué, mais je suis déjà fan de la plateforme)
Petite attention : je vous conseille de les créer sur le même service cloud histoire de faciliter la résolution de noms dans Azure :
http://msdn.microsoft.com/fr-fr/library/azure/jj156088.aspx
C'est un conseil plus que recommandé, car sur les tests que j'ai pu faire, l'installation fonctionne beaucoup mieux avec les hostnames qu'avec des IP :p
J'ai pris le même sizing que dans l'article précédent (format de base, A2, Windows Server 2012, etc)
Les noms des machines et leurs IP :
CH-MASTER : 192.168.0.4
CH-SLAVE1 : 192.168.0.5
CH-SLAVE2 : 192.168.0.6
Pré-requis
Les pré-requis restent les mêmes que sur une installation simple noeud : vous n'échapperez donc pas à l'installation de Java, Python et Visual C++ sur toutes les machines.Les points d'attention d'une installation simple noeud restent vrais : variables d'environnements pour Java, exécutable pour Python.
Pour une machine de test et ne pas se créer de souci supplémentaire, on désactive aussi les firewall de toutes les machines, dans la vraie vie, il conviendrait de mapper les ports.
Installation HDP
On peut ensuite passer à l'installation d'HDP.Pour cela, on a besoin du fichier clusterproperties.txt suivant :
| #Log directory HDP_LOG_DIR=c:\hadoop\logs #Data directory HDP_DATA_DIR=c:\hdpdata #hosts NAMENODE_HOST=CH-MASTER SECONDARY_NAMENODE_HOST=CH-MASTER RESOURCEMANAGER_HOST=CH-MASTER HIVE_SERVER_HOST=CH-MASTER OOZIE_SERVER_HOST=CH-MASTER WEBHCAT_HOST=CH-MASTER SLAVE_HOSTS=CH-SLAVE1,CH-SLAVE2 ZOOKEEPER_HOSTS=CH-MASTER CLIENT_HOSTS=CH-MASTER #Database host DB_FLAVOR=DERBY DB_HOSTNAME=CH-MASTER DB_PORT=1527 #Hive properties HIVE_DB_NAME=hive_db HIVE_DB_USERNAME=hive HIVE_DB_PASSWORD=hive #Oozie properties OOZIE_DB_NAME=oozie_db OOZIE_DB_USERNAME=oozie OOZIE_DB_PASSWORD=oozie |
On exécute ensuite la commande suivante :
msiexec /qn /i "hdp-2.1.1.0.winpkg.msi" /lv "log.txt" HDP_USER_PASSWORD="Password01" HDP_LAYOUT="C:\HDP_INSTALL\clusterproperties.txt" HDP_DIR="C:\HDP" DESTROY_DATA=yes HDP=no
L'autre point gênant, c'est que cette commande rend la main dès son exécution : on ne sait donc pas où en est l'avancement de l'installation à moins de fouiller dans les logs (qui ne sont pas toujours explicites)
L'installation est finie lorsque sur le bureau, vous avez un raccourci vers les 3 pages web de suivi du cluster et un raccourci vers une invite de commande hadoop.
Cette commande est à exécuter sur les 3 machines avec le même fichier de configuration.
Il ne reste plus qu'à lancer les services par la commande suivante sur les 3 machines :
C:\HDP>start_local_hdp_services.cmd
 |
| Sur un noeud esclave |
 |
| Sur le noeud maitre |
- la première est qu'elle ne fonctionnait pas sur d'anciennes versions d'HDP et je ne sais pas si cela a été corrigé (http://hortonworks.com/community/forums/topic/cant-start-on-windows/)
- la deuxième serait sur un problème d'exécution de powershell à distance (http://hortonworks.com/community/forums/topic/install-ok-but-trouble-validating/). Je n'ai pas eu beaucoup de succès dans mes essais de configuration à ce sujet, et je n'ai pas eu le courage d'installer un contrôleur de domaine pour aller plus loin.
Toujours est-il que le cluster est fonctionnel :
Il ne vous reste qu'à lancer un Run-SmokeTests.cmd pour vérifier que tout marche bien :
vendredi 6 juin 2014
[Big Data] Installation Hortonworks Data Platform (HDP) sur Windows
Hortonworks est l'un des acteurs majeurs dans le domaine de la distribution Hadoop dans le monde, et le seul pour le moment à s'intéresser à l'écosystème Microsoft, en proposant 2 offres orientées Cloud ou On-Premise :
HDInsight est facile à mettre en oeuvre car il ne nécessite aucune installation à proprement parler, il suffit juste de créer des stockage et le cluster dans Azure. Ce qui se fait en quelques clics (on trouve pas mal de tuto sur les blogs, celui de Romain par exemple)
L'idée, dans cet article, est de regarder comment se passe l'installation d'HDP sur un serveur Windows Server 2012. On va rester sur le cas simple d'un serveur simple nœud.
Commençons par créer la machine virtuelle dans Azure (Windows Server 2012 Datacenter, Taille A2)
Quelques tests plantent car je n'ai pas installé tous les add-in.
En bref
- Hortonworks Data Platform (HDP), à installer soit-même, et donc plutôt on-premise (rien ne vous empêche cependant de stocker les machines dans le cloud), version qui nous intéresse aujourd'hui.
- HDInsight, basé sur HDP, produit par Microsoft et disponible dans Azure.
HDInsight est facile à mettre en oeuvre car il ne nécessite aucune installation à proprement parler, il suffit juste de créer des stockage et le cluster dans Azure. Ce qui se fait en quelques clics (on trouve pas mal de tuto sur les blogs, celui de Romain par exemple)
L'idée, dans cet article, est de regarder comment se passe l'installation d'HDP sur un serveur Windows Server 2012. On va rester sur le cas simple d'un serveur simple nœud.
Commençons par créer la machine virtuelle dans Azure (Windows Server 2012 Datacenter, Taille A2)
Une fois la machine créée, on y uploade :
- le zip contenant les fichiers d'install d'HDP (à downloader ici)
- le JDK de Java (mini version 7), Python (mini version 2.7) et les packages Visual C++ distributable, tous étant des pré-requis à l'installation
La version 4.0 du Framework .NET est également requise, mais une version plus récente est déjà installée sur Windows Server 2012.
Installer les pré-requis
Visual C++ s'installe par double-clic.
Pour Java, il est impératif de ne pas avoir d'espace dans le path du répertoire d'installation (et donc de ne pas garder le répertoire par défaut en "Program Files")
De même, une fois Java installé, il faut créer une variable d'environnement qui mappe le répertoire, et rajouter le \bin au PATH :
Pour Python, c'est du double-clic aussi, juste faire attention à rajouter l'installation de l'exe qui n'est pas sélectionnée par défaut.
Enfin pour finir les pré-requis et ne pas se générer de problème supplémentaire, on va désactiver le pare-feu Windows :
Installer Hortonworks Data Platform
On est enfin prêt à passer à l'installation effective de HDP.
Dans une commande prompt, il faut lancer l'instruction suivante :
runas /user:djuber "cmd /C msiexec /lv c:\hdplog.txt /i C:\HDP_INSTALL\hdp-2.1.0.0.winpkg.msi"
où djuber doit être votre compte administrateur et C:\HDP_INSTALL le dossier où vous avez extrait le zip d'HDP que vous aviez téléchargé.
Cela ouvre la page de setup d'HDP :
Si les répertoires d'installation par défaut vous conviennent, n'y touchez pas. Choisissez "Configure Single Node".
Le "Delete existing HDP Data" n'est pas forcément nécessaire dans notre cas, mais il assure que le HDFS sera formaté.
Enfin la dernière partie concerne la configuration des bases Hive et Oozie (Pensez à choisir DERBY comme base de données si vous n'avez pas de SQL Server sous la main).
On peut enfin lancer l'installation.
 |
| Un panneau Warning pour vous dire que l'installation a réussi, c'est assez original |
Votre cluster Hadoop (simple noeud) est désormais fonctionnel, il ne vous reste plus qu'à lancer les services et lancer un batch pour vérifier qu'il fonctionne
Lancer les services :
Placer vous dans le répertoire c:\HDP (si vous n'avez pas touché aux répertoires par défaut) et lancer l'instruction suivante :
start_local_hdp_services.cmd
Sur les 13 services, 1 ne démarre pas : hwi pour Hive Web Interface, l'interface graphique de Hive. Apparemment, un problème connu, peut-être du à IIS, le sujet semble être encore ouvert (voir http://hortonworks.com/community/forums/topic/hdp-2-1-hwi-start-failure/).
On peut désormais vérifier que le serveur est actif en cliquant sur la page web disponible sur le bureau (Hadoop Name Node Status)
Lancer un batch
Il ne reste qu'à lancer un petit batch de map/reduce (fourni par HDP) pour tester notre cluster :
il faut lancer la console Hadoop (créée sur le bureau également) en mode administrateur et exécuter la commande suivante :
Run-SmokeTests.cmd
Quelques tests plantent car je n'ai pas installé tous les add-in.
En bref
L'installation n'est donc pas compliquée en soit, il faut bien respecter les pré-requis. Néanmoins quelques erreurs peuvent se produire, et il n'est pas toujours évident de trouver de la littérature sur le sujet.
C'est là où HDInsight est vraiment intéressant en permettant d'outrepasser toute difficulté d'installation.
mardi 20 mai 2014
Very Good Trip
Pas de vacances cette année (changement de boîte oblige, on y reviendra plus tard), mais un road trip européen pour participer à des conférences en contrepartie.
Sous l'impulsion de Jean-Pierre qui souhaite commencer sa carrière de speaker international, nous voilà programmés avec Florian Eiden et Jordan Mootoosamy. au SQL Saturday de Cologne le 28 Juin 2014.
2 sessions ont été retenues :
La route ne s'arrêtera pas là, car on ira, Florian et moi, le 19 Juillet au SQLBits à Birmingham, accompagner Jean-Pierre le temps d'une session autour des nouveaux paradigmes de la BI :
Enfin le 13 Septembre, même si rien n'est encore acté, nous avons bon espoir d'être speaker au SQL Saturday Paris.
L'occasion d'ailleurs de vous rappeler que l'appel aux speakers est encore ouvert et qu'il ne faut pas hésiter à proposer des sessions.
Bref, un été bien sympa en perspective.
D'abord l'Allemagne
 |
| On ne dira pas qui est qui... |
Sous l'impulsion de Jean-Pierre qui souhaite commencer sa carrière de speaker international, nous voilà programmés avec Florian Eiden et Jordan Mootoosamy. au SQL Saturday de Cologne le 28 Juin 2014.
2 sessions ont été retenues :
- Un "duel" SSIS versus Power Query que j'animerai avec Jean-Pierre (connaissant nos préférences, on sait déjà qui défendra quel outil :p)
- Une session sur la BI Agile pour Florian et Jordan (l'occasion d'un retour d'expérience de leur mission actuelle)
Direction l'Angleterre
La route ne s'arrêtera pas là, car on ira, Florian et moi, le 19 Juillet au SQLBits à Birmingham, accompagner Jean-Pierre le temps d'une session autour des nouveaux paradigmes de la BI :
Fasten Seat Belt and look at the Data Steward
In that session we will discuss about Data Governance, mainly around that fantastic platform Power BI (but also around on-prem concerns). How to avoid dataset-hell ? What are the best practices for sharing queries ? Who is the famous Data Steward and what is its role in a department or in the whole company ? How do you choose the right person ?
Keywords : Power Query, Data Management Gateway, Power BI Admin Center, Datastewardship, SharePoint 2013, eDiscovery
Retour en France
L'occasion d'ailleurs de vous rappeler que l'appel aux speakers est encore ouvert et qu'il ne faut pas hésiter à proposer des sessions.
Bref, un été bien sympa en perspective.
mardi 8 avril 2014
Serveurs liés : mauvaise performance ?
On entend souvent qu'il faut éviter les serveurs liés dans les requêtes, et je suis plutôt d'accord avec cette assertion. J'ai néanmoins rencontré une anecdote amusante en mission :
La requête de base est la suivante (un peu modifiée pour qu'elle soit plus lisible an cachant les champs parce que ce sont les vraies tables)
L'index cluster de la table FtDelivery est composé de Id_DimDate, Id_DimProduct, champ1, ..., Id_DimTransactionType
Le champ ValidityFlag ne fait pas partie de l'index cluster
Cette requête s'exécute sur le serveur où se trouve la table dbo.testProduit en 46s selon le plan d'exécution suivant :
L'idée d'optimisation a été de rapatrier la table testProduit directement sur le serveur lié et d'exécuter la requête sur ce dernier.
On passe donc à la requête suivante :
On l'exécute sur le serveur qui était lié. Et là, surprise, elle met 14 min en utilisant le plan d'exécution ci-dessous :
Belle optimisation n'est-ce pas ? Je supprime les serveurs liés et je multiplie par 20 les temps d'exécution.
Alors évidemment, SQL Server me propose de créer un index sur les colonnes de ma clause WHERE avec un include des colonnes du SELECT, mais cela ne m'arrange pas (la table a déjà quelques index et elle est particulièrement volumineuse. Il y a de plus plusieurs requêtes de ce type à exécuter, donc un index par requête ma paraît difficilement envisageable)
Ce qu'il est amusant de remarquer ici, c'est que le serveur lié permet de supprimer la clause WHERE coûteuse de ma requête, ce qui rend la "remote query" de mon premier plan d'exécution beaucoup plus rapide que la requête complète du deuxième plan. Tellement plus rapide que le "nested loop" s'en sort mieux qu'une jointure standard.
Bon c'est une vérité qui se vérifie dans ce cas précis, loin de moi l'idée de conseiller de mettre des serveurs liés partout. Surtout que sur ce même projet et de manière générale, c'est l'inverse qui se produit.
Mais le résultat semblant paradoxal et peu naturel, je trouvais sympa de le partager.
Mise à Jour :
Comme l'histoire des statistiques dans le commentaire de Romain me travaillait, j'ai ré-exécuté en étant sûr de les avoir mises à jour.
J'en ai profité pour supprimer le cache avant l'exécution des requêtes et c'est déjà plus cohérent. L'explication est aussi plus claire.
La requête avec serveur lié s'exécute en 12min35 à la première exécution et 45s à la seconde exécution.
La requête sans serveur lié s'exécute en 16min01 à la première exécution et 45s ensuite.
C'est déjà rassurant sur le fonctionnement du cache :p
La différence de temps d'exécution tient dans la 'remote query' (bien vu Romain, je ne l'avais pas regardé en détail, je pensais qu'elle supprimait la clause pas qu'elle la transformait)
Alors que dans le cas sans serveur lié SQL Server considère plus judicieux d'utiliser l'index cluster de la table FtDelivery, la 'remote query' fonctionne par boucle sur un paramètre pour le produit (au lieu du 'in' de la requête, il boucle en utilisant un '='). De ce fait, SQL Server considère plus rapide (et c'est le cas) d'utiliser un index sur le produit existant sur FtDelivery (cf plan d'exécution ci-dessous)
Les temps d'exécutions n'ont plus un rapport de 20, par contre, on reste bien sur un temps avec serveur lié plus rapide que sans. On constate aussi que c'est bien spécifique à la construction et l'indexation de la table.
La requête de base est la suivante (un peu modifiée pour qu'elle soit plus lisible an cachant les champs parce que ce sont les vraies tables)
L'index cluster de la table FtDelivery est composé de Id_DimDate, Id_DimProduct, champ1, ..., Id_DimTransactionType
Le champ ValidityFlag ne fait pas partie de l'index cluster
Cette requête s'exécute sur le serveur où se trouve la table dbo.testProduit en 46s selon le plan d'exécution suivant :
L'idée d'optimisation a été de rapatrier la table testProduit directement sur le serveur lié et d'exécuter la requête sur ce dernier.
On passe donc à la requête suivante :
On l'exécute sur le serveur qui était lié. Et là, surprise, elle met 14 min en utilisant le plan d'exécution ci-dessous :
Belle optimisation n'est-ce pas ? Je supprime les serveurs liés et je multiplie par 20 les temps d'exécution.
Alors évidemment, SQL Server me propose de créer un index sur les colonnes de ma clause WHERE avec un include des colonnes du SELECT, mais cela ne m'arrange pas (la table a déjà quelques index et elle est particulièrement volumineuse. Il y a de plus plusieurs requêtes de ce type à exécuter, donc un index par requête ma paraît difficilement envisageable)
Ce qu'il est amusant de remarquer ici, c'est que le serveur lié permet de supprimer la clause WHERE coûteuse de ma requête, ce qui rend la "remote query" de mon premier plan d'exécution beaucoup plus rapide que la requête complète du deuxième plan. Tellement plus rapide que le "nested loop" s'en sort mieux qu'une jointure standard.
En d'autres termes, le serveur lié permet d'optimiser la requête.
Bon c'est une vérité qui se vérifie dans ce cas précis, loin de moi l'idée de conseiller de mettre des serveurs liés partout. Surtout que sur ce même projet et de manière générale, c'est l'inverse qui se produit.
Mais le résultat semblant paradoxal et peu naturel, je trouvais sympa de le partager.
Mise à Jour :
Comme l'histoire des statistiques dans le commentaire de Romain me travaillait, j'ai ré-exécuté en étant sûr de les avoir mises à jour.
J'en ai profité pour supprimer le cache avant l'exécution des requêtes et c'est déjà plus cohérent. L'explication est aussi plus claire.
La requête avec serveur lié s'exécute en 12min35 à la première exécution et 45s à la seconde exécution.
La requête sans serveur lié s'exécute en 16min01 à la première exécution et 45s ensuite.
C'est déjà rassurant sur le fonctionnement du cache :p
La différence de temps d'exécution tient dans la 'remote query' (bien vu Romain, je ne l'avais pas regardé en détail, je pensais qu'elle supprimait la clause pas qu'elle la transformait)
Alors que dans le cas sans serveur lié SQL Server considère plus judicieux d'utiliser l'index cluster de la table FtDelivery, la 'remote query' fonctionne par boucle sur un paramètre pour le produit (au lieu du 'in' de la requête, il boucle en utilisant un '='). De ce fait, SQL Server considère plus rapide (et c'est le cas) d'utiliser un index sur le produit existant sur FtDelivery (cf plan d'exécution ci-dessous)
Les temps d'exécutions n'ont plus un rapport de 20, par contre, on reste bien sur un temps avec serveur lié plus rapide que sans. On constate aussi que c'est bien spécifique à la construction et l'indexation de la table.
jeudi 3 avril 2014
MVP SQL Server - Merci !
J'ai attendu 3 jours après le 1er Avril pour faire un article (qu'on ne croit plus à une blague), mais si vous avez remarqué le petit logo sur la droite du blog, me voilà MVP sur les technologies SQL Server.
MVP, qu'est-ce que c'est pour ceux qui ne connaissent pas encore :
Le programme MVP (Microsoft Most Valuable Professional) vise à reconnaitre les experts indépendants et leaders de la communauté qui partagent leur passion, leur expertise technique et leur expérience des produits Microsoft sur le terrain. Il fait partie de l'engagement de Microsoft à soutenir et à enrichir les communautés techniques
Je rejoins donc la petite dizaine d'élus français pour équilibrer les équipes entre moteur SQL et BI :
Christophe Laporte, Arian Papillon, David Baffaleuf, David Barbarin, Fred Brouard côté moteur
Romain Casteres, Jean-Pierre Riehl, Florian Eiden, François Jehl côté BI
et une pensée pour Isabelle Van Campenhoudt, notre belge francophone préférée.
Un grand merci à eux de m'accueillir dans la troupe et d'avoir pu aider ma nomination en faisant des conférences avec moi (une petite dédicace à Thomas également pour notre session aux JSS 2013) ou en disant du bien de moi par exemple (c'est pas beau de mentir). Florian, je te la dois pour une bonne partie je crois ;)
Ce programme récompense un investissement dans la communauté. donc si cet investissement est possible, c'est que la communauté SQL Server existe et est active (j'en profite pour glisser un merci à mes petits copains du GUSS). Et cette communauté, c'est vous, donc :
Un grand Merci à vous
Maintenant il s'agit de ne pas se reposer sur ses lauriers, parce que l'air de rien ça ne dure qu'un an, et de continuer l'investissement. Et j'avoue que j'ai vraiment hâte d'inaugurer cette récompense lors d'une conférence (et il y en a une "exotique" et sympa qui se profile, plus de news bientôt) ou de participer au MVP Summit.
mercredi 5 février 2014
Board du GUSS, Afterwork et TechDays 14
Election du Board du GUSS
Piqûre de rappel (ou pas), si vous êtes membre du GUSS, vous avez constaté que le board de l'association se renouvelle. Les candidats sont connus, et comme l'année dernière, je souhaite en faire partie. C'est donc à vous qu'appartient la décision de me faire continuer ou pas.
Comme je l'ai expliqué dans mon message de "campagne" (sur le ton de l'humour), j'attache énormément d'importance à la communauté, et j'espère continuer sur cette lancée. On a la chance de bénéficier de professionnels impliqués et actifs sur SQL Server, et le GUSS a comme rôle de permettre à tous ces acteurs de se rencontrer, d'échanger, en un mot de se connaître.
Les différents candidats :
http://guss.pro/candidats-au-board-du-guss-2014/
Les votes se dérouleront du 10 au 24 Février, il y aura bientôt plus d'informations sur le déroulement du scrutin. Restez attentifs aux publicationx sur le site du GUSS. On compte sur vous.
Afterwork du GUSS Février 2014
Parce que même si l'élection du board est en cours, le GUSS continue d'assurer ses événements. Il y a donc un afterwork ce soir à partir de 19h au Frog (Bercy Village), métro Saint-Emilion.
Le sujet était tout trouvé vu l'actualité, il s'agit de discuter des orientations du GUSS pour l'année à venir. C'est aussi l'occasion de rencontrer une majorité de candidats au board et de discuter avec eux.
TechDays 2014
Comme chaque année, à la même période, la plus grande conférence Microsoft en France revient. Elle aura lieu la semaine prochaine les 11, 12 et 13 Février au Palais des Congrès (Porte Maillot).
Des sessions BI, des sessions Agilité, des sessions Big Data, bref pas mal de contenu à aller picorer pour tout consultant BI qui se respecte.
Une petite liste de sessions qui semble intéressantes :
Pour se mettre à jour sur l'offre Big Data chez Microsoft
Pour appréhender le Cloud
Plutôt moteur SQL
Bien sûr BI plus classique
Sans oublier un peu de méthodo agile
Bref, pas mal de choix (la liste ne se veut pas exhaustive en plus) et l'occasion de croiser du monde de l'écosystème Microsoft.
Piqûre de rappel (ou pas), si vous êtes membre du GUSS, vous avez constaté que le board de l'association se renouvelle. Les candidats sont connus, et comme l'année dernière, je souhaite en faire partie. C'est donc à vous qu'appartient la décision de me faire continuer ou pas.
Comme je l'ai expliqué dans mon message de "campagne" (sur le ton de l'humour), j'attache énormément d'importance à la communauté, et j'espère continuer sur cette lancée. On a la chance de bénéficier de professionnels impliqués et actifs sur SQL Server, et le GUSS a comme rôle de permettre à tous ces acteurs de se rencontrer, d'échanger, en un mot de se connaître.
Les différents candidats :
http://guss.pro/candidats-au-board-du-guss-2014/
Les votes se dérouleront du 10 au 24 Février, il y aura bientôt plus d'informations sur le déroulement du scrutin. Restez attentifs aux publicationx sur le site du GUSS. On compte sur vous.
Afterwork du GUSS Février 2014
Parce que même si l'élection du board est en cours, le GUSS continue d'assurer ses événements. Il y a donc un afterwork ce soir à partir de 19h au Frog (Bercy Village), métro Saint-Emilion.
Le sujet était tout trouvé vu l'actualité, il s'agit de discuter des orientations du GUSS pour l'année à venir. C'est aussi l'occasion de rencontrer une majorité de candidats au board et de discuter avec eux.
TechDays 2014
Comme chaque année, à la même période, la plus grande conférence Microsoft en France revient. Elle aura lieu la semaine prochaine les 11, 12 et 13 Février au Palais des Congrès (Porte Maillot).
Des sessions BI, des sessions Agilité, des sessions Big Data, bref pas mal de contenu à aller picorer pour tout consultant BI qui se respecte.
Une petite liste de sessions qui semble intéressantes :
Pour se mettre à jour sur l'offre Big Data chez Microsoft
- Avec Hadoop, Excel et… 1€, réalisez votre premier Mobile BigData Tracker en moins de 45 min !
- La démystification du Big Data
Pour appréhender le Cloud
Plutôt moteur SQL
- SQL Server : Tuning et Troubleshooting
- SQL 2014 et la gestion de la sécurité
- Haute Disponibilité et Disaster Recovery
Bien sûr BI plus classique
- Power Query Demos Extravaganza
- Le reporting BI dans tous ses états / quel outil pour quel usage
- Deep Dive Performance , le In-Memory dans SQL Server
Sans oublier un peu de méthodo agile
Bref, pas mal de choix (la liste ne se veut pas exhaustive en plus) et l'occasion de croiser du monde de l'écosystème Microsoft.
Inscription à :
Articles (Atom)