L’essentiel sur le Feature Store et ses usages

Qu’est-ce qu’une feature ?

Pour ce faire, l’on peut s’en remettre à l’utilisation du terme par Chistopher Bishop, directeur de laboratoire chez Microsoft Research à Cambridge, au Royaume-Uni et professeur honoraire de sciences computationnelle à l’Université d’Édimbourg, dans son livre Pattern Recognition and Machine Learning, publié en 2006. En statistiques, dans le machine learning et la reconnaissance de motifs, une feature (variable ou caractéristique en français) est une « une propriété individuelle mesurable ou une caractéristique d’un phénomène ». Dans sa documentation, DataRobot simplifie la définition en expliquant qu’une feature est une « propriété mesurable de l’objet que vous essayez d’analyser ».

Selon l’éditeur, qui grossit légèrement le trait, les colonnes dans un jeu de donnée correspondent à des features. Les ingénieurs illustrent leur propos en recourant à une capture d’écran du jeu de données Titanic, bien connu des aspirants en data science. Ici, les caractéristiques sont le nombre de passagers à bord, la classe de leur billet, leur sexe, leur âge, ou encore leur survie (ce sont là les features les plus utilisées pour s’exercer à diverses méthodes de classification et de régression).

En clair, la feature, c’est une donnée utilisée comme un signal d’entrée d’un algorithme pour calculer ou prédire un résultat. Cela peut être un mot, un groupe de pixels, un champ dans un fichier, une donnée issue d’un capteur, etc. Reprenons le dataset Titanic. Un exercice basique consiste à se demander combien de passagers survivent au naufrage du paquebot. Ici, l’analyse repose sur la combinaison de deux caractéristiques. Il est possible d’ajouter des variables comme le sexe et la classe de la cabine pour obtenir un résultat plus détaillé. L’on peut par exemple se poser la question du nombre de femmes âgées de 18 à 25 ans ayant un billet de troisième classe qui ont survécu à la catastrophe.

Qu’est-ce que le Feature Engineering ?

Or la plupart du temps, les data scientists manipulent des données brutes. Ces variables ne sont pas clairement visibles du premier coup d’œil ou les valeurs associées ne sont pas toutes réunies dans une colonne. Il faut donc les extraire et les nettoyer, puis les adapter à un algorithme spécifique. Cette pratique se nomme le Feature Engineering.

Ces variables affinées doivent être testées et combinées au moment de l’entraînement d’un modèle. Il s’agit d’obtenir des résultats satisfaisants suivant des critères de généralisation, de précision et de performance. Si les qualités du modèle sont adéquates, il peut être déployé en production. Mais là encore, il lui faudra l’alimenter de ces fameuses features pour qu’il s’exécute correctement.

En outre, le choix des bonnes caractéristiques est un processus itératif qui demande une rigueur importante, afin de classer les résultats des différentes expériences et les données associées. D’autant qu’une feature ne joue pas le même rôle suivant l’algorithme ou le modèle de machine learning appliqué.

C’est à ces deux problématiques que doit répondre le Feature Store.

Qu’est-ce qu’un Feature Store ?

Dans son essence, un Feature Store est « une couche de gestion de données (la sortie d’un lac de données) qui permet aux data scientists et aux data engineers de partager et de découvrir des caractéristiques », selon Daniel Kobran, cofondateur de Paperspace, une plateforme cloud dédiée au traitement de machine learning.

Plus spécifiquement, il s’agit de centraliser des jeux de données triés sur le volet et cohérents avec la tâche de machine learning ou de deep learning à accomplir. « Cette couche permet de mettre en œuvre une traçabilité complète, ainsi que la conformité et l’évolutivité, de la source des données au résultat final », ajoute Daniel Kobran dans l’AI Wiki publié sur le site web de Paperspace.

Paul Séguineau, directeur général France chez Ekimetrics, un cabinet de conseil spécialisé en science des données et en IA, confirme cette définition et évoque les possibles bénéfices d’une telle approche.

« Avec un Feature Store, nous allons être capables d’industrialiser rapidement et de manière pérenne un certain nombre de projets data », déclare-t-il. « Plusieurs études font le constat que la donnée est devenue critique et il n’y aurait que 40 % des projets qui passent en production. Globalement, un Feature Store permet de faciliter l’exploitation des librairies de machine learning et de fournir des éléments sur étagère que les data scientists peuvent utiliser tout en s’assurant qu’il y ait une forme de cohérence dans les traitement qu’ils mettent en place », indique le dirigeant.

Ekimetric a d’ailleurs déployé « un Feature Store en interne » qui dans son travail auprès de ses différents clients, « l’aide à choisir les features des algorithmes suivant le contexte et le cas d’usage ».

Mais si les responsables de Paperspace et Ekimetrics sont capables d’expliquer simplement l’usage d’un Feature Store, il a principalement été popularisé par les ingénieurs d’Uber qui ont défini une architecture à partir de mi-2015. Selon les informations fournies par les équipes d’Uber, ce Feature Store désormais baptisé Palette est probablement né dans le courant de l’année 2016. Il s’agit d’un composant d’une plateforme de data science nommée Michaelango. Ce « mix de technologies open source » (HDFS, Cassandra, Kafka, Spark, etc.) permet non seulement de bâtir une architecture de stockage et de traitement de données, de supporter les librairies et les frameworks de machine learning, mais aussi de stocker les fameuses caractéristiques.

