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.

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.

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.

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 schema voor automatische vernieuwing voor uw streamingtabel wijzigen (of instellen). In de volgende voorbeelden ziet u hoe u een planning instelt met behulp van ALTER STREAMING TABLE:

ALTER STREAMING TABLE sales
  ADD SCHEDULE EVERY 1 HOUR;

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

Voor voorbeelden van het vernieuwen van schemaquery's, zie ALTER STREAMING TABLE.

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:

1. Klik op Catalogus in de zijbalk.
2. Open de catalogus in de boomstructuur van de Catalog Explorer aan de linkerkant en selecteer het schema waar de streamingtabel zich bevindt.
3. 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

Langdurige vernieuwingen kunnen time-outs hebben. Streamingtabellen die zijn gemaakt of vernieuwd na 14 augustus 2025, gebruiken de time-out die is gekoppeld aan het SQL-warehouse dat wordt gebruikt om de vernieuwing uit te voeren. Als er geen time-out is ingesteld voor het magazijn, wordt de standaardwaarde van 2 dagen gebruikt.

U kunt de time-out expliciet instellen met een STATEMENT_TIMEOUT configuratie in uw SQL voor de vernieuwing. Zie STATEMENT_TIMEOUT.

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.

1. Klik in uw Azure Databricks-werkruimte op Catalogus om de Catalogusverkenner te openen.

2. Selecteer de streamingtabel die u wilt bijwerken.

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

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

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

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:

1. Records bijwerken of records verwijderen uit de streamingtabel.
2. Voer een REORG-instructie uit voor de streamingtabel en geef de parameter APPLY (PURGE) op. Bijvoorbeeld REORG TABLE <streaming-table-name> APPLY (PURGE);.
3. 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.
4. 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.

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:

1. Klik op Klik in de linkerzijbalk om de gebruikersinterface van querygeschiedenis te openen.
2. Selecteer het selectievakje REFRESH in de vervolgkeuzelijstfilter Verklaring.
3. Klik op de naam van de query om overzichtsdetails weer te geven, zoals de duur van de query en geaggregeerde metrieken.
4. Klik op Queryprofiel weergeven om het queryprofiel te openen. Zie Het queryprofiel voor meer informatie over het navigeren in het queryprofiel.
5. 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

• Declaratieve Pijplijnen van Lakeflow Spark
• read_files tabelgewaardeerde functie
• read_kafka tabelgewaardeerde functie
• CREATE STREAMING TABLE
• ALTER STREAMING TABLE
• Gerealiseerde weergaven gebruiken in Databricks SQL