實體化特徵檢視

這很重要

這項功能目前處於公開預覽版。工作區管理員可以從 「預覽 」頁面控制對此功能的存取。請參閱管理 Azure Databricks 預覽。

在建立好功能檢視定義（儲存在 Unity 目錄）後，你可以利用這些特徵定義從來源資料表產生功能資料。這個過程稱為具象化你的特徵。 Azure Databricks 會建立並管理 Lakeflow 管線，將資料填入 Unity Catalog 中的資料表，供模型訓練、批次評分或線上推論服務使用。

關於提供特徵檢視的資訊，請參見「服務功能檢視」。

需求

特徵必須以特徵檢視（Feature View）形式建立並儲存在 Unity 目錄中。
關於版本需求，請參見需求。

依功能類型提供的具體化支援

特徵是否能及在哪裡實現取決於其類型：

ColumnSelection 功能可以實體化到線上商店。參見列選擇實體化。
帶有 a RollingWindow 的批次Last功能可以實體化到線上商店。參見「Materialize」受新鮮度限制的最新值。
RequestSource、FeatureViewSource 和 CustomUDF 功能無法實體化。請參見隨選功能與實體化。

僅在線上商店實現的功能仍可離線使用： create_training_set 且 compute_features 其時間點數值直接從來源計算，因此無需離線實體化。

柱選擇實現

ColumnSelection 功能是選擇每個實體鍵的單一欄位最新值，不需匯總。它們只能在網路商店中實現。對於離線使用情境（訓練與批次推論）， ColumnSelection 特徵會在查詢時直接從來源資料擷取，因此不需要離線實體化。

物質化行為

資料管線會將每個實體鍵對應的最新的列寫入即時資料表，且沒有聚合窗口。
線上具現化會以最新的每個實體鍵值填滿線上表格。

範例

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    DeltaTableSource, Feature, ColumnSelection, TableTrigger, OnlineStoreConfig,
)

fe = FeatureEngineeringClient()

delta_source = DeltaTableSource(
    catalog_name="catalog",
    schema_name="schema",
    table_name="transactions",
)

amount_feature = Feature(
    source=delta_source,
    function=ColumnSelection("amount"),
    entity=["user_id"],
    timeseries_column="transaction_time",
    name="latest_transaction_amount",
)

# Register before materializing
amount_feature = fe.register_feature(
    feature=amount_feature,
    catalog_name="catalog",
    schema_name="schema",
)

mfs = fe.materialize_features(
    features=[amount_feature],
    online_config=OnlineStoreConfig(
        catalog_name="catalog",
        schema_name="feats_online",
        table_name_prefix="txn_",
        online_store_name="lb_usw2"
    ),
    trigger=TableTrigger(),
)

ColumnSelection 特性使用 TableTrigger，當來源 Delta 資料表收到新的提交時，該管線便會運行。不需要 offline_config ，因為 ColumnSelection 功能是直接從來源讀取，用於離線使用（訓練和批次推論）。

Note

RequestSource 特徵無法實體化，因為它們代表呼叫者在推論時提供的資料（或在訓練時從標記資料框中擷取）。沒有來源表可供閱讀。這些值僅存在於請求有效載荷或訓練資料框架中。

具現化受新鮮度界限約束的最新值

帶有的RollingWindow批次Last聚合會賦予線上功能一個存活時間（TTL）：當該視窗內沒有來源值時，該功能的價值會從線上商店中失效。當價值的年齡決定是否安全服役時，這很有用。例如，過去一小時的裝置狀態可以被提供，而較舊的狀態則會被解析為空，而非無限期地保持可用。

A RollingWindow 定義了一個明確的持續時間，使該特徵具有類似 TTL 的行為。例如，如果來源每天發布數值，而你只想保留過去七天的值，可以使用 a RollingWindow ，且長度為七天。每次觸發時，實體化都會完整替換線上資料表，因此超出窗口範圍的值會按照可預測的排程移除。這會產生與使用 Last 的串流 RollingWindow 相同的結果，但成本較低，因為不需要持續執行運算。

這種發佈模式類似於以快照模式發佈且具有 TTL 的特徵表。如果你維護一組功能表，並想將它們與其他功能檢視一起使用，你可以將它們調整到功能檢視的撰寫框架。使用包含 a RollingWindow 和 a TableTrigger的批次Last。

此組合擁有一種僅限線上的特殊實體化模式，具備以下條件：

