次の方法で共有

Unity Catalog とは

この記事では、Azure Databricks 上のデータと AI 資産の統合ガバナンス ソリューションである Unity Catalog について説明します。 主要な概念について説明し、Unity カタログを使用してデータを管理する方法の概要を示します。

注

Unity Catalog は、オープンソースの実装としても使用できます。 お知らせブログとパブリック Unity カタログ GitHub リポジトリを参照してください。

Unity Catalog の概要

Unity Catalog は、Azure Databricks ワークスペース全体のアクセス制御、監査、系列、品質監視、およびデータ検出機能を提供する一元化されたデータ カタログです。

Unity Catalog の主な特徴は次のとおりです。

  • すべての場所で 1 回定義し、セキュリティで保護する: Unity カタログは、リージョン内のすべてのワークスペースに適用されるデータ アクセス ポリシーを管理する 1 つの場所を提供します。
  • 標準準拠のセキュリティ モデル: Unity カタログのセキュリティ モデルは標準の ANSI SQL に基づいており、管理者は使い慣れた構文を使用して既存のデータ レイクにアクセス許可を付与できます。
  • 組み込みの監査と系列: Unity Catalog では、データへのアクセスを記録するユーザーレベルの監査ログが自動的に取得されます。 さらに Unity Catalog では、すべての言語でデータ資産がどのように作成され、どのように使用されているかを追跡する系列データもキャプチャされます。
  • データ検出: Unity カタログを使用すると、データ資産のタグ付けとドキュメント化が可能になり、データ コンシューマーがデータを見つけるのに役立つ検索インターフェイスが提供されます。
  • システム テーブル: Unity カタログを使用すると、監査ログ、課金対象の使用状況、系列など、アカウントの運用データに簡単にアクセスしてクエリを実行できます。

メタストア

メタストアは、Unity Catalog 内のメタデータの最上位レベルのコンテナーです。 データと AI 資産に関するメタデータとそれらへのアクセス権を制御するアクセス許可を登録します。 ワークスペースで Unity Catalog を使用するには、Unity Catalog メタストアがアタッチされている必要があります。 ワークスペースがあるリージョンごとに 1 つのメタストアが必要です。

Hive メタストアとは異なり、Unity カタログ メタストアはサービスの境界ではありません。マルチテナント環境で実行され、特定の Azure Databricks アカウントのリージョン別にデータを分離するための論理境界を表します。

Unity カタログ オブジェクト モデル

Unity Catalog メタストアの、3 レベルのデータベース オブジェクト階層はスキーマを含むカタログで構成されます。このスキーマには、テーブルやモデルなどのデータと AI オブジェクトが含まれます。 この階層は、テーブル、ビュー、ボリューム、モデル、関数を参照するときに、3 レベルの名前空間 (catalog.schema.table-etc) として表されます。

Unity Catalaog オブジェクト モデルの図

レベル 1:

レベル 2:

  • スキーマ (データベースとも呼ばれます) には、テーブル、ビュー、ボリューム、AI モデル、関数が含まれます。 スキーマは、データと AI 資産を、カタログよりも詳細な論理カテゴリに整理します。 通常、スキーマは単一のユース ケース、プロジェクト、またはチーム サンドボックスを表します。 「Azure Databricks のスキーマとは」を参照してください。

レベル 3:

  • テーブル は、行と列で編成されたデータのコレクションです。 テーブルは、Unity カタログでテーブルの完全なライフサイクルを管理するか、Unity カタログで Azure Databricks 内からデータへのアクセスを管理する外部を使用して管理できますが、他のクライアントからのクラウド ストレージ内のデータへのアクセスは管理できません。 「Azure Databricks テーブルの概要」および「マネージド テーブルと外部テーブルとボリューム」を参照してください。
  • ビュー は、1 つ以上のテーブルに対して保存されたクエリです。 「 ビューとは」を参照してください。
  • ボリュームは、 クラウド オブジェクト ストレージ内のデータの論理ボリュームを表します。 ボリュームを使用すると、構造化データ、半構造化データ、非構造化データなど、任意の形式でファイルを格納、整理、アクセスできます。 通常、これらは表形式以外のデータに使用されます。 ボリュームは、Unity Catalog がストレージ内のデータのライフサイクルとレイアウトを完全に管理する方法（管理）と、Unity Catalog が Azure Databricks 内からのみデータへのアクセスを管理し、他のクライアントからのクラウドストレージ内のデータへのアクセスは管理しない方法（外部）のどちらかを選択できます。 「Unity カタログボリュームとは何か」と「マネージドテーブルと外部テーブルおよびボリュームの比較」を参照してください。
  • 関数 は、スカラー値または行のセットを返す保存済みロジックの単位です。 Unity カタログのユーザー定義関数 (UDF) を参照してください。
  • モデル は、MLflow でパッケージ化され、関数として Unity カタログに登録された AI モデルです。 Unity カタログでのモデルのライフサイクルの管理に関するページを参照してください。

