Le Post Infeeny

Les articles des consultants et experts Infeeny

Archives Mensuelles: décembre 2014

Éviter les « cold queries » sur son site IIS

Avez-vous déjà remarqué qu’après une longue période d’inactivité votre site internet mettait du temps à répondre ? C’est ce qu’on appelle une « cold query« , c’est à dire une requête qui se verra ajouter un temps d’initialisation de l’application en plus de son temps de traitement habituel.

Avant d’entrer plus en détails sur les différents solutions pour pallier à ce problème, revoyons nos basiques !

AppDomain

Un domaine d’application fournit une couche d’isolement dans un processus. Tout ce que vous pensez habituellement comme «par programme» (variables statiques, etc.) est en fait par AppDomain.
Par exemple Entity Framework utilise l’AppDomain pour mettre en cache :
  • Les métadonnées : contient les infos pour faire le lien entre les value types C# et les types de base de donnée
  • Les vues générées : la transformation nécessaire entre les objets C# et les tables de la base de données
  • Les traductions des requêtes LINQ en SQL

Plus d’infos à ce sujet http://msdn.microsoft.com/en-us/data/hh949853.aspx#2

 Application pool

Un pool d’applications est un mécanisme utilisé par IIS pour isoler les applications Web, cela permet d’avoir différentes configurations (sécurité, utilisation des ressources, etc.) et empêche les applications instables d’interférer avec d’autres applications.

Généralement, chaque pool d’applications correspond à un processus de travail. Un processus de travail est un processus windows (w3wp.exe) qui exécute des applications Web et est responsable du traitement des demandes envoyées à un serveur Web pour un pool d’applications spécifique.

Le pool d’applications peut contenir plusieurs AppDomain, d’où le compteur « Applications » visible dans la liste des pools d’application dans IIS.

Cycle de vie de l’application pool

Un recyclage signifie que le processus de travail qui gère les requêtes pour ce pool d’applications est terminé, et qu’un nouveau a pris le relais. Ceci afin d’éviter des états instables qui peuvent mener à des plantages, blocages ou des fuites mémoire. Les recyclages peuvent notamment se produire si on modifie le web.config ou le dossier bin du site web, et sont affectés par certains paramètres.

Les paramètres avancés du pool d’applications possède une section « Recyclage » où sont répertoriés les différents paramètres influant sur le cycle de vie dont voici la liste :

  • Intervalle de temps régulier (par défaut 29h)
  • Nombre limite de demandes (par défaut pas de limite)
  • Heures spécifiques (par défaut vide)
  • Limite de mémoire virtuelle  (par défaut pas de limite)
  • Limite de mémoire privée (par défaut pas de limite)

Un autre paramètre à ne pas négliger se trouve dans la section « Modèle de processus » :

  • Délai d’inactivité (20 minutes par défaut)

 

Résolution du problème

 

La méthode simple

Afin de régler le problème de « cold query » sur votre site IIS, vous pouvez simplement modifier tous les paramètres ci-dessus pour faire en sorte que le pool d’applications ne se recycle qu’en cas de modification du site web.

Sur une configuration par défaut il suffit de mettre 0 pour « Intervalle de temps régulier » et pour « Délai d’inactivité« . Cependant cette méthode est fortement déconseillée. Le pool d’application DOIT être recyclé à intervalles régulier, sinon la moindre et infime fuite mémoire dans n’importe quelle librairie (ASP.Net inclus) va être source de plantages aléatoires, inexpliqués, et inexplicables.

 

La méthode Preload

Une requête est envoyée une fois que le pool d’applications a été recyclé, cela permet de conserver sa logique au niveau du global.asax, mais si l’initialisation est longue cela peut figer le site. De plus la requête n’est pas déclenchée lorsque l’application est redéployée.

1) Installation du module « Application Initialization »

– Sur un Windows classique : Programmes et fonctionnalités -> Activer ou désactiver des fonctionnalités Windows -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

– Sur un Windows Server : Server Manager -> Ajouter des rôles ou fonctionnalités -> Rôle serveur -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

2) Configuration du pool d’applications

– Sur la liste des pools d’applications -> sélectionner le pool d’application

  • Paramètres de base -> cocher « Démarrer automatiquement le pool d’applications »
  • Paramètres avancés -> section Général : mettre « Mode de démarrage » à « Always Running« 

3) Configuration du site Web

Dans la page d’accueil du serveur ouvrir l’éditeur de configuration:

1 EditeurConfigurationServeur

