Testeur de big et small data : tendances, théorie, mon histoire

Bonjour à tous, je m'appelle Alexander et je suis un ingénieur Data Quality qui vérifie la qualité des données. Cet article expliquera comment j'en suis arrivé là et pourquoi en 2020, ce domaine de tests était au sommet d'une vague.

Testeur de big et small data : tendances, théorie, mon histoire

Tendance mondiale

Le monde d'aujourd'hui connaît une autre révolution technologique, dont l'un des aspects est l'utilisation des données accumulées par toutes sortes d'entreprises pour promouvoir leur propre volant de ventes, de bénéfices et de relations publiques. Il semble que la présence de données (de qualité) de bonne qualité, ainsi que de cerveaux qualifiés capables d'en tirer profit (traiter correctement, visualiser, créer des modèles d'apprentissage automatique, etc.), soient devenues la clé du succès pour beaucoup aujourd'hui. S'il y a 15 à 20 ans, les grandes entreprises étaient principalement impliquées dans un travail intensif d'accumulation et de monétisation de données, c'est aujourd'hui le lot de presque toutes les personnes sensées.

À cet égard, il y a plusieurs années, tous les portails dédiés à la recherche d'emploi dans le monde ont commencé à être remplis de postes vacants pour Data Scientists, car tout le monde était sûr qu'en embauchant un tel spécialiste, il serait possible de construire un modèle d'apprentissage automatique. , prédire l'avenir et réaliser un « bond quantique » pour l'entreprise. Au fil du temps, les gens ont réalisé que cette approche ne fonctionne presque jamais, car toutes les données qui tombent entre les mains de ces spécialistes ne conviennent pas à la formation de modèles.

Et les demandes des Data Scientists ont commencé : « Achetons plus de données de ceux-ci et de ceux-là… », « Nous n'avons pas assez de données... », « Nous avons besoin de plus de données, de préférence de haute qualité... » . Sur la base de ces demandes, de nombreuses interactions ont commencé à se construire entre les entreprises propriétaires de l'un ou l'autre ensemble de données. Naturellement, cela nécessitait l'organisation technique de ce processus - se connecter à la source de données, la télécharger, vérifier qu'elle était entièrement chargée, etc. Le nombre de ces processus a commencé à croître et nous avons aujourd'hui un énorme besoin d'un autre type de spécialistes - Ingénieurs Data Quality - ceux qui surveilleraient le flux de données dans le système (pipelines de données), la qualité des données à l'entrée et à la sortie, et tireraient des conclusions sur leur suffisance, leur intégrité et d'autres caractéristiques.

La tendance des ingénieurs Data Quality nous est venue des États-Unis, où, en pleine ère de capitalisme, personne n’est prêt à perdre la bataille des données. Ci-dessous, j'ai fourni des captures d'écran de deux des sites de recherche d'emploi les plus populaires aux États-Unis : www.monstre.com и www.dice.com — qui affiche les données au 17 mars 2020 sur le nombre de postes vacants affichés reçus en utilisant les mots-clés : Data Quality et Data Scientist.

www.monstre.com

Data Scientists – 21416 postes vacants
Qualité des données – 41104 XNUMX postes vacants

Testeur de big et small data : tendances, théorie, mon histoire
Testeur de big et small data : tendances, théorie, mon histoire

www.dice.com

Data Scientists – 404 postes vacants
Qualité des données – Postes vacants 2020

Testeur de big et small data : tendances, théorie, mon histoire
Testeur de big et small data : tendances, théorie, mon histoire

Bien évidemment, ces métiers ne se font en aucun cas concurrence. Avec des captures d'écran, je voulais juste illustrer la situation actuelle sur le marché du travail en termes de demandes d'ingénieurs Data Quality, dont on a désormais bien plus besoin que les Data Scientists.

En juin 2019, EPAM, répondant aux besoins du marché informatique moderne, a séparé la qualité des données en une pratique distincte. Les ingénieurs Data Quality, dans le cadre de leur travail quotidien, gèrent les données, vérifient leur comportement dans de nouvelles conditions et systèmes, surveillent la pertinence des données, leur suffisance et leur pertinence. Avec tout cela, d'un point de vue pratique, les ingénieurs Data Quality consacrent vraiment peu de temps aux tests fonctionnels classiques, MAIS cela dépend grandement du projet (je vais donner un exemple ci-dessous).

Les responsabilités d'un ingénieur Data Quality ne se limitent pas uniquement aux vérifications manuelles/automatiques de routine des « valeurs nulles, comptes et sommes » dans les tables de la base de données, mais nécessitent une compréhension approfondie des besoins commerciaux du client et, par conséquent, la capacité de transformer les données disponibles en informations commerciales utiles.

Théorie de la qualité des données

Testeur de big et small data : tendances, théorie, mon histoire

Afin d’imaginer plus pleinement le rôle d’un tel ingénieur, voyons ce qu’est en théorie la qualité des données.

Qualité des données — une des étapes du Data Management (tout un monde que nous vous laisserons étudier par vous-même) et se charge d'analyser les données selon les critères suivants :

Testeur de big et small data : tendances, théorie, mon histoire
Je pense qu'il n'est pas nécessaire de déchiffrer chacun des points (en théorie on les appelle « dimensions des données »), ils sont assez bien décrits dans l'image. Mais le processus de test lui-même n'implique pas strictement de copier ces fonctionnalités dans des cas de test et de les vérifier. En matière de qualité des données, comme dans tout autre type de test, il est nécessaire avant tout de s'appuyer sur les exigences de qualité des données convenues avec les participants au projet qui prennent les décisions commerciales.

En fonction du projet Data Quality, un ingénieur peut remplir différentes fonctions : d'un simple testeur d'automatisation avec une évaluation superficielle de la qualité des données, à une personne qui effectue un profilage approfondi des données selon les critères ci-dessus.

Une description très détaillée de la gestion des données, de la qualité des données et des processus associés est bien décrite dans le livre intitulé "DAMA-DMBOK : corpus de connaissances en gestion de données : 2e édition". Je recommande vivement ce livre comme introduction à ce sujet (vous trouverez un lien vers celui-ci à la fin de l'article).

Mon histoire

Dans l'industrie informatique, j'ai progressé depuis un testeur junior dans des entreprises de produits jusqu'à un ingénieur principal de la qualité des données chez EPAM. Après environ deux ans de travail en tant que testeur, j'avais la ferme conviction d'avoir réalisé absolument tous les types de tests : régression, fonctionnel, stress, stabilité, sécurité, UI, etc. - et essayé un grand nombre d'outils de tests, ayant travaillé simultanément dans trois langages de programmation : Java, Scala, Python.

Avec le recul, je comprends pourquoi mes compétences étaient si diversifiées : j'ai été impliqué dans des projets basés sur les données, petits et grands. C’est ce qui m’a amené dans un monde doté de nombreux outils et opportunités de croissance.

Pour apprécier la variété d'outils et d'opportunités d'acquérir de nouvelles connaissances et compétences, il suffit de regarder l'image ci-dessous, qui montre les plus populaires dans le monde « Data & AI ».

Testeur de big et small data : tendances, théorie, mon histoire
Ce type d'illustration est compilé chaque année par l'un des célèbres investisseurs en capital-risque, Matt Turck, issu du développement de logiciels. Ici lien sur son blog et société de capital risque, où il travaille en tant qu'associé.

J'ai grandi professionnellement particulièrement rapidement lorsque j'étais le seul testeur sur le projet, ou du moins au début du projet. C'est à ce moment-là que vous devez être responsable de l'ensemble du processus de test, et vous n'avez aucune possibilité de reculer, seulement d'avancer. Au début, ça faisait peur, mais maintenant tous les avantages d'un tel test me sont évidents :

  • Vous commencez à communiquer avec toute l'équipe comme jamais auparavant, puisqu'il n'y a pas d'intermédiaire pour la communication : ni le responsable des tests ni les autres testeurs.
  • L'immersion dans le projet devient incroyablement profonde et vous disposez d'informations sur tous les composants, tant en général que en détail.
  • Les développeurs ne vous considèrent pas comme « ce gars des tests qui ne sait pas ce qu'il fait », mais plutôt comme un égal qui produit des bénéfices incroyables pour l'équipe avec ses tests automatisés et son anticipation des bugs apparaissant dans un composant spécifique du logiciel. produit.
  • En conséquence, vous êtes plus efficace, plus qualifié et plus demandé.

Au fur et à mesure que le projet grandissait, dans 100% des cas je suis devenu le mentor des nouveaux testeurs, leur enseignant et leur transmettant les connaissances que j'avais moi-même apprises. Dans le même temps, selon le projet, je n'ai pas toujours reçu de la direction le plus haut niveau de spécialistes des tests automatiques et il fallait soit les former à l'automatisation (pour les personnes intéressées), soit créer des outils à utiliser dans les activités quotidiennes (outils pour générer des données et les charger dans le système, un outil pour effectuer des tests de charge/de stabilité « rapidement », etc.).

Exemple de projet spécifique

Malheureusement, en raison d'obligations de non-divulgation, je ne peux pas parler en détail des projets sur lesquels j'ai travaillé, mais je vais donner des exemples de tâches typiques d'un Data Quality Engineer sur l'un des projets.

L'essence du projet est de mettre en œuvre une plate-forme de préparation de données pour la formation de modèles d'apprentissage automatique basés sur celles-ci. Le client était une grande entreprise pharmaceutique américaine. Techniquement, c'était un cluster Kubernetes, s'élevant à AWS EC2 instances, avec plusieurs microservices et le projet Open Source sous-jacent d'EPAM - Légion, adapté aux besoins d'un client spécifique (maintenant le projet renaît en odahu). Les processus ETL ont été organisés en utilisant Flux d'air Apache et déplacé les données de SalesForce systèmes clients dans AWS S3 Seaux. Ensuite, une image Docker d'un modèle d'apprentissage automatique a été déployée sur la plate-forme, qui a été formée sur de nouvelles données et, à l'aide de l'interface API REST, a produit des prédictions intéressantes pour l'entreprise et a résolu des problèmes spécifiques.

Visuellement, tout ressemblait à ceci :

Testeur de big et small data : tendances, théorie, mon histoire
Il y a eu de nombreux tests fonctionnels sur ce projet, et compte tenu de la rapidité de développement des fonctionnalités et de la nécessité de maintenir le rythme du cycle de publication (sprints de deux semaines), il a fallu immédiatement penser à automatiser les tests des composants les plus critiques de le système. La majeure partie de la plate-forme basée sur Kubernetes elle-même était couverte par des autotests implémentés dans Cadre de robot + Python, mais il fallait aussi les supporter et les étendre. De plus, pour la commodité du client, une interface graphique a été créée pour gérer les modèles d'apprentissage automatique déployés sur le cluster, ainsi que pour la possibilité de spécifier où et où les données doivent être transférées pour entraîner les modèles. Cet ajout important impliquait une expansion des tests fonctionnels automatisés, qui étaient principalement effectués via des appels d'API REST et un petit nombre de tests d'interface utilisateur de bout en bout. A peu près à l'équateur de tout ce mouvement, nous avons été rejoints par un testeur manuel qui a fait un excellent travail en testant l'acceptation des versions du produit et en communiquant avec le client concernant l'acceptation de la prochaine version. De plus, grâce à l'arrivée d'un nouveau spécialiste, nous avons pu documenter notre travail et ajouter plusieurs contrôles manuels très importants et difficiles à automatiser dans l'immédiat.

Et enfin, après avoir atteint la stabilité de la plate-forme et du module complémentaire GUI, nous avons commencé à créer des pipelines ETL à l'aide des DAG Apache Airflow. Le contrôle automatisé de la qualité des données a été effectué en écrivant des DAG Airflow spéciaux qui vérifiaient les données en fonction des résultats du processus ETL. Dans le cadre de ce projet, nous avons eu de la chance et le client nous a donné accès à des ensembles de données anonymisées sur lesquelles nous avons testé. Nous avons vérifié les données ligne par ligne pour vérifier la conformité aux types, la présence de données brisées, le nombre total d'enregistrements avant et après, la comparaison des transformations effectuées par le processus ETL pour l'agrégation, la modification des noms de colonnes, etc. En outre, ces contrôles ont été étendus à différentes sources de données, par exemple, outre SalesForce, également à MySQL.

Les contrôles finaux de la qualité des données ont déjà été effectués au niveau S3, où elles étaient stockées et prêtes à l'emploi pour la formation de modèles d'apprentissage automatique. Pour obtenir les données du fichier CSV final situé sur le bucket S3 et le valider, le code a été écrit en utilisant client boto3.

Le client avait également besoin de stocker une partie des données dans un compartiment S3 et une partie dans un autre. Cela a également nécessité la réalisation de contrôles supplémentaires pour vérifier la fiabilité d'un tel tri.

Expérience généralisée d'autres projets

Un exemple de la liste la plus générale des activités d'un ingénieur Data Quality :

  • Préparez les données de test (valides, invalides, grandes, petites) via un outil automatisé.
  • Téléchargez l'ensemble de données préparé sur la source d'origine et vérifiez qu'il est prêt à être utilisé.
  • Lancez les processus ETL pour traiter un ensemble de données du stockage source au stockage final ou intermédiaire à l'aide d'un certain ensemble de paramètres (si possible, définissez les paramètres configurables pour la tâche ETL).
  • Vérifier les données traitées par le processus ETL pour leur qualité et leur conformité aux exigences commerciales.

Dans le même temps, les contrôles ne devraient pas porter uniquement sur le fait que le flux de données dans le système a, en principe, fonctionné et atteint son terme (ce qui fait partie des tests fonctionnels), mais surtout sur le contrôle et la validation des données pour le respect des exigences attendues, l'identification des anomalies et d'autres choses.

Outils

L'une des techniques pour un tel contrôle des données peut être l'organisation de contrôles en chaîne à chaque étape du traitement des données, ce que l'on appelle dans la littérature « chaîne de données » - contrôle des données depuis la source jusqu'au point d'utilisation finale. Ces types de vérifications sont le plus souvent implémentés en écrivant des requêtes SQL de vérification. Il est clair que de telles requêtes doivent être aussi légères que possible et vérifier la qualité des données individuelles (métadonnées des tables, lignes vides, NULL, erreurs de syntaxe - autres attributs requis pour la vérification).

Dans le cas des tests de régression, qui utilisent des ensembles de données prêts à l'emploi (inchangeables, légèrement modifiables), le code d'autotest peut stocker des modèles prêts à l'emploi pour vérifier la conformité des données avec la qualité (descriptions des métadonnées de table attendues ; exemples d'objets de ligne qui peuvent être sélectionnés au hasard lors du test, etc. ).

De plus, pendant les tests, vous devez écrire des processus de test ETL à l'aide de frameworks tels qu'Apache Airflow, Apache Spark ou encore un outil de type cloud boîte noire Préparation de données GCP, Flux de données GCP Et ainsi de suite. Cette circonstance oblige l'ingénieur de test à s'immerger dans les principes de fonctionnement des outils ci-dessus et, plus efficacement encore, à effectuer des tests fonctionnels (par exemple, les processus ETL existants sur un projet) et à les utiliser pour vérifier les données. En particulier, Apache Airflow propose des opérateurs prêts à l'emploi pour travailler avec des bases de données analytiques populaires, par exemple BigQuery GCP. L'exemple le plus élémentaire de son utilisation a déjà été décrit ici, donc je ne me répéterai pas.

En dehors des solutions toutes faites, personne ne vous interdit de mettre en œuvre vos propres techniques et outils. Cela sera bénéfique non seulement pour le projet, mais aussi pour le Data Quality Engineer lui-même, qui améliorera ainsi ses horizons techniques et ses compétences en codage.

Comment ça marche sur un vrai projet

Une bonne illustration des derniers paragraphes sur la « chaîne de données », l'ETL et les contrôles omniprésents est le processus suivant tiré d'un des projets réels :

Testeur de big et small data : tendances, théorie, mon histoire

Ici, diverses données (bien sûr préparées par nos soins) entrent dans « l'entonnoir » d'entrée de notre système : valides, invalides, mixtes, etc., puis elles sont filtrées et aboutissent dans un stockage intermédiaire, puis elles subissent à nouveau une série de transformations. et sont placés dans le stockage final, à partir duquel, à leur tour, seront effectuées des analyses, la création de data marts et la recherche d'informations commerciales. Dans un tel système, sans vérifier fonctionnellement le fonctionnement des processus ETL, nous nous concentrons sur la qualité des données avant et après les transformations, ainsi que sur la sortie vers l'analyse.

Pour résumer ce qui précède, quels que soient les lieux où j'ai travaillé, partout j'ai été impliqué dans des projets Data partageant les caractéristiques suivantes :

  • Ce n'est que grâce à l'automatisation que vous pourrez tester certains cas et atteindre un cycle de publication acceptable pour l'entreprise.
  • Un testeur sur un tel projet est l'un des membres les plus respectés de l'équipe, car il apporte de grands avantages à chacun des participants (accélération des tests, bonnes données du Data Scientist, identification des défauts dès les premiers stades).
  • Peu importe que vous travailliez sur votre propre matériel ou dans le cloud : toutes les ressources sont rassemblées dans un cluster tel que Hortonworks, Cloudera, Mesos, Kubernetes, etc.
  • Les projets sont construits sur une approche microservice, l'informatique distribuée et parallèle prédomine.

Je voudrais noter que lorsqu'il effectue des tests dans le domaine de la qualité des données, un spécialiste des tests déplace son attention professionnelle vers le code du produit et les outils utilisés.

Caractéristiques distinctives des tests de qualité des données

De plus, pour ma part, j'ai identifié les caractéristiques distinctives suivantes (je ferai immédiatement une réserve qu'elles sont TRÈS généralisées et exclusivement subjectives) des tests dans les projets (systèmes) Data (Big Data) et d'autres domaines :

Testeur de big et small data : tendances, théorie, mon histoire

Liens utiles

  1. Théorie: DAMA-DMBOK : Corpus de connaissances en gestion des données : 2e édition.
  2. Centre d'entraînement EPAM 
  3. Matériel recommandé pour un ingénieur Data Quality débutant :
    1. Cours gratuit sur Stepik : Introduction aux bases de données
    2. Cours sur LinkedIn Learning : Fondements de la science des données : ingénierie des données.
    3. Article:
    4. Vidéo:

Conclusion

Qualité des données est une très jeune direction prometteuse, dont faire partie signifie faire partie d'une startup. Une fois dans Data Quality, vous serez immergé dans un grand nombre de technologies modernes et très demandées, mais surtout, d'énormes opportunités s'ouvriront pour vous pour générer et mettre en œuvre vos idées. Vous pourrez utiliser l'approche d'amélioration continue non seulement sur le projet, mais aussi pour vous-même, en vous développant continuellement en tant que spécialiste.

Source: habr.com

Ajouter un commentaire