Vad är Unity Catalog?

Unity Catalog är en enhetlig data- och AI-styrningslösning som är inbyggd direkt i Azure Databricks-plattformen. Det här är en översikt över viktiga begrepp i Unity Catalog och hur du använder Unity Catalog för att styra data.

Viktiga pelare i Unity Catalog är följande:

• Enhetlig åtkomstkontroll: Unity Catalog erbjuder en enda plats för att hantera behörigheter för tabeller, filer, modeller och andra objekt från ett enda gränssnitt.
• Dataidentifiering: Unity Catalog ger användarna möjlighet att hitta och förstå datatillgångar via ett sökbart gränssnitt som berikas med taggar, beskrivningar och metadata.
• Automatiserad ursprungsspårning: Spåra dataflödet automatiskt och hur det omvandlas från källa till slutgiltiga vyer och instrumentpaneler.
• Granskning: Säkerställ ett fullständigt register över all dataåtkomst och systemloggar för att uppfylla säkerhetskrav och efterlevnadsföreskrifter.
• Övervakning av datakvalitet: Spåra proaktivt hälsotillståndet för dina datatillgångar med inbyggd profilering och aviseringar som fångar avvikelser innan de når nedströmskonsumenter.
• Säker datadelning: Utbyta realtidsdata på ett säkert sätt mellan organisationer och moln med hjälp av det öppna deltadelningsprotokollet, vilket eliminerar behovet av komplex ETL eller datakopiering.

Unity Catalog är också tillgängligt som en implementering med öppen källkod. Se meddelandebloggen och den offentliga GitHub-lagringsplatsen för Unity Catalog.

Objektmodellen för Unity Catalog

I Unity Catalog modelleras varje tillgång som du styr som ett objekt. Mer specifikt kallas dessa objekt för skyddsbara objekt i Unity Catalog. Du kan använda principer och metadata för åtkomstkontroll, till exempel taggar för att styra dessa skyddsbara objekt.

Skyddsbara objekt finns i objektmodellhierarkin i Unity Catalog, rotade på ett speciellt objekt som kallas metaarkivet. Under den följer datatillgångar som tabeller, vyer, volymer, funktioner och modeller ett namnområde på tre nivåer (catalog.schema.object). Andra objekt, till exempel autentiseringsuppgifter för lagring, externa platser, anslutningar och resurser, ligger direkt under metaarkivet.

Den här hierarkin är grunden för hur Unity Catalog organiserar tillgångar och framtvingar styrning. Mer information om objektmodellen i Unity Catalog och varje skyddsbart objekt finns i Referens för skyddsbara objekt i Unity Catalog. Information om hur behörighetsmodellen fungerar i kontexten för Unity Catalog-objektmodellen finns i Begrepp för enhetskatalogens behörighetsmodell.

Administratörsroller

Administratörer ansvarar för att övervaka styrningen i Unity Catalog. Följande är de olika nivåerna av administratörsroller och deras standardprivilegier:

• Kontoadministratörer kan skapa metaarkiv, länka arbetsytor till metaarkiv, lägga till användare och tilldela behörigheter för metaarkiv.
• Arbetsyteadministratörer kan lägga till användare i en arbetsyta och hantera många arbetsytespecifika objekt som jobb och notebook-filer. Beroende på arbetsytan kan arbetsyteadministratörer också ha många behörigheter för metaarkivet som är kopplat till arbetsytan.
• Metaarkivadministratörer är valfria roller som kan hantera tabell- och volymlagring på metaarkivnivå. Det är också praktiskt om du vill hantera data centralt över flera arbetsytor i en region.

Mer information finns i Administratörsbehörigheter i Unity Catalog.

Bevilja och återkalla åtkomst till skyddsbara objekt

Privilegierade användare kan bevilja och återkalla åtkomst till skyddsbara objekt på valfri nivå i hierarkin, inklusive själva metaarkivet. Åtkomst till ett objekt medför implicit samma åtkomst till alla dess underordnade objekt, såvida åtkomsten inte återkallas.

Du kan använda vanliga ANSI SQL-kommandon för att bevilja och återkalla åtkomst till objekt i Unity Catalog. Till exempel:

GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;

Du kan också använda Catalog Explorer, Databricks CLI och REST API:er för att hantera objektbehörigheter.

