Vad är Unity Catalog?

Den här artikeln introducerar Unity Catalog, en enhetlig styrningslösning för data och AI-tillgångar i Databricks lakehouse.

Översikt över Unity Catalog

Unity Catalog tillhandahåller centraliserade funktioner för åtkomstkontroll, granskning, ursprung och dataidentifiering i Azure Databricks-arbetsytor.

Unity Catalog diagram

Viktiga funktioner i Unity Catalog är:

  • Definiera en gång, säkert överallt: Unity Catalog erbjuder en enda plats för att administrera principer för dataåtkomst som gäller för alla arbetsytor.
  • Standardkompatibel säkerhetsmodell: Unity Catalogs säkerhetsmodell baseras på ansi-standard-SQL och tillåter administratörer att bevilja behörigheter i sin befintliga datasjö med hjälp av välbekant syntax, på katalognivå, databaser (kallas även scheman), tabeller och vyer.
  • Inbyggd granskning och ursprung: Unity Catalog samlar automatiskt in granskningsloggar på användarnivå som registrerar åtkomst till dina data. Unity Catalog samlar också in ursprungsdata som spårar hur datatillgångar skapas och används på alla språk.
  • Dataidentifiering: Med Unity Catalog kan du tagga och dokumentera datatillgångar och tillhandahåller ett sökgränssnitt som hjälper datakonsumenter att hitta data.
  • Systemtabeller (offentlig förhandsversion): Med Unity Catalog kan du enkelt komma åt och fråga efter ditt kontos driftdata, inklusive granskningsloggar, fakturerbar användning och ursprung.

Hur styr Unity Catalog åtkomsten till data och AI-tillgångar i molnobjektlagring?

Databricks rekommenderar att du konfigurerar all åtkomst till molnobjektlagring med hjälp av Unity Catalog. Se Anslut till molnobjektlagring med hjälp av Unity Catalog.

Unity Catalog introducerar följande begrepp för att hantera relationer mellan data i Azure Databricks och molnobjektlagring:

Kommentar

Lakehouse Federation tillhandahåller integreringar av data i andra externa system. Dessa objekt backas inte upp av molnobjektlagring.

Objektmodellen för Unity Catalog

I Unity Catalog flödar hierarkin för primära dataobjekt från metaarkiv till tabell eller volym:

  • Metastore: Containern på den översta nivån för metadata. Varje metaarkiv exponerar ett namnområde på tre nivåer (catalog.schema.table) som organiserar dina data.
  • Katalog: Det första lagret i objekthierarkin, som används för att organisera dina datatillgångar.
  • Schema: Scheman kallas även databaser och är det andra lagret i objekthierarkin och innehåller tabeller och vyer.
  • Tabeller, vyer och volymer: På den lägsta nivån i dataobjekthierarkin finns tabeller, vyer och volymer. Volymer ger styrning för icke-tabelldata.
  • Modeller: Även om de inte strikt sett är datatillgångar, kan registrerade modeller också hanteras i Unity Catalog och finnas på den lägsta nivån i objekthierarkin.

Unity Catalog object model diagram

Det här är en förenklad vy över skyddsbara Unity Catalog-objekt. Mer information finns i Skydda objekt i Unity Catalog.

Du refererar till alla data i Unity Catalog med hjälp av ett namnområde på tre nivåer: catalog.schema.asset, där asset kan vara en tabell, vy, volym eller modell.

Metaarkiv

Ett metaarkiv är den översta containern för objekt i Unity Catalog. Den registrerar metadata om data och AI-tillgångar och de behörigheter som styr åtkomsten till dem. Azure Databricks-kontoadministratörer bör skapa ett metaarkiv för varje region där de arbetar och tilldela dem till Azure Databricks-arbetsytor i samma region. För att en arbetsyta ska kunna använda Unity Catalog måste den ha ett Unity Catalog-metaarkiv kopplat.

Ett metaarkiv kan eventuellt konfigureras med en hanterad lagringsplats i en Azure Data Lake Storage Gen2-container eller Cloudflare R2-bucket i ditt eget molnlagringskonto. Se Hanterad lagring.

