Il y a environ 4 ans, nous avons déplacé notre système de reporting d'Oracle vers SAP Hana. Aujourd'hui, il stocke environ 10 000 tables, 38 000 personnes l'utilisent et plus de 5 000 processus de chargement se produisent quotidiennement. À l'heure actuelle, notre complexe, sur lequel le système fonctionne, se compose de 8 serveurs avec 14 To de mémoire. Chaque jour, le système de reporting traite 1,5 pb de données. Dans le même temps, Hana était environ 20 fois plus productif qu'Oracle, DB2 et MySQL. Et aujourd'hui, je veux dire comment, dans le cadre de l'intégration de M.Video et Eldorado, nous avons en outre augmenté les performances du système de reporting, optimisations que nous avons faites.
Charge
Aujourd'hui, sur plusieurs milliers de rapports créés par le système, seuls 10 génèrent 70% de la charge totale. Le rapport le plus lourd de la base de données Hana est la Revue hebdomadaire des entreprises. Il fonctionne pendant 30 minutes et consomme 4 To de mémoire. 90% de tous les rapports sont générés par le centre de contact: nous avons créé un service qui, lorsqu'un client appelle par son numéro de téléphone, ouvre automatiquement un rapport et montre à l'opérateur tout l'historique des achats de l'appelant et son interaction avec l'entreprise.
Modèle de données
Le modèle de données clé sur lequel la majeure partie des rapports est construite contient 1 500 tableaux. La plupart d'entre eux sont des tableaux de référence. En utilisant ce modèle, vous pouvez analyser n'importe quelle direction de l'entreprise. Un exemple est la visualisation d'un modèle de données créé à l'aide du concepteur d'univers. Certes, il ne reflète qu'un dixième de notre système.
Performances
Au moment de la fusion de M.Video et Eldorado, la quantité de données dans les deux systèmes de notification était d'environ 10 To: 7 To dans le système BW on HANA M.Video, 2 To dans le BW on HANA Eldorado et 1 TB données supplémentaires dans HADOOP (données historiques). Lors de la combinaison des systèmes, nous avions des limitations matérielles: le complexe M. Video était composé de 6 nœuds (2 To chacun), dont une sauvegarde. Ce système pourrait être étendu à un maximum de 8 nœuds, dont une sauvegarde.
En préparation de la fusion, nous avons supposé que le montant total de toutes les données atteindrait 13 To. Par conséquent, sur la base des recommandations SAP, nous avions besoin d'un système de 16 nœuds de 2 To chacun, dont deux nœuds de sauvegarde. De plus, un nœud devait être alloué en tant que nœud maître qui, avec un tel volume d'informations, prendrait en charge les fonctions de gestion. Autrement dit, pour un fonctionnement correct, il était nécessaire de déployer 13 nœuds.
Comme vous pouvez le voir, les ressources disponibles ne sont absolument pas suffisantes. Et c'était le premier défi.
La deuxième principale difficulté avant la fusion était que la vitesse du système ne satisfaisait souvent pas aux besoins de l'entreprise. La raison principale était le grand nombre d'appels simultanés à la base de données. Du point de vue du système, il ressemblait à une boule de neige, ce qui pouvait entraîner soit le gel et l'interruption d'une partie des processus, soit même des décharges globales de «mémoire insuffisante» sur les nœuds.
Il était clair que sans modifications importantes, une double augmentation de la quantité de données dans les rapports (pour deux marques) conduirait à une double aggravation de la situation.
Par conséquent, nous avons décidé d'optimiser le système dans les domaines suivants:
- Rapports Accélération des rapports les plus critiques et les plus gourmands en ressources et révision du modèle de données.
- Dépôt . Archivage et optimisation du stockage.
- Téléchargements . Rationalisez la procédure et modifiez le calendrier de téléchargement.
L'approche générale de l'optimisation était la suivante:
Tout d'abord, nous avons effectué une analyse dans toutes les directions, identifié les causes des problèmes, puis analysé les capacités du système avec les ressources nécessaires. Nous avons également immédiatement essayé d'automatiser autant que possible ce processus afin qu'à l'avenir nous puissions rapidement identifier les causes des problèmes et restaurer rapidement les performances.
Qu'avons-nous fait:
- Modification de la configuration des serveurs d'applications ABAP: nombre d'instances, utilisation efficace de la technologie NUMA et nombre optimal de workflows.
- Nous avons appliqué les paramètres optimaux de HANA et du système d'exploitation Linux.
- Nous avons analysé la diminution de la consommation CPU.
- Nous avons analysé la consommation de RAM dans tout l'intervalle de temps observé.
- Nous avons analysé la présence de MOO sur HANA.
- Nous avons analysé l'occurrence de verrous dans le système et la disponibilité des ressources système pour les opérations d'attente (wait).
- Nous avons analysé l'équilibrage des données en tenant compte de la redistribution et de la répartition des données pour la solution SCALE-OUT HANA.
- Nous avons analysé les causes des vidages ABAP qui affectent le fonctionnement des chaînes critiques.
Sur la base des résultats, des rapports de performance ont été compilés, ainsi que des instructions afin qu'à l'avenir il soit possible de déterminer indépendamment les goulots d'étranglement dans le système et les intervalles de temps de pointe.
Quels résultats ont été obtenus:
Un certain nombre de rapports optimisés SAP BO ont commencé à fonctionner
plusieurs fois plus rapidement et à consommer des
centaines de fois moins de mémoire .
Voici quelques exemples frappants de la façon dont le système ne remplit pas correctement les conditions de sélection, et comment créer correctement des requêtes dans HANA.
Des problèmes ont été révélés lors du filtrage par des objets non matérialisés, en particulier (!) Lors de l'utilisation des indicateurs
COUNT DISTINCT (un CD peut être écrit à la fois au niveau de l'Univers et dans une fonction en CV).
Même si vous excluez le CD de la requête, la première option fonctionnera toujours 20 fois plus lentement que la seconde, et avec un CD, la vitesse est plus de 500 fois supérieure.
Un cas particulier d'utilisation d'objets non matérialisés dans les filtres: filtres composites de deux ou plusieurs objets, par exemple, collage d'une semaine et d'un an:
Les requêtes avec des filtres collés ne fonctionnent pas aussi lentement que la conversion en date, mais elles ralentissent toujours les requêtes (environ 2-3 fois).
Pour collecter des statistiques sur le fonctionnement du système de reporting, les processus de chargement et les chaînes, nous avons développé le schéma suivant:
Dans le même temps, nous avons ajouté un commentaire spécial aux rapports avec le nom du rapport. Ainsi, nous pouvons comparer la charge de différentes parties du système et comparer la période à la période.
Plans
Nous avons de nombreux plans pour le développement de fonctionnalités commerciales et une révision substantielle de l'outil de visualisation des données. La tendance mondiale à laquelle nous participons activement est d'intégrer le système de reporting dans le paradigme de la transformation numérique.
Que voulez-vous dire?
Lorsque notre système de reporting était jeune, les utilisateurs nous adressaient souvent des demandes similaires: «Automatisez la construction d'un rapport qui montre le bénéfice net qu'un magasin particulier ou toute l'entreprise a reçu.»
Ensuite, ils ont commencé à nous soumettre des demandes pour trouver un algorithme qui permettrait de construire un plan ou de prévoir un bénéfice net, en fonction de facteurs spécifiques.
Et aujourd'hui, nous sommes arrivés à la conclusion que les utilisateurs veulent connaître les prévisions précises du bénéfice net. Nous avons toutes les données nécessaires pour le développement d'algorithmes de prévision, et il existe des spécialistes de l'analyse des données qui peuvent créer des modèles d'apprentissage automatique. Comme vous le savez, cela nécessite de très grandes quantités de données, donc l'une des principales tendances dans le développement de notre système de reporting est la transition vers l'analyse et la création de modèles basés sur le big data.
Quelques mots sur notre équipe
Aujourd'hui, les grandes entreprises introduisent de plus en plus de systèmes de prévision basés sur des algorithmes d'apprentissage automatique développés par le système lui-même. Il y a deux ans, nous avons créé un centre de compétences dans le domaine de l'analyse des données du Digital Retail Data Science Center, et cette année nous avons un groupe d'ingénieurs de données. Nous introduisons un nouveau système de traitement et d'analyse des mégadonnées. Et nous avons besoin de personnes dans l'équipe des départements de support, de développement et d'analyse des données appliquées.
Si vous vous intéressez à ces domaines, si vous sentez la force en vous - bienvenue! Vous trouverez un travail intéressant et difficile, parfois stressant, mais toujours créatif.
