Le rôle du Data Engineer avec le paradigme du Cloud Computing

Le rôle du Data Engineer avec le paradigme du Cloud Computing

2947 2121 Patrick Marshall

Le Data Engineer est une ressource qui devient de plus en plus demandée dans un monde toujours plus générateur de données et drivé par l’IA. Il y a peu, pour la plupart des entreprises, disposer d’une architecture “data” signifiait simplement de disposer d’une ou plusieurs bases de données relationnelles qui couvraient l’ensemble du besoin, du transactionnel classique au requêtage à des fins analytiques.

Avec la quantité grandissante de données, les use-cases ont évolué vers des produits dits “data-driven” – comme par exemple des systèmes de détection de fraude, des moteurs de recommandation, ou des services de personnalisation -, et ont fait accroitre la charge pesant sur le système de gestion des bases de données. Le rôle initial du Data Engineer a donc d’abord été de résoudre ces problèmes en y apportant sa connaissance de data stores relativement nouveaux, comme par exemple des frameworks de calcul parallélisé (Spark), des bases de données non structurées (NoSQL), ainsi que de l’outillage pour les faire communiquer, comme des pipelines d’ingestion et transformation des données (ETL), des systèmes de streaming (Kafka) ou encore des systèmes de déversement de données (Sqoop, Flume).

Aujourd’hui, les architectures dites “data” sont aussi variées que les use cases auxquels elles répondent.

Qui est le data engineer et quel est son rôle au sein du projet de valorisation des données ?

Un projet dit “data-driven” consiste en 3 grandes étapes bien distinctes que sont l’analyse de la problématique métier, la phase de recherche et d’extraction de la valeur, et, si celle-ci aboutit, l’industrialisation du projet.

La première phase consiste à traduire un besoin métier en termes analytiques, et analyser où pourrait se trouver la valeur ajoutée pour l’entreprise.

La seconde consiste en l’extraction d’informations pour résoudre ledit problème métier; après une phase de préparation et de nettoyage des données à disposition, il faut pouvoir modéliser, explorer et visualiser simplement des relations non perçues au premier abord dans ces données. Ces relations vont servir à créer des modèles plus complexes impliquant du Machine Learning (ML), des statistiques plus poussées ou encore des simulations. Le but est ici de démontrer via un prototype que la donnée apporte de la valeur ajoutée pour l’entreprise et valider un retour sur investissement. Cette partie du projet data est assurée par un Data Scientist, qui a traditionnellement un background plutôt orienté mathématiques, statistiques, ou recherche opérationnelle. Le Proof-of-Concept (PoC) développé par le Data Scientist doit permettre de confronter les hypothèses initialement prises par le métier et de valider ou non le besoin de les transformer en une application plus large.

C’est la phase que nous appellerons ici “industrialisation”, et qui consiste à optimiser et à préparer le produit pour une utilisation long terme et à l’échelle.

Ce produit fini devra être capable d’être alimenté par une volumétrie de “nouvelles” données beaucoup plus importante et continue par nature (à l’inverse du jeu de données utilisé pour le développement du modèle statistique). Et qui dit volumétrie plus importante, dit besoin en capacités de calcul proportionnellement plus important. Enfin, le produit devra devenir robuste, maintenable, testé et packagé, le tout en utilisant les bonnes pratiques de software engineering et la méthodologie DevOps. Sacrifier cette étape (ou opérer la fameuse escroquerie du “PoC en prod”), c’est s’exposer à une perte de confiance de la part des utilisateurs finaux du produit du fait de mauvaises prédictions, d’éventuelles pertes de données, d’une baisse de disponibilité du service ou encore de l’accumulation de la dette technique du fait d’une incapacité à ajouter ou modifier des fonctionnalités rapidement. Cette phase d’automatisation requiert des compétences en bonnes pratiques de développement, en architecture autour des outils Big Data, en sécurité, ou encore en redondance des données, tout en gardant en vue notre produit data et ses spécificités.

