Vous avez installé KubeFlow, par exemple avec GCP car c’est trivial. Et maintenant, vous êtes perdus dans l’interface. Pas de panique, nous allons parcourir tout cela ensemble.
Durant le précédent article, vous êtes arrivés à créer une instance KubeFlow.
Nous allons maintenant voir la suite, une fois que vous avez cliqué sur “ouvrir le tableau de bord des pipelines“. Le tableau de bord est constitué d’un menu avec plusieurs entrées, notamment Pipelines, Experiments, Artifacts et Executions. Hors GCP, tous ces principaux concepts resteront les mêmes puisqu’en fait Google a déployé uniquement un seul composant KubeFlow open source : KubeFlow Pipelines.
Introduction aux concepts
Un pipeline est un ensemble de tâches. Pour KubeFlow, cet ensemble est décrit, dans le cas simple, par un seul fichier YAML. Chaque tâche va s’effectuer dans un container, orchestré par Kubernetes. L’évolution du pipeline est historisée via des versions.
Un pipeline est lancé via des runs. Un run est un lancement qui peut être ponctuel ou ordonnancé avec certaines règles, par exemple une expression cron. Les runs sont regroupés au sein d’un experiment. Celui-ci permet de simplifier la compréhensions des runs, notamment dans le cas de run récurrents.
Chaque run est composé d’un ensemble d’exécutions qui correspondent à la réalisation des différentes tâches. Un run peut produire des artifacts ainsi que des metrics.
Les artifacts sont des données exportées par le pipeline qui sont directement interprétables par KubeFlow et pourront être visualisées, au cas par cas. Il est notamment possible de visualiser le lineage, c’est à dire quels artifacts ont été utilisés par quelles tâches afin de produire quels autres artifacts.
Dernier point, un run peut être archivé. Aucune donnée n’est véritablement supprimée. Cela permet simplement de se concentrer sur les runs encore utiles à regarder.
Navigation dans le menu
L’onglet Pipelines permet d’afficher la liste des pipelines enregistrés, ainsi que leurs versions. Il est possible de les filtrer via une recherche sur leur nom, d’uploader manuellement un pipeline et de supprimer un ou des pipelines.
En cliquant sur le nom du pipeline ou de sa version, l’enchaînement de ses tâches est affiché sous forme d’un graphe. Il s’agit simplement d’une représentation graphique du fichier YAML qui est aussi affichable dans son ensemble. Et pour faciliter sa lecture, il est possible d’afficher la configuration d’une seule tâche , qui elle aussi est une fraction de ce même fichier YAML.
A partir de cette vue, il est possible de lancer le pipeline en créant un run, d’uploader une nouvelle version pour ce pipeline, de créer un experiment ou encore de supprimer le pipeline.
L’onglet Experiments va afficher les runs regroupés par experiment, celui par défaut étant “Default“.
Plusieurs runs peuvent être comparés afin d’analyser, par exemple, leurs paramètres de lancement. Un run peut être cloné afin de faciliter le lancement d’un run similaire en repartant de la même configuration. Tout comme avec la vue d’un pipeline, il est aussi possible de créer un run ou experiment à partir de cette vue. Et bien que la liste soit paginée, les runs peuvent être archivés afin de la rendre encore plus lisible.
Cliquer sur un run affiche le détail. C’est similaire à l’affichage d’un pipeline mais avec un focus ici sur le déroulé de son lancement. C’est particulièrement utile pour trouver les logs et isoler les problèmes éventuels.
Typiquement, dans ce cas, le run est en erreur car toutes les APIs nécessaires n’ont pas été autorisées.
En cas de succès du run, des artifacts ont pu être générés. Ceux-ci sont visible grâce à l’onglet Artifacts.
En cliquant sur le groupe, il est possible de visualiser le lineage, c’est à dire le lien entre toutes les données qui ont été générées. Cet extrait montre un processus de décision classique dans le cadre de TFX.
Typiquement, un validator utilise le dataset (examples) et le modèle appris pour vérifier si le modèle est de qualité suffisante pour être pertinent. Dans ce cas, l’information peut être passée au pusher qui va publier le modèle. Bien que l’on montre ici un exemple avec TFX, les concepts d’artifact et de lineage n’ont pas de liens directs avec TFX. Ils peuvent être utilisés quelle que soit la technologie.
Il reste quelques onglets. Executions affiche quelques informations sur les tâches lancées et Archive permet de visualiser les runs archivés et les restaurer. Mais ce ne sont pas des informations que vous allez manipuler tout le temps.
Enfin les onglets Documentation, GitHub Repo et AI Hub Samples pointent respectivement vers la documentation officielle de KubeFlow, le code officiel de KubeFlow puis la communauté d’échange de datasets, notebooks et autres soutenue par Google. Ce sont des sources à consulter, particulièrement les deux premières, pour en savoir plus sur le fonctionnement interne de KubeFlow
Conclusion
Les concepts manipulés par KubeFlow Pipeline sont simples. Si vous avez déjà manipulé une plateforme data-science, il n’y a pas de grande surprise. Bien que le composant KubeFlow Pipeline soit toujours en bêta, il est intéressant de voir qu’en l’état, il apporte déjà de la valeur. Ainsi si vous souhaitez créer votre propre plateforme data-science, il faut vraiment se poser la question d’utiliser KubeFlow Pipeline directement. Sinon cela veut dire recréer, dans votre coin, beaucoup de concepts qui sont déjà maintenus par une communauté. Et actuellement il n’existe pas de plateforme data science open source avec le même scope et degré de maturité.
Maintenant que nous avons pu faire un premier tour de KubeFlow Pipeline, nous allons pouvoir finalement créer notre propre pipeline dans un prochain article et manipuler directement tout ces concepts.