PC & Mobile

Contrôle de version de données avec DVC. Qu'est-ce que les auteurs ont à dire?

Contrôle de version de données avec DVC. Qu'est-ce que les auteurs ont à dire?


DataOps est très important dans le domaine de la science des données et, à mon avis, les chercheurs en informatique devraient accorder une plus grande attention à DataOps. C’est la fonctionnalité la moins utilisée dans les projets de science des données. À l'heure actuelle, nous utilisons normalement du code de gestion des versions (avec quelque chose comme Git), et de plus en plus de personnes et d'organisations commencent à mettre à jour leurs modèles. Mais qu'en est-il des données?

Je vais expliquer en détail comment utiliser Git avec DVC avec d’autres outils pour la gestion des versions de presque tout ce qui entre dans un projet de science des données (et scientifique) dans un article à venir.

Récemment, le créateur du projet DVC, Dmitry Petrov, a accordé une interview à Tobias Macey sur Podcast .__ init__, un podcast en python. Dans cet article de blog, je fournis une transcription de l'interview. Vous pourriez trouver intéressantes les idées derrière DVC et comment Dmitry voit l’avenir de la science et de l’ingénierie des données.

Vous pouvez entendre le podcast ici:

TL; DR

Nous devons accorder plus d’attention à la manière dont nous organisons notre travail. Nous devons faire plus attention à la façon dont nous structurons notre projet, où nous devons trouver les endroits où nous perdons notre temps au lieu de faire du travail réel. Et il est très important d’être plus organisé et plus productif en tant que spécialiste des données, car aujourd’hui, nous sommes toujours dans le Far West.

La transcription

Avertissement: Cette transcription est le résultat d'écouter le podcast et d'écrire ce que j'ai entendu. J'ai utilisé un logiciel pour m'aider à la transcription, mais la plus grande partie du travail est effectuée par mes oreilles et mes mains, alors s'il vous plaît, si vous pouvez améliorer cette transcription, n'hésitez pas à laisser un commentaire ci-dessous :)

Tobias:

Votre hôte, comme d’habitude Tobias Macy, et aujourd’hui, je suis en train d’interviewer Dmitry Petrov à propos de DVC, un système de contrôle de version open source destiné aux projets d’apprentissage automatique. Alors, Dmitry, pourrais-tu commencer par te présenter?

Dmitry:

Sûr. Salut Tobias C'est un plaisir d'être sur votre spectacle. Je suis Dmitry Petrov. J'ai des antécédents variés en science des données et en génie logiciel. Il y a environ 10 ans, je travaillais dans le monde universitaire et parfois, je disais que je travaillais avec l'apprentissage automatique depuis plus de 10 ans, mais vous savez probablement qu'il y a 10 ans, l'apprentissage par machine consistait principalement en régression linéaire et régression logistique (rire). C'est à peu près ce sur quoi je travaillais.

Puis je suis passé au génie logiciel. J'écris du code de production. A cette époque, la science des données n'était pas une chose. Il y a environ cinq ans, je suis revenu au domaine quantitatif. Je suis devenu informaticien chez Microsoft. Et j'ai vu à quoi ressemble la science moderne des données. Récemment, je suis effectivement revenu au génie logiciel. Aujourd'hui, nous travaillons sur DVC et je construis essentiellement des outils pour l'apprentissage automatique.

Tobias:

Vous rappelez-vous comment vous avez découvert Python?

Dmitry:

C'est arrivé en 2004, je crois. C’est arrivé accidentellement, j’ai fait un stage pendant ma maîtrise et j’ai travaillé sur un projet Python, c’était mon premier langage de script. Je ne compte pas au moins dans ma classe de programmation fonctionnelle, bien sûr, et elle était alimentée par Python 2.2, puis nous passons à la version 2.3.

J’ai passé un certain nombre de nuits blanches à résoudre les problèmes Unicode (rire) en Python 2, si vous travaillez avec Python 2, vous savez probablement de quoi je parle. Et plus tard, j'ai utilisé Python dans tous les projets de recherche sur lesquels je travaillais. Nous utilisions encore le MATLAB pour l'apprentissage automatique. C'était assez populaire il y a 10 ans. Nous utilisons le langage C pour les logiciels de bas niveau, imaginons quand le pilote suit certains signaux, mais en général, Python était la langue principale de mon laboratoire, alors que je travaillais comme ingénieur logiciel. la langue était C ++. Donc, mais j'ai quand même utilisé Python pour des projets ad-hoc pour l'automatisation.

À ce moment-là, il y avait beaucoup de discussions sur Python vs. Perl et pour moi ce n'était pas une question. J'ai donc utilisé Python tout le temps lors de ma transition vers la science des données. Python est devenu ma langue principale parce que la science des données est l’une des langues les plus utilisées de nos jours. Nous construisons des outils pour les scientifiques de données et nous utilisons Python.

Tobias:

L’un des outils sur lequel vous avez travaillé est ce projet appelé DVC ou contrôle de version de données. Pouvez-vous commencer par expliquer un peu ce qu’il est et comment ce projet a été lancé?

Dmitry:

DVC, c’est essentiellement un système de contrôle de version pour les projets d’apprentissage automatique; vous pouvez penser que DVC est un outil en ligne de commande, c’est un peu Git pour ML, ce qu’il vous donne. Il donne trois choses de base. Premièrement, il vous aide à suivre nos fichiers de données volumineux, par exemple, des fichiers de 10 Go, des ensembles de données de 100 Go, des modèles ML, et vous aide à gérer les pipelines de version, les pipelines d’apprentissage de machines, c’est différent des pipelines d’ingénierie de données. C'est une version allégée des pipelines et DVC vous aide à organiser vos expériences et à les rendre auto-descriptives, descriptives, auto-documentées, en gros, vous savez, tout, comment un modèle a été produit, quels types de commandes vous devez exécuter, quels types de métriques ont été produits à la suite de ces expériences.

Vous aurez toutes ces informations dans votre historique Git. DVC vous aide à naviguer dans vos expériences du point de vue technique. Nous utilisons Git comme base. Le DVC fonctionne donc sur Git et sur un stockage en nuage. Vous pouvez utiliser S3, Google Storage ou Azure, ou tout simplement SSH aléatoire, plusieurs serveurs où vous stockez des données, DVC orchestrant essentiellement les stockages Git et cloud.

Vous avez également demandé comment le DVC a commencé. C'est en fait une histoire séparée. Parce qu'au départ, lorsque nous avons démarré le projet, nous ne pensions pas à Git pour ML. Ce à quoi nous pensions, c’était l’expérience en science des données, quelles étaient les meilleures pratiques, et nous étions inspirés par les idées des plateformes de science des données, vous avez probablement entendu parler de Michelangelo, une plateforme de science des données d’Uber, vous avez probablement entendu parler du laboratoire de données Domino.

Aujourd'hui, chaque grande entreprise de technologie possède sa propre plate-forme de science des données, car elle doit en quelque sorte travailler en grandes équipes, n'est-ce pas? Ils ont besoin de collaborer. L'ensemble d'outils d'ingénierie logicielle n'est pas parfait pour les projets ML ou les projets de science des données. Mais lorsque nous examinions la plate-forme, nous nous demandions quoi, à quoi devrait ressembler la plate-forme du futur. Comment créer une plate-forme que les scientifiques peuvent utiliser, et qui peut être largement adoptée et hautement disponible. Nous avons eu cette idée, les principes d'une plateforme de jeu de données du futur. Cela doit être open source, c’est comme cela que vous pouvez ressembler à une communauté, c’est un moyen de créer un scénario commun que tous les scientifiques peuvent utiliser.

S’il doit être distribué, c’est important, car vous travaillez parfois sur votre bureau, avec un processeur graphique, par exemple, vous avez parfois besoin de votre ordinateur portable. Parfois, vous avez besoin des ressources du cloud pour exécuter un modèle spécifique. Par exemple, vous avez besoin d’une énorme quantité de mémoire. C'est important d'être partout.

C’est pourquoi, avec ces principes, nous avons eu l’idée de ne pas réutiliser Git comme base de la plate-forme de science des données pour notre outil. Ensuite, nous réalisons qu’il est très proche de l’idée de la gestion des versions, nous avons simplement besoin de jeux de données de version, nous avons besoin d’expériences de version. Voici comment DVC a commencé.

Tobias:

Vous avez mentionné que les systèmes de contrôle de version traditionnels utilisés dans les projets logiciels classiques ne suffisent pas pour l’apprentissage automatique, car il est nécessaire de pouvoir suivre les ensembles de données avec le code lui-même et certains des modèles résultants. Alors, pouvez-vous parcourir l’ensemble du flux de travail utilisant DVC et en quoi cela diffère-t-il d’un flux de travail Git normal pour un projet d’ingénierie logicielle qui pourrait être centré sur une application Django?

Dmitry:

Tout d'abord, nous devons comprendre quelle est la différence entre le génie logiciel et l'apprentissage automatique. L'apprentissage automatique est piloté par des expériences, le problème est que vous avez plusieurs expériences, vous avez des milliers, parfois des centaines d'expériences, et vous devez communiquer avec les expériences avec vos collègues. En gros avec vous-même, car demain vous ne vous souviendrez plus de ce qui s’est passé aujourd’hui. En un mois, vous ne vous souviendrez plus de ce que vous avez fait aujourd'hui, et pourquoi cette idée donne un résultat aussi médiocre, vous devez tout suivre comme dans de nombreux cas. Vous pouvez être dans la situation lorsqu'un de vos collègues se présente à votre bureau et dit: «Hé, vous savez quoi? J'ai passé deux jours à essayer cette idée. Vous savez quoi, ça ne marche pas. Et vous êtes comme, ouais, j’ai essayé, j’ai essayé la même idée qu’il ya deux semaines. Je sais, ça n’a pas marché. Il est difficile de communiquer ces idées, car vous n’en avez que des dizaines, parfois des centaines. Et c'est la différence. Vous avez besoin d’un cadre pour communiquer par une quantité énorme d’idées, d’énormes expériences.

