Unity Catalogとは

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

Unity Catalog の概要

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

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

一度定義すれば、どこでも安全: Unity Catalog は、すべてのワークスペースに適用されるデータアクセスポリシーを 1 か所で管理できます。
標準に準拠したセキュリティモデル: Unity Catalogのセキュリティモデルは標準のANSI SQLに基づいており、管理者は、カタログ、データベース（スキーマとも呼ばれます）、テーブル、およびビューの各レベルで、使い慣れた構文を使用して既存のデータレイクに権限を付与できます。
組み込みの監査とリネージ: Unity Catalog は、データへのアクセスを記録するユーザーレベルの監査ログを自動的にキャプチャします。 Unity カタログは、すべての言語でデータアセットがどのように作成および使用されるかを追跡するリネージデータもキャプチャします。
データディスカバリー: Unity Catalogではデータアセットにタグを付けて文書化でき、またデータ利用者がデータを見つけるのに役立つ検索インターフェースを利用できます。
システムテーブル (パブリックプレビュー): Unity カタログを使用すると、監査ログ、課金対象の使用状況、系列など、アカウントの運用データに簡単にアクセスしてアクセスできます。

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

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

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

ストレージ資格情報は、クラウドストレージへのアクセスを提供する長期的なクラウド資格情報をカプセル化します。たとえば、S3 バケットまたは Cloudflare R2 API トークンにアクセスできる IAM ロール。「AWS S3 に接続するためのストレージ認証情報を作成する」および「Cloudflare R2 に接続するためのストレージ認証情報を作成する」を参照してください。
外部ロケーションには、ストレージ資格情報とクラウドストレージパスへの参照が含まれます。「外部ロケーションを作成してクラウドストレージを Databricks に接続する」を参照してください。
管理されたストレージの場所は、独自のクラウドストレージアカウントの S3 バケットまたは Cloudflare R2 バケット内のストレージの場所をメタストア、カタログ、またはスキーマに関連付けます。管理対象ストレージの場所は、管理対象テーブルおよび管理対象ボリュームのデフォルトのストレージ場所として使用されます。「 Unity Catalogで管理されたストレージの場所を指定する」を参照してください。
ボリュームは 、クラウド・オブジェクト・ストレージに格納されている表形式以外のデータへのアクセスを提供します。「ボリュームの作成と操作」を参照してください。
表は、クラウド・オブジェクト・ストレージに保管されている表形式のデータへのアクセスを提供します。

注

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

Unity Catalogオブジェクトモデル

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

メタストア: メタデータのトップレベルコンテナです。各メタストアでは、データを整理する3つのレベルの名前空間（catalog.schema.table）が公開されます。
カタログ: オブジェクト階層の1番目の層で、データアセットの整理に使用されます。
スキーマ: データベースとも呼ばれます。オブジェクト階層の第2層であり、テーブルとビューが格納されます。
テーブル、ビュー、およびボリューム: データオブジェクト階層の最下位レベルには、テーブル、ビュー、およびボリュームがあります。ボリュームは、表形式以外のデータのガバナンスを提供します。
モデル: 厳密にはデータ資産ではありませんが、登録済みのモデルは Unity Catalog で管理し、オブジェクト階層の最下位レベルに配置することもできます。

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

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

メタストア

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

メタストアは、オプションで、独自のクラウドストレージアカウントの S3 バケットまたは 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は基になるデータを削除しません。外部テーブルに対する権限を管理し、マネージドテーブルと同じ方法でクエリで使用できます。

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

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

ビュー

ビューは、メタストア内の 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 オブジェクト階層の任意のレベル (メタストア、カタログ、またはスキーマ) に格納できます。階層の下位レベルのストレージは、上位レベルで定義されたストレージをオーバーライドします。

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

重要

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

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

管理対象テーブルと管理対象ボリュームは、データとメタデータ・ファイルを管理対象ストレージに保管します。
管理対象ストレージの場所は、外部テーブルまたは外部ボリュームと重複することはできません。

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

関連付けられた Unity Catalog オブジェクト	設定方法	外部ロケーションとの関係
メタストア	メタストアの作成時にアカウント管理者によって構成されるか、作成時にストレージが指定されていない場合はメタストアの作成後に追加されます。	外部ロケーションと重なることはできません。
カタログ	カタログの作成時に `MANAGED LOCATION` キーワードを使用して指定します。	外部ロケーションに含まれている必要があります。
スキーマ	`MANAGED LOCATION` キーワードを使用したスキーマ作成時に指定します。	外部ロケーションに含まれている必要があります。

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

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

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

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

ストレージ認証情報は、S3 バケットや Cloudflare R2 API トークンにアクセスできる IAM ロールなど、クラウドストレージへのアクセスを提供する長期クラウド認証情報をカプセル化します。「AWS S3 に接続するためのストレージ認証情報を作成する」および「Cloudflare R2 に接続するためのストレージ認証情報を作成する」を参照してください。
外部ロケーションには、ストレージ資格情報とクラウドストレージパスへの参照が格納されています。

「 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では、次のテーブル形式がサポートされています。

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

Unity Catalog 制限事項

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

注

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

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

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

オブジェクト名は 255 文字を超えることはできません。
次の特殊文字は使用できません。
- 期間 (.)
- スペース ( )
- スラッシュ (/)
- すべての ASCII 制御文字 (00-1F 16 進数)
- 削除文字 (7F 16 進数)
Unity Catalog は、すべてのオブジェクト名を小文字で格納します。
SQL で UC 名を参照する場合は、バッククォートを使用して、ハイフン (-) などの特殊文字を含む名前をエスケープする必要があります。

注

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

Databricks では、外部ロケーションが単一のメタストアで定義されている場合にのみ、S3 の外部ロケーションによってサポートされるテーブルに対する書き込み特権を付与することをお勧めします。複数のメタストアを使用して 1 つの外部 S3 ロケーションのデータを安全に読み取ることができますが、複数のメタストアから同じ S3 ロケーションへの並列書き込みは、整合性の問題が発生する可能性があります。

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 制限については、「リソースクォータ」を参照してください。