Sélectionner la section « sites» sous « applicationHost » via le menu déroulant « section » :

2 choisirApplicationHost

Ouvrir la collection :

3 OuvrirCollectionApplication

Sélectionner votre site web :

  • Mettre serverAutoStart à true

4 OuvrirCollectionAppPool

Dans les paramètres de la nouvelle fenêtre mettre :

  • preloadEnabled à true

5.1 OptionAppPool

Fermer les fenêtres. De retour sur l’éditeur de configuration, vous pouvez faire « Générer le script » afin de rendre la tâche répétable 😉 Sinon, faites appliquer.

6 AppliquerChangement

Dans le web.config de l’application, ajouter :

<system.webServer>
     <applicationInitialization doAppInitAfterRestart="true"/>
</system.webServer>

A noter qu’il y a deux attributs optionnels :

  • remapManagedRequestsTo : Permet de spécrediriger les requêtes vers une page statique pendant l’initialisation du site web.
  • skipManagedModules : Spécifie si les modules managés de IIS sont chargés durant l’initialisation.

Checklist :

  • Pool d’Application
    • Démarrage automatique
    • Mode de démarrage à AlwaysRunning
  • Site web
    • serverAutoStart à true
    • Application du site web
      • preloadEnabled à true
  • Web.config :
    • Avoir ajouté la clé applicationInitalization
  • Global asax ou dans Startup.cs
    • Mettre votre logique d’initialisation : par exemple si vous utilisez Entity Framework, faire une query qui charge un objet complexe afin de mettre en cache un maximum de choses au niveau de l’AppDomain.

 

La méthode serviceAutoStart

La méthode Preload d’une classe implémentant « System.Web.Hosting.IProcessHostPreloadClient » est appelée (ne déclenche ni l’Application_Start du Global.asax ni la classe « Startup » de Owin). C’est la méthode recommandée pour garder son application up tout le temps mais la plus contraignante.

1) Créer votre classe implémentant « System.Web.Hosting.IProcessHostPreloadClient »

Exemple :

public class MvcMusicStoreApplicationPreloadClient : IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        var service = new TopSellingAlbumsService();
        HttpRuntime.Cache["TopSellingAlbums"] = service.GetTopFiveSellingAlbums();
    }
}

2) Installation du module « Application Initialization »

– Sur un Windows classique : Programmes et fonctionnalités -> Activer ou désactiver des fonctionnalités Windows -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

– Sur un Windows Server : Server Manager ->Ajouter des rôles ou fonctionnalités -> Rôle serveur -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

3) Configuration du pool d’applications

– Sur la liste des pools d’applications -> sélectionner le pool d’application

  • Paramètres de base -> cocher « Démarrer automatiquement le pool d’applications »
  • Paramètres avancés -> section Général : mettre « Mode de démarrage » à « Always Running« 

4) Ouvrir l’éditeur de configuration

Dans la page d’accueil du serveur ouvrir l’éditeur de configuration:

1 EditeurConfigurationServeur

5) Ajouter le service à IIS

Sélectionner la section « serviceAutoStartProviders» sous « applicationHost » via le menu déroulant « section » :

2 choisirSercice

Ouvrir la collection :

3 OuvrirCollection servicesAutoStart

Ajouter votre service :

4 Ajouter serviceProvider

Pour le champ type, mettre le nom complet du type implémentant IProcessHostPreloadClient par exemple : « MvcMusicStore.MvcMusicStoreApplicationPreloadClient, MvcMusicStore » (MvcMusicStore est la DLL). Fermer la fenêtre.

6) Configurer le site web

Sélectionner la section « sites» sous « applicationHost » via le menu déroulant « section » :

2 choisirApplicationHost

Ouvrir la collection :

3 OuvrirCollectionApplication

Sélectionner votre site web :

  • Mettre serverAutoStart à true

4 OuvrirCollectionAppPool

Dans les paramètres de la nouvelle fenêtre mettre :

  • serviceAutoStartEnabled à true
  • serviceAutoStartProvider : mettre le nom de votre service

5.1 OptionAppPool

Fermer les fenêtres. De retour sur l’éditeur de configuration, vous pouvez faire « Générer le script » afin de rendre la tâche répétable 😉 Sinon, faites appliquer.

6 AppliquerChangement

