Bästa praxis för Unity Catalog

Det här dokumentet innehåller rekommendationer för att använda Unity Catalog för att uppfylla dina datastyrningsbehov mest effektivt. En introduktion till datastyrning i Azure Databricks finns i Datastyrning med Azure Databricks. En introduktion till Unity Catalog finns i Vad är Unity Catalog?.

Identiteter

Huvudkonton (användare, grupper och tjänstens huvudnamn) måste definieras på Azure Databricks-kontonivå för att tilldelas behörigheter för skyddsbara objekt i Unity Catalog. Databricks rekommenderar att du använder SCIM för att tilldela huvudmän till ditt Azure Databricks-konto från din IdP.

Metodtips:

• Undvik (och inaktivera befintlig) SCIM-etablering på arbetsytenivå. Tilldelning av huvudprinciper direkt i en arbetsyta bör reserveras för äldre miljöer som inte har stöd för Unity Catalog. Du bör hantera försörjning helt på kontonivå.

• Definiera och hantera grupper i din IdP. De bör vara konsekventa med organisationens gruppdefinitioner.

  Grupper beter sig annorlunda än användare och tjänstprincipaler. Även om användare och tjänstens huvudnamn som du lägger till i en arbetsyta synkroniseras automatiskt med ditt Azure Databricksaccount, är grupper på arbetsytenivå inte det. Om du har arbetsytelokala grupper bör du migrera dem manuellt till kontot, helst genom att replikera dem i din IdP (om det behövs) och tilldela dem till kontot.

• Konfigurera grupper så att du kan använda dem effektivt för att ge åtkomst till data och andra Unity Catalog-skyddsbara enheter. Undvik direkta bidrag till användare när det är möjligt.

• Använd grupper för att tilldela ägarskap till de flesta skyddsbara objekt.

• Undvik att lägga till användare manuellt, antingen till kontot eller arbetsytan. Undvik att ändra grupper i Azure Databricks: använd din IdP.

• Använd tjänstprincipaler för att köra jobb. Tjänstprincipaler möjliggör jobbautomatisering. Om du låter användare köra jobb som skriver till produktion, riskerar du att skriva över produktionsdata av misstag.

Mer information finns i Hantera användare, tjänstens huvudnamn och grupper ochSynkronisera användare och grupper från Microsoft Entra-ID med SCIM.

Administratörsroller och kraftfulla privilegier

Tilldela administratörsroller och kraftfulla privilegier som ALL PRIVILEGES och MANAGE kräver försiktighet:

• Förstå behörigheterna för kontoadministratörer, arbetsyteadministratörer och metaarkivadministratörer innan du tilldelar dem. Se administratörsbehörigheter i Unity Catalog.
• Tilldela dessa roller till grupper när det är möjligt.
• Metaarkiv-administratörer är valfria. Tilldela dem bara om du behöver dem. Vägledning finns i (Valfritt) Tilldela administratörsrollen för metaarkivet.
• Tilldela objektägarskap till grupper, särskilt om objekt används i produktion. Skaparen av ett objekt är dess första ägare. Skapare bör omtilldela ägarskap till lämpliga grupper.
• Endast metaarkivadministratörer, ägare och användare med behörighet för MANAGE ett objekt kan bevilja behörighet för objektet. Ägare av överordnade kataloger och scheman har också möjlighet att bevilja behörigheter för alla objekt i katalogen eller schemat. Var sparsam med tilldelningen av ägarskap och av privilegiet MANAGE.
• Spara i tilldelningen av ALL PRIVILEGES, som innehåller alla privilegier förutom MANAGE, EXTERNAL USE LOCATIONoch EXTERNAL USE SCHEMA.

Behörighetstilldelning

Skyddsbara objekt i Unity Catalog är hierarkiska och privilegier ärvs nedåt. Använd den här arvshierarkin för att utveckla en effektiv privilegierad modell.

Metodtips:

• Förstå rollen för behörigheterna USE CATALOG och USE SCHEMA :

  • USE CATALOG | SCHEMA ger möjlighet att visa data i katalogen eller schemat. I sig självt beviljar inte dessa privilegier SELECT eller READ på objekten i katalogen eller schemat, men de är en förutsättning för att ge användare denna åtkomst. Bevilja endast dessa privilegier till användare som ska kunna visa data i katalogen eller schemat.
  • USE CATALOG | SCHEMA, genom att begränsa åtkomsten till en katalog eller ett schema, hindrar objektägare (till exempel en tabellskapare) från att oavsiktligt tilldela åtkomst till objektet (tabellen) till användare som inte borde ha åtkomst. Det är typiskt att skapa ett schema per team och bevilja USE SCHEMA och CREATE TABLE endast till det teamet (tillsammans med USE CATALOG i den överordnade katalogen).

