Unity Catalogとは

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

Unity Catalogの概要

Unity Catalogでは、複数のDatabricksワークスペースに対して、一元化されたアクセス制御、監査、系列、およびデータ検出機能を利用できます。

Unity Catalogの図

Unity Catalogの主な機能は次のとおりです。

  • 一度定義すれば、どこでも安全: Unity Catalog は、すべてのワークスペースに適用されるデータ アクセス ポリシーを 1 か所で管理できます。

  • 標準に準拠したセキュリティモデル: Unity Catalogのセキュリティモデルは標準のANSI SQLに基づいており、管理者は、カタログ、データベース(スキーマとも呼ばれます)、テーブル、およびビューの各レベルで、使い慣れた構文を使用して既存のデータレイクに権限を付与できます。

  • 組み込みの監査: Unity Catalog は、データへのアクセスを記録するユーザーレベルの監査ログを自動的にキャプチャします。

  • データディスカバリー: Unity Catalogではデータアセットにタグを付けて文書化でき、またデータ利用者がデータを見つけるのに役立つ検索インターフェースを利用できます。

Unity Catalog は、クラウド オブジェクト ストレージ内のデータと AI 資産へのアクセスをどのように管理しますか?

Databricks では、Unity Catalog を使用してクラウド オブジェクト ストレージへのすべてのアクセスを構成することをお勧めします。 「 Unity Catalog を使用したクラウド オブジェクト ストレージへの接続」を参照してください。

Unity Catalog では、Databricks 内のデータとクラウド オブジェクト ストレージ間の関係を管理するために、次の概念が導入されています。

レイクハウスフェデレーションは、他の外部システムのデータとの統合を提供します。 これらのオブジェクトは、クラウド・オブジェクト・ストレージによってバッキングされません。

Unity Catalogオブジェクトモデル

Unity Catalogでは、プライマリ データ オブジェクトの階層はメタストアからテーブルまたはボリュームに流れます。

  • メタストア: メタデータのトップレベルコンテナです。各メタストアでは、データを整理する3つのレベルの名前空間(catalog.schema.table)が公開されます。

  • カタログ: オブジェクト階層の1番目の層で、データアセットの整理に使用されます。

  • スキーマ: データベースとも呼ばれます。オブジェクト階層の第2層であり、テーブルとビューが格納されます。

  • テーブル、ビュー、およびボリューム: データオブジェクト階層の最下位レベルには、テーブル、ビュー、およびボリュームがあります。 ボリュームは、表形式以外のデータのガバナンスを提供します。

  • モデル: 厳密にはデータ資産ではありませんが、登録済みのモデルは Unity Catalog で管理し、オブジェクト階層の最下位レベルに配置することもできます。

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

これは、セキュリティ保護可能なUnity Catalogオブジェクトの簡略ビューです。詳しくは、「Unity Catalogのセキュリティ保護可能なオブジェクト」を参照してください。

Unity Catalog 内のすべてのデータは、テーブル、ビュー、ボリューム、またはモデルの 3 つのレベルの名前空間 catalog.schema.assetを使用して参照 asset

メタストア

メタストアは、Unity Catalog 内のオブジェクトの最上位のコンテナーです。 データと AI 資産に関するメタデータと、それらへのアクセスを制御するアクセス許可を登録します。 Databricks アカウント管理者は、操作するリージョンごとに 1 つのメタストアを作成し、同じリージョン内の Databricks ワークスペースに割り当てる必要があります。 ワークスペースで Unity Catalog を使用するには、Unity Catalog メタストアがアタッチされている必要があります。

メタストアは、オプションで、独自のクラウド ストレージ アカウントの GCS バケットまたは Cloudflare R2 バケット内の管理されたストレージの場所を使用して構成できます。 「 管理対象ストレージ」を参照してください。

このメタストアは、Unity Catalogが有効になっていないDatabricksワークスペースに含まれるHive metastoreとは異なります。ワークスペースにレガシーHive metastoreが含まれている場合、そのメタストア内のデータは、hive_metastoreという名前のカタログ内の Unity Catalogで定義されたデータと共に引き続き使用できます。 hive_metastoreカタログはUnity Catalogでは管理されず、Unity Catalogで定義されているカタログとは同じ機能セットを利用できないことに注意してください。

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

カタログ

カタログは、3層から成るUnity Catalog名前空間の1番目の層で、データアセットの整理に使用されます。ユーザーは、USE CATALOGデータ権限が割り当てられているすべてのカタログを表示できます。

