.create materialized-view

Dotyczy: ✅Microsoft Fabric✅Azure Data Explorer

Zmaterializowany widok to zapytanie agregacji względem tabeli źródłowej. Reprezentuje pojedynczą instrukcję summarize .

Istnieją dwa możliwe sposoby tworzenia zmaterializowanego widoku, jak zauważyła opcja wypełniania w poleceniu:

Utwórz zmaterializowany widok od teraz:

• Zmaterializowany widok jest tworzony pusty. Zawiera tylko rekordy pozyskane po utworzeniu widoku. Utworzenie tego rodzaju jest zwracane natychmiast, a widok jest natychmiast dostępny dla zapytania.

Utwórz zmaterializowany widok na podstawie istniejących rekordów w tabeli źródłowej:

• Zobacz Wypełnianie zmaterializowanego widoku.
• Tworzenie może potrwać długo, w zależności od liczby rekordów w tabeli źródłowej. Widok nie będzie dostępny dla zapytań do momentu ukończenia wypełniania kopii zapasowych.
• Jeśli używasz tej opcji, polecenie create musi mieć wartość async. Wykonywanie można monitorować za pomocą .show operations polecenia .
• Proces wypełniania można anulować za pomocą .cancel operation polecenia .

Ważne

W dużych tabelach źródłowych opcja wypełniania może zająć dużo czasu. Jeśli ten proces przejściowo zakończy się niepowodzeniem podczas uruchamiania, nie zostanie on automatycznie ponowiony. Następnie należy ponownie wykonać polecenie create. Aby uzyskać więcej informacji, zobacz Wypełnianie wsteczne zmaterializowanego widoku.

Uprawnienia

To polecenie wymaga uprawnień administratora bazy danych. Twórca zmaterializowanego widoku staje się jego administratorem.

Składnia

.create[] [ifnotexists] materialized-view [ with (asyncPropertyName = PropertyValue,...] )Zmaterializowane zapytanie on table SourceTableName { }

Dowiedz się więcej na temat konwencji składni.

Parametry

Nazwisko	Type	Wymagania	opis
PropertyName, PropertyValue	string		Lista właściwości w postaci par nazw i wartości z listy obsługiwanych właściwości.
MaterializedViewName	string	✔️	Nazwa zmaterializowanego widoku. Nazwa widoku nie może powodować konfliktu z nazwami tabel lub funkcji w tej samej bazie danych i musi być zgodna z regułami nazewnictwa identyfikatorów.
SourceTableName	string	✔️	Nazwa tabeli źródłowej, w której zdefiniowano widok.
Zapytanie	string	✔️	Definicja zapytania zmaterializowanego widoku. Aby uzyskać więcej informacji i ograniczeń, zobacz sekcję Parametr zapytania.

Uwaga

Jeśli zmaterializowany widok już istnieje:

• Jeśli określono flagę ifnotexists , polecenie jest ignorowane. Nie zastosowano żadnych zmian, nawet jeśli nowa definicja nie jest zgodna z istniejącą definicją.
• Jeśli flaga ifnotexists nie jest określona, zwracany jest błąd.
• Aby zmienić istniejący zmaterializowany widok, użyj polecenia .alter materialized-view .

Obsługiwane właściwości

Następujące właściwości są obsługiwane w klauzuli with(PropertyName = PropertyValue). Wszystkie właściwości są opcjonalne.

