Incrementeel verversen voor materiële weergaven

Dit artikel bevat een overzicht van de semantiek en vereisten voor incrementele vernieuwingen in gerealiseerde weergaven en identificeert de SQL-bewerkingen, trefwoorden en componenten die incrementeel vernieuwen ondersteunen. Het bevat een bespreking van de verschillen tussen incrementele en volledige vernieuwingen en bevat aanbevelingen voor het kiezen tussen gerealiseerde weergaven en streamingtabellen.

Wanneer u updates uitvoert voor gerealiseerde weergaven met behulp van serverloze pijplijnen, kunnen veel query's incrementeel worden vernieuwd. Incrementele vernieuwingen besparen rekenkosten door wijzigingen in de gegevensbronnen te detecteren die worden gebruikt om de gerealiseerde weergave te definiëren en het resultaat incrementeel te berekenen.

Vernieuwingen worden uitgevoerd op serverloze berekeningen

Vernieuwingsbewerkingen worden uitgevoerd op serverloze pijplijnen, ongeacht of de bewerking is gedefinieerd in Databricks SQL of met declaratieve pijplijnen van Lakeflow.

Voor gematerialiseerde weergaven die zijn gedefinieerd met Databricks SQL, hoeft uw werkruimte niet te worden ingeschakeld voor serverless Lakeflow Declarative Pipelines. De vernieuwing wordt automatisch uitgevoerd met behulp van een serverloze pijplijn.

Voor gerealiseerde weergaven die zijn gedefinieerd met behulp van declaratieve pijplijnen van Lakeflow, moet u de pijplijn zo configureren dat deze serverloos wordt gebruikt. Zie Een serverloze pijplijn configureren.

Wat zijn de vernieuwingssemantieken voor gematerialiseerde weergaven?

Gevmaterialiseerde weergaven garanderen equivalente resultaten voor batchopdrachten. Denk bijvoorbeeld aan de volgende aggregatie-query.

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Wanneer u deze query uitvoert met behulp van een Azure Databricks-product, wordt het resultaat berekend met behulp van batch-semantiek om alle records in de bron transactions_tablesamen te voegen, wat betekent dat alle brongegevens in één bewerking worden gescand en samengevoegd.

Opmerking

Sommige Azure Databricks-producten cachen automatisch resultaten binnen of tussen sessies als gegevensbronnen niet zijn gewijzigd nadat de laatste query is uitgevoerd. Het gedrag van automatische cachingprocessen verschilt van gematerialiseerde weergaven.

In het volgende voorbeeld wordt deze batchquery omgezet in een gerealiseerde weergave:

CREATE OR REPLACE MATERIALIZED VIEW transation_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Wanneer u een gerealiseerde weergave vernieuwt, is het berekende resultaat identiek aan de semantiek van de batchquery. Deze query is een voorbeeld van een gerealiseerde weergave die incrementeel kan worden vernieuwd, wat betekent dat de vernieuwingsbewerking een poging doet om alleen nieuwe of gewijzigde gegevens in de bron te verwerken transactions_table om de resultaten te berekenen.

Overwegingen voor gegevensbronnen voor materiële weergaven

Hoewel u een gerealiseerde weergave kunt definiëren voor elke gegevensbron, zijn niet alle gegevensbronnen geschikt voor gerealiseerde weergaven. Houd rekening met de volgende opmerkingen en aanbevelingen:

Belangrijk

Gematerialiseerde weergaven doen een poging om incrementeel resultaten voor ondersteunde bewerkingen bij te werken. Voor sommige wijzigingen in gegevensbronnen is een volledige vernieuwing vereist.

Alle gegevensbronnen voor gerealiseerde weergaven moeten robuust zijn voor volledige vernieuwingssemantiek, zelfs als de query die de gerealiseerde weergave definieert, incrementeel vernieuwen ondersteunt.

