Nous constatons, chez nos clients, un besoin croissant de libre accès à plus d’informations, sous forme de puits de données avec une granularité fine. C’est particulièrement vrai dans un contexte de modélisation de flux avec des calculation views sur BW on HANA, BW/4HANA ou tout simplement HANA 2.0.
Ce besoin de libre accès, combiné à l’augmentation des volumétries et à la complexité de certains flux, peut entrainer des surcharges de la base HANA ainsi qu’une dégradation des performances.
Dans cet article, nous vous proposons de découvrir 3 leviers permettant d’optimiser – en performance et en consommation de mémoire – vos calculation views sur HANA 2.0.

Jointure left ou inner

Dans un contexte de modélisation sur des calculation views, le choix du type de jointure est important pour une bonne optimisation.
Pour rappel, la jointure inner permet de joindre uniquement les lignes dont les clés sont présentes dans les deux tables.

Techniquement parlant, le traitement va vérifier, dans un premier temps, les valeurs de la table A dans la table B puis, dans un second temps, les valeurs de la table B dans la table A. Ce traitement sur deux tables très volumineuses consommera beaucoup de mémoire et de temps machine.

Illustration jointure inner

En revanche, la jointure left permet de retourner toutes les lignes d’une table avec les données liées d’une autre table si elles existent.
Dans ce cas la machine cherchera les occurrences de la table A dans la table B et retournera le résultat.

Illustration jointure left

Compte tenu du nombre d’opérations exécutées, la jointure left sur une base HANA est plus performante.
Dans certains cas – et selon les besoins d’optimisation, lorsqu’une jointure de type inner est trop couteuse, il est possible de la remplacer par une jointure left.
Pour cela il suffit d’ajouter un filtre excluant les lignes ayant des valeurs vides dans le champ de la deuxième table.

Illustration jointure left + filtre

Le résultat final est le même qu’avec une jointure de type inner.
Prenons l’exemple de deux tables d’une grosse volumétrie (plusieurs millions de lignes). Dans un cas nous allons utiliser la jointure inner. Dans l’autre, la jointure left avec un filtre pour supprimer les lignes superflues et retrouver le même résultat que dans le premier cas.

Jointure inner

Jointure inner

Jointure left

Jointure left

Résultat

Dans notre cas, la jointure left est bien plus performante. Dans le premier cas, l’exécution a duré environ 25 secondes au total contre environ 4 secondes pour la deuxième exécution, soit un résultat environ 5 fois plus rapide.

Pruning simplifié

Pour ce cas, plaçons-nous dans un contexte particulier.
Le client possède trois ECC chacun spécifique à une filiale de l’entreprise. Il souhaite pouvoir consolider toutes les informations issues des différents systèmes, ou consulter uniquement les informations d’un système dans la même requête.
Nous allons donc obtenir trois projections – une par système source – et une union comme nous le montre la vue ci-dessous.

Union

Pour ce faire, un input parameter (IP_ECC) est créé à l’identique dans chacune des projections et on y place les filtres suivants :
• Projection 1 : IP_ECC = * OR IP_ECC= 1
• Projection 2 : IP_ECC = * OR IP_ECC = 2
• Projection 3 : IP_ECC = * OR IP_ECC = 3

Avec ces filtres, soit l’utilisateur saisit la valeur * et remonte les données des trois ECC, soit il saisit le numéro correspondant à l’ECC voulu.
En exécutant le visual plan de cette vue, on obtient les schémas suivants :

Pruning

On constate donc que l’union n’est pas exécutée si la valeur des filtres ne concerne qu’une seule branche.
Cette méthode peut également être utilisée pour activer ou désactiver des branches complètes du flux via un Input Parameter.

Ainsi, elle peut être mise en place pour ne pas exécuter une branche contenant un calcul complexe et coûteux, quand le résultat n’est pas nécessaire pour la requête.

Utilisation de jointure left optimized

Dans les modélisations HANA, la bonne pratique veut que les vues puissent être réutilisables au maximum. Cependant, la réutilisation d’une modélisation implique des jointures avec des référentiels qui ne sont pas forcément sollicités lors de l’exécution de la requête.
Grâce au recours à la jointure left optimized, les jointures avec les référentiels non sélectionnés ne seront pas exécutées.

Dans l’exemple, nous allons faire la comparaison entre les deux requêtes suivantes :
• Afficher les quantités et unité des postes de facturation par Article.
• Afficher les quantités et unité des postes de facturation par Article et un attribut de la masterdata Article.
Nous obtenons donc la calculation view suivante :

Jointure left optimized

Dans la jointure, nous avons renseigné la cardinalité et mis l’option ‘Optimize Join Columns’ à ‘True’.

Properties

Les plans d’exécution ci-dessous nous montrent bien que, dans le cas de la requête sans attribut (plan de gauche), la jointure n’est pas exécutée, contrairement à la requête avec l’attribut (plan de droite) avec l’option Join optimized active, mais qu’elle est exécutée dans les deux cas sans l’option.

Plans d'execution

On constate bien que la jointure n’a pas été exécutée dans le cadre où le champ n’a pas été sélectionné avec l’option Join optimized active. Le processus est également environ deux fois plus rapide sur l’exécution de la requête sans attribut avec l’option (1,4ms avec option contre 2,7ms sans option).

En conclusion

En combinant ces différents leviers, il sera possible de réduire significativement la consommation mémoire et les temps de réponses.
Dans le cadre de projets de reporting basés sur HANA, il est primordial de maitriser la performance (mémoire/CPU) afin de garantir une expérience utilisateur satisfaisante sur des périmètres d’analyses acceptables, et ce, dans la durée.