Unity Catalog とは

この記事では、Azure Databricks 上のデータと AI 資産の統合ガバナンス ソリューションである Unity Catalog について説明します。

Unity Catalog の概要

Unity Catalog には、Azure Databricks ワークスペース全体の一元化されたアクセス制御、監査、系列、およびデータ検出機能が備えられています。

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

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

Unity Catalog のオブジェクト モデル

Unity Catalog では、すべてのメタデータがメタストアに登録されます。 Unity Catalog メタストア内のデータベース オブジェクトの階層は、テーブル、ビュー、ボリューム、モデル、および関数を参照するときに、3 レベルの名前空間 (catalog.schema.table-etc) として表される 3 つのレベルに分けられます。

メタストア

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

ワークスペースがあるリージョンごとに 1 つのメタストアが必要です。 通常、メタストアは、リージョンに Azure Databricks ワークスペースを初めて作成するときに自動的に作成されます。 一部の古いアカウントでは、アカウント管理者がメタストアを作成し、そのリージョンのワークスペースをメタストアに割り当てる必要があります。

「Unity Catalog メタストアを作成する」を参照してください。

メタストア内のオブジェクト階層

Unity Catalog メタストアの、3 レベルのデータベース オブジェクト階層はスキーマを含むカタログで構成されます。このスキーマには、テーブルやモデルなどのデータと AI オブジェクトが含まれます。

レベル 1:

• カタログはデータ資産を整理するために使用され、通常はデータ分離スキームの最上位レベルとして使用されます。 多くの場合、カタログは組織単位やソフトウェア開発のライフサイクル スコープを反映します。 Azure Databricks のカタログの説明を参照してください。
• ストレージ資格情報や外部の場所などのデータ セキュリティ保護が可能でないオブジェクトは、Unity Catalog でデータ ガバナンス モデルを管理するために使用されます。 これらはメタストアのすぐ下にもあります。 詳細については、「その他のセキュリティ保護可能なオブジェクト」で説明します。

レベル 2:

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

レベル 3:

• ボリュームは、クラウド オブジェクト ストレージ内にある構造化されておらず表形式ではないデータの論理ボリュームです。 ボリュームは、ストレージ内のデータの完全なライフサイクルとレイアウトを Unity Catalog で管理するマネージド ボリュームか、Azure Databricks 内からデータへのアクセスは Unity Catalog で管理し、他のクライアントからクラウド ストレージ内のデータへのアクセスは管理しない外部ボリュームのいずれかになります。 Unity Catalog ボリュームの説明と「マネージドまたは外部のテーブルとボリューム」を参照してください。
• テーブルは、行と列で編成されたデータのコレクションです。 テーブルは、Unity Catalog でテーブルの完全なライフサイクルを管理するマネージド テーブルか、Azure Databricks 内からデータへのアクセスは Unity Catalog で管理し、他のクライアントからクラウド ストレージ内のデータへのアクセスは管理しない外部テーブルのいずれかになります。 テーブルの説明と「マネージドまたは外部のテーブルとボリューム」を参照してください。
• ビューは、1 つ以上のテーブルに対して保存されたクエリです。 ビューの説明を参照してください。
• 関数は、スカラー値または行のセットを返す保存済みロジックの単位です。 「Unity Catalog のユーザー定義関数 (UDF)」を参照してください。
• モデルは、MLflow でパッケージ化され、Unity Catalog に登録された AI モデルです。 「Unity Catalog 内でモデル ライフサイクルを管理する」をご覧ください。

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

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

詳細については、Azure Databricks のデータベース オブジェクトと Unity Catalog と従来の Hive メタストアを使用した操作に関するページを参照してください。

その他のセキュリティ保護可能なオブジェクト

Unity Catalog は、スキーマに含まれるデータベース オブジェクトと AI 資産に加えて、次のセキュリティ保護可能なオブジェクトを使用してデータへのアクセスを管理します。

• ストレージの資格情報: クラウド ストレージへのアクセスを提供する長期的なクラウドの資格情報をカプセル化します。 「Azure Data Lake Storage Gen2 に接続するためのストレージ資格情報の作成」を参照してください。
• 外部の場所: ストレージ資格情報とクラウド ストレージ パスへの参照が含まれます。 外部の場所を使用して、外部テーブルを作成したり、マネージド テーブルとボリュームにマネージド ストレージの場所を割り当てたりすることができます。 「クラウド ストレージを Azure Databricks に接続するための外部の場所を作成する」、「マネージド ストレージを使用したデータの分離」、および「Unity Catalog のマネージド ストレージの場所を指定する」を参照してください。
• 接続: Lakehouse フェデレーションを使用して MySQL などのデータベース システム内の外部データベースへの読み取り専用アクセスを許可する資格情報を表します。 「Lakehouse フェデレーションと Unity Catalog」および「Lakehouse フェデレーションとは」を参照してください。
• 共有: データ プロバイダーが 1 人以上の受信者と共有するデータと AI 資産の読み取り専用コレクションを表す Delta Sharing オブジェクトです。
• 受信者: データ プロバイダーから共有を受け取るエンティティを表す Delta Sharing オブジェクトです。
• プロバイダー: 受信者とデータを共有するエンティティを表す Delta Sharing オブジェクトです。

