Dela via

Inkrementell uppdatering av materialiserade vyer

Den här artikeln beskriver semantiken och kraven för inkrementella uppdateringar av materialiserade vyer och identifierar SQL-åtgärder, nyckelord och -satser som stöder inkrementell uppdatering. Den innehåller en diskussion om skillnaderna mellan inkrementella och fullständiga uppdateringar och innehåller rekommendationer för att välja mellan materialiserade vyer och strömmande tabeller.

När du kör uppdateringar på materialiserade vyer med hjälp av serverlösa pipelines kan många frågor uppdateras stegvis. Inkrementella uppdateringar sparar beräkningskostnader genom att identifiera ändringar i de datakällor som används för att definiera den materialiserade vyn och stegvis beräkna resultatet.

Uppdateringar körs på serverlös beräkning

Uppdateringsåtgärder körs på serverlösa pipelines, oavsett om åtgärden har definierats i Databricks SQL eller med Lakeflow Spark Deklarativa pipelines.

För materialiserade vyer som definierats med Databricks SQL behöver din arbetsyta inte aktiveras för serverlösa Lakeflow Spark-deklarativa pipelines. Uppdateringen använder en serverlös pipeline automatiskt.

För materialiserade vyer som definierats med Lakeflow Spark Deklarativa pipelines måste du konfigurera pipelinen så att den använder serverlös. Se Konfigurera en serverlös pipeline.

Vad är uppdateringssemantiken för materialiserade vyer?

Materialiserade vyer garanterar likvärdiga resultat för batchfrågor. Tänk till exempel på följande aggregeringsfråga:

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

När du kör den här frågan med någon Azure Databricks-produkt beräknas resultatet med hjälp av batch-semantik för att aggregera alla poster i källan transactions_table, vilket innebär att alla källdata genomsöks och aggregeras i en åtgärd.

Note

Vissa Azure Databricks-produkter cachelagrar resultat automatiskt inom eller mellan sessioner om datakällor inte har ändrats efter att den senaste frågan har körts. Beteendet för automatisk cachelagring skiljer sig från materialiserade vyer.

I följande exempel omvandlas den här batchfrågan till en materialiserad vy:

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

När du uppdaterar en materialiserad vy är det beräknade resultatet identiskt med batchfrågesemantiken. Den här frågan är ett exempel på en materialiserad vy som kan uppdateras stegvis, vilket innebär att uppdateringsåtgärden gör ett bästa försök att endast bearbeta nya eller ändrade data i källan transactions_table för att beräkna resultatet.

Överväganden beträffande datakällor för materialiserade vyer

Du kan definiera en materialiserad vy mot alla datakällor, men inte alla datakällor passar bra för materialiserade vyer. Överväg följande varningar och rekommendationer:

Important

Materialiserade vyer gör ett bästa försök att stegvis uppdatera resultat för åtgärder som stöds. Vissa ändringar i datakällor kräver en fullständig uppdatering. Du kan definiera en uppdateringsprincip som misslyckas i stället för att köra en fullständig uppdatering.

Alla datakällor för materialiserade vyer bör vara robusta för fullständig uppdateringssemantik, även om frågan som definierar den materialiserade vyn stöder inkrementell uppdatering.

  • För frågor där en fullständig uppdatering skulle vara för kostsam använder du strömmande tabeller för att garantera exakt en gångs bearbetning. Exempel är mycket stora tabeller.
  • Definiera inte en materialiserad vy från en datakälla om poster ska bearbetas endast en gång. Använd i stället strömmande tabeller. Exempel är följande:
    • Datakällor som inte behåller datahistorik, till exempel Kafka.
    • Inmatningsoperationer, till exempel frågor som använder Auto Loader för att hämta data från molnobjektslagring.
    • Alla datakällor där du planerar att ta bort eller arkivera data efter bearbetning men behöver behålla information i underordnade tabeller. Till exempel en datumpartitionerad tabell där du planerar att ta bort poster som är äldre än ett visst tröskelvärde.
  • Alla datakällor stöder inte inkrementella uppdateringar. Följande datakällor stöder inkrementell uppdatering:
    • Deltatabeller, inklusive hanterade Unity Catalog-tabeller och externa tabeller som backas upp av Delta Lake.
    • Materialiserade vyer.
    • Strömmande tabeller, inklusive målen för AUTO CDC ... INTO operationer.
  • Vissa inkrementella uppdateringsåtgärder kräver att radspårning aktiveras på de efterfrågade datakällorna. Radspårning är en Delta Lake-funktion som endast stöds av Delta-tabeller, som inkluderar materialiserade vyer, strömmande tabeller och hanterade Unity Catalog-tabeller. Se Radspårning i Databricks.
  • Datakällor med radfilter eller definierade kolumnmasker stöder inte inkrementell uppdatering. Se Radfilter och kolumnmasker