En génie logiciel, les workflows sont différents. Vous avez un nombre limité de demandes de fonctionnalités d'idées et de corrections de bugs. Je peux dire une déclaration controversée - en génie logiciel, vous n’échouez presque jamais. Si vous décidez d'implémenter un problème, d'implémenter une fonctionnalité ou de corriger, corrigez un bogue, vous créez une branche. Et dans 9 cas sur 10, la branche sera fusionnée au grand public. Vous pouvez échouer en termes de qualité des logiciels que vous avez produits, en termes de budget, car vous pensiez que c’était comme un projet d’un jour et que vous finissez par mettre en œuvre cette fonctionnalité pendant deux semaines. Mais finalement, il sera fusionné.

Dans la science des données, vous essayez 10 idées, une fonctionne au mieux et le reste - ne fonctionne pas. Mais vous avez encore besoin de communiquer tout cela. DVC vous aide fondamentalement à faire ceci, il vous aide à mettre à jour vos expériences, les métriques de vos expériences, vous voyez les métriques qui ont été produites, vous voyez le code qui a été utilisé pour cette expérience particulière avec cette version particulière du jeu de données.

Cela fonctionne mieux que, par exemple, le tableur Excel. Parce qu'aujourd'hui, de nombreuses équipes utilisent uniquement des feuilles de calcul Excel pour suivre leur expérience. Il s’agit donc de la différence fondamentale entre les expériences auto-documentées, la manière claire de collaborer sur des expériences et d’en examiner les résultats.

La version des données est en quelque sorte une chose distincte, ce qui est important pour les expériences, c'est un élément indispensable pour les expériences. Parfois, les utilisateurs utilisent le DVC uniquement pour la gestion des versions de données. En général, par exemple, les ingénieurs travaillant du côté du déploiement utilisent le DVC pour déployer le modèle. Parfois, les ingénieurs de données, les scientifiques de données utilisent DVC uniquement pour la version des jeux de données. Parfois, les utilisateurs utilisent le DVC en remplacement de Git LFS, car celui-ci est limité et le DVC a été conçu pour être optimisé pour des dizaines ou des centaines de gigaoctets.

Tobias:

Pour les types d’expériences avec lesquelles vous travaillez, je sais que certaines des entrées peuvent être sous forme d’ingénierie des caractéristiques, dans lesquelles vous essayez d’extraire différents attributs des données, ou en modifiant les hyper paramètres que vous avez définis. réglage pour essayer d'obtenir une certaine sortie du modèle. Alors pouvez-vous nous dire comment DVC est capable de suivre ces paradigmes et certains des paradigmes de communication qu’il permet, afin de vous assurer que vous ne perdez pas cet effort de perte de temps et d’énergie avec des personnes faisant double emploi avec le même travail capable d'identifier à l'avance cet ensemble particulier de caractéristiques, d'hyperparamètres et d'entrées de données ont tous été essayés ensemble?

Dmitry:

Oh, du point de vue des fichiers de données et des ensembles de données pour le point de vue DVC, suivez-les simplement. Donc, votre fonctionnalité est, donc, fondamentalement, le DVC traite chaque fichier, comme un blob, et nous n’utilisons généralement pas la sémantique de vos fichiers de données et la structure de vos fichiers de données. La même chose pour un modèle. Les modèles ne sont donc que des fichiers binaires. Ce que DVC peut comprendre que le modèle a été modifié, il peut comprendre que cette version particulière du fichier binaire a été produite à cette étape particulière. Cette entrée particulière a été consommée, mais elle n’entre pas dans les fonctionnalités, elle n’entre pas dans la sémantique des données.

Tobias:

En ce qui concerne le modèle de communication global juste, quelles sont certaines des choses qu’un scientifique en données examinerait lorsqu’il travaille dans un projet géré par DVC pour s’assurer qu’il ne fait pas double emploi avec ces efforts? signale-t-il qu'ils seraient en train d'identifier ce qui serait perdu sinon, en utilisant simplement Git seul?

Dmitry:

Tout d'abord, la structure de l'expérience. C’est ce qu’il faut absolument savoir dans la science des données. Je veux dire, pas seulement dans Data Science. En matière d'ingénierie, c'est à peu près la même chose. Vous devez comprendre quel type de code a été utilisé, quelle version exacte de votre code et quelle version exacte du jeu de données a été utilisée. C’est ainsi que vous pouvez faire confiance à une expérience que vous avez annoncée il ya trois semaines.

Une autre chose est métrique. Si vous le savez, ce code avec cette version de l'ensemble de données produit cette valeur particulière de la métrique qu'il crée de confiance. Vous n’avez pas besoin de refaire ce travail si vous voyez ce résultat dans votre feuille de calcul Excel, il se peut qu’il y ait un écart, non? Cela peut être une erreur dans votre processus. Vous pourriez finir par refaire les mêmes choses.

Pour la documentation, vous pouvez utiliser uniquement un commit Git. Lorsque vous validez votre résultat, ce qui signifie que vous validez le pipeline, vous validez une version de votre ensemble de données et le résultat en sortie, vous mettez un message. Un message dans Git car il s’agit d’une forme très simple de documentation. C'est en fait un très puissant. Ce que fait le DVC, il le fait essentiellement pour les projets de données. Dans notre flux de travail standard, vous pouvez valider du code, mais vous n’avez pas de connexion avec les données, vous n’avez pas de connexion claire avec vos métriques de sortie. Parfois, vous n’avez même pas de connexion avec vos pipelines. Parce que cette validation peut être liée à un changement particulier, une partie particulière du pipeline sera exécutée, et non le pipeline entier.