ワークスペースの作成方法と Unity Catalog の有効化方法によっては、main カタログやワークスペース カタログ (<workspace-name>など) など、自動的にプロビジョニングされたカタログに対する既定のアクセス許可がユーザーに付与される場合があります。詳細については、「 既定のユーザー権限」を参照してください。

カタログの作成と管理」を参照してください。

スキーマ

スキーマ(別称「データベース」)は3層から成るUnity Catalog名前空間の2層目です。スキーマは、テーブルとビューの整理に使用します。ユーザーは、USE SCHEMA権限が割り当てられているすべてのスキーマと、親カタログにUSE CATALOG権限が割り当てられているスキーマを表示できます。スキーマ内のテーブルやビューにアクセスまたは一覧表示するには、ユーザーはテーブルまたはビューに対するSELECT権限も持っている必要があります。

ワークスペースで Unity Catalog を手動で有効にした場合、ワークスペース内のすべてのユーザーがアクセスできる main カタログに default という名前の既定のスキーマが含まれます。ワークスペースで Unity Catalog が自動的に有効になり、 <workspace-name> カタログが含まれている場合、そのカタログには、ワークスペース内のすべてのユーザーがアクセスできる default という名前のスキーマが含まれています。

スキーマ(データベース)の作成と管理」を参照してください。

テーブル

テーブルは3層から成るUnity Catalog名前空間の3層目で、データ行が格納されています。テーブルを作成するには、ユーザーはスキーマに対するCREATE権限とUSE SCHEMA権限、およびその親カタログに対するUSE CATALOG権限を持っている必要があります。テーブルをクエリするには、テーブルに対するSELECT権限、親スキーマに対するUSE SCHEMA権限、および親カタログに対するUSE CATALOG権限が必要です。

テーブルは、マネージドテーブルでも外部テーブルでもかまいません。

マネージドテーブル

マネージドテーブルは、Unity Catalogでテーブルを作成する既定の方法です。Unity Catalogは、これらのテーブルのライフサイクルとファイルレイアウトを管理します。Databricks外部でツールを使用してこれらのテーブル内のファイルを直接操作しないでください。 マネージドテーブルでは常にDeltaテーブル形式が使用されます。

Unity Catalogに対して手動で有効化されたワークスペースの場合、管理対象テーブルは、メタストアの作成時に構成したルート ストレージの場所に保存されます。 必要に応じて、カタログ レベルまたはスキーマ レベルでマネージド テーブルの格納場所を指定し、ルート ストレージの場所をオーバーライドできます。

Unity Catalogに対して自動的に有効になったワークスペースの場合、メタストアのルート ストレージの場所はオプションであり、管理対象テーブルは通常、カタログ レベルまたはスキーマ レベルで保存されます。

マネージドテーブルが削除されると、その基になるデータは30日以内にクラウドテナントから削除されます。

マネージドテーブル」を参照してください。

外部テーブル

外部テーブルは、データのライフサイクルとファイルレイアウトがUnity Catalogで管理されていないテーブルです。外部テーブルは、大量の既存のデータをUnity Catalogに登録する場合、またはDatabricksクラスターやDatabricks SQLウェアハウスの外部にあるツールを使用してデータに直接アクセスする必要がある場合に使用します。

外部テーブルを削除しても、Unity Catalogは基になるデータを削除しません。外部テーブルに対する権限を管理し、マネージドテーブルと同じ方法でクエリで使用できます。

外部テーブルでは、次のファイル形式を使用できます。

  • DELTA

  • CSV

  • JSON

  • AVRO

  • PARQUET

  • ORC

  • TEXT

外部テーブル」を参照してください。

ビュー

ビューは、メタストア内の 1 つ以上のテーブルとビューから作成される読み取り専用オブジェクトです。 これは、Unity Catalog の 3 レベルの名前空間の 3 番目のレイヤーに存在します。 ビューは、複数のスキーマおよびカタログ内のテーブルおよびその他のビューから作成できます。 動的ビューを作成して、行レベルと列レベルの権限を有効にすることができます。

ダイナミックビューの作成」を参照してください。

ボリューム

プレビュー

この機能はパブリックプレビュー段階です。

ボリュームは、 Unity Catalogの 3 レベルの名前空間の第 3 層に存在します。 ボリュームは、 Unity Catalogのスキーマの下に編成されたテーブル、ビュー、およびその他のオブジェクトの兄弟です。

