La suite Microsoft SQL Server permet à nos clients de profiter d’une base de données relationnelle et multidimensionnelle robuste pouvant être utilisée dans un environnement temps réel. Microsoft StreamInsight est la solution de CEP (Complex Event Processing) de Microsoft qui permet de capturer tout type d’évènement à des fréquences très élevées (plusieurs milliers d’évènements par seconde).

Le simple fait de capturer des milliers, millions d’enregistrements en base ouvre les portes d’une analyse en environnement multidimensionnel très riche et de plus en temps réel ! Microsoft StreamInsight repose sur le framework .net et permet, en plus de capturer, de corréler des évènements entre eux issus de différentes sources. 

Problématique

  • Capturer un grand nombre d’évènements et les corréler entre eux
  • Ouvrir cet ensemble de données à la Business intelligence en permettant une analyse et un reporting en temps réel
  • Consommer l’information sur le poste de travail, en mobilité sur des Dashboard HTML5 Custom

Bénéfices

  • Une plateforme temps réel robuste
  • Une complétude entre les outils de captures temps réels et les outils d’analyses BI
  • Une adaptabilité du reporting selon les besoins clients

 

Capture des évènements avec Microsoft StreamInsight

La logique d’intégration des données repose sur un flux se propageant d’un adaptateur source à un adaptateur de destination. Le flux de donnée est constitué d’évènements dont le type peut être tagué suivant des évènements suivis.

Un évènement est constitué de deux parties :

-          Header

-          Payload

L’entête indique le type d’évènement, il peut être de deux types INSERT ou CTI (Current Time Increment). Le payload est une structure .net contenant les données associées à l’évènement.

 Le modèle d’évènement (payload) est décliné en trois types :

-          Interval Model

-          Point Model

-          Edge Model

 Un modèle de type POINT qualifie un évènement se produisant une fois dans le temps.

 

 

Ce type d’évènement a une durée de vie d’un « Tick » (.net 100 nanosecondes représentées comme un ε).

La requête suivante route le flux d’un adaptateur d’entrée vers l’adaptateur de sortie.

                // Simple pass through query.  Grab the input values, pass to the output adapter

                var query = from e in input select e;

L’illustration ci-après présente cette évolution. Si l’évènement de type POINT a besoin d’être étudié et corrélé avec d’autres évènements, il faudra surcharger sa durée.

 

Dans l’exemple ci-après, nous  étudions cet évènement sur une fenêtre de trois secondes.

                // Aggregating query.  Average the meter values by meter over a 3 second window,

                // along with the min, max and number of event for that meter

                var query = from e in input

                               group e by e.MeterId into meterGroups

                               from win in meterGroups.HoppingWindow(

                                   TimeSpan.FromSeconds(3),

                                   TimeSpan.FromSeconds(2),

                                   HoppingWindowOutputPolicy.ClipToWindowEnd)

                               select new

                               {

                                   meterId = meterGroups.Key,

                                   avg = win.Avg(e => e.Value),

                                   max = win.Max(e => e.Value),

                                   min = win.Min(e => e.Value),

                                   count = win.Count()

                               };

La capture d’un évènement de type POINT est la suivante avec un END TIME correspondant au START TIME + 1 Tick.

Event Kind

Start Time

End Time

Payload

INSERT

2009‐07‐15

2009‐07‐15 09:13:33.317

100

Il est alors possible, architecturalement, de représenter l’application StreamInsight de la façon suivante.

Dans notre exemple, l’application est connectée à plusieurs flux en entrée permettant la capture et la corrélation d’évènements.

Figure 1 - Architecture StreamInsight 

Le contrat d’interface entre les sources et les bases de données cibles est alors connu ou déduit directement du flux lui-même. En effet, StreamInsight permet la capture de flux n’ayant pas de type prédéfini. Côté StreamInsight, il faut choisir le type de l’adaptateur source (ou Input Adapter).

Dans notre exemple, nous faisons le choix du mode type POINT et le payload de l’event est connu, le type de base retenu pour l’input adapter sera la classe « TypedPointInputAdapter ».

Dans cette approche, un évènement sera levé toutes les N ms (N étant configurable) sur l’adapter source Patrol et dirigé vers le flux de sortie avec ou sans données. Coté sortie, il faut choisir le type de l’adaptateur sink (ou Output Adapter). Comme le mode de traitement retenu est de type POINT, le type de base retenu pour l’output adapter sera la classe « PointOutputAdapter ». Ensuite, les données seront stockées dans une table ayant comme schéma l’ensemble des champs disponibles (fixes + dynamiques).

