Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Precis som standardvyer är materialiserade vyer resultatet av en fråga och du kommer åt dem på samma sätt som du gör med en tabell. Till skillnad från standardvyer, som omkomputerar resultat för varje fråga, cachelagras resultaten i materialiserade vyer och uppdateras med ett angivet intervall. Eftersom en materialiserad vy är förberäknad kan sökfrågor mot den köras mycket snabbare än mot vanliga vyer.
Mer information om när du ska använda materialiserade vyer jämfört med strömmande tabeller eller vyer finns i Vad är pipelines?.
En materialiserad vy är ett deklarativt pipelineobjekt. Den innehåller en fråga som definierar den, ett flöde för att uppdatera den och cachelagrade resultat för snabb åtkomst. En materialiserad syn
- Spårar ändringar i överordnade data.
- Vid utlösaren bearbetar inkrementellt ändrade data och tillämpar de nödvändiga omvandlingarna.
- Underhåller utdatatabellen, synkroniserad med källdata, baserat på ett angivet uppdateringsintervall.
Materialiserade vyer är ett bra val för många transformeringar:
- Du tillämpar resonemang över cachelagrade resultat i stället för rader. I själva verket skriver du bara en fråga.
- De är alltid korrekta vid tidpunkten för uppdateringen. Alla nödvändiga data bearbetas, även om de kommer sent eller i oordning.
- De är ofta inkrementella. Databricks försöker välja lämplig strategi som minimerar kostnaden för att uppdatera en materialiserad vy.
Så här fungerar materialiserade vyer
Följande diagram visar hur materialiserade vyer fungerar.
Materialiserade vyer definieras och uppdateras av en enda pipeline. Du kan uttryckligen definiera materialiserade vyer i pipelinens källkod. Tabeller som definieras av en pipeline kan inte ändras eller uppdateras av någon annan pipeline.
Note
När du skapar en fristående materialiserad vy utanför Lakeflow Spark Declarative Pipelines skapar Azure Databricks en pipeline som används för att uppdatera vyn. Du kan se pipelinen genom att välja ETL. Fristående materialiserade vyer är av typen MV/ST. Se Användning av fristående materialiserade vyer.
Databricks använder Unity Catalog för att lagra metadata om vyn, inklusive frågan och ytterligare systemvyer för inkrementella uppdateringar. Databricks materialiserar cachelagrade data i molnlagring.
Note
Databricks skapar interna tabeller för att stödja materialiserad inkrementell uppdatering av vyn. Dessa tabeller visas i system.information_schema.tables men visas inte i Katalogutforskaren eller andra arbetsytegränssnittsytor.
I följande exempel sammanfogas två tabeller och resultatet hålls uppdaterat med hjälp av en materialiserad vy.
Python
from pyspark import pipelines as dp
@dp.materialized_view
def regional_sales():
partners_df = spark.read.table("partners")
sales_df = spark.read.table("sales")
return (
partners_df.join(sales_df, on="partner_id", how="inner")
)
SQL
CREATE OR REPLACE MATERIALIZED VIEW regional_sales
AS SELECT *
FROM partners
INNER JOIN sales ON
partners.partner_id = sales.partner_id;
Automatiska inkrementella uppdateringar
När pipelinen som definierar en materialiserad vy utlöses hålls vyn automatiskt uppdaterad, ofta stegvis. Databricks försöker endast bearbeta de data som måste bearbetas för att hålla den materialiserade vyn uppdaterad. En materialiserad vy visar alltid rätt resultat, även om det kräver fullständig omkomponering av frågeresultatet från grunden, men ofta gör Databricks bara inkrementella uppdateringar av en materialiserad vy, vilket kan vara mycket mindre kostsamt än en fullständig omkomputation.
Diagrammet nedan visar en materialiserad vy med namnet sales_report, vilket är resultatet av att koppla två överordnade tabeller med namnet clean_customers och clean_transactionsoch gruppera efter land. En överordnad process infogar 200 rader i clean_customers tre länder (USA, Nederländerna, Storbritannien) och uppdaterar 5 000 rader clean_transactions som motsvarar dessa nya kunder. Den sales_report materialiserade vyn uppdateras stegvis för endast de länder som har nya kunder eller motsvarande transaktioner. I det här exemplet uppdateras tre rader i stället för hela försäljningsrapporten.
Mer information om hur inkrementell uppdatering fungerar i materialiserade vyer finns i Inkrementell uppdatering för materialiserade vyer.
Begränsningar för materialiserad vy
Materialiserade vyer har följande begränsningar:
- Eftersom uppdateringar skapar korrekta frågor kräver vissa ändringar av indata en fullständig omkomputation av en materialiserad vy, vilket kan vara dyrt.
- De är inte utformade för användningsfall med låg latens. Svarstiden för att uppdatera en materialiserad vy är i sekunder eller minuter, inte millisekunder.
- Alla beräkningar kan inte beräknas stegvis.
- Azure Databricks försöker identifiera när en UDF som används i en materialiserad vy ändrar beteende och utför en fullständig uppdatering för att tillämpa den uppdaterade UDF:n. UDF:er som anropar andra funktioner eller bibliotek kan dock ändra beteendet på sätt som Azure Databricks inte känner igen. Ett exempel på detta är när ett så kallat bibliotek uppgraderas. När beteendet för en UDF ändras är det ditt ansvar att utföra en fullständig uppdatering av alla materialiserade vyer som använder den.
- Materialiserade vyer stödjer inte
CLONE. Du kan inte använda en materialiserad vy som källa eller mål för en djup eller ytlig klon. Mer information finns i Begränsningar. - Om du vill visa pipelinen som stöder en materialiserad vy behöver en icke-administratörsanvändare behörigheten
REFRESHför den materialiserade vyn utöver behörigheter för pipelinen. Se Vem kan visa en pipeline och dess utdata?.