Delen via

Incrementeel vernieuwen voor gerealiseerde weergaven

  • Artikel

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.

Serverloze pijplijnen zijn vereist voor incrementeel vernieuwen

Incrementeel vernieuwen voor gerealiseerde weergaven vereist serverloze pijplijnen.

Vernieuwingsbewerkingen voor gerealiseerde weergaven die zijn gedefinieerd in Databricks SQL, worden altijd uitgevoerd met behulp van serverloze pijplijnen.

Voor gerealiseerde weergaven die zijn gedefinieerd met Delta Live Tables-pijplijnen, moet u de pijplijn zo configureren dat deze serverloos wordt gebruikt. Zie Een serverloze Delta Live Tables-pijplijn configureren.

Wat zijn de vernieuwingssemantiek voor gerealiseerde weergaven?

Gerealiseerde weergaven garanderen equivalente resultaten voor batchquery's. Denk bijvoorbeeld aan de volgende statistische 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.

Notitie

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 caching verschilt van gerealiseerde weergaven.

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

CREATE OR REFRESH 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 transactions_table te verwerken om de resultaten te berekenen.

Overwegingen voor gegevensbronnen voor gerealiseerde 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

Gerealiseerde weergaven maken een best-effort poging om incrementeel resultaten voor ondersteunde bewerkingen te vernieuwen. 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.

  • Gebruik streamingtabellen voor query's waarbij een volledige vernieuwing kostenbehalve zou zijn om exact één keer te verwerken. 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 automatisch laden gebruiken om gegevens op te nemen uit de opslag van cloudobjecten.
    • 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.
    • Gerealiseerde weergaven.
    • Streamingtabellen, inclusief de doelen van APPLY CHANGES 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 gerealiseerde weergaven, streamingtabellen en beheerde tabellen van Unity Catalog. Zie Rijtracering gebruiken 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:

Vernieuwingstypen voor gerealiseerde weergaven

Vernieuwingen naar gerealiseerde 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 bepalen om te bepalen welk vernieuwingstype een update wordt 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. Alle gerealiseerde weergaven kunnen volledig worden vernieuwd op een bepaalde update, afhankelijk van hoe de gegevensbronnen zijn gewijzigd.

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 een Delta Live Tables-pijplijn, kunt u ervoor kiezen om een volledige vernieuwing uit te voeren voor geselecteerde gegevenssets of voor alle gegevenssets in een pijplijn. Zie Hoe Delta Live Tables tabellen bijwerken tabellen en weergaven.

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.

Notitie

U kunt desgewenst volledige vernieuwingen voor een tabel uitschakelen door de tabeleigenschap pipelines.reset.allowed in te stellen 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 gerealiseerde weergaven die zijn bijgewerkt met behulp van serverloze pijplijnen, kunnen incrementeel vernieuwen gebruiken. Gerealiseerde weergaven die geen serverloze pijplijnen gebruiken, worden altijd volledig vernieuwd.

Wanneer gerealiseerde weergaven worden gemaakt met behulp van een SQL Warehouse- of serverloze Delta Live Tables-pijplijn, 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 incrementeel vernieuwen van gerealiseerde weergaven

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

Belangrijk

Voor sommige trefwoorden en componenten is het bijhouden van rijen vereist voor de opgevraagde gegevensbronnen. Zie Rijtracering gebruiken voor Delta-tabellen.

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

SQL-trefwoord of -component 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.

Notitie

Niet-deterministische functies worden CURRENT_TIMESTAMPbijvoorbeeld 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.
ROW_BASED of PARTITION_OVERWRITE Ja De gerealiseerde weergave is incrementeel vernieuwd met behulp van de opgegeven techniek.

Als u de gebruikte techniek wilt bepalen, voert u een query uit op het gebeurtenislogboek van Delta Live Tables waar het event_type volgende is planning_information:

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

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

Zie Wat is het gebeurtenislogboek van Delta Live Tables?