Gerealiseerde weergaven gebruiken in Databricks SQL

In dit artikel wordt beschreven hoe u gerealiseerde weergaven maakt en vernieuwt in Databricks SQL om de prestaties te verbeteren en de kosten van uw gegevensverwerkings- en analyseworkloads te verlagen.

Wat zijn gematerialiseerde weergaven?

In Databricks SQL zijn gerealiseerde weergaven beheerde tabellen van Unity Catalog waarmee de resultaten van een query fysiek worden opgeslagen. In tegenstelling tot standaardweergaven, die de resultaten op aanvraag berekenen, slaan gerealiseerde weergaven de resultaten in de cache op en werken ze bij naarmate de onderliggende brontabellen veranderen, volgens een planning of automatisch.

Gerealiseerde weergaven zijn geschikt voor gegevensverwerkingsworkloads, zoals ETL-verwerking (extract, transform en load). Gerealiseerde weergaven bieden een eenvoudige, declaratieve manier om gegevens te verwerken voor naleving, correcties, aggregaties of algemene wijzigingsgegevensopname (CDC). Gerealiseerde weergaven maken ook gebruiksvriendelijke transformaties mogelijk door basistabellen op te schonen, verrijken en denormaliseren. Door dure of veelgebruikte query's vooraf te berekenen, verlagen gerealiseerde weergaven de querylatentie en het resourceverbruik. In veel gevallen kunnen ze incrementeel wijzigingen van brontabellen berekenen, waardoor de efficiëntie en de ervaring van eindgebruikers verder worden verbeterd.

Hier volgen veelvoorkomende gebruiksvoorbeelden voor gerealiseerde weergaven:

• Een BI-dashboard up-to-date houden met minimale latentie van query's van eindgebruikers.
• Complexe ETL-indeling verminderen met eenvoudige SQL-logica.
• Complexe, gelaagde transformaties bouwen.
• Toepassingsgevallen die consistente prestaties vereisen met inzicht in actuele up-to-data.

Wanneer u een gematerialiseerde weergave maakt in een Databricks SQL Warehouse, wordt er een serverloze pijplijn gemaakt om het maken en vernieuwen van de gematerialiseerde weergave te verwerken. U kunt de status van vernieuwingsbewerkingen bewaken in Catalog Explorer. Zie Details weergeven met DESCRIBE EXTENDED.

vereisten voor

Gematerialiseerde weergaven die zijn gemaakt in Databricks SQL worden ondersteund door een serverloze pijplijn. Uw werkruimte moet serverloze pijplijnen ondersteunen om deze functionaliteit te kunnen gebruiken.

Vereisten voor het maken of vernieuwen van gerealiseerde weergaven:

• U moet een pro- of serverloze SQL-warehouse met Unity Catalog gebruiken.

• Als u een gerealiseerde weergave wilt vernieuwen, moet u zich in de werkruimte bevinden die deze heeft gemaakt.

• Als u een gerealiseerde weergave van Delta-tabellen incrementeel wilt vernieuwen, moeten de brontabellen het bijhouden van rijen hebben ingeschakeld.

• De eigenaar (de gebruiker die de gerealiseerde weergave maakt) moet de volgende machtigingen hebben:

  • SELECT rechten op de basistabellen waarnaar de gematerialiseerde weergave verwijst.
  • USE CATALOG en USE SCHEMA bevoegdheden voor de catalogus en het schema met de brontabellen voor de gerealiseerde weergave.
  • USE CATALOG en USE SCHEMA bevoegdheden voor de doelcatalogus en -schema voor de gematerialiseerde weergave.
  • CREATE TABLE en CREATE MATERIALIZED VIEW bevoegdheden voor het schema met de ge-materialiseerde weergave.

• Als u een gerealiseerde weergave wilt vernieuwen, moet u over de REFRESH bevoegdheid beschikken voor de gerealiseerde weergave.

• Uw werkruimte moet zich in een regio bevinden die ondersteuning biedt voor serverloze SQL-warehouses.

Vereisten voor het opvragen van gematerialiseerde weergaven:

• U moet de eigenaar van de gerealiseerde weergave zijn of beschikken over SELECT voor de gerealiseerde weergave, samen met USE SCHEMA en USE CATALOG voor de bovenliggende objecten.
• U moet een van de volgende rekenresources gebruiken:

  • SQL Warehouse

  • Lakeflow Spark-declaratieve pijplijninterfaces

  • Berekening van de standaardtoegangsmodus (voorheen modus voor gedeelde toegang)

  • De exclusieve toegangsmodus (voorheen modus voor toegang tot één gebruiker) in Databricks Runtime 15.4 en hoger, zolang de werkruimte is ingeschakeld voor serverloze verwerking. Zie Gedetailleerd toegangsbeheer voor toegewezen berekeningen.

    Als u de eigenaar van de gematerialiseerde weergave bent, kunt u een rekenresource voor de toegewezen toegangsmodus gebruiken waarop Databricks Runtime versie 14.3 of hoger wordt uitgevoerd.

Zie Beperkingenvoor meer informatie over andere beperkingen voor het gebruik van gerealiseerde weergaven.

Een gerealiseerde weergave maken

Databricks SQL-bewerkingen voor gematerialiseerde weergaven gebruiken een Databricks SQL-warehouse om gegevens te creëren en te laden in de gematerialiseerde weergave. Het maken van een gerealiseerde weergave is een synchrone bewerking, wat betekent dat de CREATE MATERIALIZED VIEW opdracht wordt geblokkeerd totdat de gerealiseerde weergave wordt gemaakt en de initiële gegevensbelasting is voltooid. Voor elke gematerialiseerde Databricks SQL-weergave wordt automatisch een serverloze pijplijn gemaakt. Wanneer de gerealiseerde weergave wordt vernieuwd, verwerkt de pijplijn de vernieuwing.

Gebruik de CREATE MATERIALIZED VIEW instructie om een gematerialiseerde weergave te maken. Als u een create-instructie wilt verzenden, gebruikt u de SQL-editor in de Azure Databricks-gebruikersinterface, de Databricks SQL CLI of de Databricks SQL-API.

De gebruiker die een gerealiseerde weergave maakt, is de eigenaar van de gerealiseerde weergave.

In het volgende voorbeeld wordt de gerealiseerde weergave gemaakt mv1 uit de basistabel base_table1:

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Wanneer u een gerealiseerde weergave maakt met behulp van de CREATE OR REPLACE MATERIALIZED VIEW instructie, wordt de initiële gegevensvernieuwing en de populatie onmiddellijk gestart. Dit verbruikt geen SQL Warehouse-rekenkracht. In plaats daarvan wordt een serverloze pijplijn ingezet voor het maken en het daaropvolgende vernieuwen.

Kolomopmerkingen in een basistabel worden automatisch doorgegeven aan de nieuwe gematerialiseerde weergave alleen bij het aanmaken. Als u een schema, tabelbeperkingen of andere eigenschappen wilt toevoegen, wijzigt u de gerealiseerde weergavedefinitie (de SQL-query).

Dezelfde SQL-instructie vernieuwt een gerealiseerde weergave als deze een volgende tijd of volgens een schema wordt aangeroepen. Een vernieuwing die op deze manier wordt uitgevoerd, fungeert als elke andere vernieuwing. Zie Een gerealiseerde weergave vernieuwen voor meer informatie.

Zie Gerealiseerde weergaven configureren in Databricks SQL voor meer informatie over het configureren van een gerealiseerde weergave. Zie CREATE MATERIALIZED VIEWvoor meer informatie over de volledige syntaxis voor het maken van een gerealiseerde weergave. Zie Gegevens laden in pijplijnen voor meer informatie over het laden van gegevens in verschillende indelingen en vanaf verschillende locaties.

Gegevens laden van externe systemen

Gerealiseerde weergaven kunnen worden gemaakt op externe gegevens met behulp van Lakehouse Federation voor ondersteunde gegevensbronnen. Zie Opties voor gegevensindeling voor informatie over het laden van gegevens uit bronnen die niet worden ondersteund door Lakehouse Federation. Zie Gegevens laden in pijplijnen voor algemene informatie over het laden van gegevens, inclusief voorbeelden.

Gevoelige gegevens verbergen