Tobias:

Et en ce qui concerne les mesures que vous suivez, pouvez-vous parler un peu de la manière dont elles sont capturées et de la manière dont elles sont prises en compte dans le cycle global d’évaluation et d’expérimentation pour vous assurer que le modèle produit les types de sorties que vous avez définies? êtes désirant et le projet global?

Dmitry:

DVC est un outil numérique agnostique et un framework agnostique. Le format DVC est également agnostique. Cela signifie que nous suivons les métriques dans de simples formes de fichiers texte. Vos métriques sont des fichiers TSV avec un en-tête, un fichier CSV ou un fichier JSON. Lorsque vous venez tout juste de sortir, nous avions cinq métriques avec cette valeur, et le DVC vous permet de consulter l'ensemble de vos expériences, quelles métriques ont été produites, vous pouvez constater que cette idée, par exemple, a échoué, car les métriques n'étaient pas parfaites, effectivement produit une meilleure métrique avait un bon moyen. Et vous avez probablement besoin de plonger profondément dans ces expériences.

Ainsi, il affiche les métriques de vos branches, de vos commits, et vous aide fondamentalement à naviguer dans votre arborescence de structure complexe de Git par métriques. C’est un moyen basé sur les données de naviguer dans votre référentiel Git. Dans un projet de données, vous pouvez avoir des milliers de validations, des centaines de milliers de branches. DVC vous aide essentiellement à naviguer à travers cette structure complexe. C’est la raison pour laquelle nous avons besoin de métriques, c’est le DVC qui dispose d’un support particulier pour les métriques.

Tobias:

Existe-t-il un support intégré permettant de rechercher parmi ces valeurs de mesure et de les comparer entre les branches? Ou est-ce quelque chose que vous auriez besoin de mettre en œuvre projet par projet en ce qui concerne un appel de fonction spécifique qui détermine, vous savez, s’il s’agit d’une valeur positive ou négative entre ces différentes comparaisons.

Dmitry:

Aujourd'hui, nous montrons essentiellement les métriques. Si vous devez naviguer, vous devez implémenter correctement quelque chose, mais je ne serais pas surpris que nous implémentions une logique spécifique à une métrique logique, par exemple, affichez-moi la valeur maximale de cette métrique particulière. Montrez-moi une valeur maximale de la combinaison de ces mesures, quelque chose comme ça.

Tobias:

Outre le contrôle de version généralement utilisé pour les applications logicielles classiques. Plusieurs autres types d’outils sont également utiles pour s’assurer que les projets que vous construisez sont sains et que vous n’avez pas de régression de code. Donc, des choses comme des peluches ou des tests unitaires sont supportées. Et je me demande quelles sont les préoccupations adjacentes à prendre en compte lors de la création de projets d’apprentissage automatique? Le travail que vous effectuez avec DVC ou l’un de vos autres projets est-il lié à cela?

Dmitry:

C'est une bonne question. Parce que, en général, les jeux d’outils dans les projets de données n’ont pas le même état que les outils définis pour les projets logiciels. C'était dans une interview avec West McKinsey, il y a environ un mois. Il a dit qu'en science des données, nous sommes toujours dans le Far West. C’est en fait ce qui se passe (rire), nous n’avons pas beaucoup d’assistance pour de nombreux scénarios.

Mais du point de vue des outils, ce que je vois aujourd’hui, c’est devenu, il est assez mature en termes d’algorithmes. Parce que nous avons PyTorch, nous avons TensorFlow, nous avons beaucoup d’autres algorithmes, comme des algorithmes basés sur des arbres aléatoires. Aujourd'hui, il existe une course aux outils de surveillance en ligne. Par exemple, TensorBoard, lorsque vous pouvez signaler vos métriques en ligne lorsque vous vous entraînez et voir ce qui se passe actuellement dans la phase de formation. C'est particulièrement important pour l'apprentissage en profondeur car les algorithmes sont encore assez lents, je dirais qu'ils sont une multitude de produits commerciaux dans cet espace, et MLflow, l'un des projets open source, qui devient populaire, ce qui vous permet de suivre vos métriques et visualisez le processus de formation. C'est une tendance aujourd'hui.

Une autre tendance est de visualiser vos modèles, de comprendre ce qu’ils contiennent. Encore une fois, il existe toute une panoplie d’outils pour le faire, mais l’état de cet outil n’est toujours pas parfait. En termes de tests unitaires, vous pouvez utiliser uniquement un test standard, uniquement le cadre de tests unitaires standard. Mais je ne peux pas dire que cela fonctionne très bien pour les projets ML, en particulier, ce que j’ai vu à maintes reprises est un test unitaire ou probablement non pas unitaire, mais des tests fonctionnels pour l’ingénieur de données. Dans la partie ingénierie des données, lorsque de nouveaux ensembles de données sont entrés dans votre système, vous pouvez obtenir des métriques de base et vous assurer qu'il n'y a pas de dérives dans les métriques, ce ne sont pas de gros changements de la métrique. Voilà comment le test unitaire, ou du moins le test, peut fonctionner dans le monde des données. Mais les outils en général sont toujours dans le Far West.

