Unity Catalog とは

  • [アーティクル]

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

Unity Catalog の概要

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

Unity Catalog の図

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

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

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

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

Unity Catalog では、Azure Databricks とクラウド オブジェクト ストレージの間の関係を管理するための以下の概念が導入されます。

Note

Lakehouse Federation は、他の外部システムのデータへの統合を提供します。 これらのオブジェクトは、クラウド オブジェクト ストレージによってサポートされません。

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

Unity Catalog では、主なデータ オブジェクトの階層は以下のようなメタストアからテーブルまたはボリュームへの流れになります:

  • メタストア: メタデータの最上位のコンテナー。 各メタストアでは、3 レベルの名前空間 (catalog.schema.table) が公開され、ここでデータが整理されます。
  • カタログ: データ資産の整理に使用されるオブジェクト階層の最初のレイヤー。
  • スキーマ: データベースとも呼ばれる、オブジェクト階層の 2 番目のレイヤーで、テーブルとビューが含まれます。
  • テーブル、ビュー、ボリューム: データ オブジェクト階層の最下位レベルにはテーブル、ビュー、およびボリュームがあります。 ボリュームは、表形式以外のデータに対するガバナンスを提供します。
  • モデル: 厳密にはデータ資産ではありませんが、登録されたモデルも Unity Catalog で管理することができ、オブジェクト階層の最下層に存在します。

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

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

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

メタストア

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

必要に応じて、お使いのクラウド ストレージ アカウントの Azure Data Lake Storage Gen2 コンテナーまたは Cloudflare R2 バケット内のマネージド保存場所を使ってメタストアを構成できます。 「マネージド ストレージ」を参照してください。

Note

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

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

カタログ

カタログは、Unity Catalog の 3 レベルの名前空間の最初のレイヤーです。 データ資産を整理するために使用されます。 ユーザーは、USE CATALOGデータのアクセス許可が割り当てられているすべてのカタログを表示できます。

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

「カタログを作成および管理する」を参照してください。

スキーマ

スキーマ (データベースとも呼ばれる) は、Unity Catalog の 3 レベルの名前空間の 2 番目のレイヤーです。 スキーマで、テーブルとビューを整理します。 ユーザーは、スキーマの親カタログに対する USE CATALOG アクセス許可に加えて、USE SCHEMA アクセス許可が割り当てられているすべてのスキーマを確認できます。 ユーザーがスキーマ内のテーブルまたはビューにアクセスまたは一覧表示するには、テーブルまたはビューに対する SELECT アクセス許可も必要です。

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

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

テーブル

テーブルは、Unity Catalog の 3 レベルの名前空間の 3 番目のレイヤーにあります。 データの行が含まれます。 テーブルを作成するには、スキーマに対する CREATE と USE SCHEMA のアクセス許可と、その親カタログに対する USE CATALOG アクセス許可がユーザーに必要です。 ユーザーがテーブルのクエリを実行するには、テーブルに対する SELECT アクセス許可、その親スキーマに対する USE SCHEMA アクセス許可、およびその親カタログに対する USE CATALOG アクセス許可が必要です。

テーブルは、"マネージド" か "外部" にすることができます。

マネージド テーブル

マネージド テーブルは、Unity Catalog にテーブルを作成するために優先される方法です。 Unity Catalog で、これらのテーブルのライフサイクルとファイル レイアウトを管理します。 Unity Catalog では、パフォーマンスが自動的に最適化されます。 Azure Databricks の外部のツールを使用して、これらのテーブル内のファイルを直接操作しないでください。 マネージド テーブルでは、常に Delta テーブル形式を使用します。

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

Unity Catalog に対して自動的に有効になったワークスペースの場合、メタストアのルートの保存場所は省略可能であり、通常、マネージド テーブルはカタログ レベルまたはスキーマ レベルで保存されます。

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

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

外部テーブル

外部テーブルは、データ ライフサイクルとファイル レイアウトが Unity Catalog によって管理されないテーブルです。 大量の既存のデータを Unity Catalog に登録するか、Azure 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 アクセス許可が必要です。

ボリュームは、マネージド か 外部 にすることができます。

Note

ボリュームを定義すると、ボリューム パスの下にあるデータへのクラウド URI アクセスは、ボリュームのアクセス許可によって制御されます。

マネージド ボリューム

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

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

次の優先順位は、マネージド ボリュームに使用される場所を制御します:

  • スキーマの場所
  • カタログの場所
  • Unity Catalog メタストアのルートの保存場所

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

マネージド ボリュームの概要に関するページを参照してください。