ボリュームには、任意の形式で格納されたデータのディレクトリとファイルが含まれています。 ボリュームはデータへの非表形式のアクセスを提供するため、ボリューム内のファイルをテーブルとして登録することはできません。

  • ボリュームを作成するには、ユーザーはスキーマに対する CREATE VOLUME および USE SCHEMA 権限と、その親カタログに対する USE CATALOG 権限を持っている必要があります。

  • ボリューム内に格納されているファイルとディレクトリを読み取るには、ユーザーは READ VOLUME アクセス許可、親スキーマに対する USE SCHEMA アクセス許可、および親カタログに対する USE CATALOG アクセス許可を持っている必要があります。

  • ボリューム内に格納されているファイルとディレクトリを追加、削除、または変更するには、ユーザーは WRITE VOLUME アクセス許可、親スキーマに対する USE SCHEMA アクセス許可、および親カタログに対する USE CATALOG アクセス許可を持っている必要があります。

ボリュームは、 管理 または 外部にすることができます。

ボリュームを定義すると、ボリューム パスの下のデータへのクラウド URI アクセスは、ボリュームの権限によって管理されます。

管理対象ボリューム

管理対象ボリュームは、表形式以外のファイルを操作するための管理された場所をプロビジョニングする場合に便利なソリューションです。

管理対象ボリュームは、ファイルが含まれるスキーマのUnity Catalogのデフォルトの保存場所にファイルを保存します。 Unity Catalogに対して手動で有効化されたワークスペースの場合、管理対象ボリュームは、メタストアの作成時に構成したルート ストレージの場所に保存されます。 必要に応じて、管理対象ボリュームの格納場所をカタログ レベルまたはスキーマ レベルで指定し、ルート格納場所をオーバーライドできます。 Unity Catalogに対して自動的に有効になったワークスペースの場合、メタストアのルート ストレージの場所はオプションであり、管理対象ボリュームは通常、カタログ レベルまたはスキーマ レベルで保存されます。

以下の優先順位によって、管理対象ボリュームに使用されるロケーションが決まります。

  • スキーマの場所

  • カタログの場所

  • Unity Catalogメタストアのルート保存場所

マネージド ボリュームを削除すると、このボリュームに格納されているファイルも 30 日以内にクラウド テナントから削除されます。

「管理対象ボリュームとは」を参照してください。

外部ボリューム

外部ボリュームは Unity Catalog 外部ロケーションに登録され、データ移行を必要とせずにクラウドストレージ内の既存のファイルへのアクセスを提供します。 ユーザーが外部ボリュームを作成するには、外部ロケーションに対する CREATE EXTERNAL VOLUME 権限が必要です。

外部ボリュームは、ファイルが他のシステムによって生成され、オブジェクト ストレージを使用して Databricks 内からアクセスするためにステージングされるシナリオ、または Databricks 外部のツールが直接ファイル アクセスを必要とするシナリオをサポートします。

Unity Catalog では、外部ボリューム内のファイルのライフサイクルとレイアウトは管理されません。 外部ボリュームを削除しても、 Unity Catalog は基になるデータを削除しません。

「外部ボリュームとは」を参照してください。

モデル

モデルは、 Unity Catalogの 3 レベルの名前空間の 3 番目の層に存在します。 ここでの「モデル」とは、 MLflow Model Registryに登録されている機械学習モデルを指します。 Unity Catalogでモデルを作成するには、ユーザーはカタログまたはスキーマに対する CREATE MODEL 権限を持っている必要があります。 また、ユーザーは、親カタログに対する USE CATALOG 特権と、親スキーマに対する USE SCHEMA を持っている必要があります。

管理ストレージ

マネージド テーブルとマネージド ボリュームは、Unity Catalog オブジェクト階層の任意のレベル (メタストア、カタログ、またはスキーマ) に格納できます。 階層の下位レベルのストレージは、上位レベルで定義されたストレージをオーバーライドします。

アカウント管理者がメタストアを手動で作成する場合、独自のクラウド ストレージ アカウントの GCS バケットまたは Cloudflare R2 バケットにストレージの場所を割り当てて、管理対象テーブルとボリュームのメタストア レベルのストレージとして使用するオプションがあります。 メタストア レベルの管理ストレージの場所が割り当てられている場合、カタログ レベルとスキーマ レベルでの管理されたストレージの場所は省略可能です。 ただし、メタストア レベルのストレージはオプションであり、Databricks では、論理データ分離のためにカタログ レベルでマネージド ストレージを割り当てることをお勧めします。 データガバナンスとデータ分離ビルディング ブロックを参照してください。

重要