Considérons comme exemple le fait que le besoin de l’interface PATROL soit un monitoring toutes les 10 ms.

La collecte des informations répond à la logique suivante :

 

Figure 2 – Input Stream

 Chaque évènement est modélisé par une structure appelée « Payload » définissant l’évènement :

/// <summary>

/// Payload class for measure events

/// </summary>

public class MesurePayload

{

    public DateTime Timestamp { get; set; }

    public string Fields { get; set; }

    public string Values { get; set; }

}

 

Intégration SQL Server et Analysis Services

Dès lors que la collecte est activée, il est nécessaire de stocker ces évènements ou agrégats d’évènements en base SQL Server. A la vue du nombre important d’enregistrements en base, celle-ci devra être constituée de tables de faits partitionnées. Ces partitions SQL Server seront alors alignées avec des partitions de type ROLAP sur le cube multidimensionnel. La best practice étant d’avoir une table physique pour une partition Analysis Services ou d’ajuster le slice des partitions ROLAP sur la clé de partitionnement SQL.

Il est important de respecter les recommandations suivantes lorsque l’on utilise des partitions de type ROLAP :

-          Supprimer toutes les colonnes non nécessaires de la table de faits

-          Réduire la taille d’un enregistrement en minimisant les types des colonnes

-          Faire en sorte qu’il existe un mapping d’une partition sur une table et non une vue dans la DSV

 Ce dernier point est nécessaire pour bénéficier des « tranparent aggregation » disponibles dans la base SQL Server.

 

Figure 3 - Architecture Analysis Services

 A contrario d’un stockage MOLAP, un stockage ROLAP va s’appuyer sur le moteur SQL Server, les I/O produits seront majoritairement séquentiels. Le système de stockage doit être optimisé pour délivrer ce type d’I/O dans les meilleures conditions. Il est important de bénéficier d’une fréquence CPU élevée afin d’absorber les nombreuses requêtes SQL concurrentes. 

 

Temps réel et Reporting HTML5

La restitution d’un cube Analysis Services se fait généralement dans Excel, Reporting Services ou autres produits de restitution Microsoft, mais il est parfois nécessaire de disposer d’un reporting plus personnalisé comme par exemple des Dashboard de suivi de compteur avec des représentations propres à chaque client.

Il est alors possible de définir une architecture de représentation basée sur HTML5 ainsi consommable sur tout type de device.

L’architecture repose sur un web service entre les Dashboard et le cube Analysis Services.

Le code applicatif contenant la partie Web Service REST WCF ainsi que les Dashboard HTML 5 correspond à une solution Visual Studio 2012

 

Figure 4 – Architecture de présentation

 La solution repose alors sur les éléments suivant :

-          Fichier.css     : Feuille de style CSS contenant les styles utilisés dans la page du dashboard HTML5

-          Fichier.html   : Page HTML5 représentant le Dashboard

-          Fichier.js        : Contient le code Javascript faisant les appels à intervalle régulier au web service REST qui ramène les données du cube

-          SSASDataService.svc    : Markup du service web REST de l’interface StreamInsight faisant le lien avec le cube Analysis Services

 

La solution globale permet alors :

-          Une capture des évènements en temps réel

-          Un stockage en base SQL Server en temps réel

-          Le calcul d’indicateurs directement dans Analysis Services en temps réel

-          L’affichage sur des Dashboard HTML5 multi-device en temps réel

Nous mettons ce type de solutions pour des clients issus de secteurs variés tels que l’énergie ou l’industrie, qui ont un besoin de monitoring, de supervision global de la sécurité de leur SI, ou d’absorber en temps réel des données issues de capteurs et sondes déployés dans des environnements divers.

 

Pour plus d’informations sur les offres packagées Microsoft Consulting Services, rendez-vous sur http://www.microsoft.com/france/services

Plus d’informations sur les blogs « SQL Server chez les clients ». 

 

Frédéric Gisbert, Architecte BI/SQL/Big Data Microsoft Consulting Services

J’interviens en clientèle sur des problématique BI, Big Data et plus globalement de gestion de données (MDM, CEP, SharePoint) en tant que lead technique et architecte. Le but premier d’un architecte solution est d’intégrer la suite SQL Server dans des environnements hétérogènes en considérant toutes les spécificités de chacun de nos clients. J’interviens aussi dans des problématiques Big Data sur nos solutions Hortonworks (Hadoop).

Certification : Analysis Services MAESTRO