tadata
← Retour à l'accueil

Feature Stores : L'Infrastructure Manquante du ML

#machine-learning#feature-store#data-engineering#mlops

Les feature stores résolvent un des problèmes les plus sous-estimés du ML : fournir des features cohérentes, fraîches et correctes aux modèles en entraînement comme en serving. Sans cette brique, les équipes reconstruisent les mêmes transformations et introduisent du skew.

Le Problème Central

tadata
Sans feature store ✗ Pipeline d'entraînement : requête SQL A ✗ Pipeline de serving : transformation PythonB (logique différente !) ✗ Résultat : skew entraînement/serving Avec feature store ✓ Pipeline d'entraînement : feature store(offline) ✓ Pipeline de serving : feature store(online), même logique, mêmes données ✓ Résultat : cohérence garantie
Sans feature store ✗ Pipeline d'entraînement : requête SQL A ✗ Pipeline de serving : transformation PythonB (logique différente !) ✗ Résultat : skew entraînement/serving Avec feature store ✓ Pipeline d'entraînement : feature store(offline) ✓ Pipeline de serving : feature store(online), même logique, mêmes données ✓ Résultat : cohérence garantie

Online vs Offline : Deux Modes de Serving

DimensionStore OfflineStore Online
UsageDonnées d'entraînement, scoring batchInférence temps réel
LatenceSecondes à minutes< 10 ms
StockageData lake / warehouse (Parquet, Delta)Key-value (Redis, DynamoDB)
VolumeMois/années d'historiqueDernières valeurs uniquement
FraîcheurBatch (horaire/quotidien)Quasi temps réel (streaming)
CoûtStockage élevé, calcul à la lectureCalcul élevé, stockage faible
tadata
txn_count_24h(feature) Labelled transactions 08:00 09:00 10:00 11:00 12:00 13:00 08:00 = 2 10:00 = 3 13:00 = 9 11:30 T1 legit 13:05 T2 fraud uses 3 uses 9
txn_count_24h(feature) Labelled transactions 08:00 09:00 10:00 11:00 12:00 13:00 08:00 = 2 10:00 = 3 13:00 = 9 11:30 T1 legit 13:05 T2 fraud uses 3 uses 9
Carte 42 : mises à jour de la valeur de la feature (ligne du haut) et deux transactions labellisées (ligne du bas). Chaque label ne peut voir que la dernière valeur de la feature à son propre horodatage ou avant

Extrait de la fiche « Feature Stores and Vector Databases » · Demander la fiche complète

Comparaison d'Outils

FonctionnalitéFeastTectonHopsworksVertex Feature Store
TypeOpen sourceCommercialOpen coreGéré (GCP)
Store OnlineRedis, DynamoDB, etc.GéréRonDBBigtable
Store OfflineBigQuery, Redshift, etc.GéréHudi sur S3BigQuery
StreamingVia Spark/FlinkNatifNatifDataflow
MonitoringBasiqueDétection de drift intégréeIntégréBasique
CoûtGratuit + infra$$$$ (enterprise)Gratuit + géréTarification GCP
Idéal pourBesoins simples, multi-cloudML temps réel à grande échellePlateforme ML complèteÉquipes GCP
tadata
Sources Transactions DB Event stream(Kafka) Warehouse tables Transform Batch transforms(SQL, Spark) batch Streamaggregations(Flink, Spark) stream Storage Offline store full history,timestamped Online store latest value per key,ms reads Serving Training point-in-time joins Online inference lookup by entity key Batch scoring Governance Feature registry Owners Lineage Freshness SLA Access control
Sources Transactions DB Event stream(Kafka) Warehouse tables Transform Batch transforms(SQL, Spark) batch Streamaggregations(Flink, Spark) stream Storage Offline store full history,timestamped Online store latest value per key,ms reads Serving Training point-in-time joins Online inference lookup by entity key Batch scoring Governance Feature registry Owners Lineage Freshness SLA Access control
Architecture d'un feature store : une définition, deux stores, deux consommateurs. Le même code de transformation alimente l'entraînement et le serving, ce qui supprime le training-serving skew

Extrait de la fiche « Feature Stores and Vector Databases » · Demander la fiche complète

Matrice de Décision d'Adoption

SignalScore (1-5)Poids
Nombre de modèles en production___3x
Équipes partageant des features___3x
Incidents de skew entraînement/serving___2x
Temps passé en plomberie feature engineering___2x
Exigences de serving temps réel___2x
Exigences de fraîcheur des données___1x

Interprétation : Total pondéré > 40 : besoin fort. 25-40 : à évaluer. < 25 : prématuré.

Quand NE PAS Construire un Feature Store

  • Vous avez moins de 3 modèles en production
  • Tous vos modèles sont batch (pas de temps réel)
  • Une seule équipe possède tout le ML sans partage de features
  • Vos features sont de simples lookups sans transformation

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.