Använda materialiserade vyer i Databricks SQL

Den här artikeln beskriver hur du skapar och uppdaterar materialiserade vyer i Databricks SQL för att förbättra prestanda och minska kostnaden för dina databearbetnings- och analysarbetsbelastningar.

Vad är materialiserade vyer?

I Databricks SQL är materialiserade vyer hanterade Unity Catalog-tabeller som fysiskt lagrar resultatet av en fråga. Till skillnad från standardvyer, som beräknar resultat på begäran, cachelagras resultaten i materialiserade vyer och uppdateras när de underliggande källtabellerna ändras – antingen enligt ett schema eller automatiskt.

Materialiserade vyer passar bra för databearbetningsarbetsbelastningar som ETL-bearbetning (extrahering, transformering och inläsning). Materialiserade vyer är ett enkelt, deklarativt sätt att bearbeta data för efterlevnad, korrigeringar, aggregeringar eller allmän insamling av ändringsdata (CDC). Materialiserade vyer möjliggör också enkla transformeringar genom att rensa, berika och avnormalisera bastabeller. Genom att förberäkna dyra eller ofta använda frågor resulterar materialiserade vyer i lägre svarstid och resursförbrukning. I många fall kan de stegvis beräkna ändringar från källtabeller, vilket ytterligare förbättrar effektiviteten och slutanvändarupplevelsen.

Följande är vanliga användningsfall för materialiserade vyer:

• Hålla en BI-instrumentpanel uppdaterad med minimal svarstid för slutanvändarfrågor.
• Minska komplex ETL-orkestrering med enkel SQL-logik.
• Skapa komplexa, lageromvandlingar.
• Alla användningsfall som kräver konsekventa prestanda med up-to-date insights.

När du skapar en materialiserad vy i ett Databricks SQL-lager skapas en serverlös pipeline för att bearbeta skapande och uppdateringar av den materialiserade vyn. Du kan övervaka status för uppdateringsåtgärder i Katalogutforskaren. Se Visa information med DESCRIBE EXTENDED.

krav

Materialiserade vyer som skapats i Databricks SQL backas upp av en serverlös pipeline. Din arbetsyta måste ha stöd för serverlösa pipelines för att kunna använda den här funktionen.

Krav för att skapa eller uppdatera materialiserade vyer:

• Du måste använda ett Unity Catalog-aktiverat proffs- eller serverlöst SQL-lager.

• Om du vill uppdatera en materialiserad vy måste du vara på arbetsytan som skapade den.

• För att stegvis uppdatera en materialiserad vy från Delta-tabeller måste källtabellerna ha radspårning aktiverat.

• Ägaren (användaren som skapar den materialiserade vyn) måste ha följande behörigheter:

  • SELECT behörighet på basstabellerna som den materialiserade vyn refererar till.
  • USE CATALOG och USE SCHEMA behörigheter på katalogen och schemat som innehåller källtabellerna för den materialiserade vyn.
  • USE CATALOG och USE SCHEMA behörigheter i målkatalogen och schemat för den materialiserade vyn.
  • CREATE TABLE och CREATE MATERIALIZED VIEW behörigheter för schemat som innehåller den materialiserade vyn.

• Om du vill uppdatera en materialiserad vy måste du ha REFRESH behörighet på den materialiserade vyn.

• Din arbetsyta måste finnas i en region som stöder serverlösa SQL-lager.

Krav för att fråga materialiserade vyer:

• Du måste ha äganderätt till den materialiserade vyn eller ha SELECT på den materialiserade vyn, tillsammans med USE SCHEMA och USE CATALOG på dess föräldrar.

• Du måste använda någon av följande beräkningsresurser:

  • SQL-lager

  • Lakeflow deklarativa gränssnitt för pipelines

  • Beräkning av standardåtkomstläge (tidigare läge för delad åtkomst)

  • Dedikerat åtkomstläge (tidigare åtkomstläge för en enskild användare) på Databricks Runtime 15.4 och senare, så länge arbetsytan är aktiverad för serverlös beräkning. Se Detaljerad åtkomstkontroll för dedikerad beräkning.

    Om du är ägare till den materialiserade vyn kan du använda en beräkningsresurs för dedikerat åtkomstläge som kör Databricks Runtime mellan 14.3 och senare.