來源必須是 DeltaTableSource。
聚合函數必須為 Last，且其視窗必須為 RollingWindow。
實體化必須提供 OnlineStoreConfig、省略 OfflineStoreConfig，並使用 TableTrigger。

以下範例中， latest_device_state_1h 為符合以下要求的註冊特徵：

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import OnlineStoreConfig, TableTrigger

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=[latest_device_state_1h],
    online_config=OnlineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="latest_device_state_serving",
        online_store_name="device_state_store",
    ),
    trigger=TableTrigger(),
)

離線訓練與批次評分時，特徵工程客戶端直接從來源計算時間點值。此功能不會讀取離線具體化資料。

Considerations

到期日僅會在觸發時提前。 當來源資料表的提交作業觸發實體化更新時，線上值及其到期時間都會往後順延。時間本身不會觸發刷新。如果原始碼停止發佈，最後實體化的值會留在線上商店，直到後續提交觸發刷新。
將時間序列欄位與來源發佈時間對齊。 時間序列欄位必須反映來源發布資料的時間。否則，線上與離線值會有所不同，因為線上商店會在觸發時間加入，而離線讀取則在時間序列時間加入。
將視窗長度設為發佈節奏的倍數。 若 RollingWindow 持續期間不是來源發佈週期的整數倍，則部分值在離線訓練期間會被視為已過期，但在線上仍然可見。

隨選功能與實體化

RequestSource 數值來自訓練 DataFrame 或推論請求，因此沒有可實現的原始資料表。 FeatureViewSource 特徵會在訓練或提供服務時，將 CustomUDF 套用至上游特徵值。它們不會儲存預先計算好的結果。對於以 Delta 資料表為基礎的 CustomUDF 功能，也不支援實體化。

對於像是 revenue_sum_7d 和 cost_sum_7d 輸入至 margin 功能的依賴圖：

若想離線訓練，請致電 create_training_setmargin。它解析上游特徵並計算時間點值，並使用相容的離線物質化（如有）。
針對線上服務，將支持的營收與成本功能實體化至線上商店。端點會查詢這些請求並對每個請求進行 margin 計算。
僅將受支援的上游功能傳遞給 materialize_features，不要傳給 margin，也不要傳遞任何以請求為後盾的功能。物質化不會遞迴地實現衍生特徵的依賴關係。

僅使用請求支持功能圖則不需要線上商店。請參閱使用 FeatureViewSource 特徵進行訓練及提供衍生特徵。

許可

實體化需要對功能以及來源和目的資源擁有權限。欲了解完整的 Unity 目錄權限描述，請參閱 Unity 目錄權限參考。

實作某項功能需要 MANAGE。 呼叫 materialize_features 會建立並管理後備的 Lakeflow 管線和 Unity 目錄資料表，因此這是一個管理操作。您必須對該功能具有 MANAGE，並具備 READ FEATURE，才能讀取已具體化的功能定義。
刪除具現化特徵僅限於其創作者。 只有創建實體化功能的使用者才能用 delete_materialized_feature刪除該功能。此限制與 Unity 目錄權限無關： MANAGE 功能或其父架構不允許其他使用者刪除該功能。
讀取原始資料需要 SELECT。 如果是使用 Delta 表格來源的功能，你必須在來源表格上有 SELECT 。若某項功能使用串流來源，您必須在該串流的擷取資料表上具有 SELECT。

關於串流認證設定所需的其他權限，請參見 Kafka 認證。
建立目的資料表需要 CREATE TABLE。 你必須在每個由 OnlineStoreConfig 或 CREATE TABLE 指定的結構描述上具有 OfflineStoreConfig。離線與線上目的地可能位於不同的結構或目錄中，且實體化需要對每個目的地擁有權限。
為線上商店進行具體化需要 CAN USE。 你必須在用於線上商店的 Lakebase 執行個體或專案中擁有 CAN USE。有關 Lakebase 權限的資訊，請參閱 Grant 專案權限。
列出具體化功能需要在父功能上使用 READ FEATURE。 要使用 list_materialized_features，您必須在已實現的功能上擁有 READ FEATURE 。
讀取物質化資料需要 SELECT。 你必須在你所存取的每個離線或線上輸出表上都具備 SELECT。 READ FEATURE 在父功能上不會授權存取這些資料表。

