Analyse décisionnelle en temps réel avec Analysis Services

Analyse décisionnelle en temps réel avec Analysis Services

Paru le 01 avril 2005

Par Paul Sanders

Ce document décrit les fonctionnalités de SQL Server 2005 Analysis Services qui permettent de surmonter nombre des problèmes liés à la collecte et à l’analyse des données d’analyse décisionnelle en temps réel.

Sur cette page

Introduction
Envoi de données à Analysis Services
Lecture de données cohérentes
Combinaison de sources de données hétérogènes
Définition de stratégies de mise en cache
Obtention de notifications par Analysis Services
Résumé
Annexe

Introduction

Le rôle des systèmes d’analyse décisionnelle est de permettre aux entreprises de prendre de meilleures décisions et plus rapidement. Par conséquent, avant toute étude des outils d’analyse décisionnelle en temps réel, il convient de déterminer ce que l’on entend par temps réel. Les informations concernées par le terme « informations en temps réel » dépendent largement de l’activité de l’entreprise et peuvent même varier au sein d’une même entreprise. Prenons l’exemple d’une chaîne de magasins au détail :

• Un analyste qui utiliserait des données historiques pour les prévisions des ventes de la période suivante n’aurait sans doute besoin que des informations du mois précédent.

• Un responsable marketing qui évaluerait la réussite d’une campagne et qui devrait décider de la durée de la campagne aurait besoin d’informations beaucoup plus récentes, probablement datant de moins d’une journée.

• Un responsable de magasin peut être amené à prendre fréquemment des décisions pendant la journée, par exemple pour décider à quel moment mettre en vente un article périssable. Il aura dans ce cas besoin d’informations datant de quelques heures au plus.

Il est fréquent qu’une combinaison d’informations à jour et historiques soit nécessaire. Par exemple, s’il peut être utile pour le responsable de magasin de connaître le nombre de ventes d’un article particulier depuis le début de la journée, il est plus utile s’il peut placer ces informations dans le contexte du nombre moyen de ventes de ce même article le même jour de la semaine l’année précédente.

Les rapports peuvent inclure des données de différents systèmes. Dans notre exemple, les données des ventes du jour du magasin sont issues des systèmes source mis à jour immédiatement à chaque vente, combinées avec les données historiques d’un data warehouse d’entreprise. Cependant, cela signifie qu’il n’existe plus « une seule version de la vérité ». Lorsque nous comparons des données provenant de deux sources, nous devons prendre soin d’appliquer les mêmes stratégies métier que celles appliquées lors du chargement du data warehouse. Cela comprend les consolidations appliquées, le traitement des remises, ainsi que l’approche des conversions monétaires. Cela signifie que les règles métier intégrées au processus de chargement du data warehouse doivent également être intégrées aux rapports ou applications qui combinent les données des deux systèmes. Il peut en résulter un système moins souple et plus sujet aux erreurs. Cela peut conduire à des décisions basées sur des informations incorrectes.

Idéalement, nous souhaitons une source unique produisant des données suffisamment proches du temps réel pour permettre à tout les décideurs de prendre les bonnes décisions dans les différents scénarios. Quelles sont les problèmes qui empêchent les systèmes d’analyse décisionnelle de fournir des données réellement en temps réel ?

Freins à l’obtention de données en temps réel

Il convient de noter que l’obtention de données d’analyse décisionnelle en temps réel pose de nombreux défis, dont un certain nombre n’ont pas de solution technologique. Il est important d’avoir ce point à l’esprit, car de nombreuses présentations de technologies d’échange d’informations d’entreprise semblent atténuer l’étendue du problème. Les freins à l’obtention de données réellement en temps réel sont les suivants :

• Il est nécessaire de fournir une vue historique. Il arrive fréquemment que les systèmes source d’origine ne fournissent pas de données historiques du tout ; par conséquent, il est nécessaire de conserver une copie distincte des données, avec un historique complet, dans un data warehouse.

• Il est nécessaire d'assurer la coordination avec les processus métier et entre les systèmes. Il peut être inutile d’effectuer une analyse particulière tant que certains processus métier ne sont pas terminés. Par exemple, dans notre exemple de chaîne de magasins au détail, les comparaisons entre magasins ne sont pas significatives tant que tous les magasins, dans tous les fuseaux horaires, n'ont pas fermé. De la même façon, les mécanismes par l’intermédiaire desquels certains systèmes anciens sont mis à jour peuvent imposer une limite inférieure au délai pouvant être obtenu.