Unity Catalog が外部データ ソースへのアクセスを管理するために使用するセキュリティ保護可能なオブジェクト

Unity Catalog では、スキーマに含まれるデータベース オブジェクトと AI 資産に加えて、次のセキュリティ保護可能なオブジェクトを使用して、クラウド ストレージやその他の外部データ ソースとサービスへのアクセスを管理します。

共有資産へのアクセスを管理するために Unity カタログが使用するセキュリティ保護可能なオブジェクト

Unity Catalog では、次のセキュリティ保護可能なオブジェクトを使用して、メタストアまたは組織の境界を越えてデータと AI 資産の共有を管理します。

  • Databricks で管理される環境を表すクリーン ルーム。基になるデータを相互に共有することなく、複数の参加者がプロジェクトで共同作業を行うことができます。 「Azure Databricks Clean Rooms とは」を参照してください。
  • シェアは、データプロバイダーが受信者と共有するデータとAI資産の読み取り専用コレクションを表すDelta Sharingオブジェクトです。
  • 受信者は、「データ プロバイダー」からシェアを受け取るエンティティを表すDelta Sharingオブジェクトです。
  • プロバイダー。これは、受信者とデータを共有するエンティティを表す差分共有オブジェクトです。

デルタ共有のセキュリティ保護可能なオブジェクトの詳細については、「 差分共有とは」を参照してください。

管理者ロール

次の Azure Databricks 管理者ロールには、既定で多くの Unity カタログ特権があります。

  • アカウント管理者: メタストアの作成、メタストアへのワークスペースのリンク、ユーザーの追加、メタストアに対する権限の割り当てを行うことができます。
  • ワークスペース管理者: ユーザーをワークスペースに追加し、ジョブやノートブックなどのワークスペース固有のオブジェクトを多数管理できます。 ワークスペースに応じて、ワークスペース管理者は、ワークスペースにアタッチされているメタストアに対する多くの特権を持つこともできます。
  • メタストア管理者: メタストア レベルでテーブルとボリュームのストレージを管理する場合は、この省略可能なロールが必要です。 また、リージョン内の複数のワークスペース間でデータを一元的に管理する場合にも便利です。

詳細については、「 Unity カタログの管理者特権」を参照してください。

セキュリティ保護可能なオブジェクトへのアクセスの許可と取り消し

特権ユーザーは、メタストア自体を含め、階層内の任意のレベルでセキュリティ保護可能なオブジェクトへのアクセスを許可および取り消すことができます。 オブジェクトへのアクセス権は、取り消されない限り、そのオブジェクトのすべての子に対して暗黙的に同じアクセス権を付与します。

一般的な ANSI SQL コマンドを使用して、Unity Catalog 内のオブジェクトへのアクセスを許可および取り消すことができます。 次に例を示します。

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

カタログ エクスプローラー、Databricks CLI、REST API を使用して、オブジェクトのアクセス許可を管理することもできます。

カタログ エクスプローラーを使用して特権を付与する

メタストア管理者、オブジェクトの所有者、およびオブジェクトの MANAGE privilege を持つユーザーは、アクセス権を付与および取り消すことができます。 Unity カタログで権限を管理する方法については、Unity カタログ での権限の管理に関するページを参照してください。

Unity Catalog 内のデータベース オブジェクトへの既定のアクセス

Unity Catalog は、最小限の特権という原則に基づいて動作します。ユーザーは、必要なタスクを実行するために必要な最小限のアクセス権を持ちます。 ワークスペースが作成されると、管理者以外のユーザーは自動的にプロビジョニングされた ワークスペース カタログにのみアクセスできます。これにより、このカタログは、ユーザーが Unity カタログでデータベース オブジェクトを作成してアクセスするプロセスを試すのに便利な場所になります。 ワークスペース カタログ権限を参照してください。

