Aller au contenu principal
Dernière mise à jour le

Gestion des coûts du Magasin de fonctionnalités

Cette page décrit comment le Magasin de fonctionnalités Databricks facture le compute et comment monitorer et optimiser ces coûts. Le Magasin de fonctionnalités est facturé au coût : vous payez pour le compute Serverless sous-jacent, le magasin en ligne et l'infrastructure de service, sans frais supplémentaires.

  • La matérialisation des fonctionnalités s'exécute en tant que compute Serverless et apparaît dans la facturation sous le produit FEATURE_STORE, facturée au même tarif que les Jobs Serverless et les LakeFlow Pipelines.
  • Les endpoints Feature Serving sont facturés sur la base du SKU Model Serving.
  • Les magasins en ligne sont facturés en fonction du compute Lakebase, sur la base de l'unité de capacité (CU) et du nombre de répliques.
remarque

Initialement, pendant la préversion publique, les pipelines de matérialisation des fonctionnalités ne sont pas facturés. Une fois la facturation activée, ils entraîneront des coûts de calcul serverless continus. D'autres frais, y compris les endpoints de Feature Serving et les magasins en ligne, s'appliquent pendant la préversion. Prévoyez les coûts de calcul de matérialisation lorsque vous déplacez des charges de travail en production.

Comment le Magasin de fonctionnalités est facturé​

Matérialisation de fonctionnalité​

info

Aperçu public

La matérialisation des fonctionnalités fait partie des Feature Views, qui est en prévisualisation publique.

Lorsque vous matérialisez les vues de fonctionnalités, Databricks exécute un pipeline Serverless pour compute et écrire les valeurs de fonctionnalités vers des destinations hors ligne et en ligne. Cela inclut les Jobs de matérialisation par batch, les pipelines de streaming et l'ingestion Kafka. Ces pipelines s'exécutent sur un calcul serverless et sont facturés au prix coûtant, avec un multiplicateur de 1x et sans surcoût par rapport à la plateforme serverless sous-jacente.

Dans le tableau système d'utilisation facturable, l'utilisation de la matérialisation apparaît avec billing_origin_product défini sur FEATURE_STORE et un SKU de compute Serverless (JOBS_SERVERLESS_COMPUTE, préfixé par votre niveau et votre région Workspace). L'utilisation est is_serverless et is_photon, et usage_metadata inclut data_source (DELTA_TABLE_SOURCE ou KAFKA_SOURCE) et operation (FEATURE_MATERIALIZATION ou KAFKA_INGESTION) afin que vous puissiez segmenter le coût par charges de travail par batch par rapport aux charges de travail en streaming.

Pour réduire le coût du compute, regroupez les fonctionnalités qui partagent une destination hors ligne, une destination en ligne et un Trigger en un seul appel materialize_features afin qu'elles s'exécutent dans un seul pipeline. Voir Matérialiser les vues de fonctionnalités. Pour en savoir plus sur la facturation du compute Serverless, voir Exécutez vos Lakeflow Jobs avec le compute Serverless pour les workflows.

Endpoints de Feature Serving​

Feature Serving Endpoint servent des features précalculées et à la demande à des applications en temps réel. They run on Model Serving and are billed against the Model Serving SKU (SERVERLESS_REAL_TIME_INFERENCE), the same as custom model serving endpoints. Charges Monter en charge with the compute the Endpoint provisions to handle request traffic. See Serve feature tables and the Model Serving Tarifs page.

Boutiques en ligne​

Les magasins en ligne fournissent des fonctionnalités avec une faible latence pour l'inférence en ligne. Un magasin en ligne Databricks est alimenté par Lakebase et est facturé sur le compute Lakebase, en fonction des unités de capacité (CU) et des répliques de lecture qu'il provisionne. Chaque unité de capacité alloue du compute, de la mémoire et du stockage à l'instance, et vous pouvez ajouter des répliques en lecture pour une disponibilité accrue et un throughput de lecture plus élevé. Consultez les magasins de fonctionnalités en ligne Databricks pour des conseils sur le dimensionnement, Gérer les computes pour savoir comment les unités de capacité se mappent au compute, et la page Tarifs de Lakebase.

Attribuer des coûts avec des tags et des politiques d'utilisation serverless​

info

Aperçu

Cette fonctionnalité est en version d’aperçu privé. Pour l'essayer, contactez votre conseiller Databricks.

When you create a materialization or a Stream, pass custom tags, a serverless usage policy, or both. Databricks applies them to the job or Lakeflow pipeline it creates, so its spend carries your attribution in the billable usage system table. To create a policy and get its ID, see Create a serverless usage policy.