• Il est fréquent d’avoir à soumettre les données à un processus de transformation afin d’en garantir la qualité. En fonction de la complexité de ces transformations et du volume des données, il peut tout simplement ne pas être rentable de réduire le temps de chargement en-deçà d'un certain niveau.

• Il est souvent nécessaire d’intégrer des données provenant de multiples sources de données, qui même en l’absence de transformations significatives, peuvent couramment être gérées par des processus de transformation, avec création d’une banque distincte.

• L’objectif d’offrir des performances utilisateur satisfaisantes est souvent incompatible avec l’obtention de résultats en temps réel. La création de rapports directement à partir du système source fournit certainement des informations en temps réel, mais en général, les requêtes courantes au niveau agrégation n'offrent pas de bonnes performances sur les systèmes conçus pour des mises à jour fréquentes. Il n’est pas non plus possible de tolérer une charge de requête aussi importante sur nos systèmes transactionnels. Par conséquent, une banque distincte doit souvent être préservée, avec une attention toute particulière pour la fourniture d’agrégats précalculés (probablement avec Analysis Services). La maintenance de ces agrégats lors de chaque mise à jour des données source prend du temps.

• La création continue de rapports sur des données à partir d’un système soumis à des mises à jour constantes nécessite de tenir compte du problème de la cohérence des données.

• Même si les données d’un rapport sont suffisamment récentes, comment être certain que le rapport est remis immédiatement aux décideurs appropriés au moment où ils en ont besoin ?

Ces considérations signifient que l’utilisateur est souvent loin des données source d’origine, comme le montre la figure 1. Chaque lien de la chaîne introduit un délai supplémentaire.

Figure 1 : freins à l’obtention de données d’analyse décisionnelle en temps réel

Les systèmes transactionnels source de chaque magasin sont mis à jour immédiatement à partir des registres de chaque point de vente. Chaque jour, les données de tous les magasins sont consolidées et des transformations étendues sont appliquées afin de nettoyer les données avant leur chargement dans un data warehouse. Une fois chargé, un processus est engagé afin de retraiter les cubes Analysis Services utilisés pour tout accès utilisateur. Une fois le cube traité sur un serveur intermédiaire, il est validé, puis transféré vers le serveur de production, où il est disponible pour la création de rapports utilisateur. Peu de temps après l’actualisation du cube, le responsable concerné exécute un rapport sur le cube, constate les informations modifiées et une action est (enfin !) engagée.

Suppression des freins

Bien que certains freins soient difficiles à supprimer par la technologie, un certain nombre de fonctionnalités de SQL Server Analysis Services et d’autres composants du produit SQL Server facilitent la fourniture d’informations aux utilisateurs finaux.

• Envoi de données à Analysis Services. La tâche de mise à jour d’Analysis Services avec les modifications est facilitée par l’ajout de transformations SSIS (SQL Server Integration Services) pouvant envoyer les données directement à Analysis Services. Cela signifie que la tâche qui extrait et nettoie les données peut directement actualiser le cube.

• Combinaison de sources de données hétérogènes. Un cube Analysis Services peut provenir de données extraites de différentes sources hétérogènes. Les données sont combinées par Analysis Services et présentées de manière uniforme à l’utilisateur.

• Lecture de données cohérentes. Le moteur relationnel de SQL Server 2005 inclut un niveau supplémentaire d’isolation des transactions, permettant au lecteur d’obtenir un cliché des données. Cette possibilité est exploitée par Analysis Services. Cela signifie qu’un cube peut être traité, de sorte que même si le processus prend de nombreuses minutes, une vue cohérente des données est présentée via le cube.

• Mise à jour incrémentielle du cube Analysis Services. Comme dans Analysis Services 2000, il est possible de réduire le temps nécessaire pour actualiser le cube Analysis Services via l’utilisation de partitions, auquel cas l’impact des mises à jour peut être limité de sorte que seule une petite partie du cube soit réellement affectée. En outre, il est possible de traiter un cube de manière incrémentielle de sorte que les nouvelles lignes de faits puissent être ajoutées au cache existant. Analysis Services 2005 utilise cette possibilité en autorisant également la mise à jour incrémentielle des dimensions, ce qui permet de traiter le cas où de nouveaux enregistrements de dimension sont uniquement ajoutés et jamais mis à jour.