• Förstå behörighetens BROWSE roll:

  • BROWSE tillåter användare att visa metadata för objekt i en katalog med hjälp av Katalogutforskaren, schemaläsaren, sökningen, ursprungsdiagrammet information_schemaoch REST-API:et. Den beviljar inte åtkomst till data.
  • BROWSE gör det möjligt för användare att identifiera data och begära åtkomst till dem, även om de inte har behörigheten USE CATALOG eller USE SCHEMA .
  • Databricks rekommenderar att du beviljar BROWSE för kataloger till gruppen All account users på katalognivå för att göra data upptäckbara och för att underlätta för åtkomstförfrågningar.

• Konfigurera mål för åtkomstbegäran för att stödja självbetjäningsåtkomst:

  • När mål för åtkomstbegäran inte har konfigurerats kan användarna inte begära åtkomst till objekt, även om de kan identifiera dem.
  • Databricks rekommenderar att du aktiverar standardmål för e-post så att begäranden skickas automatiskt till katalogens ägare eller objektägare när inget annat mål har konfigurerats.
  • Destination kan konfigureras för e-postadresser, Slack, Microsoft Teams, PagerDuty, webhooks eller en omdirigerings-URL till organisationens förfrågningssystem.

• Förstå skillnaden mellan objektägarskap och behörigheten MANAGE :

  • Ett objekts ägare har alla behörigheter för objektet, till exempel SELECT och MODIFY i en tabell, samt behörighet att bevilja behörigheter för det skyddsbara objektet till andra huvudkonton och att överföra ägarskapet till andra huvudkonton.
  • Ägare kan ge MANAGE behörigheten att delegera ägarskapsförmågor för ett objekt till andra aktörer.
  • Katalog- och schemaägare kan överföra ägarskapet för valfritt objekt i katalogen eller schemat.
  • Det är bäst att konfigurera ägarskap eller bevilja behörigheten MANAGE för alla objekt till en grupp som ansvarar för administrationen av bidrag för objektet.

• Reservera direktåtkomst till produktionstabeller för tjänstprincipaler.

Mer information finns i Hantera privilegier i Unity Catalog.

Metadatakataloger

Följande är regler och metodtips för att skapa och hantera metaarkiv:

• Du kan bara ha ett metadatalager per region. Alla arbetsytor i den regionen delar den metastore. Information om hur du delar data mellan regioner finns i Delning mellan regioner och plattformar.

• Metaarkiv ger regional isolering men är inte avsedda som standardenheter för dataisolering. Dataisolering börjar vanligtvis på katalognivå. Men om du föredrar en mer centraliserad styrningsmodell kan du skapa hanterad lagring på metaarkivnivå. Rekommendationer finns i Hanterad lagring.

• Administratörsrollen för metaarkivet är valfri. Rekommendationer om huruvida du vill tilldela en valfri metaarkivadministratör finns i Administratörsroller och kraftfulla privilegier.

Kataloger och scheman

Kataloger är den primära dataisoleringsenheten i den typiska datastyrningsmodellen för Unity Catalog. Scheman lägger till ytterligare ett organisationslager.

Metodtips för katalog- och schemaanvändning:

• Organisera data och AI-objekt i kataloger och scheman som återspeglar organisationsdivisioner och projekt. Det innebär ofta att kataloger motsvarar ett miljöomfång, team, affärsenhet eller någon kombination av dessa. Detta gör det enklare att använda behörighetshierarkin för att hantera åtkomst effektivt.
• När både arbetsmiljöer och data har samma isoleringskrav kan du binda en katalog till en specifik arbetsyta. När det krävs skapar du kataloger som kan begränsas till en begränsad uppsättning arbetsytor.
• Tilldela alltid ägarskap för produktionskataloger och scheman till grupper, inte enskilda användare.
• Bevilja USE CATALOG och USE SCHEMA endast till användare som ska kunna se eller göra sökfrågor på den data som finns där.

Mer information om hur du beviljar behörigheter för kataloger och scheman finns i Behörighetstilldelning.

Hanterad lagring