Optimera materialiserade vyer

För att få bästa prestanda rekommenderar Databricks att du aktiverar följande funktioner i alla materialiserade källtabeller för vy:

Du kan ange dessa funktioner när du skapar eller senare med -instruktionen ALTER TABLE . Till exempel:

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

Uppdateringstyper för materialiserade vyer

När en materialiserad vy uppdateras kan du ange en uppdatering eller en fullständig uppdatering.

  • En uppdatering försöker utföra en inkrementell uppdatering, men utför en fullständig omkompensering av data om det behövs. Inkrementell uppdatering är endast tillgänglig när den beräkning som du är ansluten till är serverlös.
  • En fullständig uppdatering beräknar alltid om alla indata till den materialiserade vyn och återställer alla kontrollpunkter.

Information om vilken uppdateringstyp som används finns i Fastställa uppdateringstypen för en uppdatering.

Standarduppdatering

Standarduppdateringen för en materialiserad vy på serverlösa försök att utföra en inkrementell uppdatering. En inkrementell uppdatering bearbetar ändringar i underliggande data efter den senaste uppdateringen och lägger sedan till dessa data i tabellen. Beroende på bastabeller och inkluderade åtgärder kan endast vissa typer av materialiserade vyer uppdateras stegvis. Om en inkrementell uppdatering inte är möjlig eller om den anslutna beräkningen är klassisk i stället för serverlös, utförs en fullständig omkompetentering.

Note

Azure Databricks tillämpar en fullständig eller inkrementell uppdatering. Beslutet baseras på vilket alternativ som är mer kostnadseffektivt och om en fråga stöder inkrementell uppdatering. Information om hur du ändrar det här beteendet finns i Uppdatera princip.

Utdata från en inkrementell uppdatering och en fullständig omkompensering är desamma. Azure Databricks kör en kostnadsanalys för att välja det billigare alternativet mellan en inkrementell uppdatering och en fullständig omkompensering.

Endast materialiserade vyer som uppdateras med serverlösa pipelines kan använda inkrementell uppdatering. Materialiserade vyer som inte använder serverlösa pipelines är alltid helt omberäknade.

När du skapar materialiserade vyer med ett SQL-datavaruhus eller Lakeflow Spark deklarativa serverlösa pipelines, uppdaterar Azure Databricks dem inkrementellt om deras frågor stöds. Om en fråga använder uttryck som inte stöds kör Azure Databricks en fullständig omkompensering i stället, vilket kan öka kostnaderna.

Information om vilken uppdateringstyp som används finns i Fastställa uppdateringstypen för en uppdatering.

Fullständig uppdatering

En fullständig uppdatering skriver över resultaten i den materialiserade vyn genom att rensa tabellen och kontrollpunkterna och bearbeta om alla tillgängliga data i källan.

Om du vill utföra en fullständig uppdatering av materialiserade vyer som definierats med Databricks SQL använder du följande syntax:

REFRESH MATERIALIZED VIEW mv_name FULL

För materialiserade vyer som definierats i Lakeflow Spark Declarative Pipelines kan du välja att köra en fullständig uppdatering på valda datauppsättningar eller på alla datauppsättningar i en pipeline. Se pipelineuppdateringssemantik.

Important

När en fullständig uppdatering körs mot en datakälla där poster har tagits bort på grund av tröskelvärdet för datakvarhållning eller manuell borttagning återspeglas inte borttagna poster i beräknade resultat. Du kanske inte kan återställa gamla data om data inte längre är tillgängliga i källan. Detta kan också ändra schemat för kolumner som inte längre finns i källdata.

Stöd för materialiserad inkrementell vyuppdatering

I följande tabell visas stöd för inkrementell uppdatering efter SQL-nyckelord eller -sats. Om du vill testa en specifik fråga för inkrementell funktionalitet kan du använda EXPLAIN CREATE MATERIALIZED VIEW.

Important

Vissa nyckelord och -satser kräver att radspårning aktiveras på de efterfrågade datakällorna. Se Radspårning i Databricks.

Dessa nyckelord och -satser markeras med en stjärna (*) i följande tabell.

SQL-nyckelord eller -sats Stöd för inkrementell uppdatering
SELECT Uttryck* Ja, uttryck som deterministiska inbyggda funktioner och oföränderliga användardefinierade funktioner (UDF: er) stöds.
GROUP BY Yes
WITH Ja, vanliga tabelluttryck stöds.
UNION ALL* Yes
FROM Bastabeller som stöds är Delta tabeller, materialiserade vyer och strömmande tabeller.
WHERE, HAVING* Filtersatser som WHERE och HAVING stöds.
INNER JOIN* Yes
LEFT OUTER JOIN* Yes
FULL OUTER JOIN* Yes
RIGHT OUTER JOIN* Yes
OVER Yes. PARTITION_BY kolumner måste anges för inkrementellisering i fönsterfunktioner.
QUALIFY Yes
EXPECTATIONS Ja, materialiserade vyer som innehåller förväntningar kan uppdateras stegvis. Inkrementell uppdatering stöds dock inte i följande fall:
  • När den materialiserade vyn läser från en vy som innehåller förväntningar.
  • När den materialiserade vyn har en DROP förväntan och innehåller NOT NULL kolumner i sitt schema.
