OLAP Équipe: Johanne Lavoie Giovanni Malizia Présenté le 26 avril 2004 Prof. : Robert Godin Cours : INF7115 Session : Hiver 2004

Plan de présentation Survol Problématiques Approches OLAP Amélioration de la performance Processus de sélection des vues à matérialiser Hiérarchies des attributs Contexte étudié Cadre du treillis Algorithmes glouton Modèle de coût Produits commerciaux Conclusion Références Durant cette présentation: Nous ferons un rapide survol d’OLAP Nous identifierons : Les défis rencontrés pour répondre aux critères des utilisateurs énumérés plus tôt Deux différentes approches OLAP Ce qui peut être fait pour améliorer la performance Quel est le processus de sélection des vues à matérialiser Quel est la hiérarchie des attributs Nous verrons quel est le contexte que nous avons étudié, ce qui signifie: Le cadre du treillis L’algorithme glouton Et le modèle de coût Nous verrons rapidement quels sont les 7 produits OLAP les plus populaire sur le marché Et nous terminerons cette présentation.

Survol Introduit en 1993 par E.F. Codd Utilisation pour l’aide à la décision Utilisateurs OLAP autonomes Différents types : MOLAP, ROLAP, HOLAP, DOLAP Étroitement lié aux entrepôts de données Performance inacceptable sur un environnement opérationnel

Défis Croissance constante des données Complexité des requêtes Temps de réponse Coûts Le dilemme Quelles vues doit-on matérialiser pour optimiser le temps de réponse, minimiser l’espace disque occupé et diminuer les coûts ? Croissance constante des données: Afin d’analyser, par exemple la tendance du marché, il est nécessaire d’avoir des données historiques qui peuvent provenir de bases de données d’opérations et d’autres sources externes. Comparativement à un système OLTP qui ne contient que les transactions récentes. Il s’agit ici du plus grand défi d’OLAP: le volume de données qui est nécessaire de manipuler. Complexité des requêtes Il est important que les analystes puissent analyser des données à travers n’importe quelle dimension, à n’importe quel niveau d’agrégation, avec la fonctionnalité et la facilité égales. Le modèle multidimensionnel de données soutient des requêtes complexes de décision sur des quantités énormes de données temporelles d’entreprise. Temps de réponse Les requêtes OLAP sont complexes et peuvent prendre beaucoup d’heures à s’exécuter si c’est fait directement sur les données brute. Les utilisateurs doivent obtenir un résultat dans les secondes qui suivent. Il est donc important de tout mettre en place pour accélérer le temps d’exécution des requêtes. Coûts Les coûts relatifs à ces problématiques ne sont pas seulement monétaire. On parle ici, entre autre, de temps réponse, de capacité disque (espace).

Approche MOLAP Les données sont nettoyées, agrégées dans des dimensions multiples Les données sont emmagasinées dans des rangées multidimensionnelles Pré compilation des rangées d'organisation et de données qui peuvent être consultées directement et plus rapidement Joints déjà fait Vue multidimensionnelle directe des données Facilité d'utilisation Crystal decisions, « Compound OLAP. An OLAP Architecture for the Real World », 2001, p.1-15

Approche ROLAP Données volatiles Données agrégées et emmagasinées avec les bases de données relationnelles Manipulation de requêtes complexes Interface multidimensionnelle aux données relationnelles Intégration possible à des BDs relationnelles existantes Jointures au moment de la requête Requête utilisant SQL Crystal decisions, « Compound OLAP. An OLAP Architecture for the Real World », 2001, p.1-15