U kunt gerealiseerde weergaven gebruiken om gevoelige gegevens te verbergen voor gebruikers die toegang hebben tot de tabel. Een manier om dit te doen is door de query zo te maken dat de gegevens er vanaf het begin niet in worden opgenomen. U kunt echter ook kolommen maskeren of rijen filteren op basis van de machtigingen van de querygebruiker. U kunt bijvoorbeeld de tax_id kolom verbergen voor gebruikers die zich niet in de groep bevinden HumanResourcesDept. Gebruik hiervoor de ROW FILTER en MASK syntaxis tijdens het maken van de gerealiseerde weergave. Zie Rijfilters en kolommaskers voor meer informatie.

Een gematerialiseerde weergave vernieuwen

Wanneer u een gerealiseerde weergave vernieuwt, wordt de weergave bijgewerkt met de meest recente wijzigingen in de basistabel op het moment van de vernieuwing.

Wanneer u een gerealiseerde weergave definieert, wordt de CREATE OR REPLACE MATERIALIZED VIEW instructie gebruikt om de weergave te maken en om deze te vernieuwen voor geplande vernieuwingen. U kunt de REFRESH MATERIALIZED VIEW instructie ook gebruiken om de gerealiseerde weergave te vernieuwen zonder dat u de query opnieuw hoeft op te geven. Zie REFRESH (MATERIALIZED VIEW of STREAMING TABLE) voor meer informatie over de SQL-syntaxis en parameters voor deze opdracht. Zie Incrementeel vernieuwen van gematerialiseerde weergavenvoor meer informatie over de typen gematerialiseerde weergaven die incrementeel kunnen worden vernieuwd.

Als u een vernieuwingsinstructie wilt verzenden, gebruikt u de SQL-editor in de Gebruikersinterface van Azure Databricks, een notebook dat is gekoppeld aan een SQL-warehouse, de Databricks SQL CLIof de Databricks SQL API.

De eigenaar en elke gebruiker die het REFRESH privilege op de tabel heeft gekregen, kan de materiële weergave vernieuwen.

In het volgende voorbeeld wordt de mv1 gematerialiseerde weergave vernieuwd.

REFRESH MATERIALIZED VIEW mv1;

De bewerking is standaard synchroon, wat betekent dat de opdracht wordt geblokkeerd totdat de vernieuwingsbewerking is voltooid. Als u asynchroon wilt vernieuwen, kunt u het ASYNC trefwoord toevoegen:

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Hoe worden Databricks SQL gematerialiseerde weergaven vernieuwd?

Gerealiseerde weergaven maken en gebruiken automatisch serverloze pijplijnen om vernieuwingsbewerkingen te verwerken. De vernieuwing wordt beheerd door de pijplijn en de update wordt bewaakt door het Databricks SQL Warehouse dat wordt gebruikt om de gematerialiseerde weergave te maken. Gematerialiseerde weergaven kunnen worden bijgewerkt door een pijplijn die volgens een schema wordt uitgevoerd. Databricks SQL voert gematerialiseerde weergaven altijd uit in de geactiveerde modus. Zie Getriggerd versus continue pijplijnmodus.

Gerealiseerde weergaven worden vernieuwd met behulp van een van de twee methoden.

• Incrementeel vernieuwen : het systeem evalueert de query van de weergave om wijzigingen te identificeren die zijn aangebracht na de laatste update en alleen de nieuwe of gewijzigde gegevens worden samengevoegd.
• Volledig vernieuwen : als een incrementele vernieuwing niet kan worden uitgevoerd of niet rendabel is, voert het systeem de volledige query uit en vervangt het de bestaande gegevens in de gerealiseerde weergave door de nieuwe resultaten.

De structuur van de query en het type brongegevens bepalen of incrementeel vernieuwen wordt ondersteund. Ter ondersteuning van incrementeel vernieuwen moeten brongegevens worden opgeslagen in Delta-tabellen, waarbij het bijhouden van rijen en het wijzigen van gegevensfeeds is ingeschakeld. Als u wilt zien of een query incrementalizeerbaar is, gebruikt u de Databricks SQL-instructie EXPLAIN CREATE MATERIALIZED VIEW . Nadat u een gerealiseerde weergave hebt gemaakt, kunt u het vernieuwingsgedrag controleren om te controleren of deze incrementeel of via een volledige vernieuwing wordt bijgewerkt.