Hanterade tabeller och volymer, objekt vars livscykel hanteras helt av Unity Catalog, lagras på standardlagringsplatser, så kallade hanterad lagring. Du kan konfigurera hanterad lagring på metaarkiv-, katalog- eller schemanivå. Data lagras på den lägsta tillgängliga platsen i hierarkin. Mer information finns i Hierarki för hanterad lagringsplats och Ange en hanterad lagringsplats i Unity Catalog.

Metodtips för hanterade lagringsplatser:

• Ge företräde åt lagring på katalognivå som den primära dataisoleringsenheten.

  Lagring på metaarkivnivå krävdes i tidiga Unity Catalog-miljöer men krävs inte längre.

• Om du väljer att skapa en hanterad plats på metaarkivnivå använder du en dedikerad container.

• Använd inte en container som kan nås utanför Unity Catalog.

  Om en extern tjänst eller en huvudprincip kommer åt data på den hanterade lagringsplatsen och därmed kringgår Unity Catalog, äventyras åtkomstkontrollen och granskningsmöjligheterna för hanterade tabeller och volymer.

• Återanvänd inte en container som är eller användes för DBFS-rotfilsystemet.

• Om du har lagringsintensiva arbetsbelastningar ska du inte använda ett enda lagringskonto och en container för hanterad lagring och andra externa platser.

  re:[ADLS]-konton stöder som standard 20 000 begäranden per sekund. Detta kan orsaka begränsning av arbetsbelastningen och inbromsning. Om du använder flera containrar i samma lagringskonto ändras inte den här kontoomfattande gränsen. Du bör därför fördela lagringen över flera lagringskonton.

  Sådan striping skulle vara osynlig för Slutanvändarna i Unity Catalog.

Hanterade och externa tabeller

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. De är alltid i Delta- eller Apache Iceberg-format.

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. När du skapar en extern tabell 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.

Använd hanterade tabeller:

• För de flesta användningsfall. Databricks rekommenderar hanterade tabeller och volymer eftersom de gör att du kan dra full nytta av Unity Catalog-styrningsfunktioner och prestandaoptimeringar, inklusive:

  • Automatisk komprimering
  • Automatisk optimering
  • Snabbare metadataläsningar (cachelagring av metadata)
  • Intelligenta filstorleksoptimeringar

  Nya Azure Databricks-funktioner ger företräde åt hanterade tabeller.

• För alla nya tabeller.

Använd externa tabeller:

• När du redan använder dem och uppgraderar från Hive-metaarkivet till Unity Catalog.

  • Att använda externa tabeller kan ge en snabb och sömlös uppgradering med ett klick utan att flytta data.
  • Databricks rekommenderar att du så småningom migrerar externa tabeller till hanterade tabeller.

• Om du har krav på haveriberedskap för dessa data som inte kan uppfyllas av hanterade tabeller.

  Hanterade tabeller kan inte registreras i flera metaarkiv i samma moln.

• Om externa läsare eller skrivare måste kunna interagera med data utanför Databricks.

  Normalt bör du undvika att tillåta extern åtkomst även till de externa tabeller som är registrerade i Unity Catalog. Detta kringgår åtkomstkontroll, granskning och ursprung i Unity Catalog. Det är en bättre praxis att använda hanterade tabeller och dela data mellan regioner eller molnleverantörer med Delta Sharing. Om du måste tillåta extern åtkomst till externa tabeller begränsar du den till läsningar, där alla skrivningar sker via Azure Databricks och Unity Catalog.

• Du måste ha stöd för tabeller som inte är delta- eller icke-isbergstabeller, till exempel Parquet, Avro, ORC och så vidare.

Fler rekommendationer för att använda externa tabeller:

• Databricks rekommenderar att du skapar externa tabeller med en extern plats per schema.
• Databricks rekommenderar starkt att du inte registrerar en tabell som en extern tabell i mer än ett metaarkiv på grund av risken för konsekvensproblem. En ändring av schemat i ett metaarkiv registreras till exempel inte i det andra metaarkivet. Använd Deltadelning för att dela data mellan metaarkiv. Se Delning mellan regioner och plattformar.

Se även Azure Databricks-tabeller.

Hanterade och externa volymer

Hanterade volymer hanteras helt av Unity Catalog, vilket innebär att Unity Catalog hanterar åtkomsten till volymens lagringsplats i ditt molnleverantörskonto. 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.

Använd hanterade volymer:

• För de flesta användningsfall kan du dra full nytta av styrningsfunktionerna i Unity Catalog.
• Om du vill skapa tabeller som börjar från filer i en volym utan att köra COPY INTO eller CTAS-instruktioner (CREATE TABLE AS).

