Dela via

Använda Unity Catalog med dina DLT-pipelines

  • Artikel

Viktig

DLT-stöd för Unity Catalog finns i public preview.

Databricks rekommenderar att du konfigurerar DLT-pipelines med Unity Catalog.

Pipelines som konfigurerats med Unity Catalog publicerar alla definierade materialiserade vyer och strömmande tabeller till den angivna katalogen och schemat. Unity Catalog-pipelines kan få tillgång till andra Unity Catalog-tabeller och volymer.

Använd GRANT och REVOKEför att hantera behörigheter för de tabeller som har skapats av en Unity Catalog-pipeline.

Not

I den här artikeln beskrivs funktioner för det aktuella standardpubliceringsläget för pipelines. Pipelines som skapats före den 5 februari 2025 kan använda det äldre publiceringsläget och LIVE virtuella schemat. Se LIVE-schema (äldre) –.

krav

Om du vill skapa strömmande tabeller och materialiserade vyer i ett målschema i Unity Catalog måste du ha följande behörigheter för schemat och den överordnade katalogen:

  • USE CATALOG behörigheter i målkatalogen.
  • CREATE MATERIALIZED VIEW och USE SCHEMA behörigheter för målschemat om din pipeline skapar materialiserade vyer.
  • CREATE TABLE och USE SCHEMA behörigheter på målschemat ifall din pipeline skapar strömmande tabeller.

Om din pipeline skapar nya scheman måste du ha USE CATALOG och CREATE SCHEMA behörigheter i målkatalogen.

Beräkning som krävs för att köra en Unity Catalog-aktiverad pipeline:

Beräkning som krävs för att fråga tabeller som skapas av en DLT-pipeline med Unity Catalog (inklusive strömmande tabeller och materialiserade vyer) innehåller något av följande:

  • SQL-lager
  • Standardåtkomstlägesberäkning på Databricks Runtime 13.3 LTS eller senare.
  • Dedikerad åtkomstlägesberäkning, om detaljerad åtkomstkontroll är aktiverad på den dedikerade beräkningen (det vill: den körs på Databricks Runtime 15.4 eller senare och serverlös beräkning är aktiverad för arbetsytan). Mer information finns i Detaljerad åtkomstkontroll för dedikerad beräkning (tidigare beräkning av en enskild användare).
  • Beräkning i dedikerat åtkomstläge från 13.3 LTS till 15.3, förutsatt att tabellägaren kör frågan.

Ytterligare beräkningsbegränsningar gäller. Se avsnittet nedan.

Begränsningar

Följande är begränsningar när du använder Unity Catalog med DLT:

  • Du kan inte skapa en Unity Catalog-aktiverad pipeline på en arbetsyta som är kopplad till ett metaarkiv som skapades under den offentliga förhandsversionen av Unity Catalog. Se Uppgradera till privilegiernas arv.
  • JAR stöds inte. Endast Python-bibliotek från tredje part stöds. Se Hantera Python-beroenden för DLT-pipelines.
  • Frågor med datamanipuleringsspråk (DML) som ändrar schemat för en strömmande tabell stöds inte.
  • En materialiserad vy som skapats i en DLT-pipeline-process kan inte användas som en strömmande datakälla utanför denna pipeline-process, till exempel i en annan pipeline eller en nedströms-notebook-fil.
  • Data för materialiserade vyer och strömmande tabeller lagras på lagringsplatsen för det innehållande schemat. Om en schemalagringsplats inte har angetts lagras tabellerna på katalogens lagringsplats. Om schema- och kataloglagringsplatser inte anges lagras tabellerna på metaarkivets rotlagringsplats.
  • Fliken Katalogutforskaren historik visar inte historik för materialiserade vyer.
  • Egenskapen LOCATION stöds inte när du definierar en tabell.
  • Unity Catalog-aktiverade pipelines kan inte publicera till Hive-metastore.
  • Du kan inte använda Delta Sharing med en materialiserad DLT-vy eller en strömmande tabell som publicerats till Unity Catalog.

Notis

