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

[アーティクル]
10/16/2024

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

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

特徴量の具体化の探索

具体化ジョブ 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())

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

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

警告

オフラインまたはオンラインの具体化で既に具体化されているデータは、特徴量セットレベルでオフラインやオンラインのデータ具体化が無効になっている場合は使用できなくなります。オフラインまたはオンラインの具体化ストアのデータ具体化の状態は、None にリセットされます。

バックフィルジョブは、次の方法で送信できます:

データ具体化の状態
取り消された、または失敗した具体化ジョブのジョブ 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 ではない最後のデータ間隔の終了時刻として定義されます。

Note

特徴量セットに対してバックフィルジョブまたは繰り返しジョブが送信されていない場合は、特徴量ウィンドウの開始時刻と終了時刻を指定して最初のバックフィルジョブを送信する必要があります。

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

開始時刻	終了時刻	データ具体化の状態
`2023-04-01T04:00:00.000`	`2023-04-02T04:00:00.000`	`None`
`2023-04-02T04:00:00.000`	`2023-04-03T04:00:00.000`	`Incomplete`
`2023-04-03T04:00:00.000`	`2023-04-04T04:00:00.000`	`None`
`2023-04-04T04:00:00.000`	`2023-04-05T04:00:00.000`	`Complete`
`2023-04-05T04:00:00.000`	`2023-04-06T04:00:00.000`	`None`

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

データの具体化 data_status=[DataAvailabilityStatus.Complete, DataAvailabilityStatus.Incomplete]
特徴量ウィンドウの開始 = 2023-04-02T12:00:00.000
特徴量ウィンドウの終了 = 2023-04-04T12:00:00.000

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

ジョブ 1: プロセス特徴量ウィンドウ [2023-04-02T12:00:00.000, 2023-04-03T04:00:00.000)
ジョブ 2: プロセス特徴量ウィンドウ [2023-04-04T04:00:00.000, 2023-04-04T12:00:00.000)

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

開始時刻	終了時刻	データ具体化の状態
`2023-04-01T04:00:00.000`	`2023-04-02T04:00:00.000`	`None`
`2023-04-02T04:00:00.000`	`2023-04-02T12:00:00.000`	`Incomplete`
`2023-04-02T12:00:00.000`	`2023-04-03T04:00:00.000`	`Complete`
`2023-04-03T04:00:00.000`	`2023-04-04T04:00:00.000`	`None`
`2023-04-04T04:00:00.000`	`2023-04-05T04:00:00.000`	`Complete`
`2023-04-05T04:00:00.000`	`2023-04-06T04:00:00.000`	`None`

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

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

ジョブ 1: プロセス特徴量ウィンドウ [2023-04-02T04:00:00.000, 2023-04-03T04:00:00.000)
ジョブ 2: プロセス特徴量ウィンドウ [2023-04-04T04:00:00.000, 2023-04-05T04:00:00.000)

これらの最新の要求ジョブの特徴量ウィンドウと、前の例に示した要求ジョブを比較してください。

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

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

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

SDK
SDK と CLI


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 によるバックフィルジョブによってユーザーエラーが発生します。たとえば、失敗した具体化ジョブには、特徴量ウィンドウの開始時刻 2023-04-01T04:00:00.000 の値と終了時刻 2023-04-09T04:00:00.000 の値が含まれます。この失敗したジョブの ID を使用して送信されたバックフィルジョブが成功するのは、時間範囲 2023-04-01T04:00:00.000 から 2023-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: "2023-04-15T04:00:00.000"

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

[2023-04-30T04:00:00.000, 2023-05-01T04:00:00.000) 時間枠で source_delay=0 が特徴値を生成します
[2023-04-30T02:00:00.000, 2023-05-01T02:00:00.000) 時間枠で source_delay=2hours が特徴値を生成します
[2023-04-30T00:00:00.000, 2023-05-01T00:00:00.000) 時間枠で source_delay=4hours が特徴値を生成します

具体化ストアを更新する

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

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

オンラインデータブートストラップ

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

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

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

開始時刻	終了時刻	オフラインデータの状態	オンラインデータの状態	オンラインデータブートストラップ
`2023-04-01T04:00:00.000`	`2023-04-02T04:00:00.000`	`None`	`None`	いいえ
`2023-04-02T04:00:00.000`	`2023-04-03T04:00:00.000`	`Incomplete`	`None`	いいえ
`2023-04-03T04:00:00.000`	`2023-04-04T04:00:00.000`	`Pending`	`None`	具体化ジョブが送信されていません
`2023-04-04T04:00:00.000`	`2023-04-05T04:00:00.000`	`Complete`	`None`	はい

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

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

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

ギャップを埋める

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

特徴量ウィンドウに対して具体化ジョブが送信されなかった
特徴量ウィンドウに対して送信された具体化ジョブが失敗したか、取り消された

この場合、ギャップを埋めるために、特徴量ウィンドウで data_status=[DataAvailabilityStatus.NONE,DataAvailabilityStatus.Incomplete] の具体化要求を送信してください。 1 つの具体化要求によって、特徴量ウィンドウ内のすべてのギャップが埋められます。

次の方法で共有

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

特徴量の具体化の探索

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

データ具体化ジョブ

データ具体化の状態によるデータバックフィル

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

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

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

具体化ストアを更新する

オンラインデータブートストラップ

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

ギャップを埋める

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

特徴量の具体化の探索

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

データ具体化ジョブ

データ具体化の状態によるデータ バックフィル

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

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

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

具体化ストアを更新する

オンライン データ ブートストラップ

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

ギャップを埋める

次のステップ

フィードバック

その他のリソース

データ具体化の状態によるデータバックフィル

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

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

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

オンラインデータブートストラップ

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