L’ingénierie des données n’est pas l’ingénierie logicielle

D’après tout ce que nous avons vu au cours des dernières années, il semble que l’ingénierie des données converge avec DevOps. Tous deux ont adopté l’infrastructure cloud, la conteneurisation, CI/CD et GitOps pour fournir des produits numériques fiables à leurs clients.

La convergence sur un sous-ensemble d’outils a conduit beaucoup à penser qu’il n’y a pas de distinction significative entre l’ingénierie des données et l’ingénierie logicielle. Par conséquent, le fait que l’ingénierie des données soit assez “brute” est simplement dû au retard des ingénieurs de données dans l’adoption de bonnes pratiques de développement logiciel.

Cette évaluation est erronée. L’ingénierie des données et l’ingénierie logicielle partagent de nombreux outils et pratiques communs, mais elles diffèrent également considérablement dans plusieurs domaines clés. Ignorer ces différences et gérer une équipe d’ingénierie de données comme une équipe de produits logiciels est une erreur. Pensez à l’ingénierie des données comme à une tomate : c’est un fruit, mais cela ne signifie pas qu’il doit être ajouté à une salade de fruits.

Cet article (divisé en deux parties) vise à mettre en évidence certains des défis uniques de l’ingénierie des données et pourquoi cela nécessite une approche sur mesure.

Les pipelines de données ne sont pas des applications

L’ingénierie logicielle a tendance à se préoccuper de la création d’applications. Dans le contexte de cet article, une application est définie de manière très large et peut être un site Web, une application de bureau, une API, une application mainframe monolithique, un jeu, un microservice, une bibliothèque ou n’importe quoi entre les deux. Les traits qu’ils partagent tous sont qu’ils :

1- Apporter de la valeur aux utilisateurs en proposant un nouveau mode d’interaction. Un jeu peut être joué, un site Web peut être parcouru, une API peut être utilisée dans d’autres logiciels.

2- Ils disposent d’une série de ressources indépendantes. Un site Web peut augmenter son nombre de pages, un jeu peut augmenter son nombre de niveaux ou de personnages jouables, une API peut ajouter plus de points de terminaison. Une demande n’est jamais vraiment complète.

3- Gérer une quantité relativement faible d’état qu’ils créent. L’état est conçu pour prendre en charge l’application. La gestion de cet état est généralement déchargée sur un système externe. L’objectif est que de grandes parties du logiciel soient sans état. Une application Web peut être arrêtée et redémarrée à tout moment ; son état est géré par une base de données exécutée dans un processus séparé.

4- Sont faiblement couplés à d’autres logiciels et services. Un bon logiciel doit fonctionner indépendamment dans n’importe quel environnement, d’où la popularité des microservices et des conteneurs.

Les ingénieurs de données sont concernés par la construction de pipelines de données. Les pipelines de données prennent les données là où elles sont produites, les transforment et les placent ailleurs où elles sont consommées. En règle générale, l’objectif est d’automatiser ces pipelines afin que les ensembles de données soient mis à jour au fil du temps avec de nouvelles données.

Comme les applications, les pipelines de données sont souvent des logiciels. Mais contrairement aux applications, un pipeline de données :

• Il ne fournit aucune valeur directe. Il n’y a pas d’utilisateurs du pipeline. Seul l’ensemble de données produit par le pipeline est précieux pour les consommateurs. Si les données arrivaient à destination via un système élaboré de copier-coller, le client serait tout aussi satisfait.

• Il n’a qu’une seule caractéristique pertinente pour le client : produire l’ensemble de données qui a été demandé.

• Gère un grand nombre d’états. Un pipeline est conçu pour prendre l’état existant d’autres logiciels qu’il ne contrôle pas et le convertir dans l’état qu’il contrôle. De nombreux pipelines créent des ensembles de données de manière incrémentielle, en ajoutant plus de données à chaque exécution. En ce sens, ces pipelines peuvent être considérés comme des processus de longue durée qui créent continuellement de plus en plus d’états.

• Il a un couplage inévitable. Le but d’un pipeline de données est précisément de se lier à une source de données. Le pipeline sera toujours aussi stable et fiable que la source.

