Använda materialiserade vyer i Databricks SQL

Den här sidan 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 MATERIALIZED VIEW behörighet för det schema som innehåller den materialiserade vyn.
  • Pipelines som använder äldre publiceringsläge kräver också behörigheten CREATE TABLE .

• 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 UI, Databricks SQL CLI eller Databricks SQL API.

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

Ad hoc materialiserad vy

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;

Materialiserad vy på utlösaren

I följande exempel skapas en materialiserad vy som uppdateras automatiskt när de överordnade källdata ändras med .TRIGGER ON UPDATE Använd den här metoden för produktionsarbetsbelastningar, särskilt när överordnade beroenden inte körs enligt förutsägbara scheman.

-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
  TRIGGER ON UPDATE
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Schemalagd materialiserad vy

I följande exempel skapas en materialiserad vy med ett dagligt CRON-uppdateringsschema vid midnatt UTC. Uttryck och aggregeringar i SELECT -satsen måste använda alias. GROUP BY kolumnreferenser kräver inte alias.

-- Refresh nightly at midnight UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
  SCHEDULE CRON '0 0 0 * * ?' AT TIME ZONE 'UTC'
AS SELECT
  date_trunc('day', order_time) AS sales_date,
  region,
  sum(revenue) AS total_revenue,
  count(*) AS order_count
FROM
  orders
GROUP BY sales_date, region;

Fler schemaläggningsalternativ, inklusive SCHEDULE EVERY syntax och ytterligare CRON-exempel, finns i Schemalägg uppdateringar i Databricks SQL.

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. Se Hur uppdateras Databricks SQL-materialiserade vyer?.

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 ett senare tillfälle eller körs 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 ett uppdateringsuttryck använder du SQL-redigeraren i Azure Databricks-användargränssnittet, en notebook som är kopplad till ett SQL-datavarhus, 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;

Information om hur du schemalägger en uppdatering finns i Schemalägg uppdateringar i Databricks SQL.

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.

Schemalagda uppdateringar kan ha uppdateringsmeddelanden och du kan ange prestandaläget för uppdateringen.

Inkrementell uppdatering

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.

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

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

När du kör CREATE MATERIALIZED VIEW eller REFRESH MATERIALIZED VIEW skapar och kör Azure Databricks automatiskt en serverlös pipeline för att bearbeta åtgärden. Den här pipelinen är oberoende av Databricks SQL-informationslagret eller beräkningsresursen som du skickade kommandot från. Klusterstorleken för ditt lager begränsar inte den beräkning eller kostnad som används av uppdateringen.

• Uppdateringspipelin körs på serverlös beräknings, som faktureras som serverlös Lakeflow Spark-deklarativa-pipelines-DBU:er.
• Den serverlösa pipelinen är separat från ditt lager. Beräkning från ditt lager används bara för att samordna åtgärden, inte för att utföra databearbetningen.
• Kostnaden skalar med mängden data som bearbetas, inte storleken på ditt SQL-lager.
• Om du vill övervaka kostnader för materialiserad vyuppdatering använder du systemtabeller. Se Vad är DBU-förbrukningen för en materialiserad vy eller en strömmande tabell?.
• Så här visar du den underliggande pipelinen som hanterar den materialiserade vyn:
  1. Klicka på Jobb & Pipelines i det vänstra sidofältet på din Azure Databricks-arbetsyta.
  2. Klicka på Pipelinetyp. Välj sedan MV/ST Pipeline för att se materialiserade vyer som skapats i Databricks SQL.

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 innehåller de underliggande filerna en lista över de faktiska värdena field_aför .
• 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 till din materialiserade vy kontaktar du 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