Använd externa volymer:

• Att registrera landningsområden för rådata som produceras av externa system för att stödja bearbetningen i ett tidigt skede av ETL-pipelines och andra datateknikaktiviteter.
• Om du vill registrera mellanlagringsplatser för inmatning, till exempel med hjälp av Auto Loader- COPY INTOeller CTAS-instruktioner.
• Tillhandahålla fillagringsplatser för dataforskare, dataanalytiker och maskininlärningstekniker som kan användas som delar av deras undersökande dataanalys och andra datavetenskapsuppgifter, när hanterade volymer inte är ett alternativ.
• För att ge Azure Databricks-användare åtkomst till godtyckliga filer som produceras och deponeras i molnlagring av andra system, till exempel stora samlingar av ostrukturerade data (till exempel bild-, ljud-, video- och PDF-filer) som fångas av övervakningssystem eller IoT-enheter eller biblioteksfiler (JAR och Python-hjulfiler) som exporteras från lokala beroendehanteringssystem eller CI/CD-pipelines.
• Om du vill lagra driftdata, till exempel loggnings- eller kontrollpunktsfiler, när hanterade volymer inte är ett alternativ.

Fler rekommendationer för att använda externa volymer:

• Databricks rekommenderar att du skapar externa volymer från en extern plats inom ett schema.

Se även Hanterade kontra externa volymer och externa platser.

Externa platser

Externa platsobjekt som kan säkerställas, genom att kombinera lagringsuppgifter och lagringssökvägar, ger stark kontroll och möjliggör granskning av lagringsåtkomst. Det är viktigt att förhindra användare från att komma åt containrar som registrerats som externa platser direkt och kringgå åtkomstkontrollen som tillhandahålls av Unity Catalog.

Så här använder du externa platser effektivt:

• Se till att du begränsar antalet användare med direkt åtkomst till alla containrar som används som en extern plats.

• Montera inte lagringskonton till DBFS om de också används som externa platser. Databricks rekommenderar att du migrerar monteringar på molnlagringsplatser till externa platser i Unity Catalog med hjälp av Catalog Explorer.

• Ge möjligheten att endast skapa externa platser till administratörer som har till uppgift att konfigurera anslutningar mellan Unity Catalog och molnlagring, eller till betrodda datatekniker.

  Externa platser ger åtkomst inifrån Unity Catalog till en brett omfattande plats i molnlagring, till exempel en hel bucket eller container (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net) eller en bred underväg (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog). Avsikten är att en molnadministratör kan vara involverad i att konfigurera några externa platser och sedan delegera ansvaret för att hantera dessa platser till en Azure Databricks-administratör i din organisation. Azure Databricks-administratören kan sedan ytterligare organisera den externa platsen i områden med mer detaljerade behörigheter genom att registrera externa volymer eller externa tabeller med specifika prefix under den externa platsen.

  Eftersom externa platser är så omfattande rekommenderar Databricks att endast ge CREATE EXTERNAL LOCATION behörighet till en administratör som har till uppgift att konfigurera anslutningar mellan Unity Catalog och molnlagring eller till betrodda datatekniker. För att ge andra användare mer detaljerad åtkomst rekommenderar Databricks att du registrerar externa tabeller eller volymer ovanpå externa platser och ger användarna åtkomst till data med hjälp av volymer eller tabeller. Eftersom tabeller och volymer är underordnade till en katalog och ett schema har katalog- eller schemaadministratörer den ultimata kontrollen över åtkomstbehörigheter.

  Du kan också styra åtkomsten till en extern plats genom att binda den till specifika arbetsytor. Se (Valfritt) Tilldela en extern plats till specifika arbetsytor.

• Bevilja inte allmänna READ FILES eller WRITE FILES behörigheter på externa platser till slutanvändare.

  Användare bör inte använda externa platser för något annat än att skapa tabeller, volymer eller hanterade platser. De bör inte använda externa platser för sökvägsbaserad åtkomst för datavetenskap eller andra icke-tabellbaserade dataanvändningsfall.

  Använd volymer för sökvägsbaserad åtkomst till data som inte är tabellbaserade. Moln-URI-åtkomst till data under volymsökvägen styrs av de behörigheter som beviljas på volymen, inte behörigheterna som beviljas på den externa plats där volymen lagras.

  Med volymer kan du arbeta med filer med SQL-kommandon, dbutils, Spark-API:er, REST-API:er, Terraform och ett användargränssnitt för att bläddra, ladda upp och ladda ned filer. Dessutom erbjuder volymer en FUSE-montering som är tillgänglig i det lokala filsystemet under /Volumes/<catalog_name>/<schema_name>/<volume_name>/. FUSE-monteringen gör det möjligt för dataforskare och ML-tekniker att komma åt filer som om de vore i ett lokalt filsystem, vilket krävs av många maskininlärnings- eller operativsystembibliotek.

  Om du måste ge direkt åtkomst till filer på en extern plats (för att utforska filer i molnlagring innan en användare till exempel skapar en extern tabell eller volym) kan du bevilja READ FILES. Användningsfall för beviljande WRITE FILES är sällsynta.

