Freigeben über

Was ist Unity Catalog?

  • Artikel

In diesem Artikel wird Unity Catalog vorgestellt, eine einheitliche Governancelösung für Daten und KI-Ressourcen in Azure Databricks.

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 bietet zentralisierte Zugriffssteuerungs-, Überwachungs-, Herkunfts- und Datenermittlungsfunktionen in Azure Databricks-Arbeitsbereichen.

Unity Catalog-Abbildung

Wichtige Features von Unity Catalog:

  • Einmaliges Definieren, allgegenwärtiger Schutz: Unity Catalog bietet eine einzige Anlaufstelle zum Verwalten von Datenzugriffsrichtlinien, die für alle Arbeitsbereiche gelten.
  • Standardkonformes Sicherheitsmodell: Das Sicherheitsmodell von Unity Catalog basiert auf der Standardversion von ANSI-SQL und ermöglicht es Administratoren, eine vertraute Syntax zu verwenden, um in ihrem bestehenden Data Lake Berechtigungen auf der Ebene von Katalogen, Schemas (auch Datenbanken genannt), Tabellen und Sichten zu gewähren.
  • 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 (Public Preview): Mit Unity Catalog können Sie ganz einfach auf die Betriebsdaten Ihres Kontos zugreifen und diese abfragen, einschließlich Überwachungsprotokolle, abrechenbarer Verbrauch und Herkunft.

Objektmodell von Unity Catalog

In Unity Catalog werden alle Metadaten in einem Metastore registriert. Die Hierarchie von Datenbankobjekten in einem Unity Catalog-Metastore ist in drei Ebenen unterteilt – dargestellt als dreistufiger Namespace (catalog.schema.table-etc), wenn Sie auf Tabellen, Sichten, Volumes, Modelle und Funktionen verweisen.

Objektmodell-Diagramm von Unity Catalog

Metastores

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. In der Regel wird ein Metastore automatisch erstellt, wenn Sie erstmals einen Azure Databricks-Arbeitsbereich in einer Region erstellen. Bei einigen älteren Konten muss ein Kontoadministrator den Metastore erstellen und die Arbeitsbereiche in dieser Region dem Metastore zuweisen.

Weitere Informationen finden Sie unter Erstellen eines Unity Catalog-Metastores.

Objekthierarchie im Metastore

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.

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?.
  • Sicherungsfähige Objekte, bei denen es sich nicht um Daten handelt (z. B. Speicheranmeldeinformationen und externe Speicherorte), werden verwendet, um Ihr Datengovernancemodell in Unity Catalog zu verwalten. Diese befinden sich ebenfalls direkt unter dem Metastore. Ausführlichere Informationen finden Sie unter Andere sicherungsfähige Objekte.

Ebene 2:

  • Schemas (auch Datenbanken genannt) enthalten Tabellen, Sichten, Volumes, 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:

Verwenden von Datenbankobjekten in Unity Catalog

Die Verwendung von Datenbankobjekten in Unity Catalog ähnelt stark der Verwendung von Datenbankobjekten, die in einem Hive-Metastore registriert sind, allerdings mit dem Unterschied, 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 Datenbankobjekten in Azure Databricks sowie unter Arbeiten mit Unity Catalog und dem Legacy-Hive-Metastore.

Andere sicherungsfähige Objekte

Neben den Datenbankobjekten und KI-Ressourcen, die in Schemas enthalten sind, steuert Unity Catalog auch den Zugriff auf Daten unter Verwendung folgender sicherungsfähiger Objekte:

Weitere Informationen zu sicherungsfähigen Delta Sharing-Objekten finden Sie unter Sicheres Freigeben von Daten und KI-Ressourcen mithilfe von Delta Sharing.

Gewähren und Widerrufen von Zugriff auf Datenbankobjekte und andere sicherungsfähige Objekte in Unity Catalog

Sie können Zugriff auf sicherungsfähige Objekte auf einer beliebigen Ebene in der Hierarchie gewähren und widerrufen. Das gilt auch für den Metastore 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.

