Dela via

Använda materialiserade vyer i Databricks SQL

  • Artikel

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

Kommentar

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

Viktigt!

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

Vad är materialiserade vyer?

I Databricks SQL är materialiserade vyer hanterade Unity Catalog-tabeller som gör det möjligt för användare att förberäkna resultat baserat på den senaste versionen av data i källtabeller. Materialiserade vyer på Azure Databricks skiljer sig från andra implementeringar eftersom resultaten som returneras återspeglar datatillståndet när den materialiserade vyn senast uppdaterades i stället för att alltid uppdatera resultat när den materialiserade vyn efterfrågas. Du kan uppdatera materialiserade vyer manuellt eller schemalägga uppdateringar.

Materialiserade vyer är kraftfulla 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 minskar kostnaderna och förbättrar svarstid för frågor genom att förberäkna långsamma frågor och ofta använda beräkningar. Materialiserade vyer möjliggör också enkla transformeringar genom att rensa, berika och avnormalisera bastabeller. Materialiserade vyer kan minska kostnaderna samtidigt som de ger en förenklad slutanvändarupplevelse eftersom de i vissa fall kan beräkna ändringar stegvis från bastabellerna.

Materialiserade vyer stöddes först i Azure Databricks med lanseringen av DLT-. När du skapar en materialiserad vy i ett Databricks SQL-lager skapas en serverlös pipeline för att bearbeta uppdateringar till den materialiserade vyn. Du kan övervaka status för uppdateringsåtgärder i DLT-användargränssnittet eller i pipelines-API:t . Se Visa status för en materialiserad vyuppdatering.

Krav

Så här skapar eller uppdaterar du 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 fråga om materialiserade vyer:

  • Du måste vara ägare 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
    • DLT-gränssnitt
    • 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 dedikerade datorresurser (tidigare enanvändarberäkning).
    • Endast om du är ägare av materialiserad vy: en dedikerad åtkomstlägesberäkningsresurs som kör Databricks Runtime mellan 14.3 och 15.3.

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-lager för att skapa och läsa in 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 DLT-pipeline skapas automatiskt för varje Databricks SQL-materialiserad vy. När den materialiserade vyn uppdateras hanterar DLT-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.

Kommentar

Den användare som skapar en materialiserad vy är ägare till den materialiserade vyn och måste ha följande behörigheter:

  • SELECT behörighet för de bastabeller som refereras till av den materialiserade vyn.
  • 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.

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

CREATE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Kolumnkommentarer i en grundtabell sprids automatiskt till den nya materialiserade vyn. Om du vill lägga till ett schema, tabellbegränsningar eller andra egenskaper ändrar du den materialiserade vydefinitionen. För att lära dig mer om syntax för att definiera en materialiserad vy, se CREATE MATERIALIZED VIEW.

Ange körningskanalen

Materialiserade vyer som skapats med SQL-lager uppdateras automatiskt med hjälp av en DLT-pipeline. DLT-pipelines använder körning i current-kanalen som standard. Se versionsinformation om DLT och uppgraderingsprocessen för releaser för att lära dig mer om releaser.

Databricks rekommenderar att du använder current kanalen för produktionsarbetsbelastningar. Nya funktioner släpps först till preview kanalen. Du kan ange en pipeline till DLT-förhandsgranskningskanalen för att testa nya funktioner genom att ange preview som en tabellegenskap. Du kan ange den här egenskapen när du skapar tabellen eller när tabellen har skapats med hjälp av en ALTER-instruktion.

I följande kodexempel visas hur du ställer in kanalen som förhandsversion i en CREATE-instruktion:

CREATE OR REPLACE MATERIALIZED VIEW foo.default.bar
TBLPROPERTIES ('pipelines.channel' = 'preview') as
SELECT
  *
FROM
  range(5)

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.

Uppdatera en materialiserad vy

Åtgärden REFRESH uppdaterar den materialiserade vyn så att den återspeglar de senaste ändringarna i bastabellen. Åtgärden är synkron som standard, vilket innebär att kommandot blockeras tills uppdateringsåtgärden har slutförts. Om du vill uppdatera en materialiserad vy använder du -instruktionen REFRESH MATERIALIZED VIEW . 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.

