Gestion des coûts du Feature Store

Cette page décrit comment le Feature Store d’Azure Databricks facture les ressources de calcul et comment surveiller et optimiser ces coûts. Feature Store est facturé au prix coûtant : vous payez le calcul sans serveur sous-jacent, le magasin en ligne et l’infrastructure d’inférence, sans surcoût.

  • La matérialisation de fonctionnalités s’exécute en calcul serverless et apparaît dans la facturation sous le produit FEATURE_STORE, facturée au même tarif que les travaux serverless et les pipelines Lakeflow.
  • Les point de terminaison de mise en service de fonctionnalités sont facturés par rapport à la référence SKU Model Serving.
  • Les magasins en ligne sont facturés par rapport au calcul Lakebase, en fonction du nombre d’unités de capacité (CU) et du nombre de réplicas.

Comment le Magasin de fonctionnalités est facturé

Matérialisation des fonctionnalités

Lorsque vous matérialisez des Feature Views, Azure Databricks exécute un pipeline sans serveur pour calculer et enregistrer les valeurs des variables dans des cibles hors ligne et en ligne. Cela inclut les tâches de matérialisation par lots, les pipelines de traitement en continu et l’ingestion depuis Kafka. Ces pipelines s’exécutent sur une infrastructure de calcul serverless et sont facturés au prix coûtant, avec un coefficient multiplicateur de 1x et sans surcoût par rapport à la plateforme serverless sous-jacente. Lorsque vous effectuez un backfill des Feature Views, le backfill s’exécute sur le même calcul serverless et est facturé de la même manière.

Dans la table système d’utilisation facturable, l’utilisation de la matérialisation s’affiche avec billing_origin_product défini sur FEATURE_STORE et une référence SKU de calcul sans serveur (JOBS_SERVERLESS_COMPUTE, préfixée par le niveau et la région de votre espace de travail). L’utilisation est is_serverless et is_photonusage_metadata inclut data_source (DELTA_TABLE_SOURCE ou KAFKA_SOURCE) et operation (FEATURE_MATERIALIZATION ou KAFKA_INGESTION) afin de pouvoir segmenter les coûts par lot par rapport aux charges de travail de diffusion en continu. L’utilisation du renvoi a les mêmes valeurs data_source et operation que la matérialisation par lot. Pour identifier le coût de renvoi, transmettez tags à backfill_features.

Pour réduire le coût de calcul, regroupez les fonctionnalités qui partagent une destination hors ligne, une destination en ligne et un déclencheur dans un seul appel materialize_features afin qu’elles s’exécutent dans un seul pipeline. Voir Matérialiser les vues des fonctionnalités. Pour en savoir plus sur la facturation du calcul sans serveur, consultez Exécuter vos tâches Lakeflow avec le calcul sans serveur pour les flux de travail.

Fonctionnalité Points de terminaison de service

Les points de terminaison de diffusion de variables fournissent des variables précalculées et à la demande aux applications en temps réel. Ils s’exécutent sur Model Serving et sont facturés selon le SKU Model Serving (SERVERLESS_REAL_TIME_INFERENCE), comme les points de terminaison personnalisés de Model Serving. Les frais varient en fonction des ressources de calcul que le point de terminaison provisionne pour traiter le trafic de requêtes. Voir les tableaux de fonctionnalités Serve et la page de tarification de Model Serving.

Magasins en ligne

Les magasins en ligne servent des fonctionnalités à faible latence pour l’inférence en ligne. Une boutique en ligne Azure Databricks s’appuie sur Lakebase et est facturée sur la base du calcul Lakebase, en fonction des unités de capacité (CU) et des réplicas de lecture qu’elle provisionne. Chaque unité de capacité alloue le calcul, la mémoire et le stockage à l’instance, et vous pouvez ajouter des réplicas de lecture pour une disponibilité et un débit de lecture plus élevés. Consultez Magasins de caractéristiques en ligne Databricks pour obtenir des conseils de dimensionnement, Gérer le calcul pour savoir comment les unités de capacité se traduisent en ressources de calcul, et la page des tarifs de Lakebase.

Attribution des coûts avec des balises et des stratégies d’utilisation serverless

Important

Cette fonctionnalité est en préversion privée. Pour l’essayer, contactez votre Azure Databricks contact.

Lorsque vous créez une matérialisation, lancez un backfill, ou créez un stream, passez des tags personnalisés, une politique d’utilisation serverless, ou les deux. Azure Databricks les applique à la tâche ou au pipeline Lakeflow qu’il crée, de sorte que ses dépenses soient associées à votre attribution dans la table système de l’utilisation facturable. Pour créer une politique et obtenir son ID, voir Créer une politique d’utilisation sans serveur.

Les deux valeurs sont appliquées lors de la création du poste ou du pipeline. Pour attribuer un calcul existant différemment, créez une nouvelle matérialisation ou un nouveau flux.

Calcul de matérialisation des attributs

Passer tags, budget_policy_id, ou les deux à materialize_features:

materialized = fe.materialize_features(
    features=features,
    offline_config=offline_config,
    trigger=trigger,
    tags={"team": "ml-platform", "project": "churn"},
    budget_policy_id="555e8888-e999-4444-a777-446655440000",
)

Pour la signature complète, voir Materialize Feature Views.

Calcul du renvoi des attributs

Transmettez tags, budget_policy_id ou les deux à backfill_features. Ils ne s’appliquent qu’à ce remblai, donc chaque remblai peut avoir sa propre attribution.

backfill = fe.backfill_features(
    features=features,
    backfill_ranges=backfill_ranges,
    tags={"team": "ml-platform", "project": "churn"},
    budget_policy_id="555e8888-e999-4444-a777-446655440000",
)

