Streamingtabellen gebruiken in Databricks SQL

Databricks raadt het gebruik van streamingtabellen aan om gegevens op te nemen met Databricks SQL. Een streamingtabel is een tabel die is geregistreerd bij Unity Catalog met extra ondersteuning voor streaming of incrementele gegevensverwerking. Er wordt automatisch een pijplijn gemaakt voor elke streamingtabel. U kunt streamingtabellen gebruiken voor het laden van incrementele gegevens vanuit Kafka en cloudobjectopslag.

Opmerking

Lees hoe u Delta Lake-tabellen als streamingbronnen en afvoerpunten kunt gebruiken in Delta tabel streaming leest en schrijft.

Requirements

Als u streamingtabellen wilt gebruiken, moet u voldoen aan de volgende vereisten.

Vereisten voor werkruimte:

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

Een Azure Databricks-account met ingeschakelde serverless functionaliteit. Zie Serverloze SQL-warehouses inschakelen voor meer informatie.
Een werkruimte waarvoor Unity Catalog is ingeschakeld. Zie Aan de slag met Unity Catalog voor meer informatie.

Rekenvereisten:

U moet een van de volgende handelingen gebruiken:

Een SQL Warehouse dat gebruikmaakt van het Current kanaal.
Compute met de standaardtoegangsmodus (voorheen modus voor gedeelde toegang) in Databricks Runtime 13.3 LTS of hoger.

Compute met toegewezen toegangsmodus (voorheen modus voor toegang van één gebruiker) in Databricks Runtime 15.4 LTS of hoger.

In Databricks Runtime 15.3 en lager kunt u geen toegewezen rekenkracht gebruiken om streamingtabellen op te vragen die eigendom zijn van andere gebruikers. U kunt toegewezen rekenkracht alleen gebruiken voor Databricks Runtime 15.3 en lager als u eigenaar bent van de streamingtabel. De maker van de tabel is de eigenaar.

Databricks Runtime 15.4 LTS en hoger bieden ondersteuning voor het uitvoeren van query's op tabellen die door een pijplijn zijn gegenereerd op toegewezen rekenkracht, zelfs als u niet de eigenaar van de tabel bent. Er kunnen kosten in rekening worden gebracht voor serverloze rekenresources wanneer u toegewezen berekeningen gebruikt om gegevensfilterbewerkingen uit te voeren. Zie Gedetailleerd toegangsbeheer voor toegewezen berekeningen.

Vereisten voor machtigingen:

USE CATALOG en USE SCHEMA rechten voor de catalogus en het schema waarin u de streamingtabel maakt.
De CREATE TABLE bevoegdheid voor het schema waarin u de streamingtabel maakt.
Bevoegdheden voor toegang tot de tabellen of locaties die de brongegevens voor uw streamingtabel bieden.

Streamingtabellen maken

Een streamingtabel wordt gedefinieerd door een SQL-query in Databricks SQL. Wanneer u een streamingtabel maakt, worden de gegevens die zich momenteel in de brontabellen bevinden, gebruikt om de streamingtabel te bouwen. Daarna vernieuwt u de tabel, meestal volgens een schema, om toegevoegde gegevens in de brontabellen op te halen om toe te voegen aan de streamingtabel.

Wanneer u een streamingtabel maakt, wordt u beschouwd als de eigenaar van de tabel.

Als u een streamingtabel wilt maken op basis van een bestaande tabel, gebruikt u de CREATE STREAMING TABLE instructie, zoals in het volgende voorbeeld:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT product, price FROM STREAM raw_data;

In dit geval wordt de streamingtabel sales gemaakt op basis van specifieke kolommen van de raw_data tabel, met een schema om elk uur te vernieuwen. De gebruikte query moet een streamingquery zijn. Gebruik het STREAM trefwoord om streamingsemantiek toe te passen en uit de bron te lezen.