Mer information om andra begränsningar för användning av materialiserade vyer finns i Begränsningar.

Skapa en materialiserad vy

Databricks SQL-materialiserade vyåtgärder CREATE använder ett Databricks SQL-datalager för att skapa och ladda data i den materialiserade vyn. Att skapa en materialiserad vy är en synkron åtgärd, vilket innebär att CREATE MATERIALIZED VIEW kommandot blockeras tills den materialiserade vyn har skapats och den inledande databelastningen har slutförts. En serverlös pipeline skapas automatiskt för varje materialiserad vy i Databricks SQL. När den materialiserade vyn uppdateras bearbetas uppdateringen av Lakeflows deklarativa pipelines.

Om du vill skapa en materialiserad vy använder du -instruktionen CREATE MATERIALIZED VIEW . Om du vill skicka en create-instruktion använder du SQL-redigeraren i Azure Databricks-användargränssnittet, Databricks SQL CLI eller Databricks SQL API.

Den användare som skapar en materialiserad vy är ägare till den materialiserade vyn.

I följande exempel skapas den materialiserade vyn mv1 från bastabellen base_table1:

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

När du skapar en materialiserad vy med hjälp av -instruktionen CREATE OR REPLACE MATERIALIZED VIEW börjar den första datauppdateringen och populationen omedelbart. Detta förbrukar inte SQL Warehouse-beräkning. I stället används serverless Lakeflow Declarative Pipelines för skapande och efterföljande uppdateringar.

Kolumnkommentare i en bastabell sprids automatiskt till den nya materialiserade vyn endast vid skapande. Om du vill lägga till ett schema, tabellbegränsningar eller andra egenskaper ändrar du den materialiserade vydefinitionen (SQL-frågan).

Samma SQL-instruktion uppdaterar en materialiserad vy om den anropas en efterföljande tid eller enligt ett schema. En uppdatering som görs på det här sättet fungerar som alla andra uppdateringar. Mer information finns i Uppdatera en materialiserad vy.

Mer information om hur du konfigurerar en materialiserad vy finns i Konfigurera materialiserade vyer i Databricks SQL. Mer information om den fullständiga syntaxen för att skapa en materialiserad vy finns i CREATE MATERIALIZED VIEW. För att lära dig om hur du laddar data i olika format och från olika platser, se Ladda data med Lakeflows deklarativa pipelines.

Läsa in data från externa system

Databricks rekommenderar att du läser in externa data med Lakehouse Federation för datakällor som stöds. Information om hur du läser in data från källor som inte stöds av Lakehouse Federation finns i Alternativ för dataformat. För generell information om inläsning av data, inklusive exempel, se Ladda data med Lakeflows deklarativa pipelines.

Dölj känsliga data

Du kan använda materialiserade vyer för att dölja känsliga data från användare som kommer åt tabellen. Ett sätt att göra detta är att skapa frågan så att den inte innehåller dessa data i första hand. Men du kan också maskera kolumner eller filtrera rader baserat på behörigheterna för den frågande användaren. Du kan till exempel dölja tax_id kolumnen för användare som inte finns i gruppen HumanResourcesDept. Det gör du genom att använda syntaxen ROW FILTER och MASK när den materialiserade vyn skapas. Mer information finns i Radfilter och kolumnmasker.

Förnya en materialiserad vy

När du uppdaterar en materialiserad vy uppdateras vyn så att den återspeglar de senaste ändringarna i bastabellen vid tidpunkten för uppdateringen.