Unity Catalog でのデータベース オブジェクトの操作

Unity カタログでのデータベース オブジェクトの操作は、Hive メタストアに登録されているデータベース オブジェクトを操作するのとよく似ていますが、例外として、Hive メタストアにはオブジェクト名前空間にカタログが含まれていません。 使い慣れた ANSI 構文を使用して、データベース オブジェクトの作成、データベース オブジェクトの管理、アクセス許可の管理、Unity Catalog のデータの操作を行うことができます。 カタログ エクスプローラー UI を使用して、データベース オブジェクトの作成、データベース オブジェクトの管理、データベース オブジェクトに対するアクセス許可の管理を行うこともできます。

詳細については、「 Azure Databricks のデータベース オブジェクト」を参照してください。

マネージドまたは外部のテーブルとボリューム

テーブルとボリュームは、マネージドまたは外部にできます。

  • マネージド テーブル は Unity カタログによって完全に管理されます。つまり、Unity カタログは、各マネージド テーブルのガバナンスと基になるデータ ファイルの両方を管理します。 マネージド テーブルは、クラウド ストレージ内の Unity Catalog 管理の場所に格納されます。 マネージド テーブルでは、常に Delta Lake 形式を使用します。 マネージド テーブルは、メタストア、カタログ、またはスキーマのレベルで格納できます。
  • 外部テーブル とは、Azure Databricks からのアクセスが Unity カタログによって管理されているが、データ ライフサイクルとファイル レイアウトがクラウド プロバイダーやその他のデータ プラットフォームを使用して管理されるテーブルです。 通常、Azure Databricks の大量の既存のデータを登録するか、Azure Databricks の外部のツールを使用してデータへの書き込みアクセスを要求する場合に、外部テーブルを使用します。 外部テーブルは複数のデータ形式でサポートされています。 Unity カタログ メタストアに外部テーブルが登録されたら、それに対する Azure Databricks のアクセスを管理および監査し---マネージド テーブルと同じように---操作できます。
  • マネージド ボリューム は Unity カタログによって完全に管理されます。つまり、Unity カタログは、クラウド プロバイダー アカウント内のボリュームのストレージの場所へのアクセスを管理します。 マネージド ボリュームを作成すると、そのボリュームは、包含スキーマに割り当てられた マネージド ストレージの場所 に自動的に格納されます。
  • 外部ボリュームは 、Azure Databricks の外部で管理されているが、Azure Databricks 内からのアクセスを制御および監査するために Unity カタログに登録されているストレージの場所にある既存のデータを表します。 Azure Databricks で外部ボリュームを作成するときは、その場所を指定します。この場所は、Unity カタログの 外部の場所で定義されているパス上にある必要があります。

Databricks では、ほとんどのユース ケースでマネージド テーブルとボリュームをお勧めします。これは、Unity カタログのガバナンス機能とパフォーマンスの最適化を最大限に活用できるためです。 外部テーブルとボリュームの一般的なユース ケースについては、「 マネージド テーブルと外部テーブル 」および 「マネージド ボリュームと外部ボリューム」を参照してください。

関連項目も参照:

クラウド ストレージとデータの分離

Unity カタログでは、次の 2 つの主な方法でクラウド ストレージが使用されます。

  • マネージド ストレージ: Azure Databricks で作成するマネージド テーブルとマネージド ボリューム (非構造化、表形式以外のデータ) の既定の場所。 これらのマネージド ストレージの場所は、メタストア、カタログ、またはスキーマ レベルで定義できます。 クラウド プロバイダーでマネージド ストレージの場所を作成しますが、そのライフサイクルは Unity カタログによって完全に管理されます。
  • 外部テーブルとボリュームが格納されているストレージの場所。 これらは、Azure Databricks からのアクセスが Unity カタログによって管理されているが、データ ライフサイクルとファイル レイアウトがクラウド プロバイダーやその他のデータ プラットフォームを使用して管理されているテーブルとボリュームです。 通常は、外部テーブルまたはボリュームを使用して、Azure Databricks に大量の既存のデータを登録するか、Azure Databricks の外部にあるツールを使用してデータへの書き込みアクセスも必要な場合に使用します。

外部の場所を使用したクラウド ストレージへのアクセスの管理

