Sdílet prostřednictvím

Postupná aktualizace pro materializovaná zobrazení

Tento článek popisuje sémantiku a požadavky na přírůstkové aktualizace v materializovaných zobrazeních a identifikuje operace SQL, klíčová slova a klauzule, které podporují přírůstkovou aktualizaci. Obsahuje diskuzi o rozdílech mezi přírůstkovými a úplnými aktualizacemi a obsahuje doporučení pro výběr mezi materializovanými zobrazeními a streamovanými tabulkami.

Při spouštění aktualizací v materializovaných zobrazeních pomocí bezserverových kanálů je možné přírůstkově aktualizovat mnoho dotazů. Postupné aktualizace šetří náklady na výpočetní prostředky tím, že detekují změny ve zdrojích dat používaných k definování materializovaného zobrazení a přírůstkově vypočítávají výsledek.

Aktualizace běží na bezserverových výpočetních prostředcích.

Operace aktualizace se spouští v bezserverových kanálech bez ohledu na to, jestli byla operace definovaná v Databricks SQL nebo pomocí deklarativních kanálů Sparku Lakeflow.

V případě materializovaných zobrazení definovaných pomocí Databricks SQL nemusí být váš pracovní prostor nakonfigurován pro bezserverové deklarativní kanály Spark Lakeflow. Aktualizace bude automaticky používat bezserverový kanál.

V případě materializovaných zobrazení definovaných pomocí deklarativních kanálů Sparku Lakeflow musíte kanál nakonfigurovat tak, aby používal bezserverový. Viz Konfigurace bezserverového kanálu.

Jaké jsou sémantiky aktualizace pro materializovaná zobrazení?

Materializovaná zobrazení zaručují ekvivalentní výsledky dávkových dotazů. Představte si například následující agregační dotaz:

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

Když tento dotaz spustíte pomocí libovolného produktu Azure Databricks, vypočítá se výsledek pomocí dávkové sémantiky k agregaci všech záznamů ve zdroji transactions_table, což znamená, že se všechna zdrojová data kontrolují a agregují v jedné operaci.

Note

Některé produkty Azure Databricks ukládají výsledky do mezipaměti automaticky v rámci relací nebo napříč relacemi, pokud se zdroje dat po spuštění posledního dotazu nezměnily. Strategie automatického ukládání do mezipaměti se liší od materializovaných zobrazení.

Následující příklad změní tento dávkový dotaz na materializované zobrazení:

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

Při aktualizaci materializovaného zobrazení se vypočítaný výsledek shoduje s sémantikou dávkového dotazu. Tento dotaz je příkladem materializovaného zobrazení, které lze přírůstkově aktualizovat, což znamená, že se operace aktualizace snaží zpracovat pouze nová nebo změněná data ve zdrojovém transactions_table k výpočtu výsledků.

Důležité informace o zdroji dat pro materializovaná zobrazení

I když můžete definovat materializované zobrazení pro jakýkoli zdroj dat, ne všechny zdroje dat jsou vhodné pro materializovaná zobrazení. Zvažte následující upozornění a doporučení:

Important

Materializovaná zobrazení se snaží provést pokus o přírůstkovou aktualizaci výsledků podporovaných operací. Některé změny ve zdrojích dat vyžadují úplnou aktualizaci. Můžete definovat zásadu aktualizace, která při chybném provedení nespustí úplnou aktualizaci.