Delta Sharing のセキュリティ保護可能なオブジェクトの詳細については、「Delta Sharing を使用してデータと AI 資産を安全に共有する」を参照してください。

Unity Catalog 内のデータベース オブジェクトとその他のセキュリティ保護可能なオブジェクトへのアクセスの許可と取り消し

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

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

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

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

Unity Catalog で特権を管理する方法については、「Unity Catalog で特権を管理する」を参照してください。

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

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

管理者ロール

ワークスペース管理者とアカウント管理者には、既定で追加の特権があります。 メタストア管理者は省略可能なロールであり、メタストア レベルでテーブルとボリュームのストレージを管理する場合に必要であり、リージョン内の複数のワークスペース間でデータを一元的に管理する場合に便利です。 詳細については、「Unity Catalog の管理者特権」および「(省略可能) メタストア管理者ロールの割り当て」を参照してください。

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

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

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

Databricks では、Unity Catalog のガバナンス機能とパフォーマンスの最適化を最大限に活用するために、マネージド テーブルとマネージド ボリュームを推奨しています。

マネージド テーブルを使用した作業、外部テーブルを使用した作業、管理ボリュームと外部ボリュームに関する説明を参照してください。

マネージド ストレージを使用したデータの分離

組織は、特定の種類のデータをクラウド テナントの特定のアカウントまたはバケット内に格納することを要求できます。

Unity Catalog では、このような要件を満たすために、メタストア、カタログ、またはスキーマ レベルで格納場所を構成できます。 システムは、スキーマからカタログ、メタストアまでの格納場所の階層を評価します。

たとえば、自分の組織に人事に関する運用データをコンテナー abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net に格納する必要がある会社のコンプライアンス ポリシーがあるとします。 Unity Catalog では、カタログ レベルで場所を設定し、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 では、カタログごとに個別のマネージド ストレージの場所を割り当てることを推奨しています。

詳細については、「Unity Catalog のマネージド ストレージの場所を指定する」および「データは、ストレージ内で物理的に分離されます」を参照してください。

ワークスペースとカタログのバインド

既定では、カタログ所有者 (およびアカウントに対して定義されている場合はメタストア管理者) は、同じ Unity Catalog メタストアに接続されている複数のワークスペースのユーザーにカタログへのアクセスを許可できます。 ただし、ワークスペースを使用してユーザー データ アクセスを分離する場合は、特定の種類のデータがそれらのワークスペースでのみ処理されるように、アカウント内の特定のワークスペースへのカタログ アクセスを制限することができます。 たとえば、運用ワークスペースと開発ワークスペースを別々にする場合や、個人データを処理するための別個のワークスペースが必要な場合があります。 これは、ワークスペースとカタログのバインドと呼ばれます。 「特定のワークスペースにカタログ アクセスを制限する」を参照してください。

データ アクセスの監査

Unity Catalog では、メタストアに対して実行されたアクションの監査ログがキャプチャされ、管理者は特定のデータセットにアクセスしたユーザーと実行したアクションに関する詳細にアクセスできます。

Unity Catalog で管理されているシステム テーブルを使用して、アカウントの監査ログにアクセスできます。

「Unity Catalog イベントを監査する」、「Unity Catalog イベント」、および「システム テーブルを使用して使用状況を監視する」を参照してください。

データ系列の追跡

Unity Catalog を使用すると、Azure Databricks クラスターまたは SQL ウェアハウスに対して実行されたあらゆる言語のクエリを対象にランタイム データ系列をキャプチャできます。 系列は列レベルまでキャプチャされ、クエリに関連するノートブック、ワークフロー、ダッシュボードを含んでいます。 詳細については、「Unity Catalog を使用したデータ系列のキャプチャと表示」を参照してください。

Lakehouse フェデレーションと Unity Catalog

Lakehouse フェデレーションは、Azure Databricks のクエリ フェデレーション プラットフォームです。 クエリ フェデレーションという用語は、すべてのデータを統合システムに移行することなく、ユーザーとシステムが複数のサイロ化されたデータ ソースに対してクエリを実行できるようにする機能のコレクションを表します。

Azure Databricks は、Unity Catalog を使用してクエリ フェデレーションを管理します。 Unity Catalog を使用して、一般的な外部データベース システムへの読み取り専用接続を構成し、外部データベースをミラーする外部カタログを作成します。 Unity Catalog のデータ ガバナンスおよびデータ系列 ツールは、Azure Databricks ワークスペース内のユーザーによって行われたすべてのフェデレーション クエリに対するデータ アクセスの管理と監査を保証します。

「Lakehouse フェデレーションとは」を参照してください。

