特徴量セットの実体化の概念

実体化では、ソース データから特徴量の値が計算されます。 開始時刻と終了時刻の値は、特徴量の期間を定義します。 実体化ジョブは、この特徴量期間の特徴量を計算します。 実体化された特徴量の値は、オンラインまたはオフラインの実体化ストアに格納されます。 データの実体化後、すべての特徴クエリで実体化ストアの値を使用できるようになります。

実体化しない場合、特徴セット オフライン クエリでは、変換がソースに即座に適用され、クエリが値を返す前に特徴量が計算されます。 これは、プロトタイプ作成フェーズで適切に機能します。 ただし、トレーニングと推論の操作の場合、運用環境では、トレーニングまたは推論の前に特徴を実体化する必要があります。 その段階での実体化により、信頼性と可用性が向上します。

特徴量の実体化を探索する

実体化ジョブ UI には、オフラインおよびオンラインの実体化ストアのデータ実体化の状態と、実体化ジョブの一覧が表示されます。

特徴量期間で:

• 上部の時系列グラフには、オフライン ストアとオンライン ストアの両方の実体化状態と共に、特徴量期間に分類されるデータ間隔が表示されます。
• 下部のジョブ一覧には、選択した特徴量期間と重複するすべての実体化ジョブが処理期間と共に表示されます。

データ実体化の状態とデータ間隔

データ間隔は、特徴量セットがその特徴量値を次のいずれかの状態に実体化する時間枠です:

• 完了 (緑) - データの実体化に成功
• 未完了 (赤) - このデータ間隔において取り消されたまたは失敗した 1 つ以上の実体化ジョブ
• 保留中 (青) - この データ間隔に 1 つ以上の実体化ジョブが進行中
• なし (灰色) - このデータ間隔に、実体化ジョブは送信されていません

特徴量セットに対して実体化ジョブが実行されると、データ間隔が作成またはマージされます:

• タイムライン上で 2 つのデータ間隔が連続していて、データの実体化状態が同じ場合、1 つのデータ間隔になります
• データ間隔で、特徴データの一部が再び実体化され、その部分が異なるデータ実体化状態を取得すると、そのデータ間隔は複数のデータ間隔に分割されます

ユーザーが特徴量期間を選択すると、さまざまなデータ実体化状態がある複数のデータ間隔がその期間に表示される場合があります。 さらに、タイムライン上で不整合な複数のデータ間隔も表示される場合があります。 たとえば、以前のスナップショットには、オフライン実体化ストアの定義された特徴量期間に対して 16 のデータ間隔があります。

特徴量セットは、いつでも最大 2,000 のデータ間隔を保持できます。 特徴量セットがその上限に達すると、それ以降の実体化ジョブを実行できなくなります。 その後、ユーザーは、実体化が有効になっている新しい特徴量セット バージョンを作成する必要があります。 新しい特徴量セット バージョンでは、オフライン ストアとオンライン ストアの機能をゼロから実体化します。

この制限を回避するには、ユーザーは事前にバックフィル ジョブを実行して、データ間隔のギャップを埋める必要があります。 これにより、データ間隔がマージされ、合計カウントが減少します。

データ実体化ジョブ

データ実体化ジョブを実行する前に、特徴量セット レベルでオフラインまたはオンラインのデータ実体化を有効にします。

from azure.ai.ml.entities import (
    MaterializationSettings,
    MaterializationComputeResource,
)

# Turn on both offline and online materialization on the "accounts" featureset.

accounts_fset_config = fs_client._featuresets.get(name="accounts", version="1")

accounts_fset_config.materialization_settings = MaterializationSettings(
    offline_enabled=True,
    online_enabled=True,
    resource=MaterializationComputeResource(instance_type="standard_e8s_v3"),
    spark_configuration={
        "spark.driver.cores": 4,
        "spark.driver.memory": "36g",
        "spark.executor.cores": 4,
        "spark.executor.memory": "36g",
        "spark.executor.instances": 2,
    },
    schedule=None,
)

fs_poller = fs_client.feature_sets.begin_create_or_update(accounts_fset_config)
print(fs_poller.result())

データ実体化ジョブは、次のように送信できます。

• バックフィル ジョブ - 手動で送信されたバッチ実体化ジョブ
• 繰り返し実体化ジョブ - スケジュールされた間隔でトリガーされる自動実体化ジョブ。

バックフィル ジョブは、以下別に送信できます:

• データ実体化の状態
• 取り消された、または失敗した実体化ジョブのジョブ ID

データ実体化別データ バックフィル

ユーザーは、次と一緒にバックフィル要求を送信できます。

• データ実体化状態値の一覧 - 未完了、完了、またはなし
• 特徴量期間 (省略可能)

from datetime import datetime
from azure.ai.ml.entities import DataAvailabilityStatus

