.create materialized-view

Platí pro: ✅Microsoft Fabric✅Azure Data Explorer

Materializované zobrazení je agregační dotaz nad zdrojovou tabulkou. Představuje jeden summarize příkaz.

Existují dva možné způsoby vytvoření materializovaného zobrazení, jak je uvedeno v možnosti backfill v příkazu:

Vytvořte materializované zobrazení odteď:

• Materializované zobrazení je vytvořené prázdné. Zahrnuje pouze záznamy ingestované po vytvoření zobrazení. Vytvoření tohoto typu se vrátí okamžitě a zobrazení je okamžitě k dispozici pro dotaz.

Vytvořte materializované zobrazení na základě existujících záznamů ve zdrojové tabulce:

• Viz Zobrazení Backfill a materializované zobrazení.
• Dokončení vytváření může trvat dlouho v závislosti na počtu záznamů ve zdrojové tabulce. Zobrazení nebude k dispozici pro dotazy, dokud se nedokončí obnovení.
• Pokud používáte tuto možnost, příkaz create musí být async. Spuštění můžete monitorovat pomocí .show operations příkazu.
• Proces obnovení můžete zrušit pomocí .cancel operation příkazu.

Oprávnění

Tento příkaz vyžaduje oprávnění správce databáze. Tvůrce materializovaného zobrazení se stane správcem.

Syntaxe

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

Přečtěte si další informace o konvencích syntaxe.

Parametry

Podporované vlastnosti

Následující vlastnosti jsou podporovány v klauzuli with (PropertyName = PropertyValue.) Všechny vlastnosti jsou volitelné.

Vytvoření materializovaného zobrazení přes materializované zobrazení

Materializované zobrazení můžete vytvořit v jiném materializovaném zobrazení pouze v případech, kdy je zdrojový materializovaným zobrazením take_any(*) agregace (odstranění duplicitních dat). Další informace naleznete v tématu Materialized view over materialized view and Examples.

Syntaxe:

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

Parametry:

Příklady

• Vytvořte prázdné arg_max zobrazení, které bude materializovat pouze záznamy přijaté odteď:

  .create materialized-view ArgMax on table T
  {
      T | summarize arg_max(Timestamp, *) by User
  }
  

• Vytvořte materializované zobrazení pro denní agregace s možností zpětného vyplňování pomocí: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 
  } 
  

• Vytvoření materializovaného zobrazení pomocí backfill a effectiveDateTime. Zobrazení se vytvoří pouze na základě záznamů z data a času.

  .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
  } 
  

• Pomocí zpětného vyhledávání 6 hodin vytvořte materializované zobrazení, které deduplikuje zdrojovou tabulku na EventId základě sloupce. Záznamy budou odstraněny z duplicitních dat pouze se záznamy ingestovanými 6 hodinami před aktuálními záznamy.

  .create materialized-view with(lookback=6h) DeduplicatedTable on table T
  {
      T
      | summarize take_any(*) by EventId
  }
  

• Vytvořte materializované materializované zobrazení, které je založeno na předchozím DeduplicatedTable materializovaném zobrazení:

  .create materialized-view DailyUsage on materialized-view DeduplicatedTable
  {
      DeduplicatedTable
      | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
  }
  

• Definice může obsahovat další operátory před summarize příkazem, pokud summarize je to poslední:

  .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
  }
  

• Tady jsou materializovaná zobrazení, která spojují tabulku dimenzí:

  .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 
  }
  

Poznámky

Parametr dotazu

Následující pravidla omezují dotaz použitý v parametru materializovaného zobrazení dotazu:

• Dotaz by měl odkazovat na jednu tabulku faktů, která je zdrojem materializovaného zobrazení. Měl by obsahovat jeden summarize operátor a jednu nebo více agregačních funkcí agregovaných jednou nebo více skupinami podle výrazů. Operátor summarize musí být vždy posledním operátorem v dotazu.

  Materializované zobrazení, které zahrnuje pouze jednu arg_maxarg_mintake_any//agregaci, může být lepší než materializované zobrazení, které zahrnuje tyto agregace spolu s dalšími agregacemi (například ).count/dcount/avg Důvodem je, že některé optimalizace jsou relevantní pouze pro tyto druhy materializovaných zobrazení. Nepoužijí se, pokud zobrazení obsahuje smíšené agregační funkce (kde smíšené znamená obě arg_max//arg_mintake_any i jiné agregace ve stejném zobrazení).

