Image tirée de slon.pics Suite

Il a été rédigé par Micha Kunze qui nous a très aimablement autorisé à le traduire.

Cet article a été originellement publié ici : https://towardsdatascience.com/develop-your-data-as-a-product-f9ba268c4e20

Publication originale : 31 octobre 2020 · 7 min de lecture

Pratiques de Data Engineering

TL: DR – KISS DevOps!

Suscité par une discussion au travail, j’essaie d’écrire mon point de vue personnel sur les meilleures pratiques d’ingénierie des données. Pour ce faire, j’ai pensé qu’il serait préférable de définir d’abord l’objectif de l’ingénierie des données en répondant à la question:

Quel est le résultat que nous, les ingénieurs de données, essayons de produire ?

Et puis, une fois que nous sommes clairs sur le résultat, détaillons quels principes et pratiques peuvent nous aider à y parvenir.

Un avertissement: j’ai une expérience de travail dans ce que j’appellerais de grandes entreprises (> 50.000 employés), travaillant en étroite collaboration avec des scientifiques ou directement dans une équipe produit / analytique. Si vous travaillez dans une petite entreprise en tant qu’homme-orchestre, ou dans une start-up, certaines choses peuvent ne pas être reliées – même si je pense que les basiques et les principes s’appliquent toujours.

Hypothèse: Gérer ses données comme un produit

Les données elles-mêmes (passives et dormantes) sont sans valeur, c’est le résultat dérivé de ces données qui génère de la valeur pour vous (et l’entreprise). Cela signifie bien que les données sont un produit comme un autre. Sans les clients qui l’utilisent / l’achètent réellement, cela ne génère rien.

Si nous suivons ce principe simple, nous pouvons rapidement établir des métriques qui nous indiquent le succès de notre produit de données:

Usage du produit qui génère de la valeur
Vitesse de mise sur le marché et vitesse de changement
Qualité et fiabilité
Disponibilité et interopérabilité

Comment construire de bons produits = Keep it Simple

D’après mon expérience, un état d’esprit focusé sur le produit aide vraiment à avoir de l’impact. Chaque fois que nous développons quelque chose, les dimensions du produit comme la valeur de la solution, la viabilité, l’opportunité et la faisabilité devraient être ce à quoi nous réfléchissons avant tout.

Nous passerons certainement beaucoup de temps sur la façon dont nous construisons et exploitons les solutions, ce qui déterminera la faisabilité et la viabilité du produit. Par conséquent, il est essentiel de comprendre le problème business et de concevoir des solutions durables. Et ici, je vois une relation forte entre l’état d’esprit du produit et KISS (Keep It Simple & Stupid = Restez Simple et Stupide). Ce dernier est essentiel pour construire des produits durables (lire faisables et viables à long terme).

Un exemple (trop) simple: supposons que nous sommes Starbucks et que nous devons prendre des décisions chaque jour sur le nombre de gobelets en papier que nous expédions dans chaque magasin. Maintenant, ne serait-il pas cool d’avoir un flux de données en temps réel sur les gobelets en papier pour surveiller le stock et réagir aux changements? – Absolument pas. Si nous ne devons prendre cette décision qu’une fois par jour, nous pouvons l’accomplir avec un simple cronjob qui s’exécute tous les jours.

Restez simple et ne faites que les choses dont votre solution a besoin; ce n’est pas parce que nous pourrions faire quelque chose de plus sophistiqué que nous devrions le faire.

Bonnes pratiques développement produit

Spoiler: Les meilleures pratiques pour les ingénieurs de données et les ingénieurs logiciels sont pratiquement les mêmes. Les pratiques DevOps en particulier ont amélioré la façon dont nous construisons – et s’il existe également des DataOps, ce dernier n’est qu’un terme reliant les principes DevOps au domaine des données.

Cela ne veut pas dire que l’ingénierie des données et l’ingénierie logicielle sont les mêmes, mais la vérité est que les ingénieurs logiciels ont eu une longueur d’avance lorsqu’il s’agit de créer rapidement des produits numériques générateurs de valeur, et nous devrions en tirer des leçons.

