Application des meilleures pratiques pour la modélisation

Implémentation des pratiques de modélisation recommandées

Objective

After completing this lesson, you will be able to mettre en œuvre les pratiques de modélisation recommandées.

Comprendre le processus d'instanciation

Avant d'explorer en détail comment améliorer les performances de la vue de calcul, il est utile d'en apprendre un peu plus sur la manière dont une vue calculée répond à une requête qui l'appelle.

Schéma du processus d'optimisation pour les requêtes sur les modèles stockés. Tout d'abord, le moteur de calcul instancie un modèle d'exécution pour la requête, puis l'optimise et enfin l'optimiseur SQL prend le relais. Pour plus de détails, reportez-vous au texte suivant.

Le moteur de calcul pré-optimise les requêtes avant qu'elles ne soient traitées par l'optimiseur SQL.

Une vue de calcul est instanciée au moment de l'exécution d'une requête. Lors du processus d'instanciation, le moteur de calcul simplifie la vue calculée dans un modèle qui répond aux exigences de la requête. Il en résulte un modèle réduit qui peut être optimisé davantage par le moteur de calcul. Par exemple, il prend en compte des options telles que la jointure dynamique, la cardinalité de jointure et l'élagage des nœuds d'union.

Ensuite, l'optimiseur SQL applique d'autres optimisations et détermine le plan d'exécution de la requête - par exemple, il détermine la séquence optimale des opérations, ainsi que les étapes qui peuvent être exécutées en parallèle.

Détails du processus d'instanciation. La requête qui appelle la vue calculée génère une vue calculée élaguée qui lit uniquement les parties requises de la vue calculée d'origine. Il ne contient pas d'attributs ou d'indicateurs qui ne font pas partie de la requête.

Le processus d'instanciation transforme une vue de calcul d'origine (que vous définissez) en un modèle d'exécution basé sur une requête exécutée au-dessus d'une vue de calcul. La vue générée est supprimée des éléments inutiles de la vue calculée d'origine et est techniquement une vue de colonne qui fait référence à un nœud spécifique de la vue calculée d'origine.

Lors du processus d'instanciation, la requête et le modèle de calcul d'origine sont combinés pour créer le modèle de calcul d'exécution optimisé.

Meilleures pratiques de modélisation

Dans cette leçon, nous aborderons les recommandations et les meilleures pratiques pour la modélisation des données avec SAP HANA Cloud.

Recommandations générales de conception

Capture d'écran d'une vue de calcul volumineuse et de la manière dont elle peut être divisée en blocs plus petits. Vous devez identifier les modèles récurrents, puis fractionner les modèles en parties plus petites pour éviter les vues monolithiques.

Décomposez les grands modèles en vues calculées individuelles afin qu'ils soient plus faciles à comprendre et vous permettent également de définir des composants réutilisables, évitant ainsi la redondance et la maintenance dupliquée en conséquence.

Essayez de développer des vues calculées en couches afin que chaque couche consomme les couches inférieures. Toute modification apportée aux couches inférieures a un impact immédiat sur les couches supérieures. Les couches les plus basses doivent fournir les vues calculées de la fondation. Les couches supérieures ajoutent une sémantique croissante pour fournir plus de signification économique aux vues.

Remarque

Ne vous inquiétez pas du fait que la division de grandes vues calculées en blocs de construction individuels nuira aux performances globales. Au moment de l'exécution, l'optimiseur SQL tente d'aplatir l'ensemble de la pile de vues de calcul dans une seule instruction exécutable. N'oubliez pas que les définitions de vue de calcul, même si elles sont nombreuses dans la pile, représentent une vue logique du flux de données. La manière dont l'optimiseur construit la requête SQL finale ne peut jamais être connue au stade de la conception en observant simplement les définitions de vue de calcul. Utilisez les outils SQL tels que l'analyseur SQL pour vérifier le SQL généré, si nécessaire.

Objectif du dépliage de la requête

Vous devez viser le dépliage des requêtes. L'idée est que les objets de requête doivent être directement accessibles à l'optimiseur SQL à un niveau détaillé. L'avantage est une performance d'exécution plus rapide des plans dépliés, mais le temps de compilation de la requête peut augmenter.