對於每個參與實體化的 Unity Catalog 資源，你還需要在其父目錄上具有 USE CATALOG，並在其父結構描述上具有 USE SCHEMA。此要求適用於功能、每個來源或串流擷取表，以及每個已設定的目的地。在結構描述或目錄上授與的 READ FEATURE 和 MANAGE，適用於其中包含的所有目前及未來項目。

API 資料結構

`OfflineStoreConfig`

離線商店的配置，用於寫入具象化特徵。當 materialize_features 呼叫時，功能庫後端會建立使用此前綴的資料表。根據具體化排程，每次管道執行都會將最新的特徵值實體化到表格中。

OfflineStoreConfig(
    catalog_name: str,        # Catalog name for the offline table where materialized features will be stored
    schema_name: str,         # Schema name for the offline table
    table_name_prefix: str    # Table name prefix for the offline table. The pipeline may create multiple tables with this prefix, each updated at different cadences
)

from databricks.feature_engineering.entities import OfflineStoreConfig

offline_store = OfflineStoreConfig(
    catalog_name="main",
    schema_name="feature_store",
    table_name_prefix="customer_features"
)

`OnlineStoreConfig`

線上商店的配置，儲存模型服務所使用的功能。 Materialization 會建立帶有 catalog.schema.table_name_prefix的 Delta 資料表，並將這些資料表串流到同名的線上功能商店。

from databricks.feature_engineering.entities import OnlineStoreConfig

online_store = OnlineStoreConfig(
    catalog_name="main",
    schema_name="feature_store",
    table_name_prefix="customer_features_serving",
    online_store_name="customer_features_store"
)

`MaterializedFeature`

表示已實體化的特徵檢視，也就是說，在 Unity Catalog 中已有可用的預先計算好的表示形式。離線表格和線上表格有各自的具體化功能。通常，使用者不會直接實例化 a MaterializedFeature 。

API 函式呼叫

`materialize_features()`

將功能視圖清單具體化為離線的 Delta 表或線上功能商店。功能必須先在 Unity 目錄中註冊，才能呼叫此函式（例如使用 create_feature 或 register_feature）。本地建造且未註冊的特徵將無法運作。

FeatureEngineeringClient.materialize_features(
    *,                                                                     # Arguments are keyword-only
    features: List[Feature],                                               # List of Feature Views to materialize
    offline_config: Optional[OfflineStoreConfig] = None,                   # Offline store config (aggregation features only)
    online_config: Optional[OnlineStoreConfig] = None,                     # Online store config
    trigger: Union[CronSchedule, TableTrigger, StreamingMode],             # Materialization trigger
    tags: Optional[Dict[str, str]] = None,                                 # Custom tags for cost attribution
    budget_policy_id: Optional[str] = None,                                # Serverless usage policy for cost attribution
) -> List[MaterializedFeature]:

此方法回傳一個實體化特徵清單，其中包含有關特徵值更新時間的中繼資料，以及 Unity Catalog 中特徵實體化的表格。

若同時提供 a OnlineStoreConfig 與 a OfflineStoreConfig ，則每個功能會回傳兩個具體化功能，分別對應一種商店類型。

trigger 參數控制物質化管線的運行時機。

CronSchedule：依照功能時序或來電者提供的Quartz cron排程運行。支援批次聚合功能（AggregationFunction 來自 DeltaTableSource）。
TableTrigger：當上游 Delta 資料表接收到提交時執行。支援 ColumnSelection 功能及由 DeltaTableSource 支援的彙總功能（AggregationFunction）。對於彙總特徵，系統會限制管線的執行頻率，最多只能每隔該特徵粒度的一半執行一次（滑動視窗為滑動間隔，翻滾視窗為視窗長度），此間隔上限為 1 小時，且執行頻率絕不會高於每 5 分鐘一次。例如，最多每 30 分鐘一次，1 小時的細度;最多每小時一次，2 小時以上的細度。這個間隔是以上一次執行時間起算，因此即使提交是在間隔結束後才到達，仍會立即觸發一次執行。
StreamingMode：以連續串流管線運行。這是由 StreamSource 支援的功能所必需。

你無法在單一 materialize_features 呼叫中混用需要不同觸發類型的功能。改為分開來電。

若要將具體化的成本歸因，請傳入 tags、budget_policy_id 或兩者。 Azure Databricks 會將這些資料套用到它所建立的工作或管線上，因此其支出會將你的歸因記錄在可計費使用系統資料表中。兩者皆在創造時應用，因此將現有的物質化歸因不同，意味著創造新的物質化。 budget_policy_id 取一個無伺服器使用政策的 ID。要建立一個並取得其 ID，請參見建立無伺服器使用政策。關於標籤限制、每個值所接觸的資源，以及如何查詢歸屬支出，請參見功能庫成本管理。