Amélioration de la performance Optimisateurs de requêtes Techniques d’évaluation de requête Stratégies d’indexation Index « bit-map » Index de jointures Alternatives pour la matérialisation des vues (cubes) Toutes les vues Aucune vue Quelques vues (une partie du cube) Des optimisateurs de requêtes et les techniques d'évaluation de requête peuvent être rehaussées. Pour mieux manipuler les agrégations nous pouvons utiliser différentes stratégies d'indexation. Les deux problèmes fondamentaux sont la sélection des vues et la maintenance des vues (rafraîchir les vues). Plusieurs techniques existent. Les deux plus populaires sont: - De pré calculer les vues les plus souvent demandées (MOLAP) - Utiliser les stratégies d’indexage comme des index « bit-map » et des index de jointure, et ainsi de suite (ROLAP ou ad hoc) BITMAP: L’index bitmap est associé à chaque dimension du cube Elle est utilisé pour les colonnes à cardinalité faibles ou un nombre limité de valeurs (un exemple: Homme et Femme) Vue la taille réduite de l’index elle est gérée en mémoire et donc plus performant I de J: Une jointure entre le table de fait et les tables de dimensions Elle est exclusivement adaptée aux requêtes définis sur un schéma en étoile Son efficacité est établie en conservant une entrée pour chacune des lignes du résultat de la jointure Au niveau de la matérialisation des vues (cubes) il existe 3 méthodes: Toutes: Totalité du cube. Offre un temps de réponse court mais occupe de l’espace et demande une maintenance élevée Aucune: Accéder directement aux données de base. Espace minimale mais une pauvre performance. Quelques unes: Profiter des dépendances entre les cellules du cube pour calculer des valeurs de certaines cellules à partir d’autres cellules. C’est cette dernière approche que nous présentons Étant donné l’ampleur du sujet cette présentation cible la matérialisation d’une partie du cube.

Processus de sélection des vues à matérialiser Des optimisateurs de requêtes et les techniques d'évaluation de requête peuvent être rehaussées. Pour mieux manipuler les agrégations nous pouvons utiliser différentes stratégies d'indexation. Les deux problèmes fondamentaux sont la sélection des vues et la maintenance des vues (rafraîchir les vues). Plusieurs techniques existent. Les deux plus populaires sont: - De pré calculer les vues les plus souvent demandées (MOLAP) - Utiliser les stratégies d’indexage comme des index « bit-map » et des index de jointure, et ainsi de suite (ROLAP ou ad hoc) BITMAP: L’index bitmap est associé à chaque dimension du cube Elle est utilisé pour les colonnes à cardinalité faibles ou un nombre limité de valeurs (un exemple: Homme et Femme) Vue la taille réduite de l’index elle est gérée en mémoire et donc plus performant I de J: Une jointure entre le table de fait et les tables de dimensions Elle est exclusivement adaptée aux requêtes définis sur un schéma en étoile Son efficacité est établie en conservant une entrée pour chacune des lignes du résultat de la jointure Au niveau de la matérialisation des vues (cubes) il existe 3 méthodes: Toutes: Totalité du cube. Offre un temps de réponse court mais occupe de l’espace et demande une maintenance élevée Aucune: Accéder directement aux données de base. Espace minimale mais une pauvre performance. Quelques unes: Profiter des dépendances entre les cellules du cube pour calculer des valeurs de certaines cellules à partir d’autres cellules. C’est cette dernière approche que nous présentons Étant donné l’ampleur du sujet cette présentation cible la matérialisation d’une partie du cube. Bellatreche, Ladjel, Techniques d’optimisation des requêtes dans les data warehouses, Laboratoire d’Informatique Scientifique et Industrielle, 2003, http://www.lisi.ensma.fr/

