Przyrostowe refresh dla zmaterializowanych views

W tym artykule opisano semantykę i wymagania dotyczące przyrostowego odświeżania zmaterializowanych viewsi identyfikuje operacje SQL, słowa kluczowe i klauzule, które wspierają przyrostowe refresh. Zawiera on omówienie różnic między odświeżaniem przyrostowym i pełnym, a także zalecenia dotyczące wyboru między zmaterializowanymi views a przesyłaniem strumieniowym tables.

Podczas uruchamiania aktualizacji na zmaterializowanym views za pomocą 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.

Potoki bezserwerowe są wymagane w przypadku refresh przyrostowych

Przyrostowe refresh dla zmaterializowanych views wymagają bezserwerowych potoków.

Refresh operacji zmaterializowanych views zdefiniowanych w Databricks SQL zawsze są uruchamiane przy użyciu ścieżek bezserwerowych.

W przypadku materiału views zdefiniowanego przy użyciu potoków Delta Live Tables należy skonfigurować potok do korzystania z funkcji bezserwerowej. Zobacz Konfigurowanie bezserwerowego potoku usługi Delta Live Tables.

Jakie są semantyka refresh dla zmaterializowanych views?

Zmaterializowane views 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.

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

Gdy refresh zmaterializujesz widok, obliczony wynik jest identyczny z semantyką zapytań wsadowych. To zapytanie jest przykładem zmaterializowanego widoku, który może być odświeżany przyrostowo, co oznacza, że operacja refresh podejmuje najlepszą próbę przetworzenia tylko nowych lub zmienionych danych w źródle transactions_table w celu obliczenia wyników.

Zagadnienia dotyczące źródła danych związane z materializowanymi views

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

Wszystkie źródła danych zmaterializowanego views powinny być niezawodne w celu pełnej semantyki refresh, nawet jeśli zapytanie definiujące zmaterializowany widok obsługuje przyrostową obsługę refresh.

• W przypadku zapytań where pełne refresh rozwiązanie byłoby kosztowne, użyj przesyłania strumieniowego tables, aby zagwarantować dokładnie jednokrotne przetwarzanie. Przykłady obejmują bardzo duże tables.
• Nie należy definiować zmaterializowanego widoku względem źródła danych, jeśli rekordy powinny być przetwarzane tylko raz. Zamiast tego użyj tablesprzesył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 where planujesz usunąć lub zarchiwizować dane po przetworzeniu, ale należy zachować informacje w podrzędnych tables. Na przykład planujesz usunąć rekordy starsze niż określony próg w partycjonowanym po dacie tablewhere.
• Nie wszystkie źródła danych obsługują odświeżanie przyrostowe. Następujące źródła danych obsługują wersje przyrostowe refresh:
  • Delta tables, w tym zarządzane Catalog przez Unity tables i zewnętrzne tables wspierane przez Delta Lake.
  • Zmaterializowane views.
  • Streaming tables, w tym cele operacji APPLY CHANGES INTO.
• Niektóre operacje przyrostowe refresh wymagają włączenia śledzenia wierszy dla zapytanych źródeł danych. Śledzenie wierszy to funkcja usługi Delta Lake obsługiwana tylko przez Delta tables, która obejmuje zmaterializowane views, przesyłanie strumieniowe tables, oraz zarządzanie Unity Catalogtables. Zobacz Użyj śledzenia wierszy dla Delta tables.

Optimize zmaterializowane views

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

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

typy Refresh dla zmaterializowanych views

Odświeżenia materialized views są kompletne lub przyrostowe. Wyniki przyrostowego refresh i pełnego refresh są takie same dla wszystkich operacji. Usługa Azure Databricks uruchamia analizę kosztów w celu określenia, czy zmiany źródeł danych wymagają pełnego refresh.

Aby określić, którego typu refresh używa update, zobacz Określanie typu refreshupdate.

Pełna refresh

Pełny refresh zastępuje wyniki w zmaterializowanym widoku przez ponowne przetwarzanie wszystkich danych dostępnych w źródle. Wszystkie zmaterializowane views mogą zostać w pełni odświeżone na dowolnym update, w zależności od tego, jak bardzo źródła danych uległy zmianie.

Możesz opcjonalnie wymusić pełne refresh. W przypadku zmaterializowanych views zdefiniowanych za pomocą Databricks SQL użyj następującej składni:

REFRESH MATERIALIZED VIEW mv_name FULL

W przypadku zmaterializowanych views zdefiniowanych w pipeline'ie Delta Live Tables, można uruchomić pełne refresh dla wybranych zestawów danych lub wszystkich zestawów danych w pipeline'ie. Zobacz semantyka refresh potoku .

refresh przyrostowe

Przyrostowy proces refresh przetwarza zmiany w danych bazowych po ostatnim refresh, a następnie dołącza te dane do table. W zależności od podstawowych tables i uwzględnionych operacji tylko niektóre typy zmaterializowanych views mogą być odświeżane przyrostowo.

Tylko zmaterializowane views zaktualizowane przy użyciu bezserwerowych potoków mogą używać przyrostowych refresh. Zmaterializowane views, które nie używają potoków bezserwerowych, są zawsze w pełni odświeżane.

Gdy zmaterializowane views są tworzone przy użyciu usługi SQL Warehouse lub bezserwerowego potoku usługi Delta Live Tables, są one automatycznie odświeżane przyrostowo, jeśli ich zapytania są obsługiwane. Jeśli zapytanie zawiera niewspierane wyrażenia dla przyrostowego refresh, zostanie wykonana pełna realizacja refresh, co może spowodować dodatkowe koszty.

Obsługa przyrostowa zmaterializowanego widoku refresh

Poniższa table wymienia obsługę przyrostowych refresh według słowa kluczowego lub klauzuli SQL.

Określ typ refreshupdate

Aby optimize wydajność zmaterializowanych odświeżeń widoku, usługa Azure Databricks używa modelu kosztów do select techniki używanej w refresh. W poniższym table opisano następujące techniki:

Aby określić użytą technikę, wykonaj zapytanie w dzienniku zdarzeń Delta Live Tableswhere, gdzie 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> w pełni kwalifikowaną nazwą zmaterializowanego widoku poprzez dodanie catalog i schema.

Zobacz Co to jest dziennik zdarzeń usługi Delta Live Tables?.