ワークスペースで Unity Catalog が自動的に有効になった場合、Unity Catalog メタストアはメタストア レベルのマネージド ストレージなしで作成されています。 メタストア レベルのストレージを追加することもできますが、Databricks では、カタログ レベルとスキーマ レベルでマネージド ストレージを割り当てることをお勧めします。 メタストア レベルのストレージが必要かどうかを判断するには、「 (省略可能) メタストア レベルのストレージを作成する 」および「 ストレージ内でデータが物理的に分離されている」を参照してください。

管理対象ストレージには、次のプロパティがあります。

  • 管理対象テーブルと管理対象ボリュームは、データとメタデータ・ファイルを管理対象ストレージに保管します。

  • 管理対象ストレージの場所は、外部テーブルまたは外部ボリュームと重複することはできません。

次の表では、管理対象ストレージを宣言し、 Unity Catalog オブジェクトに関連付ける方法について説明します。

関連付けられた Unity Catalog オブジェクト

設定方法

外部ロケーションとの関係

メタストア

メタストアの作成時にアカウント管理者によって構成されるか、作成時にストレージが指定されていない場合はメタストアの作成後に追加されます。

外部ロケーションと重なることはできません。

カタログ

カタログの作成時に MANAGED LOCATION キーワードを使用して指定します。

外部ロケーションに含まれている必要があります。

スキーマ

MANAGED LOCATION キーワードを使用したスキーマ作成時に指定します。

外部ロケーションに含まれている必要があります。

管理対象表および管理対象ボリュームのデータおよびメタデータの保管に使用される管理対象ストレージの場所では、以下の規則が使用されます。

  • 含まれているスキーマに管理された場所がある場合、データはスキーマの管理場所に格納されます。

  • 含まれているスキーマに管理された場所がなく、カタログに管理された場所がある場合、データはカタログの管理場所に格納されます。

  • 包含スキーマも包含カタログにも管理された場所がない場合、データはメタストアの管理場所に格納されます。

ストレージ資格情報と外部ロケーション

外部テーブル、外部ボリューム、マネージド ストレージの基になるクラウド ストレージへのアクセスを管理するために、Unity Catalog では次のオブジェクトの種類が使用されます。

Unity Catalog を使用したクラウド オブジェクト ストレージへの接続」を参照してください。

Unity CatalogのID管理

Unity Catalogは、DatabricksアカウントのIDを使用して、ユーザー、サービスプリンシパル、グループを解決し、権限を適用します。

アカウントでIDを設定するには、「、ユーザー、サービスプリンシパル、グループの管理」の手順に従います。Unity Catalogでアクセス制御ポリシーを作成するときは、これらのユーザー、サービスプリンシパル、およびグループを参照してください。

Unity Catalog ユーザー、サービスプリンシパル、およびグループも、ノートブック、Databricks SQL クエリー、カタログ エクスプローラー、または REST API コマンド内の Unity Catalog データにアクセスするには、ワークスペースに追加する必要があります。 ワークスペースへのユーザー、サービスプリンシパル、およびグループの割り当ては、 ID フェデレーションと呼ばれます。

Unity Catalogメタストアがアタッチされているすべてのワークスペースで、IDフェデレーションが有効になります。

グループに関する特別な考慮事項

ワークスペースに既に存在するグループには、アカウントコンソールで[ワークスペースローカル]というラベルが付けられます。Unity Catalogでこれらのワークスペースローカルグループを使用してアクセスポリシーを定義することはできません。アカウントレベルのグループを使用する必要があります。ワークスペースローカルグループがコマンドで参照されている場合、そのコマンドはグループが見つからなかったというエラーを返します。以前にワークスペースローカルグループを使用してノートブックやその他のアーティファクトへのアクセスを管理していた場合、これらの権限は引き続き有効です。

グループの管理」を参照してください。

Unity Catalogの管理者ロール

アカウント管理者、メタストア管理者、ワークスペース管理者は、Unity Catalog の管理に関与します。

Unity Catalog の管理者特権」を参照してください。

Unity Catalogのデータ権限

Unity Catalogでは、データはデフォルトで保護されます。最初は、ユーザーはメタストア内のデータにアクセスできません。アクセスは、メタストア管理者、オブジェクトの所有者、またはオブジェクトが格納されたカタログまたはスキーマの所有者のいずれかが許可できます。Unity Catalogのセキュリティ保護可能なオブジェクトは階層構造で、権限は上位から下位に継承されます。

権限の割り当てと取り消しは、カタログ エクスプローラ、SQL コマンド、または REST APIsを使用して行うことができます。

Unity Catalogでの権限の管理」を参照してください。

Unity Catalog でサポートされているコンピュートとクラスターのアクセス モード

Unity Catalogは、Databricks Runtime 11.3 LTS以上を実行するクラスターでサポートされます。Unity Catalogは、すべてのSQLウェアハウスコンピュートバージョンでデフォルトでサポートされています。

