Sidecar SAP HANA pour le reporting et les flux finance

La plupart des systèmes SAP fonctionnaient alors sur Oracle. SAP promouvait HANA, sa base de données en mémoire et en colonnes, beaucoup plus rapide sur les très grandes tables, ce qui la rendait intéressante pour les volumes de données de L'Oréal USA. L'Oréal a choisi de ne pas remplacer Oracle et a ajouté HANA en tandem, comme copie secondaire en lecture seule alimentée par une réplication en quasi-temps réel : un sidecar. Les données maîtres restaient dans Oracle, et rien n'était mis à jour ni supprimé dans HANA. L'objectif était d'accélérer les rapports, transactions et calculs les plus coûteux, en particulier les flux finance et les programmes de reporting BI, et d'ouvrir de nouvelles possibilités à la BI.

Le défi

Les deux bases de données fonctionnent de manière très différente. Oracle stocke les données en lignes, sur disque, avec des buffers en mémoire vive, des clés primaires et des index. HANA garde tout en mémoire vive, stocke les données en colonnes (le stockage en lignes est possible mais pas optimal) et rend la plupart des index inutiles. Elle est la plus performante sur les très grandes tables, sur les tables larges avec beaucoup de champs inutilisés et sur les agrégations et sommes : plus la table est grande, plus son avance sur Oracle est importante.

Les programmes existants de L'Oréal avaient été écrits pour une base de données en lignes, et leur passage sur HANA ne leur profitait donc pas de la même façon. Certains gagnaient peu, d'autres beaucoup. Deux contraintes ont orienté la conception :

• Le coût. HANA était facturée à l'espace consommé, et le serveur physique devait être dimensionné en puissance de calcul et en mémoire vive. La machine coûtait très cher, mon estimation des capacités devait donc être précise.
• Pas de jointure entre les deux bases. Une jointure SQL ne pouvait pas porter à la fois sur Oracle et sur HANA : toute table souvent jointe à une table répliquée devait donc elle aussi être répliquée.

Conception de la solution

• Architecture : HANA fonctionnait en tandem avec Oracle, comme base secondaire en lecture seule avec réplication en quasi-temps réel. Oracle restait la base primaire et le système de référence.
• Sélection des tables : j'ai choisi les tables les plus volumineuses, les plus lues et les plus utilisées par les rapports, ainsi que les petites tables souvent jointes avec elles, et j'ai estimé leur taille en tenant compte de leur évolution dans le temps.
• Réplication : j'ai configuré quelles tables étaient répliquées en temps réel et lesquelles n'en avaient pas besoin.

Mise en œuvre technique

Du « data to code » au « code to data ». Le schéma ABAP classique de l'époque Oracle consiste à faire des SELECT simples, puis à calculer et trier en ABAP sur les serveurs d'applications. Avec HANA, j'ai déplacé les calculs, tris, regroupements et agrégations dans du SQL exécuté dans la base de données.

Identifier les candidats. J'ai utilisé la trace SQL et les outils d'analyse de performance pour trouver les requêtes lentes et les algorithmes ABAP coûteux qui avaient le plus de chances d'en bénéficier.

Programmes SAP standard. SAP livrait des accélérateurs HANA sous forme de patchs et de notes. Avant de les appliquer, j'ai utilisé les outils de comparaison de versions pour vérifier l'absence d'extensions spécifiques que les modifications pouvaient impacter. Les accélérateurs s'appliquaient ensuite automatiquement, sans modification de code.

Programmes spécifiques. Je les ai analysés et réécrits. Oracle restait la connexion par défaut : j'ai donc utilisé les instructions qui envoient une requête vers la connexion secondaire HANA, et j'ai poussé davantage de calcul dans la base de données. J'ai aussi construit des modèles HANA Studio (vues analytiques et vues de calcul).

Redirection seule. Parfois, rediriger un programme vers HANA suffisait, car même du SQL basique s'exécute plus vite en mémoire. Dans ces cas, j'ai utilisé la configuration technique de SAP qui indique au système d'utiliser HANA automatiquement pour des programmes et tables spécifiés.

Résultats

Le client a tout de suite remarqué l'amélioration, car l'expérience utilisateur s'est améliorée immédiatement. Les attentes étaient grandes, puisque HANA coûtait cher en licences, en espace et en matériel. Dans le dossier, j'ai décrit certaines optimisations comme ayant « des résultats spectaculaires, comme des temps de traitement divisés par mille ou plus ». J'ai aussi écrit que les équipes BI pouvaient obtenir des rapports en temps réel alors que ces données étaient auparavant extraites en une journée, ce qui donnait au métier une vue en temps réel des stocks, des résultats des ventes et des transferts de marchandises. Ce sont mes propres affirmations dans le dossier, et non des chiffres mesurés de manière indépendante.

Ce que j'en ai retenu

Je m'étais préparé avec la formation HA400 de SAP (programmation ABAP sur HANA). La principale leçon a été le changement de paradigme : sur HANA, la performance vient de la logique poussée vers les données, au lieu de remonter les données vers le serveur d'applications. Peu après ce projet, SAP a annoncé S/4HANA, avec HANA comme base primaire obligatoire : ces compétences ont donc servi sur tous les projets SAP suivants.