Tobias:

Passons à la version des données intégrée au DVC. Lors de la lecture de la documentation, il est mentionné que les fichiers de données eux-mêmes sont stockés dans des systèmes externes, tels que S3, Google Cloud Storage ou quelque chose comme NFS. Je me demande donc si vous pouvez expliquer comment DVC gère réellement les différentes versions de ces données et tout type de modifications incrémentielles qu’il est en mesure de suivre, ou toute difficulté rencontrée lors de la création de ce système. en l'intégrant au contrôle logiciel que vous utilisez, Git pour dans la structure globale du projet?

Dmitry:

Oui, bien sûr, nous n’engageons pas de données (rires) dans le référentiel, nous transmettons les données à vos serveurs, à vos clouds, et vous pouvez les reconfigurer pour les transférer vers le cloud. Comme indiqué précédemment, nous traitons les données comme des blobs binaires. Pour chaque commit particulier, nous pouvons vous apporter les jeux de données réels et tous les artefacts de données utilisés. Nous ne faisons pas de diffs par fichier, car vous devez comprendre la sémantique du fichier pour pouvoir faire des diffs, c'est vrai, ce n'est pas un diff. Dans un fichier Git, chaque fichier a du sens.

En science des données, vous devez savoir quel est le format exact du fichier de données que vous utilisez. Cependant, nous suivons les répertoires en tant que types distincts de structure. Si vous avez un répertoire avec imaginons 100 000 fichiers, et que vous ajoutiez ensuite quelques fichiers supplémentaires dans un répertoire et commettiez qu’il s’agissait d’une nouvelle version de votre ensemble de données, nous comprenons que seule une petite partie de notre fichier a été modifiée, disons 2000 fichiers ont été modifiés et 1000 ont été ajoutés, puis nous avons mis la version à jour, de sorte que vous puissiez facilement ajouter vos étiquettes dans votre base de données une fois par semaine sans vous soucier du cycle de votre annuaire. Nous effectuons ce type d'optimisation.

Une autre optimisation importante que nous faisons est l'optimisation de votre espace de travail. Lorsque Git extrait des fichiers de notre structure interne, il en crée une copie dans votre espace de travail. Toutefois, dans un monde de données, cela n'a parfois aucun sens, car vous ne voulez pas créer une copie de 100, disons des gigaoctets de données, copie. Nous optimisons ce processus en ayant une référence.

Donc, vous ne faites pas la duplication de jeux de données. Donc, vous pouvez facilement travailler avec des centaines de giga-octets, des dizaines de giga-octets sans cela.

Tobias:

Pour quelqu'un qui participe à un projet existant. Et ils ne font que vérifier l'état du référentiel pour la première fois. Existe-t-il une capacité suffisante pour pouvoir dire que je veux seulement extraire le code, je ne suis pas encore prêt à extraire toutes les données, ou Je veux juste extraire un sous-ensemble de données, car quelqu'un qui travaille sur un ensemble de données de plusieurs centaines de gigaoctets ne veut pas nécessairement que tout cela se trouve sur son ordinateur portable au cours de ces expériences. Simplement curieux de savoir à quoi ressemble ce flux de travail global lors de la formation des modèles lorsque vous travaillez en local, comment il gère et interagit avec ces référentiels de données volumineux pour s’assurer qu’il ne se contente pas de remplir complètement votre disque local.

Dmitry:

C'est une bonne question. Nous faisons cette traction granulaire, nous l'optimisons aussi. En tant que scientifique, vous pouvez décider de ce dont vous avez exactement besoin. Par exemple, si vous souhaitez déployer votre modèle, qui ne dépasse probablement pas 100 mégaoctets, vous n’avez probablement pas besoin de perdre du temps pour le jeu de données de 100 Go, utilisé pour produire le modèle.

Ensuite, vous pouvez spécifier n'importe quoi dans le fichier de données, comme cloner un nouveau référentiel avec un code et des métadonnées. Ensuite, dites que j'ai juste besoin d'un fichier de modèle. Tous les fichiers de modèle seront livrés à votre système de production sur votre machine de déploiement et les mêmes jeux de données.

Tobias:

Il existe d’autres projets dont j’ai parlé, avec des personnes qui les construisent, tels que Quilt ou Pachyderm qui prennent en charge de manière intégrée la version des données. Je me demande si vous envisagez actuellement de travailler à l’intégration avec ces systèmes ou si vous envisagez uniquement le processus général de l’ajout d’un support supplémentaire pour le composant de stockage de données de DVC?

Dmitry:

Une partie de l’intégration système peut être facilement réalisée, par exemple, Pachyderm est un projet, il s’agit essentiellement d’ingénierie de données. Ils ont un concept de nos pipelines, une sorte de pipelines de données. Le DVC peut être utilisé dans un pipeline d'ingénierie de données. Il a la notion de pipelines ML, un concept léger. Optimisé spécifiquement pour les ingénieurs en apprentissage machine, il n’a pas toute cette complexité des pipelines d’ingénierie de données, mais il peut facilement être utilisé en une seule étape et en tant que pipeline d’ingénierie.