Azure Databricks maakt standaard gebruik van een kostenmodel om de rendabelere optie te kiezen tussen volledig en incrementeel vernieuwen. U kunt dit gedrag overschrijven om de voorkeur te geven aan incrementele of volledige vernieuwingen door een REFRESH POLICY in uw SQL-definitie van de gerealiseerde weergave in te stellen.

Zie Incrementeel vernieuwen voor gematerialiseerde weergaven voor meer informatie over verschillende vernieuwingstypen en hoe u kunt optimaliseren voor incrementele vernieuwingen.

Asynchrone vernieuwingen

Vernieuwingsbewerkingen worden standaard synchroon uitgevoerd. U kunt ook een vernieuwingsbewerking instellen om asynchroon te worden uitgevoerd. Dit kan worden ingesteld met behulp van de vernieuwingsopdracht met het ASYNC trefwoord. Zie REFRESH (MATERIALIZED VIEW of STREAMING TABLE). Het gedrag dat aan elke benadering is gekoppeld, is als volgt:

• synchrone: Een synchrone verversing voorkomt dat andere bewerkingen doorgaan totdat de verversing voltooid is. Als het resultaat nodig is voor de volgende stap, zoals bij het sequentiëren van vernieuwingsbewerkingen in orkestratiehulpmiddelen zoals Lakeflow Jobs, gebruikt u een synchrone vernieuwing. Als u materiaalweergaven wilt orkestreren met een taak, gebruikt u het SQL- taaktype. Zie Lakeflow Jobs.
• Asynchroon: Een asynchrone vernieuwing start een achtergrondtaak op serverloze compute wanneer de vernieuwing van een materiële weergave begint, waardoor de opdracht kan worden voltooid voordat het laden van gegevens is afgerond. Dit vernieuwingstype kan kosten besparen omdat de bewerking niet noodzakelijkerwijs rekencapaciteit bevat in het magazijn waar de opdracht wordt gestart. Als de vernieuwing inactief is en er geen andere taken worden uitgevoerd, kan het magazijn worden uitgeschakeld terwijl de vernieuwing gebruikmaakt van andere beschikbare rekenkracht. Daarnaast bieden asynchrone vernieuwingen ondersteuning voor het parallel starten van meerdere bewerkingen.

Gematerialiseerde weergavevernieuwingen plannen

U kunt een gerealiseerde Databricks SQL-weergave configureren om automatisch te vernieuwen op basis van een gedefinieerd schema of om te activeren wanneer upstream-gegevens worden gewijzigd. In de volgende tabel ziet u de verschillende opties voor het plannen van vernieuwingen.

Methode	Description	Voorbeeld van een toepassing
Handleiding	Vernieuwen op aanvraag met behulp van een SQL-instructie REFRESH of via de gebruikersinterface van de werkruimte.	Ontwikkelen, testen, ad-hoc updates.
TRIGGER ON UPDATE	Definieer de gerealiseerde weergave om automatisch te vernieuwen wanneer de upstream-gegevens worden gewijzigd.	Productieworkloads met SLA's voor gegevensnieuwheid of onvoorspelbare vernieuwingsperioden.
SCHEDULE	Definieer de gerealiseerde weergave om te vernieuwen met gedefinieerde tijdsintervallen.	Voorspelbare vernieuwingsvereisten op basis van tijd.
SQL-taak in een taakreeks	Vernieuwen wordt georkestreerd via Lakeflow-taken.	Complexe pijplijnen met afhankelijkheden tussen systemen.

Handmatig vernieuwen

Als u een gerealiseerde weergave handmatig wilt vernieuwen, kunt u een vernieuwing aanroepen vanuit Databricks SQL of de gebruikersinterface van de werkruimte gebruiken.

REFRESH verklaring

Een pijplijn vernieuwen met Databricks SQL:

1. Voer in de SQL Editor de volgende instructie uit:

   REFRESH MATERIALIZED VIEW <mv-name>;
   

Zie (REFRESH of MATERIALIZED VIEW)voor meer informatieSTREAMING TABLE.

Gebruikersinterface van werkruimte

Een pijplijn vernieuwen in de gebruikersinterface van de werkruimte:

1. Klik in de Azure Databricks-werkruimte op Taken en pijplijnen.
2. Selecteer de pijplijn die u wilt vernieuwen in de lijst.
3. Klik op de knop Start .