• Dotaz by neměl obsahovat žádné operátory, které jsou závislé na now(). Dotaz by například neměl mít where Timestamp > ago(5d). Pomocí zásad uchovávání informací v materializovaném zobrazení omezte dobu, po kterou zobrazení pokrývá.

• V dotazu materializovaného zobrazení nejsou podporovány následující operátory: sort, top-nested, top, partition, serialize.

• Složené agregace nejsou podporovány v definici materializovaného zobrazení. Například místo použití SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Iddefinujte materializované zobrazení jako: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Během doby zobrazení dotazu spusťte MaterializedViewName | project Id, Result=a/b. Požadovaný výstup zobrazení, včetně počítaného sloupce (a/b), lze zapouzdřet do uložené funkce. Přístup k uložené funkci místo přístupu k materializovanému zobrazení přímo.

• Odkazy na external_table() a externaldata se nepodporují.

• Dotaz materializovaného zobrazení nemůže obsahovat žádné popisky, které vyžadují zosobnění. Konkrétně nejsou povoleny všechny moduly plug-in připojení dotazů, které používají zosobnění.

• Kromě zdrojové tabulky zobrazení může dotaz odkazovat na jednu nebo více tabulek dimenzí. Tabulky dimenzí musí být explicitně označeny ve vlastnostech zobrazení. Při připojování k tabulkám dimenzí je důležité pochopit následující chování:

  • Záznamy ve zdrojové tabulce zobrazení (tabulka faktů) jsou materializovány pouze jednou. Aktualizace tabulek dimenzí nemají žádný vliv na záznamy, které už byly zpracovány z tabulky faktů.

  • Jiná latence příjmu dat mezi tabulkou faktů a tabulkou dimenzí může ovlivnit výsledky zobrazení.

    Příklad: Definice zobrazení obsahuje vnitřní spojení s tabulkou dimenzí. V době materializace nebyl záznam dimenze plně přijatý, ale už ingestoval do tabulky faktů. Tento záznam se z zobrazení zahodí a nezpracuje se znovu.

    Podobně pokud je spojení vnější spojení, záznam z tabulky faktů se zpracuje a přidá, aby se zobrazila hodnota null pro sloupce tabulky dimenzí. Záznamy, které už byly přidány (s hodnotami null) do zobrazení, se znovu nezpracují. Jejich hodnoty ve sloupcích z tabulky dimenzí zůstanou null.

Podporované agregační funkce

Podporují se následující agregační funkce:

• count
• countif
• dcount
• dcountif
• min
• max
• avg
• avgif
• sum
• sumif
• arg_max
• arg_min
• take_any
• take_anyif
• hll
• make_set
• make_list
• make_bag
• percentile, percentiles
• tdigest

Tipy týkající se výkonu

• Použijte klíč datetime group-by key: Materializovaná zobrazení, která mají sloupec datetime jako jeden z jejich klíčů seskupování podle skupin, jsou efektivnější než zobrazení, která nemají. Důvodem je, že některé optimalizace se dají použít jenom v případech, kdy je klíč datetime group-by key. Pokud přidání klíče datetime group-by nezmění sémantiku agregace, doporučujeme ho přidat. Můžete to udělat jenom v případě, že je sloupec datetime neměnný pro každou jedinečnou entitu.

  Například v následující agregaci:

      SourceTable | summarize take_any(*) by EventId
  

  Pokud EventId má vždy stejnou Timestamp hodnotu, a proto přidání Timestamp nezmění sémantiku agregace, je lepší definovat zobrazení takto:

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  Tip

  Pozdní příchod dat v klíči datetime podle skupiny může mít negativní dopad na výkon materializovaného zobrazení. Předpokládejme například, že materializované zobrazení používá bin(Timestamp, 1d) jako jeden ze svých klíčů seskupených podle a nově přijatých záznamů do zdrojové tabulky mají staré Timestamp hodnoty. Tyto záznamy můžou negativně ovlivnit materializované zobrazení.

  Pokud očekáváte pozdní příchozí záznamy ingestované do zdrojové tabulky, upravte zásady ukládání do mezipaměti materializovaného zobrazení odpovídajícím způsobem. Pokud se například očekává, že záznamy s časovým razítkem před šesti měsíci se budou ingestovat do zdrojové tabulky, bude proces materializace muset zkontrolovat materializované zobrazení za posledních šest měsíců. Pokud je tato doba v studené mezipaměti, materializace zaznamená neúspěšné mezipaměti, které budou mít negativní dopad na výkon zobrazení.

  Pokud takové opožděné příchozí záznamy nejsou očekávané, doporučujeme, abyste v materializovaném dotazu zobrazení buď tyto záznamy odfiltrovali, nebo normalizovali hodnoty časových razítek na aktuální čas.