Checklist

  • Pool d’Application
    • Démarrage automatique
    • Mode de démarrage à AlwaysRunning
  • Service Provider
    • Ajouter votre service en utilisant le nom complet pour le type
  • Site web
    • serverAutoStart à true
    • Application du site web
      • serviceAutoStartEnabled à true
      • serviceAutoStartProvider attribué au service précédemment ajouté
  • Web.config :
    • Avoir ajouté la clé applicationInitalization

 

 

Conclusion

Vous avez maintenant toutes les clés en main pour résoudre votre problème avec la solution la plus adaptée ! Même si cela peut sembler compliqué la 1ère fois, les méthodes « Preload » et « serviceAutoStart » sont finalement assez rapide à mettre en place une fois qu’on a pris le coup de main.

Enfin, notez que même si rien n’empêche d’utiliser les deux dernières solutions simultanément, cela est déconseillé car ça peut entrainer des instabilités (notamment des initialisations s’effectuant plusieurs fois).

 

Ressource :

http://www.iis.net/configreference/system.webserver/applicationinitialization

http://www.iis.net/configreference/system.applicationhost/serviceautostartproviders

[JSS 2014] Session : Deep Dive : Hive

Speaker : David Joubert & Julien Buret
Level : 400

Objectif : Découvrir la technologie Hive et démontrer la convergence Datawarehouse et Big Data

Introduction :
Intégré par défaut sur la plateforme Hadoop, Hive est un lien manquant entre SQL et Big Data dans l’éco-système.
Langage, stockage, exécution, cet entrepôt de données Big Data s’est toujours inspiré de ses équivalents relationnels dans son évolution.
Nous allons présenter Hadoop dans un premier temps puis Hive et son historique, type de stockage et quelques comparaisons de performance.
Le Big Data n’est pas au programme de cette session, ainsi que l’analyse en temps réel.

Hadoop :
Hadoop est un Framework permettant de développer des applications distribuées et scalables. Ce n’est pas une base. Hadoop utilise un système de fichiers distribués (HDFS) et le moteur de calcul MapReduce.
Sa mauvaise performance sur les données en temps réel est un inconvénient. Beaucoup d’évolutions dépendent de cette problématique.

Hive :
Historiquement, Hive était un projet interne à Facebook lancé en 2007. Il a été rendu open source en 2009. Aujourd’hui, il est possible de requêter en SQL sur Hadoop (HiveQL).
Hive n’est pas un moteur de base de données. C’est une application cliente de Hadoop qui permet de générer des jobs MapReduce à partir d’un langage plus performant.
Hive se compose de 2 principaux modules :

  • Hive METASTORE : base relationnelle pour indiquer comment est structurée une table dans Hadoop (HDFS)
  • Hive DRIVER : interprête les requêtes SQL fournies par le client et les transforme en job MapReduce (M/R)

DeepHive_HiveFonctionnementGlobal

Exemple de plan d’exécution :

DeepHive_MR

Démo Hive : Création d’une table, dite externe (ne copie pas les données sur disque)
Petite comparaison SQL VS Hive

Une démo rapide pour montrer la création d’une table externe :
CREATE EXTERNAL TABLE tableName (

);

Quel usage de Hive ?
On stocke le maximum de données dans Hadoop. Hive permet de traiter les use-cases complexes qu’on ne peut pas gérer dans les datawarehouses. L’inconvénient, c’est qu’il est très difficile d’avoir des requêtes interactives dues à ses latences.
Plusieurs projets ont été développés afin de gérer ces requêtes interactives (Presto, Apache, HawQ, …).

DeepHive_QuelUsage
« schema on read » = il n’y a pas de validation à l’insertion. Elle se fait à la lecture

Nouveaux moteurs :
MapReduce, c’est fini pour Hadoop. De nouveaux moteurs d’exécution ont fait leur apparition : Tez, Spark, etc. Nous allons nous focaliser sur Tez.
Tez supporte le M/R et les jointures. Il permet de construire des plans d’exécutions plus complexes que M/R (pipelining, utilisation de la mémoire à la place du disque, multiple étapes de Reduce). L’idée est de ne garder que les M/R sans écrire dans HDFS.

Démo : Hive M/R VS Hive Tez
Petite comparaison de performance entre les deux moteurs.
Résultat : Tez est environ 2 fois plus rapide que M/R.

Hive sur les données brutes :
Hive peut analyser des formats de type Text. Par contre, le parsing est coûteux et il y a un problème de compression.
Le format orienté colonne (Oriented Row Columnar, ORC) permet de stocker les données en colonne. Cela améliore les performances en lecture, écriture et traitement, notamment grâce à la compression et l’encodage des données. Grâce à cela, le traitement massif des données est plus adapté pour Hive.