Wanneer u een streamingtabel maakt met behulp van de CREATE OR REFRESH STREAMING TABLE instructie, beginnen de eerste gegevensvernieuwing en populatie onmiddellijk. Deze bewerkingen verbruiken geen DBSQL-warehouse-rekenkracht. In plaats daarvan zijn streamingtabellen afhankelijk van serverloze pijplijnen voor zowel het maken als het vernieuwen. Er wordt automatisch een toegewezen serverloze pijplijn gemaakt en beheerd door het systeem voor elke streamingtabel.

Bestanden laden met Auto Loader

Als u een streamingtabel wilt maken op basis van bestanden in een volume, gebruikt u Auto Loader. Gebruik Automatisch laden voor de meeste gegevensopnametaken uit de opslag van cloudobjecten. Automatische laadprogramma's en pijplijnen zijn ontworpen om steeds groeiende gegevens incrementeel en idempotent te laden wanneer ze binnenkomen in de cloudopslag.

Als u automatisch laden wilt gebruiken in Databricks SQL, gebruikt u de read_files functie. In de volgende voorbeelden ziet u hoe u automatisch laden gebruikt om een volume van JSON-bestanden te lezen in een streamingtabel:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT * FROM STREAM read_files(
    "/Volumes/my_catalog/my_schema/my_volume/path/to/data",
    format => "json"
  );

Als u gegevens uit de cloudopslag wilt lezen, kunt u ook automatisch laden gebruiken:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    'abfss://myContainer@myStorageAccount.dfs.core.windows.net/analysis/*/*/*.json',
    format => "json"
  );

Zie Wat is Automatisch laadprogramma?voor meer informatie over Automatisch laden. Zie Voor meer informatie over het gebruik van Automatisch laden in SQL, met voorbeelden, gegevens uit objectopslag laden.

Streaminginvoer van andere bronnen

Zie bijvoorbeeld Gegevens laden in pijplijnen voor opname uit andere bronnen, waaronder Kafka.

Alleen nieuwe gegevens opnemen

De functie read_files leest standaard alle bestaande gegevens in de bronmap tijdens het maken van de tabel en verwerkt vervolgens nieuwe binnenkomende records bij elke vernieuwing.

Als u wilt voorkomen dat gegevens worden opgenomen die al aanwezig zijn in de bronmap op het moment dat de tabel is gemaakt, stelt u de optie includeExistingFiles in op false. Dit betekent dat alleen gegevens die in de map binnenkomen nadat de tabel is gemaakt, zijn verwerkt. Voorbeeld:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    '/path/to/files',
    includeExistingFiles => false
  );

Stel het runtimekanaal in

Streamingtabellen die zijn gemaakt met behulp van SQL-warehouses, worden automatisch vernieuwd met behulp van een pijplijn. Pijplijnen maken standaard gebruik van de runtime in het current kanaal. Zie de releaseopmerkingen van Lakeflow Spark Declarative Pipelines en het release-upgradeproces voor meer informatie over het releaseproces.

Databricks raadt het gebruik van het current kanaal aan voor productieworkloads. Nieuwe functies worden voor het eerst uitgebracht voor het preview kanaal. U kunt een pijplijn instellen op het preview-kanaal om nieuwe functies te testen door deze preview op te geven als een tabeleigenschap. U kunt deze eigenschap opgeven wanneer u de tabel maakt of nadat de tabel is gemaakt met behulp van een ALTER-instructie.

In het volgende codevoorbeeld ziet u hoe u het kanaal instelt op preview in een CREATE-instructie:

CREATE OR REFRESH STREAMING TABLE sales
  TBLPROPERTIES ('pipelines.channel' = 'preview')
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM raw_data;

Vernieuwingen van streamingtabellen plannen

U kunt een Databricks SQL-streamingtabel configureren om automatisch te vernieuwen op basis van een gedefinieerd schema of om te activeren wanneer upstream-gegevens worden gewijzigd.

Ga op een van de volgende manieren te werk om een planning of trigger in te stellen:

Configureer het schema met de SCHEDULE component wanneer u de streamingtabel maakt.
Configureer een trigger met de TRIGGER ON UPDATE component wanneer u de tabel maakt.
Voeg planningen of triggers toe of wijzig deze met de ALTER STREAMING TABLE instructie.

