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 bijwerken voor gematerialiseerde weergaven vereist serverloze pijplijnen.

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

Voor gematerialiseerde weergaven die zijn gedefinieerd met Delta Live Tables-pipelines, moet u de pipeline zo configureren dat deze de serverloze modus gebruikt. Zie Een serverloze Delta Live Tables-pijplijn configureren.

Wat zijn de vernieuwingssemantieken voor gematerialiseerde weergaven?

Gevmaterialiseerde weergaven garanderen equivalente resultaten voor batchopdrachten. 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 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 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.
    • Gematerialiseerde views.
    • Streamingtabellen, inclusief de doelstellingen 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 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:

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

Notitie

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

Incrementeel vernieuwen

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 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 incrementele vernieuwing van gematerialiseerde 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 Gebruik rijtracking 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 waarin de event_type 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.

Zie Wat houdt het Delta Live Tables-gebeurtenislogboek in?.