Gestion de la température des données avec BW4/HANA (Data Tiering Optimization)

L’une des plus grandes forces de SAP HANA est le stockage en mémoire des données. Ceci permet, entre autre, d’améliorer fortement le temps des traitements (on parle de Performance de reporting x100 et de performance de chargement x10 selon SAP).

Mais cette force ne vient pas sans contreparties :  les coûts d’infrastructure pour un système HANA sont élevés comparé à une base de données classique, notamment à cause des besoins en mémoire (RAM) très élevés. Il est donc crucial d’anticiper et de maîtriser la croissance de la taille de la base, en particulier dans l’optique de réduire les coûts d’infrastructures et de licences.

SAP propose des outils pour gérer ces données et leurs empreintes sur l’infrastructure. Dans cet article, nous allons montrer comment gérer ce point sur un système BW/4HANA.

Le concept de la multi température des données

Le concept de la multi température consiste à classer les données chargées sur la base en fonction de leurs valeurs d’utilisation: plus les données sont récentes et fréquemment interrogées, plus elles auront de la valeur et inversement.

• hot data  : accès fréquent aux données => haute valeur
• warm data : accès moins fréquent =>  valeur moyenne
• cold data : accès ponctuel => faible valeur

En fonction de la température, SAP HANA propose 3 emplacements pour stocker les données

1. Niveau standard (HOT): les données sont stockées dans la mémoire principale. Les recommandations de dimensionnement de SAP HANA recommande un ratio ½ entre les données stockées et l’espace disponible. C’est à dire que les données devraient occuper 50% de l’espace disponible sur la mémoire.

2. Niveau d’extension (WARM): Selon l’architecture matérielle, les données sont stockées soit sur SAP HANA Extension Node ou soit sur SAP HANA Native Storage Extension (NSE).

• • SAP HANA Extension Node : les nœuds d’extension SAP HANA permettent de pousser cette limitation à 200% (2 fois la taille de données de l’espace mémoire).
  • SAP HANA NSE : depuis la version SAP BW/4HANA 2.0 SP04, SAP HANA NSE apporte une nouvelle approche pour stocker les données « WARM » basées sur un emplacement sur le disque dur dans SAP HANA. Pour plus d’infos sur le sujet : SAP HANA Native Storage Extension (NSE) | Q&A : Questions / Réponses (bilinksolutions.com)

3. Niveau externe (COLD): les données sont stockées dans un système externe à SAP HANA que ce soit SAP IQ ou Hadoop Cluster

 

Configuration de la température de données

Partitionnement

Sur SAP BW4/HANA, l’aDSO est l’Infoprovider à privilégier afin de persister les données transactionnelles. C’est pourquoi, c’est au niveau de cet objet que l’on paramètre la température de données.

Un concept important à comprendre pour paramétrer le Data Tiering Optimization (DTO) est le partitionnement physique de l’aDSO.

C’est le 3ème type de partitionnement qui permet la mise en place de la gestion de température de données.

Il existe deux types de partitionnement manuel :

Statique : basé sur un objet ou un champ de l’aDSO pour définir des intervalles fixes (SAP recommande l’utilisation d’un InfoObject clé comme objet de partitionnement).

Dynamique : basé généralement sur un InfoObject de type time Caracteristic (0calday, 0calyear…) ou d’un type dérivé comme Objet de partitionnement. Le type dynamique est plus flexible que le statique.

Le paramétrage général de DTO se fait sur la rubrique Data Tiering properties de l’écran General de l’aDSO :

Niveau Object : Toutes les données de la table sont déplacées (réglage non possible avec le paramétrage cold)

Niveau Partition : Chaque partition est gérée indépendamment.

Dans la partie suivante nous allons nous focaliser sur le DTO au niveau partition statique.

Exemple d’une configuration DTO sur un aDSO :

Configuration de l’aDSO

Pour notre exemple, on met en place ce réglage : on sélectionne les trois températures pour gérer la température de données sur l’aDSO.

Prérequis

