Fiche concept

Tuning de Performance HANA

À jour au 2026-07-23

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Tuning de Performance HANA ?

Le tuning HANA sépare l'architecte qui lit les query plans du junior qui blâme « le volume de données » — cinq leviers transforment une query de 5-50 secondes en 100-500 ms.

De quoi il s'agit

Le HANA Performance Tuning est la discipline d'ingénierie de faire que les queries run en 100-500 ms au lieu de 5-50 secondes. Ça sépare l'architecte senior (qui lit les query plans, design les partitions, sait quand flatten une hiérarchie) du consultant junior (qui blâme "le volume de données"). Pour les consultants SAP analytics en ère BDC — où Datasphere siège sur HANA Cloud (companion C001) — la fluence HANA est la monnaie architecturale qui convertit les décisions de modélisation en millisecondes, et les millisecondes en adoption utilisateur.

Les cinq leviers de tuning en priorité. (1) Fitness column-store — confirmer que les tables sont columnar (default, mais les migrations legacy gardent parfois row-store). 10-100× différence de scan-speed. (2) Préservation push-down — les query plans montrent si l'optimizer HANA a pushed les prédicats + projections à la couche storage. Les vues Script (companion C004) cassent le push-down; rewrite as SQL. (3) Design de partition — partitionner les fact tables par FISCAL_YEAR (2-5M lignes/partition optimal). Le partition pruning évite de scanner de la data non-pertinente. (4) Statistics + indexing — collecter statistics sur les join columns; créer inverted indexes sur filter-heavy columns. (5) Materialization vs federation — si une Datasphere view federate 5+ sources, materialize le join result; la latence query drop 5-20×.

Pourquoi c'est important

Les vues Script cassent silencieusement le push-down — les réécrire en SQL peut à elles seules produire un saut de latence qu'aucune montée en puissance matérielle ne rattraperait.
Fédérer 5+ sources dans une vue Datasphere sans matérialiser le résultat de jointure coûte 5-20× de latence — une décision prise au moment de la modélisation, pas un problème runtime à corriger plus tard.
Un senior passe 30-60 minutes à lire l'arbre d'opérateurs du Plan Visualizer par query lente et nomme l'opérateur exact en cause — un diagnostic vague « c'est lent » ne survit pas à cette discipline.

Points clés

Cinq leviers de tuning : column-store · push-down · partition · stats/index · materialize-vs-federate.
Plan Visualizer est l'outil de diagnostic ; le lire demande 5-10 min de pratique.
Préservation du push-down : pas de vues Script dans l'arbre de dépendances de l'AM.
Conception des partitions : FISCAL_YEAR + 2-5M lignes/partition optimal.
Matérialiser à partir de 5+ sources fédérées (amélioration de latence 5-20×).
Calculation Views ≤ 2 niveaux de profondeur.
ROI du tuning : 100-1000× par rapport à l'ajout de capacité.
Overhead DAC : 3-5ms/règle × N empilées.
HANA Performance Tuning n'est maîtrisé que lorsqu'il change une décision d'achat identifiée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.

Termes employés sur cette page

Column-store: Stockage par défaut de HANA : colonnes stockées séparément, optimal pour les scans analytiques. 10 à 100× plus rapide que le row-store.
Push-down: L'optimiseur pousse prédicats + projections vers la couche de stockage. Les script views le cassent.
Plan Visualizer: Outil de HANA Studio affichant l'arbre d'opérateurs par requête. L'outil de diagnostic primaire.
Partition pruning: L'optimiseur saute les partitions non pertinentes durant le scan. Nécessite un design de partition (FISCAL_YEAR typique).
Materialize-vs-federate: Arbitrage : la requête fédérée multi-source est plus lente mais les données sont fraîches ; la jointure matérialisée est plus rapide mais avec le coût de la copie.
Cold cache: La première requête de la journée est plus lente car les données ne sont pas encore en RAM HANA. Préchauffer les modèles chauds selon un planning.
Calculation View nesting: Vues HANA en couches où chaque niveau ajoute de la complexité d'optimisation. Plafonner à ≤ 2 niveaux pour la lisibilité.
DAC overhead: Coût de réécriture de requête par règle : 3 à 5 ms par règle et par requête. Les règles empilées s'additionnent.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code.

Ouvrir dans l'application →

Tuning de Performance HANA

Qu'est-ce que Tuning de Performance HANA ?

De quoi il s'agit

Pourquoi c'est important

Points clés

Termes employés sur cette page

Sources

Concepts liés

Modules d'académie associés

Études approfondies

Guides SAP analytics & TJM