Au cours de la première moitié des années 2010, ne sachant pas ce qu’elles pouvaient espérer tirer de leurs données, les entreprises – du moins celles qui capitalisaient déjà sur des bases de données fournies ou celles qui ont investi de manière à pouvoir récupérer et stocker celles-ci de manière structurée – ont initialement fait appel à des Data Scientists issus de sociétés de conseil pour les faire travailler main dans la main avec leurs métiers. Le but était alors de mettre des contours sur des problématiques business et de pré-évaluer la faisabilité d’études. Celles dont la phase de R&D était effectivement issue de vrais besoins métier ont pour la plupart mis sur pied des prototypes fonctionnels. Du fait de cet apport de valeur rapide, ces Data Scientists ont alors progressivement été “internalisés”. Mais leurs capacités à relever le défi lié à l’industrialisation de ces prototypes ont eu leurs limites.

C’est sur ces sujets qu’intervient le Data Engineer: il possède un background plutôt orienté software, excelle dans l’automatisation de la livraison de produits de qualité en production (et notamment en lisibilité, et testabilité du code), maitrise et évangélise les pratiques SecDevOps, et facilite l’ingestion massive de données. Mais sa spécificité, par rapport à un ingénieur DevOps pure souche, est notamment son aptitude à comprendre le fonctionnement de modèles de Machine Learning, et plus particulièrement leurs entrées/sorties en termes de données. Il devra alors faire en sorte que ces algorithmes soient “nourris” correctement, tant lors des prédictions à effectuer en temps-réel que lors des phases d’entrainement. Il a pour cela besoin d’avoir un panorama des frameworks fréquemment utilisés par la communauté et le fonctionnement global des modèles produits par les Data Scientists, de manière à les intégrer dans une solution plus large.

Il va également réaliser, entre autres:

  • la mise en place ou l’architecture de plateformes d’exploration de données à destination des data scientists, comme par exemple la mise en place de serveurs de notebooks Python (Jupyter, Zeppelin) interfacés directement sur la source unique de données qu’est le data-lake
  • la phase d’ETL (Extract-Transform-Load), ou la mise en place de pipelines d’ingestion et de transformation de données pour pré-processer ou croiser des quantités massives de données, et “pré-macher” le travail aux Data Scientists de manière à ce que ces derniers se concentrent sur la recherche et l’apport de valeur ajoutée
  • l’évangélisation de nouveaux outils ou frameworks et imaginer la manière dont ils s’intègreraient dans l’architecture globale du projet
  • des tâches additionnelles comme créer des librairies, des squelettes de projets, des scripts, des outils…

Quelle différence entre un projet de ML et un projet IT classique ?

Beaucoup de projets de Data Science échouent lors de la phase d’industrialisation du fait d’un manque d’anticipation en termes d’architecture et de bonnes pratiques software. Mais l’écueil principal est inhérent à la structure d’un projet de data science, qui est autrement plus complexe que des projets classiques à l’architecture plus “linéaire”.

En effet, en plus de données “d’entrée” fournies à l’algorithme à des fins de traitement, une des particularités ici est l’ingestion de données “de retour”, c’est-à-dire sur la validité de l’output proposé. Dans le cadre d’un moteur de recommandation, l’information de retour consiste par exemple à savoir si la personne ciblée par ladite recommandation a effectivement cliqué (ou non) sur ce qui lui avait été suggéré. Ces données seront notamment utiles pour mesurer la qualité des prédictions effectuées, et vont permettre par la suite de ré-entrainer notre modèle pour l’améliorer.

Il s’agit également de gérer correctement les principales dépendances, aux données d’abord, mais aussi aux caractéristiques non-déterministes inhérentes à la modélisation statistique. Un projet de ML est par nature très itératif. En effet, contrairement à tout autre produit logiciel, il est difficile de tester unitairement un modèle, qui ne se comportera pas forcément de la même manière après plusieurs entrainements successifs. C’est d’autant plus perturbant pour les équipes de développement car ce modèle est le résultat d’une phase d’entraînement longue et incertaine, et donc difficile à intégrer dans les méthodes de travail agiles. Qualifié de bon ou mauvais en fonction de métriques purement “métier”, son caractère profitable varie et il est par essence toujours perfectible.