Všechny zdroje dat pro materializovaná zobrazení by měly být robustní pro sémantiku úplné aktualizace, i když dotaz definující materializované zobrazení podporuje přírůstkovou aktualizaci.

  • V případě dotazů, kdy by úplná aktualizace byla nákladná, použijte streamovací tabulky k zajištění přesně jednou zpracování. Mezi příklady patří velmi velké tabulky.
  • Nedefinujte materializované zobrazení pro zdroj dat, pokud by záznamy měly být zpracovány pouze jednou. Místo toho používejte streamované tabulky. Mezi příklady patří:
    • Zdroje dat, které si nezachovávají historii dat, například Kafka.
    • Operace ingestování, jako jsou dotazy, které používají Auto Loader k načítání dat z cloudového úložiště objektů.
    • Jakýkoli zdroj dat, ve kterém plánujete odstranit nebo archivovat data po zpracování, ale potřebujete zachovat informace v podřízených tabulkách. Například tabulka s datem rozdělená na oddíly, ve které plánujete odstranit záznamy starší než určitou prahovou hodnotu.
  • Ne všechny zdroje dat podporují přírůstkové aktualizace. Následující zdroje dat podporují přírůstkovou aktualizaci:
    • Tabulky Delta, včetně spravovaných tabulek Katalogu Unity a externích tabulek založených na Delta Lake
    • Materializované pohledy.
    • Streamovací tabulky, včetně cílů operací AUTO CDC ... INTO
  • Některé operace přírůstkové aktualizace vyžadují povolení sledování řádků u dotazovaných zdrojů dat. Sledování řádků je funkce Delta Lake podporovaná pouze tabulkami Delta, mezi které patří materializovaná zobrazení, streamované tabulky a spravované tabulky Unity Catalog. Podívejte se na sledování řádků v Databricks.
  • Zdroje dat s filtry řádků nebo maskami sloupců definované nepodporují přírůstkovou aktualizaci. Zobrazit filtry řádků a masky sloupců

Optimalizace materializovaných zobrazení

Pro zajištění nejlepšího výkonu doporučuje Databricks povolit následující funkce ve všech materializovaných zdrojových tabulkách zobrazení:

Tyto funkce můžete nastavit během vytváření nebo později pomocí ALTER TABLE příkazu. Například:

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

Typy aktualizací pro materializovaná zobrazení

Při aktualizaci materializovaného zobrazení můžete zadat aktualizaci nebo úplnou aktualizaci.

  • Aktualizace se pokusí provést přírůstkovou aktualizaci, ale v případě potřeby provede úplné dokončování dat. Přírůstková aktualizace je dostupná jenom v případech, kdy jsou výpočetní prostředky, ke kterému jste připojení, bez serveru.
  • Úplná aktualizace vždy přepočítá všechny vstupy do materializovaného zobrazení a resetuje všechny kontrolní body.

Informace o tom, jak určit typ obnovení, který aktualizace použila, naleznete v tématu Určení typu obnovení aktualizace.

Výchozí aktualizace

Výchozí aktualizace materializovaného zobrazení při pokusech o přírůstkovou aktualizaci bez serveru Přírůstková aktualizace zpracovává změny v podkladových datech po poslední aktualizaci a pak tato data připojí k tabulce. V závislosti na základních tabulkách a zahrnutých operacích lze přírůstkově aktualizovat pouze určité typy materializovaných zobrazení. Pokud přírůstková aktualizace není možná nebo je připojené výpočetní prostředky klasické místo bez serveru, provede se úplné překomputování.

Note

Azure Databricks použije úplnou nebo přírůstkovou aktualizaci. Rozhodnutí vychází z toho, která možnost je nákladově efektivnější a jestli dotaz podporuje přírůstkovou aktualizaci. Pokud chcete toto chování změnit, přečtěte si téma Aktualizovat zásady.

Výstup přírůstkové aktualizace a úplné rekomputace jsou stejné. Azure Databricks spouští analýzu nákladů a vybírá levnější možnost mezi přírůstkovou aktualizací a úplným rekomputem.

Přírůstkovou aktualizaci můžou používat pouze materializovaná zobrazení aktualizovaná pomocí bezserverových kanálů. Materializovaná zobrazení, která nepoužívají bezserverové kanály, jsou vždy plně přepočítané.

Když vytváříte materializovaná zobrazení pomocí SQL skladu nebo bezserverových deklarativních kanálů Lakeflow Spark, Azure Databricks je přírůstkově aktualizuje, pokud jsou jejich dotazy podporovány. Pokud dotaz používá nepodporované výrazy, Azure Databricks místo toho spustí úplné překompilace, což může zvýšit náklady.

