Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird Unity Catalog vorgestellt, eine einheitliche Governancelösung für Daten und KI-Ressourcen in Azure Databricks. Es erläutert wichtige Konzepte und gibt einen Überblick über die Verwendung des Unity-Katalogs zum Steuern von Daten.
Hinweis
Unity Catalog ist auch als Open Source-Implementierung verfügbar. Weitere Informationen finden Sie im Ankündigungsblog sowie im öffentlichen GitHub-Repository für Unity Catalog.
Übersicht über Unity Catalog
Unity Catalog ist ein zentraler Datenkatalog, der Zugriffssteuerung, Überwachung, Lineage, Qualitätsüberwachung und Datenermittlungsfunktionen in Azure Databricks-Arbeitsbereichen bereitstellt.
Wichtige Features von Unity Catalog:
- Einmal definieren, überall sicher: Unity Catalog bietet einen einzigen Ort zum Verwalten von Datenzugriffsrichtlinien, die für alle Arbeitsbereiche in einer Region gelten.
- Standardkonformes Sicherheitsmodell: Das Sicherheitsmodell des Unity-Katalogs basiert auf standard ANSI SQL und ermöglicht Administratoren das Erteilen von Berechtigungen in ihrem vorhandenen Data Lake mithilfe der vertrauten Syntax.
- Integrierte Überwachung und Herkunft: Unity Catalog erfasst automatisch Überwachungsprotokolle auf Benutzerebene, in denen Zugriffe auf Ihre Daten erfasst werden. Unity Catalog erfasst auch Herkunftsdaten, die nachverfolgen, wie Datenressourcen über alle Sprachen hinweg erstellt und verwendet werden.
- Datenermittlung: Mit Unity Catalog können Sie Datenressourcen markieren und dokumentieren. Darüber hinaus bietet Unity Catalog eine Suchschnittstelle, die Datenconsumer beim Finden von Daten unterstützt.
- Systemtabellen: Im Unity-Katalog können Sie auf einfache Weise auf die Betriebsdaten Ihres Kontos zugreifen und diese abfragen, einschließlich Überwachungsprotokolle, abrechnende Nutzung und Lineage.
Metastore
Ein Metastore ist der oberste Container für Metadaten in Unity Catalog. Es registriert Metadaten zu Daten- und KI-Ressourcen und die Berechtigungen, die den Zugriff auf sie steuern. Damit ein Arbeitsbereich Unity Catalog verwendet, muss ein Unity Catalog-Metastore angefügt sein. Für jede Region, in der Sie über Arbeitsbereiche verfügen, sollte ein Metastore vorhanden sein.
Im Gegensatz zum Hive-Metastore ist der Unity Catalog-Metastore keine Dienstgrenze: Er wird in einer Mehrinstanzenumgebung ausgeführt und stellt eine logische Grenze für die Trennung von Daten nach Region für ein bestimmtes Azure Databricks-Konto dar.
Das Unity Catalog-Objektmodell
In einem Unity Catalog-Metastore besteht die dreistufige Datenbankobjekthierarchie aus Katalogen, die Schemas enthalten, die wiederum Daten und KI-Objekte wie Tabellen und Modelle enthalten. Diese Hierarchie wird als dreistufiger Namespace (catalog.schema.table-etc
) dargestellt, wenn Sie auf Tabellen, Ansichten, Volumes, Modelle und Funktionen verweisen.
Ebene 1:
- Kataloge werden verwendet, um Ihre Datenressourcen zu strukturieren, und fungieren in der Regel als oberste Ebene Ihres Datenisolationsschemas. Kataloge spiegeln häufig Organisationseinheiten oder Lebenszyklusbereiche in der Softwareentwicklung wieder. Weitere Informationen finden Sie unter Was sind Kataloge in Azure Databricks?.
- Objekte, die keine Daten sichern können, z. B. Speicherzugangsdaten und externe Speicherorte, werden verwendet, um Ihr Datengovernancemodell im Unity Catalog zu verwalten. Diese befinden sich ebenfalls direkt unter dem Metastore. Sie werden ausführlicher in sicherungsfähigen Objekten beschrieben, die Unity Catalog verwendet, um den Zugriff auf externe Datenquellen zu verwalten.
Ebene 2:
- Schemas (auch Datenbanken genannt) enthalten Tabellen, Ansichten, Speichervolumen, KI-Modelle und Funktionen. Schemas strukturieren Daten und KI-Ressourcen in logischen Kategorien, die differenzierter sind als Kataloge. In der Regel stellen sie einen einzelnen Anwendungsfall, ein bestimmtes Projekt oder eine Team-Sandbox dar. Weitere Informationen finden Sie unter Was sind Schemas in Azure Databricks?.
Ebene 3:
- Tabellen sind in Zeilen und Spalten strukturierte Datensammlungen. Tabellen können entweder verwaltet sein (in diesem Fall verwaltet Unity Catalog den gesamten Lebenszyklus der Tabelle), oder extern (in diesem Fall verwaltet Unity Catalog den Zugriff auf die Daten innerhalb von Azure Databricks, aber nicht den Zugriff auf die Daten im Cloudspeicher von anderen Clients). Siehe Einführung in Azure Databricks-Tabellen und Verwaltete und externe Tabellen und Volumes.
- Ansichten sind gespeicherte Abfragen für eine oder mehrere Tabellen. Siehe Was ist eine Ansicht?.
- Volumes stellen logische Datenmengen im Cloudobjektspeicher dar. Sie können Volumes verwenden, um Dateien in einem beliebigen Format zu speichern, zu organisieren und darauf zuzugreifen, einschließlich strukturierter, halbstrukturierter und unstrukturierter Daten. In der Regel werden sie für nicht tabellarische Daten verwendet. Volumes können entweder verwaltet sein (in diesem Fall verwaltet Unity Catalog den gesamten Lebenszyklus und das Layout der Daten im Speicher) oder extern (in diesem Fall verwaltet Unity Catalog den Zugriff auf die Daten innerhalb von Azure Databricks, aber nicht den Zugriff auf die Daten im Cloudspeicher von anderen Clients). Weitere Informationen finden Sie unter Was sind Unity Catalog-Volumes? sowie in der Gegenüberstellung von verwalteten und externen Tabellen und Volumes.
- Funktionen sind Einheiten gespeicherter Logik, die einen Skalarwert oder eine Gruppe von Zeilen zurückgeben. Weitere Informationen finden Sie unter Benutzerdefinierte Funktionen (UDFs, user-defined functions) in Unity Catalog.
- Modelle sind mit MLflow verpackte und in Unity Catalog als Funktionen registrierte KI-Modelle. Weitere Informationen dazu finden Sie unter Verwalten des Lebenszyklus von Modellen in Unity Catalog.
Sicherungsobjekte, die Unity Catalog zum Verwalten des Zugriffs auf externe Datenquellen verwendet
Zusätzlich zu den Datenbankobjekten und KI-Ressourcen, die in Schemas enthalten sind, verwendet Unity Catalog auch die folgenden sicherungsfähigen Objekte, um den Zugriff auf Cloudspeicher und andere externe Datenquellen und Dienste zu verwalten:
- Speicheranmeldeinformationen kapseln langfristige Cloudanmeldeinformationen, die den Zugriff auf Cloudspeicher ermöglichen. Siehe Erstellen einer Speicheranmeldeinformation zum Herstellen einer Verbindung mit Azure Data Lake Storage.
- Externe Speicherorte, die sowohl auf einen Cloudspeicherpfad als auch auf die für den Zugriff erforderlichen Speicheranmeldeinformationen verweisen. Externe Speicherorte können verwendet werden, um externe Tabellen zu erstellen oder einen verwalteten Speicherort für verwaltete Tabellen und Volumes zuzuweisen. Siehe Erstellen eines externen Speicherorts zum Verbinden von Cloudspeicher mit Azure Databricks, Cloudspeicher und Datenisolation und Angeben eines verwalteten Speicherorts im Unity-Katalog.
- Verbindungen stellen Anmeldeinformationen dar, die schreibgeschützten Zugriff auf eine externe Datenbank in einem Datenbanksystem wie MySQL unter Verwendung von Lakehouse Federation gewähren. Weitere Informationen finden Sie unter Was ist Lakehouse Federation?.
- Dienstanmeldeinformationen, die eine langfristige Cloudanmeldeinformationen kapseln, die Zugriff auf einen externen Dienst bieten. Siehe Erstellen von Dienstanmeldeinformationen.
Sicherungsobjekte, die Unity Catalog zum Verwalten des Zugriffs auf freigegebene Ressourcen verwendet
Unity Catalog verwendet die folgenden sicherungsfähigen Objekte zum Verwalten der Daten- und KI-Ressourcenfreigabe über Metastore- oder Organisationsgrenzen hinweg:
- Clean Rooms, die eine vom Databricks verwaltete Umgebung darstellen, in der mehrere Teilnehmer an Projekten zusammenarbeiten können, ohne zugrunde liegende Daten miteinander zu teilen. Siehe Was sind Azure Databricks Clean Rooms?.
- Freigaben sind Delta Sharing-Objekte, die eine schreibgeschützte Sammlung von Daten und KI-Ressourcen darstellen, die ein Datenanbieter für einen oder mehrere Empfänger freigibt.
- Empfänger sind Delta Sharing-Objekte, die eine Entität darstellen, welche Anteile von einem Datenanbieter erhält.
- Anbieter sind Delta Sharing-Objekte, die eine Entität darstellen, die Daten für einen Empfänger freigibt.
Weitere Informationen zu den sicherungsfähigen Delta Sharing-Objekten finden Sie unter Was ist Delta Sharing?.
Administratorrollen
Die folgenden Azure Databricks-Administratorrollen verfügen standardmäßig über viele Unity-Katalogberechtigungen:
- Kontoadministratoren: Können Metastores erstellen, Arbeitsbereiche mit Metastores verknüpfen, Benutzer hinzufügen und Berechtigungen für Metastores zuweisen.
- Arbeitsbereichsadministratoren: Sie können Einem Arbeitsbereich Benutzer hinzufügen und viele arbeitsbereichspezifische Objekte wie Aufträge und Notizbücher verwalten. Je nach Arbeitsbereich können Arbeitsbereichsadministratoren auch viele Berechtigungen für den Metastore haben, der an den Arbeitsbereich angefügt ist.
- Metastore-Administratoren: Diese optionale Rolle ist erforderlich, wenn Sie Tabellen- und Volumespeicher auf Metastore-Ebene verwalten möchten. Es ist auch praktisch, wenn Sie Daten zentral in mehreren Arbeitsbereichen in einer Region verwalten möchten.
Weitere Informationen finden Sie unter Administratorrechte im Unity-Katalog.
Gewähren und Widerrufen des Zugriffs auf sicherungsfähige Objekte
Privilegierte Benutzer können Zugriff auf sicherungsfähige Objekte auf jeder Ebene in der Hierarchie gewähren und widerrufen, einschließlich des Metaspeichers selbst. Durch Zugriff auf ein Objekt wird implizit der gleiche Zugriff auf alle untergeordneten Elemente dieses Objekts gewährt, es sei denn, der Zugriff wird widerrufen.
Sie können typische ANSI SQL-Befehle verwenden, um Zugriff auf Objekte in Unity Catalog zu gewähren und zu widerrufen. Zum Beispiel:
GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;
Objektberechtigungen können aber auch per Katalog-Explorer oder Databricks CLI oder mithilfe von REST-APIs verwaltet werden.
Metastore-Administratoren, Besitzer eines Objekts und Benutzer mit dem MANAGE privilege
auf einem Objekt können den Zugriff gewähren und widerrufen. Informationen zur Verwaltung von Berechtigungen in Unity Catalog finden Sie unter Verwalten von Berechtigungen in Unity Catalog.
Standardzugriff auf Datenbankobjekte in Unity Catalog
Unity Catalog basiert auf dem Prinzip der geringsten Rechte, bei dem Benutzer gerade über so viel Zugriff verfügen, wie sie für ihre erforderlichen Aufgaben benötigen. Wenn ein Arbeitsbereich erstellt wird, haben Benutzer ohne Administratorrechte nur Zugriff auf den automatisch bereitgestellten Arbeitsbereichskatalog. Dieser Katalog ist somit ein praktischer Ort für Benutzer, um sich mit der Erstellung von Datenbankobjekten in Unity Catalog sowie mit dem Zugriff auf diese Objekte vertraut zu machen. Weitere Informationen finden Sie unter Arbeitsbereichskatalogberechtigungen.
Verwenden von Datenbankobjekten in Unity Catalog
Das Arbeiten mit Datenbankobjekten im Unity-Katalog ähnelt dem Arbeiten mit Datenbankobjekten, die in einem Hive-Metaspeicher registriert sind, mit der Ausnahme, dass ein Hive-Metastore keine Kataloge im Objektnamespace enthält. Sie können vertraute ANSI-Syntax verwenden, um Datenbankobjekte zu erstellen, Datenbankobjekte zu verwalten, Berechtigungen zu verwalten und mit Daten in Unity Catalog zu arbeiten. Sie können aber auch den Katalog-Explorer verwenden, um Datenbankobjekte zu erstellen, Datenbankobjekte zu verwalten und Berechtigungen für Datenbankobjekte zu verwalten.
Weitere Informationen finden Sie unter Datenbankobjekte in Azure Databricks.
Gegenüberstellung von verwalteten und externen Tabellen und Volumes
Tabellen und Volumes können verwaltet oder extern sein.
- Verwaltete Tabellen werden vollständig von Unity Catalog verwaltet. Das bedeutet, dass Unity Catalog sowohl die Governance als auch die zugrunde liegenden Datendateien für jede verwaltete Tabelle verwaltet. Verwaltete Tabellen werden an einem von Unity Catalog verwalteten Speicherort in Ihrem Cloudspeicher gespeichert. Verwaltete Tabellen verwenden immer das Delta Lake-Format. Sie können verwaltete Tabellen auf Metastore-, Katalog- oder Schemaebene speichern.
- Externe Tabellen sind Tabellen, bei denen Unity Catalog den Zugriff über Azure Databricks verwaltet, aber für die Verwaltung des Datenlebenszyklus und des Dateilayouts Ihr Cloudanbieter und andere Datenplattformen verwendet werden. Externe Tabellen werden in der Regel verwendet, um große Mengen an bereits vorhandenen Daten in Azure Databricks zu registrieren oder wenn Sie auch Schreibzugriff auf die Daten über Tools außerhalb von Azure Databricks benötigen. Für externe Tabellen werden mehrere Datenformate unterstützt. Sobald eine externe Tabelle in einem Unity Catalog Metastore registriert ist, können Sie den Zugriff darauf durch Azure Databricks verwalten und überwachen und mit ihr arbeiten---genauso wie mit verwalteten Tabellen.
- Verwaltete Volumes werden vollständig vom Unity-Katalog verwaltet, was bedeutet, dass Unity Catalog den Zugriff auf den Speicherort des Volumes in Ihrem Cloudanbieterkonto verwaltet. Wenn Sie ein verwaltetes Volume erstellen, wird es automatisch an dem verwalteten Speicherort gespeichert, der dem enthaltenden Schema zugewiesen ist.
- Externe Volumes stellen vorhandene Daten an Speicherorten dar, die außerhalb von Azure Databricks verwaltet werden, aber in Unity Catalog registriert sind, um den Zugriff innerhalb von Azure Databricks zu steuern und zu überwachen. Wenn Sie ein externes Volume in Azure Databricks erstellen, geben Sie dessen Speicherort an. Dieser muss sich an einem Pfad befinden, der an einem externen Speicherort von Unity Catalog definiert ist.
Databricks empfiehlt verwaltete Tabellen und Volumes für die meisten Anwendungsfälle, da sie es Ihnen ermöglichen, die Governance-Funktionen und Leistungsoptimierungen von Unity Catalog vollständig zu nutzen. Informationen zu typischen Anwendungsfällen für externe Tabellen und Volumes finden Sie unter Verwaltete und externe Tabellen sowie verwaltete und externe Volumes.
Siehe auch:
- Verwaltete Tabellen im Unity-Katalog in Azure Databricks für Delta Lake und Apache Iceberg
- Arbeiten mit externen Tabellen
- Verwaltete und externe Volumes.
Cloudspeicher und Datenisolation
Unity-Katalog verwendet Cloudspeicher auf zwei primäre Arten:
- Verwalteter Speicher: Standardspeicherorte für verwaltete Tabellen und verwaltete Volumes (unstrukturierte, nicht tabellarische Daten), die Sie in Azure Databricks erstellen. Diese verwalteten Speicherorte können auf Metastore-, Katalog- oder Schemaebene definiert werden. Sie erstellen verwaltete Speicherorte in Ihrem Cloudanbieter, deren Lebenszyklus wird jedoch vollständig vom Unity-Katalog verwaltet.
- Speicherorte, an denen externe Tabellen und Volumes gespeichert werden. Dies sind Tabellen und Volumes, deren Zugriff von Azure Databricks vom Unity-Katalog verwaltet wird, deren Datenlebenszyklus und Dateilayout jedoch mit Ihrem Cloudanbieter und anderen Datenplattformen verwaltet werden. In der Regel verwenden Sie externe Tabellen oder Volumes, um große Mengen Ihrer vorhandenen Daten in Azure Databricks zu registrieren, oder wenn Sie auch Schreibzugriff auf die Daten mithilfe von Tools außerhalb von Azure Databricks benötigen.
Verwalten des Zugriffs auf Cloudspeicher mithilfe externer Speicherorte
Sowohl verwaltete Speicherorte als auch Speicherorte, an denen externe Tabellen und Volumes gespeichert werden, verwenden sicherungsfähige Objekte für externe Speicherorte , um den Zugriff von Azure Databricks zu verwalten. Externe Speicherortobjekte verweisen auf einen Cloudspeicherpfad und die für den Zugriff erforderlichen Speicheranmeldeinformationen . Anmeldeinformationen für die Speicherung sind selbst sichere Unity Catalog-Objekte, die die Anmeldeinformationen registrieren, die für den Zugriff auf einen bestimmten Speicherpfad erforderlich sind. Zusammen stellen diese sicherungsfähigen Elemente sicher, dass der Zugriff auf den Speicher vom Unity-Katalog gesteuert und nachverfolgt wird.
Die folgende Abbildung stellt die Dateisystemhierarchie eines einzelnen Cloudspeichercontainers mit vier externen Speicherorten dar, die eine Speicheranmeldeinformation gemeinsam nutzen.
Weitere Informationen finden Sie unter Wie regelt der Unity-Katalog den Zugriff auf Cloud-Speicher?.
Hierarchie verwalteter Speicherorte
Die Ebene, auf der Sie verwalteten Speicher im Unity-Katalog definieren, hängt von Ihrem bevorzugten Datenisolationsmodell ab. Ihre Organisation erfordert möglicherweise, dass bestimmte Datentypen in bestimmten Konten oder Buckets in Ihrem Cloudmandanten gespeichert werden.
Unity Catalog bietet Ihnen die Möglichkeit, verwaltete Speicherorte auf Metastore-, Katalog- oder Schemaebene zu konfigurieren, um diese Anforderungen zu erfüllen.
Angenommen, Ihre Organisation verfügt über eine Unternehmens-Compliance-Richtlinie, die erfordert, dass Personaldaten im Container abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net gehalten werden. Im Unity-Katalog können Sie diese Anforderung umsetzen, indem Sie einen Speicherort auf Katalogebene festlegen, z. B. einen Katalog namens hr_prod
erstellen und ihm den Speicherort abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog zuweisen. Dies bedeutet, dass verwaltete Tabellen oder Volumes, die hr_prod
im Katalog erstellt wurden (z. B. mithilfe von CREATE TABLE hr_prod.default.table …
) ihre Daten in abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog speichern. Optional können Sie festlegen, dass Speicherorte auf Schemaebene bereitgestellt werden, um Daten innerhalb von hr_prod catalog
auf granularerer Ebene zu organisieren.
Sollte für einige Kataloge keine Speicherisolation erforderlich sein, können Sie optional einen Speicherort auf Metastoreebene festlegen. Dieser Speicherort dient als Standardspeicherort für verwaltete Tabellen und Volumes in Katalogen und Schemas, die keinen Speicher zugewiesen haben. In der Regel empfiehlt es sich allerdings, separate verwaltete Speicherorte für jeden Katalog zuzuweisen.
Das System wertet die Hierarchie der Speicherorte von Schema zu Katalog zu Metastore aus.
Wenn beispielsweise eine Tabelle myCatalog.mySchema.myTable
in my-region-metastore
erstellt wird, wird der Speicherort der Tabelle gemäß der folgenden Regel bestimmt:
- Wenn ein Speicherort für
mySchema
bereitgestellt wurde, wird sie dort gespeichert. - Andernfalls, wenn ein Speicherort auf
myCatalog
bereitgestellt wurde, wird sie dort gespeichert. - Wenn kein Speicherort auf
myCatalog
angegeben wurde, wird sie schließlich an dem Speicherort gespeichert, dermy-region-metastore
zugeordnet ist.
Weitere Informationen finden Sie unter Angeben eines verwalteten Speicherorts im Unity-Katalog.
Isolierung der Umgebung durch Arbeitsbereich-Katalog-Bindung
Standardmäßig können Katalogbesitzer (und Metastore-Administratoren, sofern für das Konto definiert) einen Katalog für Benutzer in mehreren Arbeitsbereichen zugänglich machen, die an den gleichen Unity Catalog-Metastore angefügt sind.
Organisatorische und Complianceanforderungen schreiben oft vor, dass bestimmte Daten, z. B. personenbezogene Daten, nur in bestimmten Umgebungen zugänglich sein dürfen. Möglicherweise möchten Sie auch Produktionsdaten von Entwicklungsumgebungen isolieren oder sicherstellen, dass bestimmte Datasets und Domänen nie miteinander verknüpft werden.
In Azure Databricks ist der Arbeitsbereich die primäre Datenverarbeitungsumgebung, und Kataloge sind die primäre Datendomäne. Der Unity-Katalog erlaubt es Metastore-Administratoren, Katalogbesitzern und Benutzern mit der MANAGE
-Berechtigung, Kataloge an bestimmte Arbeitsbereiche zuzuweisen oder "zu binden". Mithilfe dieser sich an der Umgebung orientierenden Verknüpfungen können Sie sicherstellen, dass nur bestimmte Kataloge innerhalb eines Arbeitsbereichs verfügbar sind, unabhängig von den spezifischen Berechtigungen für Datenobjekte, die einem Benutzer gewährt werden. Wenn Sie allerdings Arbeitsbereiche verwenden, um den Benutzerdatenzugriff zu isolieren, empfiehlt es sich gegebenenfalls, den Katalogzugriff auf bestimmte Arbeitsbereiche in Ihrem Konto einzuschränken, um sicherzustellen, dass bestimmte Arten von Daten nur in diesen Arbeitsbereichen verarbeitet werden. Sie können beispielsweise separate Produktions- und Entwicklungsarbeitsbereiche oder einen separaten Arbeitsbereich für die Verarbeitung persönlicher Daten einrichten. Dies wird als Arbeitsbereichskatalogbindung bezeichnet. Weitere Informationen finden Sie unter Einschränken des Katalogzugriffs auf bestimmte Arbeitsbereiche.
Hinweis
Für eine erhöhte Datenisolation können Sie auch den Cloudspeicherzugriff und den Clouddienstzugriff an bestimmte Arbeitsbereiche binden. Siehe (Optional) Zuweisen von Speicheranmeldeinformationen zu bestimmten Arbeitsbereichen, (Optional) Zuweisen eines externen Speicherorts zu bestimmten Arbeitsbereichen und (Optional) Zuweisen einer Dienstanmeldeinformationen zu bestimmten Arbeitsbereichen.
Wie richte ich Unity Catalog für meine Organisation ein?
Für die Verwendung von Unity Catalog muss Ihr Azure Databricks-Arbeitsbereich für Unity Catalog aktiviert (sprich: an einen Unity Catalog-Metastore angefügt) sein.
Wie wird ein Arbeitsbereich an einen Metastore verbunden? Dies hängt von dem Konto und dem Arbeitsbereich ab:
- Wenn Sie zum ersten Mal einen Azure Databricks-Arbeitsbereich in einer Region erstellen, wird der Metastore automatisch erstellt und dem Arbeitsbereich zugeordnet.
- Bei einigen älteren Konten muss ein Kontoadministrator den Metastore erstellen und die Arbeitsbereiche in dieser Region dem Metastore zuweisen. Anweisungen finden Sie unter Erstellen eines Unity Catalog-Metastores.
- Wenn einem Konto bereits ein Metaspeicher für eine Region zugewiesen ist, kann ein Kontoadministrator entscheiden, ob der Metastore automatisch an alle neuen Arbeitsbereiche in dieser Region angefügt werden soll. Siehe Aktivieren eines Metastores, der automatisch neuen Arbeitsbereichen zugewiesen werden soll.
Die folgenden Schritte müssen unabhängig davon ausgeführt werden, ob Ihr Arbeitsbereich automatisch für Unity Catalog aktiviert wurde:
- Erstellen von Katalogen und Schemas für Datenbankobjekte wie Tabellen und Volumes
- Erstellen verwalteter Speicherorte zum Speichern der verwalteten Tabellen und Volumes in diesen Katalogen und Schemas
- Gewähren von Benutzerzugriff auf Kataloge, Schemas und Datenbankobjekte
Automatisch für Unity Catalog aktivierte Arbeitsbereiche stellen einen Arbeitsbereichskatalog mit umfassenden Berechtigungen bereit, die allen Arbeitsbereichsbenutzern gewährt werden. Dieser Katalog ist ein praktischer Ausgangspunkt, um sich mit Unity Catalog vertraut zu machen.
Ausführliche Anweisungen zum Einrichten finden Sie unter "Erste Schritte mit Unity-Katalog".
Aktualisieren eines vorhandenen Arbeitsbereichs auf den Unity-Katalog
Informationen darüber, wie ein Arbeitsbereich ohne Unity-Katalog auf den Unity-Katalog aktualisiert wird, finden Sie unter Aktualisierung von Azure Databricks-Arbeitsbereichen zum Unity-Katalog.
Anforderungen und Einschränkungen von Unity Catalog
Unity Catalog erfordert bestimmte Arten von Computeressourcen und Dateiformaten. Diese werden im Anschluss beschrieben. Außerdem sind im Anschluss einige Azure Databricks-Features aufgeführt, die in Unity Catalog nicht für alle Databricks Runtime-Versionen uneingeschränkt unterstützt werden.
Regionsunterstützung
Alle Regionen unterstützen Unity Catalog. Weitere Informationen finden Sie unter Azure Databricks-Regionen.
Computeanforderungen
Unity Catalog wird in Clustern unterstützt, auf denen Databricks Runtime 11.3 LTS oder höher ausgeführt wird. Unity Catalog wird standardmäßig in allen SQL-Warehouse-Computeversionen unterstützt.
Cluster, die in früheren Versionen von Databricks Runtime ausgeführt werden, bieten keine Unterstützung für alle GA-Features und -Funktionen von Unity Catalog.
Um auf Daten in Unity Catalog zuzugreifen, müssen Cluster mit dem richtigen Zugriffsmodus konfiguriert werden. Unity Catalog ist standardmäßig geschützt. Wenn ein Cluster nicht mit dem Standard- oder dedizierten Zugriffsmodus konfiguriert ist, kann der Cluster nicht auf Daten im Unity-Katalog zugreifen. Weitere Informationen finden Sie unter Zugriffsmodi.
Ausführliche Informationen zu den Änderungen der Unity Catalog-Funktionen in jeder Databricks Runtime-Version finden Sie in den Versionshinweisen.
Einschränkungen für Unity Catalog variieren je nach Zugriffsmodus und Databricks Runtime-Version. Siehe Einschränkungen des Computezugriffsmodus für Unity Catalog.
Unterstützung von Dateiformaten
Unity Catalog unterstützt die folgenden Tabellenformate:
-
Verwaltete Tabellen müssen das Tabellenformat
delta
verwenden. -
Externe Tabellen können
delta
,CSV
,JSON
,avro
,parquet
,ORC
odertext
verwenden.
Einschränkungen
Für Unity Catalog gelten die folgenden Einschränkungen: Einige davon gelten speziell für ältere Versionen der Databricks Runtime und die Zugriffsmodi für die Berechnung.
Für Workloads für strukturiertes Streaming gelten je nach Databricks Runtime-Version und Zugriffsmodus zusätzliche Einschränkungen. Siehe Einschränkungen des Computezugriffsmodus für Unity Catalog.
Databricks veröffentlicht regelmäßig neue Funktionen, durch die sich diese Liste immer weiter verkürzt.
- Zuvor in einem Arbeitsbereich erstellte Gruppen (also Gruppen auf Arbeitsbereichsebene) können nicht in
GRANT
-Anweisungen von Unity Catalog verwendet werden. Dadurch soll eine konsistente Ansicht von Gruppen sichergestellt werden, die sich über mehrere Arbeitsbereiche erstrecken kann. Um Gruppen inGRAN
T-Anweisungen zu verwenden, erstellen Sie Ihre Gruppen auf Kontoebene und aktualisieren Sie alle Automatisierungen für die Prinzipal- oder Gruppenverwaltung (z. B. SCIM, Okta- und Microsoft Entra ID-Konnektoren und Terraform), um auf Kontoendpunkte anstelle von Arbeitsbereichsendpunkten zu verweisen. Siehe Gruppenquellen. - Workloads in R unterstützen die Verwendung von dynamischen Ansichten für die Sicherheit auf Zeilen- oder Spaltenebene auf Compute mit Databricks Runtime 15.3 und darunter nicht.
Verwenden Sie eine dedizierte Computeressource mit Databricks Runtime 15.4 LTS oder höher für Workloads in R, die dynamische Ansichten abfragen. Für solche Workloads ist auch ein Arbeitsbereich erforderlich, der für serverloses Computing aktiviert ist. Ausführliche Informationen finden Sie unter feingranulare Zugriffssteuerung für dedizierte Rechenressourcen.
Flache Klone werden in Unity Catalog für Recheneinheiten, die Databricks Runtime 12.2 LTS und niedrigere Versionen ausführen, nicht unterstützt. Ab Databricks Runtime 13.3 LTS können flache Klone für die Erstellung verwalteter Tabellen verwendet werden. Sie können sie nicht zum Erstellen externer Tabellen verwenden, unabhängig von der Databricks Runtime-Version. Weitere Informationen finden Sie unter Flacher Klon für Unity Catalog-Tabellen.
Bucketing wird für Unity Catalog-Tabellen nicht unterstützt. Wenn Sie Befehle ausführen, die versuchen, eine Buckettabelle in Unity Catalog zu erstellen, wird eine Ausnahme ausgelöst.
Das Schreiben in denselben Pfad oder dieselbe Delta Lake-Tabelle von Arbeitsbereichen in mehreren Regionen kann zu einer unzuverlässigen Leistung führen, wenn einige Cluster auf Unity Catalog zugreifen und andere nicht.
Das Bearbeiten von Partitionen für externe Tabellen mithilfe von Befehlen wie
ALTER TABLE ADD PARTITION
erfordert, dass die Partitions-Metadatenprotokollierung aktiviert ist. Siehe Partitionsermittlung für externe Tabellen.Wenn Sie den Überschreibmodus für Tabellen verwenden, die sich nicht im Delta-Format befinden, muss der Benutzer über die CREATE TABLE-Berechtigung für das übergeordnete Schema verfügen und entweder der Besitzer des vorhandenen Objekts sein oder die MODIFY-Berechtigung für das Objekt haben.
In Databricks Runtime 12.2 LTS und niedrigeren Versionen werden keine Python-UDFs unterstützt. Dies schließt UDAFs, UDTFs und Pandas in Spark (
applyInPandas
undmapInPandas
) ein. Skalare Python-UDFs werden ab Databricks Runtime 13.3 LTS unterstützt.Scala UDFs werden in Databricks Runtime 14.1 und darunter auf Berechnungen mit dem Standardzugriffsmodus nicht unterstützt. Skalare UDFs werden in Databricks Runtime 14.2 und höher bei der Berechnung mit Standardzugriffsmodus unterstützt.
Standardmäßige Scala-Threadpools werden nicht unterstützt. Verwenden Sie stattdessen die speziellen Threadpools in
org.apache.spark.util.ThreadUtils
, z. Borg.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool
. Die folgenden Threadpools inThreadUtils
werden jedoch nicht unterstützt:ThreadUtils.newForkJoinPool
und alleScheduledExecutorService
-Threadpools.
- Die Überwachungsprotokollierung wird nur für Unity Catalog-Ereignisse auf Arbeitsbereichsebene unterstützt. Ereignisse, die auf Kontoebene ohne Verweis auf einen Arbeitsbereich stattfinden, z. B. das Erstellen eines Metastores, werden nicht protokolliert.
Für in Unity Catalog registrierte Modelle gelten zusätzliche Einschränkungen. Informationen finden Sie unter Einschränkungen.
Ressourcenkontingente
Unity Catalog erzwingt Ressourcenkontingente für alle sicherungsfähigen Objekte. Diese Kontingente werden in den Ressourcengrenzwerten aufgeführt. Wenn Sie davon ausgehen, dass Sie diese Ressourcengrenzwerte überschreiten, wenden Sie sich an Ihr Azure Databricks-Kontoteam.
Sie können Ihren Kontingentbedarf mithilfe der Unity Catalog-Ressourcenkontingent-APIs überwachen. Weitere Informationen finden Sie unter Überwachen des Bedarfs an Unity Catalog-Ressourcenkontingenten.