Kommentar

Det här metaarkivet skiljer sig från Hive-metaarkivet som ingår i Azure Databricks-arbetsytor som inte har aktiverats för Unity Catalog. Om din arbetsyta innehåller ett äldre Hive-metaarkiv är data i metaarkivet fortfarande tillgängliga tillsammans med data som definierats i Unity Catalog i en katalog med namnet hive_metastore. Observera att hive_metastore katalogen inte hanteras av Unity Catalog och inte drar nytta av samma funktionsuppsättning som kataloger som definierats i Unity Catalog.

Se Skapa ett Unity Catalog-metaarkiv.

Kataloger

En katalog är det första lagret i Unity Catalogs namnområde på tre nivåer. Den används för att organisera dina datatillgångar. Användarna kan se alla kataloger där de har tilldelats databehörighetenUSE CATALOG.

Beroende på hur din arbetsyta skapades och aktiverades för Unity Catalog kan användarna ha standardbehörigheter för automatiskt etablerade kataloger, inklusive antingen main katalogen eller arbetsytekatalogen (<workspace-name>). Mer information finns i Standardbehörigheter för användare.

Se Skapa och hantera kataloger.

Scheman

Ett schema (kallas även en databas) är det andra lagret i Unity Catalogs namnområde på tre nivåer. Ett schema organiserar tabeller och vyer. Användarna kan se alla scheman där de har tilldelats behörigheten USE SCHEMA , tillsammans med behörigheten USE CATALOG i schemats överordnade katalog. För att få åtkomst till eller visa en tabell eller vy i ett schema måste användarna också ha SELECT behörighet för tabellen eller vyn.

Om din arbetsyta har aktiverats för Unity Catalog manuellt innehåller den ett standardschema med namnet default i main katalogen som är tillgängligt för alla användare på din arbetsyta. Om din arbetsyta har aktiverats för Unity Catalog automatiskt och innehåller en <workspace-name> katalog innehåller katalogen ett schema med namnet default som är tillgängligt för alla användare på din arbetsyta.

Se Skapa och hantera scheman (databaser).

Tabeller

En tabell finns i det tredje lagret i Unity Catalogs namnområde på tre nivåer. Den innehåller rader med data. Om du vill skapa en tabell måste användarna ha CREATE och USE SCHEMA behörigheter för schemat, och de måste ha behörigheten för USE CATALOG den överordnade katalogen. Om du vill köra frågor mot en tabell måste användarna ha behörigheten SELECT i tabellen, behörigheten USE SCHEMA för det överordnade schemat och behörigheten för USE CATALOG den överordnade katalogen.

En tabell kan hanteras eller vara extern.

Hanterade tabeller

Hanterade tabeller är standardsättet för att skapa tabeller i Unity Catalog. Unity Catalog hanterar livscykeln och fillayouten för dessa tabeller. Du bör inte använda verktyg utanför Azure Databricks för att ändra filer i dessa tabeller direkt. Hanterade tabeller använder alltid deltatabellformatet .

För arbetsytor som har aktiverats för Unity Catalog manuellt lagras hanterade tabeller på den rotlagringsplats som du konfigurerar när du skapar ett metaarkiv. Du kan också ange lagringsplatser för hanterade tabeller på katalog- eller schemanivå, vilket översidosätter rotlagringsplatsen.

För arbetsytor som aktiverades automatiskt för Unity Catalog är rotlagringsplatsen för metaarkiv valfri och hanterade tabeller lagras vanligtvis på katalog- eller schemanivå.

När en hanterad tabell tas bort tas dess underliggande data bort från molnklientorganisationen inom 30 dagar.

Se Hanterade tabeller.

Externa tabeller

Externa tabeller är tabeller vars datalivscykel och fillayout inte hanteras av Unity Catalog. Använd externa tabeller för att registrera stora mängder befintliga data i Unity Catalog, eller om du behöver direkt åtkomst till data med hjälp av verktyg utanför Azure Databricks-kluster eller Databricks SQL-lager.