Als de pijplijn wordt bijgewerkt, ziet u updates in de UI.

Trigger bij een update

De TRIGGER ON UPDATE component vernieuwt automatisch een gerealiseerde weergave wanneer upstream-brongegevens worden gewijzigd. Dit elimineert de noodzaak om planningen in pijplijnen te coördineren. De gematerialiseerde weergave blijft actueel zonder dat de gebruiker hoeft te weten wanneer upstream-werkzaamheden zijn voltooid of complexe planningslogica hoeft bij te houden.

Dit is de aanbevolen benadering voor productieworkloads, met name wanneer upstream-afhankelijkheden niet worden uitgevoerd volgens voorspelbare planningen. Zodra de gerealiseerde weergave is geconfigureerd, worden de brontabellen gecontroleerd en automatisch vernieuwd wanneer wijzigingen in een van de upstream-bronnen worden gedetecteerd.

Beperkingen

• Limieten voor upstream-afhankelijkheid: een gerealiseerde weergave kan maximaal 10 upstream-tabellen en 30 upstreamweergaven bewaken. Splits de logica over meerdere gerealiseerde weergaven voor meer afhankelijkheden.
• Werkruimtelimieten: Er kunnen maximaal 1.000 gematerialiseerde weergaven per werkruimte met TRIGGER ON UPDATE bestaan. Neem contact op met databricks-ondersteuning als er meer dan 1000 gerealiseerde weergaven nodig zijn.
• Minimuminterval: het minimale triggerinterval is 1 minuut.

In de volgende voorbeelden ziet u hoe u een trigger instelt bij het bijwerken van een gematerialiseerde weergave.

Een gerealiseerde weergave maken met trigger bij het bijwerken

Als u een gerealiseerde weergave wilt maken die automatisch wordt vernieuwd wanneer de brongegevens worden gewijzigd, neemt u de TRIGGER ON UPDATE component in de CREATE MATERIALIZED VIEW instructie op.

In het volgende voorbeeld wordt een gerealiseerde weergave gemaakt waarmee klantorders worden samengevoegd en vernieuwd wanneer de bron customers of orders tabellen worden bijgewerkt:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Vernieuwingsfrequentie beperken

Als upstream-gegevens regelmatig worden vernieuwd, gebruik AT MOST EVERY om te beperken hoe vaak de weergave wordt vernieuwd en om de rekenkosten te beperken. Dit is handig wanneer brontabellen regelmatig worden bijgewerkt, maar downstreamgebruikers geen realtimegegevens nodig hebben. Het INTERVAL trefwoord is vereist vóór de tijdwaarde.

In het volgende voorbeeld wordt de gerealiseerde weergave maximaal elke 5 minuten vernieuwd, zelfs als de brongegevens vaker worden gewijzigd:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Geplande vernieuwing

Vernieuwingsschema's kunnen rechtstreeks in de gerealiseerde weergavedefinitie worden gedefinieerd om de weergave met vaste tijdsintervallen te vernieuwen. Deze methode is handig wanneer de frequentie van de gegevensupdate bekend is en voorspelbare vernieuwingstijdstijd is gewenst.

Wanneer er een vernieuwingsschema is, kunt u op elk gewenst moment nog steeds een handmatige vernieuwing uitvoeren als u bijgewerkte gegevens nodig hebt.

Databricks ondersteunt twee planningssyntaxis: SCHEDULE EVERY voor eenvoudige intervallen en SCHEDULE CRON voor nauwkeurige planning. De SCHEDULE trefwoorden en SCHEDULE REFRESH trefwoorden zijn semantisch gelijkwaardig.

Zie SCHEDULE voor meer informatie over de syntaxis en het gebruik van de CREATE MATERIALIZED VIEW component.

Wanneer een planning wordt gemaakt, wordt automatisch een nieuwe Databricks-taak geconfigureerd om de update te verwerken.

Gebruik een van de volgende methoden om de planning weer te geven:

• Voer de DESCRIBE EXTENDED instructie uit vanuit de SQL-editor in de Gebruikersinterface van Azure Databricks. Zie DESCRIBE TABLE.
• Gebruik Catalog Explorer om de gerealiseerde weergave weer te geven. Het schema staat vermeld op het tabblad Overzicht, onder Status vernieuwen. Zie Wat is Catalog Explorer?.