Opmerking

U kunt ook een taak maken in een taak die de CREATE OR REFRESH STREAMING TABLE of een REFRESH instructie bevat en deze op dezelfde manier indelen als elke andere taak. Zie Lakeflow Jobs.

Wanneer u een planning maakt, maakt Azure Databricks automatisch een nieuwe taak 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 streamingtabel weer te geven. Het schema staat vermeld op het tabblad Overzicht, onder Status vernieuwen. Zie Wat is Catalog Explorer?.

Zelfs met een vernieuwingsschema kunt u op elk gewenst moment een handmatige vernieuwing uitvoeren als u bijgewerkte gegevens nodig hebt.

Gevoelige gegevens verbergen

U kunt streamingtabellen gebruiken om gevoelige gegevens te verbergen voor gebruikers die toegang hebben tot de tabel. Eén benadering is het definiëren van de query, zodat gevoelige kolommen of rijen volledig worden uitgesloten. U kunt ook kolommaskers of rijfilters toepassen 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 streamingtabel. Zie Rijfilters en kolommaskers voor meer informatie.

Een streamingtabel vernieuwen

Vernieuwingen kunnen automatisch worden gepland wanneer u de streamingtabel maakt. U kunt streamingtabellen ook handmatig vernieuwen. Zelfs als u een geplande vernieuwing hebt, kunt u op elk gewenst moment een handmatige vernieuwing aanroepen. Vernieuwingen worden verwerkt door dezelfde pijplijn die automatisch is gemaakt samen met de streaming tabel.

Een streamingtabel vernieuwen:

REFRESH STREAMING TABLE sales;

U kunt de status van de meest recente vernieuwing controleren met DESCRIBE TABLE EXTENDED.

Opmerking

Wellicht moet u de streamingtabel vernieuwen voordat u queries over tijdreizen uitvoert.

Hoe vernieuwen werkt

Bij het vernieuwen van een streamingtabel worden alleen nieuwe rijen geëvalueerd die sinds de laatste update zijn aangekomen en worden alleen de nieuwe gegevens toegevoegd.

Elke vernieuwing maakt gebruik van de huidige definitie van de streamingtabel om deze nieuwe gegevens te verwerken. Als u een definitie van een streamingtabel wijzigt, worden bestaande gegevens niet automatisch opnieuw berekend. Als een wijziging niet compatibel is met bestaande gegevens (bijvoorbeeld het wijzigen van een gegevenstype), mislukt de volgende vernieuwing met een fout.

In de volgende voorbeelden wordt uitgelegd hoe wijzigingen in een definitie van een streamingtabel van invloed zijn op het vernieuwingsgedrag:

Als u een filter verwijdert, worden eerder gefilterde rijen niet opnieuw verwerkt.
Het wijzigen van kolomprojecties heeft geen invloed op de wijze waarop bestaande gegevens zijn verwerkt.
Joins met statische momentopnamen maken gebruik van de status van de momentopname op het moment van de initiële verwerking. Vertraagde binnenkomende gegevens die overeenkomen met de bijgewerkte momentopname, worden genegeerd. Dit kan ertoe leiden dat feiten worden verwijderd als dimensies te laat zijn.
Als u de CAST van een bestaande kolom wijzigt, treedt er een fout op.

Als uw gegevens worden gewijzigd op een manier die niet kan worden ondersteund in de bestaande streamingtabel, kunt u een volledige vernieuwing uitvoeren.

Een streamingtabel volledig vernieuwen

Alle beschikbare gegevens in de bron worden opnieuw verwerkt met de meest recente definitie. Het is niet raadzaam om volledige vernieuwingen aan te roepen voor bronnen die de volledige geschiedenis van de gegevens niet behouden of korte bewaarperioden hebben, zoals Kafka, omdat de volledige vernieuwing de bestaande gegevens afkapt. Mogelijk kunt u oude gegevens niet herstellen als de gegevens niet meer beschikbaar zijn in de bron.

Voorbeeld:

REFRESH STREAMING TABLE sales FULL;

Het schema voor een streamingtabel wijzigen

U kunt een Databricks SQL-streamingtabel 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 streamingtabel die automatisch moet worden vernieuwd wanneer de upstream-gegevens worden gewijzigd.	Productieworkloads met SLA's voor gegevensnieuwheid of onvoorspelbare vernieuwingsperioden.
`SCHEDULE`	Definieer de streamingtabel die moet worden vernieuwd 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 streamingtabel 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:

Voer in de SQL Editor de volgende instructie uit:
```
REFRESH MATERIALIZED VIEW <table-name>;
```

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

Gebruikersinterface van werkruimte

Een pijplijn vernieuwen in de gebruikersinterface van de werkruimte:

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

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

Trigger bij bijwerken

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

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

Beperkingen

Upstream-afhankelijkheidslimieten: een streamingtabel kan maximaal 10 upstream-tabellen en 30 upstreamweergaven bewaken. Splits de logica over meerdere streamingtabellen voor meer afhankelijkheden.
Werkruimtelimieten: er kunnen maximaal 1000 streamingtabellen bestaan TRIGGER ON UPDATE per werkruimte. Neem contact op met databricks-ondersteuning als er meer dan 1000 streamingtabellen nodig zijn.
Minimuminterval: het minimale triggerinterval is 1 minuut.

In de volgende voorbeelden ziet u hoe u een trigger instelt bij het bijwerken bij het definiëren van een streamingtabel.

Een streamingtabel maken met een bijwerken-trigger

Als u een streamingtabel wilt maken die automatisch wordt vernieuwd wanneer de brongegevens worden gewijzigd, neemt u de TRIGGER ON UPDATE component in de CREATE STREAMING TABLE instructie op.

In het volgende voorbeeld wordt een streamingtabel gemaakt waarmee klantorders worden gelezen en vernieuwd wanneer de brontabel orders wordt bijgewerkt:

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

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 streamingtabel maximaal elke 5 minuten vernieuwd, zelfs als brongegevens vaker worden gewijzigd:

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Geplande vernieuwing

Vernieuwingsschema's kunnen rechtstreeks in de definitie van de streamingtabel 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 STREAMING TABLE 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 streamingtabel 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 streamingtabel maakt met een schema:

Elke tijdsinterval plannen

In dit voorbeeld wordt elke 5 minuten een vernieuwing gepland:

CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE EVERY 5 MINUTES
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

Plannen met cron

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

CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

SQL-taak in een job

Vernieuwingen van streamingtabellen kunnen worden georkestreerd via Databricks-taken door SQL-taken te maken die REFRESH STREAMING TABLE-opdrachten bevatten. Met deze benadering worden streamingtabelvernieuwingen geïntegreerd in bestaande werkstromen voor taakindeling.

Er zijn twee manieren om een taak te maken voor het verversen van streaming-tabellen:

Vanuit de SQL-editor: schrijf de REFRESH STREAMING TABLE 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 STREAMING TABLE opdracht.

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

REFRESH STREAMING TABLE catalog.schema.sales;

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 planning op basis van streamingtabeldefinities aan de vereisten voldoet, kunt u overschakelen naar TRIGGER ON UPDATE of SCHEDULE om de werkstroom te vereenvoudigen.

Een planning toevoegen aan een bestaande streamingtabel

Als u de planning wilt instellen na het maken, gebruikt u de ALTER STREAMING TABLE instructie:

-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
  ADD TRIGGER ON UPDATE;

Een bestaand schema of een bestaande trigger wijzigen

Als aan een streamingtabel al een schema of trigger is gekoppeld, gebruikt u 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 5 minuten vernieuwd:

ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE EVERY 5 MINUTES;

Een schema of trigger verwijderen

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

ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

De status van een vernieuwing bijhouden

U kunt de status van een streamingtabelvernieuwing bekijken door de pijplijn te bekijken die de streamingtabel beheert in de gebruikersinterface van pijplijnen of door de vernieuwingsgegevens weer te geven die door de DESCRIBE EXTENDED opdracht voor de streamingtabel worden geretourneerd.