Démo : Stockage natif VS Stockage en colonne

  • Création de table de type ORC : ajouter « STORED AS ORC » à la fin de la requête CREATE TABLE
  • Gain de temps d’environ 4 fois plus en stockage colonne

Vectorization :
Hive traite les données ligne à ligne alors qu’avec la Vectorization, c’est bloc à bloc.
Le Query Engine a été modifié pour traiter des « vecteurs de colonne ». Nous avons une meilleure utilisation du CPU et des caches.
L’arbre d’exécution a été optimisé (Partition pruning, Projection pruning, filter push/down). Il n’y a pas d’optimisation liée à la donnée. L’ordre des tables dans les jointures est très important.

Cost-Based Optimizer (CBO) :
Le CBO utilise les statistiques de base de données pour générer plusieurs plans d’exécution et choisir le moins coûteux.

Démo : Performance avec et sans CBO

  • Ajouter « EXPLAIN » devant la requête pour afficher le plan d’exécution
  • On désactive CBO, active le moteur Tez, sans vectorization : 136s pour 164 lignes
  • On désactive CBO, active le moteur Tez, avec vectorization : 80s pour 164 lignes
  • On créé les stats, active CBO : 69s pour 164 lignes
    • le plan d’exécution est différents des 2 précédentes configurations
    • il y a moins de mapper

Pourquoi convergence ?

DeepHive_Convergence

Futur du SQL sur Hadoop :

  • SQL 20XX
    • Supporter les fonctionnalités analytics
    • WINDOWS, ROOLUP, CUBE
  • Transaction
  • Hive LLAP
  • Materialized views

Foudhil BABA ALI & David TANG

[JSS 2014] Data Mining Avec SSAS et Azure ML

Speaker : Patrice Harel

Titre : Data mining Avec SSAS et Azure ML

Objectif : Comparaison de Mise en place d’un process de Data Mining avec SSAS Vs Azure Machine Learning

 

Introduction :

Une introduction theorique sur le data mining

Les données utilisées pour la démo sont les données des accidents sur les routes (source : data.gouve.fr  2006-2011)

Les Données ne sont pas très volumineuses (700 000 lignes) mais avec plusieurs colonnes (attributs), l’objectif est de trouver des relations entre les attributs.

Exemple des attributs: Catégorie de route \ Luminosité \ Type d’agglomération \ Conditions atmosphériques

Data Mining :

Le premier travail du data-mineur est:

  • s’approprier le domaine métier
  • Donner du sens supplémentaire aux données ou l’information
  • Etablir une corrélation entre les attributs

Exemple : Luminosité vs condition atmosphériques: Si il y a beaucoup  de brouillard donc forcément peu de luminosité.

Ce premier travail a pour but de définir quels attributs vont contribuer dans le travail du data mining.

Les données peuvent être utilisées directement dans leur état brut. De préférence avoir des  données propres et organisées, sans pour autant les stocker dans une Base SSAS.

 

Un petit tableau de comparaison :

Data mining Machine Learning
Appliquer des algorithmes de recherche de modèles (patterns) sur d’importants volume de données Se réfère à la partie algorithme du data mining
Trouver des relations supplémentaires, faire de la prédiction, intelligible pour un humain « Désigne les ajustements dun système par lui-même dans le sens ou ce système pourra effectuer une même tâche une seconde fois mais de manière plus efficace »
Né des besoins sur les bases de données Né des besoins en intelligence artificielle

 

Les étapes de mise en place d’un modèle de datamining :

  • Se poser les bonnes questions, définir ses objectifs (si le résultat est non satisfaisant, il faut se poser la question est-ce que le résultat est mauvais ou est-ce qu’on s’est posé les mauvaises questions)
  • Définir deux types de variable :
    • les variables explicatives (condition atmosphérique)
    • Les variables à expliquer (le nombre de morts et de blessés)
  • Définir la population cible : a qui est destiné l’étude
  • Scinder la source de données en deux
    • Un échantillon de travail
    • Un échantillon de validation

Les études du Datamining mettent à notre disposition des données utiles qui complémentent celles de la BI,

 

Différence entre l’analyse descriptive et l’analyse prédictive :

Analyses descriptives : Quels sont les clients qui consomment le plus de parfums.

Analyses prédictives : Quel va être mon chiffre d’affaire l’année prochaine.
Dans notre cas d’étude « Essayer de prévoir selon les caractéristique de l’accident si oui ou non il va y avoir des morts et\ou des blessés »

 

