Använda strömmande tabeller i Databricks SQL

Databricks rekommenderar att du använder strömmande tabeller för att mata in data med Databricks SQL. En strömningstabell är en tabell som är registrerad i Unity Catalog med extra stöd för direktuppspelning eller inkrementell databehandling. En pipeline skapas automatiskt för varje strömmande tabell. Du kan använda strömmande tabeller för inkrementell datainläsning från Kafka och molnobjektlagring.

Anmärkning

Information om hur du använder Delta Lake-tabeller som strömmande källor och mottagare finns i Delta table streaming reads and writes.

Kravspecifikation

Om du vill använda strömmande tabeller måste du uppfylla följande krav.

Krav för arbetsyta:

Strömmande tabeller som skapats i Databricks SQL backas upp av serverlösa pipelines. Din arbetsyta måste ha stöd för serverlösa pipelines för att kunna använda den här funktionen.

• Ett Azure Databricks-konto med serverlöst aktiverat. Mer information finns i Konfigurera serverlösa SQL-lager.
• En arbetsyta med Unity Catalog aktiverat. Mer information finns i Komma igång med Unity Catalog.

Beräkningskrav:

Du måste använda något av följande:

• Ett SQL-lager som använder Current kanalen.
• Beräkning med standardåtkomstläge (tidigare delat åtkomstläge) på Databricks Runtime 13.3 LTS eller senare.

• Beräkning med dedikerat åtkomstläge (tidigare åtkomstläge för en enskild användare) på Databricks Runtime 15.4 LTS eller senare.

  På Databricks Runtime 15.3 och nedan kan du inte använda dedikerad beräkning för att köra frågor mot strömmande tabeller som ägs av andra användare. Du kan endast använda dedikerad beräkning på Databricks Runtime 15.3 och lägre om du äger strömningstabellen. Skaparen av tabellen är ägaren.

  Databricks Runtime 15.4 LTS och senare stöder att fråga pipelinegenererade tabeller på dedikerad beräkning, även om du inte är ägaren till tabellen. Du kan debiteras för serverlösa beräkningsresurser när du använder dedikerad beräkning för att köra datafiltreringsåtgärder. Se Detaljerad åtkomstkontroll för dedikerad beräkning.

Behörighetskrav:

• USE CATALOG och USE SCHEMA behörigheter i katalogen och schemat där du skapar strömningstabellen.
• Den CREATE TABLE behörigheten för schemat där du skapar strömningstabellen.
• Behörigheter för åtkomst till tabeller eller platser som tillhandahåller källdata för din strömmande tabell.

Skapa strömmande tabeller

En strömmande tabell definieras av en SQL-fråga i Databricks SQL. När du skapar en strömmande tabell används de data som för närvarande finns i källtabellerna för att skapa strömningstabellen. Därefter uppdaterar du tabellen, vanligtvis enligt ett schema, för att hämta eventuella tillagda data i källtabellerna för att lägga till i strömningstabellen.

När du skapar en direktuppspelningstabell betraktas du som ägare till tabellen.

Om du vill skapa en strömmande tabell från en befintlig tabell använder du -instruktionenCREATE STREAMING TABLE, som i följande exempel:

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

I det här fallet skapas strömningstabellen sales från specifika kolumner i raw_data tabellen, med ett schema för uppdatering varje timme. Frågan som används måste vara en direktuppspelningsfråga . Använd nyckelordet STREAM för att använda strömmande semantik för att läsa från källan.

Beräkning som används för uppdatering

När du skapar en strömmande tabell med instruktionen CREATE OR REFRESH STREAMING TABLE börjar den första datauppdateringen och populationen omedelbart. Dessa åtgärder använder inte Databricks SQL Warehouse-beräkning. I stället förlitar sig strömmande tabeller på serverlösa pipelines för både skapande och uppdatering. En dedikerad serverlös pipeline skapas och hanteras automatiskt av systemet för varje strömmande tabell.

Läsa in filer med Auto Loader

