index en colonne

  • Etude d'aide aux choix des technologies à mettre en place

    Contexte
    Project décisionnel
    Technologies
    • SGBD : MS SQL Server 2014 EE
    • ETL : SSIS
    • Reporting : Microstrategy V9.4 On Premise

    Objectif

    Etudier la possibilité de retirer les cubes Microstrategy aux profits des index en colonnes MSSQL

    Dans ce cas d'étude, un cube Microstrategy, composé de dizaines de mesures et de dimensions, est généré par une quarantaine de requêtes SQL sur une base de données SQL Server en version 2014 Enterprise Edition. Les index en colonnes, sont utilisés. Peuvent-ils dans ce cas remplacer le cube Microstrategy ?  Ils ont drastiquement réduit la taille des tables en base. Les types de données des identifiants ont joué un rôle important sur les performances qu'il a fallut optimiser. Au final il fut très intéressant de voir la décomposition des temps des requêtes en terme de compilation (calcul du plan d'éxécution) et d'éxécution (récupération des données).

    Les diagrammes suivants illustrent ces trois parties de l'étude : taille des tables avant/après compression, influence des types de données et décomposition compile (orange) vs exec time (bleu) :

  • Etude d'architecture SAP HANA Full Use

    Contexte
    Project décisionnel
    Technologies
    • SGBD : SAP HANA SPS11 Full Use
    • ETL : IBM Infosphere Datastage PX 9.1
    • Reporting : IBM Cognos V10.2 On Premise
    • Dataviz: Tableau 10.2 Server

    Objectifs Initiaux

    Etudier une architecture possible avec SAP HANA en remplacement du datawarehouse sous MSSQL 2005 tout en conservant le modèle de données, le patrimoine des interfaces ETL Datastage et des rapports Cognos

    Evolutions des objectifs

    Proposer un nouveau modèle de données capable d'apporter une avancée fonctionnelle sensible tous en réduisant drastiquement les temps de chargement/calculs. Proposer une solution de dataviz intégrée avec HANA afin d'apporter un éclairage nouveau sur les données tout en étant simple d'utilisation

    Dans ce cas d'étude, le modèle de données du datawarehouse est très riche et donne satisfaction aux métiers l'utilisant. Le patrimoine d'interfaces ETL représentes des centaines de flux complexes et les coûts d'une réfection complète sont élevés. Le choix du positionnement de la base de données se pose également : cloud SAP, intégration classique chez l'hébergeur traditionnel, On Premise... Les choix technologiques au sein de SAP HANA se posent également : tables classiques ou vues HANA ? Virtualisation ? en production ?

    Le diagramme suivant illustre et des scénarios proposés : Hebergement centralisé pour les briques principales, mais licencing spécifiques pour la brique datawarehouse et ainsi la possibilité d'exploiter les données avec des outils tiers non estampillés SAP :