CEP vs ETL, StreamInsight et SSIS dans la BI


Je suis de retour du MVP Summit (avec un très bel event au Safeco Field de Seattle que vous voyez ici) et à nouveau chez mon client préféré! Hormis vous dire que ce que nous avons appris augure de bien belles choses sur SQL Server Denali en général, et sur ses modules BI en particulier, ne comptez pas trop sur moi pour aller plus loin dans les détails car j’ai signé un NDA avec mon sang…

Par contre plus sérieusement j’ai été pas mal intéressé là bas par les scénarios de convergence des différents produits sortis ou à venir. Il est vrai qu’après une grosse phase de simplification marketing autour de briques bien identifiées (SQL Server 2005), l‘offre BI à l’horizon Denali devient de plus en plus complexe à lire pour nos chers clients et utilisateurs. Par conséquent la recherche à minima de convergences entre les différents modules est un sujet intéressant.
Intéressant techniquement pour adresser plus de problématiques, intéressant pédagogiquement car c’est de notre faculté à rendre cette offre lisible que dépendra en grande partie l’adoption des ces produits.
Le positionnement du CEP StreamInsight par rapport à l’ETL SSIS est un bon exemple de cela.
ETL et CEP dans la BI

Un ETL (Extract Transform Load) comme SSIS est le produit traditionnellement utilisé pour charger les entrepôts de données ou data warehouses. Orienté batch (ensemble de traitements bien identifiés) et planifié à une certaine fréquence, il est utilisé pour aller chercher les données dans les bases opérationnelles, et les amener dans les bases d’analyse, non sans leur avoir appliqué un nombre généralement considérable de vérifications, aggrégations, filtrages et autres consolidations.
Depuis quelques années et l’avènement du « mythe » (entre guillemets car il devient petit à petit réalité) des entrepôts de données (near)real-time ou zero-latency illustré côté Microsoft par des features telles que le Proactive Caching dans SSAS (pour ne citer que lui), on parle d’une supplantation des ETL par des CEP, des moteurs de Gestion d’Evenements Complexes (Complex Event Processing).
Un CEP est un moteur d’analyse de flux (souvent) constants de données, à la recherche de singularités, ou simplement à des fins d’aggrégation.
StreamInsight, sorti avec SQL Server 2008 R2 est le CEP de SQL Server, il s’agit d’un moteur utilisable en .NET dont les règles de traitement et d’agrégation et l’expression de KPI s’écrivent par des requêtes Linq sur les flux entrants, donnant des possibilités quasi infinies en terme de transformations, le tout en temps réel. Le pas est vite franchi pour certains oracles du décisionnel: ils prédisent que les ETL et les bases temporaires feront bientôt partie du passé.

Remplacer SSIS par StreamInsight dans l’alimentation d’entrepôts?

Soyons brefs: à date et sauf pour des ultra particuliers, il n’en est évidemment pas question, en tous les cas aujourd’hui, et ce pour plusieurs raisons:
1) Pas de composants spécialisés ETL: StreamInsight pour le développeur est un framework: les composants de DataFlow que l’on est amenés à utiliser en ETL avec SSIS seraient à recoder, ainsi que les interfaces d’entrée, de sortie…
2) Trop orienté développeur: utiliser StreamInsight à la place de SSIS aujourd’hui est aussi aisé que d’utiliser SSIS uniquement par le biais de son API de génération de packages… Disons pas aussi simple qu’avec un designer graphique.
3) Administration limitée: là encore les fonctionnalités out-of-the-box de StreamInsight sont restreintes car répétons-le ce n’est pas son usage premier: un CEP doit traiter des données en masse et peut se permettre des erreurs: un entrepôt contient la version corporate de la « vérité »: il n’y a pas de droit à l’erreur la supervision doit être facile et les erreurs aisément traçables.
Au bilan je ne crois pas que sauf pour des tables de faits spécifiques, ou des entrepôts dédiés à la latence zéro on n’assiste avant quelque temps à la gestion de l’ETL sous SI. En revanche Microsoft est tout à fait conscient de l’intérêt suscité par certaines potentialités de StreamInsight pour les développeurs ETL…
Avant la fusion, des scénarios de convergence…

StreamInsight permet en effet de requêter des flux en Linq: quelle puissance cela donnerait de pouvoir faire les mêmes requêtes sur des PipelineBuffer, ce qui revient en effet à embarquer un moteur StreamInsight dans SSIS.
A l’inverse, pour adresser l’absence de composants dans StreamInsight ou pourrait nourrir des lots SSIS à partir de données issues de CepStream, scénario inverse ici puisque cela revient à embarquer un lot SSIS dans un flux StreamInsight.
Ping Wang et Wee Hyong Tok des équipes StreamInsight et SSIS ont écrit un WhitePaper inspiré comme souvent de retours clients sur ce type d’usages de ces deux produits couplés: vous pouvez le trouver ici.
En espérant avoir clarifié quelques points et vous avoir donné quelques idées.
A bientôt!

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s