Nous avons vu cela à plusieurs reprises, lorsque les gens prennent, par exemple, un pipeline de DVC, et le placent dans AirFlow en une seule étape. Avec ce type de conception, c’est une bonne conception, car vous offrez un outil léger aux ingénieurs et aux spécialistes de l’informatique de ML, qui peuvent ainsi facilement produire un résultat. Ils peuvent itérer plus rapidement afin de créer leurs emplois. Vous avez un système de production avec DVC peut être facilement injecté à l'intérieur.

Il y a un terme que je ne me souviens pas quelle utilisation de l'entreprise. Netflix, probablement - ponts à l'intérieur du pont; ce qui signifie que vous avez un paquet de pipelines de données, et que vous avez un paquet ML pour un problème particulier, puis que vous injectez en fait beaucoup de paquets ML à l'intérieur du paquet d'ingénierie de données. Ainsi, de ce point de vue, l’intégration à Pachyderm, AirFlow ou d’autres systèmes ne pose aucun problème d’intégration. En ce qui concerne les données Quilt, elles gèrent le versioning, elles fonctionnent également avec S3. Nous pouvons éventuellement le faire et nous pouvons être intégrés à celles-ci. Nous réfléchissons à cela, nous essayons d’être axés sur le consommateur. Le besoin le plus important aujourd’hui est probablement l’intégration à MLflow, car ce dernier est très efficace dans le suivi des mesures en ligne. Parfois, les utilisateurs préfèrent utiliser MLflow pour le suivi, le suivi des mesures en ligne et DVC pour la gestion des versions de fichiers de données. C’est l’une des intégrations auxquelles nous pensons aujourd’hui.

Tobias:

Pour ce qui est de l’implémentation réelle de DVC, je sais qu’il est principalement écrit en Python. Et vous avez mentionné que cela tenait en grande partie au fait que cela devenait la lingua franca des scientifiques de données. Je me demande donc si, maintenant que vous êtes allé un peu plus loin dans la mise en œuvre et la maintenance globales du DVC, si vous pensez que cela reste le bon choix? Si vous deviez recommencer aujourd'hui, que feriez-vous différemment selon que vous choisissiez la langue, la conception du système ou la structure générale du projet?

Dmitry:

Je pense que Python est un bon choix pour ce type de projets, pour deux raisons principales. Premièrement, nous ciblons les scientifiques de données et la plupart d’entre eux maîtrisent bien Python. Nous nous attendons à ce que les scientifiques de données contribuent à notre base de code. Si vous écrivez ce type de projet en, disons C ou C ++, ou Golang, vous ne verrez probablement pas beaucoup de contribution de la part de la communauté. Parce que la communauté parle des langues différentes. Pour nous, pour des travaux parfaits, les scientifiques de données contribuent au code, ce qui est génial (rires).

Et la deuxième raison était la programmation des API. Auparavant, nous envisagions de créer un DVC via des API, une autre option permettant d’utiliser le DVC. Et si vous écrivez du code en Python, il se trouve en quelque sorte hors d'usage, vous pouvez réutiliser le DVC en tant que bibliothèque et l'injecter dans votre projet. Si vous utilisez un autre langage, il vous suffit de créer des frais généraux, vous devez réfléchir à ceux-ci sous une forme agréable. C'étaient les raisons. Jusqu'ici, nous sommes heureux Python et cela fonctionne si bien.

Tobias:

Vous avez mentionné que l’utilisation de DVC est aussi une bibliothèque. Je me demande donc si vous avez déjà vu des cas d’utilisation particulièrement intéressants, inattendus ou nouveaux dans ce cas d’utilisation de la bibliothèque ou simplement dans le sens de la ligne de commande qui a été conçu à l’origine.

Dmitry:

Parfois, vous demandez un soutien à la bibliothèque, car ils doivent implémenter des scénarios plus fous (rire). Je peux dire, par exemple, que les gens utilisent DVC pour créer leurs propres plates-formes. Si vous le souhaitez, ils souhaitent également créer des infrastructures d’intégration continue, lorsque DVC joue dans un tel contexte. expérience, et ils demandent des bibliothèques, mais nous avions un si grand ensemble d’outils de ligne de commande pour le support en ligne de commande, et les utilisateurs revenaient simplement à une expérience en ligne de commande. Mais un jour, je ne serai pas surpris que quelqu'un utilise le DVC comme une bibliothèque.

Tobias:

Je suis également intéressé par le fait que vous parliez de la possibilité d’intégrer le DVC dans des pipelines d’ingénierie de données en encapsulant une seule étape de mise en œuvre pour exécuter le modèle de formation. Je me demande donc si vous pouvez en dire un peu plus à ce sujet et à certaines des implémentations spécifiques que vous avez vues.

Dmitry:

Oui, absolument. C'est en fait une très bonne question. Je crois que les ingénieurs de données ont besoin de pipelines, non? Les scientifiques de données et les ingénieurs en apprentissage automatique ont besoin de pipelines. Mais le fait est que leurs besoins sont absolument différents. Les ingénieurs de données se soucient des systèmes stables. En cas de défaillance, le système doit faire quelque chose, il doit récupérer. Ceci est un objectif principal du cadre d'ingénierie de données.

Dans la science des données, cela fonctionne en quelque sorte en sens inverse. Vous échouez tout le temps (rire). Lorsque vous avez une idée, vous écrivez du code qui exécute un score qui échoue, vous pensez que cela a échoué, etc. Votre objectif est de créer un cadre pour vérifier les idées rapidement, pour échouer rapidement. C'est l'objectif des ingénieurs de ML. C'est une bonne pratique de séparer deux cadres ayant deux types de cadres de pipeline. L’un est l’ingénierie stable et le second un pipeline d’expérimentation rapide et léger, si vous le souhaitez.

Lorsque vous séparez ces deux mondes, vous simplifiez beaucoup la vie des ingénieurs de ML. Ils n'ont pas besoin de faire face à des choses compliquées, nous n'avons pas besoin de perdre du temps à comprendre comment AirFlow fonctionne, comment Luigi fonctionne, ils vivent dans leur monde, produisent des modèles, et une fois que le modèle est prêt, ils ont besoin d'un aperçu clair. manière à injecter ce pipeline dans des pipelines de données. Pour ce faire, vous pouvez créer un outil très simple. Ainsi, je me souviens que lorsque je travaillais chez Microsoft, il m’a peut-être pris environ deux heures pour produire mon pipeline. Comme j'ai un flux de travail distinct, j'avais un outil séparé pour les pipelines ML. Cela fonctionne bien. Je crois en ce genre de futur ingénieur, il faut séparer ces deux choses.

Tobias:

Je suis également intéressé par les capacités de déploiement fournies par DVC dans la mesure où il est possible de mettre des modèles en production ou d'inverser l'état du modèle dans le cas où il produit une sortie erronée ou que les prédictions que les résultats fournies fournissent des problèmes aux entreprises ou à une partie seulement de l’outillage et du flux de travail impliqués dans l’exécution de modèles d’apprentissage automatique en production, et en particulier en ce qui concerne le suivi des mesures pour savoir quand le modèle doit être recyclé et achevé, bouclant ainsi la boucle de ce processus global de construire et de déployer ces modèles.

Dmitry:

Ouais, déploiement, nous attendons de le recevoir car il est proche des affaires. Et il y a une petite histoire amusante sur le déploiement du modèle ML. Parfois, cela ressemble à ceci - un ingénieur en logiciel et une équipe de science des données, pouvons-nous faire plus de révision de notre modèle par rapport au modèle précédent, mais au modèle de la semaine précédente? Et les scientifiques de données aiment - Ouais, bien sûr, nous avons des jeux de données, et vous avez besoin de cinq heures pour le recycler (rires).

Cela n’a aucun sens de passer cinq heures trois comme un modèle dans le monde du génie logiciel, cela ne fonctionne pas de cette façon. Vous devez avoir tout disponible. Vous devez l'examiner immédiatement, car attendre cinq heures signifie gaspiller de l'argent pour les affaires.

DVC vous aide fondamentalement à organiser ce processus, il aide, il crée essentiellement un langage commun entre vos informaticiens qui produisent un modèle et les ingénieurs de ML qui prennent des modèles et les déploient. Ainsi, la prochaine fois, avec une gestion de données appropriée, vous ne demanderez même plus à l'informaticien de vous donner un modèle précédent, vous devriez avoir tout dans votre système avec DVC ou non, peu importe ce que vous devez avoir l'artefact disponible.

Du point de vue du suivi des mesures en ligne, il s'agit en fait d'une question distincte. Parce que lorsque vous parlez de suivi des mesures, en production, cela signifie généralement des mesures en ligne. Il s’agit généralement de mesures basées sur les commentaires des utilisateurs. Ceci est une question distincte. Donc, le DVC concerne principalement le déploiement ou non, principalement la phase de développement. Il ne fait rien fondamentalement avec les métriques en ligne.

Tobias:

Donc, vous construisez et maintenez ce projet sous les auspices d’iterative.ai, qui est en réalité une entreprise financée par du capital-risque. Je suis donc curieux de savoir quelle est l’équation globale de la valeur pour vos investisseurs, ce qui leur vaut la peine de financer vos efforts pour construire et publier ce projet open source. Et juste la stratégie globale que vous avez pour l'entreprise.

Dmitry:

You would be surprised (laughs) how investors are interested in open source projects today, especially the last year was super successful for open source projects. Last year, Mulesoft was acquired for numbers of millions or billions, sorry, last year Elastic Search went IPO. It’s purely open source company.

And when you do open source, it usually means that you are doing IT infrastructure. In many cases, you are doing IT infrastructure, they are good for monetization. With a successful open source project, that bunch of companies, which are monetizing this open source, it’s very important to understand your business model, because with open source there are a few common models.

One is a service model, a kind of consultancy model. The second thing is open core model, when you build software, and produce a piece of the software with advanced feature for money, or a different version of your software, as a product for enterprises.