實體化到線下商店

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    CronSchedule, OfflineStoreConfig,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=features,
    offline_config=OfflineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features"
    ),
    trigger=CronSchedule(
        quartz_cron_expression="0 0 * * * ?",  # Hourly
        timezone_id="UTC",
    ),
)

實體化到線上商店

Note

若要將大多數聚合特徵具現化到線上儲存區，您也必須將其具現化到離線儲存區。兩者 offline_config 和 online_config 均為必需。必須參考現有的線上特徵庫 online_store_name。關於建立 Feature Store 的說明，請參見 Databricks 線上功能庫。

ColumnSelection 功能不需要 OfflineStoreConfig。參見列選擇實體化。

帶有Last特殊情況的批次RollingWindow也僅限線上。參見「Materialize」受新鮮度限制的最新值。

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    CronSchedule, OfflineStoreConfig, OnlineStoreConfig,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=features,
    offline_config=OfflineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features"
    ),
    online_config=OnlineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features_serving",
        online_store_name="customer_features_store"
    ),
    trigger=CronSchedule(
        quartz_cron_expression="0 0 * * * ?",  # Hourly
        timezone_id="UTC",
    ),
)

Materialize 串流功能

串流功能只能實體化到線上商店;該 offline_config 參數不被支援。離線實體化不被支援，因為串流功能需要即時流程以確保亞秒新鮮度。離線訓練或評估時，特徵工程客戶端會根據每個評估的資料點重新計算特徵值。

串流功能不能與批 materialize_features 次功能在同一通話中混合使用。

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    OnlineStoreConfig, StreamingMode,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=[streaming_feature],
    online_config=OnlineStoreConfig(
        catalog_name="my_catalog",
        schema_name="my_schema",
        table_name_prefix="streaming_features_serving",
        online_store_name="feature_store_online"
    ),
    trigger=StreamingMode(),
)

`list_materialized_features()`

回傳由完整名稱識別的單一特徵之實體化結果。 feature_name 是必填且僅有關鍵字。若要檢視多個特徵的實體化，請先在 catalog 或 schema 中列出這些特徵，然後對傳回的每個特徵呼叫 list_materialized_features。

預設情況下，最多可回傳100個物質化。你可以用參數 max_results 來改變這個限制。

FeatureEngineeringClient.list_materialized_features(
    *,                                      # Arguments are keyword-only
    feature_name: str,                      # Required: full name of the feature whose materializations to list
    max_results: int = 100,                 # Maximum number of materializations to return
) -> List[MaterializedFeature]:

`delete_materialized_feature()`

在刪除實體化特徵前，移除或更新任何參考該特徵的模型或特徵規格。

刪除一個實體化的特徵。要通過的特徵取決於特徵類型：

聚合功能：跳過離線實體化功能。如果同一功能有線上實體化功能，兩者都會被刪除。對於具有 RollingWindow 的僅限線上批次 Last 特徵，請傳遞線上實體化特徵。
ColumnSelection 功能：跳過線上實體化功能。 ColumnSelection 特徵僅實體化到線上商店（參見 ColumnSelection 實體化），因此沒有配對離線功能。

作為物質化的一部分，特徵會依資料來源與聚合視窗分組以提高效率。 ColumnSelection 特徵沒有彙整視窗，因此僅依資料來源分組。物化管線、離線資料表和線上資料表只有在所有分組特徵都被刪除後才會被刪除。當群組中最後一個實體化的特徵被刪除時，特徵存放區會將相關資源排入由背景程序執行的自動清理作業。參見背景資源清理。

要清理物質化特徵，請查看與物質化特徵相關的表格。表格中的每個功能（每欄一個）必須先刪除，才能清理計算與 Delta 資料表資源。

用 list_materialized_features() 來取得 materialized_feature 論點。

FeatureEngineeringClient.delete_materialized_feature(
    materialized_feature: MaterializedFeature,  # Required: The materialized feature to delete
) -> None

from databricks.feature_engineering import FeatureEngineeringClient

fe = FeatureEngineeringClient()

feature_names = [
    "main.feature_store.amount_sum_sliding_7d_1d",
    "main.feature_store.amount_sum_sliding_30d_1d",
    "main.feature_store.transaction_count_sliding_7d_1d",
    "main.feature_store.latest_transaction_amount",
    "main.feature_store.latest_user_tier",
]