st = datetime(2022, 1, 1, 0, 0, 0, 0)
et = datetime(2023, 6, 30, 0, 0, 0, 0)

poller = fs_client.feature_sets.begin_backfill(
    name="transactions",
    version="1",
    feature_window_start_time=st,
    feature_window_end_time=et,
    data_status=[DataAvailabilityStatus.NONE],
)
print(poller.result().job_ids)

バックフィル要求の送信後、一致するデータ実体化の状態 (未完了、完了、またはなし) を持つデータ間隔ごとに新しい実体化ジョブが作成されます。 さらに、関連するデータ間隔は、定義された特徴量期間内に収める必要があります。 データ実体化状態は、データ間隔に対して Pending の場合、実体化ジョブはその間隔で送信されません。

バックフィル要求では、特徴量期間の開始時刻と終了時刻の両方が省略可能です:

• 特徴量期間の開始時刻が指定されていない場合、開始時刻は、None のデータ実体化の状態がない最初のデータ間隔の開始時刻として定義されます。
• 特徴量期間の終了時刻が指定されていない場合、終了時刻は、None のデータ実体化の状態がない最初のデータ間隔の終了時刻として定義されます。

この例には、現在のデータ間隔と実体化状態の値があります:

このバックフィル要求には、次の値があります:

• データ実体化 data_status=[DataAvailabilityStatus.Complete, DataAvailabilityStatus.Incomplete]
• 特徴量期間の開始 = 2025-04-02T12:00:00.000
• 特徴量期間の終了 = 2025-04-04T12:00:00.000

次の実体化ジョブが作成されます:

• ジョブ 1: プロセス特徴量期間 [2025-04-02T12:00:00.000, 2025-04-03T04:00:00.000)
• ジョブ 2: プロセス特徴量期間 [2025-04-04T04:00:00.000, 2025-04-04T12:00:00.000)

両方のジョブが正常に完了すると、新しいデータ間隔と実体化状態の値は次のようになります:

2025-04-02 日に 1 つの新しいデータ間隔が作成されます。これは、その日の半分の具体化状態が異なるためです(Complete)。 新しい具体化ジョブは 2025-04-04 日の半分実行されましたが、具体化の状態が変更されていないため、データ間隔は変更 (分割) されません。

ユーザーが、特徴量期間の開始時刻と終了時刻を設定せずに、データ実体化 data_status=[DataAvailabilityStatus.Complete, DataAvailabilityStatus.Incomplete] のみを使用してバックフィル要求を行った場合、要求では、このセクションで前述したパラメーターの既定値が使用され、次のジョブが作成されます:

• ジョブ 1: プロセス特徴量期間 [2025-04-02T04:00:00.000, 2025-04-03T04:00:00.000)
• ジョブ 2: プロセス特徴量期間 [2025-04-04T04:00:00.000, 2025-04-05T04:00:00.000)

これらの最新の要求ジョブの特徴量期間と、前の例に示した要求ジョブを比較します。

ジョブ ID によるデータ バックフィル

バックフィル要求は、ジョブ ID を使用して作成することもできます。 これは、失敗または取り消された実体化ジョブを再試行する便利な方法です。 まず、再試行するジョブのジョブ ID を見つけます:

• 特徴量セットの[実体か化ジョブ] UI に移動します
• [状態] の値が [失敗] となっている、特定のジョブの [表示名] を選択します
• ジョブの [概要] ページで、[名前] プロパティの下にある関連するジョブ ID の値を見つけます。Featurestore-Materialization- で始まるはずです。

poller = fs_client.feature_sets.begin_backfill(
    name="transactions",
    version=version,
    job_id="<JOB_ID_OF_FAILED_MATERIALIZATION_JOB>",
)
print(poller.result().job_ids)

az ml feature-set backfill --by-job-id <JOB_ID_OF_FAILED_MATERIALIZATION_JOB> --name <FEATURE_SET_NAME> --version <VERSION>  --feature-store-name <FEATURE_STORE_NAME> --resource-group <RESOURCE_GROUP>

失敗または取り消された実体化ジョブのジョブ ID のバックフィル ジョブを送信できます。 この場合、元の失敗または取り消された実体化ジョブの特徴量期間 のデータ状態は Incomplete になります。 この条件が満たされていない場合、ID によるバックフィル ジョブによってユーザー エラーが発生します。 たとえば、失敗した実体化ジョブには、特徴量期間の開始時刻の 2025-04-01T04:00:00.000 の値と終了時刻の 2025-04-09T04:00:00.000 の値が含まれます。 この失敗したジョブの ID を使用して送信されたバックフィル ジョブが成功するのは、時間範囲 2025-04-01T04:00:00.000 から 2025-04-09T04:00:00.000 のすべて場所でのデータ状態が Incomplete の場合です。

