Du type moyen au premier de la classe

Bernd Weber est un type universel. Il n'est pas vraiment grand, mais pas non plus petit, aime porter des vêtements dans des tons sobres et se déplace lentement. Lui-même se décrirait probablement comme un homme ayant des tâches importantes, des petits bobos et dans la force de l'âge.

Beaucoup d'entre nous ont déjà rencontré ce Bernd quelque part, il est plus connu sous ses initiales BW. Regardons de plus près ce Bernd moyen. À quoi ressemble-t-il vraiment ?

Les résultats mentionnés dans cet article se basent sur de nombreuses analyses automatisées de systèmes Business Warehouse productifs que nous avons effectuées en 2012 dans le cadre du test d'aptitude DataVard SAP BW. Les systèmes proviennent d'entreprises de différents secteurs et de différentes tailles, de la chimie aux services publics, des PME au DAX.

Le type moyen

Notre Bernd Weber, c'est-à-dire la moyenne absolue de SAP BW, a une taille de système d'environ 4,2 téraoctets. Notre aperçu montre qu'avec 46%, presque la moitié de tous les systèmes se situe également entre un et cinq téraoctets.

En outre, 31 % des systèmes, soit un sur trois, ont une taille inférieure à un téraoctet. Dix pour cent des systèmes ont une taille comprise entre cinq et dix téraoctets et seuls 13 pour cent de tous les systèmes que nous avons analysés dépassent la limite des dix téraoctets.

Face à la discussion actuelle sur les Big Data, nous nous demandons d'où vient ce thème tendance dans le contexte de SAP BW, puisque la plupart des systèmes ne sont apparemment pas si grands. Mais à notre avis, un indice important pour le Big Data n'est pas la taille pure du système, mais le volume de données qui doit être interrogé dans une requête.

Dans notre système moyen, moins d'un tiers des données se trouvent dans la couche de reporting. En outre, le système est généralement composé à plus de 40 % de données temporaires et autres.

Par autres données, nous entendons tout ce qui n'est pas données de base, cubes, ODS, PSA et ChangeLogs. Nous constatons souvent que les plus grandes tables de ce groupe sont les statistiques BW. Le reste du système BW se compose des couches de préparation des données et des données de base.

La taille d'un système BW ne permet guère de tirer des conclusions sur les défis à venir. La croissance est un indicateur important à cet égard. Notre Bernd Weber a un taux de croissance de 30 % par an !

Les douleurs de croissance ne sont évidemment pas absentes. Après deux ou trois ans, la taille du système a doublé. D'un côté, les coûts des technologies de stockage existantes diminuent et peuvent ainsi absorber une partie de la croissance, du moins financièrement.

D'un autre côté, nous voyons des développements actuels, comme l'informatique en mémoire, qui font à nouveau grimper les coûts par gigaoctet. Les stocks de données croissants entraînent non seulement une augmentation du TCO (Total Cost of Ownership), mais aussi des défis en termes de performance.

Le système moyen a un temps d'exécution Weighted Query Step de 14 secondes. Ce résultat explique bien des frustrations du côté des utilisateurs. La pâle apparence de notre système moyen n'est pas seulement due à ses caractéristiques discrètes, comme sa taille et ses performances, mais aussi à sa dernière mise à niveau.

Bernd Weber est un système BW sur la version NetWeaver 7.01. Seuls neuf pour cent des systèmes fonctionnent sur 7.30 et plus. Ceci est particulièrement intéressant dans le contexte de Hana, car pour passer à cette technologie, il faut au moins cette version.

Le premier de la classe

Contrairement à notre système moyen discret, le premier de la classe est une personnalité haute en couleur. La grande différence, nous la trouvons dans sa stature et sa forme physique. Il est athlétique et rapide.

Contrairement aux 14 secondes de Weighted Query Step Runtime du type moyen, le Primus a atteint l'objectif en quatre secondes - et ce sans Hana. Le taux de graisse corporelle du Primus est également intéressant : les données temporaires et système ne représentent ici que 20 % de l'ensemble du système.

En outre, la gestion des données est plus légère, car seules les données actuelles sont conservées dans les infoproviders et les données "froides" sont régulièrement externalisées. Il y a certainement de nombreuses raisons à cette bonne performance, nous en présentons brièvement trois ici :

1. l'utilisation de sa bonne disposition, des moyens de bord d'un système BW, sont ici un facteur de réussite important. Le modèle de données est optimisé en termes de temps d'accès - le temps de lecture par requête est faible. Pour le mesurer, nous calculons le nombre de lignes à lire par ligne éditée.

Dans le système moyen, il y a 57 enregistrements lus pour une ligne affichée. Dans les meilleurs systèmes, il n'y a que trois à cinq lignes. Une telle optimisation du système BW peut être réalisée sans solutions externes.

2. les meilleurs systèmes ont en commun un bon housekeeping, grâce auquel les données qui ne sont pas nécessaires pour le reporting et la préparation des données sont éliminées. Les systèmes les plus performants utilisent des solutions entièrement automatisées pour garantir la durabilité.

Contrairement à ces systèmes, nous constatons, en examinant de nombreux systèmes BW normaux, que les tableaux de statistiques et de logs font partie des plus grands du système. La question qui se pose ici est de savoir si les statistiques d'accès aux requêtes, vieilles de trois ans, ont autant de valeur que les entrées de commandes de la veille.

3. le leader de la classe répartit en outre les données en fonction de la fréquence d'accès afin d'optimiser les temps de reporting - ce qui est généralement réalisé par le biais de tranches horaires. Le temps de reporting est donc optimisé parce que la quantité de données auxquelles on accède est réduite.

Nous observons pour cela deux approches : Partitionnement et archivage/stockage en ligne. Dans le cas du partitionnement, les infoproviders sont souvent divisés manuellement. Cela peut signifier, par exemple, que les données de commande de chaque exercice se trouvent dans un infoprovider distinct.

Lors de l'archivage ou du NearLine Storage (NLS), les données sont automatiquement déchargées du fournisseur d'informations actif à l'issue d'une période de conservation. Grâce à l'interface NLS, SAP a créé la possibilité de conserver malgré tout les données dans l'accès complet des utilisateurs.

NLS n'est pas synonyme de Sybase IQ : selon la solution utilisée, les données sont stockées directement dans le système SAP sous forme hautement comprimée ou chargées dans un stockage de données séparé. L'avantage par rapport au partitionnement est que le système contient moins de ballast, car les anciennes données représentent une partie moins importante du système.

Conclusion

Comme nous l'avons vu, les systèmes BW se distinguent dans une large mesure. Les performances, en particulier, peuvent rapidement engendrer des frustrations du côté des utilisateurs dans les systèmes moyens ou inférieurs à la moyenne.

Hana n'apporte qu'une aide limitée dans ce domaine : Un changement de technologie ne permet pas d'améliorer un mauvais modèle de données. Il existe différentes possibilités pour remettre le système à niveau. Une analyse détaillée du système BW est la meilleure façon de commencer à trouver les bons points de départ.

Le test d'aptitude SAP BW de DataVard offre, outre une analyse de l'état actuel, un benchmarking avec plus de 100 systèmes BW productifs. Il est ainsi possible de voir en un coup d'œil dans quels domaines le propre Business Warehouse possède des potentiels d'amélioration.