Ces différences fondamentales entraînent des défis uniques en matière d’ingénierie des données qui sont souvent mal compris par les entreprises, la direction informatique et même les ingénieurs logiciels.

Un pipeline est complet ou sans valeur

De nombreuses organisations gèrent actuellement leurs équipes logicielles sous une certaine forme d’Agile. La philosophie de base de ces cadres est de maximiser la vitesse à laquelle le logiciel offre de la valeur au client en créant et en publiant des logiciels en courtes itérations. L’objectif est de fournir un produit minimalement viable (MVP) le plus rapidement possible et d’assurer des boucles de rétroaction rapides, garantissant ainsi que l’équipe travaille toujours sur les fonctionnalités les plus prioritaires.

Ces idées ne correspondent pas à l’ingénierie des données.

Un pipeline de données ne peut pas être construit en petites itérations pour augmenter la valeur client. Il n’y a pas d’équivalent MVP d’un pipeline de données. Il produit ou non le jeu de données souhaité pour le client.

Par conséquent, le développement de pipelines de données ne s’intègre pas parfaitement dans les cadres agiles. Un pipeline de données complexe correspond à une seule user story, mais nécessite souvent plusieurs sprints.

La direction non technique prend rarement en compte ce point subtil et essaie de toute façon d’intégrer les ingénieurs de données dans les équipes Scrum. Le résultat est que les user stories sont remplacées par des tâches, par exemple “construire un connecteur API” et “construire une logique d’ingestion”, ce qui transforme inévitablement le tableau scrum en un dispositif de microgestion.

Lorsque la direction ne comprend pas les principes fondamentaux de ce qu’elle gère, elle a tendance à prendre des décisions médiocres et peu pratiques. Frustré par la lenteur de la progression d’un pipeline, un responsable peut exiger qu’un ingénieur de données construise l’ensemble de données de manière itérative, colonne par colonne, afin que le client “ait au moins quelques données pour commencer à travailler”. Les ingénieurs de données ayant une expérience pratique des pipelines complexes et les scientifiques de données qui ont déjà reçu un ensemble de données inutile reconnaîtront le ridicule de cette situation. Pour les lecteurs sans cette expérience, voici trois raisons pour lesquelles cela ne fonctionne pas :

1- Un jeu de données partiel n’a pas d’utilité proportionnelle

Si un jeu de données contient 9 colonnes sur 10, est-il utile à 90 % ? Cela dépend de la colonne qui est omise. Si un Data Scientist souhaite construire un modèle prédictif basé sur les données, mais que la colonne manquante correspond aux étiquettes ou aux valeurs qu’il souhaite prédire, l’ensemble de données est utile à 0%. Si la colonne contient des métadonnées aléatoires non corrélées avec les étiquettes, cela peut être utile à 100 %.

Plus communément, une colonne représente un champ qui peut ou non être corrélé avec les étiquettes ; découvrir si cela est corrélé est exactement ce que le Data Scientist veut découvrir par l’expérimentation. C’est pourquoi un Data Scientist veut un ensemble de données aussi complet que possible pour commencer à expérimenter, explorer et optimiser progressivement son modèle. Leur fournir un ensemble de données partiel garantit que l’expérimentation et l’optimisation devront être refaites à mesure que des champs supplémentaires deviennent disponibles.

2- Le temps de développement d’un pipeline n’est pas corrélé à la taille du jeu de données

Même si un client était satisfait de la moitié d’un ensemble de données, sa production ne prendrait pas la moitié du temps nécessaire pour l’ensemble de données complet.

Un pipeline de données ne se compose pas de tâches indépendantes produisant chacune une colonne. Plusieurs colonnes peuvent être liées si elles proviennent de la même source, donc en inclure une ou plusieurs dans l’ensemble de données final représente la même quantité de travail.

Cependant, la logique de fusion de ces colonnes avec les colonnes d’une autre table peut être aussi simple qu’une simple jointure, ou elle peut nécessiter une série compliquée de fonctions de fenêtre. En outre, de nombreuses règles peuvent devoir être écrites dans un pipeline de données avant que des données ne sortent à l’autre extrémité, par exemple, permettre à un client d’accéder à une API ou à un analyste de traiter des données non structurées. Une fois que cela est en place, étendre la logique pour traiter des champs supplémentaires est probablement trivial. Par conséquent, le nombre de colonnes dans l’ensemble de données final est une métrique terrible pour la complexité du pipeline, à égalité avec l’utilisation du nombre de lignes de code pour mesurer le débit.