När du släpper en extern tabell tar Unity Catalog inte bort underliggande data. Du kan hantera behörigheter för externa tabeller och använda dem i frågor på samma sätt som hanterade tabeller.

Externa tabeller kan använda följande filformat:

  • DELTA
  • CSV
  • JSON
  • AVRO
  • PARKETT
  • ORC
  • TEXT

Se Externa tabeller.

Visningar

En vy är ett skrivskyddat objekt som skapats från en eller flera tabeller och vyer i ett metaarkiv. Den finns i det tredje lagret i Unity Catalogs namnområde på tre nivåer. En vy kan skapas från tabeller och andra vyer i flera scheman och kataloger. Du kan skapa dynamiska vyer för att aktivera behörigheter på rad- och kolumnnivå.

Se Skapa en dynamisk vy.

Volymer

Viktigt!

Den här funktionen finns som allmänt tillgänglig förhandsversion.

En volym finns i det tredje lagret i Unity Catalogs namnområde på tre nivåer. Volymer är syskon till tabeller, vyer och andra objekt som ordnas under ett schema i Unity Catalog.

Volymer innehåller kataloger och filer för data som lagras i valfritt format. Volymer ger icke-tabellåtkomst till data, vilket innebär att filer i volymer inte kan registreras som tabeller.

  • Om du vill skapa en volym måste användarna ha CREATE VOLUME och USE SCHEMA behörigheter för schemat, och de måste ha behörigheten för USE CATALOG den överordnade katalogen.
  • Om du vill läsa filer och kataloger som lagras i en volym måste användarna ha READ VOLUME behörigheten, behörigheten USE SCHEMA för det överordnade schemat och behörigheten för USE CATALOG den överordnade katalogen.
  • Om du vill lägga till, ta bort eller ändra filer och kataloger som lagras i en volym måste användarna ha WRITE VOLUME behörighet, behörigheten USE SCHEMA för det överordnade schemat och behörigheten för USE CATALOG den överordnade katalogen.

En volym kan hanteras eller vara extern.

Kommentar

När du definierar en volym styrs moln-URI-åtkomst till data under volymsökvägen av volymens behörigheter.

Hanterade volymer

Hanterade volymer är en praktisk lösning när du vill etablera en styrd plats för att arbeta med icke-tabellfiler.

Hanterade volymer lagrar filer i Enhetskatalogens standardlagringsplats för schemat där de finns. För arbetsytor som har aktiverats för Unity Catalog manuellt lagras hanterade volymer på den rotlagringsplats som du konfigurerar när du skapar ett metaarkiv. Du kan också ange hanterade volymlagringsplatser på katalog- eller schemanivå, vilket översidosätter rotlagringsplatsen. För arbetsytor som aktiverades automatiskt för Unity Catalog är rotlagringsplatsen för metaarkiv valfri och hanterade volymer lagras vanligtvis på katalog- eller schemanivå.

Följande prioritet styr vilken plats som används för en hanterad volym:

  • Schemaplats
  • Katalogplats
  • Rotlagringsplats för Unity Catalog-metaarkiv

När du tar bort en hanterad volym tas även filerna som lagras i den här volymen bort från molnklientorganisationen inom 30 dagar.

Se Vad är en hanterad volym?.

Externa volymer

En extern volym är registrerad på en extern plats i Unity Catalog och ger åtkomst till befintliga filer i molnlagring utan att datamigrering krävs. Användarna måste ha behörighet på CREATE EXTERNAL VOLUME den externa platsen för att kunna skapa en extern volym.

Externa volymer stöder scenarier där filer produceras av andra system och mellanlagras för åtkomst inifrån Azure Databricks med hjälp av objektlagring eller där verktyg utanför Azure Databricks kräver direkt filåtkomst.

Unity Catalog hanterar inte livscykeln och layouten för filerna i externa volymer. När du släpper en extern volym tar Unity Catalog inte bort underliggande data.

Se Vad är en extern volym?.

Modeller

