メインコンテンツまでスキップ

Feature Store コスト管理

このページでは、Databricks Feature Store がコンピュートに課金する方法と、それらのコストを監視および最適化する方法について説明します。Feature Store は費用に応じて課金されます: 基盤となるサーバレスコンピュート、オンラインストア、およびサービングインフラストラクチャに対して追加料金なしで支払います。

  • フィーチャーマテリアライゼーション はServerlessコンピュートとして実行され、FEATURE_STORE製品として課金に表示され、ServerlessジョブおよびLakeFlow Pipelinesと同じレートで課金されます。
  • Feature Serving エンドポイント には、Model Serving SKU の料金体系が適用されます。
  • オンラインストア は、容量ユニット(CU)およびレプリカ数に基づいて、Lakebase コンピュートに対して請求されます。

Feature Store の課金方法​

特徴量のマテリアライズ​

Feature Viewsをマテリアライズすると、DatabricksはServerlessパイプラインを実行して特徴量値をコンピュートし、オフラインおよびオンラインの宛先に書き込みます。これには、バッチのマテリアライズジョブ、ストリーミングパイプライン、Kafkaの取り込みが含まれます。これらのパイプラインはServerlessコンピュートで実行され、1xの乗数で、基盤となるServerlessプラットフォームに対するプレミアム料金なしで実費が課金されます。Feature Viewsのバックフィルを行うと、バックフィルは同じServerlessコンピュートで実行され、同じ方法で課金されます。

課金利用システムテーブルでは、マテリアライズドビューの利用状況の billing_origin_product に FEATURE_STORE が設定され、Serverless コンピュート SKU(JOBS_SERVERLESS_COMPUTE。ワークスペースのティアとリージョンによって接頭辞が付きます)が設定されます。使用量は is_serverless および is_photon であり、usage_metadata には data_source(DELTA_TABLE_SOURCE または KAFKA_SOURCE)および operation(FEATURE_MATERIALIZATION または KAFKA_INGESTION)が含まれるため、コストをバッチとストリーミングのワークロードで切り分けることができます。バックフィルの使用量には、バッチマテリアライズドビューと同じ data_source および operation の値があります。バックフィルのコストを特定するには、tags を backfill_features に渡します。

コンピュートコストを削減するために、オフラインの送信先、オンラインの送信先、およびトリガーを共有する特徴量を単一のmaterialize_features呼び出しにグループ化し、単一のパイプラインで実行されるようにします。「Materialize Feature Views」を参照してください。サーバレスコンピュートの料金について詳しくは、「ワークフロー向けサーバレスコンピュートによるLakeflowジョブの実行」を参照してください。

Feature Serving エンドポイント​

Feature Serving Endpointは、事前計算された特徴量およびオンデマンドの特徴量をリアルタイム アプリケーションに提供します。これらは Model Serving で実行され、カスタム モデルサービング エンドポイントと同様に、Model Serving SKU (SERVERLESS_REAL_TIME_INFERENCE) に対して課金されます。料金は、リクエスト トラフィックを処理するためにEndpointがプロビジョニングするコンピュートに応じてスケールします。特徴量テーブルの提供および モデルサービングの価格ページを参照してください。

オンラインストア​

オンラインストアは、オンライン推論のために低レイテンシで特徴量を提供します。Databricks のオンラインストアは Lakebase を搭載しており、プロビジョニングするキャパシティユニット (CU) と読み取りレプリカに基づいて、Lakebase のコンピュートに対して課金されます。各キャパシティユニットはインスタンスにコンピュート、メモリ、ストレージを割り当て、可用性と読み取りスループットを高めるために読み取りレプリカを追加できます。サイズ設定のガイダンスについてはDatabricks オンライン Feature Storeを、キャパシティユニットのコンピュートへのマッピングについてはコンピュートの管理を、およびLakebase の価格ページを参照してください。

タグとServerless使用ポリシーを使用してコストを属性に割り当てます​

備考

プレビュー

この機能は プライベート プレビュー段階です。試用するには、Databricksの担当者にお問い合わせください。

マテリアライゼーションを作成したり、バックフィルを起動したり、ストリームを作成したりするときに、カスタムタグ、Serverless使用ポリシー、またはその両方を渡します。Databricksはこれらを作成するジョブまたはLakeFlow Pipelinesに適用するため、その消費量は課金利用システムテーブルの属性に反映されます。ポリシーを作成してIDを取得するには、Serverless使用ポリシーの作成を参照してください。

両方の値は、ジョブまたはパイプラインの作成時に適用されます。既存のコンピュートを異なる方法でアトリビュートするには、新しいマテリアライズまたはストリームを作成します。

