.create materialized-view

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

Istnieją dwa możliwe sposoby utworzenia 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 zwraca 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 zapasowej.
• 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 zmaterializowanego widoku.

Uprawnienia

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

Składnia

.create[] [asyncifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon tableSourceTableName{Kwerendy}

Dowiedz się więcej o konwencjach składniowych.

Parametry

Nazwa	Typ	Wymagane	Opis
PropertyName, PropertyValue	string		Lista właściwości w postaci par nazwa i wartość 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 zostanie określona flaga ifnotexists , polecenie zostanie zignorowane. Nie zastosowano żadnych zmian, nawet jeśli nowa definicja nie jest zgodna z istniejącą definicją.
• Jeśli flaga ifnotexists nie zostanie określona, zostanie zwrócony 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.

Nazwa	Typ	Opis
wypełnienie wsteczne	bool	Czy utworzyć widok na podstawie wszystkich rekordów aktualnie w SourceTable programie (true), czy utworzyć go od teraz (false). Wartość domyślna to false. Aby uzyskać więcej informacji, zobacz Wypełnianie zmaterializowanego widoku.
effectiveDateTime	datetime	Istotne tylko wtedy, gdy używasz polecenia backfill. Jeśli jest ustawiona, wypełnianie tworzenia jest tworzone tylko przy użyciu rekordów pozyskanych po dacie/dacie/dacie. backfill należy również ustawić wartość true. 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 truena wartość , czas tworzenia zakresu jest przypisywany na podstawie klucza grupowania daty/godziny podczas procesu wypełniania. Aby uzyskać więcej informacji, zobacz Wypełnianie zmaterializowanego widoku.
lookback	timespan	Prawidłowe tylko dla arg_max//arg_mintake_any zmaterializowanych widoków. Ogranicza okres, w którym oczekiwane są duplikaty. Na przykład jeśli w widoku zostanie określone arg_max spojrzenie 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 Niepoprawne zdefiniowanie okresu wyszukiwania może prowadzić do duplikatów w zmaterializowanym widoku. Jeśli na przykład rekord dla określonego klucza zostanie pozyskany 10 godzin po pozyskaniu rekordu dla tego samego klucza, a funkcja wyszukiwania zostanie ustawiona 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	Określa, czy widok ma być automatycznie aktualizowany 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 jest ustawiona na truewartość , zmiany w tabeli źródłowej zostaną automatycznie odzwierciedlone w zmaterializowanym widoku.
dimensionTables	array	Argument dynamiczny, który zawiera tablicę tabel wymiarów w widoku. Zobacz Parametr zapytania.
folder	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 dodatek przestawny powoduje niedeterministyczny schemat.
• W przypadku używania arg_max(Timestamp, *) agregacji i wartości autoUpdateSchema 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 przy użyciu autoUpdateSchema opcji .
• Użycie autoUpdateSchema metody 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

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

Składnia:

.create[] [asyncifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon materialized-viewSourceMaterializedViewName{Kwerendy}

Parametry:

Nazwa	Typ	Wymagane	Opis
PropertyName, PropertyValue	string		Lista właściwości w postaci par nazwa i wartość 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, używając 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 za pomocą elementów 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 , przy użyciu funkcji wyszukiwania w ciągu 6 godzin. Rekordy zostaną zdeduplikowane 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 zagregowaną przez co najmniej jedną grupę według wyrażeń. Operator summarize musi zawsze być ostatnim operatorem w zapytaniu.

  Zmaterializowany widok, który zawiera 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 tego, że niektóre optymalizacje są istotne tylko dla tego rodzaju zmaterializowanych widoków. Nie mają zastosowania, gdy widok zawiera funkcje agregacji mieszanej (gdzie mieszane oznacza zarówno, jak arg_max//arg_mintake_any i 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ć wartości where Timestamp > ago(5d). Użyj zasad przechowywania w zmaterializowanym widoku, aby ograniczyć czas, który obejmuje widok.

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

• Agregacje złożone nie są obsługiwane w definicji zmaterializowanego widoku. Na przykład zamiast używania metody SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Idzdefiniuj 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. Uzyskiwanie dostępu do funkcji składowanej zamiast bezpośredniego uzyskiwania dostępu do zmaterializowanego widoku.

• Zapytania obejmujące wiele klastrów 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 dołączania do tabel wymiarów:

  • Rekordy w tabeli źródłowej widoku (tabeli faktów) są zmaterializowane tylko raz. Aktualizacje do 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 widoku.

    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 usunięty 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

Porady dotyczące wydajności

• Użyj klucza 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 grupowania daty/godziny nie spowoduje zmiany semantyki agregacji, zalecamy jej dodanie. 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 zdefiniować widok jako:

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  Porada

  Opóźnione dane w grupie daty/godziny według klucza mogą mieć negatywny wpływ na zmaterializowany widok wydajności. Załóżmy na przykład, że zmaterializowany widok używa bin(Timestamp, 1d) jako jednego z kluczy grupowania, a kilka wartości odstających w danych ma bardzo stare Timestamp wartości. Te wartości odstające mogą negatywnie wpłynąć na zmaterializowany widok.

  Zalecamy, aby w zmaterializowanym zapytaniu widoku odfiltrować rekordy odstające lub znormalizować te rekordy do bieżącego czasu.

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

• Dodawanie kolumn często używanych do filtrowania jako grupowanie według kluczy: zmaterializowane zapytania widoku są optymalizowane podczas filtrowania według jednego z zmaterializowanych kluczy widoku grupowania. Jeśli wiesz, że wzorzec zapytania często będzie filtrowany według kolumny, która jest niezmienna zgodnie z unikatową jednostką w zmaterializowanym widoku, uwzględnij go w zmaterializowanym widoku grupowania według kluczy.

  Na przykład zmaterializowany widok uwidacznia arg_maxResourceId wartość, która często będzie filtrowana według SubscriptionId. 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żywaj zasad aktualizacji, jeśli jest to odpowiednie: zmaterializowany widok może obejmować przekształcenia, normalizacje i wyszukiwania 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
  }
  

Porada

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 danych 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 klastra. Śledź postęp wypełniania przy użyciu .show operations polecenia .

Błędy przejściowe, które występują w ramach procesu wypełniania, 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, gdy liczba rekordów w tabeli źródłowej przekracza number-of-nodes X 200 million (czasami nawet mniej, w zależności od złożoności zapytania). Alternatywą jest opcja wypełniania przez zakresy 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 to 2 miliony na węzeł. Tę właściwość można zmienić domyślnie, 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 przekroczenia limitu czasu zapytania. Zwiększenie tej wartości może przyspieszyć tworzenie widoku, zakładając, że klaster może wykonać funkcję agregacji na więcej rekordów niż wartość domyślna.

• Concurrency: Operacje pozyskiwania, uruchomione w ramach procesu wypełniania, 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 klastra jest niski, ponieważ wzrost może znacząco wpłynąć na zużycie procesora CPU klastra.

Na przykład następujące polecenie wypełni zmaterializowany widok z 2020-01-01pliku . Maksymalna liczba rekordów w każdej operacji pozyskiwania wynosi 3 miliony. Polecenie wykona operacje pozyskiwania z współbieżnością elementu 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 grupy daty/godziny, proces wypełniania danych 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 były usuwane przed ostatnimi, ponieważ zasady przechowywania są oparte na czasie tworzenia zakresu. Właściwość jest obsługiwana updateExtentsCreationTime tylko wtedy, gdy widok zawiera klucz typu data/godzina grupowania według, który używa bin() funkcji. Na przykład następujące wypełnienie 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 przez przesunięcie zakresów wypełnia zmaterializowany widok na podstawie istniejącej tabeli, która niekoniecznie jest tabelą źródłową zmaterializowanego widoku. Wypełnienie można osiągnąć, przenosząc zakresy z określonej tabeli do podstawowej zmaterializowanej tabeli widoków. Ten proces oznacza, że:

• Dane w określonej tabeli powinny mieć taki sam schemat jak zmaterializowany schemat widoku.
• Rekordy w określonej tabeli są przenoszone do widoku tak, jak to jest. 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órym 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łnienia i 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 nad tabelą źródłową.

Przypadki zastosowań

Opcja wypełniania przez zakresy 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 opartego na tabeli źródłowej nie działa dobrze z powodu ograniczeń wymienionych wcześniej. W takim przypadku można zorganizować proces wypełniania do tabeli tymczasowej przy użyciu pozyskiwania z poleceń zapytań i jednego z zalecanych narzędzi orkiestracji. Gdy tabela tymczasowa zawiera wszystkie rekordy wypełnienia, 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 pozyskane T 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 (przeniesiono 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 przez zakresy przenoszenia. Użycie obu elementów source_ingestion_time_from 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. 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łnienie 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) i czasem utworzenia widoku. Nie ustawiaj tej właściwości zbyt daleko w przeszłości. To zaczęłoby zmaterializowany widok ze znaczącym opóźnieniem, które może być trudne do nadrobienia zaległości.

  W poniższym przykładzie załóżmy, że bieżący czas to 2020-01-01 03:00. Tabela DeduplicatedTable jest tabelą deduplikowaną .T Obejmuje wszystkie dane historyczne, deduplikowane do 2020-01-01 00:00. Polecenie create używa DeduplicatedTable 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 kopii zapasowej. Ta akcja jest przydatna, gdy tworzenie trwa zbyt długo i chcesz ją zatrzymać 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 anuluj sygnalizuje materializację, aby zatrzymać, a tworzenie okresowo sprawdza, czy zażądano anulowania. Polecenie anulowania czeka 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 anulowanie polecenia zgłosi niepowodzenie, zmaterializowany widok prawdopodobnie anuluje się w dalszej części procesu 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 błąd informujący o tym.

Składnia

.cancel operationoperationId

Dowiedz się więcej o konwencjach składniowych.

Parametry

Nazwa	Typ	Wymagane	Opis
operationId	guid	✔️	Identyfikator operacji zwrócony z .create async materialized-view polecenia .

Dane wyjściowe

Nazwa	Typ	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), (tworzenie widoku nie jest już uruchomione, Unknown ale nie zostało anulowane przez tę operację).
ReasonPhrase	string	Przyczyna niepowodzenia anulowania.

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.