• Définition de stratégies de mise en cache. Analysis Services 2005 introduit la possibilité de définir la façon dont le cube doit être actualisé pour refléter les modifications apportées aux données source. Ces stratégies de mise en cache proactive permettent d’équilibrer la demande de données récentes et la nécessité de performances élevées.

• Obtention de notification par Analysis Services Via l’intégration à Notification Services, il est possible de s’abonner aux changements de données intéressants. Par exemple, un responsable peut manifester son intérêt pour un indicateur KPI (Key Performance Indicator) particulier et être informé par courrier électronique lorsque l’état du KPI change. Ces technologies peuvent être utilisées de manière isolée ou en tandem. Dans de nombreux cas, elles facilitent la fourniture d’informations d’analyse décisionnelle en temps réel. Un exemple d’architecture simplifiée, applicable dans certains cas simples, est illustré ci-dessous, avec le cube Analysis Services intégré directement sur les bases de données source.

Ces technologies peuvent être utilisées de manière isolée ou en tandem. Dans de nombreux cas, elles facilitent la fourniture d’informations d’analyse décisionnelle en temps réel. Un exemple d’architecture simplifiée, applicable dans certains cas simples, est illustré ci-dessous, avec le cube Analysis Services intégré directement sur les bases de données source.

Figure 2 : Une architecture simplifiée

Remarque : même dans des cas aussi simples, il est souvent recommandé de créer le cube sur une base de données qui est une copie de la base de données OLTP source réelle. Le coût de la maintenance d’une telle réplique est largement compensé par l'avantage de libérer le système de transaction de la surcharge correspondante.

Les systèmes transactionnels source de chaque magasin sont mis à jour immédiatement à partir des registres de chaque point de vente. Toutes les vingt minutes, les stratégies de mise en cache proactive garantissent que le cube est actualisé de manière incrémentielle afin de refléter les nouvelles données. Si un utilisateur s’est abonné à un KPI dont l’état a changé, un message électronique contenant une URL vers le rapport approprié lui est envoyé directement.

La suite du document détaille ces fonctionnalités, en particulier celles qui sont nouvelles dans Analysis Services 2005.

Envoi de données à Analysis Services

Dans SQL Server 2005, SSIS introduit les tâches pipeline, qui permettent la lecture des données, leur transformation via une succession de transformations, puis leur envoi vers une destination. Analysis Services est inclus comme l’une des destinations possibles, ce qui permet l'envoi direct des données transformées vers un cube. Cela concerne le chargement des partitions et des dimensions, en incluant la possibilité de charger les données de manière incrémentielle. Les dimensions peuvent être chargées de manière incrémentielle, ce qui constitue une nouveauté dans Analysis Services 2005. Cela s’avère particulièrement utile lorsque les lignes de dimensions sont uniquement ajoutées et non mises à jour, comme c’est le cas des dimensions de type II.

Lecture de données cohérentes

SQL Server 2005 introduit un nouveau niveau d’isolation des transactions, appelé isolation de cliché. Un client qui démarre une telle transaction est assuré que toutes les données lues pendant la transaction sont telles qu’elles étaient au début de la transaction, même si des mises à jour sont validées simultanément par d’autres utilisateurs.

Le traitement d’un cube sur des données en cours de modification peut être problématique s’il n’est pas isolé des modifications apportées par les autres utilisateurs. Par exemple, la dimension Produit peut être traitée, puis avant la fin du traitement des partitions, un nouveau produit peut être saisi, avec une vente de ce produit. La vente peut ensuite être sélectionnée dans le traitement des partitions, ce qui conduit à une erreur d’intégrité référentielle apparente.

Analysis Services 2005 peut, selon les besoins du développeur, exploiter l'isolation des clichés. Si cette stratégie est définie pour une source de données, Analysis Services démarre une transaction de cliché au début du traitement et tous les objets sont traités à partir de ce même cliché. Il convient de noter que l’obtention d’un cliché n’implique pas de surcharge fixe importante. En revanche, il existe une légère surcharge pour toutes les mises à jour effectuées pendant la transaction.

Combinaison de sources de données hétérogènes

