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.

Comment le Magasin de fonctionnalités est facturé​

Matérialisation de fonctionnalité​

Lorsque vous matérialisez des Feature Views, Databricks exécute un pipeline Serverless afin de compute et d’écrire les valeurs des variables dans 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 sont exécutés sur du compute Serverless et sont facturés au coût, avec un multiplicateur de 1x sans prime sur la plateforme Serverless sous-jacente. Lorsque vous effectuez un remplissage rétrospectif des Feature Views, le remplissage s’exécute sur le même compute Serverless et est facturé de la même manière.

Dans la table système d’utilisation facturable, l’utilisation liée à 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 le niveau et la région de votre 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), ce qui vous permet de ventiler les coûts entre les workloads batch et streaming. L’utilisation du remplissage a les mêmes valeurs data_source et operation que la matérialisation par batch. Pour identifier le coût du remplissage, transmettez tags à backfill_features.

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.

Lorsque vous créez une matérialisation, start un backfill ou créez un Stream, transmettez des tags personnalisés, une politique d’utilisation Serverless ou les deux. Databricks les applique au Job ou au LakeFlow Pipelines qu’il crée, afin que ses dépenses portent votre attribution dans la table système d’utilisation facturable. Pour créer une politique et obtenir son ID, consultez Créer une politique d’utilisation serverless.

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 de remplissage d'attributs​

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

Python
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, consultez Vues de fonctionnalité de remplissage.

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 fonctionnalités, les renvoie ou ingère des données de Stream : le Job de matérialisation par batch, le Job de renvoi de fonctionnalités, le LakeFlow Pipelines de streaming et le Job qui l'orchestre, ainsi que le LakeFlow Pipelines d'ingestion de Stream avec ses Job de remplissage vers l'avant et vers l'arrière. Lorsque vous matérialisez une nouvelle table en ligne, ils s'appliquent également au LakeFlow Pipelines qui maintient la synchronisation de cette table.

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