Au moment de l'exécution, votre vue calculée est analysée par le processeur SQL. Un objectif clé est de convertir chaque opération de vue de calcul en un opérateur SQL correspondant pour convertir le graphe de flux de données complet en une seule instruction SQL. C'est ce que l'on appelle le dépliage. L'avantage du dépliage vers SQL est que seul le moteur SQL est nécessaire et qu'aucun autre moteur SAP HANA n'est appelé, tel que le moteur de calcul ou d'autres moteurs SAP HANA Cloud tels que Spatial ou Graph. Cependant, en raison de la conception de votre vue de calcul, certaines étapes peuvent ne pas pouvoir être converties en opérateurs SQL. Si ces étapes ne peuvent pas être traduites, elles seront traitées dans les moteurs SAP HANA spécialisés qui génèrent une ou plusieurs vues de colonnes matérialisées. Ces vues de colonne matérialisées sont ensuite lues par SQL. Ainsi, au lieu de lire le SQL directement à partir des tables source, les vues de colonne doivent d'abord être générées, puis le SQL doit lire à partir des vues de colonne intermédiaires. Cela entraînerait une requête partiellement dépliée qui pourrait ne pas fonctionner aussi bien qu'une requête entièrement dépliée en raison d'optimisations SQL limitées.

Certains nœuds et opérateurs ne peuvent pas être dépliés lorsqu'il n'existe aucun opérateur SQL équivalent pour la fonctionnalité de vue de calcul que vous implémentez.

Il faut souligner que bien que le dépliage soit généralement souhaitable, parfois le dépliage peut effectivement nuire aux performances globales. Par exemple, le temps de compilation d'une requête peut augmenter lorsque la requête doit être dépliée chaque fois que la vue calculée est appelée avec de nouvelles sélections. Par conséquent, il est possible de définir une astuce SQL qui empêche le dépliage pour les vues de calcul individuelles. Elle se trouve sous Propriétés→du nœud sémantique→Avancé.

Vous pouvez définir un paramètre global pour empêcher le dépliage de toutes les vues de calcul.

Vous pouvez vérifier si votre vue de calcul est dépliée à l'aide de Analyser > Explain plan dans la console SQL, où vous pouvez voir la liste des opérateurs et des sources de données.

Mode de dépliage : captures d'écran de l'analyseur SQL pour une requête dépliée et pour une requête pliée. La requête dépliée accède à une table en colonnes. La requête pliée accède aux vues de colonne.

Si une vue de colonne est utilisée comme source de données au lieu d'une table, vous savez qu'il ne s'agit pas d'une requête dépliée car le résultat a été matérialisé en tant que vue intermédiaire et n'a pas été lu directement à partir d'une table. Une requête entièrement dépliée accède uniquement aux tables.

Attention

Dans certains scénarios, le nom de l'opérateur peut également être TABLE SCAN, ce qui révèle également que l'objet sous-jacent "physique" a été accédé, ce qui signifie que cette branche du scénario a été dépliée.

En outre, vérifiez le temps de compilation de la requête par rapport au temps d'exécution pour voir comment le dépliage affecte la durée d'exécution globale.

Il est possible d'identifier le nombre de requêtes qui n'ont pas été dépliées. Exécutez une requête dans la vue système M_FEATURE_USAGE comme suit :

Code Snippet
1234567891011
SELECT
 	FEATURE_NAME,
 	CALL_COUNT 
FROM 
	"M_FEATURE_USAGE" 
WHERE 
	COMPONENT_NAME = 'CALCENGINE'
AND
	FEATURE_NAME 
IN 
  ('QUERY TOTAL','QUERY UNFOLDING')

Utiliser des vues ou des tables dédiées pour la « liste de valeurs »

Pour les problèmes de performance, nous vous recommandons généralement de créer des vues de calcul ou des tables dédiées pour générer la liste des valeurs d'aide pour les variables et les paramètres d'entrée.

Schéma d'une vue d'aide à la saisie qui lit les données de base produit. La vue d'aide à la saisie est appliquée à une vue des données de vente et à une autre vue des données d'achat. Les avantages de l'utilisation des vues d'aide à la saisie sont les boîtes de dialogue d'aide à la saisie plus rapides, les listes cohérentes de variables dans les vues d'utilisation et la prise en charge des privilèges d'analyse dans le sens où les utilisateurs voient leur liste de valeurs autorisées.

Cette approche permet un affichage plus rapide de la liste de valeurs sans lire l'intégralité de la vue ou de la table sur laquelle la vue calculée est basée.

Il s'agit également d'une meilleure pratique pour que la liste de valeurs soit réutilisable et cohérente d'une vue de calcul à une autre et que les utilisateurs voient les mêmes valeurs de sélection.

La liste peut être pilotée par des filtres fixes simples à l'aide de la vue de calcul ou même par des privilèges analytiques qui offrent une liste dynamique limitée à ce que chaque utilisateur est autorisé à sélectionner dans l'interface.

Learning

SAP FacebookSAP YoutubeSAP LinkedIn