Cycle de développement :

  • Choix du sujet, définition des objectifs
  • Inventaire des données disponibles
  • Extraire, transformer, corriger et rassembler les données (évacuer les données aberrantes, Choisir des variables ni trop corrélées ni très peu corrélées avec la variable qu’on veut expliquer)
  • Statistiques descriptives
  • Choix de l’algorithme
  • Souvent dans le datamining on crée des variables booléens, c’est plus facile à traiter
  • Validation du modèle, déploiement

 

La problématique :

Puis-je prédire, en fonction des caractéristiques d’un accident si il y aura ou non des morts/hospitalisés?

  • Création d’une nouvelle variable : EstGrave (Booléen)

 

Objets SSAS DM :

SSAS DM

Case : la table qui va contenir les caractéristiques de notre étude de cas

Nested : la table qui contient des caractéristiques complémentaires (pas indispensable)

Input : variables explicatives

Output : variables à expliquer

DEMO Datamining sous SSAS :

Les étapes de création dans SSDT :

  • Créer une solution SSAS
  • Définir une data source
  • Créer data source view
  • Créer la structure mining
  • Choisir le modèle de mining à utiliser (L’algorithme) : Arbre de décision
  • Choisir les cas & nested
  • Key : identifiant de chacune des instance de nos case
  • Input : var explicatives
  • Predict : var à expliquer
  • Définir le pourcentage de data pour l’étude, et le reste servira à la validation (30/70)
  • Observer le résultat : la courbe Lift permet de définir le niveau de prédiction du modèle (80%)

PS : Un modèle qui fait 60% est considéré comme pas mal, 75% est très bon, 90% est parfait.

 

Object Azur Machine Learning :

AML

 

DEOM AML :

Les étapes de création :

  • Créer une nouvelle expérimentation (l’interface ressemble à SSIS)
  • Importer le data set (pas de possibilité de travailler sur des externes)
  • Ajouter le composant Project column (selectionner les attributs que l’on va utiliser)
  • Ajouter le composant Split (30%, 70%)
  • Choisir le model (Algo): 2 class (boosted decision tree)
  • Choisir la variable à expliquer
  • Evaluate
  • Run
  • Résultat : 76% (algo est légèrement diffèrent par rapport à celui implémenté dans SSAS)

 

Conclusion :

Conclusion

[JSS 2014] Sécurité Via policies

Description :

Basée sur mon expérience dans les banques suisses, je vous propose une manière simple de contrôler la sécurité via les policies. Quels types de contrôle doit-on mettre en place au niveau de l’instance, au niveau de la base de données? Comment les gérer sur plusieurs serveurs? Avoir de beaux petits rapports ou emails en retour… Essayons de répondre ensemble à toutes ces petites questions que nous avons aux niveaux des audits de sécurité…

Level : 200

Date & heure : 2 décembre 2014 – 10h30

Speaker(s) : Stéphane Haby

 

Dans cette session Stéphane Haby nous a expliqué comment le DBA peut-il devenir le Gardien des données.

Dans un 1 er temps nous avons fait un tour des Bests practices de sécurisation générale puis dans un second nous avons vu comment mettre en place des policies sur SQL Server :

1.     Bests practices de sécurisation :

Afin de s’assurer de la sécurité des données existantes dans notre environnement Stéphane Haby nous propose de l’auditer afin de lister l’ensemble des points à surveiller.

Des résultats obtenus de son expérience, il va nous proposer de contrôler les niveaux suivants :

  1. Server
  2. Instance
  3. Database
  4. Data

1.Server :

Dans cette partie, nous avons fait le tour des bonnes pratiques à mettre place coté sécurité sur le serveur hébergeant la ou les instances de bases :

 

  • Permission sur les disques des serveurs (enlever le Read / Read & execute / List Folder) pour tous les utilisateurs)

Sec_Pol_1

 

  • Formater les partitions en NTFS ( Le format NTFS a pour avantage de disposer d’une encryptions et de l’ALS)
  • Installation que des outils nécessaires sur les instances ( faire attention aux outils ajouté automatiquement : par exemple DQS s’installe automatique lors de l’installation d’une infrastructure en cluster )
  • Installer les derniers Services Packs et Security Fix
  • Supprimer les scripts d’installation => un mdp administrateur peut trainer par la …
  • Désactiver NetBios et SMB

2. Coté instance :  