De underliggande filerna som stöder materialiserade vyer kan innehålla data från överordnade tabeller (inklusive möjlig personligt identifierbar information) som inte visas i den materialiserade vydefinitionen. Dessa data läggs automatiskt till i den underliggande lagringen för att stödja inkrementell uppdatering av materialiserade vyer.

Eftersom de underliggande filerna i en materialiserad vy kan riskera att exponera data från överordnade tabeller som inte ingår i det materialiserade vyschemat rekommenderar Databricks att inte dela den underliggande lagringen med obetrodda nedströmsanvändare.

Anta till exempel att en materialiserad vydefinition innehåller en COUNT(DISTINCT field_a)-sats. Även om den materialiserade vydefinitionen endast innehåller den aggregerade COUNT DISTINCT-satsen innehåller de underliggande filerna en lista över de faktiska värdena för field_a.

Kan jag använda Hive-metaarkiv och Unity Catalog-pipelines tillsammans?

Din arbetsyta kan innehålla pipelines som använder Unity Catalog och det äldre Hive-metaarkivet. En enskild pipeline kan dock inte skriva till Hive-metastore och Unity Catalog. Befintliga pipelines som skriver till Hive-metastore kan inte uppgraderas för att använda Unity Catalog. Om du vill migrera en befintlig pipeline som skriver till Hive-metaarkivet måste du skapa en ny pipeline och mata in data från datakällorna igen. Se Skapa en pipeline för Unity Catalog genom att klona en Hive-metastore-pipeline.

Befintliga pipelines som inte använder Unity Catalog påverkas inte genom att skapa nya pipelines som konfigurerats med Unity Catalog. Dessa pipelines fortsätter att lagra data i Hive-metadatakatalogen med hjälp av den konfigurerade lagringsplatsen.

Om inget annat anges i det här dokumentet stöds alla befintliga datakällor och DLT-funktioner med pipelines som använder Unity Catalog. Både Python-- och SQL--gränssnitt stöds med pipelines som använder Unity Catalog.

Ändringar i befintliga funktioner

När DLT har konfigurerats för att bevara data till Unity Catalog hanterar DLT-pipelinen tabellens livscykel och behörigheter. Som ett resultat:

  • När en tabell tas bort från pipelinedefinitionen kommer nästa pipelineuppdatering att markera motsvarande materialiserade vy eller post i strömmande tabell som inaktiv. Inaktiva tabeller kan fortfarande frågas men uppdateras inte. Om du vill rensa materialiserade vyer eller strömmande tabeller kan du uttryckligen DROP tabellen.
    • Du kan återställa alla borttagna tabeller inom 7 dagar med hjälp av kommandot UNDROP.
    • Om du vill behålla det äldre beteendet där den materialiserade vyn eller strömningstabellposten tas bort från Unity Catalog vid nästa pipelineuppdatering anger du pipelinekonfigurationen "pipelines.dropInactiveTables": "true". Faktiska data behålls under en period så att de kan återställas om de tas bort av misstag. Data kan återställas inom 7 dagar genom att lägga till den materialiserade vyn eller strömningstabellen i pipelinedefinitionen igen.
  • Om du tar bort DLT-pipelinen tas alla tabeller som definierats i pipelinen bort. På grund av den här ändringen uppdateras DLT-användargränssnittet så att du uppmanas att bekräfta borttagningen av en pipeline.
  • Interna bakgrundstabeller, inklusive de som används för att stödja APPLY CHANGES INTO, är inte direkt tillgängliga för användare.

Skriva tabeller till Unity Catalog från en DLT-pipeline

Om du vill skriva tabellerna till Unity Catalog måste du konfigurera pipelinen så att den fungerar med den via arbetsytan. När du skapa en pipelineväljer du Unity Catalog under Lagringsalternativ, väljer en katalog i listrutan Catalog och väljer ett befintligt schema eller anger namnet på ett nytt schema i listrutan Mål schema. Mer information om Unity Catalog-kataloger finns i Vad är kataloger i Azure Databricks?. Mer information om scheman i Unity Catalog finns i Vad är scheman i Azure Databricks?.

