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.

Operacje odświeżania są uruchamiane w obliczeniach bezserwerowych

Operacje odświeżania są uruchamiane w potokach bezserwerowych, niezależnie od tego, czy operacja została zdefiniowana w usłudze Databricks SQL czy w deklaratywnych potokach Lakeflow Spark.

W przypadku zmaterializowanych widoków zdefiniowanych przy użyciu usługi Databricks SQL obszar roboczy nie musi być włączony dla bezserwerowych potoków deklaratywnych platformy Spark w usłudze Lakeflow. Odświeżanie automatycznie użyje potoku bezserwerowego.

W przypadku zmaterializowanych widoków zdefiniowanych przy użyciu deklaratywnych potoków Lakeflow Spark, należy skonfigurować potok do pracy w trybie bezserwerowym. Zobacz Jak skonfigurować potok bezserwerowy.

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.

Note

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 transaction_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:

Important

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 AUTO CDC ... 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.
• Źródła danych z zdefiniowanymi filtrami wierszy lub maskami kolumn nie obsługują odświeżania przyrostowego. Zobacz Filtry wierszy i maski kolumn

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

Te funkcje można ustawić podczas tworzenia lub później za pomocą instrukcji ALTER TABLE . Przykład:

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Typy odświeżania zmaterializowanych widoków

Po zaktualizowaniu zmaterializowanego widoku można określić odświeżanie lub pełne odświeżenie.

• Odświeżenie próbuje wykonać odświeżanie przyrostowe, ale w razie potrzeby wykona pełną ponowną kompilację danych. Odświeżanie przyrostowe jest dostępne tylko wtedy, gdy połączone z nim obliczenia są bezserwerowe.
• Pełne odświeżanie zawsze ponownie oblicza wszystkie dane wejściowe do zmaterializowanego widoku i resetuje wszystkie punkty kontrolne.

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

Odświeżanie domyślne

Domyślne odświeżanie zmaterializowanego widoku w przypadku bezserwerowych prób wykonania odświeżania przyrostowego. 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. Jeśli odświeżanie przyrostowe nie jest możliwe lub połączone zasoby obliczeniowe są klasyczne zamiast bezserwerowe, wykonywana jest pełna ponowna kompilacja.

Dane wyjściowe odświeżania przyrostowego i pełne ponownej kompilacji są takie same. Usługa Azure Databricks uruchamia analizę kosztów, aby wybrać tańszą opcję między odświeżaniem przyrostowym a pełną ponowną kompilacją.

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 w pełni ponownie skompilowane.

pl-PL: Gdy tworzysz zmaterializowane widoki za pomocą SQL Warehouse lub deklaratywnych bezserwerowych potoków Spark w Azure Databricks, są one przyrostowo odświeżane, jeśli ich zapytania są obsługiwane. Jeśli zapytanie używa nieobsługiwanych wyrażeń, usługa Azure Databricks uruchamia zamiast tego pełną ponowną kompilację, co może zwiększyć koszty.

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żanie zastępuje wyniki w zmaterializowanym widoku przez wyczyszczenie tabeli i punktów kontrolnych oraz ponowne przetwarzanie wszystkich danych dostępnych w źródle.

Aby wykonać pełne odświeżanie w zmaterializowanych widokach 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 potokach deklaratywnych platformy Spark w usłudze Lakeflow można uruchomić pełne odświeżanie wybranych zestawów danych lub wszystkich zestawów danych w potoku. Zobacz semantykę odświeżania potoku .

Important

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. Może to również spowodować zmianę schematu kolumn, które już nie istnieją w danych źródłowych.

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.

Important

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	Yes
WITH	Tak, obsługiwane są typowe wyrażenia tabeli.
UNION ALL*	Yes
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*	Yes
LEFT OUTER JOIN*	Yes
FULL OUTER JOIN*	Yes
RIGHT OUTER JOIN*	Yes
OVER	Yes. PARTITION_BY kolumny muszą być określone dla przyrostowego przetwarzania w funkcjach okiennych.
QUALIFY	Yes
EXPECTATIONS	Tak, zmaterializowane widoki, które obejmują oczekiwania, mogą być odświeżane przyrostowo. Jednak odświeżanie przyrostowe nie jest obsługiwane w następujących przypadkach: Gdy zmaterializowany widok odczytuje z widoku zawierającego oczekiwania. Gdy zmaterializowany widok ma DROP oczekiwania i zawiera NOT NULL kolumny w jego schemacie.
Funkcje niedeterministyczne	Funkcje czasu niedeterministycznego są obsługiwane w WHERE klauzulach. Obejmuje to funkcje, takie jak current_date(), current_timestamp()i now(). Inne funkcje niedeterministyczne nie są obsługiwane.
Źródła nie-delta	Źródła, takie jak woluminy, lokalizacje zewnętrzne i katalogi obce, nie 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:

Technique	Odświeżanie przyrostowe?	Description
FULL_RECOMPUTE	No	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.
Dowolny z: ROW_BASED PARTITION_OVERWRITE WINDOW_FUNCTION APPEND_ONLY GROUP_AGGREGATE GENERIC_AGGREGATE	Yes	Zmaterializowany widok został odświeżony przyrostowo przy użyciu określonej techniki.

Aby określić użytą technikę, wykonaj zapytanie dotyczące dziennika zdarzeń platformy Lakeflow Spark Declarative Pipelines, 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.

Przykładowe dane wyjściowe dla tego polecenia:

• • sygnatura czasowa
  • komunikat
• • 2025-03-21T22:23:16.497+00:00
  • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Zobacz Dziennik zdarzeń rurociągu.