共用方式為


.create materialized-view

適用於: ✅Microsoft網狀架構Azure 數據總管

具體化檢視是源數據表的匯總查詢。 它表示單 summarize 一語句。

有兩種方法可以建立具體化檢視,如命令中的backfill選項所指出:

從現在開始建立具體化檢視:

  • 具體化檢視會建立空白。 它只包含檢視建立之後所擷取的記錄。 此類型的建立會立即傳回,而且檢視會立即可供查詢。

根據源數據表中的現有記錄建立具體化檢視:

  • 請參閱 回填具體化檢視
  • 建立可能需要很長的時間才能完成,視源數據表中的記錄數目而定。 在完成回填之前,檢視將無法供查詢使用。
  • 當您使用這個選項時,create 命令必須是 async。 您可以使用 命令來監視執行 .show operations
  • 您可以使用 命令取消回填程式 .cancel operation

重要

在大型源數據表上,回填選項可能需要很長的時間才能完成。 如果此程式在執行時暫時失敗,則不會自動重試。 然後,您必須重新執行 create 命令。 如需詳細資訊,請參閱 回填具體化檢視

權限

此命令需要 Database Admin 許可權。 具體化檢視的建立者會成為它的系統管理員。

語法

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )MaterializedViewName SourceTableName 查詢on table { }

深入瞭解 語法慣例

參數

姓名 類型​​ 必要 描述
PropertyNamePropertyValue string 名稱與值組形式的屬性清單,來自支援的屬性清單
MaterializedViewName string ✔️ 具體化檢視的名稱。 檢視名稱不能與相同資料庫中的數據表或函式名稱衝突,而且必須遵守 標識符命名規則
SourceTableName string ✔️ 定義檢視的來源數據表名稱。
查詢 string ✔️ 具體化檢視的查詢定義。 如需詳細資訊和限制,請參閱 查詢參數 一節。

注意

如果具體化檢視已經存在:

  • 如果指定旗 ifnotexists 標,則會忽略命令。 即使新的定義不符合現有的定義,也不會套用任何變更。
  • ifnotexists如果未指定旗標,則會傳回錯誤。
  • 若要改變現有的具體化檢視,請使用 .alter materialized-view 命令。

支援的屬性

PropertyName = PropertyValue) 子句支援with(下列屬性。 所有屬性都是選擇性的。

名稱 類型​​ 描述
回填 bool 是要根據目前 SourceTable 的所有true記錄來建立檢視,還是從現在開始建立檢視。false。 預設值為 false。 如需詳細資訊,請參閱 回填具體化檢視
effectiveDateTime datetime 只有在您使用 backfill時才相關。 如果已設定,則建立只會填入日期時間之後內嵌的記錄。 backfill 也必須設定為 true。 此屬性需要 datetime 常值;例如, effectiveDateTime=datetime(2019-05-01)
updateExtentsCreationTime bool 只有在您使用 backfill時才相關。 如果設定為 true則會在回填程式期間,根據 datetime 群組索引鍵指派範圍建立時間 。 如需詳細資訊,請參閱 回填具體化檢視
lookback timespan 僅適用於arg_maxarg_min//take_any具體化檢視。 它會限制預期重複項目的時間週期。 例如,如果在檢視上 arg_max 指定了 6 小時的回溯,新擷取記錄與現有記錄之間的重複資料刪除只會考慮最多 6 小時前擷取的記錄。

回溯相對於 ingestion_time()。 如果具體化檢視查詢未保留 ingestion_time() 值,則無法在檢視上定義回溯。 請參閱 具體化檢視限制和已知問題。 不正確地定義回溯期間可能會導致具體化檢視中的重複專案。 例如,如果特定索引鍵的記錄在擷取相同索引鍵的記錄之後 10 小時內嵌,且回溯設定為 6 小時,該索引鍵會在檢視中重複。 回溯期間會同時套用具體化時間和查詢時間
autoUpdateSchema bool 是否要自動更新源數據表上的檢視變更。 預設值為 false。 此選項僅適用於 類型的 arg_max(Timestamp, *)/arg_min(Timestamp, *)/take_any(*) 檢視(只有當數據行的自變數為 *時)。 如果此選項設定為 true,源數據表的變更將會自動反映在具體化檢視中。
dimensionTables 陣列 包含檢視中維度數據表數位的動態自變數。 請參閱 查詢參數
folder string 具體化檢視的資料夾。
docString string 記錄具體化檢視的字串。
allowMaterializedViewsWithoutRowLevelSecurity bool 允許在已啟用數據列層級安全策略的數據表上建立具體化檢視。

警告

  • 如果具體化檢視的源數據表變更或數據變更,系統會自動停用具體化檢視,而導致具體化檢視查詢與預期的具體化檢視架構不相容。
  • 若要避免此錯誤,具體化檢視查詢必須具決定性。 例如, bag_unpack樞紐 外掛程式會產生不具決定性的架構。
  • 當您使用 arg_max(Timestamp, *) 匯總,而當 為 false 時 autoUpdateSchema ,源數據表的變更也會導致架構不符。 藉由將檢視查詢 arg_max(Timestamp, Column1, Column2, ...)定義為 ,或使用 autoUpdateSchema 選項來避免此失敗。
  • 卸除源數據表中的數據行時,使用 autoUpdateSchema 可能會導致無法復原的數據遺失。
  • 使用 MaterializedViewResult計量監視具體化檢視的自動停用。
  • 修正不相容問題之後,您應該使用 啟用具體化檢視命令明確地重新啟用檢視

透過具體化檢視建立具體化檢視

只有當來源具體化檢視是匯總(重複數據刪除)時,才可以在另一個 take_any(*) 具體化檢視上建立具體化檢視。 如需詳細資訊,請參閱具體化檢視和範例的具體化檢視。

語法:

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )MaterializedViewName SourceMaterializedViewName 查詢on materialized-view { }

