Des accidents quotidiens à la stabilité: Informatica avec 10 yeux d'administrateur

Le composant ETL de l'entrepôt de données est souvent dans l'ombre de l'entrepôt lui-même et moins d'attention y est accordée que la base de données principale ou le composant frontal, BI, de génération de rapports. Dans le même temps, du point de vue des mécanismes de remplissage de l'entrepôt de données, ETL joue un rôle clé et ne requiert pas moins d'attention de la part des administrateurs que les autres composants. Je m'appelle Alexander, j'administre actuellement des ETL à Rostelecom, et dans cet article, je vais essayer de partager avec l'administrateur l'administrateur de l'un des systèmes ETL les plus célèbres d'un grand entrepôt de données de Rostelecom.

Si vos chers lecteurs connaissent déjà notre projet d'entrepôt de données et le produit Informatica PowerCenter en général, vous pouvez passer à la section suivante.

Il y a quelques années, l'idée d'un seul entrepôt de données d'entreprise a mûri et a commencé à être mise en œuvre à Rostelecom. Un certain nombre de stockages permettant de résoudre des tâches individuelles avaient déjà été créés, mais le nombre de scénarios augmentait, les coûts de support augmentaient également et il devenait clair que l'avenir était centralisé. Sur le plan architectural, il s'agit du référentiel lui-même, composé de plusieurs couches, implémenté sur Hadoop et GreenPlum, des bases de données auxiliaires, des mécanismes ETL et BI.

Dans le même temps, en raison du grand nombre de sources de données hétérogènes géographiquement réparties, un mécanisme spécial de téléchargement de données a été créé, dont le travail est contrôlé par Informatica. En conséquence, les paquets de données se retrouvent dans la zone frontale Hadoop, après quoi le processus de chargement des données via les couches de stockage, dans Hadoop et GreenPlum, commence et ils sont contrôlés par le soi-disant mécanisme de contrôle ETL implémenté dans Informatica. Ainsi, le système Informatica est l'un des éléments clés qui assurent l'opération de stockage.

Plus de détails sur notre stockage seront discutés dans l'un des articles suivants.

Informatica PowerCenter / Big Data Management est actuellement considéré comme le logiciel leader dans le domaine des outils d'intégration de données. Il s'agit d'un produit de la société américaine Informatica, qui est l'un des acteurs les plus puissants en ETL (Extract Transform Load), en gestion de la qualité des données, en MDM (Master Data Management), en ILM (Information Lifecycle Management) et plus encore.

Le PowerCenter que nous utilisons est un serveur d'applications Tomcat intégré, dans lequel les applications Informatica elles-mêmes fonctionnent, mettant en œuvre ses services:

Le domaine , en fait, est la base de tout le reste; au sein du domaine, les services, les utilisateurs et les composants GRID fonctionnent.

Administrator Console , un outil de gestion et de surveillance basé sur le Web, en plus du client Informatica Developer, le principal outil d'interaction avec le produit

MRS, Model Repository Service , un référentiel de métadonnées, est une couche entre la base de données dans laquelle les métadonnées sont stockées physiquement et le client Informatica Developer dans lequel elles sont développées. Les référentiels stockent à la fois une description des données et d'autres informations, y compris pour un certain nombre d'autres services Infromatica, par exemple, des calendriers de lancement de tâches ou de surveillance de données, ainsi que des paramètres d'application, en particulier, permettant d'utiliser la même application pour le travail avec diverses sources de données et récepteurs.

DIS, Data Integration Service , est un service dans lequel les principaux processus fonctionnels ont lieu, les applications y travaillent et les lancements réels des workflows (descriptions de la séquence des mappages et de leur interaction) et des mappages (transformations, blocs dans lesquels les transformations elles-mêmes se produisent, traitement des données) se produisent.