La taille de l’ensemble de données peut également faire référence au nombre de lignes/d’enregistrements. Un pipeline bien conçu doit être capable de gérer n’importe quel nombre d’enregistrements, de sorte que le temps de développement doit être entièrement découplé. Cependant, il peut y avoir des « sauts » dans le temps de développement en fonction d’exigences spécifiques telles que :

• À quelle fréquence l’ensemble de données doit-il être actualisé, c’est-à-dire avons-nous besoin d’un traitement par lots ou d’un flux ?

• Quels sont les volumes de données et la vitesse attendus ?

• Les données tiennent-elles dans la RAM ?

Ces considérations doivent être connues à l’avance et influenceront l’ensemble de la conception du pipeline de données.

3- Le temps et le coût économique pour construire un jeu de données sont corrélés à sa taille

Plus un jeu de données est volumineux, à la fois en termes de lignes et de colonnes, plus il faut de temps pour le créer et le mettre à jour.

La modification d’un seul enregistrement dans une énorme base de données est simple et rapide, mais il s’agit d’un scénario inhabituel pour les ensembles de données analytiques. La modification d’un jeu de données analytique implique généralement l’ajout/la modification de colonnes entières (ce qui modifie tous les enregistrements) ou la mise à jour de milliers ou de millions de lignes. Il existe deux façons de gérer les modifications de données, et aucune n’est bon marché.

Du point de vue d’un développeur, le moyen le plus simple d’actualiser un jeu de données consiste à tout écraser en actualisant et en réexécutant le pipeline. Cependant, c’est le plus coûteux en termes de coûts de calcul et de temps pour mettre à jour l’ensemble de données. Concevoir un pipeline de sorte qu’il écrase correctement l’état des exécutions précédentes n’est pas toujours trivial et nécessite une planification initiale appropriée.

Alternativement, la logique de mise à jour d’un ensemble de données peut être codée dans un pipeline séparé qui prend l’ancien ensemble de données en entrée. Cela peut être plus économique en termes de coût et de vitesse de calcul, mais cela entraîne un temps de développement et une surcharge mentale supplémentaires. Les pipelines qui appliquent des deltas ne sont pas idempotents, il est donc important de garder une trace de l’état actuel ainsi que du moment où des opérations spécifiques ont été effectuées. Même dans ce deuxième scénario, l’ancien pipeline doit être mis à jour pour inclure la modification souhaitée dans les nouvelles mises à jour.

Quoi qu’il en soit, le problème est découpé en dés, les ensembles de données ont une inertie inhérente. Essayer d’apporter des modifications nécessite plus de temps, d’efforts et/ou d’argent plus l’ensemble de données est grand.

Conclusion de la partie 1 : Déployer un pipeline partiel vers la production est un gaspillage

Le déploiement d’un pipeline partiellement achevé en production n’est pas utile pour le client, cela gaspille des calculs et complique la vie des ingénieurs de données qui construisent le pipeline car ils devront gérer l’ancien état. Cultiver les charges DevOps et les principes agiles sur le développement du pipeline de données, où les changements incrémentiels et les déploiements fréquents sont encouragés, ignore simplement l’inertie des données.

Les ingénieurs de données aimeraient « bien faire les choses du premier coup » et minimiser le nombre de déploiements en production. Un pipeline fréquemment déployé signifie que le client ne sait pas ce qu’il veut ou que la source de données est très instable et que le pipeline nécessite des correctifs constants. Contrairement aux applications sans état, où les mises à jour ont tendance à être aussi simples que de supprimer quelques conteneurs et d’en créer de nouveaux, la mise à jour d’un ensemble de données n’est pas la même chose que le redéploiement du code de pipeline. Emballer le code du pipeline dans un conteneur et l’exécuter sur Kubernetes ne comblera pas cette lacune.

Nous continuons dans la partie 2.

David Matos

Les références:

L’ingénierie des données n’est pas l’ingénierie logicielle

Formation d’ingénieur de données

En rapport