Om du vill skapa en strömmande tabell från filer i en volym använder du Auto Loader. Använd Auto Loader för de flesta datainmatningsuppgifter från molnobjektlagring. Automatisk inläsning och pipelines är utformade för att inkrementellt och idempotent läsa in ständigt växande data när de kommer till molnlagringen.

Om du vill använda Auto Loader i Databricks SQL använder du read_files funktionen. Följande exempel visar hur du använder Auto Loader för att läsa en volym JSON-filer till en strömmande tabell:

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"
  );

Om du vill läsa data från molnlagring kan du också använda Automatisk inläsning:

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"
  );

Mer information om automatisk inläsning finns i Vad är automatisk inläsning?. Mer information om hur du använder automatisk inläsning i SQL finns i Läsa in data från objektlagring.

Strömmande inmatning från andra källor

Exempel på inmatning från andra källor, inklusive Kafka, se Läsa in data i pipelines.

Tillämpa ändringsdatainsamling (CDC) med automatiska CDC-flöden

Viktigt!

Den här funktionen finns i Beta. Finns i Databricks SQL med hjälp av Current kanalen.

Använd FLOW AUTO CDC-satsen för att bearbeta Change Data Capture (CDC)-register från en källa till en strömmande tabell. Tidigare användes instruktionen MERGE INTO ofta för bearbetning av CDC-poster på Azure Databricks. Kan dock MERGE INTO ge felaktiga resultat på grund av poster som inte är sekvenserade eller kräver komplex logik för att ordna om poster. Se Ändra datainsamling och ögonblicksbilder.

AUTO CDC förenklar CDC genom att automatiskt hantera out-of-order-poster. Du anger nycklar för att identifiera poster, en sekvenskolumn för beställning och om resultat ska lagras som SCD typ 1 (direktuppdateringar) eller SCD typ 2 (historikspårning).

I följande exempel skapas en strömmande tabell som tillämpar CDC-ändringar med SCD typ 1.

CREATE OR REFRESH STREAMING TABLE target
  FLOW AUTO CDC
  FROM stream(cdc_data.users)
  KEYS (userId)
  SEQUENCE BY sequenceNum
  STORED AS SCD TYPE 1;

I följande exempel används SCD typ 2 för att behålla en historik över ändringar:

CREATE OR REFRESH STREAMING TABLE target
  FLOW AUTO CDC
  FROM stream(cdc_data.users)
  KEYS (userId)
  APPLY AS DELETE WHEN operation = "DELETE"
  SEQUENCE BY sequenceNum
  COLUMNS * EXCEPT (operation, sequenceNum)
  STORED AS SCD TYPE 2;

Fullständig information om alternativ och beteende för Automatisk CDC finns i API:er för AUTOMATISK CDC: Förenkla insamling av ändringsdata med pipelines. Den fullständiga syntaxreferensen finns i CREATE STREAMING TABLE.

Mata bara in ny data

Som standard read_files läser funktionen alla befintliga data i källmappen när tabellen skapas och bearbetar sedan nyligen ankommande poster med varje uppdatering.

Om du vill undvika att mata in data som redan finns i källmappen när tabellen skapas anger du includeExistingFiles alternativet till false. Det innebär att endast data som tas emot i mappen när tabellen har skapats har bearbetats. Till exempel:

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

Ange körningskanalen

Strömmande tabeller som skapats med SQL-lager uppdateras automatiskt med hjälp av en pipeline. Pipelines använder som standard körmiljön i current-kanalen. För mer information om lanseringsprocessen, se versionsanmärkningarna och versionsuppgraderingsprocessen för Lakeflow Spark Deklarativa pipelines.

Databricks rekommenderar att du använder current kanalen för produktionsarbetsbelastningar. Nya funktioner släpps först till preview kanalen. Du kan ange en pipeline till förhandsgranskningskanalen för att testa nya funktioner genom att preview ange som en tabellegenskap med hjälp av en CREATE OR REFRESH STREAMING TABLE -instruktion. Om du vill uppdatera kanalen för en befintlig strömningstabell måste du köra CREATE OR REFRESH STREAMING TABLE med den uppdaterade TBLPROPERTIES.