När du definierar en materialiserad vy används -instruktionen CREATE OR REPLACE MATERIALIZED VIEW både för att skapa vyn och för att uppdatera den för schemalagda uppdateringar. Du kan också använda -instruktionen REFRESH MATERIALIZED VIEW för att uppdatera den materialiserade vyn utan att behöva ange frågan igen. Se REFRESH (MATERIALIZED VIEW eller STREAMING TABLE) för mer information om SQL-syntaxen och parametrarna för det här kommandot. Mer information om de typer av materialiserade vyer som kan uppdateras stegvis finns i Inkrementell uppdatering för materialiserade vyer.

Om du vill skicka en uppdateringsinstruktor använder du SQL-redigeraren i Azure Databricks-användargränssnittet, en notebook-fil som är kopplad till ett SQL-lager, Databricks SQL CLI eller Databricks SQL API.

Ägaren och alla användare som har beviljats behörigheten REFRESH i tabellen kan uppdatera den materialiserade vyn.

I följande exempel uppdateras den mv1 materialiserade vyn:

REFRESH MATERIALIZED VIEW mv1;

Åtgärden är synkron som standard, vilket innebär att kommandot blockeras tills uppdateringsåtgärden har slutförts. Om du vill uppdatera asynkront kan du lägga till nyckelordet ASYNC :

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Hur uppdateras Databricks SQL-materialiserade vyer?

Materialiserade vyer skapar och använder automatiskt serverlösa deklarativa Lakeflow-pipelines för att bearbeta uppdateringsåtgärder. Uppdateringen hanteras av pipelinen och uppdateringen övervakas av Databricks SQL-lagret som används för att skapa den materialiserade vyn. Materialiserade vyer kan uppdateras med hjälp av en pipeline som körs enligt ett schema. Databricks SQL-skapade materialiserade vyer körs alltid i triggarläge. Se Triggad pipeline-läge kontra kontinuerligt läge.

Materialiserade vyer uppdateras med någon av två metoder.

• Inkrementell uppdatering – Systemet utvärderar vyns fråga för att identifiera ändringar som inträffade efter den senaste uppdateringen och sammanfogar endast nya eller ändrade data.
• Fullständig uppdatering – Om en inkrementell uppdatering inte kan utföras kör systemet hela frågan och ersätter befintliga data i den materialiserade vyn med de nya resultaten.

Frågans struktur och typen av källdata avgör om inkrementell uppdatering stöds. För att stödja inkrementell uppdatering bör källdata lagras i Delta-tabeller, med radspårning och ändringsdataflöde aktiverat. När du har skapat en materialiserad vy kan du övervaka dess uppdateringsbeteende för att kontrollera om den uppdateras stegvis eller via en fullständig uppdatering.

Mer information om uppdateringstyper och hur du optimerar för inkrementella uppdateringar finns i Inkrementell uppdatering för materialiserade vyer.

Asynkrona uppdateringar

Som standard utförs uppdateringsåtgärder synkront. Du kan också ange att en uppdateringsåtgärd ska ske asynkront. Detta kan anges med hjälp av uppdateringskommandot med nyckelordet ASYNC . Se REFRESH (MATERIALIZED VIEW eller STREAMING TABLE) Beteendet som är associerat med varje metod är följande:

• Synkron: En synkron uppdatering förhindrar att andra åtgärder fortsätter tills uppdateringen är klar. Om resultatet behövs för nästa steg, till exempel vid sekvensering av uppdateringsåtgärder i orkestreringsverktyg som Lakeflow-jobb, använder du en synkron uppdatering. Om du vill orkestrera materialiserade vyer med ett jobb använder du uppgiftstypen SQL. Se Lakeflow Jobs.
• Asynkron: En asynkron uppdatering startar ett bakgrundsjobb på Lakeflow Deklarativa Pipelines-beräkning när en materialiserad vyuppdatering börjar, vilket gör att kommandot kan återvända innan datainläsningen slutförs. Den här uppdateringstypen kan spara på kostnaden eftersom åtgärden inte nödvändigtvis innehåller beräkningskapacitet i det lager där kommandot initieras. Om uppdateringen blir inaktiv och inga andra aktiviteter körs kan lagret stängas av medan uppdateringen använder annan tillgänglig beräkning. Dessutom stöder asynkrona uppdateringar start av flera åtgärder parallellt.

