Använda materialiserade vyer i Databricks SQL

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 kontaktar du din Databricks-representant.

Viktigt!

Materialiserade vyer som skapats i Databricks SQL backas upp av en serverlös Delta Live Tables-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 frågefördröjningen genom långsamma frågor före databehandling och ofta använda beräkningar. Materialiserade vyer möjliggör också lätthanterade 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 Delta Live Tables. 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 Delta Live Tables-användargränssnittet eller pipelines-API :et. 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.

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

Så här frågar du 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
  • Delta Live Tables-gränssnitt
  • Beräkning av läget för delad åtkomst
  • Åtkomstläge för en 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 beräkning av en användare.
  • Endast om du är ägare till den materialiserade vyn: en beräkningsresurs för enkel användaråtkomst 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 Delta Live Tables-pipeline skapas automatiskt för varje materialiserad Databricks SQL-vy. När den materialiserade vyn uppdateras bearbetar Delta Live Tables-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 i 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 HJÄLP av SQL-lager uppdateras automatiskt med hjälp av en Delta Live Tables-pipeline. Delta Live Tables-pipelines använder körningen current i kanalen som standard. Mer information om lanseringsprocessen finns i Viktig information om Delta Live Tables och versionsuppgraderingsprocessen .

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 förhandsgranskningskanalen Delta Live Tables för att testa nya funktioner genom att preview ange 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 Delta Live Tables-pipelines för att bearbeta uppdateringsåtgärder. Uppdateringen hanteras av Delta Live Tables-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 Delta Live Tables-pipeline som körs enligt ett schema. Se Utlöses jämfört med kontinuerligt pipelineläge.

Kommentar

Delta Live Tables-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 SQL-aktivitetstypen. Se Översikt över orkestrering på Databricks.
• Asynkron: En asynkron uppdatering startar ett bakgrundsjobb på Delta Live Tables-beräkningen 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.

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

Kommentar

Eftersom en Delta Live Tables-pipeline hanterar materialiserade visningsuppdateringar uppstår svarstid för starttiden 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 Delta Live Tables-användargränssnittet eller genom att visa uppdateringsinformationen DESCRIBE EXTENDED som returneras av kommandot för den materialiserade vyn.

Du kan också visa uppdateringshistoriken för en materialiserad vy genom att fråga händelseloggen Delta Live Tables. Se 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 pipelinen Delta Live Tables som används för att köra dina uppdateringar av strömmande tabeller. 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 instruktioner som rör materialiserade vyer visas i frågehistoriken. Du kan använda listrutefiltret Instruktion för att välja valfritt kommando och granska relaterade frågor. Alla CREATE instruktioner följs av en REFRESH instruktion som körs asynkront på en Delta Live Tables-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 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 Delta Live Tables-användargränssnittet

Som standard visas inte Delta Live Tables-pipelinen som hanterar en materialiserad vy i användargränssnittet för Delta Live Tables. Om du vill visa pipelinen i Delta Live Tables-användargränssnittet måste du direkt komma åt länken till pipelinens informationssida för pipeline . Så här öppnar du länken:

• Kopiera och klistra in länken som visas på raden Senaste uppdatering i tabellen som returneras av -instruktionenDESCRIBE EXTENDED.
• På fliken ursprung 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

Om du vill stoppa en aktiv uppdatering i Delta Live Tables-användargränssnittet 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.

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.

Släppa 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 släpps den mv1 materialiserade vyn:

DROP MATERIALIZED VIEW mv1;

Beskriva 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 Delta Live Tables-pipelines för att bearbeta ändringar. Använd följande steg för att ändra ägare av materialiserade vyer:

• På fliken ursprung 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 vyn. 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 materialiserade vyn, och den materialiserade vyn blir inaktuell.
• Om det automatiseras med ett schema misslyckas eller körs inte nästa schemalagda REFRESH schema.

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 REFRESH för åtgärder i en materialiserad vy, inklusive aktuella och tidigare uppdateringar, frågar du händelseloggen Delta Live Tables:

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 händelseloggen Delta Live Tables?.

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 summamängd över en NULL-able-kolumn och endast NULL värden finns kvar i den kolumnen, är det materialiserade vyernas resulterande aggregeringsvärde NULLnoll i stället för .
• 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 .