Informace o tom, jak určit typ obnovení, který aktualizace použila, naleznete v tématu Určení typu obnovení aktualizace.

Úplná aktualizace

Úplná aktualizace přepíše výsledky v materializovaném zobrazení vymazáním tabulky a kontrolních bodů a opětovným zpracováním všech dat dostupných ve zdroji.

Pokud chcete provést úplnou aktualizaci materializovaných zobrazení definovaných pomocí Databricks SQL, použijte následující syntaxi:

REFRESH MATERIALIZED VIEW mv_name FULL

Pro materializovaná zobrazení definovaná v deklarativních kanálech Sparku pro Lakeflow můžete spustit úplnou aktualizaci u vybraných datových sad nebo u všech datových sad v kanálu. Vizte sémantika aktualizace potrubí .

Important

Když se úplná aktualizace spustí ve zdroji dat, kde byly záznamy odebrány z důvodu prahové hodnoty uchovávání dat nebo ručního odstranění, odebrané záznamy se ve vypočítaných výsledcích neprojeví. Pokud už data nejsou ve zdroji dostupná, možná nebudete moct obnovit stará data. To může také změnit schéma sloupců, které už ve zdrojových datech neexistují.

podpora pro přírůstkovou aktualizaci materializovaného zobrazení

Následující tabulka uvádí podporu přírůstkové aktualizace podle klíčového slova nebo klauzule SQL. K otestování konkrétního dotazu na přírůstkovou dostupnost můžete použít EXPLAIN CREATE MATERIALIZED VIEW.

Important

Některá klíčová slova a klauzule vyžadují povolení sledování řádků u dotazovaných zdrojů dat. Podívejte se na sledování řádků v Databricks.

Tato klíčová slova a klauzule jsou v následující tabulce označené hvězdičkou (*).

Klíčové slovo nebo klauzule SQL Podpora přírůstkové aktualizace
SELECT výrazy* Ano, podporují se výrazy včetně deterministických předdefinovaných funkcí a neměnných uživatelem definovaných funkcí (UDF).
GROUP BY Yes
WITH Ano, podporují se běžné výrazy tabulek.
UNION ALL* Yes
FROM Mezi podporované základní tabulky patří tabulky Delta, materializovaná zobrazení a tabulky streamování.
WHERE, HAVING* Klauzule filtru, jako WHERE a HAVING, jsou podporovány.
INNER JOIN* Yes
LEFT OUTER JOIN* Yes
FULL OUTER JOIN* Yes
RIGHT OUTER JOIN* Yes
OVER Yes. PARTITION_BY sloupce musí být zadány pro inkrementaci okenních funkcí.
QUALIFY Yes
EXPECTATIONS Ano, materializovaná zobrazení, která zahrnují očekávání, je možné přírůstkově aktualizovat. Přírůstková aktualizace se ale nepodporuje pro následující případy:
  • Když materializované zobrazení načte ze zobrazení, které obsahuje očekávání.
  • Pokud materializované zobrazení má DROP očekávání a obsahuje NOT NULL sloupce ve schématu.
Ne deterministické funkce Ne deterministické časové funkce jsou podporovány v WHERE klauzulích. To zahrnuje funkce, jako current_date()jsou , current_timestamp()a now(). Jiné ne deterministické funkce nejsou podporovány.
Jiné zdroje než Delta Zdroje, jako jsou svazky, externí umístění a cizí katalogy, nejsou podporovány.

Určení typu aktualizace

K optimalizaci výkonu materializovaných aktualizací zobrazení používá Azure Databricks k výběru techniky použité pro aktualizaci nákladový model. Následující tabulka popisuje tyto techniky:

