Materialiserade vyer

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 beräknar om resultaten för varje fråga, cachelagras resultatet 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.

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 har alltid rätt. 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.

Databricks använder Unity Catalog för att lagra metadata om vyn, inklusive frågan och ytterligare systemvyer som används för inkrementella uppdateringar. Cachelagrade data materialiseras i molnlagring.

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 ser vi tre rader uppdaterade 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 hos materialiserade vyer

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.