importera data i en Unity Catalog pipeline

Din pipeline som har konfigurerats för att använda Unity Catalog kan läsa data från:

  • Hantera och externa tabeller, vyer, materialiserade vyer och strömmande tabeller i Unity Catalog.
  • Hive-metaarkivtabeller och -vyer.
  • Automatisk inläsning med hjälp av funktionen read_files() för att läsa från externa platser i Unity Catalog.
  • Apache Kafka och Amazon Kinesis.

Följande är exempel på läsning från Unity Catalog- och Hive-metaarkivtabeller.

Batchinmatning från en Unity-katalogtabell

SQL

CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  my_catalog.my_schema.table1;

Python

@dlt.table
def table_name():
  return spark.read.table("my_catalog.my_schema.table")

Strömma ändringar från en Unity Catalog-tabell

SQL

CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  STREAM(my_catalog.my_schema.table1);

Python

@dlt.table
def table_name():
  return spark.readStream.table("my_catalog.my_schema.table")

Mata in data från Hive-metaarkiv

En pipeline som använder Unity Catalog kan läsa data från Hive-metaarkivtabeller med hjälp av hive_metastore-katalogen:

SQL

CREATE OR REFRESH MATERIALIZED VIEW
  table_name
AS SELECT
  *
FROM
  hive_metastore.some_schema.table;

Python

@dlt.table
def table3():
  return spark.read.table("hive_metastore.some_schema.table")

Mata in data från Auto Loader

SQL

CREATE OR REFRESH STREAMING TABLE
  table_name
AS SELECT
  *
FROM
  read_files(
    <path-to-uc-external-location>,
    "json"
  )

Python

@dlt.table(table_properties={"quality": "bronze"})
def table_name():
  return (
     spark.readStream.format("cloudFiles")
     .option("cloudFiles.format", "json")
     .load(f"{path_to_uc_external_location}")
 )

Dela materialiserade vyer

Som standard har endast pipelineägaren behörighet att köra frågor mot datauppsättningar som skapats av pipelinen. Du kan ge andra användare möjlighet att köra frågor mot en tabell med hjälp av GRANT-instruktioner och du kan återkalla frågeåtkomst med hjälp av REVOKE-instruktioner. Mer information om behörigheter i Unity Catalog finns i Hantera privilegier i Unity Catalog.

Bevilja val i en tabell

GRANT SELECT ON TABLE
  my_catalog.my_schema.table_name
TO
  `user@databricks.com`

Återkalla val i en tabell

REVOKE SELECT ON TABLE
  my_catalog.my_schema.table_name
FROM
  `user@databricks.com`

Bevilja behörighet för att skapa tabell eller materialiserad vy

GRANT CREATE { MATERIALIZED VIEW | TABLE } ON SCHEMA
  my_catalog.my_schema
TO
  { principal | user }

Visa härledning för en pipeline

Ursprung för tabeller i en DLT-pipeline är synligt i Katalogutforskaren. Katalogutforskarens härkomstgränssnitt visar ursprungs- och efterföljandetabellerna för materialiserade vyer eller strömmande tabeller i en pipeline med Unity Catalog. Mer information om Unity Catalog-ursprung finns i Avbilda och visa data härstamning med hjälp av Unity Catalog.

För en materialiserad vy eller strömningstabell i en Unity Catalog-aktiverad DLT-pipeline länkar katalogutforskarens ursprungsgränssnitt också till pipelinen som producerade den materialiserade vyn eller strömningstabellen om pipelinen är tillgänglig från den aktuella arbetsytan.

Lägga till, ändra eller ta bort data i en strömmande tabell

Du kan använda instruktioner för datamanipuleringsspråk (DML), inklusive infognings-, uppdaterings-, borttagnings- och sammanslagningsinstruktioner, för att ändra strömmande tabeller som publicerats till Unity Catalog. Stöd för DML-frågor mot strömningstabeller möjliggör användningsfall, till exempel uppdatering av tabeller för kompatibilitet med GDPR (General Data Protection Regulation).