參數:

名稱 類型​​ 必要 描述
PropertyNamePropertyValue string 名稱與值組形式的屬性清單,來自支援的屬性清單
MaterializedViewName string ✔️ 具體化檢視的名稱。 檢視名稱不能與相同資料庫中的數據表或函式名稱衝突,而且必須遵守 標識符命名規則
SourceMaterializedViewName string ✔️ 定義檢視的來源具體化檢視名稱。
查詢 string ✔️ 具體化檢視的查詢定義。

範例

  • 建立空 arg_max 的檢視,只具體化從現在開始擷取的記錄:

    .create materialized-view ArgMax on table T
    {
        T | summarize arg_max(Timestamp, *) by User
    }
    
  • 使用 async建立每日匯總的具體化檢視,並使用 回填選項:

    .create async materialized-view with (backfill=true, docString="Customer telemetry") CustomerUsage on table T
    {
        T 
        | extend Day = bin(Timestamp, 1d)
        | summarize count(), dcount(User), max(Duration) by Customer, Day 
    } 
    
  • 使用和 effectiveDateTime建立具體化檢視backfill。 檢視是根據日期時間的記錄所建立。

    .create async materialized-view with (backfill=true, effectiveDateTime=datetime(2019-01-01)) CustomerUsage on table T 
    {
        T 
        | extend Day = bin(Timestamp, 1d)
        | summarize count(), dcount(User), max(Duration) by Customer, Day
    } 
    
  • 使用回溯 6 小時,根據 EventId 數據行建立重複數據刪除源數據表的具體化檢視。 記錄只會針對目前記錄前 6 小時內嵌的記錄進行重複數據刪除。

    .create materialized-view with(lookback=6h) DeduplicatedTable on table T
    {
        T
        | summarize take_any(*) by EventId
    }
    
  • 建立以先前 DeduplicatedTable 具體化檢視為基礎的向下取樣具體化檢視:

    .create materialized-view DailyUsage on materialized-view DeduplicatedTable
    {
        DeduplicatedTable
        | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
    }
    
  • 定義可以在 語句之前 summarize 包含其他運算符,只要 summarize 是最後一個運算符:

    .create materialized-view CustomerUsage on table T 
    {
        T 
        | where Customer in ("Customer1", "Customer2", "CustomerN")
        | parse Url with "https://contoso.com/" Api "/" *
        | extend Month = startofmonth(Timestamp)
        | summarize count(), dcount(User), max(Duration) by Customer, Api, Month
    }
    
  • 以下是與維度數據表聯結的具體化檢視:

    .create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T
    {
        T
        | lookup DimUsers on User  
        | summarize arg_max(Timestamp, *) by User 
    }
    
    .create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T 
    {
        DimUsers | project User, Age, Address
        | join kind=rightouter hint.strategy=broadcast T on User
        | summarize arg_max(Timestamp, *) by User 
    }
    

