Odświeżanie przyrostowe dla widoków zmaterializowanych

W tym artykule opisano semantyka i wymagania dotyczące odświeżania przyrostowego w zmaterializowanych widokach oraz identyfikuje operacje SQL, słowa kluczowe i klauzule, które obsługują odświeżanie przyrostowe. Obejmuje on omówienie różnic między odświeżaniem przyrostowym i pełnym odświeżaniem, a także zalecenia dotyczące wybierania między zmaterializowanymi widokami i tabelami strumieniowymi.

Podczas uruchamiania aktualizacji na zmaterializowanych widokach przy użyciu potoków bezserwerowych wiele zapytań można odświeżać w sposób przyrostowy. Odświeżanie przyrostowe oszczędza koszty obliczeń, wykrywając zmiany w źródłach danych używanych do definiowania zmaterializowanego widoku i przyrostowego obliczania wyniku.

Odświeżanie przyrostowe wymaga rurek bezserwerowych

Odświeżanie przyrostowe dla zmaterializowanych widoków wymaga przepływów pracy bezserwerowych.

Operacje odświeżania dla zmaterializowanych widoków zdefiniowanych w usłudze Databricks SQL zawsze są uruchamiane przy użyciu potoków bezserwerowych.

W przypadku zmaterializowanych widoków zdefiniowanych przy użyciu potoków DLT należy skonfigurować pipeline do używania w trybie bezserwerowym. Zobacz , jak skonfigurować bezserwerowy potok DLT.

Jakie są semantyki odświeżania dla zmaterializowanych widoków?

Zmaterializowane widoki gwarantują równoważne wyniki zapytaniom wsadowym. Rozważmy na przykład następujące zagregowane zapytanie:

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Po uruchomieniu tego zapytania przy użyciu dowolnego produktu usługi Azure Databricks wynik jest obliczany przy użyciu semantyki wsadowej w celu agregowania wszystkich rekordów w źródle transactions_table, co oznacza, że wszystkie dane źródłowe są skanowane i agregowane w jednej operacji.

Uwaga

Niektóre produkty usługi Azure Databricks buforować wyniki automatycznie w ramach sesji lub między nimi, jeśli źródła danych nie uległy zmianie po uruchomieniu ostatniego zapytania. Automatyczny sposób buforowania różni się od zmaterializowanych widoków.

Poniższy przykład przekształca to zapytanie wsadowe w zmaterializowany widok:

CREATE OR REPLACE MATERIALIZED VIEW transation_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Podczas odświeżania zmaterializowanego widoku obliczony wynik jest identyczny do semantyki zapytań wsadowych. To zapytanie jest przykładem materializowanego widoku, który może być odświeżany przyrostowo. Oznacza to, że operacja odświeżania stara się przetwarzać jedynie nowe lub zmienione dane w źródle transactions_table, aby obliczyć wyniki.

Zagadnienia dotyczące źródła danych dla zmaterializowanych widoków

Chociaż można zdefiniować zmaterializowany widok dla dowolnego źródła danych, nie wszystkie źródła danych są dobrze dostosowane do zmaterializowanych widoków. Rozważ następujące zastrzeżenia i zalecenia:

Ważne

Zmaterializowane widoki dokładają najlepszych możliwych starań, aby przeprowadzać przyrostowe odświeżanie wyników obsługiwanych operacji. Niektóre zmiany w źródłach danych wymagają pełnego odświeżenia.

Wszystkie źródła danych dla zmaterializowanych widoków powinny być niezawodne dla semantyki pełnego odświeżania, nawet jeśli zapytanie definiujące zmaterializowany widok obsługuje odświeżanie przyrostowe.

