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

Feature Store コスト管理

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

  • フィーチャーマテリアライゼーション はサーバレスコンピュートとして実行され、FEATURE_STORE 製品として請求に表示され、サーバレスジョブおよびLakeFlow Spark宣言型パイプラインと同じ料金で請求されます。
  • 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 エンドポイントは、事前計算されたオンデマンドの機能をリアルタイム アプリケーションに提供します。これらは Model Serving で実行され、カスタムモデルサービングエンドポイントと同じく、Model Serving SKU (SERVERLESS_REAL_TIME_INFERENCE) に課金されます。料金は、エンドポイントがリクエストトラフィックを処理するためにプロビジョニングするコンピュートに応じて変動します。Feature Serving エンドポイントとModel Serving の価格ページを参照してください。

オンラインストア​

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

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

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のフィールドは、各コスト行を生成した特定の具体化ジョブまたはパイプラインを特定するため、パイプラインごとの属性付けのためにそれらでグループ化できます。

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

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

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

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

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

その他のリソース​

このページの見出し