En modell finns i det tredje lagret i Unity Catalogs namnområde på tre nivåer. I det här sammanhanget refererar "modell" till en maskininlärningsmodell som är registrerad i MLflow Model Registry. Om du vill skapa en modell i Unity Catalog måste användarna ha behörigheten CREATE MODEL för katalogen eller schemat. Användaren måste också ha behörigheten USE CATALOG för den överordnade katalogen och USE SCHEMA det överordnade schemat.

Hanterad lagring

Du kan lagra hanterade tabeller och hanterade volymer på någon av dessa nivåer i objekthierarkin i Unity Catalog: metaarkiv, katalog eller schema. Lagring på lägre nivåer i hierarkin åsidosätter lagring som definierats på högre nivåer.

När en kontoadministratör skapar ett metaarkiv manuellt kan de tilldela en lagringsplats i en Azure Data Lake Storage Gen2-container eller Cloudflare R2-bucket i ditt eget molnlagringskonto som ska användas som lagring på metaarkivnivå för hanterade tabeller och volymer. Om en hanterad lagringsplats på metaarkivnivå har tilldelats är hanterade lagringsplatser på katalog- och schemanivå valfria. Med det sagt är lagring på metaarkivnivå valfritt, och Databricks rekommenderar att du tilldelar hanterad lagring på katalognivå för logisk dataisolering. Se Byggstenar för datastyrning och dataisolering.

Viktigt!

Om din arbetsyta aktiverades automatiskt för Unity Catalog skapades Unity Catalog-metaarkivet utan hanterad lagring på metaarkivnivå. Du kan välja att lägga till lagring på metaarkivnivå, men Databricks rekommenderar att du tilldelar hanterad lagring på katalog- och schemanivå. Hjälp med att avgöra om du behöver lagring på metaarkivnivå finns i (Valfritt) Skapa lagring på metaarkivnivå och Data är fysiskt avgränsade i lagringen.

Hanterad lagring har följande egenskaper:

  • Hanterade tabeller och hanterade volymer lagrar data- och metadatafiler i hanterad lagring.
  • Hanterade lagringsplatser kan inte överlappa externa tabeller eller externa volymer.

I följande tabell beskrivs hur hanterad lagring deklareras och associeras med Unity Catalog-objekt:

Associerat Unity Catalog-objekt Så här ställer du in Relation till externa platser
Metaarkiv Konfigurerad av kontoadministratör när metaarkivet skapades eller lades till efter att metaarkivet skapades om inget lagringsutrymme angavs när det skapades. Det går inte att överlappa en extern plats.
Katalog Anges när katalogen skapades med hjälp av nyckelordet MANAGED LOCATION . Måste finnas på en extern plats.
Schema Anges när schemat skapades med hjälp av nyckelordet MANAGED LOCATION . Måste finnas på en extern plats.

Den hanterade lagringsplats som används för att lagra data och metadata för hanterade tabeller och hanterade volymer använder följande regler:

  • Om det innehållande schemat har en hanterad plats lagras data på den schemahanterade platsen.
  • Om det innehållande schemat inte har någon hanterad plats men katalogen har en hanterad plats lagras data på den kataloghanterade platsen.
  • Om varken det innehållande schemat eller den innehållande katalogen har en hanterad plats lagras data på den hanterade platsen för metaarkivet.

Autentiseringsuppgifter för lagring och externa platser

För att hantera åtkomst till den underliggande molnlagringen för externa tabeller, externa volymer och hanterad lagring använder Unity Catalog följande objekttyper:

Se Anslut till molnobjektlagring med hjälp av Unity Catalog.

Identitetshantering för Unity Catalog

Unity Catalog använder identiteterna i Azure Databricks-kontot för att lösa användare, tjänstens huvudnamn och grupper och för att framtvinga behörigheter.

Om du vill konfigurera identiteter i kontot följer du anvisningarna i Hantera användare, tjänstens huvudnamn och grupper. Se dessa användare, tjänstens huvudnamn och grupper när du skapar principer för åtkomstkontroll i Unity Catalog.

Användare, tjänsthuvudnamn och grupper i Unity Catalog måste också läggas till i arbetsytor för att få åtkomst till Unity Catalog-data i en notebook-fil, en Databricks SQL-fråga, Catalog Explorer eller ett REST API-kommando. Tilldelningen av användare, tjänstens huvudnamn och grupper till arbetsytor kallas identitetsfederation.