Metaarkivadministratörer, ägare av ett objekt och användare med MANAGE privilege på ett objekt kan bevilja och återkalla åtkomst. Information om hur du hanterar privilegier i Unity Catalog finns i Hantera privilegier i Unity Catalog.

Standardåtkomst till databasobjekt i Unity Catalog

Unity Catalog fungerar enligt principen om lägsta behörighet, där användarna har den lägsta åtkomst de behöver för att utföra sina nödvändiga uppgifter. När en arbetsyta skapas har icke-administratörsanvändare endast åtkomst till den automatiskt etablerade arbetsytekatalogen, vilket gör den här katalogen till en lämplig plats för användare att prova processen med att skapa och komma åt databasobjekt i Unity Catalog. Se Katalogbehörigheter för arbetsytor.

Hanterade kontra externa tabeller och volymer

Tabeller och volymer kan vara hanterade eller externa.

• Hanterade tabeller hanteras helt av Unity Catalog, vilket innebär att Unity Catalog hanterar både styrningen och de underliggande datafilerna för varje hanterad tabell. Hanterade tabeller lagras på en Unity Catalog-hanterad plats i din molnlagring. Hanterade tabeller använder alltid Delta Lake-formatet. Du kan lagra hanterade tabeller på metaarkiv-, katalog- eller schemanivåer.
• Externa tabeller är tabeller vars åtkomst från Azure Databricks hanteras av Unity Catalog, men vars datalivscykel och fillayout hanteras med hjälp av din molnleverantör och andra dataplattformar. Vanligtvis använder du externa tabeller för att registrera stora mängder av dina befintliga data i Azure Databricks, eller om du också behöver skrivåtkomst till data med hjälp av verktyg utanför Azure Databricks. Externa tabeller stöds i flera dataformat. När en extern tabell har registrerats i ett Unity Catalog-metaarkiv kan du hantera och granska åtkomsten till Azure Databricks---och arbeta med den--- precis som med hanterade tabeller.
• Hanterade volymer hanteras helt av Unity Catalog, vilket innebär att Unity Catalog hanterar åtkomsten till volymens lagringsplats i ditt molnleverantörskonto. När du skapar en hanterad volym lagras den automatiskt på den hanterade lagringsplats som tilldelats till det innehållande schemat.
• Externa volymer representerar befintliga data på lagringsplatser som hanteras utanför Azure Databricks, men som registrerats i Unity Catalog för att styra och granska åtkomst inifrån Azure Databricks. När du skapar en extern volym i Azure Databricks anger du dess plats, som måste finnas på en sökväg som definieras på en extern plats i Unity Catalog.

Databricks rekommenderar hanterade tabeller och volymer för de flesta användningsfall, eftersom de gör att du kan dra full nytta av unity catalog-styrningsfunktioner och prestandaoptimeringar. Information om vanliga användningsfall för externa tabeller och volymer finns i Hanterade och externa tabeller och Hanterade och externa volymer.

Se även:

• Unity Catalog-hanterade tabeller i Azure Databricks för Delta Lake och Apache Iceberg
• Arbeta med externa tabeller
• Hanterade kontra externa volymer.

Molnlagring och dataisolering

Unity Catalog använder molnlagring på två primära sätt:

• Hanterad lagring: standardplatser för hanterade tabeller och hanterade volymer (ostrukturerade, icke-tabellbaserade data) som du skapar i Azure Databricks. Dessa hanterade lagringsplatser kan definieras på metaarkiv-, katalog- eller schemanivå. Du skapar hanterade lagringsplatser i molnleverantören, men deras livscykel hanteras helt av Unity Catalog.
• Lagringsplatser där externa tabeller och volymer lagras. Det här är tabeller och volymer vars åtkomst från Azure Databricks hanteras av Unity Catalog, men vars datalivscykel och fillayout hanteras med hjälp av din molnleverantör och andra dataplattformar. Vanligtvis använder du externa tabeller eller volymer för att registrera stora mängder av dina befintliga data i Azure Databricks, eller om du också behöver skrivåtkomst till data med hjälp av verktyg utanför Azure Databricks.

Styra åtkomsten till molnlagring med hjälp av externa platser

