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 Deklarativa pipelines för Lakeflow.

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

För materialiserade vyer som definierats med Lakeflow-deklarativa pipelines måste du konfigurera pipelinen så att den är 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.

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 Använd radspårning för Delta-tabeller.

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.

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-lager eller serverlösa Deklarativa Lakeflow-pipelines uppdaterar Azure Databricks dem stegvis 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 deklarativa pipelines kan du välja att utfö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.

Important

Vissa nyckelord och -satser kräver att radspårning aktiveras på de efterfrågade datakällorna. Se Använd radspårning för Delta-tabeller.

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.

För att fastställa vilken teknik som används, gör en fråga mot händelseloggen för Lakeflow 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ändelseloggen för Deklarativa pipelines i Lakeflow.