REX: Le choix de SQL Server Analysis Services 2016 face à Business Object 4.2 by VISEO
LinkedIn Google Plus Twitter Email

REX: Le choix de SQL Server Analysis Services 2016 face à Business Object 4.2

Un retour d’expérience de David Raynaud, Architecte & Practice Manager Microsoft BI VISEO
24 Juillet 2017

Migration Big Data: SQL Server Analysis Services 2016 ou Business Object 4.2?

David Raynaud, Architecte & Practice Manager Microsoft BI VISEO, nous parle d’une mission client de migration vers de nouvelles technologies Big Data. Alors, SSAS 2016 ou Business Object 4.2? Notre expert vous explique tout.

Une migration nécessaire vers de nouvelles technologies Big Data

Notre client désirait tester et comparer la couche sémantique de Microsoft (SQL Server 2016) avec leur outil de reporting Business Object 4.2 SP2. En effet, il est en train d’étudier la possibilité de basculer vers de nouvelles technologies Big data et la suite SAP BI ne s’adapte pas parfaitement à cette nouvelle architecture. Avec SSAS 2016, nous avions donc à créer un cube sur le modèle d’un univers déjà existant. L’objectif étant de comparer les fonctionnalités des deux outils mais aussi de qualifier/quantifier les efforts et les risques d’une telle migration. Il désirait également évaluer les possibilités offertes par les outils de reporting de Microsoft (SSRS, Power BI, Excel) afin d’identifier:

- Leurs rôles et utilisations potentielles
- Leurs fonctionnalités
- L’autonomie que ces outils apportent aux utilisateurs
- La facilité d’accès aux données

Cube multidimensionnel ou cube tabulaire?

Avant de commencer les développements, la première étape était de choisir la bonne technologie pour notre cube. Nous pouvions soit utiliser un cube multidimensionnel, technologie amplement éprouvée depuis 2005, soit un cube tabulaire s’appuyant sur une base VertiPaq. Le choix entre ces deux solutions était capital pour la bonne réussite du projet. 

La première solution, le cube multidimensionnel est une solution de raison. Elle est parfaitement maitrisée mais nous connaissons aussi ses points faibles. Elle permet de gérer des volumétries très fortes, elle permet également d’optimiser les analyses grâce au pré-calcul des agrégats. Par contre, un cube multidimensionnel n’est pas approprié lorsque l’analyse se rapproche du niveau fin et lorsqu’il faut croiser beaucoup d’attributs. L’autre inconvénient dans ce projet est la différence de logique entre un univers BO et un cube multidimensionnel. L’effort de migration est là très important et le langage MDX n’aide pas non plus car il est bien plus complexe.

Le cube tabulaire, lui, est plus comparable à un univers BO. Sa technologie est bien plus proche d’une base de données, du coup le gap pour passer de BO vers un cube tabulaire est plus faible. De plus, le stockage des données en mémoire (par colonnes) permet d’avoir de très bonnes performances. Depuis la version 2016, le cube tabulaire a de nouvelles fonctionnalités importantes comme:

- La gestion des dossiers d’affichage
- Les traductions
​- La possibilité de créer des tables calculées dans SSDT
- Le traitement en parallèle de plusieurs partitions de tables dans les modèles tabulaires
​- L’amélioration de l’utilisation mémoire
​- Et la possibilité de faire des filtres croisés bidirectionnels

Les uses-cases exprimés par notre client comme le besoin de reporting opérationnel (au niveau fin) et la plus grande proximité des cubes tabulaires avec un univers BO nous a donc poussé à abandonner les cubes multidimensionnels. De plus il est plus facile de développer un rapport avec Power BI car il utilise la même technologie que les cubes tabulaires.

La création du modèle

Une fois ce choix réalisé, la création du modèle a été faite en se basant sur des vues pour alimenter tous les objets du cube. Cela permet de simplifier et de mutualiser la gestion des règles de calcul mais aussi:

- De simplifier le modèle en regroupant dans un objet plusieurs informations de plusieurs tables
​- D’identifier et d’optimiser les traitements lors des exploitations
​- De réduire la volumétrie lors du développement pour accélérer l’import et la création des jointures

La sélection de la Data

Nous avons également sélectionné uniquement les données nécessaires aux jointures, aux analyses et aux calculs pour réduire l’espace mémoire utilisé.

Les points d’attentions identifiés ont été les suivantes:

- La traduction n’est possible que pour les libellés des champs mais pas le contenu. En effet, le fichier JSON de traduction ne contient que la structure du cube. Il n’est donc pas possible d’afficher un libellé en fonction de la langue de l’utilisateur.
​- La langue par défaut du cube est celle de SSDT et il n’est pas possible de la changer (même en modifiant le code XML du projet). De plus, il n’est pas possible de créer de traduction sur la langue par défaut. Les noms des colonnes et des mesures ne peuvent donc pas être modifiés par traduction pour cette langue et cela aura un impact sur les rapports déjà créés.

Puisque les cubes tabulaires sont basés sur une base VertiPaq, les jointures entre les tables ne sont possibles qu’à partir d’une et une seule colonne. Il y a donc obligation de modéliser les relations de tous les objets avec une clé unique. Là encore, les vues sont un bon moyen de les créer.

Le dernier écart entre BO et la couche sémantique MS est l’impossibilité d’avoir des contextes dans un cube. Il est, bien sûr, possible de créer des alias permettant d’éviter les boucles de relation, mais il n’y a pas de gestion de contexte.

Donc, Univers Business Object ou Cube Tabulaire?

En conclusion, on peut dire qu’un univers BO et un cube tabulaire ont une approche assez similaire dans la conception et la modélisation. La différence est plus technologique. Malgré quelques fonctionnalités manquantes (comme la traduction), le cube tabulaire, bien qu’encore jeune, tient bien la comparaison. Associé aux outils de reporting de Microsoft, le cube in-memory est donc une alternative sérieuse à une couche sémantique classique basée sur du SQL comme celle de la suite SAP BI.

 

Mais aussi:
- Business Intelligence et Data: Cinq tendances pour 2017
​- REX MySQL vers Azure SQL Database, via Azure Data Factory
​- Découvrez notre offre d'intégration de solutions BI