備註

查詢參數

下列規則會限制具體化檢視 Query 參數中使用的查詢:

  • 查詢應該參考單一事實數據表,該數據表是具體化檢視的來源。 它應該包含單 summarize 一運算符,以及一或多個 依表達式匯總的一或多個群組匯總的聚合 函數。 運算元 summarize 一律必須是查詢中的最後一個運算符。

    只包含單arg_maxtake_any/arg_min/一匯總的具體化檢視可能會比包含這些匯總和其他匯總的具體化檢視執行得更好(例如 )。count/dcount/avg 這是因為某些優化只與這類具體化檢視有關。 當檢視包含混合聚合函數時,不適用它們(其中混合表示/take_anyarg_max/arg_min和相同檢視中的其他匯總)。

  • 查詢不應包含相依 now()的任何運算符。 例如,查詢不應該有 where Timestamp > ago(5d)。 在具體化檢視上使用保留原則來限制檢視涵蓋的時間週期。

  • 具體化檢視查詢不支援下列運算子:sort、、top-nestedtoppartitionserialize

  • 具體化檢視的定義不支持復合匯總。 例如,而不是使用 SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id,請將具體化檢視定義為: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id。 在檢視查詢期間,執行 MaterializedViewName | project Id, Result=a/b。 檢視的必要輸出,包括匯出數據行 (a/b), 可以封裝在預存函式。 存取預存函式,而不是直接存取具體化檢視。

  • 不支援跨叢集和跨資料庫查詢。
  • 不支援跨 Eventhouse 和跨資料庫查詢。
  • 不支援external_table()externaldata 的參考。

  • 具體化檢視查詢不能包含任何需要仿真的圖說文字。 具體而言,不允許使用仿真的所有 查詢連線外掛程式

  • 除了檢視的源數據表之外,查詢還允許參考一或多個 維度數據表。 維度數據表必須在檢視屬性中明確呼叫。 當您與維度數據表聯結時,請務必瞭解下列行為:

    • 檢視源數據表中的記錄只會具體化一次。 維度數據表的更新不會影響已從事實數據表處理的記錄。

    • 事實數據表和維度數據表之間的不同擷取延遲可能會影響檢視結果。

      範例:檢視定義包含維度數據表的內部聯結。 在具體化時,維度記錄並未完全擷取,但它已經內嵌到事實數據表中。 此記錄將會從檢視中卸除,且永遠不會再處理。

      同樣地,如果聯結是外部聯結,則會處理事實數據表中的記錄,並以維度數據表數據行的 Null 值加入檢視。 已新增至檢視的記錄(具有 Null 值)將不會再次處理。 其值在維度數據表的數據行中,會維持 Null。

支援的聚合函數

支援下列聚合函數:

效能祕訣

  • 使用日期時間群組索引鍵:具有 datetime 數據行做為其群組索引鍵之一的具體化檢視比沒有的索引鍵更有效率。 原因是只有在有日期時間群組索引鍵時,才能套用某些優化。 如果新增日期時間群組索引鍵不會變更匯總的語意,建議您新增它。 只有當每個唯一實體的 datetime 數據行不 可變 時,您才能這麼做。

    例如,在下列匯總中:

        SourceTable | summarize take_any(*) by EventId
    

    如果 EventId 一律具有相同 Timestamp 的值,因此新增 Timestamp 並不會變更匯總的語意,最好將檢視定義為:

        SourceTable | summarize take_any(*) by EventId, Timestamp
    

    提示

    日期時間群組索引鍵中的延遲抵達數據可能會對具體化檢視的效能產生負面影響。 例如,假設具體化檢視使用 bin(Timestamp, 1d) 做為其其中一個群組索引鍵,而新內嵌至源數據表的記錄具有舊 Timestamp 值。 這些記錄可能會對具體化檢視產生負面影響。

    如果您預期已晚抵達的記錄擷取至源數據表,請據以調整具體化檢視的快取原則。 例如,如果預期使用 Timestamp 為六個月前的記錄擷取至源數據表,具體化程式將需要掃描過去六個月的具體化檢視。 如果這個期間處於冷快取中,具體化將遇到快取遺漏,而對檢視效能會有負面影響。

    如果這類遲到的記錄不預期,建議您在具體化檢視查詢中篩選掉這些記錄,或將其時間戳值正規化為目前時間。

  • 定義回溯期間:如果適用於您的案例,新增 lookback 屬性可以大幅改善查詢效能。 如需詳細資訊,請參閱 支援的屬性

  • 新增經常用來篩選為分組索引鍵的數據行:具體化檢視查詢在依具體化檢視的其中一個群組索引鍵篩選時會優化。 如果您知道查詢模式通常會依據具體化檢視中唯一實體的數據行進行篩選,請將它包含在具體化檢視的群組索引鍵中。

    例如,具體化檢視會 arg_maxResourceId 通常由 SubscriptionId篩選的值公開。 假設 ResourceId 值一律屬於相同的 SubscriptionId 值,請將具體化檢視查詢定義為:

    .create materialized-view ArgMaxResourceId on table FactResources
    {
        FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
    }
    

    上述定義優於下列專案:

    .create materialized-view ArgMaxResourceId on table FactResources
    {
        FactResources | summarize arg_max(Timestamp, *) by ResourceId 
    }
    
  • 適當時使用更新原則:具體化檢視可以包含維度數據表中的轉換、正規化和查閱。 不過,我們建議您將這些作業 移至更新原則。 只保留具體化檢視的匯總。

    例如,最好定義下列更新原則:

    .alter-merge table Target policy update 
    @'[{"IsEnabled": true, 
        "Source": "SourceTable", 
        "Query": 
            "SourceTable 
            | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
            | lookup DimResources on ResourceId
            | mv-expand Events
        "IsTransactional": false}]'  
    

    並定義下列具體化檢視:

    .create materialized-view Usage on table Events
    {
        Target 
        | summarize count() by ResourceId 
    }
    

    替代做法是將更新原則納入具體化檢視查詢的一部分,可能會執行得更糟,因此不建議:

    .create materialized-view Usage on table SourceTable
    {
        SourceTable
        | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
        | lookup DimResources on ResourceId
        | mv-expand Events
        | summarize count() by ResourceId
    }
    

提示

如果您需要最佳的查詢時間效能,但您可以容忍某些數據延遲,請使用 materialized_view() 函式

回填具體化檢視

當您使用 backfill 屬性建立具體化檢視時,會根據源數據表中可用的記錄來建立具體化檢視。 或者,如果您使用 effectiveDateTime,則會根據這些記錄的子集來建立。

在幕後,回填程式會將數據分割成多個批次,並執行數個擷取作業來回填檢視。 當源數據表中的記錄數目很大時,此程式可能需要很長的時間才能完成。 進程持續時間取決於資料庫大小。 使用 .show operations 命令來追蹤回填進度。

系統會重試在回填過程中發生的暫時性失敗。 如果所有重試都用盡,命令將會失敗,而且需要手動重新執行 create 命令。

建議您不要在源數據表中的記錄數目超過 number-of-nodes X 200 million 時使用回填(有時甚至更少,視查詢的複雜度而定)。 替代方法是移動範圍選項的回填。

冷快取中的數據不支援使用回填選項。 視需要增加經常性快取期間,檢視建立期間。 這可能需要向外延展。