Endast ägaren kan REFRESH den materialiserade vyn.

I följande exempel uppdateras den mv1 materialiserade vyn:

REFRESH MATERIALIZED VIEW mv1;

Hur uppdateras Databricks SQL-materialiserade vyer?

Materialiserade vyer skapar och använder automatiskt serverlösa DLT-pipelines för att bearbeta uppdateringsåtgärder. Uppdateringen hanteras av DLT-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 DLT-pipeline som körs enligt ett schema. Se Triggad pipeline-läge kontra kontinuerligt läge.

Kommentar

DLT-körningen kan inte identifiera ändringar i datakällor som inte är Delta. Tabellen uppdateras fortfarande regelbundet, men med ett högre standardutlösarintervall för att förhindra att överdriven ombearbetning saktar ned inkrementell bearbetning vid beräkning.

Som standard utförs uppdateringsåtgärder synkront. Du kan också ange att en uppdateringsåtgärd ska ske asynkront. Detta kan ställas in med hjälp av uppdateringskommandot. 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 Databricks-jobb, använder du en synkron uppdatering. Om du vill orkestrera materialiserade vyer med ett jobb använder du uppgiftstypen SQL. Se Översikt över orkestrering på Databricks.
  • Asynkron: En asynkron uppdatering startar ett bakgrundsjobb på DLT-beräkningen när en materialiserad vyuppdatering börjar, 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.

Vissa frågor kan uppdateras stegvis. Se Inkrementell uppdatering för materialiserade vyer. Om det inte går att utföra en inkrementell uppdatering utförs en fullständig uppdatering i stället.

Schemalägga materialiserade vyuppdateringar

Du kan konfigurera en materialiserad Databricks SQL-vy så att den uppdateras automatiskt baserat på ett definierat schema. Gör något av följande för att ange ett schema:

  • Konfigurera schemat med satsen när du skapar den materialiserade vyn
  • Lägg till ett schema med instruktionen ALTER MATERIALIZED VIEW.

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.
  • Använd Katalogutforskaren för att visa den materialiserade vyn. Schemat visas på fliken Översikt under Uppdateringsstatus. Se Vad är Katalogutforskaren?.

Visa status för en materialiserad vyuppdatering

Anteckning

Eftersom en DLT-pipeline hanterar uppdateringar av materialiserade vyer uppstår det en fördröjning orsakad av uppstartstiden för pipelinen. Den här tiden kan vara i sekunder till minuter, förutom den tid som krävs för att utföra uppdateringen.

Du kan visa status för en materialiserad vyuppdatering genom att visa pipelinen som hanterar den materialiserade vyn i DLT-användargränssnittet eller genom att visa Uppdatera information som returneras av kommandot DESCRIBE EXTENDED för den materialiserade vyn.

Du kan också visa uppdateringshistoriken för en materialiserad vy genom att fråga i DLT-händelseloggen. Se även Visa uppdateringshistoriken för en materialiserad vy.

Övervaka körningar med hjälp av frågehistorik

Du kan använda sidan för frågehistorik för att få åtkomst till frågeinformation och frågeprofiler som kan hjälpa dig att identifiera frågor och flaskhalsar som fungerar dåligt i DLT-pipelinen som används för att köra uppdateringar av strömningstabellen. En översikt över vilken typ av information som är tillgänglig för frågehistorik och frågeprofiler finns i Frågehistorik och Frågeprofil.

Viktigt!

Den här funktionen finns som allmänt tillgänglig förhandsversion. Arbetsyteadministratörer kan aktivera den här funktionen från sidan Förhandsversioner . Se Hantera Förhandsversioner av Azure Databricks.

Alla uttryck som rör materialiserade vyer visas i frågehistoriken. Du kan använda listrutefiltret Uttalande för att välja ett kommando och granska relaterade sökfrågor. Alla CREATE-instruktioner följs av en REFRESH-instruktion som körs asynkront på en DLT-pipeline. Instruktionerna REFRESH innehåller vanligtvis detaljerade frågeplaner som ger insikter om hur du optimerar prestanda.