D’un point de vue DevOps, c’est cet aspect particulier qui fait qu’un modèle doit toujours être considéré comme un livrable indépendant: il doit donc être versionné indépendamment du code de l’application, doit avoir son propre cycle de vie (différent de celui du reste de l’application), et pouvoir être livré via un pipeline automatisé indépendant ayant sa propre stratégie de déploiement. C’est en ce sens que des outils comme MLFlow ont été créés en tant que complémentaires aux outils plus classiques tels que Jenkins. La dé-duplication ou l’intégration de ces phases de pipelining, packaging, monitoring, alerting spécifiques ne sont pas des plus excitantes, mais l’absence de l’un de ces éléments peut tuer dans l’œuf un ensemble d’efforts prometteurs autour d’un projet IA.

Notre modèle doit ensuite être exposé, ce qui est le plus souvent fait via une API REST: il sera requêté avec une donnée sur laquelle on souhaite avoir une information de classification ou de prédiction. Dans le cas par exemple d’une visite sur un site d’e-commerce, on souhaite pouvoir afficher dynamiquement à notre visiteur, en fonction du produit qu’il regarde, une sélection de produits en lien avec ce dernier et qu’il serait susceptible de mettre dans son panier. Un appel vers l’API de notre moteur de recommandation effectue une inférence sur la base du produit regardé, et nous répond avec la liste de produits suggérés. De manière générale, il sera donc nécessaire de dimensionner correctement l’API par laquelle notre modèle va être requêté.

Certains outils cloud, à l’instar d’AWS Sagemaker, répondent parfaitement à ces besoins, qui sont à la fois d’entrainer, de packager, et d’exposer nos modèles, le tout en gérant le versionning ou en offrant la possibilité de changer le modèle actuellement en production avec une stratégie de type canary/blue-green…

NB: On parle ici d’algorithmes ou de prototypes de data science développés sur mesure, c’est-à-dire pour lesquels il n’existe pas de solution “sur étagère” répondant au besoin métier. En effet, les différents fournisseurs de solutions cloud, et notamment AWS, proposent un ensemble de service de Machine Learning “managés” (compréhension de texte, analyse sémantique, reconnaissance d’images…), qu’il est possible de paramétrer très simplement et sans avoir besoin de compétences particulières en Data Science.

De la nécessité d’avoir expérimenté on-premise

Dans le cadre d’un travail d’optimisation des performances de l’exécution ou de l’entrainement du modèle sur une plateforme distribuée, le travail du Data Engineer peut être de répartir au mieux le traitement en jouant sur un partitionnement optimal des données et/ou sur la taille et le format de celles-ci, mais peut aussi passer par un choix judicieux d’instances de calcul (CPU, GPU) adaptées au problème. Ainsi, on s’orientera plutôt sur des GPU pour un modèle de Deep Learning orienté classification ou détection d’images, alors qu’un modèle d’analyse sémantique aura besoin de capacités CPU. Dans un datacenter “on-premise”, une fois l’investissement matériel réalisé, il peut devenir limitant pour le choix du modèle à utiliser pour un problème donné, ou alors brider involontairement ses performances.

Ainsi, les clusters managés (EMR chez AWS) permettent non seulement de capitaliser sur les connaissances acquises “on-premises” – on retrouve en effet beaucoup des outils distribués de l’écosystème Apache (Hadoop, Spark, Hive, Presto…)-, mais permettent aussi et surtout de pouvoir adapter de manière totalement transparente le type, le nombre et la puissance des ressources. Dans une optique de réduction des coûts, les instances machine derrière les nœuds de calcul de notre cluster peuvent être paramétrées pour utiliser des instances moins disponibles, mais moins chères (“spot”).

Quelles tendances pour 2020 ? Data-lakehouse, edge computing…