• W przypadku zapytań, w których pełne odświeżanie byłoby zbyt kosztowne, użyj tabel strumieniowych, aby zagwarantować jednokrotne przetwarzanie. Przykłady obejmują bardzo duże tabele.
• Nie należy definiować zmaterializowanego widoku względem źródła danych, jeśli rekordy powinny być przetwarzane tylko raz. Zamiast tego należy użyć tabel przesyłania strumieniowego. Przykłady obejmują następujące elementy:
  • Źródła danych, które nie zachowują historii danych, takie jak Kafka.
  • Operacje pobierania, takie jak zapytania używające Auto Loader do wczytywania danych z pamięci masowej w chmurze.
  • Każde źródło danych, w którym planujesz usunąć lub zarchiwizować dane po przetworzeniu, ale musi zachować informacje w tabelach podrzędnych. Na przykład tabela podzielona na partycje dat, w której planujesz usunąć rekordy starsze niż określony próg.
• Nie wszystkie źródła danych obsługują odświeżanie przyrostowe. Następujące źródła danych obsługują odświeżanie przyrostowe:
  • Tabele Delta, w tym tabele zarządzane przez Unity Catalog oraz tabele zewnętrzne wspierane przez Delta Lake.
  • Zmaterializowane widoki.
  • Tabele przesyłania strumieniowego, w tym obiekty docelowe operacji APPLY CHANGES INTO.
• Niektóre operacje odświeżania przyrostowego wymagają włączenia śledzenia wierszy dla zapytanych źródeł danych. Śledzenie wierszy to funkcja Delta Lake obsługiwana wyłącznie przez tabele Delta, które obejmują zmaterializowane widoki, tabele strumieniowe oraz tabele zarządzane przez Unity Catalog. Zobacz Używanie śledzenia wierszy dla tabel delty.

Optymalizowanie zmaterializowanych widoków

Aby uzyskać najlepszą wydajność, usługa Databricks zaleca włączenie następujących funkcji we wszystkich zmaterializowanych tabelach źródłowych widoku:

• Wektory usuwania
  • Śledzenie wierszy
  • Zmienianie źródła danych

Typy odświeżania zmaterializowanych widoków

Proces odświeżania zmaterializowanych widoków może być pełny lub przyrostowy. W przypadku wszystkich operacji wyniki odświeżania przyrostowego i pełnego odświeżania są takie same. Usługa Azure Databricks uruchamia analizę kosztów w celu określenia, czy zmiany w źródłach danych wymagają pełnego odświeżenia.

Aby określić, jaki typ odświeżania został użyty w aktualizacji, zobacz Określanie typu odświeżania aktualizacji.

Pełne odświeżanie

Pełne odświeżenie zastępuje wyniki w zmaterializowanym widoku, ponownie przetwarzając wszystkie dane dostępne w źródle. Wszystkie zmaterializowane widoki mogą być w pełni odświeżane w każdej aktualizacji, w zależności od tego, jak źródła danych uległy zmianie.

Opcjonalnie możesz wymusić pełne odświeżenie. W przypadku zmaterializowanych widoków zdefiniowanych przy użyciu usługi Databricks SQL użyj następującej składni:

REFRESH MATERIALIZED VIEW mv_name FULL

W przypadku zmaterializowanych widoków zdefiniowanych w potoku DLT można uruchomić pełne odświeżanie dla wybranych zestawów danych lub wszystkich zestawów danych w potoku. Zobacz semantykę odświeżania potoku .

Ważne

Gdy pełne odświeżanie jest uruchamiane względem źródła danych, w którym rekordy zostały usunięte z powodu progu przechowywania danych lub ręcznego usuwania, usunięte rekordy nie są odzwierciedlane w obliczonych wynikach. Nie można odzyskać starych danych, jeśli dane nie są już dostępne w źródle.

Uwaga

Opcjonalnie można wyłączyć pełne odświeżanie w tabeli, ustawiając właściwość tabeli pipelines.reset.allowed na false.

Odświeżanie przyrostowe

Odświeżanie przyrostowe przetwarza zmiany w danych bazowych po ostatnim odświeżeniu, a następnie dołącza te dane do tabeli. W zależności od tabel podstawowych i uwzględnionych operacji tylko niektóre typy zmaterializowanych widoków mogą być odświeżane przyrostowo.