Dans cette partie Stéphane Haby nous expose les modifications à effectuer coté instance SQL Server permettant d’améliorer la sécurité : 

  • Changer les ports (il est facile d’attaquer le 1433)
  • Enlever le browser (on masque les instances … Seul les utilisateurs connaissant les bonnes chaines de connexions peuvent les trouver …)
  • Depuis la version 2012, il est possible de cacher les instances
  • Il est utile de créer un compte de service pour chaque instance
  • Utiliser des password Complexes
  • Préférer l’Authentication Windows
  • Eviter le Grant Control server to [public]
  • Revoke Extended and OLE Automation stored procedures for the public Role
  • Supprimer les BUILTIN\Administrator
  • Sa => mdp complexes
  • Supprimer les login obsolète
  • Désactiver le cmd shell
  • Désactiver cross db ownership chaining
  • Désactiver le sql Server web assistant
  • Désactiver CLR intégration
  • Désactiver le Ad hoc remote queries
  • Activer l’audit de sécurité
  • Activer les traces par défaut

3.Database :

 Dans cette partie nous avons fait une revue des bonnes pratiques coté base de données : 

  • Minimiser les rôles DBO
  • Supprimer les comptes orphelins (comptes d’utilisateurs n’ayant plus de bases rattachés ou plus utilisés)
  • Supprimer les schémas dbo 

4.Data 

   Enfin coté données nous avons vu que la meilleur sécurité était le cryptage de celles-ci

2.     Mise en place de policy  :

Les policies SQL Server correspondent à une stratégie de sécurité mis en place pour automatiser les contrôles de conformités du Serveur. 

Objectif :

  • Mettre en place des règles et vérifier les écarts sur les différentes instances ( par exemple : différences de droits sur les bases entre l’instance de DEV et de PROD , auditer les modifications intempestive de donnée effectué par des développeurs malin qui incluent des Grant dans les scripts , verifier l’arrivée de nouveaux utilisateurs … )
  • Automatiser le contrôle des instances par l’intermédiaire de reporting ou de mail  (Automatiser cet « Audit » en envoyant des mails réguliers aux DBA’s et aux équipes de sécurité)

Pour avoir une meilleure compréhension sur le concept de gestion axée sur les policies il ya quelques termes à comprendre :

  • Target– Permet à l’administrateur de gérer ses règles sur un type d’entité : Par exemple, une table, une base de données ou un index
  • Facet – Permet de gérer la gestion des règles. Un exemple de Facet est le nom d’un trigger ou la propriété de Réduction automatique de la base de données (Auto Shrink).
  • Conditions – Critères qui spécifie l’état de la « Facet » à vrai ou faux. Par exemple, vous pouvez vérifier et régler l’état d’une Facet qui vous donne des informations de toutes les procédures stockées dans le schéma «dbo».
  • Policy – Un ensemble de règles définies pour les objets de serveur ou les propriétés de base de données.

Sec_Pol_2

 

Sec_Pol_3

 

Après avoir compris ces différents concepts Stéphane Haby nous a présenté comment créer une policy et comment les déployer pour les exécutés : 

  • A la demande
  • De manière automatique
  • Lors de detection de changement

Dans sa démo Stéphane Haby nous détail chaque étape en nous présentant les tenant et les aboutissant et les différents rendus présentés aux DBA qui peuvent s’avérer utile sur le terrain:

  1. Créer une condition
  2. Créer la policy
  3. Evaluer la policy
  4. Le déployer sur plusieurs serveurs
  5. L’automatiser (par l’intermédiaire de rapport ou de mail)

Julien PIERRE

Consultant Décisionnel

[JSS 2014] Ma première analyse avec Machine Learning

Level : 200 Date & heure : 2 décembre 2014 – 10h30 Speaker: Florian Eiden

Titre : Ma première analyse avec Machine Learning

Objectif : Concevoir un système automatisé et intelligible qui apprendra de ses expériences

Introduction :

Rappel sur la BI dite classique, ses limites avantages et inconvénients.
Schéma du positionnement de la technologie Machine Learning par rapport à la BI traditionnelle. (Hacking skills, mathematiques, BI Analyst)

A qui est-elle destinée ?

Aux utilisateurs métiers de l’entreprise qui souhaitent avoir des éléments de réponse à une question posée.
Exemple : Quelle est le meilleur prix de vente pour mon appartement sur le marché parisien?

Quelles sont les interlocuteurs qui vont la mettre en œuvre ?

IT, Matheux, statisticiens, data scientist

Dans quel but ?