Schemalägga materialiserade vyuppdateringar

Du kan konfigurera en materialiserad Databricks SQL-vy så att den uppdateras automatiskt baserat på ett definierat schema eller för att utlösa när överordnade data ändras.

Om du vill ange ett schema eller en utlösare gör du något av följande:

• Konfigurera schemat med satsen när du skapar den materialiserade vyn
• Konfigurera en utlösare med TRIGGER ON UPDATE -satsen när du skapar den materialiserade vyn.
• Lägg till eller ändra scheman eller utlösare med -instruktionen ALTER MATERIALIZED VIEW .

I följande exempel skapas den materialiserade vyn mv1 från bastabellen base_table1och ett schema för att uppdatera den materialiserade vyn en gång i timmen:

CREATE OR REPLACE MATERIALIZED VIEW mv1
  SCHEDULE EVERY 1 hour
  AS SELECT
    date,
    sum(sales) AS sum_of_sales
  FROM
    base_table1
  GROUP BY
    date;

Om du vill ange eller ändra schemat när du har skapat det använder du -instruktionen ALTER MATERIALIZED VIEW :

-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales ALTER TRIGGER ON UPDATE;

När ett schema skapas konfigureras ett nytt Databricks-jobb automatiskt för att bearbeta uppdateringen.

Om du vill visa schemat gör du något av följande:

• Kör -instruktionen DESCRIBE EXTENDED från SQL-redigeraren i Azure Databricks-användargränssnittet. Se även DESCRIBE TABLE.
• Använd Katalogutforskaren för att visa den materialiserade vyn. Schemat visas på fliken Översikt under Uppdateringsstatus. Se Vad är Katalogutforskaren?.

När det finns ett schema för uppdateringar har du fortfarande möjlighet att köra en manuell uppdatering när som helst, om du behöver uppdaterade data.

Stoppa en aktiv uppdatering

Om du vill stoppa en aktiv uppdatering i lakeflow-användargränssnittet för deklarativa pipelines klickar du på Stoppa på sidan Pipelineinformation för att stoppa pipelineuppdateringen. Du kan också stoppa uppdateringen med Databricks CLI eller ÅTGÄRDEN POST /api/2.0/pipelines/{pipeline_id}/stop i Pipelines-API:et.

Tidsgränser för uppdateringar

Långvariga uppdateringar kan överskrida tidsbegränsningen. Materialiserade vyer som skapats eller uppdaterats efter den 14 augusti 2025 använder tidsgränsen som är associerad med DET SQL-lager som används för att köra uppdateringen. Om lagret inte har en tidsgräns, används standardvärdet 2 dagar.

Du kan uttryckligen ange tidsgränsen med en STATEMENT_TIMEOUT konfiguration i din SQL för uppdateringen. Se även STATEMENT_TIMEOUT.

Ta bort poster permanent från en materialiserad vy med borttagningsvektorer aktiverade

För att fysiskt ta bort poster från den underliggande lagringen för en materialiserad vy med borttagningsvektorer aktiverade, till exempel för GDPR-efterlevnad, måste ytterligare åtgärder vidtas för att säkerställa att en VACUUM åtgärd körs på den materialiserade vyns data.

Så här tar du bort poster fysiskt:

1. Kör en REORG-instruktion mot den materialiserade vyn och ange parametern APPLY (PURGE). Till exempel REORG TABLE <materialized-view-name> APPLY (PURGE);. Se även REORG TABLE.
2. Vänta tills datakvarhållningsperioden för den materialiserade vyn har passerat. Standardperioden för datakvarhållning är sju dagar, men den kan konfigureras med egenskapen delta.deletedFileRetentionDuration tabell. Se Konfigurera datalagring för frågor rörande tidsresor.
3. REFRESH den materialiserad vy. Se även Uppdatera en materialiserad vy. Inom 24 timmar efter REFRESH åtgärden körs underhållsuppgifter för Lakeflow Declarative Pipelines, inklusive den VACUUM åtgärd som krävs för att säkerställa att poster tas bort permanent.