• Bij query's waarbij een volledige vernieuwing te duur zou zijn, gebruik streamingtabellen om verwerking precies één keer te garanderen. Voorbeelden zijn zeer grote tabellen.
• Definieer geen gerealiseerde weergave voor een gegevensbron als records slechts één keer moeten worden verwerkt. Gebruik in plaats daarvan streamingtabellen. Voorbeelden hiervan zijn:
  • Gegevensbronnen die geen gegevensgeschiedenis behouden, zoals Kafka.
  • Opnamebewerkingen, zoals query's die Auto Loader gebruiken om gegevens op te nemen uit cloudobjectopslag.
  • Elke gegevensbron waar u gegevens wilt verwijderen of archiveren na verwerking, maar informatie in downstreamtabellen moet bewaren. Bijvoorbeeld een tabel met datumpartitionering waarin u records wilt verwijderen die ouder zijn dan een bepaalde drempelwaarde.
• Niet alle gegevensbronnen ondersteunen incrementele vernieuwingen. De volgende gegevensbronnen ondersteunen incrementeel vernieuwen:
  • Delta-tabellen, waaronder door Unity Catalog beheerde tabellen en externe tabellen die worden ondersteund door Delta Lake.
  • Gematerealiseerde weergaven.
  • Streamingtabellen, inclusief de doelstellingen van AUTO CDC ... INTO bewerkingen.
• Voor sommige incrementele vernieuwingsbewerkingen is het bijhouden van rijen vereist voor de opgevraagde gegevensbronnen. Rijtracking is een Delta Lake-functie die alleen wordt ondersteund door Delta-tabellen, waaronder gematerialiseerde weergaven, streaming tabellen en door Unity Catalog beheerde tabellen. Zie Gebruik rijtracking voor Delta-tabellen.

Gerealiseerde weergaven optimaliseren

Databricks raadt u aan de volgende functies in te schakelen voor alle gerealiseerde weergavebrontabellen om de beste prestaties te verkrijgen:

• Verwijderingsvectoren
• Rijvolgen
• Gegevensfeed wijzigen

U kunt deze functies instellen tijdens het maken of later met de ALTER TABLE instructie. Voorbeeld:

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Vernieuwingstypen voor geëmaterialiseerde weergaven

Vernieuwingen van gematerialiseerde weergaven zijn volledig of incrementeel. Voor alle bewerkingen zijn de resultaten van een incrementeel vernieuwen en volledig vernieuwen hetzelfde. Azure Databricks voert een kostenanalyse uit om te bepalen of wijzigingen in gegevensbronnen een volledige vernieuwing vereisen.

Zie Het vernieuwingstype van een update bepalenom te bepalen welk vernieuwingstype door een update is gebruikt.

Volledig vernieuwen

Een volledige vernieuwing overschrijft de resultaten in de gerealiseerde weergave door alle gegevens die beschikbaar zijn in de bron opnieuw te verwerken. Afhankelijk van hoe de gegevensbronnen zijn gewijzigd, kunnen alle gerealiseerde weergaven bij elke willekeurige update volledig worden vernieuwd.

U kunt eventueel een volledige vernieuwing afdwingen. Gebruik de volgende syntaxis voor gerealiseerde weergaven die zijn gedefinieerd met Databricks SQL:

REFRESH MATERIALIZED VIEW mv_name FULL

Voor gerealiseerde weergaven die zijn gedefinieerd in declaratieve pijplijnen van Lakeflow, kunt u ervoor kiezen om een volledige vernieuwing uit te voeren voor geselecteerde gegevenssets of voor alle gegevenssets in een pijplijn. Zie semantiek voor pijplijnvernieuwing.

Belangrijk

Wanneer een volledige vernieuwing wordt uitgevoerd op een gegevensbron waar records zijn verwijderd vanwege de drempelwaarde voor gegevensretentie of handmatig verwijderen, worden verwijderde records niet weergegeven in berekende resultaten. U kunt mogelijk geen oude gegevens herstellen als de gegevens niet meer beschikbaar zijn in de bron.

Opmerking

U kunt desgewenst volledige vernieuwingen voor een tabel uitschakelen door de tabeleigenschap in te stellen pipelines.reset.allowed op false.

Incrementele vernieuwing

Bij incrementeel vernieuwen worden wijzigingen in de onderliggende gegevens verwerkt na de laatste vernieuwing en worden die gegevens vervolgens toegevoegd aan de tabel. Afhankelijk van de basistabellen en opgenomen bewerkingen, kunnen alleen bepaalde typen gerealiseerde weergaven incrementeel worden vernieuwd.