La configuration GRID est, en fait, une option pour construire un complexe en utilisant plusieurs serveurs, lorsque la charge lancée par DIS est répartie entre les nœuds (c'est-à-dire les serveurs qui font partie du domaine). Dans le cas de cette option, en plus de répartir la charge sur DIS via une couche d'abstraction GRID supplémentaire, combinant plusieurs nœuds, sur lesquels DIS fonctionne au lieu de travailler sur un seul nœud spécifique, des instances MRS de sauvegarde supplémentaires peuvent également être créées. Vous pouvez même implémenter la haute disponibilité lorsque des appels externes peuvent être effectués via des nœuds de sauvegarde en cas de défaillance principale. Nous avons jusqu'à présent refusé une telle option de construction.


Informatica PowerCenter, schéma

Aux premières étapes du travail, des problèmes sont régulièrement apparus dans la chaîne d'approvisionnement des données, certains en raison du travail instable d'Informatica à l'époque. Je vais partager certains des moments mémorables de cette saga - le développement d'Informatica 10.


Ancien logo Informatica

D'autres environnements Informatica font également partie de notre domaine de responsabilité, ils ont leurs propres spécificités en raison d'une charge différente, mais pour l'instant je vais rappeler exactement comment Informatica s'est développé en tant que composant ETL de l'entrepôt de données lui-même.

Comment est-ce arrivé

En 2016, lorsque nous sommes devenus responsables d'Informatica, il atteignait déjà la version 10.0, et pour les collègues optimistes qui ont décidé d'utiliser un produit avec une version mineure .0 dans une solution sérieuse, tout semblait évident - vous devez utiliser la nouvelle version! Du point de vue des ressources matérielles, tout était excellent à l'époque.

Depuis le printemps 2016, l'entrepreneur était responsable des travaux d'Informatica et, selon les quelques utilisateurs du système, «cela fonctionnait deux fois par semaine». Ici, il est nécessaire d'expliquer que le stockage était de facto au stade PoC, il n'y avait pas d'administrateur dans l'équipe et le système s'est constamment écrasé pour diverses raisons, après quoi l'ingénieur entrepreneur l'a soulevé à nouveau.

À l'automne, trois administrateurs sont apparus dans l'équipe, partageant leurs responsabilités et ont commencé à aligner le travail normal sur les systèmes d'exploitation du projet, y compris Informatica. Séparément, il faut dire que ce produit n'est pas répandu et a une grande communauté dans laquelle vous pouvez trouver la réponse à toutes les questions et résoudre tout problème. Par conséquent, le soutien technique à part entière du partenaire russe Informatica était très important, avec l'aide duquel toutes nos erreurs et les erreurs du jeune Informatca 10 ont été corrigées.

La première chose que nous avons dû faire pour les développeurs de notre équipe et de notre sous-traitant a été de stabiliser le travail d'Informatica lui-même, afin de rendre la console d'administration Web (Informatica Administrator) opérationnelle.


Nous avons donc souvent rencontré des développeurs Informatica

Laissant de côté le processus de recherche des causes, la principale raison des plantages était l'interaction entre le logiciel Informatica et la base de données du référentiel située sur un serveur relativement distant en termes de paysage réseau. Cela a entraîné des retards et perturbé les mécanismes de surveillance de l'état du domaine Informatica. Après quelques ajustements de la base de données, la modification des paramètres Informatica, qui la rendait plus tolérante aux retards de base de données, et à la suite de la mise à jour de la version d'Informatica vers 10.1 et du transfert de la base de données du serveur précédent vers le serveur situé plus près d'Informatica, le problème a perdu de sa pertinence et depuis lors, ce type de plantages nous n'observons pas.


L'une des tentatives pour faire fonctionner Informatica Monitor

Avec la console d'administration, la situation était également critique. Comme il y avait un développement actif dans un environnement conditionnellement productif, les collègues avaient constamment besoin d'analyser le travail de cartographie, le flux de travail «en déplacement». Dans la nouvelle Informatica, le service d'intégration de données ne dispose pas d'un outil distinct pour une telle surveillance, mais la section de surveillance (Informatica Administrator Monitor) est apparue dans la console Web d'administration, dans laquelle vous pouvez observer le fonctionnement des applications, le flux de travail et les mappages, les démarrages, les journaux. Périodiquement, la console est devenue complètement indisponible, ou les informations sur les processus en cours dans DIS ont cessé d'être mises à jour, ou des erreurs se sont produites lors du chargement des pages.


Sélection de paramètres java pour stabiliser le travail

Le problème a été résolu de plusieurs façons, des expériences ont été menées pour modifier les paramètres, des journaux ont été collectés, jstack a été envoyé à l'appui, la recherche active sur Google se déroulait en même temps et l'observation venait d'être menée.

Tout d'abord, un MRS distinct a été créé pour la surveillance, car il s'est avéré plus tard être l'un des principaux consommateurs de ressources dans nos environnements, car les mappages sont lancés de manière très intensive. Les paramètres concernant java heap et un certain nombre d'autres ont été modifiés.
En conséquence, la prochaine mise à jour d'Informatica 10.1.1 a réussi à stabiliser la console et le moniteur, les développeurs ont commencé à travailler plus efficacement et les processus réguliers sont devenus plus réguliers.

L'expérience de l'interaction entre le développement et l'administration peut être intéressante. La question d'une compréhension commune du fonctionnement de tout, de ce qui peut et ne peut pas être fait, est toujours importante lors de l'utilisation de systèmes complexes. Par conséquent, nous pouvons vous recommander en toute sécurité de former d'abord l'équipe d'administration sur la façon d'administrer le logiciel et l'équipe de développement sur la façon d'écrire du code et de dessiner des processus dans le système, puis d'envoyer les premier et second pour travailler sur le résultat. C'est vraiment important lorsque le temps n'est pas une ressource sans fin. De nombreux problèmes peuvent être résolus même par une énumération aléatoire des options, mais parfois certains nécessitent une connaissance a priori - notre cas confirme l'importance de comprendre cet axiome.

Par exemple, lorsque nous avons essayé d'inclure la gestion des versions dans MRS (il s'est avéré que nous avions besoin d'une version différente de SVN), après un certain temps, nous étions impatients de constater que le temps de redémarrage du système était passé à plusieurs dizaines de minutes. S'agissant de la cause du démarrage différé et de la désactivation du contrôle de version, ils se sont à nouveau bien comportés.

Parmi les obstacles notables associés à Informatica, on peut rappeler la bataille épique avec les flux java croissants. À un moment donné, le moment est venu de répliquer, c'est-à-dire d'étendre les processus établis à un grand nombre de systèmes sources. Il s'est avéré que tous les processus de 10.1.1 ne fonctionnaient pas bien et après un certain temps, DIS est devenu inopérant. Des dizaines de milliers de threads ont été détectés, leur nombre a augmenté de manière notable au cours de la procédure de déploiement de l'application. Parfois, il était nécessaire de redémarrer plusieurs fois par jour pour restaurer les performances.

Ici, vous devez remercier le support, les problèmes ont été localisés et résolus assez rapidement à l'aide d'EBF (Emergency Bug Fix) - après quoi tout le monde a eu le sentiment que l'outil fonctionnait vraiment.

Ça marche toujours!

Lorsque le travail a commencé en mode cible, Informatica se présente comme suit. Informatica version 10.1.1HF1 (HF1 est HotFix1, un assemblage de fournisseur à partir d'un ensemble d'EBF) avec des EBF supplémentaires installés qui résolvent nos problèmes de mise à l'échelle et d'autres, sur l'un des trois serveurs GRID, 20 cœurs x86_64 et stockage, sur un énorme réseau lent de disques locaux - c'est la configuration du serveur pour le cluster Hadoop. Sur un autre serveur du même type, le SGBD Oracle avec lequel le domaine Informatica et le mécanisme de contrôle ETL fonctionnent. Tout cela est contrôlé par les outils de surveillance standard utilisés dans l'équipe (Zabbix + Grafana), des deux côtés - Informatica lui-même avec ses services, et les processus de chargement qui y sont associés. Désormais, les performances et la stabilité, sans tenir compte des facteurs externes, dépendent désormais des paramètres qui limitent la charge.

Séparément, nous pouvons parler de GRID. L'environnement a été construit sur trois nœuds, avec possibilité d'équilibrage de charge. Cependant, lors des tests, il a été constaté qu'en raison de problèmes d'interaction entre les instances en cours d'exécution de nos applications, cette configuration ne fonctionnait pas comme prévu, et a temporairement décidé d'abandonner ce schéma de construction en supprimant deux des trois nœuds du domaine. Dans le même temps, le schéma lui-même est resté le même, et maintenant c'est un service GRID, mais dégénéré en un nœud.

À l'heure actuelle, il reste la complexité associée à une baisse des performances lors du nettoyage régulier du circuit du moniteur - avec des processus simultanés dans le CNN et un nettoyage en cours, des dysfonctionnements dans le fonctionnement du mécanisme de contrôle ETL peuvent se produire. Ce problème est résolu jusqu'à présent par une «béquille» - nettoyage manuel du circuit du moniteur, avec la perte de toutes ses données précédentes. Ce n'est pas trop critique pour le produit, avec un travail à temps plein normal, mais jusqu'à présent, la recherche d'une solution normale est en cours.

Un autre problème provient de la même situation - parfois plusieurs lancements de notre mécanisme de contrôle se produisent.


Lancement de plusieurs applications, entraînant une panne du mécanisme

Lors du démarrage selon un calendrier en cas de forte charge sur le système, des situations qui conduisent à une panne du mécanisme se produisent parfois. Jusqu'à présent, le problème a été résolu manuellement et une solution permanente est recherchée.

En général, on peut résumer que sous une charge élevée, il est très important de fournir des ressources adéquates, cela s'applique également aux ressources matérielles pour Informatica lui-même, et de même pour son référentiel de base de données, ainsi que pour garantir des paramètres optimaux pour eux. En outre, la question reste de savoir quelle disposition de la base de données est la meilleure - sur un hôte séparé ou sur le même où le logiciel Informatica fonctionne. D'une part, il sera moins cher sur un serveur, et lorsqu'il est combiné, un problème possible d'interaction réseau est pratiquement éliminé, d'autre part, la charge sur l'hôte de la base de données est complétée par la charge d'Informatica.

Comme pour tout produit sérieux, Informatica connaît des moments curieux.
Une fois, analysant une sorte d'accident, j'ai remarqué que l'heure des événements était étrangement marquée dans les journaux MRS.


Dualisme temporaire dans les journaux MRS «par conception»

Il s'est avéré que les horodatages sont écrits au format 12 heures, sans spécifier AM / PM, c'est-à-dire avant midi ou après. Une candidature a même été ouverte à ce sujet, et une réponse officielle a été reçue - il en était ainsi prévu, les notes dans le journal MRS sont écrites dans ce format. Autrement dit, il reste parfois une certaine intrigue concernant le moment de l'apparition d'une erreur ...

Cherchez le meilleur

Aujourd'hui, Informatica est un outil assez stable, pratique pour l'administrateur et les utilisateurs, extrêmement puissant en termes de capacités et de potentiel actuels. Il dépasse de nombreuses fois fonctionnellement nos besoins et est de facto maintenant utilisé dans le projet d'une manière peu caractéristique et typique. Une partie de la difficulté réside dans le fonctionnement des mécanismes - la spécificité est qu'un grand nombre de threads sont lancés dans un court laps de temps, qui mettent à jour intensivement les paramètres et fonctionnent avec la base de données du référentiel, tandis que les ressources matérielles du serveur sont presque entièrement utilisées par le CPU.

Nous sommes maintenant sur le point de passer à Informatica 10.2.1 ou 10.2.2, dans lequel certains mécanismes internes ont été repensés, et le support promet l'absence d'un certain nombre de problèmes actuels de performances et de fonctionnement. Et d'un point de vue matériel, les serveurs devraient être optimaux pour nous, étant donné la marge pour l'avenir proche en raison de la croissance et du développement du stockage.

Bien sûr, les tests, les tests de compatibilité et éventuellement les modifications architecturales de la partie HA GRID sont à venir. Le développement au sein d'Informatica va se poursuivre, car à court terme nous ne pouvons rien mettre pour remplacer le système.
Et ceux qui continueront d'être responsables de ce système pourront certainement l'amener aux indicateurs de fiabilité et de performance requis proposés par les clients.

Cet article a été préparé par l'équipe de gestion des données de Rostelecom


Logo Informatica actuel