I följande kodexempel visas hur du ställer in kanalen som förhandsversion:

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

Dölj känsliga data

Du kan använda strömmande tabeller för att dölja känsliga data från användare som kommer åt tabellen. En metod är att definiera frågan så att den utesluter känsliga kolumner eller rader helt och hållet. Du kan också använda kolumnmasker eller radfilter baserat på behörigheterna för den frågande användaren. Du kan till exempel dölja tax_id kolumnen för användare som inte finns i gruppen HumanResourcesDept. Det gör du genom att använda syntaxen ROW FILTER och MASK när du skapar strömningstabellen. Mer information finns i Radfilter och kolumnmasker.

Uppdatera en strömningstabell

Strömmande tabeller skapar och använder automatiskt serverlösa pipelines för att bearbeta uppdateringsåtgärder. Förnyelsen hanteras av pipelinen och uppdateringen övervakas av Databricks SQL-lagret som används för att skapa den strömmande tabellen. Strömmande tabeller kan uppdateras med hjälp av en pipeline som körs enligt ett schema.

Även om du har en schemalagd uppdatering kan du anropa en manuell uppdatering när som helst. Uppdateringar hanteras av samma pipeline som skapades automatiskt tillsammans med strömningstabellen.

Så här uppdaterar du en strömmande tabell:

REFRESH STREAMING TABLE sales;

Du kan kontrollera status för den senaste uppdateringen med DESCRIBE TABLE EXTENDED.

Anmärkning

Du kan behöva uppdatera strömningstabellen innan du använder frågor om tidsresor.

Information om hur du schemalägger en uppdatering finns i Schemalägg uppdateringar i Databricks SQL. Schemalagda uppdateringar kan ha uppdateringsmeddelanden och du kan ange prestandaläget för uppdateringen.

Så här fungerar uppdateringen

En uppdatering av strömningstabellen utvärderar endast nya rader som har anlänt efter den senaste uppdateringen och lägger endast till nya data.

Varje uppdatering använder den aktuella definitionen av strömningstabellen för att bearbeta dessa nya data. Om du ändrar en definition för en strömmande tabell beräknas inte befintliga data automatiskt om. Om en ändring inte är kompatibel med befintliga data (till exempel om du ändrar en datatyp) misslyckas nästa uppdatering med ett fel.

I följande exempel förklaras hur ändringar i en strömmande tabelldefinition påverkar uppdateringsbeteendet:

• Om du tar bort ett filter bearbetas inte tidigare filtrerade rader.
• Om du ändrar kolumnprojektioner påverkas inte hur befintliga data bearbetades.
• Kopplingar med statiska ögonblicksbilder använder ögonblicksbildens tillstånd vid det första bearbetningstillfället. Data som anländer sent och som skulle ha stämt överens med den uppdaterade ögonblicksbilden ignoreras. Detta kan leda till att fakta tas bort om dimensionerna är sena.
• Om du ändrar CAST för en befintlig kolumn resulterar det i ett fel.

Om dina data ändras på ett sätt som inte kan stödjas i den befintliga strömningstabellen kan du utföra en fullständig uppdatering.

Uppdatera en strömningstabell fullständigt

Fullständiga uppdateringar bearbetar om alla data som är tillgängliga i källan med den senaste definitionen. Vi rekommenderar inte att du anropar fullständiga uppdateringar på källor som inte behåller hela datahistoriken eller har korta kvarhållningsperioder, till exempel Kafka, eftersom den fullständiga uppdateringen trunkerar befintliga data. Du kanske inte kan återställa gamla data om data inte längre är tillgängliga i källan.

Till exempel:

REFRESH STREAMING TABLE sales FULL;

Ändra schemat för en strömningstabell

Du kan konfigurera en Databricks SQL-direktuppspelningstabell så att den uppdateras automatiskt baserat på ett definierat schema eller för att utlösa när överordnade data ändras. I följande tabell visas de olika alternativen för att schemalägga uppdateringar.