属性マテリアライゼーションコンピュート​

materialize_featuresに tags、budget_policy_id、またはその両方を渡します:

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",
)

完全なシグネチャについては、特徴量ビューの具体化を参照してください。

属性バックフィル コンピュート​

tags、 budget_policy_id、またはその両方を backfill_features に渡します。それらはそのバックフィルにのみ適用されるため、各バックフィルは独自のアトリビューションを持つことができます。

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",
)

完全なシグネチャについては、「フィーチャビューのバックフィル」を参照してください。

属性管理対象の取り込みコンピュート​

ストリームの場合は、create_streamに渡すIngestionConfigにtagsとbudget_policy_idを設定します。

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",
)

その他のインジェスト オプションについては、ストリームのセットアップを参照してください。

アトリビューションが適用されるコンピュート​

タグとサーバレス使用ポリシーは、機能をマテリアライズ、バックフィル、またはStreamデータを取り込むコンピュートに適用されます。これには、バッチマテリアライズジョブ、機能バックフィルジョブ、ストリーミング Lakeflow パイプラインとそれをオーケストレートするジョブ、およびStreamの取り込み Lakeflow パイプラインとそのフォワードフィルおよびバックフィルジョブが含まれます。新しいオンラインテーブルにマテリアライズする場合、それらはそのテーブルを同期状態に保つ LakeFlow Pipelinesにも適用されます。

これらはオンラインストア自体には適用されません。オンラインストア独自のコンピュートの使用量を按分するには、ストアにServerless使用ポリシーを設定します。「Databricks Online Feature Stores」を参照してください。

制限事項​

  • すでに存在するオンライン テーブルに具体化する場合、tags も budget_policy_id も適用されず、エラーは返されません。そのテーブルを同期状態に保つ Lakeflow パイプラインは、作成時に付与されたタグを保持します。アトリビューションを変更するには、新しいオンライン テーブルに具体化します。
  • 渡すことができるタグは最大 25 個です。
  • タグキーは最大127文字、タグ値は最大65,535文字まで指定できます。どちらも空にすることはできません。
  • タグキーをdatabricks:で始めることはできません。そのプレフィックスは予約されています。また、チェックでは大文字と小文字が区別されません。

使用状況とコストを監視する​

Feature Store のコストは、課金利用システムテーブル system.billing.usage を使用して監視できます。マテリアライズの使用状況は 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;

コストをバッチとストリーミングで細分化するには、usage_metadata.data_sourceとoperationを使用してください。usage_metadata.job_idとusage_metadata.dlt_pipeline_idのフィールドは、各コスト行を生成した特定の具体化ジョブまたはパイプラインを特定するため、パイプラインごとの属性付けのためにそれらでグループ化できます。

custom_tags列には、Serverlessの使用ポリシーによって保持されるタグとともに渡されたタグが保持されるため、custom_tags['<key>']でグループ化またはフィルター処理してコストを配分できます。ポリシータグが請求レコードに達する方法については、請求レコードでのServerless使用ポリシータグの分析を参照してください。

Feature Servingとオンラインストアのコストは別々に追跡されます:

  • Feature Serving エンドポイントは、Model Serving SKU に分類されます。モデルサービングのコストを監視するを参照してください。
  • オンラインストアのコンピュートは、Lakebase (データベース) のサーバレス SKU に分類されます。

課金利用テーブルとそのクエリ方法の詳細については、課金利用システムテーブルのリファレンス」を参照してください。

コスト最適化のベストプラクティス​

  • 特徴量を共有マテリアライズドパイプラインにグループ化する :オフラインの送信先、オンラインの送信先、およびトリガーを共有する特徴量は、単一のパイプラインで一緒にマテリアライズできます。これにより、支払うパイプラインの数を減らすことができます。
  • オンラインストアの再利用 : 複数の特徴量テーブルを1つのオンラインストアに公開できます。開発、テスト、およびトレーニングでは、個別のストアを作成するのではなく、複数のプロジェクトで1つのオンラインストアを共有します。
  • オンラインストアの容量を最適化する :テスト用に小さな容量ユニットから開始し、パフォーマンスとコストに基づいてスケールアップまたはスケールダウンします。
  • **使用されていないリソースを削除する**: オンラインストアでは継続的にコストが発生します。不要になったオンラインストアとマテリアライゼーションパイプラインを削除します。
  • 適切なマテリアライズトリガーの選択 : 連続的または頻繁な再マテリアライズよりも、頻度の低いスケジュールされたトリガーの方がコストは低くなります。フィーチャの鮮度のニーズに合わせてトリガーを調整します。

その他のリソース​