Un cube dans Analysis Services peut trouver sa source dans plusieurs sources de données. Par exemple, si les données Produit et Ventes peuvent provenir du data warehouse principal de l’entreprise, les données Quotas peuvent être extraites d’une petite base de données de département. Analysis Services exécute les requêtes nécessaires pour joindre les données à travers les différentes sources.

L’une des sources de données doit être SQL Server, dans la mesure où Analysis Services exploite le processeur de requête distribué de SQL Server. La base de données SQL Server ne doit pas nécessairement contenir des données ; des données de deux bases de données Oracle peuvent par exemple être jointes via le processeur de requête d’une troisième base de données SQL Server.

Définition de stratégies de mise en cache

Analysis Services offre des performances élevées pour les requêtes en gérant un cache des données sous-jacentes dans une forme optimisée pour les requêtes analytiques, souvent avec des agrégations précalculées. La présence d’un tel cache soulève un certain nombre de questions importantes :

• Que faut-il faire lorsque les données sous-jacentes changent et que le cache devient obsolète ?

• Selon quelle fréquence le cache doit-il être actualisé ? Comment répondre aux requêtes pendant l’actualisation du cache ? À partir du cache obsolète, ou plutôt en revenant à la source sous-jacente, avec à la clé des données à jour mais des performances moins bonnes ?

• Comment savoir qu’une modification a eu lieu sur les données source ? Selon quelle fréquence effectuer la vérification ?

La nouvelle fonctionnalité de mise en cache proactive d’Analysis Services 2005 offre un moyen permettant au concepteur de cube de définir des stratégies qui équilibrent les performances et la nécessité des données en temps réel. Le système fonctionne sur « pilote automatique », sans la nécessité d'un traitement explicite.

Les paramètres de stratégie disponibles permettent un éventail de comportements du système. L’exemple suivant illustre un cube dans lequel la stratégie spécifie que l’actualisation du cache MOLAP (Multidimensional OLAP) du cube commence immédiatement après une mise à jour des données source. En outre, en raison de la nécessité de données à jour, si l’actualisation du cache n’est pas effectuée rapidement, le système revient au mode ROLAP (Relational OLAP) et envoie les requêtes directement à la base de données sous-jacente, jusqu'à la fin de l'actualisation du cache.

Différentes stratégies permettent des comportements assez différents. Par exemple :

• MOLAP automatique. Le comportement est le même que dans la figure 3, à ceci près que le système ne revient jamais au mode ROLAP, car la nécessité de performances élevées est supérieure à la nécessité de données en temps réel.

• MOLAP planifié. Le cube est simplement actualisé périodiquement, quelles que soient les mises à jour des données source.

• MOLAP incrémentiel. Le cube est actualisé de manière incrémentielle avec les nouvelles données de la base de données source.

• ROLAP en temps réel. Le cube est toujours en mode ROLAP et toutes les mises à jour des données source sont immédiatement reflétées dans les résultats des requêtes.

Les paramètres de mise en cache proactive peuvent être définis sur chaque objet Analysis Services différent (dimension et partition). Cela permet une grande flexibilité lorsque les stratégies et les compromis entre performances et latence varient pour différentes parties du cube.

Les paramètres de mise en cache proactive sont décrits plus en détail dans l’annexe.

Schémas de notification

Il existe trois schémas de notification permettant à Analysis Services d’être informé des mises à jour de la source sous-jacente :

• Événements de trace. Cela s’applique uniquement lorsque la source de données sous-jacente est SQL Server. Analysis Services s’inscrit pour la réception d’événements de trace sur les tables requises. Ce schéma nécessite que le compte de service Analysis Services dispose de privilèges administrateur sur la base de données SQL Server. La distribution des événements n’est pas garantie si la base de données est indisponible (par exemple en raison de problèmes réseau) lors de la mise à jour.

• Initié par le client. Un client peut simplement envoyer un message de notification à Analysis Services, indiquant qu’une table spécifiée a été mise à jour. Cela est pertinent lorsque l’application qui effectue réellement la mise à jour est consciente de l’impact sur les cubes Analysis Services.