Alleen materiële weergaven die zijn bijgewerkt met behulp van serverloze pijplijnen, kunnen gebruik maken van incrementeel vernieuwen. Gerealiseerde weergaven die geen serverloze pijplijnen gebruiken, worden altijd volledig vernieuwd.

Wanneer gerealiseerde weergaven worden gemaakt met behulp van een SQL-warehouse of serverloze Lakeflow-declaratieve pijplijnen, worden ze automatisch incrementeel vernieuwd als hun query's worden ondersteund. Als een query niet-ondersteunde expressies voor incrementeel vernieuwen bevat, wordt een volledige vernieuwing uitgevoerd, wat mogelijk leidt tot extra kosten.

Ondersteuning voor incrementele vernieuwing van gematerialiseerde weergaven

De volgende tabel bevat ondersteuning voor incrementeel vernieuwen op SQL-trefwoord of -component.

Belangrijk

Voor sommige trefwoorden en clausules is het bijhouden van rijen vereist voor de opgevraagde gegevensbronnen. Zie Gebruik rijtracking voor Delta-tabellen.

Deze trefwoorden en componenten worden gemarkeerd met een ster (*) in de volgende tabel.

SQL-trefwoord of -clausule	Ondersteuning voor incrementeel vernieuwen
SELECT uitdrukkingen*	Ja, expressies, waaronder deterministische ingebouwde functies en onveranderbare, door de gebruiker gedefinieerde functies (UDF's) worden ondersteund.
GROUP BY	Ja
WITH	Ja, algemene tabelexpressies worden ondersteund.
UNION ALL*	Ja
FROM	Ondersteunde basistabellen zijn Delta-tabellen, gerealiseerde weergaven en streamingtabellen.
WHERE, HAVING*	Filterclausules zoals WHERE en HAVING worden ondersteund.
INNER JOIN*	Ja
LEFT OUTER JOIN*	Ja
FULL OUTER JOIN*	Ja
RIGHT OUTER JOIN*	Ja
OVER	Ja. PARTITION_BY kolommen moeten worden opgegeven voor incrementele instellingen voor vensterfuncties.
QUALIFY	Ja
EXPECTATIONS	Nee. Gerealiseerde weergaven die gebruikmaken van verwachtingen, worden altijd volledig vernieuwd.
Niet-deterministische functies	Nee. Niet-deterministische functies worden bijvoorbeeld CURRENT_DATEniet ondersteund.
Niet-Delta-bronnen	Bronnen zoals volumes, externe locaties en buitenlandse catalogi worden niet ondersteund.

Het vernieuwingstype van een update bepalen

Om de prestaties van gerealiseerde weergavevernieuwingen te optimaliseren, gebruikt Azure Databricks een kostenmodel om de techniek te selecteren die wordt gebruikt voor het vernieuwen. In de volgende tabel worden deze technieken beschreven:

Techniek	Incrementeel vernieuwen?	Beschrijving
FULL_RECOMPUTE	Nee.	De gerealiseerde weergave is volledig opnieuw gecomputeerd
NO_OP	Niet van toepassing	De gerealiseerde weergave is niet bijgewerkt omdat er geen wijzigingen in de basistabel zijn gedetecteerd.
Een of meer van: ROW_BASED PARTITION_OVERWRITE WINDOW_FUNCTION APPEND_ONLY GROUP_AGGREGATE GENERIC_AGGREGATE	Ja	De gerealiseerde weergave is incrementeel vernieuwd met behulp van de opgegeven techinique.

Als u de gebruikte techniek wilt bepalen, voert u een query uit op het gebeurtenislogboek van Lakeflow Declarative Pipelines, waarbij het event_type volgende het geval is planning_information:

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Vervang <fully-qualified-table-name> door de volledig gekwalificeerde naam van de gerealiseerde weergave, inclusief de catalogus en het schema.

Voorbeelduitvoer voor deze opdracht:

• • tijdstempel
  • bericht
• • 2025-03-21T22:23:16.497+00:00
  • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Zie Wat is het evenementenlogboek van Lakeflow Declarative Pipelines?