Nazwisko	Pisz	Opis
wypełnienie wsteczne	bool	Czy utworzyć widok na podstawie wszystkich rekordów aktualnie w SourceTable (true) lub utworzyć go od teraz (false). Wartość domyślna to false. Aby uzyskać więcej informacji, zobacz Wypełnianie wsteczne zmaterializowanego widoku.
effectiveDateTime	datetime	Istotne tylko wtedy, gdy używasz polecenia backfill. Jeśli jest ustawiona, tworzenie wypełniania jest tworzone tylko z rekordami pozyskanymi po dacie/godziny. backfill musi być również ustawiona na truewartość . Ta właściwość oczekuje literału daty/godziny; na przykład effectiveDateTime=datetime(2019-05-01).
updateExtentsCreationTime	bool	Istotne tylko wtedy, gdy używasz polecenia backfill. Jeśli jest ustawiona na truewartość , czas tworzenia zakresu jest przypisywany na podstawie klucza grupowania daty/godziny w trakcie procesu wypełniania. Aby uzyskać więcej informacji, zobacz Wypełnianie wsteczne zmaterializowanego widoku.
lookback	timespan	Prawidłowe tylko dla arg_max//arg_mintake_any zmaterializowanych widoków. Ogranicza okres, w którym oczekiwane są duplikaty. Jeśli na przykład w widoku zostanie określone arg_max spojrzenie zwrotne z 6 godzin, deduplikacja między nowo pozyskanych rekordów a istniejącymi będzie uwzględniać tylko rekordy, które zostały pozyskane do 6 godzin temu. Funkcja Lookback jest względna względem ingestion_time(). Jeśli zmaterializowane zapytanie widoku nie zachowuje ingestion_time() wartości, nie można zdefiniować odnośnika w widoku. Zobacz zmaterializowane ograniczenia widoków i znane problemy. Niepoprawne zdefiniowanie okresu wyszukiwania może prowadzić do duplikatów w zmaterializowanym widoku. Jeśli na przykład rekord dla określonego klucza jest pozyskiwany 10 godzin po pozyskaniu rekordu dla tego samego klucza, a wyszukiwanie jest ustawione na 6 godzin, ten klucz będzie duplikatem w widoku. Okres wyszukiwania jest stosowany zarówno w czasie materializacji, jak i w czasie zapytania.
autoUpdateSchema	bool	Czy automatycznie zaktualizować widok w tabeli źródłowej. Wartość domyślna to false. Ta opcja jest prawidłowa tylko dla widoków typu arg_max(Timestamp, *)//arg_min(Timestamp, *)take_any(*) (tylko wtedy, gdy argument kolumny to ).* Jeśli ta opcja ma wartość true, zmiany w tabeli źródłowej zostaną automatycznie odzwierciedlone w zmaterializowanym widoku.
dimensionTables	tablica	Argument dynamiczny, który zawiera tablicę tabel wymiarów w widoku. Zobacz Parametr zapytania.
w folderze lokalnego systemu plików	string	Folder zmaterializowanego widoku.
docString	string	Ciąg, który dokumentuje zmaterializowany widok.
allowMaterializedViewsWithoutRowLevelSecurity	bool	Umożliwia utworzenie zmaterializowanego widoku w tabeli z włączonymi zasadami zabezpieczeń na poziomie wiersza.

Ostrzeżenie

• System automatycznie wyłączy zmaterializowany widok, jeśli zmiany w tabeli źródłowej zmaterializowanego widoku lub zmiany w danych prowadzą do niezgodności między zmaterializowanym zapytaniem widoku a oczekiwanym zmaterializowanym schematem widoku.
• Aby uniknąć tego błędu, zmaterializowane zapytanie widoku musi być deterministyczne. Na przykład wtyczka bag_unpack lub wtyczka przestawna powoduje niedeterministyczny schemat.
• W przypadku używania arg_max(Timestamp, *) agregacji i autoUpdateSchema wartości false zmiany w tabeli źródłowej mogą również prowadzić do niezgodności schematu. Unikaj tego błędu, definiując zapytanie widoku jako arg_max(Timestamp, Column1, Column2, ...), lub używając autoUpdateSchema opcji .
• Użycie autoUpdateSchema może prowadzić do nieodwracalnej utraty danych, gdy kolumny w tabeli źródłowej zostaną porzucone.
• Monitoruj automatyczne wyłączanie zmaterializowanych widoków przy użyciu metryki MaterializedViewResult.
• Po rozwiązaniu problemów z niezgodnością należy jawnie ponownie włączyć widok przy użyciu polecenia włącz zmaterializowany widok .

Tworzenie zmaterializowanego widoku w zmaterializowanym widoku

Można utworzyć zmaterializowany widok w innym zmaterializowanym widoku tylko wtedy, gdy zmaterializowany widok źródłowy jest take_any(*) agregacją (deduplikacja). Aby uzyskać więcej informacji, zobacz zmaterializowany widok w zmaterializowanym widoku i Przykłady.

Składnia:

.create[] [ifnotexists] materialized-view [ with (asyncPropertyName = PropertyValue,...] )MaterializedViewName SourceMaterializedViewName { Kwerenda on materialized-view }

Parametry:

Nazwisko	Type	Wymagania	opis
PropertyName, PropertyValue	string		Lista właściwości w postaci par nazw i wartości z listy obsługiwanych właściwości.
MaterializedViewName	string	✔️	Nazwa zmaterializowanego widoku. Nazwa widoku nie może powodować konfliktu z nazwami tabel lub funkcji w tej samej bazie danych i musi być zgodna z regułami nazewnictwa identyfikatorów.
SourceMaterializedViewName	string	✔️	Nazwa zmaterializowanego widoku źródłowego, w którym jest zdefiniowany widok.
Zapytanie	string	✔️	Definicja zapytania zmaterializowanego widoku.

Przykłady

• Utwórz pusty arg_max widok, który zmaterializuje tylko rekordy pozyskane od teraz:

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

• Utwórz zmaterializowany widok dla codziennych agregacji z opcją wypełniania wstecznego przy użyciu polecenia 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 
  } 
  

• Utwórz zmaterializowany widok z elementami backfill i effectiveDateTime. Widok jest tworzony na podstawie rekordów tylko z daty/godziny.

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

• Utwórz zmaterializowany widok, który deduplikuje tabelę źródłową w oparciu o kolumnę EventId , używając odnośnika 6 godzin. Rekordy będą deduplikowane tylko względem rekordów pozyskanych 6 godzin przed bieżącymi rekordami.

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

• Utwórz zmaterializowany widok downsampling oparty na poprzednim DeduplicatedTable zmaterializowanym widoku:

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

• Definicja może zawierać dodatkowe operatory przed instrukcją summarize , o ile summarize jest to ostatnia:

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

• Poniżej przedstawiono zmaterializowane widoki, które łączą się z tabelą wymiarów:

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

Uwagi

Parametr zapytania

Następujące reguły ograniczają zapytanie używane w zmaterializowanym widoku Parametr zapytania:

• Zapytanie powinno odwoływać się do pojedynczej tabeli faktów, która jest źródłem zmaterializowanego widoku. Powinien on zawierać jeden summarize operator i co najmniej jedną funkcję agregacji agregowaną przez co najmniej jedną grupę według wyrażeń. Operator summarize musi zawsze być ostatnim operatorem w zapytaniu.

  Zmaterializowany widok zawierający tylko jedną arg_maxarg_mintake_any//agregację może działać lepiej niż zmaterializowany widok, który obejmuje te agregacje wraz z innymi agregacjami (takimi jak ).count/dcount/avg Wynika to z faktu, że niektóre optymalizacje mają zastosowanie tylko do tego rodzaju zmaterializowanych widoków. Nie mają zastosowania, gdy widok zawiera mieszane funkcje agregacji (gdzie mieszane oznacza zarówno, jak arg_max/take_any/arg_mini inne agregacje w tym samym widoku).

• Zapytanie nie powinno zawierać żadnych operatorów, które zależą od now(). Na przykład zapytanie nie powinno mieć where Timestamp > ago(5d)wartości . Użyj zasad przechowywania w zmaterializowanym widoku, aby ograniczyć czas, przez który widok obejmuje.

• Następujące operatory nie są obsługiwane w zmaterializowanym zapytaniu widoku: sort, , top-nestedtop, partitionserialize.

• Agregacje złożone nie są obsługiwane w definicji zmaterializowanego widoku. Na przykład zamiast używać SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Idmetody , zdefiniuj zmaterializowany widok jako: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. W czasie wyświetlania zapytania uruchom polecenie MaterializedViewName | project Id, Result=a/b. Wymagane dane wyjściowe widoku, w tym kolumna obliczeniowa (a/b), można hermetyzować w funkcji składowanej. Uzyskaj dostęp do funkcji składowanej zamiast bezpośrednio uzyskiwać dostęp do zmaterializowanego widoku.

• Zapytania obejmujące wiele centrów zdarzeń i między bazami danych nie są obsługiwane.

• Odwołania do external_table() i danych zewnętrznych nie są obsługiwane.

• Zmaterializowane zapytanie widoku nie może zawierać żadnych objaśnień, które wymagają personifikacji. W szczególności wszystkie wtyczki łączności zapytań używające personifikacji nie są dozwolone.