Décomposons cela plus en détail et lions-le aux métriques ci-dessus.

Usage et génération de valeur. Ce qui compte, c’est de livrer un produit qui a de l’impact. Nous savons grâce au développement de logiciels que cela peut être fait efficacement en connaissant et en travaillant en étroite collaboration avec nos utilisateurs, de préférence dans la même équipe. Connaître les besoins, comprendre les points faibles et y répondre de manière itérative. Concrètement, cela signifie que nous devrons expérimenter et faire évoluer notre produit. Techniquement, cela signifie que nous devons être en mesure de garder une trace de cela et être constamment en mesure de développer de nouvelles fonctionnalités (ou de revenir en arrière).

Rapidité de commercialisation. Automatiser les processus et les outils, nous devons être en mesure d’expédier et de développer un produit de données rapidement, au niveau de la production. La seule façon de le faire efficacement, en particulier dans un contexte d’analyse, consiste à découpler les actifs de données. Si chaque fois que nous devons d’abord mettre à jour un milliard de pipelines pour ajouter une nouvelle dimension à notre fidèle schéma en étoile (et ainsi briser une certaine dépendance en aval non documentée), nous n’avons aucune chance de gagner une vitesse durable.

Qualité et fiabilité. La première chose que nous devons avoir est un état d’esprit sain d’amélioration continue en ce qui concerne le développement et les opérations. Nous ne construirons jamais un produit parfait dès le départ. Techniquement, cela signifie que nous devrions toujours avoir une bonne configuration CI / CD (DevOps). Mentalement, cela signifie que nous devons adopter une culture post-mortem. En d’autres termes, nous faisons de notre mieux pour détecter les problèmes en utilisant des tests automatiques / des pods auto-réparateurs / des contrôles de qualité des données. Et lorsque les choses tournent inévitablement, nous nous assurons d’en tirer des leçons et d’améliorer le produit!

Disponibilité et interopérabilité. La disponibilité n’est pas seulement la présence d’un produit de données, mais aussi sa facilité de consommation. Pas pour nous, mais pour nos consommateurs. Notre produit doit être utilisé afin de maximiser la création de valeur, nous devons donc le rendre facilement disponible. Nous devons utiliser des interfaces standard pour faciliter l’utilisation de notre produit par des équipes diverses, c’est-à-dire que nous ne faisons pas de choix technologique pour nos consommateurs ou ne les faisons pas sauter à travers les arceaux technologiques. Pour rester agile et rapide, nous devons séparer la préoccupation de notre développement interne de l’interface que nous partageons avec nos consommateurs.

Tous les points ci-dessus sont tirés des leçons apprises par les ingénieurs en logiciel lors de la création de produits numériques. À mon avis, ils s’appliquent tout aussi bien à l’ingénierie des données – bien que leur mise en œuvre puisse varier en termes de technologie.

Encore une chose: l’ immuabilité. Ce n’est peut-être pas aussi important / répandu dans les meilleures pratiques en génie logiciel et cela vient davantage des programmeurs fonctionnels, mais cela a un impact extrêmement important sur l’ingénierie des données. Surtout dans l’espace analytique. Essayez de pratiquer l’ingénierie fonctionnelle des données, ce qui signifie: nous ne changeons pas l’historique, mais nous prenons un instantané de toutes les données. Ne pas faire cela est un chemin vers la folie – quelque chose qui vaut la peine d’écrire un article complet. Pour l’instant, je vous laisse avec un pointeur sur quelques-uns des travaux de Maxime Beauchemin, qui dispose d’un excellent matériel sur l’ingénierie fonctionnelle des données ❤️.

Pratiques de Data Engineering

Si vous avez réussi jusqu’à présent, tant mieux! Essayons de résumer les choses en quelques pratiques simples et tangibles que nous, en tant qu’ingénieurs de données, pouvons appliquer au quotidien.

