Comment automatiser avec Jenkins la création et le roulement d'artefacts d'artefacts de modèle de métadonnées pour les tables du référentiel

Tout a commencé avec le fait que nous étions confrontés à la nécessité de former rapidement et correctement les structures EDWEX, JSON, DDL, puis de les déployer sur différents contours de bases de données relationnelles. Par contours, je veux dire des abréviations que tout le monde connaît - DEV, TST, UAT, PRD.



À cette époque, nous faisions presque tout manuellement: nous avons généré DDL et collecté edwex et json en fonction des métadonnées de la base de données Oracle. Il existe de nombreux paramètres d'entrée. Si vous en manquez, vous formerez une entité incorrectement. Et comme tout le processus de formation était cohérent et continu, l'erreur ne sera détectée qu'à la toute fin. À propos de la façon dont nous avons tous automatisé et surmonté les erreurs, lisez sous la coupe.

Un peu sur l'infrastructure

Avant de remplir les données dans les tableaux des bases de données relationnelles, nous devons les accepter de la source - dans n'importe quel format, par exemple, dans Excel. Les données de la source utilisant le mécanisme interne sont transportées vers Hadoop (Data Lake). Hive a installé le module complémentaire Hive - avec son aide, nous pouvons afficher le contenu des fichiers en utilisant une syntaxe de type SQL.

Pour transférer les données dans Data Lake sous forme de tableaux, nous avons besoin de json, qui sont formés sur la base de métadonnées. Pour analyser les données au format Excel, nous devons créer des fichiers EDWEX. Les fichiers EDWEX (EDW_EXTRACTOR) sont un ensemble d'artefacts qui contiennent des ensembles de tables avec le nom, ainsi que des ensembles de champs pour chacune de ces tables, qui sont formés sur la base de métadonnées. En fonction de la version du modèle et de l'ID source, l'ensemble de champs varie. La formation de DDL est nécessaire pour créer les tables elles-mêmes dans la base de données Hive au niveau des données opérationnelles et dans la base de données Greenplum au niveau des données détaillées et agrégées. Autrement dit, les données sont principalement transférées vers Hive, si nécessaire, filtrées et transférées vers Greenplum pour une manipulation ultérieure des données et la création de vitrines basées sur celle-ci.

Comment automatiser

Pour résoudre le problème, nous avons utilisé:

• Jenkins - en tant qu'orchestre et outil de mise en œuvre du processus CI.
  
• Python - il implémente des fonctionnalités et des tests unitaires.
  
• SQL - pour accéder à la base de données de métadonnées.
  
• Script shell - pour copier des artefacts entre des répertoires et créer des scripts dans des projets multi-tâches exécutés sur le serveur Jenkins.
  

Pour commencer, nous travaillons initialement avec un grand nombre de sources.Par conséquent, en utilisant le script Shell comme paramètre de démarrage, nous transmettons les ID des sources aux fonctions SQL pour les identifier. Les fonctions SQL résultantes seront ensuite exécutées automatiquement dans la base de données de métadonnées. Sur la base des métadonnées disponibles, ces fonctions forment un fichier avec une liste de nouvelles fonctions SQL pour chacune des tables source afin que nous puissions les appeler ultérieurement dans le programme exécutable. Le résultat de l'exécution des fonctions générées est le transfert des valeurs DDL, JSON ou EDWEX au paramètre de sortie.

C'est là que Python se connecte, avec toutes les fonctionnalités exécutables et les tests unitaires écrits. Avant de démarrer l'un des modules de roulement des artefacts à l'aide de tests unitaires, le transfert de paramètres correct est vérifié pour exécuter des scripts python. Les tests vérifient non seulement l'exactitude des paramètres d'entrée, mais également leur présence dans le module de métadonnées, les tailles des fichiers créés et les dates de leur création. Les tests contrôlent également le nombre de nouveaux artefacts créés et le nombre d'artefacts existants. Nous optimisons donc l'utilisation des ressources du serveur, car nous ne prenons que les nouveaux fichiers à déplacer et ne réinstallons pas les modèles existants.