DESCRIBE TABLE EXTENDED <table-name>;

U kunt de streamingtabel ook bekijken in Catalog Explorer en de status van de vernieuwing daar bekijken:

Klik op Catalogus in de zijbalk.
Open de catalogus in de boomstructuur van de Catalog Explorer aan de linkerkant en selecteer het schema waar de streamingtabel zich bevindt.
Open het item Tabellen onder het schema dat u hebt geselecteerd en klik op de streamingtabel.

Hier kunt u de tabbladen onder de naam van de streamingtabel gebruiken om informatie over de streamingtabel weer te geven en te bewerken, waaronder:

Status en geschiedenis vernieuwen
Het tabelschema
Voorbeeldgegevens (vereist een actieve berekening)
Permissions
Herkomst, inclusief tabellen en pijplijnen waarvan deze streamingtabel afhankelijk is
Inzicht in gebruik
Monitors die u hebt gemaakt voor deze streamingtabel

Time-outs voor vernieuwingen

Vernieuwingen van streamingtabellen worden uitgevoerd met een time-out waarmee wordt beperkt hoe lang ze kunnen worden uitgevoerd. Voor streamingtabellen 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 streamingtabellen die voor het laatst zijn bijgewerkt vóór 14 augustus 2025, is de time-out ingesteld op 2 dagen.

Voorbeeld: Een time-out instellen voor het vernieuwen van een streamingtabel U kunt expliciet bepalen hoe lang het vernieuwen van een streamingtabel mag worden uitgevoerd door een time-out op instructieniveau in te stellen bij het maken of bijwerken van de tabel:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH STREAMING TABLE my_catalog.my_schema.my_st
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Hiermee wordt ingesteld dat de streamingtabel 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.

Het beheer van de toegang tot streamingtabellen

Streamingtabellen ondersteunen uitgebreide toegangscontrole om gegevensdeling mogelijk te maken, terwijl tegelijkertijd wordt voorkomen dat mogelijk privégegevens worden blootgesteld. Een eigenaar van een streamingtabel of een gebruiker met de MANAGE bevoegdheid kan bevoegdheden verlenen SELECT aan andere gebruikers. Gebruikers met SELECT toegang tot de streamingtabel hebben geen toegang nodig SELECT tot de tabellen waarnaar wordt verwezen door de streamingtabel. Met dit toegangsbeheer kunt u gegevens delen terwijl u de toegang tot de onderliggende gegevens beheert.

U kunt ook de eigenaar van een streamingtabel wijzigen.

Bevoegdheden verlenen aan een streamingtabel

Gebruik de GRANT instructie om toegang te verlenen tot een streamingtabel:

GRANT <privilege_type> ON <st_name> TO <principal>;

Dit privilege_type kan het volgende zijn:

SELECT - de gebruiker kan SELECT de streaming-tabel.
REFRESH - de gebruiker kan REFRESH de streaming-tabel. Vernieuwingen worden uitgevoerd met behulp van de machtigingen van de eigenaar.

In het volgende voorbeeld wordt een streamingtabel gemaakt en worden machtigingen voor selecteren en vernieuwen verleend aan gebruikers:

CREATE MATERIALIZED VIEW st_name AS SELECT * FROM source_table;

-- Grant read-only access:
GRANT SELECT ON st_name TO read_only_user;

-- Grand read and refresh access:
GRANT SELECT ON st_name TO refresh_user;
GRANT REFRESH ON st_name TO refresh_user;

Zie Unity Catalog-bevoegdheden en beveiligbare objecten voor meer informatie over het verlenen van bevoegdheden voor unity-catalogusobjecten.

Bevoegdheden van een streamingtabel intrekken

Als u de toegang vanuit een streamingtabel wilt intrekken, gebruikt u de REVOKE instructie:

REVOKE privilege_type ON <st_name> FROM principal;