for name in feature_names:
    mfs = fe.list_materialized_features(feature_name=name)   # required, keyword-only
    offline = [mf for mf in mfs if not mf.is_online]
    for mf in (offline or mfs):
        fe.delete_materialized_feature(materialized_feature=mf)
    fe.delete_feature(full_name=name)

背景資源清理

當你刪除實體化的特徵時，Databricks 會立即移除該特徵的元資料。相關的基礎設施（資料表、管線和作業）會由背景程序以非同步方式清理。

由於多個實體化特徵可能共享相同的資料表和管線，這些共享資源不會被移除，直到所有參考它們的實體化特徵都被刪除。當共用同一組資料表的最後一個實體化特徵被刪除時，背景程序會自動刪除下列資源：

離線的 Delta 表格包含具體化特徵資料
如果這些功能能實體化到線上商店，線上表格
物質化管線
協調作業

這個背景流程會使用由 Databricks 管理的系統服務主體，代表你執行這些清理動作，包括刪除工作區中的資料表、管線和工作。你不需要採取任何行動。清理工作完全由功能商店負責。

Note

在刪除群組中最後一個實體化特徵與移除相關資料表及其他資源之間，可能會有短暫的延遲。

查看實體化狀態

若要在 Databricks UI 中查看 Feature View 的實體化狀態，並對實體化錯誤進行偵錯，請參閱在 Unity Catalog 中探索 Feature View。

局限性

批次功能

批次物質化管線以無伺服器 Lakeflow 管線形式運作。
批次滾動視窗特徵無法實體化，僅有將具新鮮度界限的最新值實體化中所述的僅限線上使用 Last 特殊情況除外。對於離線訓練或批次推論，都會針對每個時間點查詢，根據來源資料計算滾動視窗特徵。
ColumnSelection 功能只能在線上商店實現。
RequestSource、FeatureViewSource 和 CustomUDF 功能無法實體化。請參見隨選功能與實體化。
具現化特性只能在其建立的工作區中才能被刪除。
只有建立實體化特徵的使用者才能刪除該特徵，不論其對該特徵或其父結構描述擁有哪些 Unity Catalog 權限。
對於實體化聚合功能，線上實體化功能無法直接刪除。刪除配對離線物質化功能，變更會同時傳達到兩者。
對於 2026 年 4 月 20 日之前建立的實體化聚合特徵，物質化管線會持續產生新的特徵值，直到管線中所有實體化特徵被刪除，觸發資源清理。若要建立能支援逐個功能刪除的更新管線，請刪除並重新實體化該功能。
對於實體化 ColumnSelection 特徵，物質化管線會持續產生新的特徵值，直到管線中所有實體化特徵被刪除，這才會觸發資源清理。

串流功能

串流功能只能在線上商店實現。不需要進行離線實體化，因為用於訓練時的串流特徵在設計上，就是要針對每個資料點根據歷史事件重新計算，以達到毫秒等級的精確度。
串流功能不能在單一 materialize_features 通話中與批次功能混合使用。
compute_features 不支援串流功能。
工作區必須位於支援 Lakebase 實例的區域。
僅支援 JSON 序列化的 Kafka 訊息。訊息結構必須直接以 JSON 架構格式提供。在預覽期間，尚未正式支援結構描述登錄（Confluent、Glue）；但如果您直接提供結構描述，管線便可從受結構描述登錄管理的主題讀取資料。
僅 RollingWindow 支援串流聚合功能。 TumblingWindow SlidingWindow並應與批次特徵一起使用。
串流功能僅支援 Count、Avg、Sum、Min、Last、StddevPop、First、LastDistinct、Max、FirstN、LastN 及 FirstDistinct 彙總函數。
串流來源的欄位選擇功能無法處理順序不符的訊息。即使時間序列欄位值早於先前接收的事件，仍會顯示 Kafka 串流中的最新事件。
串流管線每週重啟兩次。每次重啟都可能導致處理延遲和啟動時間長達 1 分鐘。不含重新啟動時，p99 新鮮度為 200 毫秒。
不支援實體化的功能回填。當一個特徵被物質化時，它會從該點開始計算。線上商店中新建立的彙總資料，在其時間範圍結束前都會不準確。
僅支援 Databricks Online 功能商店。
串流實體化管線以無伺服器 Lakeflow 管線形式運作。
僅限企業級工作空間。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-09-30