Materializacja widoków metrycznych

Materializacja widoków metryk przyspiesza zapytania przy użyciu zmaterializowanych widoków do agregacji wstępnie obliczonych. Potoki Lakeflow koordynują zdefiniowane przez użytkownika widoki zmaterializowane dla danego widoku metryk. W czasie wykonywania zapytania optymalizator zapytań kieruje zapytania do najbardziej odpowiedniego widoku materializowanego, korzystając z automatycznego dopasowywania zapytań uwzględniającego agregację (przepisywania zapytań). Wysyłasz zapytanie do widoku metryki w zwykły sposób bez dodatkowego nakładu pracy ręcznej. Usługa Databricks odświeża materializacje, aby zapewnić ich aktualność. Wybiera również, której materializacji użyć do zapytań, aby przyspieszyć ich wykonywanie niższym kosztem.

Jak działa materializacja

Materializacja widoków metryk obejmuje dwie fazy: definiowanie materializacji i uruchamianie zapytań względem niego.

Faza definicji

Podczas definiowania widoku metryki z materializacją należy określić pola, miary i harmonogram odświeżania w widoku metryki YAML. Na podstawie tej definicji usługa Databricks tworzy zarządzany pipeline Lakeflow, który tworzy i utrzymuje widoki zmaterializowane.

Dzięki temu definicja metryki jest oddzielona od sposobu przechowywania:

• Widok metryki jest obiektem Unity Catalog, który definiuje pola, miary i połączenia metryki oraz konfigurację materializacji (harmonogram i stopień szczegółowości). Jest to jedno źródło prawdy dla tego, co oznacza metryka.
• Potok materializuje tę definicję do postaci jednego lub większej liczby widoków zmaterializowanych, z których każdy jest wstępnie obliczany z określoną granulacją. Usługa Databricks wybiera, który z nich ma być odczytywany w czasie wykonywania zapytań.

Wykonywanie zapytania

Po uruchomieniu SELECT ... FROM <metric_view> optymalizator zapytań używa przepisania zapytania z uwzględnieniem agregacji, aby zoptymalizować wydajność.

• Szybka ścieżka: odczytuje ze wstępnie obliczonych zmaterializowanych widoków, gdy istnieje odpowiedni materializacja.
• Ścieżka rezerwowa: odczytuje dane źródłowe bezpośrednio, gdy nie jest dostępna odpowiednia materializacja.

Optymalizator zapytań automatycznie równoważy wydajność i świeżość, wybierając między zmaterializowanymi i źródłowymi danymi. Wyniki są zwracane w sposób przejrzysty niezależnie od tego, której ścieżki używa optymalizator. Aby uzyskać więcej informacji na temat uruchamiania zapytań względem widoków metryk, zobacz Query metric views (Widoki metryk zapytań).

Wymagania

Aby użyć materializacji dla widoków metryk:

• Twój workspace musi mieć włączone obliczenia serwerowe, aby uruchomić potoki Lakeflow.
• Usługa SQL Warehouse lub zasób obliczeniowy z uruchomionym środowiskiem Databricks Runtime w wersji 17.3 lub nowszej. Obsługiwane są widoki metryczne bez materializacji, począwszy od Databricks Runtime 16.4. Aby sprawdzić minimalną wersję środowiska uruchomieniowego dla poszczególnych funkcji, zobacz Dostępność funkcji widoku metryk.

Important

Nie można zmaterializować widoku metryki, gdy widok lub którakolwiek z jego tabel źródłowych korzysta z zabezpieczeń na poziomie wiersza (RLS),masek kolumnowych lub polityk kontroli dostępu opartej na atrybutach (ABAC). Ponieważ materializacja jest wcześniej obliczana z użyciem tożsamości właściciela, udostępnienie jej innym użytkownikom omijałoby mechanizmy dostępu dla użytkownika, które te funkcje wymuszają w czasie zapytania. Szczegóły można znaleźć w Trybie przepisywania zapytań.

Dokumentacja konfiguracji

