Inkrementell uppdatering för 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.

Serverlösa pipelines krävs för inkrementell uppdatering

Inkrementell uppdatering för materialiserade vyer kräver pipelines utan servrar.

Uppdateringsåtgärder för materialiserade vyer som definierats i Databricks SQL körs alltid med hjälp av serverlösa pipelines.

För de materialiserade vyer som definierats med hjälp av Delta Live Tables-pipelines måste du konfigurera pipelinen så att den använder serverlös drift. Se Konfigurera en pipeline för Delta Live Tables utan server.

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.

Kommentar

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 transation_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:

Viktigt!

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 mot en datakälla om poster bara ska bearbetas 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.
  • Mata in åtgärder, till exempel frågor som använder Automatisk inläsning för att mata in data från molnobjektlagring.
  • 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 APPLY CHANGES INTO åtgärder.
• 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:

• Borttagningsvektorer
  • Radspårning
  • Ändra dataflöde

Uppdateringstyper för materialiserade vyer

Uppdateringar av materialiserade vyer är antingen fullständiga eller inkrementella. För alla åtgärder är resultatet av en inkrementell uppdatering och fullständig uppdatering detsamma. Azure Databricks kör en kostnadsanalys för att identifiera om ändringar i datakällor kräver en fullständig uppdatering.

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 bearbeta om alla tillgängliga data i källan. Alla materialiserade vyer kan uppdateras fullständigt vid en viss uppdatering, beroende på hur datakällorna har ändrats.

Du kan också framtvinga en fullständig uppdatering. Använd följande syntax för materialiserade vyer som definierats med Databricks SQL:

REFRESH MATERIALIZED VIEW mv_name FULL

För materialiserade vyer som definierats i en Delta Live Tables-pipeline kan du välja att köra en fullständig uppdatering på valda datauppsättningar eller på alla datauppsättningar i en pipeline. Se semantik för pipelineuppdatering.

Viktigt!

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.

Kommentar

Du kan också inaktivera fullständiga uppdateringar i en tabell genom att ange tabellegenskapen pipelines.reset.allowed till false.

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.

Endast materialiserade vyer som uppdateras med serverlösa pipelines kan använda inkrementell uppdatering. Materialiserade vyer som inte använder serverlösa pipelines uppdateras alltid fullständigt.

När materialiserade vyer skapas med hjälp av ett SQL-lager eller en serverlös Delta Live Tables-pipeline uppdateras de automatiskt stegvis om deras frågor stöds. Om en fråga innehåller uttryck som inte stöds för en inkrementell uppdatering utförs en fullständig uppdatering, vilket kan leda till ytterligare kostnader.

Stöd för materialiserad inkrementell vyuppdatering

I följande tabell visas stöd för inkrementell uppdatering efter SQL-nyckelord eller -sats.

Viktigt!

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	Ja
WITH	Ja, vanliga tabelluttryck stöds.
UNION ALL*	Ja
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*	Ja
LEFT OUTER JOIN*	Ja
FULL OUTER JOIN*	Ja
RIGHT OUTER JOIN*	Ja
OVER	Ja. PARTITION_BY kolumner måste anges för inkrementellisering i fönsterfunktioner.
QUALIFY	Ja
EXPECTATIONS	Nej. Materialiserade vyer som använder förväntningar uppdateras alltid fullständigt.

Kommentar

Icke-deterministiska funktioner, till exempel CURRENT_TIMESTAMP, 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:

Teknik	Inkrementell uppdatering?	beskrivning
FULL_RECOMPUTE	Nej	Den materialiserade vyn har omberäknats helt
NO_OP	Inte tillämpligt	Den materialiserade vyn uppdaterades inte eftersom inga ändringar i bastabellen identifierades.
ROW_BASED eller PARTITION_OVERWRITE	Ja	Den materialiserade vyn uppdaterades stegvis med den angivna tekniken.

För att fastställa vilken teknik som används, sök i händelseloggen för Delta Live Tables 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.

Se Vad är Delta Live Tables händelseloggen?.