Materializacja widoków metrycznych

W tym artykule wyjaśniono, jak używać materializacji widoków metryk w celu przyspieszenia wydajności zapytań.

Materializacja widoków metrycznych przyspiesza zapytania dzięki użyciu zmaterializowanych widoków. Potoki deklaratywne platformy Lakeflow organizuje zmaterializowane widoki zdefiniowane przez użytkownika dla danego widoku metryki. W czasie wykonywania zapytania optymalizator zapytań inteligentnie kieruje zapytania użytkowników w widoku metryki do najlepszego zmaterializowanego widoku przy użyciu automatycznego dopasowywania zapytań obsługujących agregację, znanego również jako ponowne zapisywanie zapytań.

Takie podejście zapewnia korzyści wynikające z obliczeń wstępnych i automatycznych aktualizacji przyrostowych, dlatego nie trzeba określać, która tabela agregacji lub zmaterializowany widok wysyła zapytania o różne cele wydajności i eliminuje konieczność zarządzania oddzielnymi potokami produkcyjnymi.

Przegląd

Na poniższym diagramie pokazano, jak widoki metryk obsługują definicję i wykonywanie zapytań:

Faza definicji

Podczas definiowania widoku metryki z materializacją CREATE METRIC VIEW lub ALTER METRIC VIEW określasz wymiary, miary i harmonogram odświeżania. Usługa Databricks tworzy zarządzany potok, który utrzymuje zmaterializowane widoki.

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, jeśli to stosowne.
• Ścieżka rezerwowa: Odczytuje dane źródłowe bezpośrednio, gdy materializacje są niedostępne.

Optymalizator zapytań automatycznie równoważy wydajność i świeżość, wybierając między zmaterializowanymi i źródłowymi danymi. Wyniki są wyświetlane w sposób niewidoczny niezależnie od tego, która ścieżka jest używana.

Requirements

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

• Obszar roboczy musi mieć włączone przetwarzanie bezserwerowe. To jest wymagane do uruchamiania deklaratywnych potoków Spark w ramach usługi Lakeflow.
• Databricks Runtime 17.2 lub nowsza wersja.

Dokumentacja konfiguracji

Wszystkie informacje związane z materializacją są definiowane w polu najwyższego poziomu o nazwie materialization w definicji YAML widoku metryki.

Pole materialization zawiera następujące wymagane pola:

• schedule: obsługuje tę samą składnię co klauzula schedule dla zmaterializowanych widoków.
• tryb: musi być ustawiony na relaxed.
• materialized_views: Lista widoków do zmaterializowania.
  • name: Nazwa materializacji.
  • Wymiary: lista wymiarów do materializowania. Dozwolone są tylko bezpośrednie odwołania do nazw wymiarów; Wyrażenia nie są obsługiwane.
  • miary: lista miar do materializowania. Dozwolone są tylko bezpośrednie odwołania do nazw miar; Wyrażenia nie są obsługiwane.
  • typ: określa, czy zmaterializowany widok jest agregowany, czy nie. Akceptuje dwie możliwe wartości: aggregated i unaggregated.
    • Jeśli type jest aggregated, musi istnieć co najmniej jeden wymiar lub miara.
    • Jeśli type to unaggregated, nie należy definiować miar ani wymiarów.

Przykładowa definicja

version: 0.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

Mode

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

Oznacza to, że pominięto kilka kontroli:

• Nie ma kontroli, czy zmaterializowany widok jest aktualny.
• Nie ma kontroli, czy masz pasujące ustawienia SQL (na przykład ANSI_MODE lub TIMEZONE).
• Nie ma kontroli, czy zmaterializowany widok zwraca wyniki deterministyczne.

Jeśli zapytanie zawiera którykolwiek z następujących warunków, ponowne zapisywanie zapytania nie występuje, a zapytanie wraca do tabel źródłowych:

• Zabezpieczenia na poziomie wiersza (RLS) lub maskowanie na poziomie kolumny (CLM) w zmaterializowanych widokach.
• Funkcje niedeterministyczne, takie jak current_timestamp() w zmaterializowanych widokach. Mogą one pojawić się w definicji widoku metryki lub w tabeli źródłowej używanej przez widok metryki.

Typy materializacji widoków metrycznych

W poniższych sekcjach opisano typy zmaterializowanych widoków dostępnych dla widoków metryk.

Typ zagregowany

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

Jest to przydatne w przypadku określania docelowych typowych wzorców zapytań agregacji lub widżetów. Usługa Databricks zaleca uwzględnienie potencjalnych kolumn filtru jako wymiarów w zmaterializowanej konfiguracji widoku. Potencjalne kolumny filtru są kolumnami używanymi w czasie zapytania w klauzuli WHERE .

Typ nieagregowany