• Definujte období zpětného vyhledávání: Pokud je to možné pro váš scénář, přidání lookback vlastnosti může výrazně zlepšit výkon dotazů. Podrobnosti najdete v tématu Podporované vlastnosti.

• Přidání sloupců často používaných k filtrování jako klíče seskupených podle: Materializované dotazy zobrazení jsou optimalizované, když jsou filtrovány jedním z materializovaných klíčů zobrazení seskupených podle. Pokud víte, že vzor dotazu bude často filtrovat podle sloupce, který je neměnný podle jedinečné entity v materializovaném zobrazení, zahrňte ho do klíčů seskupování podle materializovaného zobrazení.

  Například materializované zobrazení zveřejňuje arg_max hodnotu ResourceId , která bude často filtrována podle SubscriptionId. Za předpokladu ResourceId , že hodnota vždy patří do stejné SubscriptionId hodnoty, definujte materializovaný dotaz zobrazení jako:

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

  Předchozí definice je vhodnější než následující:

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

• Použijte zásady aktualizace tam, kde je to vhodné: Materializované zobrazení může zahrnovat transformace, normalizace a vyhledávání v tabulkách dimenzí. Doporučujeme ale přesunout tyto operace do zásad aktualizace. Ponechte pouze agregaci pro materializované zobrazení.

  Je například lepší definovat následující zásady aktualizace:

  .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}]'  
  

  A definujte následující materializované zobrazení:

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

  Alternativní možnost zahrnutí zásady aktualizace jako součásti materializovaného dotazu zobrazení může být horší, a proto se nedoporučuje:

  .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
  }
  

Obnovení materializovaného zobrazení

Při vytváření materializovaného zobrazení pomocí backfill vlastnosti se materializované zobrazení vytvoří na základě záznamů dostupných ve zdrojové tabulce. Nebo se vytvoří na základě podmnožina těchto záznamů, pokud použijete effectiveDateTime.

Proces backfillu na pozadí rozdělí data do několika dávek a provede několik operací ingestování pro obnovení zobrazení. Dokončení procesu může trvat dlouhou dobu, když je počet záznamů ve zdrojové tabulce velký. Doba trvání procesu závisí na velikosti databáze. Průběh backfillu můžete sledovat pomocí .show operations příkazu.

Přechodné selhání, ke kterým dochází v rámci procesu obnovení, se opakuje. Pokud dojde k vyčerpání všech opakování, příkaz selže a bude vyžadovat ruční opětovné spuštění příkazu create.

Nedoporučujeme používat backfill, pokud počet záznamů ve zdrojové tabulce překročí number-of-nodes X 200 million (někdy i méně v závislosti na složitosti dotazu). Alternativou je možnost zpětného vyplňování podle rozsahů přesunutí.

Použití možnosti zpětného vyplňování není podporováno pro data v studené mezipaměti. V případě potřeby zvyšte dobu trvání vytváření zobrazení v horké mezipaměti. To může vyžadovat horizontální navýšení kapacity.

Pokud při vytváření zobrazení dochází k chybám, zkuste změnit tyto vlastnosti:

• MaxSourceRecordsForSingleIngest: Ve výchozím nastavení je počet zdrojových záznamů v každé operaci ingestování během obnovení 2 miliony na uzel. Toto výchozí nastavení můžete změnit nastavením této vlastnosti na požadovaný počet záznamů. (Hodnota je celkový počet záznamů v každé operaci ingestování.)

  Snížení této hodnoty může být užitečné při selhání vytváření limitů paměti nebo časových limitů dotazů. Zvýšení této hodnoty může urychlit vytváření zobrazení za předpokladu, že databáze může spustit funkci agregace u více záznamů než výchozí.

• Concurrency: Operace ingestování spuštěné v rámci procesu obnovení se spouští souběžně. Ve výchozím nastavení je min(number_of_nodes * 2, 5)souběžnost . Tuto vlastnost můžete nastavit tak, aby se zvýšila nebo snížila souběžnost. Tuto hodnotu doporučujeme zvýšit pouze v případě nízkého využití procesoru databáze, protože zvýšení může výrazně ovlivnit spotřebu procesoru databáze.

Například následující příkaz obnoví materializované zobrazení z 2020-01-01. Maximální počet záznamů v každé operaci ingestování je 3 miliony. Příkaz provede operace ingestování s souběžností 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)
} 

Pokud materializované zobrazení obsahuje klíč datetime group-by, proces backfill podporuje přepsání času vytvoření rozsahu na základě sloupce datetime. To může být užitečné, například pokud chcete, aby starší záznamy byly vyřazeny před posledními záznamy, protože zásada uchovávání informací je založená na době vytváření rozsahu. Vlastnost updateExtentsCreationTime je podporována pouze v případě, že zobrazení obsahuje klíč datetime group-by, který používá bin() funkci. Například následující backfill přiřadí čas vytvoření na Timestamp základě klíče seskupování podle:

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

Obnovení podle rozsahů přesunu

Možnost obnovení přesunutím rozsahů backfills backfills materializované zobrazení na základě existující tabulky, což nemusí nutně být zdrojová tabulka materializovaného zobrazení. Obnovení dosáhnete přesunutím rozsahů ze zadané tabulky do podkladové materializované tabulky zobrazení. Tento proces znamená, že:

• Data v zadané tabulce by měla mít stejné schéma jako schéma materializovaného zobrazení.
• Záznamy v zadané tabulce se přesunou do zobrazení tak, jak jsou. Předpokládá se, že budou odstraněny na základě definice materializovaného zobrazení.

Pokud má například materializované zobrazení následující agregaci:

T | summarize arg_max(Timestamp, *) by EventId

Záznamy ve zdrojové tabulce pro operaci rozsahů přesunutí by již měly být odstraněny EventID.

Vzhledem k tomu, že operace používá rozsahy .move, budou záznamy odebrány ze zadané tabulky během backfillu (přesunuty, nezkopírovány).

Backfill by move extents není podporován pro všechny agregační funkce podporované v materializovaných zobrazeních. U agregací, jako avg()je například , dcount()se nezdaří, ve kterých se podkladová data uložená v zobrazení liší od samotné agregace.

Materializované zobrazení je znovu vyplněno pouze na základě zadané tabulky. Materializace záznamů ve zdrojové tabulce zobrazení začne ve výchozím nastavení od času vytváření zobrazení.

Pokud zdrojová tabulka materializovaného zobrazení průběžně ingestuje data, může vytvoření zobrazení pomocí rozsahů přesunutí způsobit ztrátu dat. Důvodem je to, že záznamy ingestované do zdrojové tabulky nebudou v krátkém čase mezi přípravou tabulky na obnovení a časem vytvoření zobrazení zahrnuty do materializovaného zobrazení. Pro zpracování tohoto scénáře můžete vlastnost nastavit source_ingestion_time_from na počáteční čas materializovaného zobrazení ve zdrojové tabulce.

Případy použití

Možnost obnovení rozsahů přesunu může být užitečná ve dvou hlavních scénářích:

• Pokud už máte tabulku, která obsahuje zdrojová data odstraněná z duplicit pro materializované zobrazení a po vytvoření zobrazení tyto záznamy v této tabulce nepotřebujete, protože používáte jenom materializované zobrazení.