Gewähren von Berechtigungen mithilfe des Katalog-Explorers

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.

Administratorrollen

Arbeitsbereichsadministratoren und Kontoadministratoren verfügen standardmäßig über zusätzliche Berechtigungen. Metastore-Administrator ist eine optionale Rolle. Sie wird benötigt, wenn Sie Tabellen- und Volumespeicher auf Metastore-Ebene verwalten möchten, und ist praktisch, wenn Sie Daten in einer Region zentral über mehrere Arbeitsbereiche hinweg verwalten möchten. Weitere Informationen finden Sie unter Administratorrechte in Unity Catalog sowie unter (Optional) Zuweisen der Metastore-Administratorrolle.

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. Nachdem eine externe Tabelle in einem Unity Catalog-Metastore registriert wurde, können Sie den Azure Databricks-Zugriff darauf genauso verwalten und überwachen wie bei verwalteten Tabellen und auch auf die gleiche Weise damit arbeiten.
  • Verwaltete Volumes werden vollständig von Unity Catalog verwaltet. Das 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 zu verwenden, um in vollem Umfang von den Governancefunktionen und Leistungsoptimierungen von Unity Catalog zu profitieren.

Weitere Informationen finden Sie unter Verwenden verwalteter Tabellen, unter Verwenden externer Tabellen und unter Gegenüberstellung von verwalteten und externen Volumes.

Datenisolation mit verwaltetem Speicher

In Organisationen kann es erforderlich sein, bestimmte Arten von Daten in bestimmten Konten oder Buckets des eigenen Cloudmandanten zu speichern.

Unity Catalog bietet die Möglichkeit, Speicherorte auf Metastore-, Katalog- oder Schemaebene zu konfigurieren, um diese Anforderungen zu erfüllen. Das System wertet die Hierarchie der Speicherorte von Schema zu Katalog zu Metastore aus.

Angenommen, Ihre Organisation verfügt über eine Unternehmenscompliancerichtlinie, die erfordert, dass Produktionsdaten im Zusammenhang mit Personalressourcen sich im Container abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net befinden. 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 Metaspeicherebene festlegen. Dieser Speicherort fungiert als Standardspeicherort für verwaltete Tabellen und Volumes in Katalogen und Schemas, denen kein Speicher zugewiesen ist. In der Regel empfiehlt es sich allerdings, separate verwaltete Speicherorte für jeden Katalog zuzuweisen.

Weitere Informationen finden Sie unter Angeben eines verwalteten Speicherorts in Unity Catalog sowie unter Daten werden im Speicher physisch getrennt.

Arbeitsbereichskatalogbindung

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. 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 stärkere Datenisolation können Sie den Cloudspeicherzugriff auch an bestimmte Arbeitsbereiche binden. Weitere Informationen finden Sie unter (Optional) Zuweisen von Speicheranmeldeinformationen zu bestimmten Arbeitsbereichen und (Optional) Zuweisen eines externen Speicherorts zu bestimmten Arbeitsbereichen.

Überwachen des Datenzugriffs

Unity Catalog erstellt ein Überwachungsprotokoll für Aktionen, die für den Metastore ausgeführt werden. Dadurch können Administratoren genau nachvollziehen, wer auf ein bestimmtes Dataset zugegriffen hat und welche Aktionen ausgeführt wurden.

Sie können mithilfe von Systemtabellen, die von Unity Catalog verwaltet werden, auf die Überwachungsprotokolle Ihres Kontos zugreifen.

Weitere Informationen finden Sie unter Überwachen von Unity Catalog-Ereignissen, unter Unity Catalog-Ereignisse und unter Überwachen des Verbrauchs mit Systemtabellen.

Nachverfolgen der Datenherkunft

Sie können Unity Catalog verwenden, um die Datenherkunft von Runtime-Daten in jeder Sprache über Abfragen hinweg zu erfassen, die auf einem Azure Databricks-Cluster oder einem SQL-Warehouse ausgeführt werden. Die Linie wird bis zur Spaltenebene erfasst und enthält Notebooks, Workflows und Dashboards im Zusammenhang mit der Abfrage. Weitere Informationen finden Sie unter Erfassen und Anzeigen der Datenherkunft mit Unity Catalog.

