< Industrialiser la démarche data : ceux qui mettent en œuvre témoignent

Ce témoignage est extrait du Livre blanc "DataOps" 🗝

Il n’y aura jamais assez d’ingénieurs dans une entreprise pour tout faire, il faut donc outiller les personnes qui se servent de la data et bien articuler les rôles et responsabilités entre les uns et les autres.

Sur la partie Analytics, par exemple, jusqu’à quel point les ingénieurs ont-ils besoin de comprendre le métier ? S’il y a un défaut de compréhension et qu’ils tentent de faire de la modélisation, le résultat ne sera pas bon. Inversement, les analystes peuvent être tentés de réaliser les requêtes de transformation eux-mêmes et, possiblement, aboutir à des dégradations de performances, des hausses de coûts ou, pire, des contresens dus à la complexité de l’outil de transformation - alors que tout cela aurait pu être évité avec une démarche d’ingénierie.

L’organisation autour de la donnée est forcément propre à chaque entreprise.
Chez Dailymotion, la partie engineering est centralisée. Il s’agit de construire des jeux de données capables de monter en charge, en respectant un certain nombre de bonnes pratiques pour que la qualité soit au rendez-vous. Je ne dirais pas que nous sommes parvenus à mettre en place une gouvernance idéale, parfaitement structurée, mais nous y travaillons encore et toujours.

Aujourd’hui, nous avançons vers une organisation où les jeux de données centraux sont sous l’entière responsabilité des ingénieurs data et où les analystes ont pleine autonomie pour créer des jeux de données secondaires servant leurs besoins grâce à une plateforme fournie par les ingénieurs. Concrètement, dans ce schéma, les ingénieurs data travaillent en amont sur la plateforme, au centre sur la création et la maintenance des jeux de données centraux et en aval pour valider les requêtes des analystes pour créer les jeux de données secondaires.

Sur la partie Machine Learning, le même défi de clarification des rôles se pose entre ingénieurs machine learning et ingénieurs data. Chez Dailymotion, le travail d’un ingénieur de machine learning va au-delà de produire un modèle Python dans un notebook : il n’a fini son travail que quand son modèle est en production. Nous avons commencé par toujours associer des ingénieurs data aux ingénieurs machine learning afin de traiter pour eux les problématiques de montée en charge, de CI/CD, d’extraction des données, etc. Nous allons à présent vers un modèle similaire à la partie analytics : les ingénieurs data fournissent aux ingénieurs machine learning les composants nécessaires à leur autonomie (chaînes de traitement normalisées, composants standard réutilisables entre chaînes de traitement, cluster de GPU “as-a-service”, template de CI, orchestrateur propre au ML, etc.).

Un autre défi, propre au Machine Learning, est de savoir définir le “besoin”. C’est quelque chose sur lequel nous avons progressé : au début, nous avons travaillé sur des algorithmes sans suffisamment clarifier les contraintes issues du produit. Renforcer la collaboration avec le produit et définir les attendus en termes de spécifications ont été clefs pour arriver à monter en production tous nos projets ces 4 dernières années : quel est le KPI de succès et quelles contraintes s’imposent à la solution, quoi qu’il advienne.

À la fois pour les Analytics et pour le Machine Learning, l’utilisation du Cloud est un élément crucial pour la réussite de nos projets car il apporte beaucoup de souplesse en éliminant des obstacles en début de projet : bons de commande, installation, capacity planning au cordeau. C’est d’autant plus important pour des projets Machine Learning où le niveau d’incertitude sur la faisabilité est élevé en début de projet.

L’élasticité du Cloud est aussi fondamentale pour stocker et analyser nos données. Nous disposons de plusieurs pétaoctets de données et malgré cela, nous n’avons jamais de problème, les performances sont au rendez-vous.

Le Cloud nous apporte la tranquillité d’esprit : en passant moins de temps sur l’ingénierie, on peut se concentrer davantage sur notre mission, qui est de répondre aux besoins du métier. Mais le Cloud fonctionne tellement bien que cela en devient presque un inconvénient : quand on compte en pétaoctets et en centaines de chaînes de traitement, cela finit par alourdir sensiblement la facture. Il faut donc se poser la question de l’utilité de certaines données ou de certains traitements.

Nous avons adopté une démarche FinOps : toutes nos ressources cloud ont été labellisées (buckets, datasets, pipelines, compute...) pour pouvoir les identifier dans la facture et savoir à quels produits elles sont rattachées.Cela nous permet d’offrir aux analystes comme aux ingénieurs machine learning une plateforme de données dont on maîtrise à la fois la qualité et les coûts.

Découvrez notre Livre blanc “DataOps” - SFEIR
Découvrez au travers de notre livre blanc comment industrialiser la valorisation de vos données grâce au DataOps.
Share this post