ガイダンスとベスト プラクティス

適切な source_delay と繰り返しスケジュールを設定する

ソース データの source_delay プロパティは、データ生成のイベント時刻と比較して、消費可能なデータの取得時間の間の遅延を示します。 t の時点で発生したイベントは、t + x 時点でソース データ テーブルに書き込まれます。これは、アップストリーム データ パイプラインの待機時間が原因です。 x 値はソース遅延です。

適切に設定するには、繰り返し実体化ジョブのスケジュール作成時に待機時間を考慮します。 繰り返しジョブでは、[schedule_trigger_time - source_delay - schedule_interval, schedule_trigger_time - source_delay) 時間枠の特徴量が生成されます。

materialization_settings:
  schedule:
    type: recurrence
    interval: 1
    frequency: Day
    start_time: "2025-04-15T04:00:00.000"

毎日午前 4 時にトリガーするジョブを 2025 年 4 月 15 日から定義する例です。 source_delay設定に応じて、2025 年 5 月 1 日のジョブ実行では、異なる時間枠で機能が生成されます。

• source_delay=0 は、期間 [2025-04-30T04:00:00.000, 2025-05-01T04:00:00.000) で特徴量を生成します
• source_delay=2hours は、期間 [2025-04-30T02:00:00.000, 2025-05-01T02:00:00.000) で特徴量を生成します
• source_delay=4hours は、期間 [2025-04-30T00:00:00.000, 2025-05-01T00:00:00.000) で特徴量を生成します

実体化ストアを更新する

オンライン特徴量ストアまたはオフラインの実体化ストアを更新する前に、その特徴量ストア内のすべての特徴量セットで、対応するオフライン/オンラインの実体化を無効にする必要があります。 一部の特徴量セットで実体化が有効になっている場合、更新操作は UserError として失敗します。

オフラインまたはオンラインの実体化ストアのデータの実体化状態は、特徴量セットでオフラインまたはオンラインの実体化が無効になっている場合にリセットされます。 リセットにより、実体化されたデータが使用できなくなります。 特徴量セットのオフライン/オンラインの実体化が後で有効にされた場合、ユーザーは実体化ジョブを再送信する必要があります。

Online data bootstrap

Online data bootstrap は、送信されたオフライン実体化ジョブが正常に完了した場合にのみ適用されます。 最初に特徴量セットに対してオフライン実体化のみが有効になっていて、オンライン実体化を後で有効にする場合:

• オンライン ストア内のデータの既定のデータ実体化状態は None になります

• オンライン実体化ジョブが送信されると、オフライン ストアの Complete の実体化状態があるデータが、オンライン機能の計算に使用されます。 これは online data bootstrapping と呼ばれます。 Online data bootstrap では、オフライン実体化ストアに保存されている既に計算済みの特徴が再利用されるため、計算コストが節約されます。次の表は、Online data bootstrap の結果となるオフライン データとオンライン データ状態の値をデータ間隔別にまとめたものです:

  [開始時間]	終了時刻	オフライン データの状態	オンライン データの状態	Online data bootstrap
  2025-04-01T04:00:00.000	2025-04-02T04:00:00.000	None	None	いいえ
  2025-04-02T04:00:00.000	2025-04-03T04:00:00.000	Incomplete	None	いいえ
  2025-04-03T04:00:00.000	2025-04-04T04:00:00.000	Pending	None	実体化ジョブが送信されていません
  2025-04-04T04:00:00.000	2025-04-05T04:00:00.000	Complete	None	はい

ソース データのエラーと変更に対処する

一部のシナリオでは、データの実体化後にエラーまたはその他の理由により、ソース データが変更されます。 このような場合、複数のデータ間隔にわたる特定の特徴量期間に対する特徴量データの更新によって、誤った特徴量データまたは古い特徴量データが解決される場合があります。 特徴量期間で、データ状態 None、Complete、Incomplete のエラーまたは古い特徴量データ解決に向けて実体化要求を送信します。

特徴量データ更新の実体化要求は、特徴量期間に Pending データ状態を持つデータ間隔が含まれていない場合にのみ送信する必要があります。

ギャップを埋める

実体化ストアでは、実体化データには次の理由からギャップがある場合があります:

• 特徴量期間に実体化ジョブが送信されなかった
• 特徴量期間に送信された実体化ジョブが失敗したか、取り消された

この場合、ギャップを埋めるために、data_status=[DataAvailabilityStatus.NONE,DataAvailabilityStatus.Incomplete] に対する特徴量期間で実体化要求を送信します。 1 つの実体化要求によって、特徴量期間内のすべてのギャップが埋められます。

次のステップ

• チュートリアル 1: マネージド Feature Store を使用して特徴量セットの開発と登録を行う
• GitHub サンプル リポジトリ