Base de données de caractéristiques FeatureDB - Platform For AI

Qu'est-ce que FeatureDB

FeatureDB est une base de données de stockage distribué haute performance fournie par FeatureStore. Elle prend en charge les formats de données KV et KKV et permet le stockage structuré des tableaux sous forme de type Array et des paires clé-valeur sous forme de type Map. Le stockage des données dans les types Array et Map offre des performances supérieures pour les opérations de lecture/écriture ultérieures et les services d'inférence. FeatureDB prend entièrement en charge les pipelines de production, de mise à jour et de consommation pour les caractéristiques hors ligne et en temps réel, y compris les caractéristiques de séquence de comportement utilisateur.

Comment activer

Activez FeatureDB lors de la création d'une nouvelle source de données FeatureDB en suivant les instructions à l'écran. Pour plus de détails, reportez-vous à Créer une source de données en ligne : FeatureDB.

Fonctionnalités du produit

FeatureDB met en œuvre les capacités et optimisations suivantes, adaptées aux caractéristiques de lecture des données de caractéristiques de FeatureStore :

Prise en charge de la lecture et de l'écriture des caractéristiques de type KV et KKV.
Prise en charge de la lecture et de l'écriture des caractéristiques de type complexe MaxCompute (Array, Map).
Prise en charge de l'extraction complète de toutes les données de caractéristiques d'un FeatureView.
Prise en charge de l'interrogation au niveau de la milliseconde pour mettre à jour les données de caractéristiques en temps réel.
Prise en charge du TTL (Time To Live) au niveau de la seconde pour nettoyer automatiquement les données expirées.
Facturation selon le modèle paiement à l'utilisation, basée sur le volume réel de données lues et écrites.

FeatureDB répartit les données FeatureView sur plusieurs partitions. Ajustez le nombre de shards pour répondre aux exigences de performance en lecture/écriture pour différents scénarios. Les réplicas sont également pris en charge pour garantir la stabilité et la sécurité des données. Le nombre de shards est défini en fonction de l'Estimated Data Scale que vous sélectionnez :

Below tens of millions (par défaut) : 5 shards.
Between tens of millions and hundreds of millions : 10 shards.
Above hundreds of millions : 20 shards.

Dans la boîte de dialogue Create Feature View , sélectionnez l'échelle appropriée dans la liste déroulante Estimated Data Scale .

Avantages

Rapport qualité-prix élevé

Les clients disposant d'un stockage de caractéristiques à plus petite échelle peuvent réduire leurs coûts en utilisant FeatureDB.
Répond aux exigences de mises à jour fréquentes

Lors de l'utilisation de caractéristiques statistiques en temps réel, vous devez mettre à jour les caractéristiques en temps réel vers plusieurs instances EasyRec Processor (service d'inférence de modèle) toutes les quelques secondes. Cela exige des mises à jour à haute fréquence, ce que FeatureDB prend en charge.
Prend en charge les caractéristiques de type complexe

Dans les scénarios de recherche et de publicité, les caractéristiques de type Array et Map, les longues séquences de comportement utilisateur et leurs SideInfo sont largement utilisées. Le stockage des caractéristiques de type complexe sous forme de chaînes nécessite une sérialisation en type Map lors de l'utilisation, ce qui dégrade les performances.

FeatureDB prend en charge le stockage natif des données de type complexe et permet la synchronisation des données de type complexe MaxCompute 2.0 dans FeatureDB pour des lectures haute performance.
Prend en charge la mise à l'échelle élastique

Les clients à grande échelle peuvent augmenter de manière flexible le nombre de shards par feature view pour améliorer les performances en lecture/écriture.
Élimine les angles morts de surveillance

L'intégration de sources de données tierces rend difficile la surveillance de bout en bout du pipeline de données, en particulier pour les caractéristiques en temps réel. FeatureDB surveille les métriques de performance clés, notamment le QPS en lecture/écriture, le RT, la latence de mise à jour des données et l'utilisation du stockage, au niveau de granularité de chaque vue.

Capacités du produit

Connectivité VPC haute vitesse

FeatureDB fournit une connectivité VPC haute vitesse via PrivateLink. Après une configuration réussie, FeatureStore utilise PrivateLink pour connecter votre VPC au service FeatureDB. Vous pouvez ensuite accéder à FeatureDB via une connexion privée depuis votre VPC en utilisant le SDK FeatureStore, améliorant ainsi les performances de lecture/écriture des données et réduisant la latence d'accès.

Configurez la connectivité VPC haute vitesse comme suit :

Méthode 1 : Si vous n'avez pas encore créé de source de données FeatureDB, cliquez sur Manage Data Source . Sur la page Manage Data Source, cliquez sur Create Data Source . Lors de la création d'une source de données FeatureDB, remplissez la section VPC Direct Connection Configurations avec votre VPC et Zone and vSwitch. Pour les étapes détaillées, reportez-vous à Créer une source de données en ligne : FeatureDB.
Méthode 2 : Si vous avez déjà créé une source de données FeatureDB, cliquez sur Manage Data Source . Sur la page Manage Data Source, cliquez sur la source de données feature_db existante pour accéder à sa page produit. Cliquez sur VPC Direct Connection Configurations, saisissez votre VPC et Zone and vSwitch, puis cliquez sur Confirm.

Notes

Une fois défini, le VPC ne peut pas être modifié. Confirmez que le VPC configuré correspond à celui utilisé par votre service en ligne FeatureStore.

Déployez votre service dans la zone recommandée pour éviter la latence réseau inter-zones et maximiser les performances d'accès.

Area	Region	Recommended Zone
Asia-Pacific	China (Hangzhou)	Zone G
	China (Shanghai)	Zone L
	China (Beijing)	Zone F
	China (Shenzhen)	Zone F
	Hong Kong (China)	Zone B
	Singapore	Zone C
	Indonesia (Jakarta)	Zone B
Europe and Americas	Germany (Frankfurt)	Zone A
Europe and Americas	US (Silicon Valley)	Zone B

Zone and vSwitch : Assurez-vous de sélectionner des vSwitches dans la même zone que vos instances de service en ligne. Pour une haute disponibilité et une stabilité accrues, sélectionnez des vSwitches dans au moins deux zones, de préférence la zone où votre service en ligne s'exécute et la zone recommandée indiquée ci-dessus.
Après une configuration réussie, vous pouvez uniquement ajouter des vSwitches provenant d'autres zones. Vous ne pouvez pas modifier ni supprimer les configurations existantes.

Écrire des caractéristiques

Pour les caractéristiques hors ligne, utilisez le SDK Python FeatureStore avec DataWorks pour exécuter des tâches planifiées quotidiennes qui synchronisent les données de MaxCompute vers FeatureDB.

Par défaut, les écritures de caractéristiques en temps réel effectuent des mises à jour complètes des lignes. Si les données écrites ne comprennent que des champs partiels, les champs manquants sont définis comme vides. Pour mettre à jour uniquement les champs spécifiés et les fusionner avec les données existantes, configurez comme suit :

Lors de l'écriture via le SDK Java : Spécifiez InsertMode comme InsertMode.PartialFieldWrite.

for (int i = 0; i < 100;i++) {
    featureView.writeFeatures(writeData, InsertMode.PartialFieldWrite);
}

Lors de l'écriture via le connecteur Flink : Définissez le paramètre insert_mode sur partial_field_write.

Lire les caractéristiques

Utilisez le SDK FeatureStore (Go/Java) ou EasyRec Processor pour lire les caractéristiques.

Le SDK FeatureStore (Go/Java) prend en charge les jointures ponctuelles KV pour les caractéristiques hors ligne et en temps réel. Spécifiez le JoinID (clé primaire) de la caractéristique et le nom de la caractéristique pour effectuer une requête KV et récupérer les données de caractéristiques cibles en quelques millisecondes. Le SDK prend également en charge les requêtes KKV pour les caractéristiques de séquence de comportement. Spécifiez un UserID pour récupérer les résultats de caractéristiques de séquence assemblés.

EasyRec Processor intègre le SDK C++ FeatureStore, permettant l'ingestion complète des données de caractéristiques FeatureDB en mémoire et l'interrogation au niveau de la milliseconde pour mettre à jour les caractéristiques en temps réel en mémoire, offrant ainsi des performances de lecture supérieures.

Métriques de surveillance

