メインコンテンツまでスキップ

Unity Catalog とは何ですか?

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

注記

Unity Catalog は、オープンソースの実装としても利用できます。 お知らせのブログと公開されている Unity Catalog GitHub リポジトリを参照してください。

Unity Catalog の概要​

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

Unity Catalogの図

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

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

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

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

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

メタストア​

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

ワークスペースがあるリージョンごとに 1 つのメタストアが必要です。 ワークスペースはどのようにしてメタストアにアタッチされますか? 組織の Unity Catalog を設定する方法を参照してください。

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

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

レベル1:

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

レベル2:

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

レベル3:

  • ボリューム は、クラウドオブジェクトストレージ内の非構造化、非表形式データの論理ボリュームです。 ボリュームは、Unity Catalog がストレージ内のデータのライフサイクル全体とレイアウトを管理するように 管理 することも、Unity Catalog が Databricks 内からデータへのアクセスを管理するが、他のクライアントからクラウド ストレージ内のデータへのアクセスを管理するわけではない 外部 管理を行うこともできます。 Unity Catalogボリュームとはおよび管理テーブルと外部テーブルおよびボリュームの比較を参照してください。
  • テーブル は、行と列で整理されたデータのコレクションです。 テーブルは、Unity Catalog がテーブルのライフサイクル全体を管理するように管理することも、Unity Catalog が Databricks 内からデータへのアクセスを管理するが、他のクライアントからクラウド ストレージ内のデータへのアクセスを管理することはない 外部 の Unity Catalog を使用して 管理 することもできます。テーブルとは および管理テーブルと外部テーブルおよびボリュームの比較を参照してください。
  • ビュー は、1 つ以上のテーブルに対する保存されたクエリです。 「ビューとは」を参照してください。
  • 関数はスカラー値または行のセットを返す保存されたロジックの単位です 。 「Unity Catalog のユーザー定義関数 (UDF)」を参照してください。
  • モデルは 、MLflow にパッケージ化され、Unity Catalog に関数として登録される AI モデルです。 「Unity Catalog でのモデルのライフサイクルの管理」を参照してください。

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

Unity Catalog でのデータベースオブジェクトの操作は、Hive metastoreに登録されているデータベースオブジェクトの操作とよく似ていますが、Hive metastoreオブジェクト名前空間にカタログが含まれていない点が異なります。使い慣れた ANSI 構文を使用して、データベース オブジェクトの作成、データベース オブジェクトの管理、アクセス許可の管理、Unity Catalog でのデータの操作を行うことができます。 また、Catalog Explorer UI を使用して、データベース オブジェクトの作成、データベース オブジェクトの管理、およびデータベース オブジェクトに対する権限の管理を行うこともできます。

詳細については、「Databricksのデータベース オブジェクト」および「Unity Catalog と従来のHive metastoreの操作」を参照してください。

その他の保護可能なオブジェクト​

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

Delta Sharingセキュリティ保護可能なオブジェクトの詳細については、Delta Sharingとはを参照してください。

Unity Catalog 内のデータベース オブジェクトおよびその他のセキュリティ保護可能なオブジェクトに対するアクセス権の付与と取り消し​

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

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

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

カタログエクスプローラ、 Databricks CLI、および REST APIs を使用して、オブジェクトの権限を管理することもできます。

カタログエクスプローラを使用した権限の付与

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

Unity Catalog のデータベースオブジェクトへのデフォルトアクセス​

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

管理者の役割​

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

マネージドテーブルと外部テーブルおよびボリュームの比較​

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

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

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

マネージドテーブルの操作、外部テーブルの操作、および管理ボリュームと外部ボリュームを参照してください。

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

組織では、特定の種類のデータをクラウド テナントの特定のアカウントまたはバケット内に格納する必要がある場合があります。

