Share via

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.

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 worden mogelijk kosten in rekening 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.

Rekenkracht die wordt gebruikt voor vernieuwen

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 Databricks SQL Warehouse-rekenproces. In plaats daarvan zijn streamingtabellen afhankelijk van serverloze pijplijnen voor zowel het maken als 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 leest standaard read_files alle bestaande gegevens in de bronmap tijdens het maken van de tabel en verwerkt vervolgens zojuist binnenkomende records bij elke vernieuwing.

Als u wilt voorkomen dat gegevens worden opgenomen die al in de bronmap aanwezig zijn op het moment dat de tabel is gemaakt, stelt u de includeExistingFiles optie 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 op te geven preview als een tabeleigenschap met behulp van een CREATE OR REFRESH STREAMING TABLE instructie. Als u het kanaal van een bestaande streamingtabel wilt updaten, moet u CREATE OR REFRESH STREAMING TABLE uitvoeren met het bijgewerkte TBLPROPERTIES.

In het volgende codevoorbeeld ziet u hoe u het kanaal instelt op preview:

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

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

Streamingtabellen maken automatisch gebruik van serverloze pijplijnen om vernieuwingen te verwerken. De vernieuwing wordt beheerd door de pijplijn en de update wordt bewaakt door het Databricks SQL Warehouse dat wordt gebruikt om de streamingtabel te maken. Streamingtabellen kunnen worden bijgewerkt met behulp van een pijplijn die volgens een schema wordt uitgevoerd.

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.

Zie Vernieuwingen plannen in Databricks SQL voor meer informatie over het plannen van een vernieuwing. Geplande vernieuwingen kunnen updatemeldingen hebben en u kunt de prestatiemodus voor het vernieuwen instellen.

Hoe vernieuwen werkt

Een streamingtabelvernieuwing evalueert alleen nieuwe rijen die na de laatste update zijn aangekomen en voegt alleen de nieuwe gegevens toe.

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 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 is na verloop van tijd 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 het pictogram Gegevens.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 potloodpictogram 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

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:

  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.

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:

  1. Klik op het pictogram Geschiedenis. 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

  • Last updated on