Wanneer de bevoegdheden SELECT voor een brontabel worden ingetrokken van de eigenaar van de streamingtabel of van een andere gebruiker die de bevoegdheden MANAGE of SELECT op de streamingtabel heeft gekregen, of wanneer de brontabel wordt verwijderd, kan de eigenaar van de streamingtabel of de gebruiker die toegang heeft gekregen nog steeds queries op de streamingtabel uitvoeren. Het volgende gedrag treedt echter op:

De eigenaar van de streamingtabel of anderen die geen toegang meer hebben tot een streamingtabel, kan deze streamingtabel niet meer REFRESH gebruiken en de streamingtabel wordt verouderd.
Als het geautomatiseerd is met een schema, mislukt de volgende geplande REFRESH-bewerking of wordt deze niet uitgevoerd.

In het volgende voorbeeld wordt de SELECT bevoegdheid ingetrokken van read_only_user:

REVOKE SELECT ON st_name FROM read_only_user;

De eigenaar van een streamingtabel wijzigen

Een gebruiker met MANAGE machtigingen voor een streamingtabel die is gedefinieerd in Databricks SQL, kan een nieuwe eigenaar instellen via Catalog Explorer. De nieuwe eigenaar kan zichzelf zijn of een service principal waarvoor ze de rol Service Principal User hebben.

Klik in uw Azure Databricks-werkruimte op Catalogus om de Catalogusverkenner te openen.
Selecteer de streamingtabel die u wilt bijwerken.
Zoek in de rechterzijbalk onder Over deze streamingtabel de eigenaar en klik op het om te bewerken.

Opmerking

Als u een bericht krijgt waarin wordt aangegeven dat u de eigenaar moet bijwerken door de Run as-gebruiker te wijzigen in de pijplijninstellingen, wordt de streamingtabel gedefinieerd in declaratieve Pijplijnen van Lakeflow Spark, niet in Databricks SQL. Het bericht bevat een koppeling naar de pijplijninstellingen, waar u de Run as-gebruiker kunt wijzigen.
Selecteer een nieuwe eigenaar voor de streamingtabel.

Eigenaren hebben automatisch MANAGE en SELECT bevoegdheden voor streamingtabellen die ze bezitten. Als u een service-principal als eigenaar van een streamingtabel instelt die u bezit en u niet expliciet beschikt over SELECT of MANAGE bevoegdheden voor de streamingtabel, zou deze wijziging ertoe leiden dat u alle toegang tot de streamingtabel kwijtraakt. In dit geval wordt u gevraagd deze bevoegdheden expliciet op te geven.

Selecteer zowel Manage verlenen als Bevoegdheden verlenen SELECT om machtigingen op te geven bij Opslaan.
Klik op Opslaan om de eigenaar te wijzigen.

De eigenaar van de streamingtabel wordt bijgewerkt. Alle toekomstige updates worden uitgevoerd met behulp van de identiteit van de nieuwe eigenaar.

Wanneer de eigenaar bevoegdheden voor brontabellen verliest

Als u de eigenaar wijzigt en de nieuwe eigenaar geen toegang heeft tot de brontabellen (of SELECT bevoegdheden worden ingetrokken voor de onderliggende brontabellen), kunnen gebruikers nog steeds een query uitvoeren op de streamingtabel. Aan de andere kant:

Ze kunnen de streamingtabel niet wijzigen.
De volgende geplande vernieuwing van de streamingtabel mislukt.

Als de toegang tot de brongegevens verloren gaat, worden updates niet meer verwerkt, maar kan de bestaande streamingtabel nog steeds gelezen worden en wordt deze niet direct ongeldig.

records definitief verwijderen uit een streamingtabel

Belangrijk

Ondersteuning voor de REORG instructie met streamingtabellen bevindt zich in Openbare Preview.

Opmerking

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

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

Records fysiek verwijderen uit onderliggende opslag:

Records bijwerken of records verwijderen uit de streamingtabel.
Voer een REORG-instructie uit voor de streamingtabel en geef de parameter APPLY (PURGE) op. Bijvoorbeeld REORG TABLE <streaming-table-name> APPLY (PURGE);.
Wacht tot de gegevensretentieperiode van de streamingtabel 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.
REFRESH de streaming-tabel. Zie Een streamingtabel 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.