And the third model is ecosystem. When you build a product, an open source product and create services as a separate product. One example might be Git and GitHub, when they have open source and SaaS service, which is absolutely different product is absolutely different experience and use cases. You need to understand which model you fit in. For successful project to be a lot of wish to interested in this experience in this kind of businesses.

Initially, I started the project as it was my pet project for about a year. And then I was thinking — how to make something big out of this, how to spend more time on this, how to find more resources in order to do this. It was clear that this project if it’s successful, there will be a few businesses monetizing this area. Why don’t we be this business, which builds a product and monetize this product. So it’s a natural path for a modern open source world, I would say.

Tobias:

As far as the overall experience of building and maintaining the DVC project and the community, I’m wondering what you have found to be some of the most interesting or challenging or unexpected lessons learned in the process.

Dmitry:

One of the lesson that I learned, I think it’s a usual business lesson, actually. So when you build your project, you know what you do, you know, your roadmap, you know your goal, and you’re just building, but one day users came to you. And they asked for a lot of different stuff.

Then you have tension, you have tension between your vision, your plans and demands from user side. And today, where is the point when everyday, we have a few requests from users sometimes, so we had like 10 requests per day (laughing). It’s not easy to balance the things. Because if you if you do everything people ask, you have no time for your roadmap. And actually, you have no time to fix and to implement everything that people asked. So you need to learn how to prioritize things. You need to learn how to say it, sometimes say no to users and say we will do this, but probably not right now. So this is not easy to do. This is what you need to learn during the process. As I said, the software experience in open source, it was the same as the same way in the business environment. I have seen that for many times.

Tobias:

Looking forward in terms of the work that you have planned for DVC, I’m curious what types of features or improvements that you have on the roadmap.

Dmitry:

Features for the near future, we are going to release better support for datasets versioning, and ML model versioning. We are introducing newcomers into DVC, which simplify your experience today. some companies are using mono-repos with a bunch of data sets inside. We need new commands to do something better, sometimes because these datasets are evolving in a different speed. You need to work with one version your those dataset, one version with others, sometimes. So basically, this is one of the steps we are taking.

And the another use case for data sets is a cross repository references. Other companies are not using the mono-repo, they’re using set of repos. For example, they might have like 10, 20 repos with data sets and 20 more with models. They need to cross-reference datasets, this is the next command we are going to implement to support this cross-reference, cross repository scenarios. This is our near future.

And in longer vision, the next step would be implementing more features for better experiment support, especially when people deal with such scenarios as hyper-parameter tuning. They need to have let’s say 1000 experiments. And they need to still control them. They don’t want to have 1000 branches (laughing).This is this experience we need to improve. We have a clear plan on how to do this. And this pretty much is for the next maybe half a year. Eventually we believe that the DVC can be this platform, when people can work on the same environment in one team and share ideas between each other. In the future we believe we can create experiences, great experience when people can share ideas, even between companies, between teams.

This is the big future of DVC that I believe in.

Tobias:

Are there any other aspects of the work that you’re doing on DVC or the overall workflow of machine learning projects that we didn’t discuss yet do you think we should cover before we close out the show?

Dmitry:

I don’t they have something to add. But what I believe in, is that we need to pay more attention on how we organize our work. We need to pay more attention how we structure our project, we need to find more places when we waste our time instead of doing actual work. And this is very important to be more organized, more productive as a data scientist, because today we are still on the Wild West, this needs to be changed as soon as possible. It is important to pay attention to this, it’s important to understand this problem set.

Tobias:

All right. Well, for anybody who wants to follow along with the work that you’re doing or get in touch I’ll have you add your preferred contact information to the show notes. And so with that, I’ll move us into the pics and this week, I’m going to choose a tool that I started using recently and experimenting with called otter.ai.

And it’s billed as a voice note taking service that will transcribe your meeting notes or just mental notes to yourself to text so that they’re searchable. And I’ve been experimenting with using it to try out generating transcriptions for the podcast. So looking forward to start using that more frequently and starting transcripts to the show. So definitely worth checking out if you’re looking for something that does a pretty good job of generating transcripts automatically and at a reasonable price. So with that, I’ll pass it to you to meet you. Do you have any pics this week?

Dmitry:

So I thought the open source part and open source vs. venture capital is a question that we will discuss. Actually, I have nothing special to suggest but today it’s a nice weather. Spring just started. So just spent more time outside the region outside and walking around the city or town.

Tobias:

All right, well, thank you very much for taking the time today to join me and discuss the work that you’re doing on DVC and adding some better structure to the overall project development of machine learning life cycles. So thank you for that. I hope you enjoy the rest of your day.

Dmitry:

Oh, thank you, Tobias. Je vous remercie.

Conclusion

https://dvc.org/

We need testing and versioning to understand what we’re doing. When we are programming we’re doing a lot of different things all the time, we are testing new things, trying new libraries and more, and it’s not uncommon to mess things up. It’s the path of data science, fail fast and iterate to success.

DVC is one of the best tools we have at the moment for controlling your data projects, and as you can see it can be connected with other great tools. I hope this interview and article helped you get started with them.

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close