功能集具體化概念

具體化會根據來源資料計算功能值。 開始時間和結束時間值會定義功能視窗。 具體化作業會計算此功能視窗中的功能。 然後將具體化功能值儲存至線上或離線具體化存放區中。 資料具體化之後，所有功能查詢都可以使用具體化存放區中的這些值。

沒有具體化時，功能集離線查詢會即時將轉換套用至來源，以便在查詢傳回值之前先計算功能。 此程序適用於原型設計階段。 然而，針對實際執行環境中的定型和推斷作業，則應在定型或推斷之前具體化功能。 該階段的具體化提供了更高的可靠性和可用性。

探索功能具體化

具體化作業 UI 會顯示離線和線上具體化存放區中的資料具體化狀態，以及具體化作業清單。

在功能視窗中：

• 頂端的時間序列圖表顯示了離線和線上存放區落入功能視窗的資料間隔以及具體化狀態。
• 底部的作業清單顯示了所有具體化作業，其處理視窗與所選功能視窗重疊。

資料具體化狀態和資料間隔

資料間隔是功能集將功能值具體化為下列狀態之一的時間範圍：

• 完成 (綠色) - 成功的資料具體化
• 未完成 (紅色) - 此資料間隔中一或多個已取消或失敗的具體化作業
• 擱置 (藍色) - 此資料間隔中一或多個具體化作業正在進行中
• 無 (灰色) - 未針對此資料間隔提交具體化作業

針對功能集執行具體化作業時，便會建立或合併資料間隔：

• 當兩個資料間隔在時間軸上處於連續狀態，且具有相同的資料具體化狀態時，則會變成一個資料間隔
• 在資料間隔中，當部分功能資料再次具體化，因此進入不同的資料具體化狀態時，則資料間隔會分割為多個資料間隔

當使用者選取功能視窗時，可能會在該視窗中看到多個具有不同資料具體化狀態的資料間隔。 他們可能會看到在時間軸上不相鄰的多個資料間隔。 例如，針對離線具體化存放區中定義的功能視窗，先前的快照集有 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。

您可以透過下列方式提交回填作業：

• 資料具體化狀態
• 已取消或失敗具體化作業的作業識別碼

依資料具體化狀態進行資料回填

使用者可以透過下列方式提交回填要求：

• 資料具體化狀態值的清單 - 未完成、完成或無
• 功能視窗 (選用)

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 的最後一個資料間隔結束時間。

注意

如果尚未提交功能集的回填或週期性作業，則提交的第一個回填作業必須包含功能視窗開始時間和結束時間。

此範例具有目前資料間隔和具體化狀態值，如下所示：

開始時間	結束時間	資料具體化狀態
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 日建立一個新的資料間隔，因為當天有一半時間目前都處於不同的具體化狀態：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)

比較這些最新要求作業的功能視窗，以及上述範例中顯示的要求作業。

依作業識別碼進行資料回填

您也可以使用作業識別碼建立回填要求。 這是重試失敗或已取消具體化作業的簡便方式。 首先，尋找要重試作業的作業識別碼：

• 瀏覽至功能集的 [具體化作業] UI
• 選取具失敗 [狀態] 值的特定作業 [顯示名稱]
• 在作業 [概觀] 頁面上，在 [名稱] 屬性下找到開頭為 Featurestore-Materialization- 的相關作業識別碼值。

SDK

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

SDK 和 CLI

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>

您可以使用失敗或已取消具體化作業的作業識別碼來提交回填作業。 在此情況下，原始失敗或已取消的具體化作業功能視窗資料狀態應為 Incomplete。 如果不符合此條件，則依識別碼進行回填作業會導致使用者錯誤。 例如，失敗的具體化作業可能會有一個功能視窗開始時間 2023-04-01T04:00:00.000 值以及結束時間 2023-04-09T04:00:00.000 值。 只有在時間範圍 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 日執行的作業會在不同的時間範圍內產生功能：

• source_delay=0 在時間範圍 [2023-04-30T04:00:00.000, 2023-05-01T04:00:00.000) 內產生功能值
• source_delay=2hours 在時間範圍 [2023-04-30T02:00:00.000, 2023-05-01T02:00:00.000) 內產生功能值
• source_delay=4hours 在時間範圍 [2023-04-30T00:00:00.000, 2023-05-01T00:00:00.000) 內產生功能值

更新具體化存放區

在更新功能存放區的線上或離線具體化存放區之前，該功能存放區中的所有功能集都應該停用對應的離線和/或線上具體化。 如果某些功能集已啟用具體化，則更新作業會因為 UserError 而失敗。

如果功能集上已停用離線和/或線上具體化，則離線和/或線上具體化存放區中資料的具體化狀態會重設。 重設會將具體化資料轉譯為無法使用。 如果稍後啟用功能集上的離線和/或線上具體化，則使用者必須重新提交其具體化作業。

線上資料啟動程序

只有在提交的離線具體化作業順利完成時，才適用線上資料啟動程序。 如果最初僅針對功能集啟用離線具體化，稍後才啟用線上具體化，則：

• 線上存放區中資料的預設資料具體化狀態為 None

• 提交線上具體化作業時，會將離線存放區中具有 Complete 具體化狀態的資料用於計算線上功能。 這稱為線上資料啟動載入。 線上資料啟動載入可節省計算成本，因其會重複使用儲存在離線具體化存放區中的已計算功能。下表摘要說明資料間隔中導致線上資料啟動載入的離線和線上資料狀態值：

  開始時間	結束時間	離線資料狀態	線上資料狀態	線上資料啟動程序
  2023-04-01T04:00:00.000	2023-04-02T04:00:00.000	None	None	No
  2023-04-02T04:00:00.000	2023-04-03T04:00:00.000	Incomplete	None	No
  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	Yes

解決來源資料錯誤和修改

某些案例在資料具體化後，會因為錯誤或其他原因而修改來源資料。 在這些情況下，針對跨多個資料間隔的特定功能視窗執行功能資料重新整理，可以解決錯誤或過時的功能資料。 在資料狀態為 None、Complete 和 Incomplete 的功能視窗中，提交錯誤或過時功能資料解決方案的具體化請求。

只有在功能視窗未包含具有 Pending 資料狀態的任何資料間隔時，您才可提交功能資料重新整理的具體化要求。

填滿間距

在具體化存放區中，具體化資料可能有間距，因為：

• 從未針對功能視窗提交具體化作業
• 針對功能視窗提交的具體化作業失敗或已取消

在此情況下，請在功能視窗中提交具體化要求，以便 data_status=[DataAvailabilityStatus.NONE,DataAvailabilityStatus.Incomplete] 填滿間距。 單一具體化要求會填滿功能視窗中的所有間距。

下一步

• 教學課程 1：使用受管理的功能存放區開發及註冊功能集
• GitHub 範例存放庫