BI classique analyse l’existant et permet d’apporter des éléments de réponses basés sur des indicateurs de performance.

Machine Learning s’attaque à la prédiction des événements futurs au travers d’un algorithme mathématique qui une fois entrainé (Train model) obtient d’un échantillon (training set) une tendance sur l’avenir.

Use case :

Estimer le prix du marché d’un appartement Parisien par rapport à sa surface, son arrondissement, et le prix du m2 afin de pouvoir le vendre au meilleur prix.

Fait appel aux cours de mathématiques (fonction affine, régression linéaire, valeur discrète, continue).

L’idée étant de déterminer le prix en fonction du nombre de m2 et de la superficie, le prix d’un appartement à Paris par l’expérience (experiment). Cela se traduit par une courbe constituée par un ensemble continue de valeurs discrètes où Y étant le prix de l’appartement à vendre qui est égal à X le nombre de m2 par rapport à un coefficient à déterminer qui s’appuie sur la tendance du marché. D’où la formule y=h(x).

Les données piochées proviennent du site PaP dont les données ont été aspirées avec l’outil Kimono (firme américaine) qui permet d’obtenir des données structurées dans une table (dataset) à partir d’un navigateur web.

Démo :

Plateforme azure (dans le cloud) avec un navigateur web et un compte azure sont les seuls éléments dont vous devrez vous acquitter pour commencer à développer :

On retrouve des composants classées et rangées par catégorie tels que la source, les splits qui ne sont pas sans rappeler les éléments de la toolbox SSIS auxquels vont se greffer de nouveaux concepts/modèles (train model, score model, algorithmes, evaluate model, script, langage R).
Ces différents éléments précités s’imbriquent les uns dans les autres pour constituer un workflow relié par des flux au travers desquels les données vont transitées. Chaque élément peut être visualisé pendant son traitement et permet d’expliciter les données en apportant des éléments sur la précision, la pertinence des données traitées sur une courbe. Le speaker insiste sur l’importance d’intégrer le maximum de données concrètes pour améliorer et entrainer le modèle.

Conclusion :

Une Technologie d’avenir qui vient enrichir l’écosystème CLOUD de Microsoft et nécessite une forte propension à comprendre les concepts mathématiques.

La prise en main est rapide et ne nécessite aucune installation logicielle.
Concevoir des modèles  et bénéficier de la puissance mathématique des algorithmes (initialement développés pour XBOX et BING) en utilisant le  « Drag and Drop » des composants présents dans ML Studio.

Ces projets verront le jour en réunissant les compétences  d’un mathématicien  couplées à  celles d’un data scientist qui aura la charge d’apporter des données nettoyées en source afin de construire le workflow pertinent.

Pour aller plus loin,
Apprentissage des codes et pratiques du Data Scientist au travers d’une Formation Machine Learning  dispensée par la société coursera cursus de 10 semaines, nécessite des notions en mathématiques et statistiques. Vidéos de présentations sur le site studio.azure.ml.

 

[JSS 2014] Session : L’agilité n’est pas une fatalité

Speaker(s) : Michel Perfetti – Nicholas Suter
Level : 200

Cette session nous présente la méthode Agile comme une révolution qui touche non seulement les différentes entités mais aussi son impact dans le futur.
L’Agilité touche aujourd’hui presque tous les domaines de développement, même la BI n’y échappe pas.
La session a commencé d’abord par plusieurs interrogations légitimes, à savoir :
Si l’Agilité est une révolution pour certains.
Cela implique-t-il qu’il faut outrepasser les Designers et passer directement au code ?
Nous avons vu aussi que l’agilité touche 3 royaumes
Utilisateur : Définit son besoin et attend le résultat
Développeurs : Leur travail est souvent vu de l’extérieur comme une boîte noire.
Opérationnels : Ils attendent surtout des livrables.

En tant que professionnel de la Data il faudra trouver sa place entre ces 3 royaumes.
Les Speakers nous montrent que la vraie révolution sera autour du DevOps.
Car il faudra en finir avec la guerre entre les Devs et les Ops et qu’il faudra un mur de confusion.
D’une part l’équipe de dév qui la plupart des cas est amené à maximiser les changements et d’autres part les équipes Système et Infra qui cherchent le plus souvent à minimiser le changement.

Cette révolution se ressentira à plusieurs niveaux :
– Les individus et leurs interactions
– Les logiciels opérationnels
– La collaboration avec le client
– L’adaptation au changement
– La réduction des Cycles de Livraison
– L’optimisation des ressources
– L’amélioration de la qualité