Både hanterade lagringsplatser och lagringsplatser där externa tabeller och volymer lagras använder externa platsskyddbara objekt för att hantera åtkomst från Azure Databricks. Externa platsobjekt refererar till en molnlagringssökväg och de lagringsautentiseringsuppgifter som krävs för att komma åt den. Autentiseringsuppgifter för lagring är själva Skyddsbara objekt i Unity Catalog som registrerar de autentiseringsuppgifter som krävs för att få åtkomst till en viss lagringssökväg. Tillsammans säkerställer dessa skyddsbara objekt att åtkomsten till lagringen styrs och spåras av Unity Catalog.

Diagrammet nedan visar hur externa platser refererar till lagringsuppgifter och molnlagringsplatser.

I det här diagrammet:

• Varje extern plats refererar till en lagringsautentiseringsuppgift och en molnlagringsplats.
• Flera externa platser kan referera till samma lagringsautentiseringsuppgifter. Lagringsautentiseringsuppgifter 1 ger åtkomst till allt under sökvägen bucket/tables/*, så både extern plats A och extern plats B refererar till den.

Mer information finns i Hur styr Unity Catalog åtkomsten till molnlagring?.

Hierarki för hanterad lagringsplats

På vilken nivå du definierar hanterad lagring i Unity Catalog beror på vilken dataisoleringsmodell du föredrar. Din organisation kan kräva att vissa typer av data lagras i specifika konton eller bucketar i din molnklientorganisation.

Unity Catalog ger dig möjlighet att konfigurera hanterade lagringsplatser på metaarkiv-, katalog- eller schemanivå för att uppfylla sådana krav.

Anta till exempel att din organisation har en efterlevnadsprincip för företaget som kräver att produktionsdata som rör personal finns i containern abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. I Unity Catalog kan du uppnå det här kravet genom att ange en plats på katalognivå, skapa en katalog med namnet, till exempel hr_prod, och tilldela platsen abfss://mycompanyhr-prod@storage-account.dfs.core.windows.net/unity-catalog till den. Det innebär att hanterade tabeller eller volymer som skapats i hr_prod-katalogen (till exempel med CREATE TABLE hr_prod.default.table …) lagrar sina data i abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Valfritt kan du välja att ange platser på schemanivå för att organisera data inom hr_prod catalog på en mer detaljerad nivå.

Om lagringsisolering inte krävs för vissa kataloger kan du ange en lagringsplats på metaarkivnivå. Den här platsen fungerar som standardplats för hanterade tabeller och volymer i kataloger och scheman som inte har tilldelats lagring. Databricks rekommenderar dock vanligtvis att du tilldelar separata hanterade lagringsplatser för varje katalog.

Systemet utvärderar hierarkin för lagringsplatser från schema till katalog till metaarkiv.

Om en tabell myCatalog.mySchema.myTable till exempel skapas i my-region-metastorebestäms lagringsplatsen för tabellen enligt följande regel:

1. Om en plats har angetts för mySchemalagras den där.
2. Om inte, och en plats har angetts på myCatalog, lagras den där.
3. Slutligen, om ingen plats har angetts på myCatalog, kommer den att lagras på den plats som är associerad med my-region-metastore.

Mer information finns i Ange en hanterad lagringsplats i Unity Catalog.

Miljöisolering med arbetsyta-katalogbindning

Som standard kan katalogägare (och metaarkivadministratörer, om de har definierats för kontot) göra en katalog tillgänglig för användare på flera arbetsytor som är kopplade till samma Unity Catalog-metaarkiv.

Organisations- och efterlevnadskrav anger ofta att du behåller vissa data, till exempel personliga data, endast tillgängliga i vissa miljöer. Du kanske också vill hålla produktionsdata isolerade från utvecklingsmiljöer eller se till att vissa datauppsättningar och domäner aldrig kopplas samman.

I Azure Databricks är arbetsytan den primära databearbetningsmiljön och kataloger är den primära datadomänen. Unity Catalog låter metaarkivadministratörer, katalogägare och användare med MANAGE behörighet tilldela, eller "binda", kataloger till specifika arbetsytor. Dessa miljömedvetna bindningar ger dig möjlighet att se till att endast vissa kataloger är tillgängliga på en arbetsyta, oavsett de specifika behörigheterna för dataobjekt som beviljas en användare. Om du använder arbetsytor för att isolera åtkomst till användardata kanske du vill begränsa katalogåtkomsten till specifika arbetsytor i ditt konto för att säkerställa att vissa typer av data endast bearbetas på dessa arbetsytor. Du kanske vill ha separata arbetsytor för produktion och utveckling, till exempel eller en separat arbetsyta för bearbetning av personliga data. Detta kallas arbetsytekatalogbindning. Se Begränsa katalogåtkomst till specifika arbetsytor.

Hur gör jag för att konfigurera Unity Catalog för min organisation?

Om du vill använda Unity Catalog måste din Azure Databricks-arbetsyta vara aktiverad för Unity Catalog, vilket innebär att arbetsytan är kopplad till ett Unity Catalog-metaarkiv.

Hur kopplas en arbetsyta till ett metaarkiv? Det beror på kontot och arbetsytan:

• När du skapar en Azure Databricks-arbetsyta i en region för första gången skapas vanligtvis metaarkivet automatiskt och kopplas till arbetsytan.
• För vissa äldre konton måste en kontoadministratör skapa metaarkivet och tilldela arbetsytorna i den regionen till metaarkivet. Instruktioner finns i Skapa ett Unity Catalog-metaarkiv.
• Om ett konto redan har ett metaarkiv tilldelat för en region kan en kontoadministratör bestämma om metaarkivet ska kopplas automatiskt till alla nya arbetsytor i den regionen. Se Aktivera att ett metaarkiv tilldelas automatiskt till nya arbetsytor.

Oavsett om din arbetsyta har aktiverats för Unity Catalog automatiskt eller inte krävs även följande steg för att komma igång med Unity Catalog:

• Skapa kataloger och scheman som ska innehålla databasobjekt som tabeller och volymer.
• Skapa hanterade lagringsplatser för att lagra de hanterade tabellerna och volymerna i dessa kataloger och scheman.
• Ge användare åtkomst till kataloger, scheman och databasobjekt.

Arbetsytor som aktiveras automatiskt för Unity Catalog etablerar en arbetsytekatalog med breda behörigheter som beviljas alla arbetsyteanvändare. Den här katalogen är en praktisk startpunkt för att testa Unity Catalog.

Detaljerade installationsinstruktioner finns i Komma igång med Unity Catalog.

Uppgradera en befintlig arbetsyta till Unity Catalog

Information om hur du uppgraderar en arbetsyta som inte är en Unity-katalog till Unity Catalog finns i Uppgradera en Azure Databricks-arbetsyta till Unity Catalog.

Krav och begränsningar för Unity-katalogen

Unity Catalog kräver specifika typer av beräknings- och filformat, som beskrivs nedan. Nedan visas även några Azure Databricks-funktioner som inte stöds fullt ut i Unity Catalog på alla Databricks Runtime-versioner.

Regionstöd

Alla regioner stöder Unity Catalog. Mer information finns i Azure Databricks-regioner.

Beräkningskrav

Unity Catalog stöds på kluster som kör Databricks Runtime 11.3 LTS eller senare. Unity Catalog stöds som standard i alla SQL Warehouse-beräkningsversioner .

Kluster som körs på tidigare versioner av Databricks Runtime har inte stöd för alla unity catalog GA-funktioner.

För att få åtkomst till data i Unity Catalog måste kluster konfigureras med rätt åtkomstläge. Unity Catalog är säker som standard. Om ett kluster inte har konfigurerats med standard- eller dedikerat åtkomstläge kan klustret inte komma åt data i Unity Catalog. Se Åtkomstlägen.

Detaljerad information om funktionsändringar i Unity Catalog i varje Databricks Runtime-version finns i viktig information.

Stöd för filformat

Unity Catalog stöder följande tabellformat:

• Hanterade tabeller måste använda tabellformatet delta eller iceberg .
• Externa tabeller kan använda delta, CSV, JSON, avro, parquet, ORCeller text.

Begränsningar

Unity Catalog har följande begränsningar. Vissa av dessa är specifika för äldre Databricks Runtime-versioner och beräkningsåtkomstlägen.

Strukturerade strömningsarbetsbelastningar har ytterligare begränsningar, beroende på Databricks Runtime och åtkomstläge. Se Krav och begränsningar för standardberäkning ochdedikerade beräkningskrav och begränsningar.

Databricks släpper nya funktioner som krymper listan regelbundet.

• Grupper som tidigare har skapats i en arbetsyta (dvs. grupper på arbetsytenivå) kan inte användas i Unity Catalog-instruktioner GRANT . Detta är för att säkerställa en konsekvent vy över grupper som kan sträcka sig över arbetsytor. Om du vill använda grupper i GRANT -instruktioner skapar du dina grupper på kontonivå och uppdaterar all automatisering för huvudkonto- eller grupphantering (till exempel SCIM-, Okta- och Microsoft Entra-ID-anslutningsappar och Terraform) för att referera till kontoslutpunkter i stället för arbetsyteslutpunkter. Se Gruppkällor.

• Arbetsbelastningar i R stöder inte användning av dynamiska vyer för säkerhet på radnivå eller kolumnnivå vid beräkning som kör Databricks Runtime 15.3 och lägre.

  • Använd en dedikerad beräkningsresurs som kör Databricks Runtime 15.4 LTS eller senare för arbetsbelastningar i R som frågar dynamiska vyer. Sådana arbetsbelastningar kräver också en arbetsyta som är aktiverad för serverlös beräkning. Mer information finns i Detaljerad åtkomstkontroll för dedikerad beräkning.

• En hanterad tabell kan ytligt klonas till en annan hanterad tabell som går på Databricks Runtime 13.3 LTS och senare. En extern tabell kan ytligt klonas till en annan extern tabell på Databricks Runtime 14.2 och senare. En hanterad tabell kan inte klonas ytligt till en extern tabell. En extern tabell kan inte heller ytklonas till en hanterad tabell. Mer information finns i Shallow clone for Unity Catalog tables.

• Bucketing stöds inte för Unity Catalog-tabeller. Om du kör kommandon som försöker skapa en bucketad tabell i Unity Catalog utlöser det ett undantag.

• Att skriva till samma sökväg eller Delta Lake-tabell från arbetsytor i flera regioner kan leda till otillförlitliga prestanda om vissa kluster har åtkomst till Unity Catalog och andra inte.

• Att manipulera partitioner för externa tabeller med hjälp av kommandon som ALTER TABLE ADD PARTITION kräver att loggning av partitionsmetadata aktiveras. Se Partitionsidentifiering för externa tabeller.

• När du använder överskrivningsläge för tabeller som inte är i Delta-format måste användaren ha CREATE TABLE behörighet för det överordnade schemat och måste vara ägare till det befintliga objektet ELLER ha behörigheten ÄNDRA för objektet.

• Python-UDF:er stöds inte i Databricks Runtime 12.2 LTS och nedan. Detta inkluderar UDAFs, UDTF:er och Pandas på Spark (applyInPandas och mapInPandas). Python-skalära UDF:er stöds i Databricks Runtime 13.3 LTS och senare.

• Scala-UDF:er stöds inte i Databricks Runtime 14.1 och lägre vid beräkning med standardåtkomstläge. Skalära UDF:er stöds i Databricks Runtime 14.2 och senare vid beräkning med standardåtkomstläge.

• Standard Scala-trådpooler stöds inte. Använd i stället de särskilda trådpoolerna i org.apache.spark.util.ThreadUtils, till exempel org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool. Följande trådpooler i ThreadUtils stöds dock inte: ThreadUtils.newForkJoinPool och alla ScheduledExecutorService trådpooler.

• Azure-diagnostikloggar loggar endast Unity Catalog-händelser på arbetsytenivå. Om du vill visa åtgärder på kontonivå måste du använda systemtabellen för granskningsloggar. Se systemtabellreferens för granskningsloggar.

Modeller som är registrerade i Unity Catalog har ytterligare begränsningar. Se Begränsningar.

Resurskvoter

Unity Catalog tillämpar resurskvoter på alla skyddbara objekt. Dessa kvoter visas i Resursgränser. Om du förväntar dig att överskrida dessa resursgränser kontaktar du ditt Azure Databricks-kontoteam.

Du kan övervaka din kvotanvändning med hjälp av API:erna för Enhetskatalogens resurskvoter. Se Övervaka din användning av Unity Catalog-resurskvoter.

Ytterligare resurser

• Datastyrning med Azure Databricks
• Uppgradera en Azure Databricks-arbetsyta till Unity Catalog
• metodtips för Unity Catalog