• Interrogation. L’approche la plus souvent applicable consiste à utiliser l’interrogation. Les requêtes d’interrogation sont définies pour chaque table et renvoient une valeur unique (c'est-à-dire une ligne unique, avec une colonne), dont la modification indique une mise à jour de la table. Par exemple, une requête qui renvoie la valeur maximale de la colonne d’horodatage LastUpdated est une requête d’interrogation appropriée. Outre la requête, le concepteur spécifie également la fréquence selon laquelle Analysis Services doit envoyer la requête d’interrogation.

Traitement incrémentiel

En général, lorsqu'un cache est actualisé, il traite intégralement l’objet Analysis Services affecté afin de recharger complètement le cache. Pour être plus précis, les partitions utilisent l’option de traitement Complet, tandis que les dimensions utilisent l'option de traitement Mise à jour. Ces options garantissent que les données de partition liées sont préservées. Il est cependant également possible d’effectuer un traitement incrémentiel des partitions et dimensions lorsque l’on sait que les lignes sont uniquement ajoutées et non mises à jour.

Cette possibilité est disponible uniquement avec le schéma de notification d’interrogation. Avec une requête d’interrogation qui indique qu’une mise à jour a eu lieu, le concepteur fournit également une requête de traitement incrémentiel, laquelle renvoie les nouvelles lignes. Cette requête est paramétrée, en prenant la valeur précédente et la nouvelle valeur telles qu’elles sont renvoyées par la requête d’interrogation. Un exemple est fourni dans l’annexe.

Obtention de notifications par Analysis Services

Notification Services est un ajout récent de SQL Server. Ce service offre une infrastructure évolutive avec laquelle les clients peuvent manifester leur intérêt pour un événement (c'est-à-dire la valeur d’une requête qui change) et définir la façon dont ils souhaitent être informés si l’événement se produit (par exemple par courrier électronique ou via Instant Messenger). Notification Services fournit des services standard pour cela, par exemple la garantie de distribution de la notification et la garantie que la notification n’est envoyée qu’une seule fois lors d’une transition. Par exemple, lorsqu’un KPI passe de OK à Bad, l’utilisateur est informé une fois et pas de manière répétée, même si le KPI reste à l’état Bad.

Dans SQL Server 2005, Notification Services inclut un adaptateur spécial pour Analysis Services. Celui-ci permet à un client de s'abonner à un événement en spécifiant une requête MDX qui définit les données intéressantes, ainsi que la fréquence de l’interrogation, le schéma de notification, etc. Par exemple, le responsable d’un magasin peut demander une notification si les ventes par heure d’un produit particulier tombent en-deçà d’un niveau spécifié.

Cela facilite la création d’applications d’analyse décisionnelle qui garantissent que les utilisateurs peuvent être informés rapidement lorsque des événements spécifiés se produisent.

Résumé

Analysis Services 2005, avec d'autres produits SQL Server 2005, offre un certain nombre de fonctionnalités permettant de rendre disponibles les données d’analyse décisionnelle en temps réel. Voici quelques-unes de ces fonctionnalités :

• La maintenance d’un ensemble d’agrégats est facilitée par la possibilité de définir des stratégies de mise en cache, puis de laisser le système fonctionner en « pilote automatique » sans qu’il soit nécessaire de retraiter explicitement les agrégats.

• L’efficacité est améliorée par la possibilité de charger directement Analysis Services à partir d’une transformation et d’ajouter de manière incrémentielle de nouveaux enregistrements.

• La possibilité d’obtenir une vue cohérente, même lorsque des données changent, est offerte par l’isolation des clichés.

• L’intégration de données à partir de plusieurs sources hétérogènes peut être facilitée par la possibilité des cubes Analysis Services à combiner des données de plusieurs sources.

• La possibilité d'informer les utilisateurs d'événements importants est offerte par Notification Services. S’il existe de nombreux freins à l’obtention de données d’analyse décisionnelle réellement en temps réel, ces fonctionnalités peuvent être utilisées de manière indépendante ou en combinaison afin de rendre les informations suffisamment proches du temps réel pour permettre de meilleures décisions, plus rapides.

Annexe

Cette annexe fournit des détails supplémentaires sur les paramètres de mise en cache proactive, ainsi que l’utilisation de requêtes d’interrogation et de requêtes de traitement incrémentiel pour actualiser de manière incrémentielle un cube via la mise en cache proactive.

Paramètres de mise en cache proactive

Traitement incrémentiel avec mise en cache proactive

Le tableau suivant illustre un exemple de requête d’interrogation et la requête de traitement incrémentiel associée qui seraient utilisées pour détecter la présence de nouvelles lignes de ventes dans la table de faites et ajouter ces lignes de manière incrémentielle à une partition.