Le Data Engineer peut intervenir sur des problématiques de structuration de datalakes. Un datalake correctement architecturé doit en effet, quelle que soit la volumétrie, pouvoir être utilisé pour plusieurs activités en parallèle, qu’elles aient trait au développement, au requêtage, ou encore à la visualisation. Après le data warehouse et le data-lake, la tendance s’oriente désormais vers un hybride, le data “lakehouse”, qui est une plateforme pouvant contenir à la fois de la donnée structurée et non structurée, permettre des lectures/écritures concurrentes, permettre un requêtage facile par des équipes ou encore servir de support à des dashboards temps-réel, toujours en décloisonnant stockage et processing.

Ces caractéristiques permettent de résoudre le problème des réplications en “off” des sources de données: dans un cadre d’études de data science par exemple, et à cause de la charge nécessaire à des fins d’entrainement, les données sont souvent dupliquées du datalake vers une plateforme dédiée à l’exploration. Cette plateforme doit toutefois rester en phase avec le datalake, qui est lui enrichi continuellement par les données issues de flux continus (type streaming) ou encore des données issues de retour utilisateurs sur les prédictions effectuées par notre modèle.

Il va de soi que la scalabilité “à chaud” – horizontale comme verticale – de la volumétrie et du processing est un atout essentiel du cloud par rapport à un datacenter physique, qui, lui, nécessite un dimensionnement amont et une surveillance constante des besoins des applications. La clé pour la réussite d’un projet de création ou de migration de datalake sera donc la mise en place d’une véritable gouvernance des données, le fait de pouvoir versionner nos datasets et de pouvoir constamment “tracer” l’origine de la donnée travaillée/transformée jusqu’à la “golden source”, le fait de pouvoir requêter un catalogue unique contenant par exemple la sémantique métier de la donnée, son type, sa fréquence de mise à jour, sa source initiale, sa volumétrie totale…

Autre tendance récente, avec l’avènement des objets connectés en tout genre, est celle du fait de pouvoir inférer sur un modèle directement embarqué sur l’objet. En effet, lorsque l’objet est connecté – à l’instar des assistants vocaux -, la donnée est enregistrée et requêtée contre une API, et la réponse qui vous est fournie est le résultat d’un traitement déporté. Toutefois, il arrive que des objets évoluent dans un environnement dénué de connexion, mais doivent tout de même continuer à effectuer des prédictions.
Il va donc être nécessaire “d’embarquer” le modèle (et donc aussi l’OS et les runtimes requis pour son bon fonctionnement) au sein d’un objet à la capacité souvent limitée en stockage comme en processing: c’est ce qu’on appelle le Edge Computing.

Mais le défi ne s’arrête pas là: il faut mettre en place un système de remontée des données afin 1) de ne pas saturer le stockage sur l’objet et 2) de pouvoir effectuer des traitements centralisés sur ces données au niveau de notre datalake. Les problématiques peuvent alors être liées à de l’ingestion continue – ou streaming – et notamment sur le fait de pouvoir disposer d’une architecture résiliente à l’erreur nous permettant de “rejouer” ces flux de données dans le cas d’une panne ou de fichiers corrompus.

Des frameworks ont été développés pour permettre la compression de modèles au format serialisé et le déploiement sur des objets connectés; certains cloud providers vont même jusqu’à proposer des outils (Greengrass, IoT Core chez AWS) permettant la remontée d’informations de ces mêmes capteurs et directement interfacés avec le reste de l’écosystème qu’ils proposent.

Conclusion

Dans le cadre d’une industrialisation d’algorithmes développés dans le cadre de PoCs, le Data Engineer devient indispensable et complémentaire au Data Scientist pour mettre à l’échelle la valeur ajoutée produite par ce dernier. En ce sens, les outils cloud managés mis à disposition par les différents cloud providers sont extrêmement séduisants, si tant est que le Data Engineer possède une vision d’ensemble des outils, patterns d’architecture et frameworks rencontrés on-premise; mais aussi des écueils qui leur sont liés, et ce manière à les éviter dès la phase de conception de la solution cloud.