Gematerealiseerde weergaven

Net als bij standaardweergaven zijn gerealiseerde weergaven de resultaten van een query en opent u deze op dezelfde manier als een tabel. In tegenstelling tot standaardweergaven, die resultaten voor elke query opnieuw compileren, slaan gerealiseerde weergaven de resultaten in de cache op en vernieuwen ze op een opgegeven interval. Omdat een gerealiseerde weergave vooraf is gecomputeerd, kunnen query's op deze weergave veel sneller worden uitgevoerd dan bij normale weergaven.

Raadpleeg Wat zijn pijplijnen? voor richtlijnen over wanneer u gematerialiseerde weergaven gebruikt in plaats van streamingtabellen of weergaven.

Een gerealiseerde weergave is een declaratief pijplijnobject. Het bevat een query die deze definieert, een stroom om deze bij te werken en de resultaten in de cache voor snelle toegang. Een gerealiseerde weergave:

• Houdt wijzigingen bij in upstream-gegevens.
• Bij trigger worden de gewijzigde gegevens incrementeel verwerkt en worden de benodigde transformaties toegepast.
• Onderhoudt de uitvoertabel, gesynchroniseerd met de brongegevens, op basis van een opgegeven vernieuwingsinterval.

Gematerialiseerde weergaven zijn een goede keuze voor veel transformaties.

• U past redenering toe op resultaten in de cache in plaats van rijen. In feite schrijft u gewoon een query.
• Ze zijn altijd correct op het moment van hun update. Alle vereiste gegevens worden verwerkt, zelfs als deze te laat of niet in orde zijn.
• Ze zijn vaak incrementeel. Azure Databricks probeert de juiste strategie te kiezen waarmee de kosten voor het bijwerken van een gerealiseerde weergave worden geminimaliseerd.

Hoe gerealiseerde weergaven werken

In het volgende diagram ziet u hoe gerealiseerde weergaven werken.

Gematerialiseerde weergaven worden gedefinieerd en bijgewerkt door één pijplijn. U kunt gerealiseerde weergaven expliciet definiëren in de broncode van de pijplijn. Tabellen die zijn gedefinieerd door een pijplijn, kunnen niet worden gewijzigd of bijgewerkt door een andere pijplijn.

Azure Databricks maakt gebruik van Unity Catalog om metagegevens over de weergave op te slaan, inclusief de query en aanvullende systeemweergaven voor incrementele updates. Azure Databricks slaat de gegevens uit de cache op in cloudopslag. Azure Databricks slaat enkele onderliggende gegevens op in de __databricks_internal-catalogus. Zie de __databricks_internal catalogus.

In het volgende voorbeeld worden twee tabellen samengevoegd en wordt het resultaat bijgewerkt met behulp van een gerealiseerde weergave.

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;

Automatische incrementele updates

Wanneer de pijplijn die een gematerialiseerde weergave definieert wordt geactiveerd, wordt de weergave automatisch up-to-date gehouden, vaak in stappen. Azure Databricks probeert alleen de gegevens te verwerken die moeten worden verwerkt om de gerealiseerde weergave up-to-date te houden. Een gematerialiseerde weergave toont altijd het juiste resultaat, zelfs als daarvoor het queryresultaat volledig opnieuw vanaf nul moet worden berekend, maar vaak voert Azure Databricks alleen incrementele updates uit op een gematerialiseerde weergave, wat veel minder kostbaar kan zijn dan een volledige herberekening.

In het onderstaande diagram ziet u een gematerialiseerde weergave met de naam sales_report, die het resultaat is van het samenvoegen van twee upstreamtabellen met de namen clean_customers en clean_transactions, en gegroepeerd op land. Een upstream-proces voegt 200 rijen clean_customers in in drie landen (VS, Nederland, VK) en werkt 5000 rijen bij die clean_transactions overeenkomen met deze nieuwe klanten. De sales_report gerealiseerde weergave wordt stapsgewijs bijgewerkt voor alleen de landen met nieuwe klanten of bijbehorende transacties. In dit voorbeeld worden drie rijen bijgewerkt in plaats van het volledige verkooprapport.

Zie Incrementeel vernieuwen voor gerealiseerde weergaven voor meer informatie over hoe incrementeel vernieuwen werkt in gerealiseerde weergaven.

Beperkingen van gematerialiseerde weergaven

Gerealiseerde weergaven hebben de volgende beperkingen:

• Omdat updates juiste query's maken, vereisen sommige wijzigingen in invoer een volledige hercomputatie van een gerealiseerde weergave, wat duur kan zijn.
• Ze zijn niet ontworpen voor gebruiksscenario's met lage latentie. De latentie van het bijwerken van een gerealiseerde weergave is in de seconden of minuten, niet in milliseconden.
• Niet alle berekeningen kunnen incrementeel worden berekend.
• Azure Databricks probeert te detecteren wanneer een UDF die in een gerealiseerde weergave wordt gebruikt, verandert en voert een volledige vernieuwing uit om de bijgewerkte UDF toe te passen. UDF's die andere functies of bibliotheken aanroepen, kunnen echter gedrag wijzigen op manieren die Azure Databricks niet herkent. Een voorbeeld hiervan is wanneer een aangeroepen library wordt bijgewerkt. Wanneer het gedrag van een UDF verandert, is het uw verantwoordelijkheid om een volledige vernieuwing uit te voeren op elke gematerialiseerde weergave die deze gebruikt.
• Gematerialiseerde weergaven bieden geen ondersteuning voor CLONE. U kunt een gematerialiseerde weergave niet gebruiken als bron of doel voor een diepe of ondiepe kloon. Zie Beperkingen voor meer informatie.
• Om de pijplijn te bekijken die achter een gematerialiseerde weergave zit, heeft een niet-beheerder naast machtigingen voor de pijplijn ook het privilege REFRESH op de gematerialiseerde weergave nodig. Zie Wie een pijplijn en de uitvoer kan bekijken?

Aanvullende bronnen

• Incrementele vernieuwing voor gematerialiseerde weergaven
• Zelfstandige gematerialiseerde weergaven gebruiken
• Afzonderlijke gematerialiseerde views bewaken