Note

  • DML-instruktioner som ändrar tabellschemat för en strömmande tabell stöds inte. Se till att DML-uttrycken inte försöker utveckla tabellschemat.
  • DML-instruktioner som uppdaterar en strömmande tabell kan endast köras i ett delat Unity Catalog-kluster eller ett SQL-lager med Databricks Runtime 13.3 LTS och senare.
  • Eftersom strömning kräver källor där data endast läggs till, ange flaggan hoppa över flaggan för ändringsåtaganden när du läser från en källströmningstabell om bearbetningen kräver strömning från en källströmningstabell med förändringar (till exempel vid DML-uttalanden). När skipChangeCommits anges ignoreras transaktioner som tar bort eller ändrar poster i källtabellen. Om din bearbetning inte kräver en strömmande tabell kan du använda en materialiserad vy (som inte har append-only-begränsningen) som måltabell.

Följande är exempel på DML-instruktioner för att ändra poster i en strömningstabell.

Ta bort poster med ett specifikt ID:

DELETE FROM my_streaming_table WHERE id = 123;

Uppdatera poster med ett specifikt ID:

UPDATE my_streaming_table SET name = 'Jane Doe' WHERE id = 123;

Publicera tabeller med radfilter och kolumnmasker

Viktig

Den här funktionen finns i offentlig förhandsversion.

Radfilter kan du ange en funktion som används som ett filter när en tabellgenomsökning hämtar rader. Dessa filter säkerställer att efterföljande frågor endast returnerar rader som filterpredikatet utvärderas till sant för.

Kolumnmasker gör att du kan maskera en kolumns värden när en tabellgenomsökning hämtar rader. Framtida frågor för kolumnen returnerar den utvärderade funktionens resultat i stället för kolumnens ursprungliga värde. Mer information om hur du använder radfilter och kolumnmasker finns i Filtrera känsliga tabelldata med hjälp av radfilter och kolumnmasker.

Hantera radfilter och kolumnmasker

Radfilter och kolumnmasker på materialiserade vyer och strömmande tabeller bör läggas till, uppdateras eller tas bort via CREATE OR REFRESH-instruktionen.

Detaljerad syntax för att definiera tabeller med radfilter och kolumnmasker finns i referens för DLT SQL-språk- och DLT Python-språkreferens.

Uppförande

Följande är viktig information när du använder radfilter eller kolumnmasker i DLT-pipelines:

  • Uppdatera som ägare: När en pipelineuppdatering uppdaterar en materialiserad vy eller en strömmande tabell körs radfilter- och kolumnmaskfunktionerna med pipelineägarens rättigheter. Det innebär att tabelluppdateringen använder säkerhetskontexten för den användare som skapade pipelinen. Funktioner som kontrollerar användarkontexten (till exempel CURRENT_USER och IS_MEMBER) utvärderas med hjälp av pipelineägarens användarkontext.
  • Query: När du kör frågor mot en materialiserad vy eller en strömmande tabell utvärderas funktioner som kontrollerar användarkontexten (till exempel CURRENT_USER och IS_MEMBER) med hjälp av anroparens användarkontext. Den här metoden tillämpar användarspecifika datasäkerhets- och åtkomstkontroller baserat på den aktuella användarens kontext.
  • När du skapar materialiserade vyer över källtabeller som innehåller radfilter och kolumnmasker är uppdateringen av den materialiserade vyn alltid en fullständig uppdatering. En fullständig uppdatering ombearbetar alla data som är tillgängliga i källan med de senaste definitionerna. Den här processen kontrollerar att säkerhetsprinciperna i källtabellerna utvärderas och tillämpas med de mest up-todatumdata och definitioner.

Observerbarhet

Använd DESCRIBE EXTENDED, INFORMATION_SCHEMAeller Katalogutforskaren för att undersöka befintliga radfilter och kolumnmasker som gäller för en viss materialiserad vy eller strömningstabell. Med den här funktionen kan användarna granska och utvärdera dataåtkomst och skyddsåtgärder för materialiserade vyer och strömmande tabeller.