In de volgende voorbeelden ziet u hoe u een gerealiseerde weergave maakt met een schema:

Elke tijdsinterval plannen

In dit voorbeeld wordt een vernieuwing eenmaal per uur gepland:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

Plannen met cron

In dit voorbeeld wordt elke 15 minuten een vernieuwing gepland, op het kwartaaluur van de UTC-tijdzone:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

SQL-taak in een job

Materialized view-vernieuwingen kunnen worden georkestreerd via Databricks Jobs door SQL-taken aan te maken die opdrachten bevatten REFRESH MATERIALIZED VIEW. Deze aanpak integreert vernieuwingen van materialized views in bestaande werkstromen voor orkestratie van taken.

Er zijn twee manieren om een taak te maken voor het vernieuwen van gerealiseerde weergaven:

• Vanuit de SQL-editor: schrijf de REFRESH MATERIALIZED VIEW opdracht en klik op de knop Planning om rechtstreeks vanuit de query een taak te maken.
• Vanuit de Jobs-gebruikersinterface: maak een nieuwe taak, voeg een SQL-taaktype toe en koppel een SQL-query of notebook met de REFRESH MATERIALIZED VIEW opdracht.

In het volgende voorbeeld ziet u de SQL-instructie in een SQL-taak waarmee een gerealiseerde weergave wordt vernieuwd:

REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

Deze methode is geschikt wanneer:

• Complexe pijplijnen met meerdere stappen hebben afhankelijkheden in verschillende systemen.
• Integratie met bestaande taakindeling is vereist.
• Waarschuwingen en bewaking op taakniveau zijn nodig.

SQL-taken maken gebruik van zowel het SQL-warehouse dat is gekoppeld aan de taak als de serverloze berekening die de vernieuwing uitvoert. Als het gebruik van materialized view-definitie gebaseerde planning voldoet aan de vereisten, kunt u overschakelen naar TRIGGER ON UPDATE of SCHEDULE om de werkstroom te vereenvoudigen.

Een planning toevoegen aan een bestaande gerealiseerde weergave

Als u de planning wilt instellen na het maken, gebruikt u de ALTER MATERIALIZED VIEW instructie:

-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales
  ADD TRIGGER ON UPDATE;

Een bestaand schema of een bestaande trigger wijzigen

Als aan een gerealiseerde weergave al een planning of trigger is gekoppeld, gebruik dan ALTER SCHEDULE of ALTER TRIGGER ON UPDATE om de vernieuwingsconfiguratie te wijzigen. Dit geldt voor het wijzigen van het ene schema naar het andere, het wijzigen van de ene trigger naar de andere, of het schakelen tussen een schema en een trigger.

In het volgende voorbeeld wordt een bestaand schema om de 4 uur vernieuwd:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

Een schema of trigger verwijderen

Als u een schema wilt verwijderen, gebruikt u ALTER ... DROP:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

Stop een actieve vernieuwing

Als u een actieve vernieuwing in de Gebruikersinterface van Azure Databricks wilt stoppen, klikt u op de pagina Pijplijndetails op Stoppen om de pijplijnupdate te stoppen. U kunt het verversen ook stoppen met de Databricks CLI of de POST /api/2.0/pipelines/{pipeline_id}/stop operatie in de Pipelines-API.

Time-outs voor vernieuwingen

Materialized view-vernieuwingen worden uitgevoerd met een time-out die beperkt hoelang ze kunnen blijven draaien. Voor materiële weergaven die zijn gemaakt of bijgewerkt op of na 14 augustus 2025, wordt de time-out vastgelegd wanneer u bijwerkt door het volgende uit te voeren CREATE OR REFRESH.

• Als een STATEMENT_TIMEOUT waarde is ingesteld, wordt die waarde gebruikt. Zie STATEMENT_TIMEOUT.
• Anders wordt de time-out van het SQL-warehouse gebruikt om de opdracht uit te voeren.
• Als er geen time-out is geconfigureerd voor het magazijn, is een standaardwaarde van 2 dagen van toepassing.