Alla arbetsytor som har ett Unity Catalog-metaarkiv kopplat till sig är aktiverade för identitetsfederation.

Särskilda överväganden för grupper

Alla grupper som redan finns på arbetsytan är märkta arbetsyta lokalt i kontokonsolen. Dessa arbetsytelokala grupper kan inte användas i Unity Catalog för att definiera åtkomstprinciper. Du måste använda grupper på kontonivå. Om en arbetsytelokal grupp refereras till i ett kommando returnerar kommandot ett fel om att gruppen inte hittades. Om du tidigare använde arbetsytelokala grupper för att hantera åtkomst till notebook-filer och andra artefakter gäller dessa behörigheter.

Se Hantera grupper.

Administratörsroller för Unity Catalog

Kontoadministratörer, metaarkivadministratörer och arbetsyteadministratörer deltar i hanteringen av Unity Catalog:

Se Administratörsbehörigheter i Unity Catalog.

Databehörigheter i Unity Catalog

I Unity Catalog är data säkra som standard. Inledningsvis har användarna ingen åtkomst till data i ett metaarkiv. Åtkomst kan beviljas av antingen en metaarkivadministratör, ägaren av ett objekt eller ägaren av katalogen eller schemat som innehåller objektet. Skyddsbara objekt i Unity-katalogen är hierarkiska och privilegierna ärvs nedåt.

Du kan tilldela och återkalla behörigheter med hjälp av Catalog Explorer, SQL-kommandon eller REST-API:er.

Se Hantera privilegier i Unity Catalog.

Beräknings- och klusteråtkomstlägen som stöds för Unity Catalog

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 något av åtkomstlägena som kan användas med Unity-Catalog (dvs. delat eller tilldelat) 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.

Begränsningarna för Unity Catalog varierar beroende på åtkomstläge och Databricks Runtime-version. Se Begränsningar för beräkningsåtkomstläge för Unity Catalog.

Data härstamning för Unity Catalog

Du kan använda Unity Catalog för att samla in körningsdata härstamning mellan frågor på valfritt språk som körs i ett Azure Databricks-kluster eller SQL-lager. Ursprunget avbildas ned till kolumnnivån och innehåller notebook-filer, arbetsflöden och instrumentpaneler relaterade till frågan. Mer information finns i Avbilda och visa data härstamning med hjälp av Unity Catalog.

Lakehouse Federation och Unity Catalog

Lakehouse Federation är frågefederationsplattformen för Azure Databricks. Termen frågefederation beskriver en samling funktioner som gör det möjligt för användare och system att köra frågor mot flera siloade datakällor utan att behöva migrera alla data till ett enhetligt system.

Azure Databricks använder Unity Catalog för att hantera frågefederation. Du använder Unity Catalog för att konfigurera skrivskyddade anslutningar till populära externa databassystem och skapa externa kataloger som speglar externa databaser. Unity Catalogs verktyg för datastyrning och dataursprung säkerställer att dataåtkomst hanteras och granskas för alla federerade frågor som görs av användarna på dina Azure Databricks-arbetsytor.

Se Vad är Lakehouse Federation.

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

Mer information om hur du konfigurerar Unity Catalog finns i Konfigurera och hantera Unity Catalog.

Regioner som stöds

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

Datafilformat som stöds

Unity Catalog stöder följande tabellformat:

Begränsningar i Unity-katalogen

Unity Catalog har följande begränsningar.

Kommentar

Om klustret körs på en Databricks Runtime-version under 11.3 LTS kan det finnas ytterligare begränsningar som inte visas här. Unity Catalog stöds på Databricks Runtime 11.3 LTS eller senare.