Delta Sharing、Databricks Marketplace、Unity Catalog

Delta Sharing は、Databricks を使用しているかどうかに関係なく、組織外のユーザーとデータおよび AI 資産を共有できる、セキュリティで保護されたデータ共有プラットフォームです。 Delta Sharing はオープンソース実装として利用できますが、Databricks では拡張機能を最大限に活用するために、Unity Catalog が必要です。 「Delta Sharing を使用してデータと AI 資産を安全に共有する」を参照してください。

Databricks Marketplace は、データ製品を交換するためのオープン フォーラムであり、Delta Sharing の上に構築されているため、Marketplace プロバイダーになるには Unity Catalog 対応ワークスペースが必要です。 Databricks Marketplace の概要に関するページをご覧ください。

組織用に Unity Catalog を設定する方法

Unity Catalog を使用するには、Unity Catalog に対して Azure Databricks ワークスペースを有効にする必要があります。これは、ワークスペースが Unity Catalog メタストアにアタッチされていることを意味します。 新しいワークスペースはすべて作成時に Unity Catalog に対して自動的に有効になりますが、古いワークスペースではアカウント管理者が Unity Catalog を手動で有効にする必要がある場合があります。 ワークスペースが Unity Catalog に対して自動的に有効になっているかどうかにかかわらず、Unity Catalog の使用を開始するには、次の手順も必要です。

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

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

詳細なセットアップ手順については、「Unity Catalog の設定と管理」を参照してください。

既存のワークスペースの Unity Catalog への移行

Unity Catalog に対して最近有効にした古いワークスペースがある場合は、レガシ Hive メタストアによってデータが管理されている可能性があります。 Unity Catalog に登録されているデータと共にそのデータを操作できますが、従来の Hive メタストアは非推奨です。Unity Catalog の優れたガバナンス機能とパフォーマンスを利用するには、できるだけ早く Hive メタストアのデータを Unity Catalog に移行する必要があります。

移行には次の処理が含まれます。

1. ワークスペースローカル グループをアカウントレベルのグループに変換します。 Unity Catalog は、アカウント レベルで ID 管理を一元化します。
2. Hive メタストアで管理されているテーブルとビューを Unity Catalog に移行します。
3. 古い Hive メタストア テーブルではなく、新しい Unity Catalog テーブルを参照するようにクエリとワークフローを更新します。

移行の管理に役立つ情報を次に示します。

• Databricks Labs プロジェクトである UCX には、Unity Catalog 以外のワークスペースを Unity Catalog にアップグレードするのに役立つツールが用意されています。 UCX は、大規模な移行に適しています。 「UCX ユーティリティを使用してワークスペースを Unity Catalog にアップグレードする」を参照してください。

• 移行するテーブルの数が少ない場合は、Azure Databricks の UI ウィザードと SQL コマンドを使用できます。 「Hive のテーブルとビューを Unity Catalog にアップグレードする」を参照してください。

• Hive メタストアのテーブルを、同じワークスペース内の Unity Catalog のデータベース オブジェクトと共に使用する方法については、「Unity Catalog と従来の Hive メタストアの使用」を参照してください。

Unity Catalog の要件と制限事項

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

リージョンのサポート

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

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

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

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

Unity Catalog 内のデータにアクセスするには、クラスターが正しいアクセス モード で構成されている必要があります。 既定で Unity Catalog はセキュリティで保護されています。 クラスターが共有またはシングルユーザー アクセス モードで構成されていない場合、クラスターは Unity Catalog 内のデータにアクセスできません。 「アクセス モード」を参照してください。

Databricks Runtime の各バージョンにおける Unity Catalog の機能変更の詳細については、リリース ノートを参照してください。

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

ファイル形式のサポート

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

• マネージド テーブル では、delta テーブル形式を使用する必要があります。
• 外部テーブルではdelta、CSV、JSON、avro、parquet、ORCまたはtextを使用できます。

制限事項

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

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

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

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

• R のワークロードでは、行レベルまたは列レベルのセキュリティのための動的ビューの使用はサポートされていません。

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

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

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

• ALTER TABLE ADD PARTITION などのコマンドを使用して作成されたカスタム パーティション スキームは、Unity Catalog のテーブルでサポートされません。 Unity Catalog では、ディレクトリスタイルのパーティション分割が使用されているテーブルにアクセスできます。

• Unity Catalog へのデータフレーム書き込み操作での上書きモードがサポートされているのは、Delta テーブルに対してのみであり、他のファイル形式は含まれません。 さらに、ユーザーは親スキーマで CREATE 特権を持っている必要があり、既存オブジェクトの所有者であるかオブジェクトで 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 はサポートされていません。 共有クラスター上の Databricks Runtime 14.2 以降では、Scala スカラー UDF がサポートされています。

• 標準 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 の親 (または先祖) オブジェクトに対して相対的に表されます。

Delta Sharing の制限については、リソース クォータを参照してください。