外部テーブルとボリュームが格納されているマネージド ストレージの場所とストレージの場所の両方で、 外部の場所 のセキュリティ保護可能なオブジェクトを使用して、Azure Databricks からのアクセスを管理します。 外部の場所オブジェクトは、クラウド ストレージ パスと、それにアクセスするために必要な ストレージ資格情報 を参照します。 ストレージ資格情報自体は、特定のストレージ パスにアクセスするために必要な資格情報を登録する Unity カタログセキュリティ保護可能なオブジェクトです。 これらのセキュリティ保護可能なリソースを組み合わせることで、ストレージへのアクセスが Unity カタログによって制御および追跡されます。

次の図は、1 つのクラウド ストレージ コンテナーのファイルシステム階層を表しており、1 つのストレージ資格情報を共有する 4 つの外部の場所があります。

外部の場所

詳細については、「 Unity カタログでクラウド ストレージへのアクセスを制御する方法」を参照してください。

マネージド ストレージの場所の階層

Unity カタログでマネージド ストレージを定義するレベルは、推奨されるデータ分離モデルによって異なります。 組織では、クラウド テナント内の特定のアカウントまたはバケット内に特定の種類のデータを格納することが要求される場合があります。

Unity カタログを使用すると、このような要件を満たすために、メタストア、カタログ、またはスキーマ レベルでマネージド ストレージの場所を構成できます。

たとえば、組織に、コンテナー abfss://mycompany-hr-prod@storage-account.dfs.core.windows.netに存在する人事に関連する運用データを必要とする会社のコンプライアンス ポリシーがあるとします。 Unity カタログでは、カタログ レベルで場所を設定し、 hr_prodなどのカタログを作成し、場所 abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog を割り当てることで、この要件を満たすことができます。 つまり、 hr_prod カタログに作成されたマネージド テーブルまたはボリューム (たとえば、 CREATE TABLE hr_prod.default.table …を使用) は、そのデータを abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog に格納します。 オプションで、hr_prod catalog 内のデータをより細かいレベルで整理するためにスキーマ レベルの場所を指定することもできます。

一部のカタログでストレージの分離が必要ない場合は、必要に応じて、メタストア レベルでストレージの場所を設定できます。 この場所は、ストレージが割り当てられないカタログとスキーマ内のマネージド テーブルとボリュームの既定の場所として機能します。 ただし、通常、Databricks では、カタログごとに個別のマネージド ストレージの場所を割り当てることを推奨しています。

システムは、スキーマからカタログ、メタストアまでの格納場所の階層を評価します。

たとえば、テーブル myCatalog.mySchema.myTable が my-region-metastoreに作成された場合、テーブルの保存場所は次の規則に従って決定されます。

  1. mySchema に場所が指定されている場合は、その場所に格納されます。
  2. そうでない場合は、myCatalog に場所が指定されていると、その場所に保存されます。
  3. 最後に、myCatalog で場所が指定されていない場合は、my-region-metastore に関連付けられた場所に格納されます。

Unity カタログストレージ階層

詳細については、「 Unity カタログでマネージド ストレージの場所を指定する」を参照してください。

ワークスペース カタログ バインドを使用した環境の分離

既定では、カタログ所有者 (およびアカウントに対して定義されている場合はメタストア管理者) は、同じ Unity Catalog メタストアに接続されている複数のワークスペースのユーザーにカタログへのアクセスを許可できます。

多くの場合、組織の要件およびコンプライアンス要件では、個人データなどの特定のデータを特定の環境内でのみアクセス可能にすることが指定されています。 また、運用データが開発データから分離された状態を維持するか、特定のデータ セットとドメインが結合されないようにする必要もあります。

Azure Databricks では、ワークスペースはプライマリ データ処理環境であり、カタログはプライマリ データ ドメインです。 Unity カタログを使用すると、メタストア管理者、カタログ所有者、および MANAGE アクセス許可を持つユーザーが、特定のワークスペースにカタログを割り当てる ("バインド" できます)。 これらの環境対応バインディングを使用すると、ユーザーに付与されたデータ オブジェクトに対する特定の特権に関係なく、ワークスペース内で特定のカタログのみを使用できるようにします。 ただし、ワークスペースを使用してユーザー データ アクセスを分離する場合は、特定の種類のデータがそれらのワークスペースでのみ処理されるように、アカウント内の特定のワークスペースへのカタログ アクセスを制限することができます。 たとえば、運用ワークスペースと開発ワークスペースを別々にする場合や、個人データを処理するための別個のワークスペースが必要な場合があります。 これは、ワークスペースとカタログのバインドと呼ばれます。 特定のワークスペースへのカタログ アクセスの制限を参照してください。