このような要件を満たすために、Unity Catalogを用いることで、メタストア、カタログ、またはスキーマ レベルのストレージロケーションを設定することができます。 システムは、スキーマからカタログ、メタストアに至るストレージロケーションの階層を評価します。

たとえば、組織に会社のコンプライアンス ポリシーがあり、人間のリソースに関連する本番運用データをバケット s3://mycompany-hr-prod に存在させる必要があるとします。 Unity Catalog では、カタログ レベルで場所を設定し、 hr_prodなどというカタログを作成し、それに 場所 s3://mycompany-hr-prod/unity-catalog を割り当てることで、この要件を達成できます。 つまり、 hr_prod カタログで作成されたマネージドテーブルまたはボリューム ( CREATE TABLE hr_prod.default.table …など) は、そのデータを s3://mycompany-hr-prod/unity-catalog に保存します。 必要に応じて、スキーマレベルの場所を提供して、 hr_prod catalog 内のデータをより詳細なレベルで整理することを選択できます。

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

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

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

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

注記

データの分離を強化するために、クラウド ストレージ アクセスとクラウド サービス アクセスを特定のワークスペースにバインドすることもできます。 「(オプション) 特定のワークスペースにストレージ資格情報を割り当てる」、「(オプション) 特定のワークスペースに外部ロケーションを割り当てる」、および (「オプション) 特定のワークスペースにサービス資格情報を割り当てる」を参照してください。

データ・アクセスの監査​

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

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

Unity Catalogイベントの監査、 Unity Catalogイベント、およびシステムテーブルによるアカウントアクティビティの監視を参照してください。

データリネージの追跡​

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

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

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

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

「レイクハウスフェデレーションとは」を参照してください。

Delta Sharing、 Databricks Marketplace、および Unity Catalog​

Delta Sharing は、データや AI 資産を組織外のユーザーと共有できる安全なデータ共有プラットフォームです (そのユーザーが Databricks を使用しているかどうかは関係ありません)。 Delta Sharing はオープンソースの実装として利用できますが、Databricks では、拡張機能を最大限に活用するために Unity Catalog が必要です。 「Delta Sharing とは」を参照してください。

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

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

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

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

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

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

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

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

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

既存のワークスペースを Unity Catalog に移行する​

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

移行には以下が含まれます。

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

移行の管理には、次の方法があります。

Unity Catalog の要件と制限​

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

地域サポート​

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

コンピュートの要件​

Unity Catalogは、Databricks Runtime 11.3LTS 以降が実行されるクラスターでサポートされています。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 Catalogでは、次のテーブル形式がサポートされています。

セキュリティ保護可能なオブジェクトの名前付け要件​

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

  • オブジェクト名は 255 文字以内にする必要があります。

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

    • ピリオド (.)
    • スペース ()
    • スラッシュ (/)
    • すべてのASCII制御文字(00-1F、16進数)
    • DELETEキャラクタ(7Fヘックス)

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

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

注記

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

制限​

Unity Catalog には、次の制限があります。 これらの一部は、古い Databricks Runtime バージョンとコンピュート アクセス モードに固有のものです。

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

Databricks では、このリストを定期的に縮小する新機能がリリースされています。

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

動的ビューをクエリする R のワークロードには、 Databricks Runtime 15.4 LTS 以降を実行している専用のコンピュート リソースを使用します。 このようなワークロードには、サーバレス コンピュートが有効になっているワークスペースも必要です。 詳細については、「 専用コンピュート (旧シングル ユーザー コンピュート) のきめ細かなアクセス制御」を参照してください。

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

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

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

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

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

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

  • Scala UDF は、標準アクセス モードのコンピュートの Databricks Runtime 14.1 以下ではサポートされていません。 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 は、セキュリティ保護可能なすべてのオブジェクトにリソース クォータを適用します。 これらのクォータは、「 リソース制限」に記載されています。 これらのリソース制限を超えることが予想される場合は、Databricks アカウント チームにお問い合わせください。

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

に最終更新