• Undvik sökvägskonflikter: Skapa aldrig externa volymer eller tabeller i roten på en extern plats.

  Om du skapar externa volymer eller tabeller i roten för den externa platsen kan du inte skapa några ytterligare externa volymer eller tabeller på den externa platsen. Skapa i stället externa volymer eller tabeller på en underkatalog på den externa platsen.

Du bör endast använda externa platser för att göra följande:

• Registrera externa tabeller och volymer med hjälp av CREATE EXTERNAL VOLUME kommandona eller CREATE TABLE .
• Registrera en plats som hanterad lagringsplats. Privilegiet CREATE MANAGED STORAGE är en förutsättning.
• Utforska befintliga filer i molnlagring innan du skapar en extern tabell eller volym med ett specifikt prefix. Privilegiet READ FILES är en förutsättning. Tilldela den här behörigheten sparsamt. Mer information finns i rekommendationen i föregående lista.

Externa platser jämfört med externa volymer

Innan volymerna släpptes tilldelade READ FILES vissa Unity Catalog-implementeringar åtkomst direkt till externa platser för datautforskning. Med tillgängligheten för volymer som registrerar filer i valfritt format, inklusive strukturerade, halvstrukturerade och ostrukturerade data, finns det ingen verklig anledning att använda externa platser för något annat än att skapa tabeller, volymer eller hanterade platser. Detaljerad information om när du ska använda externa platser och när du ska använda volymer finns i Hanterade och externa volymer och Externa platser.

Delning mellan regioner och plattformar

Du kan bara ha ett metadatalager per region. Om du vill dela data mellan arbetsytor i olika regioner använder du Databricks-till-Databricks Delta Sharing.

Metodtips:

• Använd ditt metaarkiv för en enda region för alla omfattningar av programvaruutvecklingens livscykel och affärsavdelningar, till exempel utveckling (dev), testning (test), produktion (prod), försäljning och marknadsföring. Se till att de arbetsytor som kräver frekvent delad dataåtkomst finns i samma region.
• Använd Databricks-to-Databricks Delta Sharing mellan molnregioner eller molnleverantörer.
• Använd Delta Sharing för tabeller som används sällan eftersom du ansvarar för utgående avgifter från molnregion till molnregion. Om du måste dela ofta använda data mellan regioner eller molnleverantörer kan du läsa: Övervaka och hantera kostnader för datadelning (för leverantörer).

Tänk på följande begränsningar när du använder Databricks-till-Databricks-delning:

• Härstamningsdiagram skapas på metadatabasnivå och går inte över regions- eller plattformsgränser. Detta gäller även om en resurs delas mellan metaarkiv inom samma Databricks-konto: källelinjens information syns inte i destinationen och vice versa.
• Åtkomstkontroll definieras på metaarkivnivå och går inte över region- eller plattformsgränser. Om en resurs har tilldelats behörigheter och resursen delas till ett annat metaarkiv i kontot gäller inte behörigheterna för den resursen för målresursen. Du måste tilldela behörigheter på målresursdelningen.

Beräkningskonfigurationer

Databricks rekommenderar att du använder beräkningsprinciper för att begränsa möjligheten att konfigurera kluster baserat på en uppsättning regler. Med beräkningsprinciper kan du begränsa användare till att skapa Unity Catalog-aktiverade kluster, särskilt kluster som använder standardåtkomstläge (tidigare delat åtkomstläge) eller dedikerat åtkomstläge (tidigare en användare eller tilldelat åtkomstläge).

Endast kluster som använder något av dessa åtkomstlägen kan komma åt data i Unity Catalog. All serverlös beräkning och DBSQL-beräkning stöder Unity Catalog.

Databricks rekommenderar standardåtkomstläge för alla arbetsbelastningar. Använd endast dedikerat åtkomstläge om de funktioner som krävs inte stöds av standardåtkomstläget. Se åtkomstlägen.