Query-uitvoeringen bewaken door middel van querygeschiedenis

U kunt de pagina querygeschiedenis gebruiken om toegang te krijgen tot querydetails en queryprofielen waarmee u slecht presterende query's en knelpunten in de pijplijn kunt identificeren die worden gebruikt voor het uitvoeren van updates voor de streamingtabel. Zie Querygeschiedenis en Queryprofiel voor een overzicht van het soort informatie dat beschikbaar is in querygeschiedenissen en queryprofielen.

Belangrijk

Deze functie bevindt zich in openbare preview-versie. Werkruimtebeheerders kunnen de toegang tot deze functie beheren vanaf de pagina Previews . Zie Azure Databricks-previews beheren.

Alle instructies met betrekking tot streamingtabellen worden weergegeven in de querygeschiedenis. U kunt het vervolgkeuzefilter Instructie gebruiken om een opdracht te selecteren en de gerelateerde query's te inspecteren. Alle CREATE instructies worden gevolgd door een REFRESH instructie die asynchroon wordt uitgevoerd op een pijplijn. De REFRESH instructies bevatten doorgaans gedetailleerde queryplannen die inzicht bieden in het optimaliseren van de prestaties.

Gebruik de volgende stappen om toegang te krijgen tot REFRESH instructies in de gebruikersinterface van de querygeschiedenis:

Klik op Klik in de linkerzijbalk om de gebruikersinterface van querygeschiedenis te openen.
Selecteer het selectievakje REFRESH in de vervolgkeuzelijstfilter Verklaring.
Klik op de naam van de query om overzichtsdetails weer te geven, zoals de duur van de query en geaggregeerde metrieken.
Klik op Queryprofiel weergeven om het queryprofiel te openen. Zie Het queryprofiel voor meer informatie over het navigeren in het queryprofiel.
U kunt eventueel de koppelingen in de sectie Querybron gebruiken om de gerelateerde query of pijplijn te openen.

U kunt ook toegang krijgen tot querygegevens met behulp van koppelingen in de SQL-editor of vanuit een notebook dat is gekoppeld aan een SQL-warehouse.

Toegang tot streamingtabellen van externe clients

Als u toegang wilt krijgen tot streamingtabellen 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 streamingtabel die toegankelijk is voor elke Delta Lake- of Iceberg-client.

Aanvullende bronnen

Feedback

Is deze pagina nuttig?

Last updated on 2026-02-04

Delen via

Streamingtabellen gebruiken in Databricks SQL

Requirements

Streamingtabellen maken

Bestanden laden met Auto Loader

Streaminginvoer van andere bronnen

Alleen nieuwe gegevens opnemen

Stel het runtimekanaal in

Vernieuwingen van streamingtabellen plannen

Gevoelige gegevens verbergen

Een streamingtabel vernieuwen

Hoe vernieuwen werkt

Een streamingtabel volledig vernieuwen

Het schema voor een streamingtabel wijzigen

Handmatig vernieuwen

REFRESH verklaring

Gebruikersinterface van werkruimte

Trigger bij bijwerken

Geplande vernieuwing

SQL-taak in een job

Een planning toevoegen aan een bestaande streamingtabel

Een bestaand schema of een bestaande trigger wijzigen

Een schema of trigger verwijderen

De status van een vernieuwing bijhouden

Time-outs voor vernieuwingen

Hoe geplande vernieuwingen time-outs verwerken

Het beheer van de toegang tot streamingtabellen

Bevoegdheden verlenen aan een streamingtabel

Bevoegdheden van een streamingtabel intrekken

De eigenaar van een streamingtabel wijzigen

Wanneer de eigenaar bevoegdheden voor brontabellen verliest

records definitief verwijderen uit een streamingtabel

Query-uitvoeringen bewaken door middel van querygeschiedenis

Toegang tot streamingtabellen van externe clients

Aanvullende bronnen

Feedback

Aanvullende resources