Et l’agilité dans le futur ?
• Dans un futur assez lointain (10 ans) Nicholas Suter nous promet:
o Des cycles de développement ultra cours
o Des infrastructures différentes
o Des livrables plus petits et plus simples

• Dans les 3 ans l’Agilité aura touché ces domaines:
o Cloud
o Big Data
o Machine Learning

Conclusion :
S’il y avait qu’un seul mot à retenir ce serait « raz de marée ».
Michel Perfetti – Nicholas Suter nous ont montré que l’agilité bouleverse toute l’organisation et en gros c’est quelque chose qu’on subit tous.
Les speakers on finit néanmoins par quelques tips à savoir :
– Déployer en ligne de commande si possible, ce qui permet de confier le déploiement à un Ope par exemple
– Ne pas hésiter à regarder ce qu’il y a sous le capot(le code)
Et je ne peux que confirmer cela pour avoir déjà travaillé en mode Agile sur un projet pendant presque un an.

Cheikh SECK – Consultant décisionnel MCNEXT

[JSS 2014] Session : BI et déploiement automatique avec TFS

Speaker : Romuald COUTAUD & Khirdine HADDAR
Level : 200

Objectif : Déploiement des solutions BI (SQL, SSIS, SSAS, SSRS) automatiquement avec TFS

Introduction :
Dans tous les projets BI, il y a différentes façons de gérer l’industrialisation de nos projets (SQL, SSIS, SSAS, SSRS). Cette session va permettre d’illustrer TFS (Team Foundation Server), l’un des moyens d’industrialisation de ces projets en automatisant la génération et le déploiement des livrables dans les différents environnements (Dev, Intégration, Prod).
Ce qui va être présenté ici, ce sont juste le versioning des solutions ainsi que la génération et le déploiement automatique des différents projets (TFS Build).

TFS :

  • Gestion des versions des projets
  • Packager les livrables
  • Build TFS
    • Extraction et copie automatique sur le serveur
    • Génération des projets (se fait à l’aide de MSBuild, un framework dotNet)
    • Déploiement

Le déploiement se fait à l’aide de WWF (Windows Workflow Foundation). Il est possible d’utiliser des scripts PowerShell pour compléter ces tâches.
Beaucoup de DLL (codeplex) ont été développées par la communauté et seront utilisées.

Outils :
SSIS : MSBuildSSIS2012 (génération & déploiement)
SSAS : SSASHelper (génération)
SSRS : SSRSMSBuildTasks

Démo : Déploiement SQL Server

  • définition du Build avec les différents arguments (deploy, environment, …)
    • fait appel à TFSBuild.exe

>> Toute la base a été déployée sur l’instance DB indiquée, avec les schémas associés.

Démo : Déploiement SSIS

  • le fichier .proj a été modifié pour prendre en compte des options non natifs
  • possibilité d’ajouter un fichier .xaml (WWF) pour avoir des options en plus aussi (BuildSSIS, …)
  • lancement du Build
    • compilation du projet SSIS + déploiement
    • le build peut se lancer aussi en ligne de commande. En changeant les paramètres, on peut facilement déployer les mêmes sources mais sur des instances différentes

Démo : Déploiement SSAS

  • mêmes procédés que précédemment à l’exception qu’un fichier de config.xml peut permettre de customiser ses différentes sources
  • comme indiqué dans la partie Outils, le codeplex pour SSAS ne permet pas de déployer les solutions SSAS. Pour la démo, un script PowerShell a été développé, permettant les déploiements

Démo : Déploiement SSRS

  • pas de surprise par rapport aux précédentes démos. La DLL, récupérée sur codeplex, met à disposition plusieurs méthodes permettant de checker l’existance d’un rapport, l’ajout/suppression d’un rapport, la modification de la source, etc.
  • les étapes de génération et déploiement restent les mêmes que précédemment

Pré-requis :

  • avoir un server TFS configuré
  • adapter tous les codeplex récupérés

Conclusion :
On entend beaucoup parler de TFS (surtout chez les dotNetiens) mais durant mes différentes missions, je n’ai pas eu l’occasion de voir cette méthode mise en place.
Très bonne session, on a pu voir qu’une fois que toutes les configurations, pour chaque type de solution, ont été mises en place, on peut facilement déployer nos solutions sur chacun de nos environnements et du coup, faciliter la tâche à nos chers collègues du support (et nous même).
Reste à voir ce que TFS peut donner avec les tests unitaires par exemple…