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 Spark.

Voor gerealiseerde weergaven die zijn gedefinieerd met Databricks SQL, hoeft uw werkruimte niet te worden ingeschakeld voor serverloze Lakeflow Spark-declaratieve pijplijnen. Tijdens het vernieuwen wordt automatisch een serverloze pijplijn gebruikt.

Voor gematerialiseerde weergaven die zijn gedefinieerd met behulp van declaratieve pijplijnen van Lakeflow Spark, moet u de pijplijn zo configureren dat deze zonder server 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.

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

CREATE OR REPLACE MATERIALIZED VIEW transaction_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:

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 Rijtracking in Databricks.
• Gegevensbronnen met rijfilters of kolommaskers die zijn gedefinieerd, bieden geen ondersteuning voor incrementeel vernieuwen. Rijfilters en kolommaskers weergeven

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

Wanneer een gerealiseerde weergave wordt bijgewerkt, kunt u een vernieuwing of een volledige vernieuwing opgeven.

• Een vernieuwing probeert een incrementele vernieuwing uit te voeren, maar voert indien nodig een volledige hercomputing van de gegevens uit. Incrementeel vernieuwen is alleen beschikbaar wanneer de berekening met wie u verbinding hebt, serverloos is.
• Bij een volledige vernieuwing worden alle invoerwaarden in de gerealiseerde weergave altijd opnieuw berekend en worden alle controlepunten opnieuw ingesteld.

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

Standaardvernieuwing

De standaardvernieuwing voor een gerealiseerde weergave op serverloze pogingen om een incrementele vernieuwing uit te voeren. 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. Als een incrementeel vernieuwen niet mogelijk is of de verbonden berekening klassiek is in plaats van serverloos, wordt een volledige hercomputing uitgevoerd.

De uitvoer van een incrementeel vernieuwen en een volledige hercomputing zijn hetzelfde. Azure Databricks voert een kostenanalyse uit om de goedkopere optie te kiezen tussen incrementeel vernieuwen en een volledige hercomputing.

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 opnieuw gecomputeerd.

Wanneer u gematerialiseerde weergaven maakt met een SQL-warehouse of serverloze declaratieve Lakeflow Spark-pijplijnen, vernieuwt Azure Databricks deze incrementeel, mits hun query's worden ondersteund. Als een query gebruikmaakt van niet-ondersteunde expressies, voert Azure Databricks in plaats daarvan een volledige hercomputing uit, waardoor de kosten kunnen worden verhoogd.

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 de tabel en controlepunten te wissen en alle gegevens die beschikbaar zijn in de bron opnieuw te verwerken.

Als u een volledige vernieuwing wilt uitvoeren voor gerealiseerde weergaven die zijn gedefinieerd met Databricks SQL, gebruikt u de volgende syntaxis:

REFRESH MATERIALIZED VIEW mv_name FULL

Voor materiële weergaven die zijn gedefinieerd in de declaratieve pijplijnen van Lakeflow Spark, kun je kiezen voor een volledige vernieuwing van geselecteerde gegevenssets of alle gegevenssets in een pijplijn. Zie semantiek voor pijplijnvernieuwing.

Ondersteuning voor incrementele vernieuwing van gematerialiseerde weergaven

De volgende tabel bevat ondersteuning voor incrementeel vernieuwen op SQL-trefwoord of -component. Als u een specifieke query wilt testen op incrementele aanpassing, kunt u dit gebruiken EXPLAIN CREATE MATERIALIZED VIEW.

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:

Zie ook Beleid vernieuwen.

Als u de gebruikte techniek wilt bepalen, voert u een query uit op het gebeurtenislogboek van Lakeflow Spark 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:

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

Zie het gebeurtenislogboek van de pijplijn.

Beleid vernieuwen

Standaard selecteert Azure Databricks automatisch de meest rendabele vernieuwingsstrategie (incrementeel of volledig) op basis van querystructuur, gegevenswijzigingsvolume en systeemkostenmodellering. Dit standaardgedrag optimaliseert de vernieuwingsprestaties zonder handmatige configuratie.

Voor sommige workloads is echter meer voorspelbaar of expliciet gecontroleerd vernieuwingsgedrag vereist. Ter ondersteuning van deze scenario's kunt u een REFRESH POLICY in de gerealiseerde weergavedefinitie opgeven. Een vernieuwingsbeleid bepaalt of Azure Databricks incrementeel vernieuwen uitvoert, wanneer het kan terugvallen op een volledige vernieuwing en of een vernieuwing moet mislukken in plaats van een volledige hercomputing uit te voeren.

Met behulp van REFRESH POLICYkunt u het systeem configureren voor:

• AUTO (standaard): gebruik automatische selectie op basis van kosten. Databricks kiest voor incrementeel of volledig vernieuwen op basis van efficiëntie en querymogelijkheden. Aanbevolen voor de meeste gebruikers.
• INCREMENTAL - Geef de voorkeur aan incrementeel vernieuwen. Databricks voert waar mogelijk incrementeel vernieuwen uit. Het valt terug op een volledige vernieuwing als het queryplan incrementeel vernieuwen niet meer ondersteunt.
• INCREMENTAL STRICT - Strikt genomen vereisen incrementele vernieuwing. Stapsgewijs bijwerken is vereist tijdens de normale werking. Als incrementeel uitvoeren niet mogelijk is, mislukt de vernieuwing of het aanmaken van de operatie.
• FULL - Altijd volledige vernieuwingen uitvoeren. Databricks voert nooit incrementeel vernieuwen uit, zelfs wanneer de query incrementalizeerbaar is.

-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Het optimale vernieuwingsbeleid is afhankelijk van de kenmerken van uw workload:

• AUTO is geschikt voor de meeste workloads. Het systeem balanceert kosten en prestaties en past zich automatisch aan wanneer het querygedrag verandert.
• INCREMENTAL is handig wanneer incrementeel vernieuwen voordelen biedt, maar het is acceptabel dat Azure Databricks volledige vernieuwingen uitvoert wanneer incrementeel aanpassen tijdelijk niet beschikbaar is (bijvoorbeeld wanneer het bijhouden van rijen in een brontabel is uitgeschakeld).
• INCREMENTAL STRICT moet worden gebruikt wanneer incrementeel vernieuwen is vereist om te voldoen aan kosten, prestaties of SLA-beperkingen, en onverwachte volledige vernieuwingen zijn onaanvaardbaar. Dit beleid wordt aanbevolen wanneer gebruikers de voorkeur geven aan een mislukte update, zodat ze het probleem kunnen opsporen in plaats van door te gaan met een volledige vernieuwing.
• FULL is geschikt wanneer incrementele vernieuwing weinig voordelen biedt, de dataset klein is, of de querystructuur regelmatig wordt gewijzigd op manieren die het voorkomen van incrementele vernieuwing verhinderen.