Les deux valeurs sont appliquées lors de la création du job ou du pipeline. Pour attribuer différemment le compute existant, créez une matérialisation ou un Stream.

Compute de matérialisation d’attributs​

Passez tags, budget_policy_id ou les deux à materialize_features:

Python
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 connaître la signature complète, consultez Matérialiser les vues de caractéristiques.

Compute d’ingestion géré par les attributs​

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

Python
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 connaître les autres options d'ingestion, consultez Configurer un Stream.

Calculer l’attribution s’applique à​

Les tags et la politique d'utilisation serverless s'appliquent au compute qui matérialise les features ou ingère les données Stream : le Job de matérialisation par batch, le LakeFlow pipeline en streaming et le Job qui l'orchestre, ainsi que le LakeFlow pipeline d'ingestion d'un Stream avec ses Jobs de remplissage direct et rétrospectif. Lorsque vous matérialisez vers une nouvelle table en ligne, ils s'appliquent également au Lakeflow pipeline qui maintient cette table synchronisée.

Ils ne s'appliquent pas à la boutique en ligne elle-même. Pour attribuer le compute propre d'une boutique en ligne, définissez une politique d'utilisation serverless sur la boutique. Consultez Magasins de fonctionnalités en ligne Databricks.

Limitations​

  • La matérialisation vers une table en ligne qui existe déjà n'applique ni tags ni budget_policy_id et ne renvoie aucune erreur. Le Lakeflow pipeline qui maintient cette table synchronisée conserve les tags avec lesquels il a été créé. Pour modifier l'attribution, matérialisez vers une nouvelle table en ligne.
  • Vous pouvez passer au plus 25 tags.
  • Une clé de tag peut comporter jusqu'à 127 caractères et une valeur de tag jusqu'à 65 535 caractères. Aucun des deux ne peut être vide.
  • Une clé de tag ne peut pas commencer par databricks:. Ce préfixe est réservé et la vérification ne tient pas compte de la casse.

Surveiller l'utilisation et les coûts​

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

SQL
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 ventiler les coûts par batch par rapport au streaming. Les champs usage_metadata.job_id et usage_metadata.dlt_pipeline_id identifient le job de matérialisation ou le pipeline spécifique qui a produit chaque ligne de coût, afin que vous puissiez les regrouper pour une attribution par pipeline.

La colonne custom_tags contient les tags que vous avez transmis en plus de ceux de la politique d’utilisation serverless, ce qui vous permet d’effectuer un regroupement ou un filtrage par custom_tags['<key>'] pour attribuer les dépenses. Pour découvrir comment les tags de politique parviennent aux enregistrements de facturation, consultez la section Analyser les tags de politique d’utilisation serverless dans les enregistrements de facturation.

Les coûts de Feature Serving et du magasin en ligne sont suivis séparément :

  • Les Endpoints Feature Serving apparaissent sous le SKU Model Serving. Découvrez Surveiller les coûts du service de modèles.
  • Le compute de magasin en ligne apparaît sous la SKU serverless Lakebase (base de données).

Pour plus de détails sur la table d'utilisation facturable et comment l'interroger, consultez la référence de la table système d'utilisation facturable.

Meilleures pratiques d'optimisation des coûts​

  • Regroupez les fonctionnalités dans des pipelines de matérialisation partagés : les fonctionnalités qui partagent une destination hors ligne, une destination en ligne et un trigger peuvent être matérialisées ensemble dans un seul pipeline, ce qui réduit le nombre de pipelines pour lesquels vous payez.
  • **Réutiliser les boutiques en ligne** : vous pouvez publier plusieurs tables de fonctionnalités vers une seule boutique en ligne. Pour le développement, les tests et la formation, partagez un magasin en ligne unique entre les projets plutôt que de créer des magasins distincts.
  • Optimisez la capacité de votre boutique en ligne : commencez par une petite unité de capacité pour les tests et montez en charge ou réduisez en fonction des performances et des coûts.
  • Supprimer les ressources inutilisées : les boutiques en ligne entraînent des coûts continus. Supprimer les boutiques en ligne et les pipelines de matérialisation qui ne sont plus nécessaires.
  • Choisissez un Trigger de matérialisation approprié : les Triggers planifiés moins fréquents coûtent moins cher qu'une rematérialisation continue ou fréquente. Adaptez le Trigger à la fraîcheur requise pour vos fonctionnalités.

Ressources supplémentaires​

Sur cette page