Tylko zmaterializowane widoki, które można aktualizować przy użyciu potoków bezserwerowych, mogą korzystać z odświeżania przyrostowego. Zmaterializowane widoki, które nie używają potoków bezserwerowych, są zawsze całkowicie odświeżane.

Kiedy zmaterializowane widoki są tworzone z wykorzystaniem SQL Warehouse lub bezserwerowego potoku DLT, są one automatycznie odświeżane przyrostowo, o ile ich zapytania są obsługiwane. Jeśli zapytanie zawiera nieobsługiwane wyrażenia dla odświeżania przyrostowego, wykonywane jest pełne odświeżanie, co może spowodować dodatkowe koszty.

Obsługa przyrostowego odświeżania zmaterializowanego widoku

W poniższej tabeli wymieniono obsługę odświeżania przyrostowego według słowa kluczowego LUB klauzuli SQL.

Ważne

Niektóre słowa kluczowe i klauzule wymagają włączenia śledzenia wierszy dla zapytanych źródeł danych. Zobacz Używanie śledzenia wierszy dla tabel delty.

Te słowa kluczowe i klauzule są oznaczone gwiazdką (*) w poniższej tabeli.

Słowo kluczowe lub klauzula SQL	Obsługa odświeżania przyrostowego
SELECT Wyrażenia*	Tak, obsługiwane są wyrażenia obejmujące wbudowane funkcje deterministyczne i niezmienne funkcje zdefiniowane przez użytkownika (UDF).
GROUP BY	Tak
WITH	Tak, obsługiwane są typowe wyrażenia tabeli.
UNION ALL*	Tak
FROM	Obsługiwane tabele podstawowe obejmują takie jak tabele Delta, widoki materializowane i tabele strumieniowe.
WHERE, HAVING*	Klauzule filtru, takie jak WHERE i HAVING , są obsługiwane.
INNER JOIN*	Tak
LEFT OUTER JOIN*	Tak
FULL OUTER JOIN*	Tak
RIGHT OUTER JOIN*	Tak
OVER	Tak. PARTITION_BY kolumny muszą być określone dla przyrostowego przetwarzania w funkcjach okiennych.
QUALIFY	Tak
EXPECTATIONS	Nie Zmaterializowane widoki, które wykorzystują strategie przewidywania, są zawsze w pełni odświeżane.

Uwaga

Funkcje niedeterministyczne, na przykład , CURRENT_TIMESTAMPnie są obsługiwane.

Określanie typu odświeżania aktualizacji

Aby zoptymalizować wydajność zmaterializowanych odświeżeń widoku, usługa Azure Databricks używa modelu kosztów do wybierania techniki używanej do odświeżania. W poniższej tabeli opisano następujące techniki:

Technika	Odświeżanie przyrostowe?	opis
FULL_RECOMPUTE	Nie.	Zmaterializowany widok został w pełni ponownie obliczony
NO_OP	Nie dotyczy	Zmaterializowany widok nie został zaktualizowany, ponieważ nie wykryto żadnych zmian w tabeli podstawowej.
ROW_BASED, PARTITION_OVERWRITE lub WINDOW_FUNCTION	Tak	Zmaterializowany widok został odświeżony przyrostowo przy użyciu określonej techniki.
APPEND_ONLY	Tak	Zmaterializowany widok został odświeżony przyrostowo, ponieważ jedynymi zmianami w danych wejściowych i zmaterializowanym widoku były dołączane dane.
GROUP_AGGREGATE lub GENERIC_AGGREGATE	Tak	Zmaterializowany widok został odświeżony przyrostowo przy użyciu funkcji agregującej.

Aby określić użytą technikę, wykonaj zapytanie w dzienniku zdarzeń DLT, w którym event_type jest planning_information:

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Zastąp <fully-qualified-table-name> kompletną i specyficzną nazwą zmaterializowanego widoku, w tym katalogiem i schematem.

Zobacz Co to jest dziennik zdarzeń DLT?.