• Pokud je zdrojová tabulka materializovaného zobrazení velmi velká a obnovení zobrazení založené na zdrojové tabulce nefunguje dobře kvůli omezením uvedeným dříve. V takovém případě můžete proces backfillu orchestrovat sami do dočasné tabulky pomocí ingestování z příkazů dotazu. Pokud dočasná tabulka obsahuje všechny záznamy pro backfill, vytvořte materializované zobrazení založené na této tabulce.

Příklady:

• V následujícím příkladu tabulka DeduplicatedTable obsahuje jeden záznam na EventId instanci a bude použit jako směrný plán pro materializované zobrazení. Do materializovaného zobrazení budou zahrnuty pouze záznamy, které T se ingestují po vytvoření zobrazení.

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

• effectiveDateTime Pokud je vlastnost zadána spolu s move_extents_from vlastností, pouze rozsahy, jejichž DeduplicatedTable MaxCreatedOn hodnota je větší než effectiveDateTime je zahrnuta do backfillu (přesunuta do materializovaného zobrazení):

  .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
  } 
  

• Následující příklad ukazuje použití source_ingestion_time_from vlastnosti v možnosti backfilling podle rozsahů přesunutí. Použití obou source_ingestion_time_from a move_extents_from označuje, že materializované zobrazení je znovu vyplněno ze dvou zdrojů:

  • Tabulkamove_extents_from: DeduplicatedTable v následujícím příkladu. Tato tabulka by měla obsahovat všechna historická data k obnovení. Volitelně můžete vlastnost použít effectiveDateTime k zahrnutí pouze rozsahů, jejichž DeduplicatedTable MaxCreatedOn hodnota je větší než effectiveDateTime.

  • Zdrojová tabulka materializovaného zobrazení: T v následujícím příkladu. Obnovení z této tabulky obsahuje pouze záznamy, jejichž hodnota ingestion_time() je větší než source_ingestion_time_from.

    Vlastnost source_ingestion_time_from by měla být použita pouze ke zpracování možné ztráty dat v krátké době mezi přípravou tabulky na backfill from (DeduplicatedTable) a časem vytvoření zobrazení. Nenastavujte tuto vlastnost příliš daleko v minulosti. Tím by se spustil materializovaný pohled s významnou prodlevou, což by mohlo být obtížné dohnat.

  V následujícím příkladu předpokládejme, že aktuální čas je 2020-01-01 03:00. Tabulka DeduplicatedTable je deduped tabulka .T Zahrnuje všechna historická data, odstraněná duplicitní data do 2020-01-01 00:00. Příkaz create používá DeduplicatedTable k obnovení materializovaného zobrazení pomocí rozsahů přesunutí. Příkaz create obsahuje také všechny záznamy, které T byly ingestovány od 2020-01-01.

  .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
  } 
  

Zrušení vytváření materializovaného zobrazení

Proces vytváření materializovaného zobrazení můžete zrušit při použití možnosti obnovení. Tato akce je užitečná, když vytváření trvá příliš dlouho a chcete ji zastavit, když je spuštěná.

Proces vytvoření nelze zrušit okamžitě. Zrušení příkazové signály materializace zastavit a vytvoření pravidelně kontroluje, zda bylo požadováno zrušení. Příkaz zrušit počká na maximálně 10 minut, dokud se nezruší proces vytvoření materializovaného zobrazení a pokud bylo zrušení úspěšné, vrátí se zpět.

I když zrušení nebude úspěšné během 10 minut a selhání příkazu zrušit, materializované zobrazení se pravděpodobně později v procesu vytváření zruší. Příkaz .show operations označuje, jestli byla operace zrušena.

Pokud už operace po vydání příkazu neprobíhá .cancel operation , příkaz ohlásí chybu.

Syntaxe

.cancel operationoperationId

Přečtěte si další informace o konvencích syntaxe.

Parametry

Výstup

Příklady

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e

Pokud se zrušení nedokončilo do 10 minut, CancellationState značí selhání. Vytvoření pak můžete zrušit.