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
- Gränssnitt för Deklarativa pipelines för Lakeflow Spark
- 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 bearbetar pipelinen uppdateringen.

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 en serverlös pipeline för att skapa 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. Lär dig mer om hur du läser in data i olika format och från olika platser genom att se Läsa in data i pipelines.

Läsa in data från externa system

Materialiserade vyer kan skapas på 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. Allmän information om inläsning av data, inklusive exempel, finns i Läsa in data i 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 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 eller inte är kostnadseffektiv 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. Om du vill se om en fråga är inkrementell kan du använda Databricks SQL-instruktionen EXPLAIN CREATE MATERIALIZED VIEW . 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.

Som standard använder Azure Databricks en kostnadsmodell för att välja det mer kostnadseffektiva alternativet mellan fullständig och inkrementell uppdatering. Du kan åsidosätta det här beteendet genom att antingen föredra inkrementella eller fullständiga uppdateringar genom att ange en REFRESH POLICY i DIN SQL-definition av den materialiserade vyn.

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å serverlös beräkning när en materialiserad vyuppdatering påbörjas, vilket gör att kommandot kan returneras 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. I följande tabell visas de olika alternativen för att schemalägga uppdateringar.

Metod	Description	Exempel på användningsfall
Manuell	Uppdatering på begäran med hjälp av en SQL-instruktion `REFRESH` eller via arbetsytans användargränssnitt.	Utveckling, testning, ad hoc-uppdateringar.
`TRIGGER ON UPDATE`	Definiera den materialiserade vyn så att den uppdateras automatiskt när de överordnade data ändras.	Produktionsarbetsbelastningar med serviceavtal för dataaktualitet eller oförutsägbara uppdateringsperioder.
`SCHEDULE`	Definiera den materialiserade vyn som ska uppdateras med definierade tidsintervall.	Förutsägbara, tidsbaserade uppdateringskrav.
SQL-uppgift i ett jobb	Uppdateringen dirigeras via Lakeflow-jobb.	Komplexa pipelines med systemöverskridande beroenden.

Manuell uppdatering

Om du vill uppdatera en materialiserad vy manuellt kan du anropa en uppdatering från Databricks SQL eller använda arbetsytans användargränssnitt.

REFRESH uttalande

Så här uppdaterar du en pipeline med Databricks SQL:

I SQL-redigeraren kör du följande instruktion:
```
REFRESH MATERIALIZED VIEW <mv-name>;
```

Mer information finns i REFRESH (MATERIALIZED VIEW eller STREAMING TABLE).

Användargränssnitt för arbetsutrymme

Så här uppdaterar du en pipeline i arbetsytans användargränssnitt:

På Azure Databricks-arbetsytan klickar du på Jobb och pipelines.
Välj den pipeline som du vill uppdatera från listan.
Klicka på startknappen .

När pipelinen uppdateras visas uppdateringar i användargränssnittet.

Utlösare vid uppdatering

TRIGGER ON UPDATE Satsen uppdaterar automatiskt en materialiserad vy när överordnade källdata ändras. Detta eliminerar behovet av att samordna scheman mellan pipelines. Den materialiserade vyn förblir fräsch utan att användaren behöver veta när överordnade jobb slutförs eller underhåller komplex schemaläggningslogik.

Det här är den rekommenderade metoden för produktionsarbetsbelastningar, särskilt när överordnade beroenden inte körs enligt förutsägbara scheman. När den materialiserade vyn har konfigurerats övervakar den sina källtabeller och uppdateras automatiskt när ändringar i någon av de överordnade källorna identifieras.

Begränsningar

Överordnade beroendegränser: En materialiserad vy kan övervaka högst 10 överordnade tabeller och 30 överordnade vyer. Om du vill ha fler beroenden delar du upp logiken i flera materialiserade vyer.
Begränsningar för arbetsytor: Högst 1 000 materialiserade vyer med TRIGGER ON UPDATE kan finnas per arbetsyta. Kontakta Databricks-supporten om mer än 1 000 materialiserade vyer behövs.
Minsta intervall: Det minsta utlösarintervallet är 1 minut.

