Zmaterializowane widoki

Podobnie jak w przypadku widoków standardowych, zmaterializowane widoki są wynikami zapytania i uzyskujesz do nich dostęp w taki sam sposób, jak w przypadku tabeli. W przeciwieństwie do widoków standardowych, które rekompilują wyniki dla każdego zapytania, zmaterializowane widoki buforują wyniki i odświeżają je w określonym interwale. Ponieważ zmaterializowany widok jest wstępnie skompilowany, zapytania względem niego mogą działać znacznie szybciej niż w przypadku zwykłych widoków.

Zmaterializowany widok jest obiektem deklaratywnego przepływu danych. Zawiera to zapytanie, które je definiuje, przepływ do jego aktualizacji oraz buforowane wyniki umożliwiające szybki dostęp. Zmaterializowany widok:

• Śledzi zmiany w danych nadrzędnych.
• Po uruchomieniu wyzwalacza przetwarza przyrostowo zmienione dane i stosuje niezbędne przekształcenia.
• Utrzymuje tabelę wyjściową zsynchronizowaną z danymi źródłowymi na podstawie określonego interwału odświeżania.

Zmaterializowane widoki są dobrym wyborem dla wielu przekształceń:

• Zamiast wierszy stosuje się wnioskowanie dotyczące buforowanych wyników. W rzeczywistości wystarczy napisać zapytanie.
• Są one zawsze poprawne. Wszystkie wymagane dane są przetwarzane, nawet jeśli przybywają z opóźnieniem lub w niewłaściwej kolejności.
• Są one często przyrostowe. Usługa Databricks spróbuje wybrać odpowiednią strategię, która minimalizuje koszt procesu aktualizacji zmaterializowanego widoku.

Jak działają zmaterializowane widoki

Na poniższym diagramie przedstawiono sposób działania zmaterializowanych widoków.

diagram

Zmaterializowane widoki są definiowane i aktualizowane przez pojedynczy proces. Można jawnie zdefiniować zmaterializowane widoki w kodzie źródłowym pipeline'u. Tabele zdefiniowane przez potok nie mogą być zmieniane ani aktualizowane przez żaden inny potok.

Podczas tworzenia zmaterializowanego widoku poza potokiem w Databricks SQL, Databricks tworzy ukryty potok, który służy do aktualizacji widoku.

Usługa Databricks używa Unity Catalog do przechowywania metadanych dotyczących widoku, w tym zapytań, i dodatkowych widoków systemowych używanych do aktualizacji przyrostowych. Buforowane dane są zmaterializowane w magazynie w chmurze.

Poniższy przykład łączy dwie tabele ze sobą i utrzymuje wynik na bieżąco przy użyciu zmaterializowanego widoku.

Pyton

import dlt

@dlt.table
def regional_sales():
  partners_df = spark.read.table("partners")
  sales_df = spark.read.table("sales")

  return (
    partners_df.join(sales_df, on="partner_id", how="inner")
  )

Jeśli w metodzie używasz jednego lub więcej spark.readStream wywołań, zmienia to widok na tabelę strumieniową zamiast zmaterializowanego widoku.

SQL

CREATE OR REPLACE MATERIALIZED VIEW regional_sales
  AS SELECT *
  FROM partners
    INNER JOIN sales ON
      partners.partner_id = sales.partner_id;

Automatyczne aktualizacje przyrostowe

Po wyzwoleniu potoku definiującego zmaterializowany widok jest automatycznie aktualizowany, często przyrostowo. Usługa Databricks próbuje przetworzyć tylko dane, które muszą być przetwarzane, aby zachować aktualny zmaterializowany widok. Zmaterializowany widok zawsze wyświetla prawidłowy wynik, nawet jeśli wymaga pełnego ponownego skompilowania wyniku zapytania od podstaw, ale często usługa Databricks tworzy tylko przyrostowe aktualizacje zmaterializowanego widoku, co może być znacznie mniej kosztowne niż pełna ponowna kompilacja.

Na poniższym diagramie przedstawiono zmaterializowany widok o nazwie sales_report, który jest wynikiem łączenia dwóch nadrzędnych tabel o nazwie clean_customers i clean_transactionsi grupowania według kraju. Proces nadrzędny wstawia 200 wierszy do clean_customers w trzech krajach (USA, Holandia, Wielka Brytania) i aktualizuje 5000 wierszy w clean_transactions odpowiadających tym nowym klientom. Zmaterializowany sales_report widok jest aktualizowany przyrostowo tylko dla krajów, które mają nowych klientów lub odpowiadające im transakcje. W tym przykładzie zobaczymy trzy wiersze zaktualizowane zamiast całego raportu sprzedaży.

Aby uzyskać więcej informacji na temat działania odświeżania przyrostowego w zmaterializowanych widokach, zobacz Odświeżanie przyrostowe dla zmaterializowanych widoków.

Zmaterializowane ograniczenia widoków

Zmaterializowane widoki mają następujące ograniczenia:

• Ponieważ aktualizacje tworzą poprawne zapytania, niektóre zmiany w danych wejściowych będą wymagały pełnej ponownej kompilacji zmaterializowanego widoku, co może być kosztowne.
• Nie są one przeznaczone dla przypadków użycia o niskim opóźnieniu. Opóźnienie aktualizowania zmaterializowanego widoku wynosi w sekundach lub minutach, a nie milisekundach.
• Nie wszystkie obliczenia mogą być obliczane przyrostowo.