Renaud Harduin
BI et Proactive Caching : Le temps réel tiendra t'il ses promesses ?
S'il est un sujet récurrent en matière d'analyse, il s'agit bien de la notion de temps réel. Microsoft nous a présenté sa copie avec le proactive Caching, mais qu'en est-il ?
Par Renaud Harduin publié le 23/09/2007 à 18:33, lu 2015 fois, 4 pages
commentaire(s) 0 commentaire(s) tag(s)Tags: SQL Server 2005, Architecture, Business intelligence
 2 | Protocole de Test
Protocole de Test
Sans revenir sur tout le détail du tutoriel, je vous ai proposé de construire une base simplifiée du cube (BI_ART) exemple de Microsoft. Ce cube a la particularité d'avoir 2 partitions :
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image003.jpg
 
La première s'appuie sur la table de fait habituelle et la seconde s'appuie sur une table de fait FACTS.
Si l'on s'intéresse aux « settings », on peut jouer sur les options de stockage :
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image005.jpg
 
On peut y faire varier les options de stockage de la partition d'un accès systématique aux données détaillées « temps réel » (ROLAP) à un stockage rafraichit « tous les .. » en passant par des scénarii intermédiaires.
La question est : Est ce que les différents paramétrages se traduisent comme prévus ?

Afin de faire les tests de performance, nous utilisons un package SSIS qui injecte 10000 lignes d'un ODS vers la table Fact. Une petite application winform va lancer ce package SSIS toutes les 100 millisecondes.
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image007.jpg
 
Parallèlement, une autre application va lancer une requête MDX dans le cube et relève la valeur de la requête :

select [Measures].[Order Quantity] on columns  from [BI_ART]

 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image009.jpg
 
A la fermeture chaque application génère un fichier XML contenant les éléments de log :

<?xml version="1.0" standalone="yes"?>

<NewDataSet>

  <PerfTrace>

    <Time>2007-09-04T21:53:30.953125+02:00</Time>

    <Fraction>953</Fraction>

    <value>60398</value>

  </PerfTrace>

<NewDataSet>

L'objectif va donc être de comparer la valeur théorique (envoyée par l'injecteur) et la valeur observée de la requête.
Scénario ROLAP
Premier cas, le ROLAP (Relational OLAP). Dans ce cas, la partition ne stocke aucun agrégat. A chaque appel, SSAS envoie donc la requête à la base relationnelle. L'intégralité des données de la table Fact est lue.
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image011.jpg
 
Ci-dessous la courbe des résultats :
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image013.jpg
 
En rouge, vous pouvez observer la valeur théorique et en bleu la valeur requêtée.
La courbe bleu suit très bien la valeur théorique. L'écart moyen est de 2700 en quantité. Comme nous insérons 10000 lignes toutes les 100 ms, le décalage peut être estimé à 27 ms.

Dans le détail, si on prend une valeur à 140398, la valeur théorique dans le jeu a été atteinte à 10:02:49.859. Les faits montrent que la première requête qui trouve une valeur similaire est à 10:02:50.671.
Le décalage est minime (d'autant plus que l'on parle de 10000 lignes).
Scénario HOLAP
Le deuxième test va mettre en oeuvre le paramétrage par défaut HOLAP. L'idée du HOLAP est de stocker quelques agrégats suivant un plan de stockage. SSAS est notifié et sur cette base, il remonte les données dans son cache.
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image015b.jpg
 
Le profil se présente sous la forme :
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image017.jpg
 
Encore une fois la requête suit assez bien la valeur théorique. On observe néanmoins quelques décrochages liés à l'agrégation du cache. Le décalage moyen est de 5077, donc environ 50 ms.
Low Latency HOLAP ou Lagged HOLAP
Dans le dernier cas standard, les partitions sont à décalage/latence paramétré(e).
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image019.jpg
 
En rentrant dans le détail des options
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image021.jpg
 
Par défaut, Le cube sera notifié 10 secondes après l'évènement et la consolidation du cache interviendra 10 minutes plus tard (Scénario proche temps réel).Le profil avec latence donne :
 
/content/a39b84d3-0fc8-49f4-9c3a-4f7501773c7f/image023.jpg
 
La courbe « requête » ne suit plus la valeur théorique. Elle se rattrape par contre 10 minutes plus tard ...Petit détail, je suis passé dans ce test de 10000 lignes injectées à 100 lignes.
Dans le détail, la première insertion de données intervient à 2007-08-18 00:36:59.312 et la consolidation et le rattrapage interviennent à 2007-08-18 00:47:01.734, soit 10 minutes après (comme prévu).
 
» Démarrer une discussion