Metod	Description	Exempel på användningsfall
Manuell	Uppdatering på begäran med hjälp av en SQL-instruktion REFRESH eller via arbetsytans användargränssnitt.	Utveckling, testning, ad hoc-uppdateringar.
TRIGGER ON UPDATE	Definiera strömningstabellen så att den uppdateras automatiskt när de överordnade data ändras.	Produktionsarbetsbelastningar med serviceavtal för dataaktualitet eller oförutsägbara uppdateringsperioder.
SCHEDULE	Definiera den strömmande tabellen som ska uppdateras med definierade tidsintervall.	Förutsägbara, tidsbaserade uppdateringskrav.
SQL-uppgift i ett jobb	Uppdateringen dirigeras via Lakeflow-jobb.	Komplexa pipelines med systemöverskridande beroenden.

Manuell uppdatering

Om du vill uppdatera en strömmande tabell manuellt kan du anropa en uppdatering från Databricks SQL eller använda arbetsytans användargränssnitt.

REFRESH uttalande

Så här uppdaterar du en pipeline med Databricks SQL:

1. I SQL-redigeraren kör du följande instruktion:

   REFRESH MATERIALIZED VIEW <table-name>;
   

Mer information finns i REFRESH (MATERIALIZED VIEW eller STREAMING TABLE).

Användargränssnitt för arbetsutrymme

Så här uppdaterar du en pipeline i arbetsytans användargränssnitt:

1. På Azure Databricks-arbetsytan klickar du på Jobb och pipelines.
2. Välj den pipeline som du vill uppdatera från listan.
3. Klicka på startknappen .

När pipelinen uppdateras visas uppdateringar i användargränssnittet.

Utlösare vid uppdatering

TRIGGER ON UPDATE Satsen uppdaterar automatiskt en strömmande tabell när överordnade källdata ändras. Detta eliminerar behovet av att samordna scheman mellan pipelines. Strömningstabellen förblir fräsch utan att användaren behöver veta när uppströms jobb slutförs eller behöver underhålla komplex schemaläggningslogik.

Det här är den rekommenderade metoden för produktionsarbetsbelastningar, särskilt när överordnade beroenden inte körs enligt förutsägbara scheman. När den har konfigurerats övervakar den strömmande tabellen sina källtabeller och uppdateras automatiskt när ändringar i någon av de överordnade källorna identifieras.

Begränsningar

• Överordnade beroendegränser: En strömmande tabell kan övervaka högst 10 överordnade tabeller och 30 överordnade vyer. Om du vill ha fler beroenden delar du upp logiken i flera strömningstabeller.
• Begränsningar för arbetsyta: Högst 1 000 strömmande tabeller med TRIGGER ON UPDATE kan finnas per arbetsyta. Kontakta Databricks-supporten om fler än 1 000 strömmande tabeller behövs.
• Minsta intervall: Det minsta utlösarintervallet är 1 minut.

I följande exempel visas hur du anger en utlösare vid uppdatering när du definierar en strömningstabell.

Skapa en strömningstabell med utlösare vid uppdatering

För att skapa en strömmande tabell som uppdateras automatiskt när källdata förändras, inkluderar du TRIGGER ON UPDATE klausulen i CREATE STREAMING TABLE instruktionen.

I följande exempel skapas en strömmande tabell som läser kundbeställningar och uppdateras när källtabellen orders uppdateras:

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

Uppdateringsfrekvens för strypning

Om överordnade data uppdateras ofta kan du använda AT MOST EVERY för att begränsa hur ofta vyn uppdateras och begränsa beräkningskostnaderna. Detta är användbart när källtabeller uppdateras ofta, men nedströmskonsumenter inte behöver realtidsdata. Nyckelordet INTERVAL krävs före tidsvärdet.

I följande exempel begränsas strömningstabellen så att den uppdateras högst var 5:e minut, även om källdata ändras oftare:

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 STREAM catalog.schema.orders o;