• Oprócz tabeli źródłowej widoku zapytanie może odwoływać się do co najmniej jednej tabeli wymiarów. Tabele wymiarów muszą być jawnie wywoływane we właściwościach widoku. Ważne jest, aby zrozumieć następujące zachowanie podczas łączenia się z tabelami wymiarów:

  • Rekordy w tabeli źródłowej widoku (tabeli faktów) są zmaterializowane tylko raz. Aktualizacje tabel wymiarów nie mają żadnego wpływu na rekordy, które zostały już przetworzone z tabeli faktów.

  • Inne opóźnienie pozyskiwania między tabelą faktów a tabelą wymiarów może mieć wpływ na wyniki wyświetlania.

    Przykład: definicja widoku zawiera sprzężenie wewnętrzne z tabelą wymiarów. W czasie materializacji rekord wymiaru nie został w pełni pozyskany, ale został już pozyskany do tabeli faktów. Ten rekord zostanie porzucony z widoku i nigdy nie zostanie przetworzony ponownie.

    Podobnie, jeśli sprzężenie jest sprzężenie zewnętrzne, rekord z tabeli faktów zostanie przetworzony i dodany do widoku z wartością null dla kolumn tabeli wymiarów. Rekordy, które zostały już dodane (z wartościami null) do widoku, nie zostaną ponownie przetworzone. Ich wartości w kolumnach z tabeli wymiarów pozostaną zerowe.

Obsługiwane funkcje agregacji

Obsługiwane są następujące funkcje agregacji:

• 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

Wskazówki dotyczące wydajności

• Użyj klucza typu data/godzina grupowania według: zmaterializowane widoki, które mają kolumnę data/godzina jako jeden z kluczy grupowania według, są bardziej wydajne niż te, które nie. Przyczyną jest to, że niektóre optymalizacje można zastosować tylko wtedy, gdy istnieje klucz grupowania daty/godziny. Jeśli dodanie klucza typu data/godzina nie spowoduje zmiany semantyki agregacji, zalecamy dodanie go. Można to zrobić tylko wtedy, gdy kolumna datetime jest niezmienna dla każdej unikatowej jednostki.

  Na przykład w następującej agregacji:

      SourceTable | summarize take_any(*) by EventId
  

  Jeśli EventId zawsze ma tę samą Timestamp wartość i dlatego dodanie Timestamp nie zmienia semantyki agregacji, lepiej jest zdefiniować widok jako:

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  Napiwek

  Późne przybycie danych w kluczu typu data/godzina według grupy może mieć negatywny wpływ na wydajność zmaterializowanego widoku. Załóżmy na przykład, że zmaterializowany widok używa bin(Timestamp, 1d) jako jednego z kluczy grupowania, a nowo pozyskane rekordy do tabeli źródłowej mają stare Timestamp wartości. Te rekordy mogą negatywnie wpłynąć na zmaterializowany widok.

  Jeśli spodziewasz się późnych przychodzących rekordów pozyskanych do tabeli źródłowej, odpowiednio dostosuj zasady buforowania zmaterializowanego widoku. Jeśli na przykład rekordy ze znacznikiem czasu sześciu miesięcy temu mają zostać pozyskane do tabeli źródłowej, proces materializacji będzie musiał zeskanować zmaterializowany widok w ciągu ostatnich sześciu miesięcy. Jeśli ten okres znajduje się w zimnej pamięci podręcznej, materializacja będzie doświadczać chybienia pamięci podręcznej, co będzie miało negatywny wpływ na wydajność widoku.

  Jeśli takie późne przychodzące rekordy nie są oczekiwane, zalecamy, aby w zmaterializowanym zapytaniu widoku odfiltrować te rekordy lub znormalizować ich wartości sygnatury czasowej do bieżącej godziny.

• Definiowanie okresu wyszukiwania: jeśli ma zastosowanie do danego scenariusza, dodanie lookback właściwości może znacznie poprawić wydajność zapytań. Aby uzyskać szczegółowe informacje, zobacz Obsługiwane właściwości.

• Dodaj kolumny często używane do filtrowania jako klucze grupowania: zmaterializowane zapytania widoku są optymalizowane podczas filtrowania według jednego z zmaterializowanych kluczy widoku według grupy. Jeśli wiesz, że wzorzec zapytania często filtruje według kolumny niezmiennej zgodnie z unikatową jednostką w zmaterializowanym widoku, uwzględnij go w zmaterializowanym widoku według kluczy.

  Na przykład zmaterializowany widok uwidacznia arg_max ResourceId wartość, która często będzie filtrowana według SubscriptionIdwartości . Zakładając, że ResourceId wartość zawsze należy do tej samej SubscriptionId wartości, zdefiniuj zmaterializowane zapytanie widoku jako:

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

  Poprzednia definicja jest preferowana w następujących kwestiach:

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