Använd följande steg för att komma åt REFRESH instruktioner i användargränssnittet för frågehistorik:

  1. Klicka Historikikon i det vänstra sidofältet för att öppna användargränssnittet för frågehistorik .
  2. Markera kryssrutan REFRESH från filterlistrutan Statement.
  3. Klicka på namnet på frågeuttrycket för att visa sammanfattningsinformation som frågans varaktighet och aggregerade mått.
  4. Klicka på Se frågeprofil för att öppna frågeprofilen. Mer information om hur du navigerar i frågeprofilen finns i Frågeprofil.
  5. Du kan också använda länkarna i avsnittet Frågekälla för att öppna den relaterade frågan eller pipelinen.

Se CREATE MATERIALIZED VIEW.

Visa uppdateringsstatusen i DLT-användargränssnittet

Som standard visas inte DLT-pipelinen som hanterar en materialiserad vy i DLT-användargränssnittet. Om du vill visa pipelinen i DLT-användargränssnittet måste du komma åt länken direkt till pipelinens Pipeline-information sidan. Så här öppnar du länken:

  • Kopiera och klistra in länken som visas i raden Senaste uppdatering i tabellen som returneras av deklarationen DESCRIBE EXTENDED.
  • På fliken härstamning för den materialiserade vyn klickar du på Pipelines och sedan på pipelinelänken.

För asynkrona REFRESH kommandon som skickas med SQL-redigeraren i Azure Databricks-användargränssnittet kan du visa uppdateringsstatusen genom att följa länken som visas i resultatpanelen .

Stoppa en aktiv uppdatering

För att stoppa en aktiv uppdatering i DLT-användargränssnittet klickar du på Stoppa på sidan Detaljer om pipeline 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.

Uppdatera definitionen av en materialiserad vy

Om du vill uppdatera definitionen av en materialiserad vy måste du först släppa och sedan återskapa den materialiserade vyn.

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.

Kommentar

  • Användning av en REORG-instruktion med en materialiserad vy kräver Databricks Runtime 15.4 eller senare.
  • Även om du kan använda REORG-instruktionen 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.

Följande beskriver de här stegen mer detaljerat:

  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 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 även Konfigurera datakvarhållning för frågor relaterade till tidsresor.
  3. REFRESH den materialiserad vy. Se även Uppdatera en materialiserad vy. Inom 24 timmar efter den REFRESH åtgärden körs DLT-underhållsaktiviteter, inklusive den VACUUM åtgärd som krävs för att säkerställa att poster tas bort permanent. Se Underhållsaktiviteter som utförs av DLT.

Ta bort en materialiserad vy

Kommentar

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;

Beskriv en materialiserad vy

Om du vill hämta kolumner och datatyper för en materialiserad vy använder du -instruktionen DESCRIBE . Om du vill hämta kolumner, datatyper och metadata som ägare, plats, skapandetid och uppdateringsstatus för en materialiserad vy använder du DESCRIBE EXTENDED. Om du vill skicka en DESCRIBE instruktion använder du SQL-redigeraren i Azure Databricks-användargränssnittet, Databricks SQL CLI eller Databricks SQL API.

Ändra ägare till en materialiserad vy

Du kan ändra ägaren till en materialiserad vy om du är både metaarkivadministratör och arbetsyteadministratör. Materialiserade vyer skapar och använder automatiskt DLT-pipelines för att bearbeta ändringar. Använd följande steg för att ändra ägare av materialiserade vyer:

  • På fliken härledning för den materialiserade vyn klickar du på Pipelines och sedan på pipelinelänken.
  • Klicka på Dela. Dialogrutan Behörighetsinställningar visas.
  • Klicka på x till höger om den aktuella ägarens namn för att ta bort den aktuella ägaren.
  • Börja skriva för att filtrera listan över tillgängliga användare. Klicka på den användare som ska vara den nya pipelineägaren.
  • Klicka på Spara för att spara ändringarna och stäng dialogrutan.