Schemalagd uppdatering

Uppdateringsscheman kan definieras direkt i strömningstabelldefinitionen för att uppdatera vyn med fasta tidsintervall. Den här metoden är användbar när datauppdateringens takt är känd och förutsägbar uppdateringstid är önskad.

När det finns ett uppdateringsschema kan du fortfarande köra en manuell uppdatering när som helst om du behöver uppdaterade data.

Databricks stöder två schemaläggningssyntaxer: SCHEDULE EVERY för enkla intervall och SCHEDULE CRON för exakt schemaläggning. Nyckelorden SCHEDULE och SCHEDULE REFRESH är semantiskt likvärdiga.

Mer information om syntaxen och användningen av -satsen finns i SCHEDULECREATE STREAMING TABLE SCHEDULE-satsen.

När ett schema skapas konfigureras ett nytt Databricks-jobb automatiskt för att bearbeta uppdateringen.

Om du vill visa schemat gör du något av följande:

• Kör -instruktionen DESCRIBE EXTENDED från SQL-redigeraren i Azure Databricks-användargränssnittet. Se även DESCRIBE TABLE.
• Använd Katalogutforskaren för att visa strömningstabellen. Schemat visas på fliken Översikt under Uppdateringsstatus. Se Vad är Katalogutforskaren?.

Följande exempel visar hur du skapar en strömmande tabell med ett schema:

Schemalägg varje tidsintervall

I det här exemplet schemaläggs en uppdatering var femte minut:

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;

Schemalägg med cron

I det här exemplet schemaläggs en uppdatering var 15:e minut, efter en kvart i UTC-tidszonen:

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-uppgift i ett jobb

Uppdateringar av strömmande tabeller kan orkestreras via Databricks-jobb genom att skapa SQL-uppgifter som innehåller REFRESH STREAMING TABLE kommandon. Den här metoden integrerar uppdateringar av strömmande tabeller i befintliga arbetsflöden för jobborkestrering.

Det finns två sätt att skapa ett jobb för att uppdatera strömmande tabeller:

• Från SQL-redigeraren: Skriv REFRESH STREAMING TABLE kommandot och klicka på knappen Schema för att skapa ett jobb direkt från frågan.
• Från jobbgränssnittet: Skapa ett nytt jobb, lägg till en SQL-aktivitetstyp och bifoga en SQL-fråga eller notebook-fil med REFRESH STREAMING TABLE kommandot .

I följande exempel visas SQL-instruktionen i en SQL-uppgift som uppdaterar en strömmande tabell:

REFRESH STREAMING TABLE catalog.schema.sales;

Den här metoden är lämplig när:

• Komplexa pipelines i flera steg har beroenden mellan olika system.
• Integrering med befintlig jobborkestrering krävs.
• Aviseringar och övervakning på jobbnivå krävs.

SQL-uppgifter använder både SQL-datalager som är kopplat till jobbet och den serverlösa beräkningen som kör uppdateringen. Om du använder definitionsbaserad schemaläggning för strömmande tabeller uppfyller kraven kan du växla till TRIGGER ON UPDATE eller SCHEDULE förenkla arbetsflödet.

Lägga till ett schema i en befintlig direktuppspelningstabell

Om du vill ange schemat när du har skapat det använder du -instruktionen ALTER STREAMING TABLE :

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

Ändra ett befintligt schema eller en utlösare

Om en strömmande tabell redan har ett schema eller en utlösare associerad, använd ALTER SCHEDULE eller ALTER TRIGGER ON UPDATE för att ändra uppdateringskonfigurationen. Detta gäller oavsett om du ändrar från ett schema till ett annat, en utlösare till en annan eller växlar mellan ett schema och en utlösare.

I följande exempel ändras ett befintligt schema för uppdatering var femte minut:

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

Ta bort ett schema eller en utlösare

Om du vill ta bort ett schema använder du ALTER ... DROP:

ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

Spåra status för en uppdatering