Technique Přírůstková aktualizace? Description
FULL_RECOMPUTE No Materializované zobrazení bylo plně přepočítané.
NO_OP Není relevantní Materializované zobrazení nebylo aktualizováno, protože nebyly zjištěny žádné změny základní tabulky.
Libovolná z těchto možností:
  • ROW_BASED
  • PARTITION_OVERWRITE
  • WINDOW_FUNCTION
  • APPEND_ONLY
  • GROUP_AGGREGATE
  • GENERIC_AGGREGATE
 Yes Materializované zobrazení bylo přírůstkově aktualizováno pomocí zadané techniky.

Přečtěte si také o zásadách aktualizace.

Pokud chcete zjistit použitou techniku, udejte dotaz v logu událostí Deklarativní kanály Lakeflow Spark, kde event_type je planning_information:

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

Nahraďte <fully-qualified-table-name> plně kvalifikovaným názvem materializovaného zobrazení, včetně katalogu a schématu.

Ukázkový výstup pro tento příkaz:

    • časové razítko
    • zpráva
    • 2025-03-21T22:23:16.497+00:00
    • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Viz protokol událostí kanálu.

Zásady aktualizace

Azure Databricks ve výchozím nastavení automaticky vybere nákladově nejefektivnější strategii aktualizace (přírůstkové nebo úplné) na základě struktury dotazů, objemu změn dat a modelování systémových nákladů. Toto výchozí chování optimalizuje výkon aktualizace bez nutnosti ruční konfigurace.

Některé úlohy ale vyžadují předvídatelnější nebo explicitně řízené chování aktualizace. Pro podporu těchto scénářů můžete zadat REFRESH POLICY v definici materializovaného zobrazení. Zásady aktualizace řídí, jestli Azure Databricks provádí přírůstkovou aktualizaci, kdy se může vrátit k úplné aktualizaci a jestli by aktualizace neměla selhat místo provedení úplného rekompute.

Pomocí REFRESH POLICYnástroje , můžete systém nakonfigurovat na:

  • AUTO (výchozí) – Použijte automatický výběr založený na nákladech. Databricks vybírá přírůstkovou nebo úplnou aktualizaci na základě efektivity a možností dotazů. Doporučuje se pro většinu uživatelů.
  • INCREMENTAL - Upřednostněte přírůstkovou aktualizaci. Databricks provádí přírůstkovou aktualizaci, kdykoli je to možné. Pokud plán dotazu už nepodporuje přírůstkovou aktualizaci, vrátí se zpět na úplnou aktualizaci.
  • INCREMENTAL STRICT – Vyžaduje výhradně přírůstkovou aktualizaci. Přírůstková aktualizace se vyžaduje během normálního provozu. Pokud není inkrementace možná, operace aktualizace nebo vytvoření selže.
  • FULL – Vždy provádět úplné aktualizace. Databricks nikdy neprovádí přírůstkovou aktualizaci, i když je dotaz přírůstkový.
-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Optimální zásady aktualizace závisí na vlastnostech vašich úloh:

  • AUTO je vhodná pro většinu úloh. Vyrovnává náklady a výkon a automaticky se přizpůsobí, když se změní chování dotazů.
  • INCREMENTAL je užitečný, když přírůstková aktualizace poskytuje výhody, ale je přijatelné, aby Azure Databricks prováděl úplné aktualizace, když je přírůstková aktualizace dočasně nedostupná (například když je sledování řádků ve zdrojové tabulce vypnuté).
  • INCREMENTAL STRICT by měla být použita, pokud je nutná přírůstková aktualizace, aby splňovala omezení nákladů, výkonu nebo smlouvy SLA a neočekávané úplné aktualizace jsou nepřijatelné. Tato zásada se doporučuje, když uživatelé dávají přednost tomu, aby aktualizace selhala, aby mohli problém ladit, a ne pokračovat v úplné aktualizaci.
  • FULL je vhodný v případě, že přírůstková aktualizace poskytuje malou výhodu, datová sada je malá nebo se struktura dotazů často mění způsoby, které brání inkrementalizaci.
  • Last updated on