Si de prime abord une base de données ou un cube lié à un datawarehouse semble pouvoir faire l’affaire, les travaux des ingénieurs d’Uber ont quelque peu défini le standard de ce que l’on appelle un Feature Store aujourd’hui.

Deux types de traitement, deux bases de données

Bien avant que l’approche MLOps gagne en popularité, Uber avait déjà besoin d’administrer et de déployer des modèles de machine learning et de deep learning selon une démarche « bout en bout ». En consultant le document d’architecture, l’on s’aperçoit qu’il n’y a pas un, mais deux Feature Store. Les ingénieurs expliquent que son équipe de data science souhaitait à la fois entraîner (model training) et déployer (model serving) des modèles de prédiction en batch et en temps réel.

Ainsi, des pipelines de préparation de données par-dessus le data lake nourrisse un Feature Store « offline » Hive, pour les traitements batch. Son équivalent « online » repose sur Cassandra (KV Store) pour les prédictions en temps réel (dont les résultats sont souvent affichés à des utilisateurs finaux) et tire ses flux de données depuis Apache Kafka et les transforme avec Flink. Dans cette architecture, les bases de données Apache Cassandra et Apache Hive partagent les mêmes variables. Un pipeline tiré de Hive vers Cassandra assure la synchronisation des features et de leurs métadonnées. En outre, la plupart des services communiquent entre eux permettant de déployer les différents modèles entraînés qui sont stockés dans un cluster Cassandra indépendant. De plus, les données de streaming sont accessibles pour entraîner un algorithme en batch. Les modèles peuvent être lancés en production en appelant les caractéristiques depuis le bon Feature Store, via des jobs Apache Spark ou Flink, suivant la situation.

En 2018, les ingénieurs d’Airbnb présentent Zipline. Son équivalent de Palette. Là encore, il s’agit d’un bout d’architecture comprenant un Feature Store online et l’autre offline. À l’époque, la différence principale entre les deux technologies dépend de la manière de synchroniser les features à l’aide de séries chronologiques et de pouvoir les combiner pour un même job. Databricks Twitter, Facebook, CondeNast, Comcast, Netflix ou encore Wix sont quelques-unes des entreprises référencées par le site featurestore.org, tenu par un groupe de chercheurs du KTH, l’Institut royal de technologie de Stockholm.

Puis, sont apparus les Feature Store open source « standalone », à savoir Hopsworks, par l’éditeur Logical Clocks et Feast, issu d’une collaboration entre Google et Gojek, une entreprise d’e-commerce indonésienne et Tecton, une entreprise lancée par certains des ingénieurs à l’origine de Palette. Feast reçoit le support de Redis qui est devenu la base de données sur laquelle repose le Feature Store en ligne depuis la version 0.11 en lieu et place de BigTable.

AWS propose un Feature Store propriétaire, perçu comme une forme d’extension à SageMaker. Tecton offre une version managée de Feast tout comme Google Cloud, Hopswork fait de même avec sa technologie. Redis se prépare à inclure son Feature Store online dans Redis Enterprise Cloud.

Les limites du Feature Store

Depuis 2015-2016, cette architecture spécifique s’est enrichie pour finalement inclure non seulement le stockage des variables, mais aussi la possibilité d’effectuer des ingestions, des transformations de données (agrégats, jobs ETL, jointures, etc.), d’enregistrer chaque utilisation des features dans un registre (via les métadonnées), d’exécuter le « serving », c’est-à-dire de réaliser les prédictions ou des entraînements depuis des données batch ou événementielles.

Mais toutes ces technologies ne sont pas totalement abouties. Si les grands principes d’architecture se valent, certaines solutions sont plus avancées que d’autres. Par exemple, Feast ne dispose pas encore de toutes les capacités nécessaires pour réaliser les traitements batch, si l’on en croit la documentation et les propos d’Ismaïl Lachheb, Software engineer et Data Scientist chez le cabinet de conseils Octo.

Chang She, VP Engineering chez TubiTV (auparavant ingénieur chez Cloudera), un concurrent américain de Molotov, lui déplore dans un article de blog que pour un même processus entre un traitement en temps réel et un autre en batch, il faille utiliser plusieurs langages de programmation et différentes API. De même, les cadres conceptuels que peuvent représenter Palette ou Zipline ne sont pas suffisants, puisqu’ils ont été pensés pour des cas d’usage spécifiques. Il manque selon lui une fonctionnalité pour assurer la confiance dans le traitement des features, mais aussi un bon nombre d’abstractions pour cacher la complexité des transformations et des composants requis aux data scientists.

Il faut dire que cette architecture est imaginée par des data engineers et des data scientists dont les projets de data science sont fortement évolués, alors que la majorité des entreprises commencent à peine leur aventure en data science.

Enfin, selon Paul Séguineau, le Feature Store est utile pour les équipes de data science, mais ne représente pas le saint Graal pour les sociétés. « Cela n’apporte pas intrinsèquement de la valeur à l’entreprise. Là où la différence se fait, c’est d’adopter dès le départ une stratégie autour de la mise en production et l’industrialisation des chaînes de traitement algorithmiques. Le Feature Store représente une petite portion de ce travail et peut servir à mieux traiter les données en amont. Aujourd’hui, chez nos clients ce sont des choses relativement immatures », constate-t-il.