Du kan visa status för en uppdatering av en strömmande tabell genom att visa pipelinen som hanterar strömningstabellen i pipelinegränssnittet eller genom att visa uppdateringsinformationenDESCRIBE EXTENDED som returneras av kommandot för strömningstabellen.

DESCRIBE TABLE EXTENDED <table-name>;

Alternativt kan du visa strömningstabellen i Katalogutforskaren och se uppdateringsstatusen där:

1. Klicka på Katalog i sidofältet.
2. I trädet Katalogutforskaren till vänster öppnar du katalogen och väljer det schema där din strömmande tabell finns.
3. Öppna objektet Tabeller under det schema som du valde och klicka på den strömmande tabellen.

Härifrån kan du använda flikarna under strömningstabellens namn för att visa och redigera information om strömningstabellen, inklusive:

• Uppdatera status och historik
• Tabelldesign
• Exempeldata (kräver en aktiv beräkning)
• Behörigheter
• Ursprung, inklusive tabeller och pipelines som den här strömmande tabellen är beroende av
• Insikter om användning
• Monitorer som du har skapat för den här strömningstabellen

Tidsgränser för uppdateringar

Uppdateringar av strömmande tabeller körs med en tidsgräns som begränsar hur länge de kan köras. För strömmande tabeller som skapats eller uppdaterats den 14 augusti 2025 registreras tidsgränsen när du uppdaterar genom att köra CREATE OR REFRESH:

• Om en STATEMENT_TIMEOUT anges används det värdet. Se även STATEMENT_TIMEOUT.
• Annars används tidsgränsen från SQL-lagret som används för att köra kommandot.
• Om informationslagret inte har en tidsgräns konfigurerad gäller standardvärdet 2 dagar.

Tidsgränsen används vid den första skapande, men även vid schemalagda uppdateringar som följer.

För strömningstabeller som senast uppdaterades före den 14 augusti 2025 är tidsgränsen inställd på 2 dagar.

Exempel: Ange en tidsgräns för en uppdatering av strömningstabellen Du kan uttryckligen styra hur länge en uppdatering av strömmande tabell tillåts köras genom att ange en tidsgräns på instruktionsnivå när du skapar eller uppdaterar tabellen:

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;

Detta konfigurerar att strömningstabellen uppdateras var 12:e timme, och om en uppdatering tar mer än 6 timmar överskrider den tidsgränsen och väntar på nästa schemalagda uppdatering.

Så hanterar schemalagda uppdateringar tidsgränser

Tidsgränser synkroniseras endast när du uttryckligen kör CREATE OR REFRESH.

• Schemalagda uppdateringar fortsätter att nyttja den tidsgräns som registrerats under den senaste CREATE OR REFRESH.
• Att enbart ändra tidsgränsen för datamagasinet påverkar inte befintliga schemalagda uppdateringar.

Viktigt!

När du har ändrat tidsgränsen för ett lager kör du CREATE OR REFRESH igen för att tillämpa den nya tidsgränsen på framtida schemalagda uppdateringar.

Kontrollera åtkomsten till strömmande tabeller

Strömningstabeller har stöd för omfattande åtkomstkontroller för att stödja datadelning och samtidigt undvika att exponera potentiellt privata data. En ägare av direktuppspelningstabellen eller en användare med behörigheten MANAGE kan bevilja SELECT behörigheter till andra användare. Användare med SELECT åtkomst till strömningstabellen behöver SELECT inte åtkomst till tabellerna som refereras av strömningstabellen. Den här åtkomstkontrollen möjliggör datadelning samtidigt som åtkomsten till underliggande data kontrolleras.

Du kan också ändra ägaren till en strömmande tabell.

Tilldela behörigheter till en strömningstabell

Om du vill bevilja åtkomst till en strömningstabell använder du -instruktionenGRANT:

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

privilege_type Kan vara:

• SELECT – användaren kan SELECT strömma tabellen.
• REFRESH – användaren kan REFRESH strömma tabellen. Uppdateringar körs med ägarens behörigheter.