Materializację konfiguruje się w polu materialization na najwyższym poziomie w definicji YAML widoku metryk. To pole ustawia przepisanie zapytania mode (zawsze relaxed), opcjonalne odświeżanie schedule oraz listę materialized_views do utrzymania. Każdy zmaterializowany widok to aggregated, który wstępnie oblicza określone wymiary i miary, lub unaggregated, który materializuje pełny model danych.

Aby uzyskać pełną specyfikację każdego pola, w tym pola wymagane i opcjonalne, dozwolone wartości oraz ograniczenia klauzuli schedule, zobacz Materialization.

Przykładowa definicja

W poniższym przykładzie zdefiniowano widok metryk z jedną nieagregowaną i dwiema zagregowanymi materializacjami:

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

Note

Blok materialization używa słowa kluczowego dimensions: do wymienienia pól, które mają zostać zmaterializowane, mimo że definicja najwyższego poziomu używa słowa kluczowego fields:. Dwa słowa kluczowe są równoważne. Zobacz Pola.

Materializacja revenue_breakdown korzysta z cluster_by i partition_by do określania, jak zmaterializowane dane są fizycznie rozmieszczane, podobnie jak klauzule CLUSTER BY i PARTITION BY w widoku zmaterializowanym. Pełną specyfikację pola można znaleźć w Materialization.

Tworzenie widoku metryk przy użyciu języka SQL

Aby utworzyć ten widok metryki poza narzędziem Catalog Explorer, zawiń kod YAML w CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS i umieść definicję między ogranicznikami $$:

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Tryb ponownego zapisywania zapytań

W relaxed trybie automatyczne przepisywanie zapytań sprawdza tylko, czy kandydackie widoki zmaterializowane mają niezbędne pola i miary do obsługi zapytania.

Pominięto następujące kontrole:

• Świeżość: Nie sprawdza, czy materializacja jest aktualna.
• Ustawienia SQL: nie weryfikuje, czy ustawienia takie jak TIMEZONE lub ANSI_MODE są zgodne.
• Determinizm: Nie sprawdza, czy zmaterializowane wyniki są w pełni deterministyczne.

Zapytania pasujące do materializacji korzystają z ostatniego odświeżenia. Zapytania, które nie znajdują dopasowania, są kierowane do źródła i zwracają dane w czasie rzeczywistym. W związku z tym świeżość danych może się różnić w zależności od tego, czy zapytanie kwalifikuje się do ponownego zapisywania. Aby zweryfikować spójność, dostosuj harmonogram odświeżania materializacji do potoku źródłowego. Jeśli na przykład dane źródłowe są aktualizowane codziennie za pomocą potoku wsadowego, zaplanuj odświeżanie materializacji tak, aby uruchamiało się po zakończeniu tego potoku. Alternatywnie, użyj nieagregowanej materializacji, aby zagwarantować, że wszystkie zapytania odczytują dane z tej samej migawki.

Nie można utworzyć materializacji, gdy widok metryk lub którakolwiek z tabel źródłowych tego widoku korzysta z:

• Zabezpieczenia na poziomie wiersza (RLS),maskowanie na poziomie kolumny (CLM) lub zasady ABAC. Wstępnie obliczone wyniki mogą pomijać mechanizmy kontroli dostępu poszczególnych użytkowników, które mają być wymuszane w czasie wykonywania zapytań.
• Wyrażenia zależne od wywołania, których wynik zmienia się na podstawie tego, kto uruchamia zapytanie (na przykład current_user() lub is_member()). Materializacja jest obliczana z wyprzedzeniem tylko raz i współdzielona, więc udostępnienie jej innemu użytkownikowi zwróci niepoprawne lub niebezpieczne wyniki.

Usługa Databricks weryfikuje to ograniczenie podczas tworzenia, zmieniania lub odświeżania materializacji. Te operacje kończą się niepowodzeniem z warunkiem błędu METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E). Zobacz METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Typy materializacji dla widoków metrycznych

W poniższych sekcjach opisano typy zmaterializowanych widoków dostępnych dla widoków metryk i przedstawiono wskazówki dotyczące wybierania odpowiedniej konfiguracji dla źródeł danych i wzorców zapytań.

