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
SANS Feature Store : AVEC Feature Store :
Pipeline d'entraînement Pipeline d'entraînement
└── Requête SQL A └── Feature Store (offline)
Pipeline de serving Pipeline de serving
└── Transformation Python B └── Feature Store (online)
(logique différente !) (même logique, mêmes données)
Résultat : Skew entraînement/serving Résultat : Cohérence garantie
Online vs Offline : Deux Modes de Serving
| Dimension | Store Offline | Store Online |
|---|---|---|
| Usage | Données d'entraînement, scoring batch | Inférence temps réel |
| Latence | Secondes à minutes | < 10 ms |
| Stockage | Data lake / warehouse (Parquet, Delta) | Key-value (Redis, DynamoDB) |
| Volume | Mois/années d'historique | Dernières valeurs uniquement |
| Fraîcheur | Batch (horaire/quotidien) | Quasi temps réel (streaming) |
| Coût | Stockage élevé, calcul à la lecture | Calcul élevé, stockage faible |
Comparaison d'Outils
| Fonctionnalité | Feast | Tecton | Hopsworks | Vertex Feature Store |
|---|---|---|---|---|
| Type | Open source | Commercial | Open core | Géré (GCP) |
| Store Online | Redis, DynamoDB, etc. | Géré | RonDB | Bigtable |
| Store Offline | BigQuery, Redshift, etc. | Géré | Hudi sur S3 | BigQuery |
| Streaming | Via Spark/Flink | Natif | Natif | Dataflow |
| Monitoring | Basique | Détection de drift intégrée | Intégré | Basique |
| Coût | Gratuit + infra | $$$$ (enterprise) | Gratuit + géré | Tarification GCP |
| Idéal pour | Besoins simples, multi-cloud | ML temps réel à grande échelle | Plateforme ML complète | Équipes GCP |
Matrice de Décision d'Adoption
| Signal | Score (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