Pour la signature complète, voir Backfill Feature Views.

Capacité de calcul d’ingestion gérée par attributs

Pour un flux, définissez tags et IngestionConfig sur le create_stream que vous transmettez à budget_policy_id :

from databricks.feature_engineering.entities import IngestionConfig, IngestionDestination

ingestion_config = IngestionConfig(
    ingestion_destination=IngestionDestination(
        delta_table_name="my_catalog.my_schema.events_ingestion"
    ),
    tags={"team": "ml-platform", "project": "churn"},
    budget_policy_id="555e8888-e999-4444-a777-446655440000",
)

Pour les options d’ingestion restantes, voir Configurer un flux.

Calculer à quoi l’attribution s’applique

Les balises et la stratégie d’utilisation serverless s’appliquent aux ressources de calcul qui matérialisent les fonctionnalités, renvoient les fonctionnalités ou ingèrent les données de flux : la tâche de matérialisation par lot, le pipeline Lakeflow de streaming et la tâche qui l’orchestrent, ainsi que le pipeline Lakeflow d’ingestion d’un flux avec ses tâches de transfert-remplissage et de renvoi. Lorsque vous matérialisez des données dans une nouvelle table en ligne, elles s’appliquent également au pipeline Lakeflow qui maintient cette table synchronisée.

Elles ne s’appliquent pas à la boutique en ligne elle-même. Pour attribuer à une boutique en ligne ses propres ressources de calcul, définissez sur la boutique en ligne une politique d’utilisation serverless. Consultez les magasins de fonctionnalités Databricks Online.

Limitations

  • La matérialisation dans une table en ligne déjà existante n’applique ni tags ni budget_policy_id et ne renvoie aucune erreur. Le pipeline Lakeflow qui synchronise cette table conserve les tags avec lesquels elle a été créée. Pour modifier l’attribution, matérialisez les données dans une nouvelle table en ligne.
  • Vous pouvez transmettre au maximum 25 balises.
  • Une clé de tag peut compter jusqu’à 127 caractères et une valeur de tag jusqu’à 65 535 caractères. Aucun des deux ne peut être vide.
  • Une clé de balise ne peut pas commencer par databricks:. Ce préfixe est réservé, et la vérification ignore la casse.

Surveiller l’utilisation et les coûts

Vous pouvez surveiller les coûts de de magasins de fonctionnalités à l’aide de la table système de l’utilisation facturable, system.billing.usage. L’utilisation de la matérialisation est identifiée par billing_origin_product = 'FEATURE_STORE' :

SELECT
  usage_date,
  usage_metadata.data_source,
  usage_metadata.operation,
  usage_metadata.job_id,
  usage_metadata.dlt_pipeline_id,
  identity_metadata.run_as,
  sum(usage_quantity) AS dbus,
  usage_unit
FROM system.billing.usage
WHERE billing_origin_product = 'FEATURE_STORE'
GROUP BY ALL;

Utilisez usage_metadata.data_source et operation pour décomposer les coûts entre le traitement par lot et le streaming. Les champs usage_metadata.job_id et usage_metadata.dlt_pipeline_id identifient la tâche de matérialisation ou le pipeline spécifique ayant produit chaque ligne de coût, ce qui vous permet d’effectuer un regroupement par ces champs pour une attribution des coûts par pipeline.

La colonne custom_tags contient les tags que vous avez transmis ainsi que ceux associés à la politique d’utilisation serverless, ce qui vous permet de regrouper ou de filtrer selon custom_tags['<key>'] afin d’attribuer les dépenses. Pour savoir comment les balises de politique atteignent les enregistrements de facturation, voir Analyser les balises de politique d’utilisation sans serveur dans les enregistrements de facturation.

Les coûts de service de fonctionnalités et de magasin en ligne sont suivis séparément :

  • Les points de terminaison de mise en service de fonctionnalité s’affichent sous la référence SKU du service de modèles. Consultez Surveiller les coûts de mise en service du modèle.
  • La capacité de calcul du magasin en ligne figure sous la référence SKU serverless Lakebase (base de données).

Pour plus d’informations sur la table d’utilisation facturable et sur la façon de l’interroger, consultez Référence de table système d’utilisation facturable.

Meilleures pratiques en termes d’optimisation des coûts

  • Regrouper les fonctionnalités dans des pipelines de matérialisation partagés : les fonctionnalités qui partagent une destination hors connexion, la destination en ligne et le déclencheur peuvent se matérialiser ensemble dans un seul pipeline, ce qui réduit le nombre de pipelines que vous payez.
  • Réutiliser les magasins en ligne : vous pouvez publier plusieurs tables de fonctionnalités dans un magasin en ligne unique. Pour le développement, les tests et la formation, partagez un magasin en ligne entre des projets plutôt que de créer des magasins distincts.
  • Dimensionnez correctement la capacité de la boutique en ligne : commencez par une petite unité de capacité pour les tests, puis augmentez-la ou réduisez-la en fonction des performances et des coûts.
  • Supprimer les ressources qui ne sont pas utilisées : les magasins en ligne entraînent en permanence des coûts. Supprimez les magasins en ligne et les pipelines de matérialisation qui ne sont plus nécessaires.
  • Choisissez un déclencheur de matérialisation approprié : les déclencheurs planifiés moins fréquents coûtent moins cher que la re-matérialisation continue ou fréquente. Faites correspondre le déclencheur au niveau d’actualité nécessaire de vos fonctionnalités.

Ressources additionnelles

  • Dernière mise à jour :