Icke-deterministiska funktioner Icke-deterministiska tidsfunktioner stöds i WHERE satser. Detta omfattar funktioner som current_date(), current_timestamp()och now(). Andra icke-deterministiska funktioner stöds inte.
Icke-Delta-källor Källor som volymer, externa platser och externa kataloger stöds inte.

Fastställa uppdateringstypen för en uppdatering

För att optimera prestanda för materialiserade vyuppdateringar använder Azure Databricks en kostnadsmodell för att välja den teknik som används för uppdateringen. I följande tabell beskrivs dessa tekniker:

Technique Inkrementell uppdatering? Description
FULL_RECOMPUTE No Den materialiserade vyn har omberäknats helt
NO_OP Ej tillämpligt Den materialiserade vyn uppdaterades inte eftersom inga ändringar i bastabellen identifierades.
Något av:
  • ROW_BASED
  • PARTITION_OVERWRITE
  • WINDOW_FUNCTION
  • APPEND_ONLY
  • GROUP_AGGREGATE
  • GENERIC_AGGREGATE
 Yes Den materialiserade vyn uppdaterades stegvis med den angivna tekniken.

Se även Uppdateringspolicy.

För att fastställa vilken teknik som används, kontrollera händelseloggen för Lakeflow Spark Deklarativa Pipelines där event_type är planning_information.

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

Ersätt <fully-qualified-table-name> med det fullständigt kvalificerade namnet på den materialiserade vyn, inklusive katalogen och schemat.

Exempelutdata för det här kommandot:

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

Se Händelselogg för pipeline.

Uppdatera princip

Som standard väljer Azure Databricks automatiskt den mest kostnadseffektiva uppdateringsstrategin – inkrementell eller fullständig – baserat på frågestruktur, dataändringsvolym och systemkostnadsmodellering. Det här standardbeteendet optimerar uppdateringsprestanda utan manuell konfiguration.

Vissa arbetsbelastningar kräver dock mer förutsägbart eller explicit kontrollerat uppdateringsbeteende. För att stödja dessa scenarier kan du ange en REFRESH POLICY i den materialiserade vydefinitionen. En uppdateringsprincip styr om Azure Databricks utför inkrementell uppdatering, när den kan återgå till en fullständig uppdatering och om en uppdatering ska misslyckas i stället för att utföra en fullständig omkompensering.

Med hjälp av REFRESH POLICY kan du konfigurera systemet så att:

  • AUTO (standardinställning) – Använd automatisk, kostnadsbaserat val. Databricks väljer inkrementell eller fullständig uppdatering baserat på effektivitets- och frågefunktioner. Rekommenderas för de flesta användare.
  • INCREMENTAL – Föredrar inkrementell uppdatering. Databricks utför inkrementell uppdatering när det är möjligt. Den återgår till en fullständig uppdatering om frågeplanen inte längre stöder inkrementell uppdatering.
  • INCREMENTAL STRICT - Strikt kräver inkrementell uppdatering. Inkrementell uppdatering krävs under normal drift. Om inkrementellisering inte är möjlig misslyckas uppdateringen eller skapandeåtgärden.
  • FULL – Utför alltid fullständiga uppdateringar. Databricks utför aldrig inkrementell uppdatering, även om frågan är inkrementell.
-- 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;

Den optimala uppdateringsprincipen beror på dina arbetsbelastningsegenskaper:

  • AUTO är lämpligt för de flesta arbetsbelastningar. Den balanserar kostnader och prestanda och anpassas automatiskt när frågebeteendet ändras.
  • INCREMENTAL är användbart när inkrementell uppdatering ger fördelar, men det är acceptabelt för Azure Databricks att utföra fullständiga uppdateringar när inkrementellisering blir tillfälligt otillgänglig (till exempel när radspårning i en källtabell är inaktiverad).
  • INCREMENTAL STRICT bör användas när inkrementell uppdatering krävs för att uppfylla kostnads-, prestanda- eller SLA-begränsningar och oväntade fullständiga uppdateringar är oacceptabla. Den här principen rekommenderas när användarna föredrar att uppdateringen misslyckas, så att de kan felsöka problemet i stället för att fortsätta med en fullständig uppdatering.
  • FULL är lämplig när inkrementell uppdatering ger liten nytta, datamängden är liten eller frågestrukturen ändras ofta på sätt som förhindrar inkrementellisering.
  • Last updated on