I följande exempel skapas en strömningstabell och användare får behörighet att välja och uppdatera:

CREATE OR REFRESH STREAMING TABLE st_name AS SELECT * FROM source_table;

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

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

Mer information om hur du beviljar behörigheter för skyddsbara objekt i Unity Catalog finns i Referens för Behörigheter för Unity Catalog.

Återkalla behörigheter från en streaming-tabell

Om du vill återkalla åtkomst från en strömningstabell använder du -instruktionenREVOKE:

REVOKE privilege_type ON <st_name> FROM principal;

När SELECT behörigheter i en källtabell återkallas från strömningstabellägaren eller någon annan användare som har beviljats MANAGE eller SELECT behörigheter i strömningstabellen, eller om källtabellen tas bort, kan ägaren eller användaren som beviljats åtkomst till strömningstabellen fortfarande köra frågor mot strömningstabellen. Följande beteende inträffar dock:

• Den strömmande tabellägaren eller andra som har förlorat åtkomsten till en strömmande tabell kan inte längre REFRESH den strömmande tabellen, och strömningstabellen blir föråldrad med tiden.
• Om det automatiseras med ett schema, misslyckas nästa planerade REFRESH eller körs inte.

I följande exempel återkallas behörigheten SELECT från read_only_user:

REVOKE SELECT ON st_name FROM read_only_user;

Ändra ägaren till en streamningstabell

En användare med MANAGE behörigheter för en strömmande tabell som definierats i Databricks SQL kan ange en ny ägare via Katalogutforskaren. Den nya ägaren kan vara sig själv eller ett tjänstehuvudnamn där de har Service Principal User-rollen.

1. Från din Azure Databricks-arbetsyta klickar du på Katalog för att öppna Katalogutforskaren.

2. Välj den strömmande tabell som du vill uppdatera.

3. I det högra sidofältet, under Om den här strömningstabellen, letar du upp Ägare och klickar på

   Anmärkning

   Om du får ett meddelande som uppmanar dig att uppdatera ägaren genom att ändra Kör som-användare i pipeline-inställningar, definieras strömningstabell i deklarativa pipelines i Lakeflow Spark, inte Databricks SQL. Meddelandet innehåller en länk till pipelineinställningarna: där du kan ändra Kör som användare.

4. Välj en ny ägare för strömningstabellen.

   Ägare har automatiskt behörigheterna MANAGE och SELECT på strömmande tabeller som de äger. Om du anger ett huvudnamn för tjänsten som ägare för en strömmande tabell som du äger, och du inte uttryckligen har SELECT eller MANAGE behörighet på strömningstabellen, skulle den här ändringen leda till att du förlorar all åtkomst till strömningstabellen. I det här fallet uppmanas du att uttryckligen ange dessa privilegier.

   Välj både Bevilja HANTERA och Bevilja SELECT behörigheter för att ange dem i Spara.

5. Klicka på Spara för att ändra ägaren.

Ägaren till strömningstabellen uppdateras. Alla framtida uppdateringar körs med den nya ägarens identitet.

När ägaren förlorar behörighet till källtabeller

Om du ändrar ägaren och den nya ägaren inte har åtkomst till källtabellerna (eller om behörigheterna på de underliggande källtabellerna återkallas) kan användarna fortfarande köra frågor mot strömningstabellen. Observera följande:

• De kan inte REFRESH strömma tabellen.
• Nästa schemalagda uppdatering av strömningstabellen misslyckas.

Att förlora åtkomsten till källdata förhindrar uppdateringar, men förhindrar inte omedelbart den befintliga strömmande tabellen från att läsas.

ta bort poster från en streamingtabell permanent

Viktigt!

Stöd för REORG-instruktionen med strömmande tabeller finns i offentlig förhandsversion.

Anmärkning

• Om du använder en REORG-instruktion med en strömmande tabell krävs Databricks Runtime 15.4 och senare.
• Även om du kan använda -instruktionen REORG med en strömningstabell krävs den bara när du tar bort poster från en strömmande tabell med borttagningsvektorer aktiverade. Kommandot har ingen effekt när det används med en strömmande tabell utan att borttagningsvektorer har aktiverats.