Pour pouvoir configurer la température cold, il faut au préalable avoir configuré les paramètres de la base de données externe (dans notre cas SAP IQ).

Et par conséquent la température n’est possible qu’au niveau partition (car on a sélectionné cold).

Voici le schéma de notre aDSO :

Sur l’onglet Settings on définit les partitions comme suit : on a sélectionné le partitionnement statique en se basant sur le champ 0CALYEAR :

On veut gérer quatre partitions, chacune correspondant à des intervalles d’années.

Avant le changement de la température de données, jetons un œil sur les tables et les données de notre aDSO :

Pour l’instant nous n’avons que les tables standards.

Le contenu de la table active :

 

Gestion de la température des données

Il existe deux moyens pour gérer la température de données :

1. SAP GUI: Transaction RSOADSODTO, disponible depuis SAP BW/4HANA 1.0 SP04
2. BW/4HANA cockpit: App for DataStore Objects – Manage Data Tiering, disponible depuis SAP BW/4HANA 2.0.

On peut aller directement à l’écran de configuration cockpit on appuyant « Maintain Temperatures » de l’écran setting de l’aDSO

Cet écran montre la répartition des données en MB (on voit que 100% des données sont chaudes). Sélectionner l’aDSO et appuyer sur la petite flèche à droite :

On peut avoir les mêmes options de configuration via SAP GUI ->  Tcode « RSOADSODTO » :

On peut changer chaque partition indépendamment. Après le changement des températures, les températures actuelles n’ont pas changée par contre celles planifiées ont pris les nouvelles valeurs.

Revenir sur l’écran précèdent et appuyer sur exécuter. Ici on peut planifier un job de DTO ou bien l’exécuter immédiatement :

Après la fin de l’exécution la répartition de données a changé :

On peut vérifier le détail sur l’écran des partitions : la partition actuelle a bien pris les valeurs planifiées :

L’aDSO après le changement de la température

En revenant sur l’aDSO, on remarque la création de trois nouvelles tables externes ( sur la base externe configurée)

Réexécutons la même requête pour examiner le contenu de la table active :

Les données paramétrées comme froides ne sont plus sur la table active.

L’exécution de la même requête sur la table « /BIC/ONZDSODTO » montre que les données froides ont été déplacées sur celle-ci.

Les deux autres nouvelles tables externes sont des tables techniques.

Reporting sur les données froides

Par défaut les données transférées au niveau froid ne peuvent pas être interrogées par les outils de reporting.

Pour changer ce réglage :

• compositeProvider : General -> Common Runtime Properties->Cold Store Access :
  

  Copie d’écran de logiciel SAP

• Requête BW : General -> Extended -> Cold Store Access :

Limitations

Par défaut BW ne gère pas la mise à jour des données dans la partition cold, SAP a ajouté cette fonctionnalité depuis le version BW/4HANA 2.0 SP07. Pour l’activer il faut cocher l’option « Exceptional Updates to Cold Store » sur les propriété DTO de l’aDSO. Le système crée suite à cela, à l’instar de la table /BIC/A<nom technique ADSO>1 pour les données hot et warm, une nouvelle table /BIC/A<nom technique ADSO>9 qui va gérer les mises à jour des données cold après l’activation de l’aDSO.

La taille de la table / partition de table est limité à 2^31 lignes ( à peu près 2 milliards) par partitions.

Une table peut être divisée jusqu’aux 16000 partitions.

Conclusion

Nous avons vu avec un exemple simple comment configurer le DTO sur un partitionnement statique. Il y a des scenarios beaucoup plus complexe. Notamment avec l’utilisation du partitionnement dynamique. Par exemple : Changer la température de toutes les données antérieures aux 3 dernières années en warm ou cold.

Dans la roadmap de BW/4HANA, SAP prévoit d’ajouter une nouvelle température de données : Deleted. Cette température va permettre de supprimer les données de la partition cold. Pour plus d’information sur le sujet : Deleting Data from the Cold Store | SAP Help Portal