• Użyj zasad aktualizacji, jeśli jest to odpowiednie: zmaterializowany widok może obejmować przekształcenia, normalizacje i odnośniki w tabelach wymiarów. Zalecamy jednak przeniesienie tych operacji do zasad aktualizacji. Pozostaw tylko agregację dla zmaterializowanego widoku.

  Na przykład lepiej jest zdefiniować następujące zasady aktualizacji:

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

  Zdefiniuj następujący zmaterializowany widok:

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

  Alternatywa obejmująca zasady aktualizacji w ramach zmaterializowanego zapytania widoku może działać gorzej i dlatego nie jest zalecana:

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

Napiwek

Jeśli potrzebujesz najlepszej wydajności czasu zapytań, ale możesz tolerować pewne opóźnienia danych, użyj funkcji materialized_view().

Wypełnianie zmaterializowanego widoku

Podczas tworzenia zmaterializowanego widoku przy użyciu backfill właściwości zmaterializowany widok zostanie utworzony na podstawie rekordów dostępnych w tabeli źródłowej. Lub zostanie utworzony na podstawie podzestawu tych rekordów, jeśli używasz polecenia effectiveDateTime.

W tle proces wypełniania kopii zapasowych dzieli dane na wiele partii i wykonuje kilka operacji pozyskiwania w celu wypełnienia widoku. Proces może potrwać długo, gdy liczba rekordów w tabeli źródłowej jest duża. Czas trwania procesu zależy od rozmiaru bazy danych. Śledzenie postępu wypełniania kopii zapasowych przy użyciu .show operations polecenia .

Błędy przejściowe, które występują w ramach procesu wypełniania kopii zapasowych, są ponawiane. Jeśli wszystkie ponawianie prób zostanie wyczerpane, polecenie zakończy się niepowodzeniem i będzie wymagać ręcznego ponownego wykonania polecenia create.

Nie zalecamy używania wypełniania w przypadku przekroczenia number-of-nodes X 200 million liczby rekordów w tabeli źródłowej (czasami nawet mniej w zależności od złożoności zapytania). Alternatywą jest opcja wypełniania kopii zapasowych według zakresów przenoszenia.

Użycie opcji wypełniania nie jest obsługiwane w przypadku danych w zimnej pamięci podręcznej. W razie potrzeby zwiększ okres gorącej pamięci podręcznej na czas tworzenia widoku. Może to wymagać skalowania w poziomie.

Jeśli wystąpią błędy podczas tworzenia widoku, spróbuj zmienić następujące właściwości:

• MaxSourceRecordsForSingleIngest: Domyślnie liczba rekordów źródłowych w każdej operacji pozyskiwania podczas wypełniania kopii zapasowej wynosi 2 miliony na węzeł. Tę wartość domyślną można zmienić, ustawiając tę właściwość na żądaną liczbę rekordów. (Wartość jest całkowitą liczbą rekordów w każdej operacji pozyskiwania).

  Zmniejszenie tej wartości może być przydatne, gdy tworzenie kończy się niepowodzeniem w przypadku limitów pamięci lub limitów czasu zapytania. Zwiększenie tej wartości może przyspieszyć tworzenie widoku, zakładając, że baza danych może wykonać funkcję agregacji na więcej rekordów niż wartość domyślna.

• Concurrency: Operacje pozyskiwania uruchomione w ramach procesu wypełniania kopii zapasowych są uruchamiane współbieżnie. Domyślnie współbieżność to min(number_of_nodes * 2, 5). Tę właściwość można ustawić, aby zwiększyć lub zmniejszyć współbieżność. Zalecamy zwiększenie tej wartości tylko wtedy, gdy procesor CPU bazy danych jest niski, ponieważ wzrost może znacząco wpłynąć na użycie procesora CPU bazy danych.

Na przykład następujące polecenie spowoduje wypełnienie zmaterializowanego widoku z pliku 2020-01-01. Maksymalna liczba rekordów w każdej operacji pozyskiwania wynosi 3 miliony. Polecenie wykona operacje pozyskiwania z współbieżnością .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)
} 