如果您在檢視建立時發生失敗,請嘗試變更這些屬性:

  • MaxSourceRecordsForSingleIngest:根據預設,回填期間每個擷取作業中的來源記錄數目是每個節點 2 百萬筆。 您可以將此屬性設定為所需的記錄數目,以變更此預設值。 (此值是 每個擷取作業中的記錄總數

    在記憶體限制或查詢逾時建立失敗時,減少此值會很有説明。 增加此值可以加速檢視建立,假設資料庫可以在比預設值更多的記錄上執行匯總函式。

  • Concurrency:擷取作業,以回填程式一部分的形式執行,同時執行。 根據預設,並行為 min(number_of_nodes * 2, 5)。 您可以設定此屬性來增加或減少並行。 只有當 databse 的 CPU 不足時,建議只增加此值,因為增加可能會大幅影響資料庫的 CPU 耗用量。

例如,下列命令會從 2020-01-01重新填入具體化檢視。 每個擷取作業中的記錄數目上限為300萬筆。 此命令會以的並行方式 2執行內嵌作業。

.create async materialized-view with (
        backfill=true,
        effectiveDateTime=datetime(2020-01-01),
        MaxSourceRecordsForSingleIngest=3000000,
        Concurrency=2
    )
    CustomerUsage on table T
{
    T
    | summarize count(), dcount(User), max(Duration) by Customer, bin(Timestamp, 1d)
} 

如果具體化檢視包含日期時間群組索引鍵,則回填程式支持根據 datetime 數據行覆寫 範圍建立時間 。 例如,如果您想要在最近的記錄之前卸除較舊的記錄,因為 保留原則 是以建立時間範圍為基礎,這非常有用。 updateExtentsCreationTime只有當檢視包含使用 bin() 函式的datetime群組索引鍵時,才支援屬性。 例如,下列回填會根據 Timestamp 群組索引鍵指派建立時間:

.create async materialized-view with (
        backfill=true,
        updateExtentsCreationTime=true
    )
    CustomerUsage on table T
{
    T
    | summarize count() by Customer, bin(Timestamp, 1d)
} 

移動範圍回填

移動範圍所回填的選項會根據現有的數據表來回填具體化檢視,這不一定是具體化檢視的源數據表。 您可以將指定數據表的範圍移至基礎具體化檢視表,以達成回填。 此程式表示:

  • 指定數據表中的數據應該具有與具體化檢視架構相同的架構。
  • 指定數據表中的記錄會依目前方式移至檢視。 系統會根據具體化檢視的定義進行重複數據刪除。

例如,如果具體化檢視具有下列匯總:

T | summarize arg_max(Timestamp, *) by EventId

然後,移動範圍作業之源數據表中的記錄應該已經由 重複數據刪除 EventID

由於作業使用 .move 範圍,因此記錄將會 在回填期間從指定的數據表中移除 (移動,未複製)。

具體化檢視中支援的所有聚合函數都不支援移動範圍回填。 匯總會失敗,例如 avg()dcount(),其中儲存在檢視中的基礎數據與匯總本身不同。

具體化檢視只會根據指定的數據表回填。 根據預設,檢視源數據表中記錄的具體化將從檢視建立時間開始。

如果具體化檢視的源數據表持續擷取數據,使用移動範圍建立檢視可能會導致某些數據遺失。 這是因為擷取到源數據表的記錄,在準備數據表回填的時間與建立檢視的時間之間的短時間內,將不會包含在具體化檢視中。 若要處理此案例,您可以將 屬性設定 source_ingestion_time_from 為源數據表上具體化檢視的開始時間。

使用案例

移動範圍回填的選項在兩個主要案例中很有用:

  • 當您已經有包含具體化檢視重複數據刪除源數據的數據表時,而且檢視建立之後就不需要此數據表中的這些記錄,因為您只使用具體化檢視。

  • 當具體化檢視的源數據表非常大,且根據源數據表回填檢視並無法正常運作時,因為先前所述的限制。 在此情況下,您可以使用從查詢命令擷取,自行協調回填程式到臨時表。 當臨時表包含回填的所有記錄時,請根據該數據表建立具體化檢視。

您也可以使用其中一個建議的 協調流程工具

範例:

  • 在下列範例中,數據表 DeduplicatedTable 會包含每個 EventId 實例的單一記錄,並且將做為具體化檢視的基準。 只有在檢視建立時間之後內嵌的記錄 T 才會包含在具體化檢視中。

    .create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
    {
        T
        | summarize arg_max(Timestamp, *) by EventId
    } 
    
  • 如果屬性effectiveDateTimemove_extents_from 屬性一起指定,則只有DeduplicatedTableMaxCreatedOn值大於effectiveDateTime內填的範圍才會包含在回填中(移至具體化檢視):

    .create async materialized-view with 
        (move_extents_from=DeduplicatedTable, effectiveDateTime=datetime(2019-01-01)) 
        MV on table T
    {
        T
        | summarize arg_max(Timestamp, *) by EventId
    } 
    
  • 下列範例示範在 source_ingestion_time_from 移動範圍回填選項中使用 屬性。 source_ingestion_time_from使用 和 move_extents_from 表示具體化檢視是從兩個來源回填:

    • 表格move_extents_fromDeduplicatedTable在下列範例中。 此數據表應包含要回填的所有歷程記錄數據。 您可以選擇性地使用 effectiveDateTime 屬性,只包含其MaxCreatedOn值大於effectiveDateTime的範圍DeduplicatedTable

    • 具體化檢視的源數據表: T 在下列範例中。 此數據表的回填只包含ingestion_time() 值大於 source_ingestion_time_from記錄。

      source_ingestion_time_from屬性應該只用來在準備數據表以從 (DeduplicatedTable) 和建立檢視的時間之間的短時間內處理可能的數據遺失。 請勿在過去設定此屬性太遠。 這會以明顯的延遲開始具體化檢視,這可能很難趕上。

    在下列範例中,假設目前的時間是 2020-01-01 03:00。 Table DeduplicatedTable 是 的重複資料刪除資料表 T。 其中包含所有歷程記錄數據,重複數據刪除直到 2020-01-01 00:00為止。 create命令會使用 DeduplicatedTable 移動範圍來回填具體化檢視。 命令create也包含自 之後2020-01-01內嵌的所有記錄T

    .create async materialized-view with (move_extents_from=DeduplicatedTable, source_ingestion_time_from=datetime(2020-01-01)) MV on table T
    {
        T
        | summarize arg_max(Timestamp, *) by EventId
    } 
    

取消具體化檢視建立

當您使用 [回填] 選項時,您可以取消具體化檢視建立的程式。 建立時間過長,且您想要在執行時停止動作時,此動作很有用。

警告

執行此命令之後,就無法還原具體化檢視。

無法立即取消建立程式。 cancel 命令會發出具體化信號以停止,而建立會定期檢查是否已要求取消。 cancel 命令會等候最多 10 分鐘的時間,直到具體化檢視建立程式取消為止,而且會回報取消是否成功。

即使取消在 10 分鐘內未成功,而且取消命令會回報失敗,具體化檢視可能會在建立程式中稍後自行取消。 .show operations命令會指出作業是否已取消。

如果發出命令時 .cancel operation 作業不再進行中,命令會回報錯誤,並指出。

語法

.cancel operationoperationId

深入瞭解 語法慣例

參數

姓名 類型​​ 必要 描述
operationId guid ✔️ 從命令傳回的作業標識碼 .create async materialized-view

輸出

名字 類型​​ 描述
OperationId guid 命令的 .create materialized-view 作業識別碼。
作業 string 作業的類型。
StartedOn datetime 建立作業的開始時間。
CancellationState string 其中一個: Canceled successfully (建立已取消), Cancellation failed (等待取消逾時),(檢視建立已不再執行, Unknown 但未取消此作業)。
ReasonPhrase string 取消失敗的原因。

範例

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e
OperationId 作業 StartedOn CancellationState ReasonPhrase
c4b29441-4873-4e36-8310-c631c35c916e MaterializedViewCreateOrAlter 2020-05-08 19:45:03.9184142 Canceled successfully

如果取消未在 10 分鐘內完成, CancellationState 將會指出失敗。 然後可以取消建立。