Typ zagregowany

Ten typ wstępnie oblicza agregacje dla określonej miary i kombinacji pól dla docelowego pokrycia.

Użyj typu zagregowanego, jeśli istnieją konkretne kombinacje wymiarów i miar, które są często używane w zapytaniach. W przypadku materializacji zagregowanych zastosowanie mają zarówno strategie dopasowania dokładnego, jak i dopasowania agregującego, zapewniając najlepszą wydajność zapytań dla tych wzorców.

Aby uzyskać optymalne agregacje:

• Uwzględnij najczęściej używane wymiary w GROUP BY klauzulach.
• Uwzględnij wszelkie potencjalne kolumny filtru (kolumny używane w WHERE czasie wykonywania zapytania).
• Zmaterializuj na najbardziej szczegółowym poziomie potrzebne zapytania. Na przykład materializacja w lokalizacji (region, sku, event_day) może obsłużyć wszystkie następujące elementy:
  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku Z WHERE region = 'US'
• Unikaj wymiarów o tak dużej szczegółowości, które powodują, że powstają głównie grupy składające się tylko z jednego wiersza (na przykład surowy znacznik czasu z dokładnością do milisekund). Nie przynosi to żadnych korzyści i zwiększa zużycie miejsca.
• Uważaj na miary nieaddytywne. Miary nieaddytywne nie mogą być agregowane ponownie na podstawie wyników częściowych (na przykład COUNT(DISTINCT), MEDIAN i percentyle) i wymagają dokładnego dopasowania do materializacji.

Pojedyncza agregacja może obsłużyć tylko zapytania, które odpowiadają jej konkretnym wymiarom (dokładne dopasowanie) lub podzbiorowi jej wymiarów (dopasowanie sumaryczne). Usługa Databricks zaleca tworzenie wielu zagregowanych materializacji dla różnych kształtów zapytań.

Typ nieagregowany

Ten typ materializuje cały nieagregowany model danych (pola source, joins, filter i fields), aby zapewnić szersze pokrycie przy mniejszym narzucie na wydajność w porównaniu z typem zagregowanym.

Użyj typu nieagregowanego, jeśli zachodzi którykolwiek z poniższych warunków:

• Widok metryk wymaga kosztownych przekształceń danych źródłowych lub złączeń.
• Wzorce zapytań są nieprzewidywalne lub zróżnicowane.
• Wszyscy użytkownicy, którzy wysyłają zapytania dotyczące widoku metryki, muszą widzieć spójność w danych.

W przypadku nieagregowanych materializacji kosztowne widoki źródłowe i złączenia są obliczane tylko raz podczas odświeżania, a nie przy każdym zapytaniu. Gdy istnieją zarówno zagregowane, jak i niezagregowane materializacje, usługa Databricks oblicza zagregowane materializacje na podstawie niezagregowanej materializacji. Zapewnia to spójny obraz i pozwala uniknąć zbędnego ponownego przeliczania źródła. Niezagregowane dopasowanie zawsze kwalifikuje się bez względu na strukturę zapytania, z zastrzeżeniem ograniczeń opisanych w trybie przekształcania zapytań.

Niezagregowana materializacja nie pomaga, gdy źródłem jest bezpośrednie odwołanie do tabeli bez selektywnego filtra. W takim przypadku nie ma korzyści z bezpośredniego wykonywania zapytań względem źródła.

Aby uzyskać dodatkowe wskazówki dotyczące sposobu i kiedy używać tych typów materializacji, zobacz Wybieranie typu materializacji dla widoków metryk.

Automatyczne zapisywanie zapytań

Gdy wysyłasz zapytanie do widoku metryk, mechanizm przekształcania zapytań automatycznie kieruje je do najlepszej dostępnej materializacji. Używa trzech strategii ponownego zapisywania zapytań: dokładne dopasowanie, dopasowanie zestawienia i dopasowanie nieagregowane.

Zapytanie jest uruchamiane automatycznie w przypadku najlepszej materializacji zamiast tabel bazowych przy użyciu tego algorytmu:

1. Najpierw optymalizator zapytań próbuje znaleźć dokładne dopasowanie.
2. Jeśli nie ma dokładnego dopasowania, optymalizator zapytań próbuje dopasowania zbiorczego.
3. Jeśli nie ma dopasowania agregacji Rollup, a istnieje niezagregowana materializacja, optymalizator zapytań próbuje znaleźć niezagregowane dopasowanie.
4. Jeśli nie ma dopasowania niezagregowanego, zapytanie odczytuje je bezpośrednio z tabel źródłowych.

W poniższych sekcjach opisano, jak działa każda strategia.

Note

Materializacje muszą się zakończyć, zanim ponowne przetwarzanie zapytań może zostać zastosowane.

Dokładne dopasowanie

Zapytanie dotyczy dokładnie tego, co zostało wcześniej obliczone w materializacji. Mechanizm przepisywania zapytań odczytuje zapisany wynik bez dodatkowego przetwarzania, co umożliwia szybkie uzyskanie wyników.

Aby spełnić warunki dokładnego dopasowania:

• Wyrażenia zapytania GROUP BY muszą dokładnie odpowiadać wymiarom materializacji.
• Miary zapytania muszą być podzbiorem miar materializacji.

Na przykład materializacja ma wymiary [region, order_date] i mierzy [total_revenue, order_count]. Zapytanie, które grupuje według region i order_date oraz żąda total_revenue, jest dokładnym dopasowaniem, ponieważ wymiary są takie same, a miara została wcześniej obliczona.

Dopasowanie zestawienia

Zapytanie pyta o podsumowanie na poziomie grubszym niż to, co zostało wstępnie obliczone. Optymalizator odczytuje wstępnie obliczony wynik i ponownie agreguje go do poziomu potrzeb zapytania.

Aby kwalifikować się do dopasowania zbiorczego:

• Grubsze ziarno: zapytanie grupuje według mniejszej liczby wymiarów lub mniej szczegółowej granularności czasu niż materializacja.
• Wszystkie miary są addytywne: każda miara, o którą pyta zapytanie, musi dać się poprawnie ponownie obliczyć przez połączenie wyników częściowych (na przykład SUMsuma SUMów lub MAXliczba MAXów). MEDIAN nie może zostać zagregowany, ponieważ opiera się na rozkładzie grup.
• Wszystkie uczestniczące filtry muszą być wyrażeniami deterministycznymi: jeśli zapytanie ma klauzulę WHERE , filtr musi zawsze wygenerować ten sam wynik dla tych samych danych wejściowych. Na przykład WHERE region = 'US' jest deterministyczny, ale wyrażenia takie jak rand() lub uuid() nie.

Dopasowanie agregacji nie ma zastosowania do miar nieaddytywnych, ponieważ nie można ich poprawnie ponownie agregować na podstawie wyników częściowych. Zobacz Miary addytywne.

Na przykład zapytanie używające tej samej materializacji z wymiarami [region, order_date] i miarami [total_revenue, order_count], które grupuje tylko według region i żąda total_revenue, jest dopasowaniem agregacji. Zapytanie wymaga mniejszej liczby wymiarów niż to, co zostało zmaterializowane, więc aparat zwija dzienne sumy na sumy na poziomie regionu.

Note

Dopasowanie agregacji nie jest dostępne, gdy widok metryk używa złączenia one_to_many. W takim przypadku każda materializacja ogranicza się wyłącznie do dokładnego dopasowania. Aby uzyskać szczegółowe informacje na temat sprzężeń jeden do wielu, zobacz sprzężenia jeden do wielu.

Miary addytywne

Miara jest addytywna, jeśli jej zagregowany wynik można poprawnie ponownie obliczyć poprzez ponowną agregację na podstawie istniejących zagregowanych materializacji. To jest kluczowy wymóg dotyczący dopasowywania agregacji.

Każda agregacja wykorzystująca DISTINCT (na przykład COUNT(DISTINCT), SUM(DISTINCT)) nie jest sumowalna i nie może być agregowana na wyższym poziomie.