Hiérarchies des attributs Deux types d’opérations couramment utilisées pendant les requêtes : Le pliage (roll up) et le dépliage (drill down) Jour Semaine Aucun Mois Année Période Semaines du mois (1-5) Jours du mois (1-31) X Les dimensions du cube de données contiennent plus d’un attribut et sont organisés hiérarchiquement Cette hiérarchie implique des dépendances au niveau des requêtes et complique la détermination de quelles vues matérialisées L’exemple suivant est représenté par la dimension temporelle période. Elle est composée de plusieurs attributs permettant de naviguer à différents niveaux de granularité. La partie de droite démontre d’une façon plus conviviale le niveau de complexité. Nous pouvons observer dans la relation entre les attributs que: la semaine dépend du jour; le mois dépend du jour et l’année dépend du mois La complexité ce situe au niveau des non dépendances. Par exemple: le mois ne peut être dérivé à partir de la semaine et également l’année ne peut être dérivé à partir de la semaine Remarquez que l’attribut AUCUN signifie qu’il n’existe pas d’attribut dans la clause de regroupement (group by) Veuillez notez les faits suivants de cet l’exemple: - Les mois ne peuvent être divisé uniformément en semaines - Les groupements par semaine ne sont pas liés aux groupements par année Yl : dépends de Aucun représente les possibilité Mois/Semaine et Semaine/Mois X Année Jan. Avr. Déc. Jours du mois (1-31) Harinarayan, Venky, Rajaraman, Anand, Ullman, Jeffrey, D., « Implementing Data Cubes Efficiently », Proceedings of the 1996 ACM SIGMOD international conference on Management of Data, p.205-216, ISSN:0163-5808

1 2 3 Contexte étudié Cadre de treillis Modèle de coût Vues possibles Taille / Temps Algorithme glouton Espace / Temps

Cadre de treillis Cadre de treillis Vues possibles

Treillis des 8 vues TPC-D Huit (8) vues possibles 1. Pièce, fournisseur, client (6M) 2. Pièce, client (6M) 3. Pièce, fournisseur (0,8M) 4. Fournisseur, client (6M) 5. Pièce (0,2M) 6. Fournisseur (0,01M) 7. Client (0,1M) 8. None (1) Total: 19.1M Total: 7.1M

Treillis composé de dimensions hiérarchiques Combinaison de deux dimensions hiérarchiques c = client n = par pays p = pièce s = taille t = type de pièce Client Pièce Taille Aucun Type + Pays Reprenons l’exemple de client / pièces du TPC-D (quelle requête) Voici deux dimensions hiérarchiques client et pièce. CLICK Chaque dimension contient des attributs. Veuillez remarquez l’attribut AUCUN. Cela signifie que ………………….. De plus dans ce contexte de l’exemple l’attribut AUCUN indique un niveau de granularité particulier. Également, pour client, le niveau ce termine à pays et pour pièce aucune relation n’existe entre la taille et le type de la pièce. Par la l’unification des hiérarchies client et pièces ont obtient le treillis composé suivant. Deux types de dépendances des requêtes: - Interaction entre les dimensions - Interaction à l’intérieure d’une dimension causée par des attributs hiérarchiques Cette représentation permet de simplifier la compréhension des vues à matérialiser pour ………………… Aucun Harinarayan, Venky, Rajaraman, Anand, Ullman, Jeffrey, D., « Implementing Data Cubes Efficiently », Proceedings of the 1996 ACM SIGMOD international conference on Management of Data, p.205-216, ISSN:0163-5808

Avantages du treillis composé Fournit un cadre pour évaluer les dimensions hiérarchiques Améliore la modélisation des requêtes communes entre les utilisateurs Indique dans quel ordre matérialiser les vues Réduction de l’accès aux données sources

1 2 3 Contexte étudié Cadre de treillis Modèle de coût Vues possibles Taille / Temps Algorithme glouton Espace / Temps

Algorithme glouton Algorithme glouton Espace / Temps Génére la sélection des vues à matérialiser à partir du treillis. Il est a noter que plusieurs autres algorithmes existent tel que ……..

Déroulement de l’algorithme glouton (greedy) La vue haut niveau est matérialisée Sélection des vues additionnelles à matérialiser, une à une, jusqu’à l’atteinte du coût total choisie À chaque étape, choisir la vue non matérialisée, avec les bénéfices les plus avantageux