Lakehouse Federation und Unity Catalog

Lakehouse Federation ist die Abfrageverbundplattform für Azure Databricks. Der Begriff Abfrageverbund beschreibt eine Sammlung von Features, mit denen Benutzer und Systeme Abfragen für mehrere isolierte Datenquellen ausführen können, ohne alle Daten zu einem einheitlichen System migrieren zu müssen.

Azure Databricks verwendet zum Verwalten des Abfrageverbunds Unity Catalog. Sie verwenden Unity Catalog, um schreibgeschützte Verbindungen mit gängigen externen Datenbanksystemen zu konfigurieren und Fremdkataloge zu erstellen, die externe Datenbanken spiegeln. Die Tools für Datengovernance und Datenherkunft von Unity Catalog stellen sicher, dass der Datenzugriff für alle Verbundabfragen verwaltet und überwacht wird, die von den Benutzern in Ihren Azure Databricks-Arbeitsbereichen durchgeführt werden.

Weitere Informationen finden Sie unter Was ist der Lakehouse-Verbund?.

Delta Sharing, Databricks Marketplace und Unity Catalog

Delta Sharing ist eine sichere Datenfreigabeplattform, mit der Sie Daten und KI-Ressourcen für Benutzer außerhalb Ihrer Organisation freigeben können – unabhängig davon, ob diese Benutzer Databricks verwenden. Delta Sharing ist zwar als Open-Source-Implementierung verfügbar, in Databricks wird jedoch Unity Catalog benötigt, um uneingeschränkt von erweiterten Funktionen profitieren zu können. Weitere Informationen unter Sicheres Freigeben von Daten und KI-Ressourcen mithilfe von Delta Sharing.

Databricks Marketplace ist ein offenes Forum für den Austausch von Datenprodukten und basiert auf Delta Sharing. Daher müssen Sie über einen Unity Catalog-fähigen Arbeitsbereich verfügen, um als Marketplace-Anbieter fungieren zu können. Weitere Informationen finden Sie unter Was ist Databricks-Marketplace?.

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. Alle neuen Arbeitsbereiche werden bei der Erstellung automatisch für Unity Catalog aktiviert. Bei älteren Arbeitsbereichen muss Unity Catalog allerdings unter Umständen manuell von einem Kontoadministrator aktiviert werden. 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.

Eine ausführliche Einrichtungsanleitung finden Sie unter Einrichten und Verwalten von Unity Catalog.

Migrieren eines bereits vorhandenen Arbeitsbereichs zu Unity Catalog

Wenn Sie über einen älteren Arbeitsbereich verfügen, den Sie kürzlich für Unity Catalog aktiviert haben, verfügen Sie wahrscheinlich über Daten, die vom Legacy-Hive-Metastore verwaltet werden. Sie können diese Daten zusammen mit Daten verwenden, die in Unity Catalog registriert sind. Der Legacy-Hive-Metastore wird jedoch eingestellt, und es empfiehlt sich, die Daten aus Ihrem Hive-Metastore zeitnah zu Unity Catalog migrieren, um von den Vorteilen der überlegenen Governancefunktionen und der Leistung von Unity Catalog profitieren zu können.

Die Migration umfasst Folgendes:

  1. Konvertieren arbeitsbereichslokaler Gruppen in Gruppen auf Kontoebene. Unity Catalog zentralisiert die Identitätsverwaltung auf Kontoebene.
  2. Migrieren der im Hive-Metastore verwalteten Tabellen und Sichten zu Unity Catalog
  3. Aktualisieren von Abfragen und Workflows, sodass sie nicht mehr auf die alten Hive-Metastore-Tabellen verweisen, sondern auf Unity Catalog-Tabellen