Następujące funkcje są addytywne:

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

Dodatkowe ograniczenia dotyczą miar addytywnych:

• Definicja miary musi zawierać dokładnie jedną funkcję agregacji. Miara, której definicja łączy wiele agregacji (na przykład sum(cost) + min(revenue)), nie kwalifikuje się do użycia przy dopasowywaniu sum częściowych.
• Jeśli definicja miary zawiera klauzulę FILTER , musi być deterministyczna.
• Miara nie może być miarą okienkową (na przykład 7-dniową sumą kroczącą lub porównaniem rok do roku zdefiniowanym za pomocą bloku okna).

Poniższa tabela zawiera podsumowanie sposobu mapowania typowych wzorców miar w celu dopasowania typów:

Wzorzec miary	Typ dopasowania	Powód
Pojedyncza agregacja addytywna (SUM, COUNT, MIN, MAX)	Kwalifikujący się do aktualizacji zbiorczej	Można ponownie agregować na podstawie wyników częściowych
COUNT(DISTINCT) lub inna nieaddytywna agregacja	Dokładne dopasowanie tylko	Nie można ponownie agregować
Wiele agregacji w jednym wyrażeniu (SUM(x) + MIN(y))	Dokładne dopasowanie tylko	Nie można wyizolować pojedynczych agregatów dla rollupów
Addytywny agregat z deterministycznym FILTER	Kwalifikujący się do aktualizacji zbiorczej	Filtr jest deterministyczny, agregacja jest addytywna
Miara okna	Dokładne dopasowanie tylko	Ramka okienna zależy od dokładnego ziarna

Dopasowanie niezsumowane

Zapytanie nie odpowiada żadnej wcześniej obliczonej agregacji, ale kosztowne prace przygotowawcze (złączenia i filtrowanie) zostały już wykonane. Ponowne zapisywanie zapytań rozpoczyna się od przygotowanego zestawu danych nieagregowanej materializacji zamiast wracać do tabel źródłowych.

Jeśli istnieje nieagregowana materializacja, strategia ta zawsze może być użyta jako rozwiązanie awaryjne przed sięgnięciem do źródła. Dowolny kształt zapytania może go używać, z zastrzeżeniem ograniczeń opisanych w trybie ponownego zapisywania zapytań.

Na przykład Twoje zapytanie grupuje według category i żąda unique_customers, ale żadna zagregowana materializacja nie obejmuje tych pól i miar. Jednak istnieje niezagregowana materializacja, w której połączony, przefiltrowany zestaw danych jest już gotowy. Optymalizator zapytań odczytuje dane z tego przygotowanego zestawu danych i wykonuje na nich operację GROUP BY category, COUNT(DISTINCT customer_id) w momencie wykonywania zapytania, zamiast ponownie łączyć surowe tabele od zera.

Sprawdzanie, czy zapytanie używa zmaterializowanych widoków

Istnieją dwa sposoby sprawdzania, czy zapytanie korzysta z zmaterializowanego widoku:

• Uruchom EXPLAIN EXTENDED dla swojego zapytania, aby zobaczyć plan zapytania. Jeśli użyto materializacji, węzeł liścia zawiera __materialization_mat_<pipeline ID>___metric_view_mat_ i nazwę materializacji z pliku YAML.
• Przyjrzyj się profilowi zapytania, jak pokazano poniżej.

Cykl życia materializacji

W tej sekcji wyjaśniono, jak materializacje są tworzone, zarządzane i odświeżane w całym cyklu życia.

Tworzenie i modyfikowanie

Podczas tworzenia lub modyfikowania widoku metryki (przy użyciu CREATE, ALTERlub Eksploratora wykazu) definicja widoku metryki jest natychmiast aktualizowana. Widoki zmaterializowane są odświeżane asynchronicznie w tle przy użyciu zarządzanego potoku przetwarzania.

Aby zdefiniować nową materializację w edytorze Eksploratora katalogów:

1. Kliknij Materializations.
2. Kliknij pozycję Harmonogram , aby ustawić harmonogram. Możesz wybrać interwał lub ustawić uruchamianie materializacji na określoną godzinę.
3. Wybierz typ. W widoku metryki dozwolona jest tylko jedna nieagregowana materializacja. Aby uzyskać więcej informacji, zobacz Typy materializacji dla widoków metryk.
4. Użyj listy rozwijanej Pola , aby wybrać pola do uwzględnienia w materializacji.
5. Użyj listy rozwijanej Miary , aby wybrać miary do uwzględnienia.

Podczas tworzenia widoku metryk usługa Databricks tworzy potok Lakeflow i natychmiast planuje pierwszą aktualizację, jeśli określono widoki zmaterializowane. Widok miary pozostaje możliwy do wykonywania zapytań bez konieczności materializacji, poprzez wykonywanie zapytań na podstawie danych źródłowych.

Podczas modyfikowania widoku metryki usługa Databricks nie planuje nowych aktualizacji, chyba że po raz pierwszy włączysz materializację. Zmaterializowane widoki nie są używane do automatycznego ponownego zapisywania zapytań do momentu ukończenia następnej zaplanowanej aktualizacji.

Zmiana harmonogramu materializacji nie powoduje wyzwolenia odświeżania.

Bez harmonogramu potok danych wykonuje początkową aktualizację przy tworzeniu, ale kolejne odświeżenia trzeba uruchamiać ręcznie, w przeciwnym razie dane stają się nieaktualne. Usługa Databricks zaleca zawsze definiowanie harmonogramu, aby dane pozostały świeże, chyba że testujesz lub prototypujesz.

Zobacz Odświeżanie ręczne , aby uzyskać dokładnszą kontrolę nad zachowaniem odświeżania.

Zbadaj bazowy potok

Materializacja widoków metryk jest implementowana przy użyciu potoków Lakeflow. Dostęp do potoku można uzyskać na dwa sposoby:

• W Eksploratorze katalogu: karta Przegląd widoku wskaźnika zawiera bezpośredni link pod nagłówkiem Harmonogram odświeżania. Aby dowiedzieć się, jak uzyskać dostęp do Eksploratora wykazu, zobacz Co to jest Eksplorator wykazu?.
• Przy użyciu języka SQL: uruchom polecenie DESCRIBE EXTENDED. Sekcja Informacje o odświeżaniu zawiera link do potoku i bieżący stan odświeżania.

DESCRIBE EXTENDED my_metric_view;

Przykładowy wynik:

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Odświeżanie ręczne

Na stronie linku do potoku Lakeflow możesz ręcznie uruchomić aktualizację potoku, aby zaktualizować materializacje. Odświeżanie ręczne można również wyzwolić przy użyciu następującego polecenia SQL:

REFRESH MATERIALIZED VIEW <metric-view-name>

Przyrostowe odświeżanie

Zmaterializowane widoki używają odświeżania przyrostowego zawsze, gdy jest to możliwe, i mają takie same ograniczenia jak standardowe zmaterializowane widoki dotyczące źródeł danych i struktury planu.

Aby uzyskać szczegółowe informacje na temat wymagań wstępnych i ograniczeń, zobacz Odświeżanie przyrostowe dla zmaterializowanych widoków.

Billing

Odświeżanie zmaterializowanych widoków wiąże się z opłatami za korzystanie z Lakeflow pipelines. Aby sprawdzić zużycie DBU potoku, zobacz Jakie jest zużycie DBU potoku bezserwerowego?.

Znane ograniczenia

Następujące ograniczenia dotyczą materializacji widoków metryk:

• Nie można zmaterializować widoku metryki, który definiuje parametry.
• Po utworzeniu materializacji dla widoku metryki nie można zmienić właściciela.
• Databricks nie obsługuje własności grupowej zmaterializowanych widoków metrycznych.
• Tylko strategia dopasowania ścisłego jest dostępna dla widoków metryk ze sprzężeniami typu jeden-do-wielu.
• Materializacja schedule nie obsługuje klauzuli TRIGGER ON UPDATE.