Résultats de l’algorithme glouton Numéro Sélection Bénéfice Temps total Espace total 1 c p infinit 72M 6M 2 n s 24M 48M 3 n t 12M 36M 4 c 5,9M 30,1M 6,1M 5 p 5,8M 24,3M 6,3M 6 c s 1M 23,3M 11,3M 7 n p 22,3M 16,3M 8 c t 0,01M 9 t petit 10 n 11 s 12 aucune c = client n = par pays p = pièce s = taille t = type de pièce Temps Espace Nombre de vues

1 2 3 Contexte étudié Cadre de treillis Modèle de coût Vues possibles Taille / Temps Algorithme glouton Espace / Temps

1 2 3 Modèle de Coût Modèle de Coût Taille / Temps Il calcul le ratio entre l”espace et le temps pour estimer les coûts et bénéfices de la matérialisation d’un ensemble de vues

Rappel: Treillis des 8 vues TPC-D Huit (8) vues possibles 1. Pièce, fournisseur, client (6M) 2. Pièce, client (6M) 5. Pièce (0,2M) 6. Fournisseur (0,01M) 7. Client (0,1M) 8. None (1) 4. Fournisseur, client (6M) 3. Pièce, fournisseur (0,8M)

Modèle linéaire de coût T = m * S + c (T) temps d’exécution (S) taille d’une vue (c) coût fixe (m) ratio du temps de requête/taille de la vue Source Taille (S) Temps (sec.) Ratio Une cellule seulement 1 2,07 Non applicable 6. Vue – fournisseur 10 000 2,38 ,000031 3. Vue – pièce, fournisseur 800 000 20,77 ,000023 1. Vue – pièce, fournisseur, client 6 000 000 226,23 ,000037 Ce tableau représente la validation expérimentale du modèle qui est été base sur le TPC-D. La demande est les ventes totales pour un seul fournisseur sous quatre conditions possibles, utilisant des vues de différentes granularités. Il semble y avoir une relation linéaire entre la taille et le temps d’exécution d’une requête. Cette relation linéaire s’exprime par la formule T= m* S + c T est le temps de traitement de la requête sur une vue de taille S. C équivaut au coût fixe: l’exécution de cette requête sur une vue de taille négligeable. Ce coût fixe s’établi à 2.07 seconds. M est le ratio pour le temps de la requête selon la taille de la vue après avoir appliqué le coût fixe. Comme on peut voir, le ratio est presque le même pour les différentes vues. Temps de réponse de la requête par rapport à la taille de la vue 2,38 – 2,07 = (0,31)/10000 = ,000031 Harinarayan, Venky, Rajaraman, Anand, Ullman, Jeffrey, D., « Implementing Data Cubes Efficiently », Proceedings of the 1996 ACM SIGMOD international conference on Management of Data, p.205-216, ISSN:0163-5808

Produits commerciaux

Multidimensional server engine Client multidimensional engine Catégorisation ROLAP MOLAP DOLAP Multi-pass SQL Cartesis Magnitude MicroStrategy Multidimensional server engine Crystal Holos (ROLAP mode) SAS CFO Vision Hyperion Essbase Crystal Holos Longview Khalix Comshare Decision Speedware Media/MR Hyperion Essbase Microsoft Analysis Services Oracle Express Oracle Express (ROLAP mode) Oracle OLAP Option AW Oracle OLAP Option (ROLAP mode) Gentia Pilot Analysis Server Microsoft Analysis Services WhiteLight PowerPlay Enterprise Server Pilot Analysis Server Applix TM1 Client multidimensional engine Oracle Discoverer Comshare FDC Hyperion Intelligence Dimensional Insight BusinessObjects Hyperion Enterprise Cognos PowerPlay Hyperion Pillar Personal Express TM1 Perspectives http://www.olapreport.com/Architectures.htm#Matrix

Tendance de part du marché http://www.olapreport.com/market.htm