Si vous utilisez FeatureDB comme magasin en ligne, après avoir créé une vue de caractéristiques, cliquez sur Data Monitoring à côté de la vue cible pour afficher des métriques telles que le QPS et le RT en lecture/écriture. (Remarque : Les écritures provenant de la synchronisation des données de vue de caractéristiques hors ligne n'apparaissent pas dans ces métriques.)

Pipeline de caractéristiques en temps réel

Le service de stockage de FeatureStore se compose de trois composants : Feature Service (couche d'accès), file d'attente de messages (DataHub) et FeatureDB.

Pour les caractéristiques en temps réel, vous pouvez appeler Feature Service via le SDK Java FeatureStore ou le connecteur Flink pour écrire des données de caractéristiques dans FeatureDB. Les données écrites via Feature Service sont également synchronisées avec votre table MaxCompute pour l'exportation d'échantillons de caractéristiques en temps réel et la formation ultérieure de modèles.

Vous pouvez lire les données de caractéristiques stockées dans FeatureDB en utilisant les SDK Java/Go FeatureStore ou extraire toutes les caractéristiques dans le cache local via EasyRec Processor pour des performances de lecture supérieures. Les caractéristiques en temps réel fournissent les dernières informations de caractéristiques en quelques millisecondes.

Paramètres du cycle de vie des données de caractéristiques en temps réel

Lors de la création d'une vue de caractéristiques en temps réel, définissez le cycle de vie des données pour la table FeatureDB en utilisant Feature Lifecycle . Les lignes expirent et sont automatiquement nettoyées en quelques secondes après avoir atteint la durée de leur cycle de vie.

Le délai d'expiration des données (TTL) prend actuellement en charge deux méthodes de configuration :

Méthode 1 : Ne spécifiez pas de champ Event Time . Dans ce cas, la durée de vie commence à partir de l'heure d'écriture des données, et les lignes sont automatiquement nettoyées à l'expiration.
Méthode 2 : Sélectionnez un champ de caractéristique comme champ Event Time (unité : millisecondes). Soit event_time la valeur du champ Event Time , time_now l'heure actuelle, et time_ttl = time_now - ttl le seuil event_time pour l'expiration. FeatureDB traite les données écrites comme suit :
- Si vous utilisez le mode PartialFieldWrite pour des mises à jour de champs partiels, la durée de vie est calculée à partir de l'heure d'écriture réelle.
- Si event_time > time_now + 15 min : Les données ne sont pas écrites. (Cela permet d'éviter les écarts d'horodatage entre les systèmes en autorisant une marge de 15 minutes.)
- Si time_ttl < event_time <= time_now + 15 min : Les données sont écrites normalement. La durée de vie commence à partir de event_time, et la ligne est automatiquement nettoyée à l'expiration.
- Si 0 < event_time < time_ttl : Les données sont écrites mais immédiatement nettoyées. Remarque : event_time est en millisecondes. Si votre champ Event Time utilise des secondes, les données tombent dans ce cas et ne persistent pas.
- Si event_time <= 0 : La durée de vie est calculée à partir de l'heure d'écriture réelle.
- Si la valeur est invalide (ne peut pas être convertie en entier) : Les données ne sont pas écrites.
- Le champ Event Time est enregistré mais aucune valeur n'est fournie pour le champ Event Time : les données sont écrites normalement, et leur durée de vie est calculée en fonction de l'heure d'écriture réelle.
- Si aucun champ Event Time n'est enregistré : Les données sont écrites normalement, et la durée de vie est calculée à partir de l'heure d'écriture réelle.
- De plus, FeatureDB utilise la valeur event_time comme horodatage (ts) de la ligne. Pour mettre à jour les données d'une clé donnée, la nouvelle valeur Event Time doit être supérieure ou égale à la valeur précédente. Si le nouveau event_time est inférieur à l'original, les données de la clé ne seront pas mises à jour.

Tests de performance

Ce qui suit présente des exemples de résultats de tests de stress pour la lecture des données FeatureDB en utilisant le SDK Go FeatureStore dans un environnement VPC. Les données de test proviennent de tables côté utilisateur dans un scénario de recommandation, avec un total de 17 689 586 lignes. Les tests ont été effectués sur une machine de 4 cœurs et 8 GiB. Les résultats sont fournis à titre indicatif uniquement.

Avec la Connectivité haute vitesse du réseau VPC configurée et le service en ligne déployé dans la zone recommandée :

Number of feature fields (columns)

Number of keys read (rows)

Average latency

TP95

TP99

260

1

0,89 ms

1,20 ms

1,45 ms

260

10

1,17 ms

1,52 ms

1,87 ms

260

50

1,91 ms

2,56 ms

2,92 ms

260

100

2,87 ms

3,58 ms

3,93 ms

260

200

4,43 ms

5,25 ms

5,80 ms

Avec la connectivité haute vitesse du réseau VPC configurée, mais le service en ligne déployé dans une zone non recommandée :

Number of feature fields (columns)

Number of keys read (rows)

Average latency

TP95

TP99

260

1

2,54 ms

2,86 ms

3,15 ms

260

10

2,75 ms

3,12 ms

3,56 ms

260

50

3,95 ms

4,75 ms

5,19 ms

260

100

4,82 ms

5,66 ms

6,21 ms

260

200

6,84 ms

7,75 ms

8,25 ms

Sans la connectivité haute vitesse du réseau VPC configurée :

Number of feature fields (columns)

Number of keys read (rows)

Average latency

TP95

TP99

260

1

3,62 ms

3,83 ms

4,27 ms

260

10

3,82 ms

4,11 ms

4,61 ms

260

50

4,54 ms

5,19 ms

5,60 ms

260

100

5,40 ms

6,13 ms

6,56 ms

260

200

7,15 ms

7,93 ms

8,47 ms

Facturation

Pour plus de détails, reportez-vous à Facturation FeatureStore.