外部ボリューム

外部ボリュームは Unity Catalog の外部の場所に登録され、データ移行を必要とせずにクラウド ストレージ内の既存のファイルにアクセスできます。 ユーザーは、外部ボリュームを作成するための外部の場所に対する CREATE EXTERNAL VOLUMEアクセス許可を持っている必要があります。

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

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

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

モデル

モデルは、3 レベルから成る Unity Catalog の名前空間の 3 番目のレイヤーにあります。 このコンテキストで、"モデル" とは、MLflow モデル レジストリに登録されている機械学習モデルを指します。 Unity Catalog でモデルを作成するには、ユーザーはカタログまたはスキーマに対する CREATE MODEL 特権を持っている必要があります。 ユーザーには、親カタログに対する USE CATALOG 特権と、親スキーマに対する USE SCHEMA も必要です。

マネージド ストレージ

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

アカウント管理者は、メタストアを手動で作成するときに、お使いのクラウド ストレージ アカウントの Azure Data Lake Storage Gen2 コンテナーまたは Cloudflare R2 バケット内の保存場所を割り当てて、マネージド テーブルとボリュームのメタストアレベルのストレージとして使うことができます。 メタストア レベルのマネージド ストレージの場所が割り当てられている場合、カタログ レベルとスキーマ レベルのマネージド ストレージの場所は省略可能です。 つまり、メタストア レベルのストレージは省略可能であり、Databricks では、論理データ分離のためにカタログ レベルでマネージド ストレージを割り当てることをお勧めします。 「データ ガバナンスとデータ分離の構成要素」を参照してください。

重要

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

マネージド ストレージには、次のプロパティがあります:

  • マネージド テーブルとマネージド ボリュームでは、データ ファイルとメタデータ ファイルがマネージド ストレージに格納されます。
  • マネージド ストレージの場所は、外部テーブルまたは外部ボリュームと重複できません。

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

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

マネージド テーブルとマネージド ボリュームのデータとメタデータを格納するために使用されるマネージド ストレージの場所では、次の規則が使用されます:

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

ストレージの資格情報と外部の場所

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

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

Unity Catalog の ID 管理

Unity Catalog では、Azure 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 カタログのセキュリティ保護可能なオブジェクトは階層構造であり、権限は下位に継承されます。

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

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

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

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

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

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

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

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

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

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

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

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

Unity Catalog の制限事項

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

Note

クラスターが 11.3 LTS より前の Databricks Runtime バージョンで実行されている場合、ここに挙げられていない追加の制限が発生する可能性があります。 Unity Catalog は、Databricks Runtime 11.3 LTS 以降でサポートされています。

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

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

  • Databricks Runtime 13.3 LTS 以上では、既存の Unity Catalog マネージド テーブルから Unity Catalog マネージド テーブルを作成するために、シャロー クローンがサポートされています。 Databricks Runtime 12.2 LTS 以下では、Unity Catalog のシャロー クローンはサポートされていません。 「Unity Catalog テーブルのシャロー クローン」を参照してください。

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

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

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

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

  • Databricks Runtime 13.3 LTS 以降では、Python スカラー UDF がサポートされています。 Databricks Runtime 12.2 LTS 以前では、Spark (applyInPandas と mapInPandas) で 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 イベントに対してのみサポートされています。 メタストアの作成など、ワークスペースに関係なくアカウント レベルで発生するイベントはログに記録されません。

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

  • オブジェクト名は、255 文字以内である必要があります。
  • 次の特殊文字は使用できません:
    • ピリオド (.)
    • 空白 ( )
    • スラッシュ (/)
    • すべての ASCII 制御文字 (16 進数 00 から 1F)
    • DELETE 文字 (16 進数 7F)
  • Unity Catalog では、すべてのオブジェクト名が小文字で格納されます。
  • SQL で UC 名を参照する場合は、バッククォートを使用して、ハイフン (-) などの特殊文字を含む名前をエスケープする必要があります。

Note

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

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

リソース クォータ

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

以下のクォータ値は、Unity Catalog の親 (または先祖) オブジェクトに対して相対的に表されます。

オブジェクト Parent 値
テーブル schema 10000
table メタストア 100000
volume schema 10000
function schema 10000
登録済みのモデル schema 1000
登録済みのモデル メタストア 5000
モデル バージョン 登録済みのモデル 10000
モデル バージョン メタストア 100000
schema catalog 10000
catalog メタストア 1000
つながり メタストア 1000
ストレージの資格情報 メタストア 200
外部の場所 メタストア 500

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