Jeśli zmaterializowany widok zawiera klucz grupowania daty/godziny, proces wypełniania wstecznego obsługuje zastępowanie czasu tworzenia zakresu na podstawie kolumny datetime. Może to być przydatne, na przykład jeśli chcesz, aby starsze rekordy zostały porzucone przed ostatnimi rekordami, ponieważ zasady przechowywania są oparte na czasie tworzenia zakresu. Właściwość jest obsługiwana updateExtentsCreationTime tylko wtedy, gdy widok zawiera klucz grupowania daty/godziny, który używa bin() funkcji. Na przykład następujące wypełnianie danych spowoduje przypisanie czasu utworzenia na podstawie klucza grupowania Timestamp :

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

Wypełnianie według zakresów przenoszenia

Opcja wypełniania kopii zapasowych przez zakresy przenoszenia wypełnia zmaterializowany widok na podstawie istniejącej tabeli, która nie musi być tabelą źródłową zmaterializowanego widoku. Wypełnienie można osiągnąć, przenosząc zakresy z określonej tabeli do bazowej zmaterializowanej tabeli widoków. Ten proces oznacza, że:

• Dane w określonej tabeli powinny mieć ten sam schemat co zmaterializowany schemat widoku.
• Rekordy w określonej tabeli są przenoszone do widoku w następujący sposób. Zakłada się, że są one deduplikowane na podstawie definicji zmaterializowanego widoku.

Jeśli na przykład zmaterializowany widok ma następującą agregację:

T | summarize arg_max(Timestamp, *) by EventId

Następnie rekordy w tabeli źródłowej dla operacji przenoszenia zakresów powinny być już zdeduplikowane przez EventID.

Ponieważ operacja używa zakresów przenoszenia, rekordy zostaną usunięte z określonej tabeli podczas wypełniania (przeniesione, nie skopiowane).

Wypełnianie według zakresów przenoszenia nie jest obsługiwane dla wszystkich funkcji agregacji obsługiwanych w zmaterializowanych widokach. Nie powiedzie się w przypadku agregacji, takich jak avg(), dcount(), w których bazowe dane przechowywane w widoku różnią się od samej agregacji.

Zmaterializowany widok jest wypełniany tylko na podstawie określonej tabeli. Materializacja rekordów w tabeli źródłowej widoku domyślnie rozpocznie się od czasu utworzenia widoku.

Jeśli tabela źródłowa zmaterializowanego widoku stale pozyskiwa dane, utworzenie widoku przy użyciu zakresów przenoszenia może spowodować utratę danych. Wynika to z faktu, że rekordy pozyskane do tabeli źródłowej w krótkim czasie między przygotowaniem tabeli do wypełniania kopii zapasowych a czasem utworzenia widoku nie zostaną uwzględnione w zmaterializowanym widoku. Aby obsłużyć ten scenariusz, można ustawić source_ingestion_time_from właściwość na godzinę rozpoczęcia zmaterializowanego widoku w tabeli źródłowej.

Przypadki użycia

Opcja wypełniania kopii zapasowych według zakresów przenoszenia może być przydatna w dwóch głównych scenariuszach:

• Jeśli masz już tabelę zawierającą deduplikowane dane źródłowe dla zmaterializowanego widoku i nie potrzebujesz tych rekordów w tej tabeli po utworzeniu widoku, ponieważ używasz tylko zmaterializowanego widoku.

• Gdy tabela źródłowa zmaterializowanego widoku jest bardzo duża, a wypełnianie widoku na podstawie tabeli źródłowej nie działa dobrze z powodu ograniczeń wymienionych wcześniej. W takim przypadku możesz samodzielnie zorganizować proces wypełniania danych w tabeli tymczasowej przy użyciu pozyskiwania z poleceń zapytania. Gdy tabela tymczasowa zawiera wszystkie rekordy wypełniania, utwórz zmaterializowany widok na podstawie tej tabeli.

Przykłady:

• W poniższym przykładzie tabela DeduplicatedTable zawiera pojedynczy rekord na EventId wystąpienie i będzie używana jako punkt odniesienia dla zmaterializowanego widoku. Tylko rekordy, które T są pozyskiwane po czasie tworzenia widoku, zostaną uwzględnione w zmaterializowanym widoku.

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

• effectiveDateTime Jeśli właściwość jest określona wraz z właściwościąmove_extents_from, tylko zakresy, w DeduplicatedTable których MaxCreatedOn wartość jest większa niż effectiveDateTime są uwzględnione w wypełnianiu wstecznym (przeniesione do zmaterializowanego widoku):

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