De time-out wordt gebruikt bij de initiële creatie, maar ook bij geplande vernieuwingen die volgen.

Voor gematerialiseerde weergaven die vóór 14 augustus 2025 voor het laatst zijn bijgewerkt, is de time-out ingesteld op 2 dagen.

Voorbeeld: Een time-out instellen voor een gerealiseerde weergavevernieuwing U kunt expliciet bepalen hoelang een gerealiseerde weergavevernieuwing mag worden uitgevoerd door een time-out op instructieniveau in te stellen bij het maken of bijwerken van de weergave:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Hiermee wordt ingesteld dat de gerealiseerde weergave elke 12 uur wordt vernieuwd. Als het vernieuwen langer dan 6 uur duurt, treedt er een time-out op en wordt er gewacht op de volgende geplande vernieuwing.

Hoe geplande vernieuwingen time-outs verwerken

Tijdlimieten worden alleen gesynchroniseerd wanneer u expliciet CREATE OR REFRESH uitvoert.

• Geplande verversingen blijven de time-out gebruiken die tijdens de meest recente CREATE OR REFRESH is vastgelegd.
• Het wijzigen van de time-outperiode van het magazijn op zichzelf heeft geen invloed op bestaande geplande vernieuwingen.

Belangrijk

Nadat u een time-out voor een magazijn hebt gewijzigd, voert u CREATE OR REFRESH opnieuw uit om de nieuwe time-out toe te passen op toekomstige vernieuwingen.

records definitief verwijderen uit een gerealiseerde weergave met verwijderingsvectoren ingeschakeld

Belangrijk

Ondersteuning voor de REORG-instructie met gematerialiseerde weergaven bevindt zich in openbare preview.

Opmerking

• Voor het gebruik van een REORG-instructie met een gerealiseerde weergave is Databricks Runtime 15.4 en hoger vereist.
• Hoewel u de REORG instructie kunt gebruiken met een gerealiseerde weergave, is dit alleen vereist wanneer u records verwijdert uit een gerealiseerde weergave waarvoor verwijderingsvectoren zijn ingeschakeld. De opdracht heeft geen effect wanneer deze wordt gebruikt met een gerealiseerde weergave zonder verwijderingsvectoren ingeschakeld.

Als u records fysiek wilt verwijderen uit de onderliggende opslag voor een gerealiseerde weergave waarvoor verwijderingsvectoren zijn ingeschakeld, zoals voor AVG-naleving, moeten er aanvullende stappen worden ondernomen om ervoor te zorgen dat een VACUUM bewerking wordt uitgevoerd op de gerealiseerde gegevens van de gerealiseerde weergave.

Records fysiek verwijderen:

1. Voer een REORG-instructie uit voor de gematerialiseerde weergave, waarbij u de parameter APPLY (PURGE) opgeeft. Bijvoorbeeld REORG TABLE <materialized-view-name> APPLY (PURGE);. Zie REORG TABLE.
2. Wacht totdat de gegevensretentieperiode van de gerealiseerde weergave is verstreken. De standaardperiode voor gegevensretentie is zeven dagen, maar kan worden geconfigureerd met de eigenschap delta.deletedFileRetentionDuration tabel. Zie Gegevensretentie configureren voor tijdreis-query's.
3. REFRESH de gematerialiseerde weergave. Zie Een Gematerialiseerde Weergave Vernieuwen. Binnen 24 uur na de REFRESH bewerking worden pijplijnonderhoudstaken, inclusief de VACUUM bewerking die nodig is om ervoor te zorgen dat records permanent worden verwijderd, automatisch uitgevoerd.

Een materiële weergave verwijderen

Opmerking

Als u de opdracht wilt verzenden om een gerealiseerde weergave te verwijderen, moet u de eigenaar van die gerealiseerde weergave zijn of de bevoegdheid MANAGE voor de gerealiseerde weergave hebben.

Als u een gerealiseerde weergave wilt verwijderen, gebruikt u de instructie DROP VIEW. Als u een DROP instructie wilt verzenden, kunt u de SQL-editor gebruiken in de Gebruikersinterface van Azure Databricks, de Databricks SQL CLI of de Databricks SQL-API. In het volgende voorbeeld wordt de mv1 gerealiseerde weergave verwijderd.

DROP MATERIALIZED VIEW mv1;