Begränsningarna i Unity Catalog varierar beroende på Databricks Runtime och åtkomstläge. Strukturerade strömningsarbetsbelastningar har ytterligare begränsningar baserat på Databricks Runtime och åtkomstläge. Se Begränsningar för beräkningsåtkomstläge för Unity Catalog.

  • Arbetsbelastningar i R stöder inte användning av dynamiska vyer för säkerhet på radnivå eller kolumnnivå.

  • I Databricks Runtime 13.1 och senare stöds grunda kloner för att skapa hanterade Unity Catalog-tabeller från befintliga hanterade Unity Catalog-tabeller. I Databricks Runtime 13.0 och nedan finns det inget stöd för grunda kloner i Unity Catalog. Se Ytlig klon för Unity Catalog-tabeller.

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

  • Anpassade partitionsscheman som skapats med kommandon som ALTER TABLE ADD PARTITION inte stöds för tabeller i Unity Catalog. Unity Catalog kan komma åt tabeller som använder partitionering i katalogformat.

  • Skriv över läge för DataFrame-skrivåtgärder till Unity Catalog stöds endast för Delta-tabeller, inte för andra filformat. Användaren måste ha behörigheten CREATE för det överordnade schemat och måste vara ägare till det befintliga objektet eller ha behörigheten MODIFY för objektet.

  • I Databricks Runtime 13.2 och senare stöds python-skalära UDF:er. I Databricks Runtime 13.1 och nedan kan du inte använda Python UDF:er, inklusive UDF:er, UDF:er och Pandas på Spark (applyInPandas och mapInPandas).

  • I Databricks Runtime 14.2 och senare stöds scala scalar-UDF:er i delade kluster. I Databricks Runtime 14.1 och nedan stöds inte alla Scala-UDF:er i delade kluster.

  • Grupper som tidigare har skapats i en arbetsyta (dvs. grupper på arbetsytenivå) kan inte användas i Unity Catalog GRANT-instruktioner. 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 huvud- eller grupphantering (till exempel SCIM-, Okta- och Microsoft Entra-ID-anslutningsappar (tidigare Azure Active Directory) och Terraform) för att referera till kontoslutpunkter i stället för arbetsyteslutpunkter. Se Skillnaden mellan kontogrupper och arbetsytelokala grupper.

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

  • Granskningsloggning stöds endast för Unity Catalog-händelser på arbetsytenivå. Händelser som äger rum på kontonivå utan referens till en arbetsyta, till exempel att skapa ett metaarkiv, loggas inte.

Följande begränsningar gäller för alla objektnamn i Unity Catalog:

  • Objektnamn får inte överstiga 255 tecken.
  • Följande specialtecken tillåts inte:
    • Period (.)
    • Blanksteg ( )
    • Snedstreck (/)
    • Alla ASCII-kontrolltecken (00–1F hex)
    • Tecknet DELETE (7F hex)
  • Unity Catalog lagrar alla objektnamn som gemener.
  • När du refererar till UC-namn i SQL måste du använda backticks för att undkomma namn som innehåller specialtecken som bindestreck (-).

Kommentar

Kolumnnamn kan använda specialtecken, men namnet måste tas bort med backticks i alla SQL-instruktioner om specialtecken används. Unity Catalog bevarar kolumnnamnshöljet, men frågor mot Unity Catalog-tabeller är skiftlägeskänsliga.

Ytterligare begränsningar finns för modeller i Unity Catalog. Se Begränsningar för stöd för Unity Catalog.

Resurskvoter

Unity Catalog tillämpar resurskvoter på alla skyddsbara objekt. Gränser respekterar samma hierarkiska organisation i hela Unity Catalog. Om du förväntar dig att överskrida dessa resursgränser kontaktar du ditt Azure Databricks-kontoteam.

Kvotvärdena nedan uttrycks i förhållande till det överordnade objektet (eller mor- och farföräldrarna) i Unity Catalog.

Objekt Parent Värde
table schema 10000
table metaarkiv 100000
volym schema 10000
function schema 10000
registrerad modell schema 1000
registrerad modell metaarkiv 5000
modellversion registrerad modell 10000
modellversion metaarkiv 100000
schema Katalog 10000
Katalog metaarkiv 1000
anslutning metaarkiv 1000
lagringsautentiseringsuppgifter metaarkiv 200
extern plats metaarkiv 500

Information om deltadelningsgränser finns i Resurskvoter.