Et ce n'est qu'après avoir réussi toutes les vérifications qu'un programme python est exécuté qui crée les artefacts nécessaires et décompose le résultat dans les dossiers de projet nécessaires sur le serveur. Python dirige non seulement les fichiers json générés dans des répertoires, mais forme également des structures dans Data Lake afin que les données se chargent correctement. Lors de la génération d'artefacts DDL, ils sont non seulement enregistrés pour une analyse et une réutilisation ultérieures, mais peuvent également être immédiatement installés dans la base de données à l'aide de nouveaux modèles et structures spécifiés dans le module de métadonnées. Cela vous permet de créer des centaines de tables en peu de temps sans impliquer de travail manuel.

Et où est Jenkins ici?

Jenkins entre lorsqu'il est nécessaire de gérer visuellement tous ces processus à l'aide d'une interface.

Cet outil a été sélectionné car il:

• couvre entièrement les besoins d'automatisation de l'assemblage et de l'installation
  
• vous permet de concevoir un mécanisme d'assemblage d'artefacts avec la mise en œuvre du processus d'auto-test
  
• vous permet de gérer facilement les lancements de travaux et de surveiller l'exécution à une personne loin de la programmation
  
• vous permet de configurer le mécanisme de journalisation de manière à ce que le résultat de l'exécution soit compréhensible pour toute personne de l'équipe. Le problème dans l'assembly sera explicitement indiqué ou le processus se terminera avec succès.
  

Pour résoudre les tâches, nous avons créé plusieurs projets multi-tâches. Ce type de projet a été utilisé, car il peut fonctionner en parallèle avec d'autres travaux en un seul démarrage. Chacun des jobs est responsable de l'implémentation de son bloc de fonctionnalités. Nous avons donc remplacé le processus séquentiel d'obtention d'artefacts par des artefacts parallèles autonomes. Tout commence séparément: la formation d'EDWEX, JSON, DDL, la formation de la structure dans HIVE, l'installation des structures de table dans la base de données. Nous analysons le résultat à différentes étapes de la formation des artefacts et procédons au lancement des actions suivantes en cas de succès.

La partie Jenkins est implémentée sans trop de trucs. Les paramètres de chaîne ou d' exécution sont envoyés à l'entrée pour démarrer le code python. Le paramètre String est une fenêtre permettant de saisir une valeur de type str avant de démarrer. Le paramètre run peut être transféré à la volée vers un autre job pour exécution, il suffit pour cela d'indiquer de quel projet il est nécessaire de prendre la variable reçue. En outre, un nœud est transmis en tant que paramètre distinct pour l'exécution. Ici, le partitionnement en runtimes sur DEV, TST, UAT, PRD vient d'être implémenté. Un travail distinct a été utilisé pour transférer les fichiers EDWEX reçus vers SVN avec le numéro de révision afin de pouvoir suivre les versions des structures modifiées.

Un exemple d'interface dans Jenkins:



Le résultat de l'exécution du travail est la création et l'installation des artefacts nécessaires, leur transfert vers SVN et la formation d'un rapport HTML qui affiche le succès des tests unitaires réussis et les résultats de l'assemblage et de l'installation des artefacts. Les travaux peuvent être exécutés individuellement avec vos mains ou en mode automatique, après avoir préalablement construit une chaîne d'exécution.


Architecture du mécanisme d'assemblage et d'installation

Pour résumer

Beaucoup de travail a été fait pour automatiser la formation des artefacts. Auparavant, vous deviez monter manuellement sur le serveur, exécuter des scripts shell, puis étudier et modifier les données pendant longtemps avec vos mains. Maintenant, cliquez simplement sur le bouton Démarrer, spécifiez l'ID du système source, le numéro de modèle et la boucle d'exécution. Avec l'aide de Jenkins, il a été possible de structurer et de décomposer l'ensemble du mécanisme d'assemblage et d'installation des artefacts en étapes indépendantes. Les vérifications nécessaires ont été ajoutées avant de commencer la formation des artefacts et leur intégration. Les artefacts reçus sont automatiquement transférés vers SVN, ce qui simplifie le travail avec des équipes connexes d'analystes système et de modélisateurs de données. Des vérifications sont mises en œuvre pour éviter les lancements inactifs de la formation d'artefacts et confirmer leur exactitude.

En conséquence, nous avons réduit le processus fastidieux d'assemblage et d'installation des artefacts de modèle de plusieurs heures à quelques minutes. Et surtout, ils ont éliminé les erreurs dues au facteur humain, qui se sont inévitablement produites dans un processus de routine complexe.