I följande exempel visas hur du anger en utlösare vid uppdatering när du definierar en materialiserad vy.

Skapa en materialiserad vy med utlösare vid uppdatering

Om du vill skapa en materialiserad vy som uppdateras automatiskt när källdata ändras tar du med TRIGGER ON UPDATE satsen i -instruktionen CREATE MATERIALIZED VIEW .

I följande exempel skapas en materialiserad vy som aggregerar kundbeställningar och uppdateras när customers- eller orders-tabellerna uppdateras:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Uppdateringsfrekvens för strypning

Om överordnade data uppdateras ofta kan du använda AT MOST EVERY för att begränsa hur ofta vyn uppdateras och begränsa beräkningskostnaderna. Detta är användbart när källtabeller uppdateras ofta, men nedströmskonsumenter inte behöver realtidsdata. Nyckelordet INTERVAL krävs före tidsvärdet.

I följande exempel begränsas den materialiserade vyn till att uppdateras högst var femte minut, även om källdata ändras oftare:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Schemalagd uppdatering

Uppdateringsscheman kan definieras direkt i den materialiserade vydefinitionen för att uppdatera vyn med fasta tidsintervall. Den här metoden är användbar när datauppdateringens takt är känd och förutsägbar uppdateringstid är önskad.

När det finns ett uppdateringsschema kan du fortfarande köra en manuell uppdatering när som helst om du behöver uppdaterade data.

Databricks stöder två schemaläggningssyntaxer: SCHEDULE EVERY för enkla intervall och SCHEDULE CRON för exakt schemaläggning. Nyckelorden SCHEDULE och SCHEDULE REFRESH är semantiskt likvärdiga.

Mer information om syntaxen och användningen av -satsen finns i SCHEDULECREATE MATERIALIZED VIEW SCHEDULE-satsen.

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?.

I följande exempel visas hur du skapar en materialiserad vy med ett schema:

Schemalägg varje tidsintervall

I det här exemplet schemaläggs en uppdatering en gång i timmen:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

Schemalägg med cron

I det här exemplet schemaläggs en uppdatering var 15:e minut, efter en kvart i UTC-tidszonen:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

SQL-uppgift i ett jobb

Materialiserade vyuppdateringar kan dirigeras via Databricks-jobb genom att skapa SQL-uppgifter som innehåller REFRESH MATERIALIZED VIEW kommandon. Den här metoden integrerar materialiserade vyuppdateringar i befintliga arbetsflöden för jobborkestrering.

Det finns två sätt att skapa ett jobb för att uppdatera materialiserade vyer:

Från SQL-redigeraren: Skriv REFRESH MATERIALIZED VIEW kommandot och klicka på knappen Schema för att skapa ett jobb direkt från frågan.
Från jobbgränssnittet: Skapa ett nytt jobb, lägg till en SQL-aktivitetstyp och bifoga en SQL-fråga eller notebook-fil med REFRESH MATERIALIZED VIEW kommandot .

I följande exempel visas SQL-instruktionen i en SQL-uppgift som uppdaterar en materialiserad vy:

REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

Den här metoden är lämplig när:

Komplexa pipelines i flera steg har beroenden mellan olika system.
Integrering med befintlig jobborkestrering krävs.
Aviseringar och övervakning på jobbnivå krävs.

SQL-uppgifter använder både SQL-datalager som är kopplat till jobbet och den serverlösa beräkningen som kör uppdateringen. Om schemaläggning baserad på materialiserad vydefinition uppfyller kraven, kan du växla till TRIGGER ON UPDATE eller SCHEDULE för att förenkla arbetsflödet.

Lägga till ett schema i en befintlig materialiserad vy

Om du vill ange 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
  ADD TRIGGER ON UPDATE;

Ändra ett befintligt schema eller en utlösare

