Odświeżanie przyrostowe dla zmaterializowanych widoków
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łnymi operacjami odświeżania, a także zalecenia dotyczące wybierania między zmaterializowanymi widokami i tabelami przesyłania strumieniowego.
Podczas uruchamiania aktualizacji w zmaterializowanych widokach przy użyciu potoków bezserwerowych można odświeżać przyrostowo wiele zapytań. 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.
Potoki bezserwerowe są wymagane do odświeżania przyrostowego
Odświeżanie przyrostowe dla zmaterializowanych widoków wymaga potoków 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 delta Live Tables należy skonfigurować potok do używania bezserwerowego. Zobacz Konfigurowanie potoku bezserwerowych tabel różnicowych na żywo.
Jakie są semantyka 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. Automatyczne zachowania buforowania różnią się od zmaterializowanych widoków.
Poniższy przykład przekształca to zapytanie wsadowe w zmaterializowany widok:
CREATE OR REFRESH 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 z semantykami zapytań wsadowych. To zapytanie jest przykładem zmaterializowanego widoku, który może być odświeżany przyrostowo, co oznacza, że operacja odświeżania sprawia, że najlepszym wysiłkiem jest próba przetworzenia tylko nowych lub zmienionych danych w źródle transactions_table w celu obliczenia wyników.
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 ułatwiają próbę przyrostowego odświeżania 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 kosztowne, użyj tabel przesyłania strumieniowego, aby zagwarantować przetwarzanie dokładnie jednokrotne. 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 pozyskiwania, takie jak zapytania używające automatycznego modułu ładującego do pozyskiwania danych z magazynu obiektów 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 różnicowe, w tym tabele zarządzane przez wykaz aparatu Unity i tabele zewnętrzne wspierane przez usługę Delta Lake.
- Zmaterializowane widoki.
- Tabele przesyłania strumieniowego
APPLY CHANGES INTO, w tym cele operacji.
- Niektóre operacje odświeżania przyrostowego wymagają włączenia śledzenia wierszy dla zapytanych źródeł danych. Śledzenie wierszy to funkcja usługi Delta Lake obsługiwana tylko przez tabele delty, które obejmują zmaterializowane widoki, tabele przesyłania strumieniowego i tabele zarządzane przez wykaz aparatu Unity. 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:
Typy odświeżania dla zmaterializowanych widoków
Odświeżenia do zmaterializowanych widoków są pełne lub przyrostowe. 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ć używany typ odświeżania 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 ponowne przetwarzanie wszystkich danych dostępnych 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 Delta Live Tables można uruchomić pełne odświeżanie wybranych zestawów danych lub wszystkich zestawów danych w potoku. Zobacz Jak tabele delta live aktualizuje tabele i widoki.
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ść pipelines.reset.allowed tabeli na falsewartość .
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 aktualizowane przy użyciu potoków bezserwerowych mogą używać odświeżania przyrostowego. Zmaterializowane widoki, które nie używają potoków bezserwerowych, są zawsze w pełni odświeżane.
Gdy zmaterializowane widoki są tworzone przy użyciu potoku usługi SQL Warehouse lub bezserwerowych tabel delta live tables, są one automatycznie odświeżane przyrostowo, jeśli są obsługiwane ich zapytania. 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 zmaterializowanego odświeżania przyrostowego 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ą tabele delty, zmaterializowane widoki i tabele przesyłania strumieniowego. |
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 przyrostyzacji w funkcjach okien. |
QUALIFY |
Tak |
EXPECTATIONS |
L.p. Zmaterializowane widoki, które korzystają z oczekiwań, 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 skompilowany |
NO_OP |
Nie dotyczy | Zmaterializowany widok nie został zaktualizowany, ponieważ nie wykryto żadnych zmian w tabeli podstawowej. |
ROW_BASED lub PARTITION_OVERWRITE |
Tak | Zmaterializowany widok został odświeżony przyrostowo przy użyciu określonej techniki. |
Aby określić użytą technikę, wykonaj zapytanie w dzienniku zdarzeń delta Live Tables, w którym znajduje się planning_informationparametr event_type :
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> w pełni kwalifikowaną nazwą zmaterializowanego widoku, w tym wykazem i schematem.