För att fysiskt ta bort poster från den underliggande lagringen för en strömmande tabell med borttagningsvektorer aktiverade, till exempel för GDPR-efterlevnad, måste ytterligare åtgärder vidtas för att säkerställa att en VACUUM åtgärd körs på strömningstabellens data.

Så här tar du bort poster fysiskt från underliggande lagring:

1. Uppdatera poster eller ta bort poster från strömningstabellen.
2. Kör en REORG-instruktion mot strömningstabellen och ange parametern APPLY (PURGE). Till exempel REORG TABLE <streaming-table-name> APPLY (PURGE);.
3. Vänta tills datakvarhållningsperioden för strömningstabellen har passerat. Standardperioden för datakvarhållning är sju dagar, men den kan konfigureras med egenskapen delta.deletedFileRetentionDuration tabell. Se Konfigurera datalagring för frågor rörande tidsresor.
4. REFRESH strömningstabellen. Se även Uppdatera en streamingtabel. Inom 24 timmar efter REFRESH-åtgärden körs pipelineunderhållsuppgifter automatiskt, inklusive VACUUM-åtgärden som krävs för att säkerställa att poster tas bort permanent.

Övervaka körningar med hjälp av frågehistorik

Du kan använda sidan för frågehistorik för att komma åt frågeinformation och frågeprofiler som kan hjälpa dig att identifiera frågor och flaskhalsar som fungerar dåligt i pipelinen som används för att köra uppdateringar av strömningstabellen. En översikt över vilken typ av information som är tillgänglig i frågehistorik och frågeprofiler finns i Frågehistorik och Frågeprofil.

Viktigt!

Den här funktionen finns som allmänt tillgänglig förhandsversion. Arbetsyteadministratörer kan styra åtkomsten till den här funktionen från sidan Förhandsversioner . Se Hantera förhandsversioner av Azure Databricks.

Alla instruktioner som rör strömmande tabeller visas i frågehistoriken. Du kan använda listrutan Statement för att välja valfritt kommando och granska relaterade frågor. Alla CREATE instruktioner följs av en REFRESH instruktion som körs asynkront på en pipeline. Instruktionerna REFRESH innehåller vanligtvis detaljerade frågeplaner som ger insikter om hur du optimerar prestanda.

Använd följande steg för att komma åt REFRESH instruktioner i användargränssnittet för frågehistorik:

1. Klicka på Öppna användargränssnittet för frågehistorik i det vänstra sidofältet.
2. Markera kryssrutan REFRESH från filterlistrutan Statement.
3. Klicka på namnet på frågeuttrycket för att visa sammanfattningsinformation som frågans varaktighet och aggregerade mått.
4. Klicka på Se frågeprofil för att öppna frågeprofilen. Mer information om hur du navigerar i frågeprofilen finns i Frågeprofil .
5. Du kan också använda länkarna i avsnittet Frågekälla för att öppna den relaterade frågan eller pipelinen.

Du kan också komma åt frågeinformation med hjälp av länkar i SQL-redigeraren eller från en notebook-fil som är kopplad till ett SQL-lager.

Få åtkomst till strömmande tabeller från externa klienter

Om du vill komma åt strömmande tabeller från externa Delta Lake- eller Iceberg-klienter som inte stöder öppna API:er kan du använda kompatibilitetsläge. Kompatibilitetsläget skapar en skrivskyddad version av din strömmande tabell som kan nås av alla Delta Lake- eller Iceberg-klienter.

Ytterligare resurser

• Deklarativa pipelines för Lakeflow Spark
• read_files tabellvärdesfunktion
• read_kafka tabellvärdesfunktion
• CREATE STREAMING TABLE
• ALTER STREAMING TABLE
• Använda materialiserade vyer i Databricks SQL
• API:er för AUTOMATISK CDC: Förenkla insamling av ändringsdata med pipelines