Om en materialiserad vy redan har ett schema eller en utlösare associerad, använd ALTER SCHEDULE eller ALTER TRIGGER ON UPDATE för att ändra uppdateringskonfigurationen. Detta gäller oavsett om du ändrar från ett schema till ett annat, en utlösare till en annan eller växlar mellan ett schema och en utlösare.

I följande exempel ändras ett befintligt schema för uppdatering var fjärde timme:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

Ta bort ett schema eller en utlösare

Om du vill ta bort ett schema använder du ALTER ... DROP:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

Stoppa en aktiv uppdatering

Om du vill stoppa en aktiv uppdatering i Azure Databricks-användargränssnittet går du till sidan Pipelineinformation och klickar på Stoppa 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

Materialiserade vyuppdateringar körs med en tidsgräns som begränsar hur länge de kan köras. För materialiserade vyer som skapats eller uppdaterats på eller efter den 14 augusti 2025 registreras tidsgränsen när du uppdaterar genom att köra CREATE OR REFRESH:

Om en STATEMENT_TIMEOUT anges används det värdet. Se även STATEMENT_TIMEOUT.
Annars används tidsgränsen från SQL-lagret som används för att köra kommandot.
Om informationslagret inte har en tidsgräns konfigurerad gäller standardvärdet 2 dagar.

Tidsgränsen används vid den första skapande, men även vid schemalagda uppdateringar som följer.

För materialiserade vyer som senast uppdaterades före den 14 augusti 2025 är tidsgränsen inställd på 2 dagar.

Exempel: Ange en tidsgräns för en materialiserad vyuppdatering Du kan uttryckligen styra hur länge en materialiserad vyuppdatering tillåts köras genom att ange en tidsgräns på instruktionsnivå när du skapar eller uppdaterar vyn:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Detta konfigurerar den materialiserade vyn som ska uppdateras var 12:e timme, och om en uppdatering tar mer än 6 timmar överskrider den tidsgränsen och väntar på nästa schemalagda uppdatering.

Så hanterar schemalagda uppdateringar tidsgränser

Tidsgränser synkroniseras endast när du uttryckligen kör CREATE OR REFRESH.

Schemalagda uppdateringar fortsätter att nyttja den tidsgräns som registrerats under den senaste CREATE OR REFRESH.
Att enbart ändra tidsgränsen för datamagasinet påverkar inte befintliga schemalagda uppdateringar.

Viktigt!

När du har ändrat tidsgränsen för ett lager kör du CREATE OR REFRESH igen för att tillämpa den nya tidsgränsen på framtida schemalagda uppdateringar.

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

Viktigt!

Stöd för REORG-instruktionen med materialiserade vyer finns i offentlig testversion.

Anmärkning

Användning av en REORG-instruktion med en materialiserad vy kräver Databricks Runtime 15.4 eller senare.
Även om du kan använda -instruktionen REORG med valfri materialiserad vy krävs den bara när du tar bort poster från en materialiserad vy med borttagningsvektorer aktiverade. Kommandot har ingen effekt när det används med en materialiserad vy utan att borttagningsvektorer har aktiverats.

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:

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.
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.
REFRESH den materialiserad vy. Se även Uppdatera en materialiserad vy. Inom 24 timmar efter REFRESH-åtgärden körs pipelineunderhållsuppgifter automatiskt, inklusive VACUUM-åtgärden som krävs för att säkerställa att poster tas bort permanent.

Ta bort en materialiserad vy

Anmärkning

Om du vill skicka kommandot för att släppa en materialiserad vy måste du vara ägare till den materialiserade vyn eller ha MANAGE behörighet i den materialiserade vyn.

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.

Klicka på Katalog i sidofältet.
Öppna katalogen i katalogutforskarens träd till vänster och välj det schema där den materialiserade vyn finns.
Öppna objektet Tables under det schema som du valde och klicka på den materialiserade vyn.
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 Radspårning i Databricks

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.

Feedback

Var den här sidan hjälpsam?

Last updated on 2026-02-04