U kunt ook de Catalog Explorer gebruiken om een materialized view te verwijderen.

1. Klik op Catalogus in de zijbalk.
2. Open in de boomstructuur van Catalogusverkenner aan de linkerkant de catalogus en selecteer het schema waarin de gematerialiseerde weergave zich bevindt.
3. Open het -item Tabellen onder het door u geselecteerde schema en klik op de gematerialiseerde weergave.
4. Selecteer Kebab menu icon.Verwijderen in het .

Inzicht in de kosten van een geënmaterialiseerde weergave

Omdat een gerealiseerde weergave wordt uitgevoerd in serverloze berekeningen, buiten de berekening die u hebt ingesteld voor een notebook of taak, vraagt u zich misschien af hoe u inzicht krijgt in de kosten die eraan zijn gekoppeld. Gerealiseerde weergavegebruik wordt bijgehouden door DBU-verbruik. Voor meer informatie, zie Wat is het DBU-verbruik van een materialized view of streamingtabel?

Rijtracking inschakelen

Om incrementele vernieuwingen van Delta-tabellen te ondersteunen, moet het bijhouden van rijen zijn ingeschakeld voor deze brontabellen. Als u een brontabel opnieuw maakt, moet u het bijhouden van rijen opnieuw inschakelen.

In het volgende voorbeeld ziet u hoe u rijtracering voor een tabel inschakelt:

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Zie Rijtracering in Databricks voor meer informatie

Beperkingen

• Zie Vereisten voor reken- en werkruimtevereisten.
• Zie voor incrementele vernieuwingsvereisten Incrementele vernieuwing voor gematerialiseerde weergaven.
• Gematerialiseerde weergaven bieden geen ondersteuning voor identiteitskolommen of surrogaatsleutels.
• Als een gerealiseerde weergave gebruikmaakt van een somaggregatie over een NULL-able kolom en alleen NULL waarden in die kolom blijven, is de resulterende geaggregeerde waarde van de gerealiseerde weergave nul in plaats van NULL.
• U kunt een wijzigingsgegevensfeed niet lezen vanuit een materiële weergave.
• Queries voor tijdreizen worden niet ondersteund op gematerialiseerde weergaven.
• De onderliggende bestanden die gerealiseerde weergaven ondersteunen, bevatten mogelijk gegevens uit upstreamtabellen (inclusief mogelijke persoonsgegevens) die niet worden weergegeven in de gerealiseerde weergavedefinitie. Deze gegevens worden automatisch toegevoegd aan de onderliggende opslag ter ondersteuning van incrementeel vernieuwen van gerealiseerde weergaven. Omdat de onderliggende bestanden van een gerealiseerde weergave mogelijk risico lopen dat gegevens uit upstream-tabellen worden weergegeven die geen deel uitmaken van het gerealiseerde weergaveschema, raadt Databricks aan om de onderliggende opslag niet te delen met niet-vertrouwde downstreamgebruikers. Stel dat de definitie van een gerealiseerde weergave een COUNT(DISTINCT field_a) component bevat. Hoewel de gerealiseerde weergavedefinitie alleen de aggregatie COUNT DISTINCT clausule bevat, zullen de onderliggende bestanden een lijst bevatten met de daadwerkelijke waarden van field_a.
• Er kunnen serverloze rekenkosten in rekening worden gebracht, zelfs wanneer u deze functies op toegewezen rekenkracht gebruikt.

• Als u een Azure Private Link-verbinding met uw gerealiseerde weergave wilt gebruiken, neemt u contact op met uw Databricks-vertegenwoordiger.

Toegang tot gerealiseerde weergaven van externe clients

Als u toegang wilt krijgen tot gerealiseerde weergaven van externe Delta Lake- of Iceberg-clients die geen ondersteuning bieden voor open API's, kunt u de compatibiliteitsmodus gebruiken. De compatibiliteitsmodus maakt een alleen-lezen versie van uw gematerialiseerde weergave die toegankelijk is voor elke Delta Lake- of Iceberg-client.

Verwante artikelen

• Gerealiseerde weergaven configureren in Databricks SQL
• Gematerialiseerde weergaven bewaken in Databricks SQL
• Streamingtabellen gebruiken in Databricks SQL