Unity Catalog

注

データの分離を強化するために、クラウド ストレージ アクセスとクラウド サービスアクセスを特定のワークスペースにバインドすることもできます。 (省略可能) 特定のワークスペースへのストレージ資格情報の割り当て、(省略可能) 特定のワークスペースへの外部の場所の割り当て、(省略可能) 特定のワークスペースへのサービス資格情報の割り当てに関するページを参照してください。

組織操作方法 Unity カタログを設定しますか?

Unity Catalog を使用するには、Unity Catalog に対して Azure Databricks ワークスペースを有効にする必要があります。これは、ワークスペースが Unity Catalog メタストアにアタッチされていることを意味します。

ワークスペースはどのようにメタストアにアタッチされますか? アカウントとワークスペースによって異なります。

  • 通常、リージョンに Azure Databricks ワークスペースを初めて作成すると、メタストアが自動的に作成され、ワークスペースにアタッチされます。
  • 一部の古いアカウントでは、アカウント管理者がメタストアを作成し、そのリージョンのワークスペースをメタストアに割り当てる必要があります。 手順については、「 Unity カタログメタストアの作成」を参照してください。
  • アカウントにリージョンにメタストアが既に割り当てられている場合、アカウント管理者は、そのリージョン内のすべての新しいワークスペースにメタストアを自動的にアタッチするかどうかを決定できます。 「 メタストアを新しいワークスペースに自動的に割り当てできるようにする」を参照してください。

ワークスペースが Unity Catalog に対して自動的に有効になっているかどうかにかかわらず、Unity Catalog の使用を開始するには、次の手順も必要です。

  • テーブルやボリュームなどのデータベース オブジェクトを含むカタログとスキーマを作成します。
  • これらのカタログとスキーマにマネージド テーブルとマネージド ボリュームを格納するマネージド ストレージの場所を作成します。
  • カタログ、スキーマ、およびデータベース オブジェクトへのアクセス権をユーザーに付与します。

Unity カタログに対して自動的に有効になっているワークスペースは、すべてのワークスペース ユーザーに付与される広範な特権を持つワークスペース カタログ をプロビジョニングします。 このカタログは、Unity Catalog を試す際の出発点として便利です。

詳細なセットアップ手順については、「 Unity カタログの概要」を参照してください。

既存のワークスペースを Unity カタログにアップグレードする

Unity カタログ以外のワークスペースを Unity カタログにアップグレードする方法については、「 Azure Databricks ワークスペースを Unity カタログにアップグレードする」を参照してください。

Unity Catalog の要件と制限事項

Unity Catalog には、以下で説明する特定の種類のコンピューティング形式とファイル形式が必要です。 また、すべての Databricks Runtime バージョンの Unity Catalog で完全にはサポートされていないいくつかの Azure Databricks 機能を次に示します。

リージョンのサポート

すべてのリージョンで Unity Catalog がサポートされます。 詳細については、 Azure Databricks リージョンに関するページを参照してください。

コンピューティングの要件

Unity Catalog は、Databricks Runtime 11.3 LTS 以降を実行するクラスターでサポートされています。 Unity カタログは、すべての SQL Warehouse コンピューティング バージョンで既定でサポートされています。

以前のバージョンの Databricks Runtime で実行されているクラスターでは、Unity Catalog GA のすべての機能がサポートされるわけではありません。

Unity カタログ内のデータにアクセスするには、クラスターを正しい アクセス モードで構成する必要があります。 既定で Unity Catalog はセキュリティで保護されています。 クラスターが標準または専用のアクセス モードで構成されていない場合、クラスターは Unity カタログ内のデータにアクセスできません。 アクセス モードを参照してください。

各 Databricks Runtime バージョンでの Unity カタログ機能の変更の詳細については、 リリース ノートを参照してください。

Unity Catalog の制限はアクセス モードと Databricks Runtime バージョンによって変わります。 Unity カタログのコンピューティング アクセス モードの制限事項を参照してください。

ファイル形式のサポート

Unity カタログでは、次のテーブル形式がサポートされます：

制限事項

Unity Catalog には次の制限事項があります。 これらの一部は、以前の Databricks Runtime バージョンとコンピューティング アクセス モードに固有です。

