Feature Storeのコスト管理

このページでは、Azure Databricks Feature Store でのコンピューティング料金の仕組みと、そのコストを監視して最適化する方法について説明します。 Feature Store はコストで課金されます。基になるサーバーレス コンピューティング、オンライン ストア、サービス インフラストラクチャに対して料金を支払い、上位にプレミアムを設定する必要はありません。

  • 機能の具体化 はサーバーレス コンピューティングとして実行され、サーバーレス ジョブや Lakeflow パイプラインと同じレートで課金される、 FEATURE_STORE 製品の課金に表示されます。
  • 機能サービス エンドポイントは、 モデル サービス SKU に対して課金されます。
  • オンライン ストア は、容量ユニット (CU) とレプリカ数に基づいて、Lakebase コンピューティングに対して課金されます。

Feature Store の課金方法

特徴の具体化

フィーチャー ビューを具体化すると、Azure 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) が含まれているため、バッチワークロードとストリーミング ワークロードでコストをスライスできます。

コンピューティング コストを削減するには、オフラインの宛先、オンラインの宛先を共有し、1 つの materialize_features 呼び出しにトリガーする機能をグループ化して、1 つのパイプラインで実行します。 「 フィーチャ ビューを具体化する」を参照してください。 サーバーレス コンピューティングの課金方法の詳細については、「ワークフローの サーバーレス コンピューティングを使用して Lakeflow ジョブを実行する」を参照してください。

エンドポイントを提供する機能

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

オンライン ストア

オンライン ストアは、オンライン推論の待機時間が短い機能を提供します。 Azure Databricks のオンライン ストアは Lakebase を基盤として動作し、プロビジョニングされる容量ユニット (CU) と読み取りレプリカに基づいて、Lakebase コンピューティングに対して請求されます。 各容量ユニットは、コンピューティング、メモリ、ストレージをインスタンスに割り当てます。読み取りレプリカを追加して、可用性と読み取りスループットを向上させることができます。 サイジングのガイダンスについては Databricks Online Feature Stores、容量ユニットがコンピュートにどのように対応するかについては コンピュートの管理、および Lakebase の価格ページ を参照してください。

タグとサーバーレス使用ポリシーに関する属性コスト

Important

この機能は、プライベート プレビュー段階にあります。 試すには、Azure Databricks の連絡先にお問い合わせください。

マテリアライゼーションや ストリームを作成する際は、カスタムタグやサーバーレス使用ポリシー、またはその両方を渡してください。 Azure Databricks は、これらを自身で作成するジョブまたは Lakeflow パイプラインに適用するため、その利用料金は、課金対象の使用量システムテーブルでは、あなたの帰属が反映されます。 ポリシーを作成し、その ID を取得するには、サーバーレス使用ポリシーを作成するを参照してください。

ジョブやパイプラインの作成時に両方の値が適用されます。 既存の計算に異なる属性を与えるには、新しいマテリアライゼーションまたはストリームを作成します。

属性実体化計算

tags、budget_policy_id、または両方をmaterialize_featuresにパスしてください:

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

完全な署名については 「Materialize Feature Views」をご覧ください。

属性管理された取り込みコンピューティング

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

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 パイプラインにも適用されます。

オンラインストア自体には適用されません。 オンラインストアの計算量を割り当てるには、ストアにサーバーレス使用ポリシーを設定します。 Databricks Online Feature Store を参照してください。

制限事項

  • すでに存在するオンラインテーブルにマチャライズしても、 tags も budget_policy_idも適用されず、エラーも返されません。 そのテーブルを同期させるLakeflowパイプラインは、作成時に使ったタグを保持します。 属性を変更するには、新しいオンライン テーブルにマテリアライズしてください。
  • 最大で25個のタグを通過できます。
  • タグキーは最大127文字、タグ値は最大65,535文字まで可能です。 どちらも空っぽであることはできません。
  • タグキーは databricks:で始まることはできません。 その接頭辞は予約されており、チェックでは大文字と小文字は区別されません。

使用状況とコストの監視

Feature Store のコストは、課金対象の使用状況システム テーブル ( system.billing.usage) を使用して監視できます。 マテリアライゼーションの使用は、billing_origin_product = 'FEATURE_STORE'によって識別されます:

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列には、渡したタグとサーバーレス使用ポリシーに含まれるタグが格納されるため、支出を割り当てる目的でcustom_tags['<key>']によるグループ化やフィルタリングができます。 ポリシータグが請求記録にどのように到達するかについては、「 請求記録内のサーバーレス使用ポリシータグの分析」を参照してください。

機能の提供とオンライン ストアのコストは、個別に追跡されます。

  • 機能サービス エンドポイントは、モデル サービス SKU の下に表示されます。 「 モデルサービスコストの監視」を参照してください。
  • オンライン ストア コンピューティングは、Lakebase (データベース) サーバーレス SKU の下に表示されます。

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

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

  • 共有マテリアライズ パイプラインに機能をグループ化する: オフラインの宛先、オンラインの宛先、トリガーを共有する機能は、1 つのパイプラインでまとめて具体化できるため、支払うパイプラインの数を減らすことができます。
  • オンライン ストアを再利用する: 1 つのオンライン ストアに複数の機能テーブルを発行できます。 開発、テスト、トレーニングを行う場合は、個別のストアを作成するのではなく、プロジェクト間で 1 つのオンライン ストアを共有します。
  • 適切なサイズのオンライン ストア容量: パフォーマンスとコストに基づいてテストおよびスケールアップまたはスケールダウンするための小さな容量ユニットから開始します。
  • 使用されていないリソースを削除する: オンライン ストアでは継続的にコストが発生します。 不要になったオンライン ストアと具体化パイプラインを削除します。
  • 適切な具体化トリガーを選択します。スケジュールされたトリガーの頻度が低いと、継続的または頻繁な再具体化よりもコストが低くなります。 機能をどの程度最新の状態に保つ必要があるかに合わせて、トリガーを選択します。

その他のリソース

  • 最終更新: