メインコンテンツまでスキップ
に最終更新

Feature Store コスト管理

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

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

当初のパブリックプレビュー期間中は、機能の具体化パイプラインは課金されません。課金が有効になると、継続的なサーバレスコンピュートコストが発生します。Feature Servingエンドポイントやオンラインストアなど、その他の料金がプレビュー期間中に適用されます。ワークロードを本番運用に移行する際には、具体化コンピュートコストを計画してください。

Feature Store の課金方法​

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

備考

パブリックプレビュー

特徴のマテリアライズは、Feature Views の一部であり、パブリックプレビュー段階です。

Feature View を具体化すると、Databricks はサーバレス パイプラインを実行して、特徴量値をオフラインおよびオンラインの宛先にコンピュートして書き込みます。これには、バッチ具体化ジョブ、ストリーミング パイプライン、および Kafka 取り込みが含まれます。これらのパイプラインはサーバレス コンピュートで実行され、1 倍の乗数でコストが課金され、基盤となるサーバレス プラットフォームに対するプレミアムは適用されません。

課金利用システムテーブルでは、マテリアライゼーションの使用量は billing_origin_product が FEATURE_STORE に設定され、サーバレスコンピュート SKU (JOBS_SERVERLESS_COMPUTE、ワークスペースの階層とリージョンがプレフィックスとして付加されます) と共に表示されます。使用量は is_serverless と is_photon であり、usage_metadata には data_source (DELTA_TABLE_SOURCE または KAFKA_SOURCE) と operation (FEATURE_MATERIALIZATION または KAFKA_INGESTION) が含まれているため、バッチワークロードとストリーミングワークロードでコストを分割できます。

コンピュートコストを削減するために、オフラインの送信先、オンラインの送信先、およびトリガーを共有する特徴量を単一の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",
)

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

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

ストリームの場合は、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 パイプラインにも適用されます。

これらはオンラインストア自体には適用されません。オンラインストア独自のコンピュートの使用量を按分するには、ストアに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つのオンラインストアを共有します。
  • オンラインストアの容量を最適化する ：テスト用に小さな容量ユニットから開始し、パフォーマンスとコストに基づいてスケールアップまたはスケールダウンします。
  • **使用されていないリソースを削除する**： オンラインストアでは継続的にコストが発生します。不要になったオンラインストアとマテリアライゼーションパイプラインを削除します。
  • 適切なマテリアライズトリガーの選択 : 連続的または頻繁な再マテリアライズよりも、頻度の低いスケジュールされたトリガーの方がコストは低くなります。フィーチャの鮮度のニーズに合わせてトリガーを調整します。

その他のリソース​

このページの見出し