• W poniższym przykładzie pokazano użycie source_ingestion_time_from właściwości w opcji wypełniania kopii zapasowych przez zakresy przenoszenia. Przy użyciu obu source_ingestion_time_from elementów i move_extents_from wskazuje, że zmaterializowany widok jest wypełniany z dwóch źródeł:

  • Tabelamove_extents_from: DeduplicatedTable w poniższym przykładzie. Ta tabela powinna zawierać wszystkie dane historyczne do wypełniania kopii zapasowych. Opcjonalnie można użyć effectiveDateTime właściwości , aby uwzględnić tylko zakresy, w DeduplicatedTable których MaxCreatedOn wartość jest większa niż effectiveDateTime.

  • Tabela źródłowa zmaterializowanego widoku: T w poniższym przykładzie. Wypełnianie z tej tabeli zawiera tylko rekordy, których wartość ingestion_time() jest większa niż source_ingestion_time_from.

    Właściwość source_ingestion_time_from powinna być używana tylko do obsługi możliwej utraty danych w krótkim czasie między przygotowaniem tabeli do wypełnienia z (DeduplicatedTable) a czasem utworzenia widoku. Nie ustawiaj tej właściwości zbyt daleko w przeszłości. To spowodowałoby zmaterializowany pogląd ze znaczącym opóźnieniem, które może być trudne do nadrobienia zaległości.

  W poniższym przykładzie przyjęto założenie, że bieżąca godzina to 2020-01-01 03:00. Tabela DeduplicatedTable jest tabelą z deduplikowaną tabelą .T Obejmuje wszystkie dane historyczne, deduplikowane do 2020-01-01 00:00. Polecenie create używa DeduplicatedTable funkcji do wypełniania zmaterializowanego widoku przy użyciu zakresów przenoszenia. Polecenie create zawiera również wszystkie rekordy, które T zostały pozyskane 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
  } 
  

Anulowanie zmaterializowanego tworzenia widoku

Proces tworzenia zmaterializowanego widoku można anulować, gdy używasz opcji wypełniania wstecznego. Ta akcja jest przydatna, gdy tworzenie trwa zbyt długo i chcesz zatrzymać ją podczas jej działania.

Ostrzeżenie

Nie można przywrócić zmaterializowanego widoku po uruchomieniu tego polecenia.

Nie można natychmiast anulować procesu tworzenia. Polecenie cancel sygnalizuje materializację, aby zatrzymać, a tworzenie okresowo sprawdza, czy zażądano anulowania. Polecenie anulowania czeka przez maksymalnie 10 minut, aż zmaterializowany proces tworzenia widoku zostanie anulowany, i zgłasza z powrotem, jeśli anulowanie zakończyło się pomyślnie.

Nawet jeśli anulowanie nie powiedzie się w ciągu 10 minut, a niepowodzenie anulowania raportów poleceń, zmaterializowany widok prawdopodobnie anuluje się później w procesie tworzenia. Polecenie .show operations wskazuje, czy operacja została anulowana.

Jeśli operacja nie jest już w toku po wydaniu .cancel operation polecenia, polecenie zgłosi komunikat o błędzie.

Składnia

.cancel operationoperationId

Dowiedz się więcej na temat konwencji składni.

Parametry

Nazwisko	Type	Wymagania	opis
operationId	guid	✔️	Identyfikator operacji zwrócony z .create async materialized-view polecenia .

Dane wyjściowe

Nazwa/nazwisko	Pisz	Opis
Identyfikator operacji	guid	Identyfikator .create materialized-view operacji polecenia.
Operacja	string	Typ operacji.
Rozpoczęto	datetime	Godzina rozpoczęcia operacji tworzenia.
CancellationState	string	Jeden z: Canceled successfully (tworzenie zostało anulowane), Cancellation failed (poczekaj na przekroczenie limitu czasu anulowania) Unknown (tworzenie widoku nie jest już uruchomione, ale nie zostało anulowane przez tę operację).
ReasonPhrase	string	Powód, dla którego anulowanie nie powiodło się.

Przykłady

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

Identyfikator operacji	Operacja	Rozpoczęto	CancellationState	ReasonPhrase
c4b29441-4873-4e36-8310-c631c35c916e	MaterializedViewCreateOrAlter	2020-05-08 19:45:03.9184142	Canceled successfully

Jeśli anulowanie nie zostało zakończone w ciągu 10 minut, CancellationState oznacza to niepowodzenie. Następnie można anulować tworzenie.