Folgenden kann bei einer Migration hilfreich sein:

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 allgemein verfügbaren 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 Modus für gemeinsamen Zugriff oder mit dem Einzelbenutzerzugriffsmodus konfiguriert ist, kann der Cluster nicht auf Daten in Unity Catalog 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 Azure Databricks Runtime-Version. Siehe Einschränkungen des Computezugriffsmodus für Unity Catalog.

Unterstützung von Dateiformaten

Unity Catalog unterstützt die folgenden Tabellenformate:

Einschränkungen

Für Unity Catalog gelten die folgenden Einschränkungen: Einige davon gelten speziell für ältere Databricks Runtime-Versionen und Computezugriffsmodi.

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. Wenn Sie Gruppen in GRAN-Anweisungen verwenden möchten, erstellen Sie Ihre Gruppen auf Kontoebene, und aktualisieren Sie alle Automatisierungen für die Prinzipal- oder Gruppenverwaltung (z. B. Konnektoren für SCIM, Okta und Microsoft Entra ID (vormals Azure Active Directory) sowie Terraform), sodass sie auf Kontoendpunkte und nicht auf Arbeitsbereichsendpunkte verweisen. Weitere Informationen finden Sie unter Unterschied zwischen Kontogruppen und arbeitsbereichslokalen Gruppen.

  • Workloads in diesen Sprachen unterstützen die Verwendung dynamischer Sichten für die Sicherheit auf Zeilen- oder Spaltenebene nicht.

  • Flache Klone werden in Unity Catalog für Computeressourcen, 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 verwendet werden, unabhängig von der Databricks Runtime-Version. Siehe Flache Klone für verwaltete 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-Tabelle von Arbeitsbereichen in mehreren Regionen kann zu einer unzuverlässigen Leistung führen, wenn einige Cluster auf Unity Catalog zugreifen und andere nicht.

  • Benutzerdefinierte Partitionsschemas, die mit Befehlen wie „ALTER TABLE ADD PARTITION“ erstellt wurden, werden für Tabellen in Unity Catalog nicht unterstützt. Unity Catalog kann auf Tabellen zugreifen, die die Partitionierung im Verzeichnisstil verwenden.

  • Der Überschreibmodus für Dataframeschreibvorgänge in Unity Catalog wird nur für Delta-Tabellen unterstützt, nicht für andere Dateiformate. Der Benutzer muss das Recht CREATE für das übergeordnete Schema besitzen und Eigentümer des vorhandenen Objekts sein oder das Recht MODIFY für das Objekt besitzen.

  • 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 und mapInPandas) ein. Skalare Python-UDFs werden ab Databricks Runtime 13.3 LTS unterstützt.

  • In Databricks Runtime 14.1 und niedrigeren Versionen werden Scala-UDFs für freigegebene Cluster nicht unterstützt. Ab Databricks Runtime 14.2 werden skalare Scala-UDFs für freigegebene Cluster unterstützt.

  • Standardmäßige Scala-Threadpools werden nicht unterstützt. Verwenden Sie stattdessen die speziellen Threadpools in org.apache.spark.util.ThreadUtils, z. B org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool. Die folgenden Threadpools in ThreadUtils werden jedoch nicht unterstützt: ThreadUtils.newForkJoinPool und alle ScheduledExecutorService-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. Wenn Sie davon ausgehen, dass Sie diese Ressourcengrenzwerte überschreiten, wenden Sie sich an Ihr Azure Databricks-Kontoteam.

Die folgenden Kontingentwerte sind relativ zum übergeordneten Objekt (oder zum übergeordneten Element der zweiten Ebene) in Unity Catalog ausgedrückt:

Object Parent Wert
table schema 10000
table Metastore 1000000
Volume schema 10000
Funktion schema 10000
registriertes Modell schema 1.000
registriertes Modell Metastore 5000
Modellversion registriertes Modell 10000
Modellversion Metastore 100.000
schema catalog 10000
catalog Metastore 1000
Verbindung Metastore 1000
Speicheranmeldeinformationen Metastore 200
externer Speicherort Metastore 10000

Informationen zu Delta Sharing-Grenzwerten finden Sie unter Ressourcenkontingente.