Contrôle de version – Tout notre travail doit être contrôlé en version, notre code, nos données et la documentation de nos données. Évoluez, expérimentez et si nécessaire revenez en arrière!

Test et déploiement automatisés – Les tests automatisés offrent une qualité élevée et durable. Le déploiement automatisé nous rend efficaces et atténue les erreurs. Nous en avons besoin (vérifiez Python pour DevOps pour commencer)!

Rendre et conserver les données disponibles – Rendez vos données disponibles de la manière la plus simple possible. Et assurez-vous qu’il reste disponible – utilisez la surveillance et les alertes pour rester proactif dans la résolution des problèmes.

Testez et communiquez la qualité des données – Évaluez en permanence la qualité des données de votre produit et communiquez-la, de préférence via une documentation automatisée des données. Utilisez la surveillance et les alertes pour rester proactif dans la résolution des problèmes.

Préoccupations distinctes – Assurez-vous de ne pas associer étroitement les choses. Ne mettez pas tout dans un schéma en étoile tout de suite, gardez les produits de données séparés autant que possible.

Partagez les meilleures pratiques avec vos collègues – Communiquez avec nos collègues de l’ingénierie des données, découvrez les meilleures implémentations et partagez-les. En fin de compte, nous mettons les meilleures idées dans un cadre et résumons les détails de la mise en œuvre -> profit!

Créez des ensembles de données immuables – Les données sont de l’histoire et l’histoire est immuable. La mise à jour des observations (lignes) entraîne des problèmes lors de l’analyse de l’historique des données. Ceci est extrêmement important pour le débogage et aussi pour les cas d’utilisation de l’apprentissage automatique. Nous nous efforçons de le simplifier et de permettre l’utilisation en aval de nos produits de données en préservant l’historique -> les données sont immuables.

Voici mes meilleures pratiques, celles qui (à mon humble avis) nous en donnent le plus pour notre argent et sont étroitement liées aux paramètres décrits précédemment. Cela ne veut pas dire qu’il n’y a plus rien à apprendre là-bas!

Notes sur le positionnement dans les grandes entreprises

Si nous suivons ces basiques des “données en tant que produit (ndt: aka Data Products)”, nous devons comprendre intimement nos consommateurs, nous devons les expérimenter pour obtenir le meilleur résultat possible. Nous devons créer ensemble de la valeur et changer constamment pour comprendre ce qui fonctionne et nous devons constamment prendre soin de notre produit pour l’améliorer davantage.

Cela signifie essentiellement travailler dans une équipe produit plutôt que dans une équipe de données centralisée (et je peux dire par expérience que c’est génial ). Bien sûr, le concept de décentralisation des ingénieurs de données n’est pas nouveau et vous pourriez même dire qu’il ne fait que prendre au sérieux l’équipe interfonctionnelle – et je suis d’accord. Une des personnes qui a rassemblé et promu cela est Zhamak Dehghani qui a écrit un excellent article à ce sujet avec une vue d’ensemble descriptive sur la façon dont cela pourrait fonctionner à grande échelle (elle est également convaincante sur Youtube ). Je crois que ce que je décris dans cet article est la vision intérieure et la motivation d’une ingénieur de données et je suis donc tout à fait d’accord avec son point de vue.

Conclusion

J’ai utilisé ce post pour me vider la tête et mettre de l’ordre dans certaines de mes pensées.

Ce faisant, j’espère avoir été en mesure de donner à certaines personnes des éléments de réflexion. Peut-être une inspiration pour améliorer leur travail quotidien d’ingénierie des données ou pour devenir plus productif. Si vous n’êtes pas d’accord avec mes opinions, j’aimerais également vous entendre et apprendre de vous.

Je crois que les résultats que nous pouvons obtenir grâce aux produits de données ont un impact et que nous devons en faire des citoyens de premier ordre.

Nous avons tous les outils et toutes les technologies pour y parvenir, alors faisons-le! 😛