Server 2003 Enterprise Edition 64 bit Résultats TPC Produit Version QphH Prix / QphH Oracle Enterprise Edition v9.2.0.2.0 34,492 141.00 $ US IBM DB2 UDB 7.2 22,361 253.00 $ US Microsoft SQL Server 2000 Server 2003 Enterprise Edition 64 bit 5,199 120.00 $ US http://www.olapreport.com/Architectures.htm#Matrix Voici les résultats de quelques produits commerciaux publier par le TPC QphH est le Query per hour performance ou l’exécution de requêtes dans une heure. La capacité du produit d’exécuter les requêtes selon les paramètres établies par le TPC. Il faut par contre mentionner que les résultats obtenus sont difficiles à comparer. Chaque produit utilise des versions différentes du matériel (serveur) et du système d’exploitation. Donc la comparaison entre eux devient difficile sinon impossible Résultats des essais à 1,000 GB Réf.: www.tpc.org

Conclusion La distribution de l’espace disque entre les vues et les index L’algorithme glouton considère seulement la contrainte de l’espace disque et exclut l’utilisation des index par les vues Le découplage de la maintenance des vues dans l’entrepôt de données par rapport aux mises à jour constantes des données sources Dans le contexte de l’article de Harinarayan et al. les facteurs suivants, qui ont une importance capitale, ne sont pas considérées

Références Ullman, Jeffrey D., « Efficient Implementation of Data Cubes Via Materialized Views », KDD Proceedings, 1996, p.386-388 Harinarayan, Venky, Rajaraman, Anand, Ullman, Jeffrey, D., « Implementing Data Cubes Efficiently », Proceedings of the 1996 ACM SIGMOD international conference on Management of Data, p.205-216, ISSN:0163-5808 Gupta, Ashish, Mumick, Inderpal Singh, Ross, Kenneth A., « Adapting Materialized Views after Redefinition », ACM SIGMOD Conference, 1995, p.211-222 Goldstein, Jonathan, Larson, Per-Åke, « Optimizing Queries Using Materialized Views: A Practical, Scalable Solution », ACM SIGMOD Conference, 2001, Vol. 2 No. 3, 1999, p.331-342 Gupta, Himanshu, « Selection of Views to Materialized in a Data Warehouse », Proceedings of 23rd VLDB Conference, Athens, Greece 1997, p.1-15 Gupta, Himanshu, Mumick, Inderpal Singh, « Selection of Views to Materialize Under a Maintenance Cost Constraint », Proceeding of the 7th International Conference on Database Theory, 1999, p. 453-470 Bellatreche, Ladjel, Techniques d’optimisation des requêtes dans les data warehouses, Laboratoire d’Informatique Scientifique et Industrielle, 2003, http://www.lisi.ensma.fr/

Diapositives d'appui

Autres algorithmes Algorithme Description ECA (Eager Compensating Adresse le découplage de vues avec les données sources VRDS (View Relevance Driven Selection) Sélection d’un ensemble de vues à matérialiser dans un contexte espace / coûts ILGA (Inner Level Greedy Optimisation de GA initiale par une comparaison itérative des combinaisons possibles des vues et des indexes ITGA (Inverted Tree Greedy Utilise un arbre inversé pour le comparer au GA initiale et l’optimiser GIA (Greedy Interchange Utilise la solution généré par le GA et l’optimise en remplaçant une à une la vue déjà sélectionnée par une vue pas encore sélectionné

Tendances de recherche OLAP Stream Data Cube Iceberg Cube-H Cube Étoile (Star cubing)

Techniques d’indexages Produit Arbre B Bitmap Jointure Oracle 9i Oui IBM DB2 Universal Database 7.2 MySQL 4.0 Non Sybase Adaptive Server Enterprise 12.5 Microsoft SQL Server 2000 SP2 http://common.ziffdavisinternet.com/download/0/1387/ExtendedFeatures_SQL.xls