以前のバージョンのDatabricks Runtimeで実行されているクラスターでは、Unity Catalog GAの一部の機能がサポートされない場合があります。

Unity Catalog のデータにアクセスするには、クラスターを正しい アクセス モードで構成する必要があります。 Unity Catalog は 既定でセキュリティで保護されます。 クラスターが Unity Catalog 対応アクセス モードのいずれか (つまり、共有または割り当て済み) で構成されていない場合、クラスターは Unity Catalog 内のデータにアクセスできません。 アクセス・モードを参照してください。

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

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

Unity Catalogのデータリネージ

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

レイクハウスフェデレーションと Unity Catalog

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

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

「レイクハウスフェデレーションとは」をご覧ください。

自分の組織のUnity Catalogを設定するにはどうすればよいですか?

Unity Catalog の設定方法については、「 Unity Catalog の設定と管理」を参照してください。

サポートされているリージョン

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

サポートされているデータファイル形式

Unity Catalogでは、次のテーブル形式がサポートされています。

Unity Catalog 制限事項

Unity Catalogには次の制限があります。

クラスターが 11.3 LTSより前のDatabricks Runtimeバージョンで実行されている場合は、ここに記載されていない制限が他に存在する可能性があります。Unity CatalogはDatabricks Runtime 11.3 LTS以上でサポートされています。

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

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

  • Databricks Runtime 13.1 以降では、既存の Unity Catalog マネージド テーブルから Unity Catalog マネージド テーブルを作成するために、浅い複製がサポートされています。 Databricks Runtime 13.0 以下では、Unity Catalog での浅い複製はサポートされていません。 「 Unity Catalog テーブルの浅い複製」を参照してください。

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

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

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

  • Unity CatalogへのDataFrame書き込み操作の上書きモードは、Deltaテーブルでのみサポートされ、他のファイル形式ではサポートされません。ユーザーは、親スキーマに対するCREATE権限を持っている必要があり、また既存のオブジェクトの所有者であるか、オブジェクトに対するMODIFY権限を持っている必要があります。

  • Databricks Runtime 13.2 以降では、Python スカラー UDF がサポートされています。 Databricks Runtime 13.1 以下では、Spark (applyInPandasmapInPandas) で UDAF、UDTF、Pandas などの Python UDF を使用できません。

  • Databricks Runtime 14.2 以降では、Scala スカラー UDF は共有クラスターでサポートされています。 Databricks Runtime 14.1 以前では、すべての Scala UDF が共有クラスターでサポートされているわけではありません。

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

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

Unity Catalog内のすべてのオブジェクト名には、次の制限が適用されます。

  • オブジェクト名は 255 文字を超えることはできません。

  • 次の特殊文字は使用できません。

    • 期間 (.)

    • スペース ( )

    • スラッシュ (/)

    • すべての ASCII 制御文字 (00-1F 16 進数)

    • 削除文字 (7F 16 進数)

  • Unity Catalog は、すべてのオブジェクト名を小文字で格納します。

  • SQL で UC 名を参照する場合は、バッククォートを使用して、ハイフン (-) などの特殊文字を含む名前をエスケープする必要があります。

列名には特殊文字を使用できますが、特殊文字を使用する場合は、すべての SQL ステートメントで名前をバッククォートでエスケープする必要があります。 Unity Catalog では列名の大文字と小文字の区別が保持されますが、 Unity Catalog テーブルに対するクエリーでは大文字と小文字が区別されません。

Unity Catalog のモデルには、追加の制限があります。 「 Unity Catalog のサポートに関する制限事項」を参照してください。

リソースクォータ

Unity Catalog は、セキュリティ保護可能なすべてのオブジェクトにリソース クォータを適用します。 制限は、 Unity Catalog全体で同じ階層組織を尊重します。 これらのリソース制限を超えることが予想される場合は、Databricks アカウント チームにお問い合わせください。

以下のクォータ値は、Unity Catalog の親 (または祖父母) オブジェクトを基準にして表されます。

オブジェクト

テーブル

スキーマ

10000

テーブル

メタストア

100000

容積

スキーマ

10000

関数

スキーマ

10000

登録されたモデル

スキーマ

1000

登録されたモデル

メタストア

5000

モデルバージョン

登録されたモデル

10000

モデルバージョン

メタストア

100000

スキーマ

カタログ

10000

カタログ

メタストア

1000

接続

メタストア

1000

ストレージ資格情報

メタストア

200

外部ロケーション

メタストア

500

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