構造化ストリーミング ワークロードには、Databricks Runtime とアクセス モードによって追加の制限があります。 Unity カタログのコンピューティング アクセス モードの制限事項を参照してください。

Databricks は、新機能をリリースしており、このリストは定期的に縮小されます。

  • ワークスペースで以前に作成されたグループ (つまり、ワークスペースレベルのグループ) は、Unity Catalog GRANT ステートメントで使用できません。 これは、複数のワークスペースにまたがる可能性のあるグループのビューについて一貫性を確保するためです。 GRANT ステートメントでグループを使用するには、アカウント レベルでグループを作成し、ワークスペース エンドポイントではなくアカウント エンドポイントを参照するように、プリンシパルまたはグループ管理 (SCIM、Okta、Microsoft Entra ID コネクタ、Terraform など) の自動化を更新してください。 グループ ソースを参照してください。
  • R のワークロードでは、Databricks Runtime 15.3 以下を実行しているコンピューティングでの行レベルまたは列レベルのセキュリティに対する動的ビューの使用はサポートされていません。

動的ビューを照会する R のワークロードには、Databricks Runtime 15.4 LTS 以降を実行する専用のコンピューティング リソースを使用します。 このようなワークロードには、サーバーレス コンピューティングに対して有効になっているワークスペースも必要です。 詳細については、 専用コンピューティングでのきめ細かなアクセス制御に関するページを参照してください。

  • シャロー クローンは、Databricks Runtime 12.2 LTS 以下を実行するコンピューティング上の Unity Catalog ではサポートされていません。 シャロー クローンを使用したマネージド テーブルの作成は、Databricks Runtime 13.3 LTS 以降で行えます。 Databricks Runtime のバージョンに関係なく、これらを使用して外部テーブルを作成することはできません。 Unity カタログ テーブルの簡易クローンを参照してください。

  • Unity Catalog テーブルではバケットはサポートされていません。 Unity Catalog でバケット化テーブルを作成しようとするコマンドを実行すると、例外がスローされます。

  • 複数のリージョンにあるワークスペースから同じパスまたは Delta Lake テーブルに書き込むと、一部のクラスターが Unity Catalog にアクセスし、他のクラスターがそれにアクセスしない場合、パフォーマンスの信頼性が低下することがあります。

  • ALTER TABLE ADD PARTITIONなどのコマンドを使用して外部テーブルのパーティションを操作するには、パーティション メタデータ ログを有効にする必要があります。 外部テーブルのパーティション検出を参照してください。

  • 差分形式でないテーブルに上書きモードを使用する場合、ユーザーは親スキーマに対する CREATE TABLE 権限を持ち、既存のオブジェクトの所有者であるか、オブジェクトに対する MODIFY 権限を持っている必要があります。

  • Python UDF は、Databricks Runtime 12.2 LTS 以下ではサポートされていません。 これには、Spark (applyInPandas と mapInPandas) 上の UDAF、UDTF、Pandas が含まれます。 Databricks Runtime 13.3 LTS 以降では、Python スカラー UDF がサポートされています。

  • 標準アクセス モードのコンピューティングでは、Databricks Runtime 14.1 以下では Scala UDF はサポートされていません。 Scala スカラー UDF は、Databricks Runtime 14.2 以降の標準アクセス モードのコンピューティングでサポートされています。

  • 標準 Scala スレッド プールはサポートされていません。 代わりに、org.apache.spark.util.ThreadUtils で特殊なスレッド プールを使用します (例: org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool)。 ただし、ThreadUtils 内の ThreadUtils.newForkJoinPool スレッド プールとすべての ScheduledExecutorService スレッド プールはサポートされていません。

  • 監査ログは、ワークスペース レベルの Unity Catalog イベントに対してのみサポートされています。 メタストアの作成など、ワークスペースに関係なくアカウント レベルで発生するイベントはログに記録されません。

Unity Catalog に登録されているモデルには、追加の制限があります。 制限事項を参照してください。

リソース クォータ

Unity Catalog では、セキュリティ保護可能なすべてのオブジェクトにリソース クォータが適用されます。 これらのクォータは、[ リソースの制限] に一覧表示されます。 これらのリソース制限を超えることが予想される場合は、Azure Databricks アカウント チームにお問い合わせください。

Unity Catalog リソース クォータ API を使用して、クォータの使用状況を監視できます。 Unity カタログ リソース クォータの使用状況の監視を参照してください。

その他のリソース