Ta bort en materialiserad vy

Om du vill ta bort en materialiserad vy använder du instruktionen DROP VIEW. Om du vill skicka en DROP instruktion kan du använda SQL-redigeraren i Azure Databricks-användargränssnittet, Databricks SQL CLI eller Databricks SQL API. I följande exempel tas den mv1 materialiserade vyn bort:

DROP MATERIALIZED VIEW mv1;

Du kan också använda Katalogutforskaren för att ta bort en materialiserad vy.

1. Klicka på Katalog i sidofältet.
2. Öppna katalogen i katalogutforskarens träd till vänster och välj det schema där den materialiserade vyn finns.
3. Öppna objektet Tables under det schema som du valde och klicka på den materialiserade vyn.
4. Välj Kebab menu icon.Ta bort på

Förstå kostnaderna för en materialiserad vy

Eftersom en materialiserad vy körs i serverlös beräkning, utanför den beräkning som du har konfigurerat för en notebook-fil eller ett jobb, kanske du undrar hur du ska förstå kostnaderna som är associerade med den. Materialiserad vyanvändning spåras av DBU-förbrukning. Mer information finns i Vad är DBU-förbrukningen för en materialiserad vy eller en strömmande tabell?

Aktivera radspårning

För att stöda inkrementella uppdateringar från Delta-tabeller måste radspårning aktiveras för dessa källtabeller. Om du återskapar en källtabell måste du återaktivera radspårning.

I följande exempel visas hur du aktiverar radspårning i en tabell:

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Mer information finns i Använda radspårning för Delta-tabeller

Begränsningar

• Krav för beräkning och arbetsyta finns i Krav.
• Stegvisa uppdateringskrav finns i Inkrementell uppdatering för materialiserade vyer.
• Materialiserade vyer stöder inte identitetskolumner eller surrogatnycklar.
• Om en materialiserad vy använder en summaaggregering över en NULL-kompatibel kolumn och endast NULL-värden finns kvar i den kolumnen, blir det materialiserade vyernas aggregerade värde noll istället för NULL.
• Du kan inte läsa ett ändringsdataflöde från en materialiserad vy.
• Förfrågningar om tidsresefrågor stöds inte i materialiserade vyer.
• De underliggande filerna som stöder materialiserade vyer kan innehålla data från överordnade tabeller (inklusive möjlig personligt identifierbar information) som inte visas i den materialiserade vydefinitionen. Dessa data läggs automatiskt till i den underliggande lagringen för att stödja inkrementell uppdatering av materialiserade vyer. Eftersom de underliggande filerna i en materialiserad vy kan riskera att exponera data från överordnade tabeller som inte ingår i det materialiserade vyschemat rekommenderar Databricks att inte dela den underliggande lagringen med obetrodda nedströmsanvändare. Anta till exempel att definitionen av en materialiserad vy innehåller en COUNT(DISTINCT field_a) -sats. Även om den materialiserade vydefinitionen endast innehåller aggregeringssatsen COUNT DISTINCT, kommer de underliggande filerna att innehålla en lista över de faktiska värdena av field_a.
• Du kan debiteras vissa serverlösa beräkningsavgifter, även när du använder dessa funktioner för dedikerad beräkning.

• Om du behöver använda en Azure Private Link-anslutning med din materialiserade vy ska du kontakta din Databricks-representant.

Få åtkomst till materialiserade vyer från externa klienter

Om du vill komma åt materialiserade vyer från externa Delta Lake- eller Iceberg-klienter som inte stöder öppna API:er kan du använda kompatibilitetsläge. Kompatibilitetsläget skapar en skrivskyddad (read-only) version av din materialiserade vy, som kan nås av alla Delta Lake- och Iceberg-klienter.

Relaterade artiklar

• Konfigurera materialiserade vyer i Databricks SQL
• Övervaka materialiserade vyer i Databricks SQL
• Använda strömmande tabeller i Databricks SQL