Alla pipelinetillgångar, inklusive materialiserade vyer som definierats i pipelinen, ägs av den nya pipelineägaren. Alla framtida uppdateringar körs med den nya ägarens identitet.

Kontrollera åtkomsten till materialiserade vyer

Materialiserade vyer har stöd för omfattande åtkomstkontroller för att stödja datadelning och samtidigt undvika att exponera potentiellt privata data. En ägare av en materialiserad vy eller en användare med MANAGE-behörighet kan bevilja SELECT-behörigheter till andra användare. Användare med SELECT åtkomst till den materialiserade vyn behöver SELECT inte åtkomst till tabellerna som refereras av den materialiserade vyn. Den här åtkomstkontrollen möjliggör datadelning samtidigt som åtkomsten till underliggande data kontrolleras.

Bevilja behörigheter till en materialiserad vy

Om du vill bevilja åtkomst till en materialiserad vy använder du -instruktionen GRANT :

GRANT
  privilege_type [, privilege_type ] ...
  ON <mv_name> TO principal;

Privilege_type kan vara:

  • SELECT – användaren kan SELECT den materialiserade vyn.
  • REFRESH – användaren kan REFRESH den materialiserade bilden. Uppdateringar körs med ägarens behörigheter.

I följande exempel skapas en materialiserad vy och en användare får behörighet att välja och uppdatera:

CREATE MATERIALIZED VIEW <mv_name> AS SELECT * FROM <base_table>;
GRANT SELECT ON <mv_name> TO user;
GRANT REFRESH ON <mv_name> TO user;

Återkalla privilegier från en materialiserad vy

Om du vill återkalla åtkomst från en materialiserad vy använder du -instruktionen REVOKE :

REVOKE
  privilege_type [, privilege_type ]
  ON <name> FROM principal;

När SELECT behörigheter på en bastabell återkallas från den materialiserade vyägaren eller någon annan användare som har beviljats MANAGE eller SELECT behörigheter på den materialiserade vyn, eller när bastabellen tas bort, kan den materialiserade vyägaren eller en användare som har beviljats åtkomst fortfarande köra frågor mot den materialiserade vyn. Följande beteende inträffar dock:

  • Den materialiserade vyägaren eller andra som har förlorat åtkomsten till en materialiserad vy kan inte längre REFRESH den, och den materialiserade vyn kommer att bli inaktuell.
  • Om det automatiseras med ett schema, misslyckas nästa planerade REFRESH eller körs inte.

I följande exempel återkallas behörigheten SELECT från mv1:

REVOKE SELECT ON mv1 FROM user1;

Aktivera ändringsdataflöde

Ändringsdataflöde krävs i bastabellerna för materialiserade vyer, förutom för vissa avancerade användningsfall. Om du vill aktivera ändringsdataflöde i en bastabell anger du tabellegenskapen delta.enableChangeDataFeed med hjälp av följande syntax:

ALTER TABLE table1 SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

Visa uppdateringshistoriken för en materialiserad vy

Om du vill visa status för REFRESH åtgärder i en materialiserad vy, inklusive aktuella och tidigare uppdateringar, frågar du DLT-händelseloggen:

SELECT
  *
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = "update_progress"
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 DLT-händelseloggen?.

Få detaljerad information om materialiserade vyer med Catalog Explorer

Du kan använda Catalog Explorer för att visa information om en materialiserad vy.

  1. Klicka på katalogikonenCatalog 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.

Härifrån kan du använda flikarna under det materialiserade vynamnet för att visa och redigera information om den materialiserade vyn, inklusive:

  • Uppdatera status och historik
  • Tabellschemat
  • Exempeldata (kräver en aktiv beräkning)
  • Behörigheter
  • Härledning, inklusive tabeller och pipelines som denna materialiserade vy är beroende på
  • Insikter om användning
  • Övervakare som du har skapat för den här materialiserade vyn

Begränsningar

  • Krav för beräkning och arbetsyta finns i Krav.
  • 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.