Ten typ materializuje cały nieagregowany model danych (na przykład pola source, join i filter) w celu uzyskania szerszego zasięgu przy mniejszym wzroście wydajności w porównaniu z typem zagregowanym.

Użyj tego typu, jeśli są spełnione następujące warunki:

• Źródło jest kosztownym widokiem lub zapytaniem SQL.
• Połączenia zdefiniowane w widoku metryki są kosztowne.

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

Tworzenie lub modyfikowanie widoku metryki (przy użyciu CREATE, ALTERlub Eksploratora wykazu) odbywa się synchronicznie. Określone zmaterializowane widoki zmaterializują się asynchronicznie przy użyciu Deklaratywnych Potoków Lakeflow Spark.

Podczas tworzenia widoku metryki, usługa Databricks tworzy potok Deklaratywne Potoki Spark Lakeflow i natychmiast planuje początkową aktualizację, jeśli określono zmaterializowane widoki. 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 nie zaplanowano żadnych 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.

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 deklaratywnych potoków Lakeflow Spark. Link do pipeline'u znajduje się na karcie Przegląd w Eksploratorze katalogu. Aby dowiedzieć się, jak uzyskać dostęp do Eksploratora wykazu, zobacz Co to jest Eksplorator wykazu?.

Dostęp do tego potoku danych można również uzyskać, uruchamiając polecenie DESCRIBE EXTENDED w widoku metryki. Sekcja Odśwież informacje zawiera link do potoku.

DESCRIBE EXTENDED my_metric_view;

Przykładowy wynik:

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

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh information
         Latest Refresh status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 3 HOURS

Odświeżanie ręczne

Na stronie linku do strony Potoki deklaratywne platformy Spark w usłudze Lakeflow możesz ręcznie uruchomić aktualizację potoku, aby zaktualizować materializacje. Można to również koordynować przy użyciu wywołania API na podstawie identyfikatora potoku.

Na przykład następujący skrypt języka Python uruchamia odświeżanie potoku:

from databricks.sdk import WorkspaceClient

client = WorkspaceClient()
pipeline_id = "01484540-0a06-414a-b10f-e1b0e8097f15"
client.pipelines.start_update(pipeline_id)

Aby wykonać odświeżanie ręczne w ramach zadania lakeflow, utwórz skrypt języka Python z powyższą logiką i dodaj go jako zadanie typu Skrypt języka Python. Możesz też utworzyć notes z tą samą logiką i dodać zadanie typu Notes.

Odświeżanie przyrostowe

Zmaterializowane widoki używają odświeżania przyrostowego zawsze, gdy jest to możliwe, i mają te same ograniczenia 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.

Automatyczne zapisywanie zapytań

Zapytania do widoku metryki z materializacją próbują jak najwięcej wykorzystać jego materializacje. Istnieją dwie strategie ponownego zapisywania zapytań: dokładne dopasowanie i dopasowanie nieagregowane.

Podczas wykonywania zapytań względem widoku metryki optymalizator analizuje zapytanie i dostępne materializacje zdefiniowane przez użytkownika. Zapytanie jest uruchamiane automatycznie w przypadku najlepszej materializacji zamiast tabel bazowych przy użyciu tego algorytmu:

1. Pierwsze próby dokładnego dopasowania.
2. Jeśli istnieje nieagregowana materializacja, próbuje dopasowania nieagregowanego.
3. Jeśli ponowne zapisywanie zapytań zakończy się niepowodzeniem, zapytanie odczytuje się bezpośrednio z tabel źródłowych.

Zweryfikuj, czy zapytanie używa zmaterializowanych widoków

Aby sprawdzić, czy zapytanie korzysta z zmaterializowanego widoku, uruchom EXPLAIN EXTENDED na swoim zapytaniu, aby wyświetlić plan zapytania. Jeśli zapytanie korzysta z zmaterializowanych widoków, węzeł liścia zawiera __materialization_mat___metric_view oraz nazwę materializacji z pliku YAML.

Alternatywnie, profil zapytania pokazuje te same informacje.

Dokładne dopasowanie

Aby kwalifikować się do strategii dokładnego dopasowania, wyrażenia grupujące zapytania muszą dokładnie odpowiadać wymiarom materializacji. Wyrażenia agregacji zapytania muszą być podzbiorem miar materializacji.

Dopasowanie niezsumowane

Jeśli dostępna jest niezagregowana materializacja, ta strategia zawsze kwalifikuje się.

Fakturowanie

Odświeżanie zmaterializowanych widoków powoduje naliczanie opłat za użycie potoków deklaratywnych w usłudze Lakeflow Spark.

Znane ograniczenia

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

• Widok metryki z materializacją, który odnosi się do innego widoku metryki jako źródła, nie może mieć nieagregowanej materializacji.