Unity Catalog とは何ですか?

この記事では、Databricks 上のデータと AI アセットの統合ガバナンス ソリューションである Unity Catalog について説明します。主要な概念について説明し、Unity Catalog を使用してデータを管理する方法の概要を示します。

注記

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

Unity Catalog の概要

Unity Catalog は、 Databricks ワークスペース全体でアクセス制御、監査、リネージ、品質モニタリング、およびデータディスカバリー機能を提供する一元化されたデータカタログです。

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

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

メタストア

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

Hive metastoreとは異なり、Unity Catalog メタストアはサービス境界ではなく、マルチテナント環境で実行され、特定の Databricks アカウントのリージョンごとにデータを分離するための論理的な境界を表します。

Unity Catalog オブジェクト モデル

Unity Catalog メタストアでは、3 レベルのデータベース オブジェクト階層は、スキーマを含むカタログで構成され、スキーマにはデータと AI オブジェクト (テーブルやモデルなど) が含まれます。この階層は、テーブル、ビュー、ボリューム、モデル、および関数を参照するときに、3 レベルの名前空間 (catalog.schema.table-etc) として表されます。

レベル1:

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

レベル2:

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

レベル3:

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

外部データソースへのアクセスを管理するために Unity Catalog が使用するセキュリティ保護可能なオブジェクト

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

• ストレージ資格情報 は、クラウド ストレージへのアクセスを提供する長期的なクラウド資格情報をカプセル化します。 「 AWS S3 に接続するためのストレージ認証情報を作成する」を参照してください。
• 外部ロケーション : クラウド ストレージ パスと、それにアクセスするために必要なストレージ資格情報の両方を参照します。 外部ロケーション を使用して、外部テーブルを作成したり、マネージドテーブルとボリュームの管理 ストレージロケーション を割り当てたりできます。 クラウドストレージをDatabricksに接続するための外部ロケーションの作成、 クラウドストレージとデータ分離、およびUnity Catalogでの管理対象ストレージロケーションの指定を参照してください。
• 接続 は、 MySQL を使用した などのデータベース・システム内の外部データベースに読み取り専用アクセスを許可する資格情報を表します。 「レイクハウスフェデレーションとは」を参照してください。
• サービス資格情報 は、外部サービスへのアクセスを提供する長期的なクラウド資格情報をカプセル化します。 サービス資格情報の作成を参照してください。

Unity Catalog が共有アセットへのアクセスを管理するために使用するセキュリティ保護可能なオブジェクト

Unity Catalog では、次のセキュリティ保護可能なオブジェクトを使用して、メタストアまたは組織の境界を越えたデータと AI 資産の共有を管理します。

• クリーンルーム は、複数の参加者が基礎データを共有することなくプロジェクトに協力できる Databricks管理された環境を表しています。 「Databricksクリーンルームとは」をご覧ください。
• 共有 は、データ プロバイダーが 1 人以上の受信者と共有するデータと AI 資産の読み取り専用コレクションを表す Delta Sharing オブジェクトです。
• 受信者 は、データ プロバイダーから共有を受け取るエンティティを表す Delta Sharing オブジェクトです。
• プロバイダー は、受信者とデータを共有するエンティティを表す Delta Sharing オブジェクトです。

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

管理者の役割

次の Databricks 管理者ロールには、デフォルトによって多くの Unity Catalog 権限があります。

• アカウント管理者: メタストアの作成、メタストアへのワークスペースのリンク、ユーザーの追加、メタストアに対する権限の割り当てを行うことができます。
• ワークスペース管理者: ワークスペースにユーザーを追加し、ジョブやノートブックなどの多くのワークスペース固有のオブジェクトを管理できます。 ワークスペースによっては、ワークスペース管理者は、ワークスペースにアタッチされているメタストアに対して多くの特権を持つこともできます。
• メタストア管理者 : このオプションの役割は、メタストア レベルでマネージドテーブルとボリューム ストレージを使用する場合に必要です。 また、リージョン内の複数のワークスペース間でデータを一元的に管理する場合にも便利です。

詳細については、「Unity Catalogの管理者権限」を参照してください。

セキュリティ保護可能なオブジェクトへのアクセスの許可と取り消し

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

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

SQL

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

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

メタストア管理者、オブジェクトの所有者、およびオブジェクトに対する MANAGE privilege を持つユーザーは、アクセスを許可および取り消すことができます。Unity Catalog で特権を管理する方法については、「 Unity Catalog での特権の管理」を参照してください。

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

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

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

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

詳細については、Databricksのデータベースオブジェクトを参照してください。

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

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

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

Databricks 、ほとんどのユースケースでマネージドテーブルとボリュームを推奨しています。これは、 Unity Catalog ガバナンス機能とパフォーマンスの最適化を最大限に活用できるためです。 外部テーブルとボリュームの一般的なユースケースに関する情報については、 Managed and externalテーブル および Managed and external volumesを参照してください。

関連項目は次を参照してください。

• DatabricksにおけるDelta LakeとApache IcebergのUnity Catalog マネージドテーブル
• 外部テーブルに関する作業
• 管理ボリュームと外部ボリューム。

クラウドストレージとデータ分離

Unity Catalog は、主に 2 つの方法でクラウド ストレージを使用します。

• Managed storage : Databricksで作成するマネージドテーブルと管理ボリューム (非構造化、非表形式データ) のデフォルトの場所。 これらの管理されたストレージの場所は、メタストア、カタログ、またはスキーマ レベルで定義できます。管理されたストレージの場所はクラウド プロバイダーで作成しますが、そのライフサイクルは Unity Catalogごとにフルマネージドです。
• 外部テーブルとボリュームが格納されるストレージの場所。これらは、Databricks からのアクセスが Unity Catalog によって管理されているが、データのライフサイクルとファイル レイアウトがクラウド プロバイダーやその他のデータ プラットフォームを使用して管理されているテーブルとボリュームです。通常、外部テーブルまたはボリュームを使用して、既存のデータを Databricks に大量に登録するか、Databricks の外部ツールを使用してデータへの書き込みアクセスも必要とします。

外部ロケーションを使用したクラウドストレージへのアクセスの管理

管理されたストレージの場所と、外部テーブルとボリュームが格納されているストレージの場所はどちらも、 外部ロケーション セキュリティ保護可能なオブジェクトを使用して、 Databricks. 外部ロケーションオブジェクトは、クラウドストレージパスと、それにアクセスするために必要な ストレージ認証情報 を参照します。ストレージ資格情報は、それ自体が、特定のストレージ パスにアクセスするために必要な資格情報を登録する Unity Catalog のセキュリティ保護可能なオブジェクトです。これらのセキュリティ保護可能なリソースを組み合わせることで、ストレージへのアクセスが Unity Catalog によって制御および追跡されるようになります。

以下の図は、1つのストレージ資格情報を共有する4つの外部ロケーションを持つ、単一のクラウドストレージバケットのファイルシステム階層を表しています。

詳細については、「Unity Catalog はクラウド ストレージへのアクセスをどのように管理しますか?」を参照してください。

管理されたストレージの場所の階層

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 では、カタログごとに個別の管理ストレージの場所を割り当てることをお勧めします。

システムは、スキーマからカタログ、メタストアに至るストレージロケーションの階層を評価します。

たとえば、テーブル myCatalog.mySchema.myTable が my-region-metastoreで作成されている場合、このテーブルのストレージロケーションは次のルールに従って決定されます。

1. ロケーションがmySchemaに対して指定されている場合、テーブルはそこに格納されます。
2. ロケーションがmyCatalogに指定されている場合、テーブルはそこに格納されます。
3. myCatalogに指定されているロケーションがない場合は、my-region-metastoreに関連付けられたロケーションに格納されます。

詳細については、「Unity Catalogで管理されたストレージの場所を指定する」を参照してください。

ワークスペースとカタログのバインドを使用した環境の分離

デフォルトにより、カタログ所有者 (およびアカウントで定義されている場合はメタストア管理者) は、同じ Unity Catalog メタストアにアタッチされた複数のワークスペース内のユーザーがカタログにアクセスできるようにすることができます。

多くの場合、組織やコンプライアンスの要件では、個人データなどの特定のデータには特定の環境でのみアクセスできるようにすることが規定されています。また、本番データを開発環境から隔離したり、特定のデータセットやドメインが決して結合されないようにしたい場合もあります。

Databricks では、ワークスペースがプライマリ データ処理環境であり、カタログがプライマリ データ ドメインです。Unity Catalog を使用すると、メタストア管理者、カタログ所有者、および MANAGE アクセス許可を持つユーザーは、カタログを特定のワークスペースに割り当て ("バインド") できます。これらの環境対応バインディングを使用すると、ユーザーに付与されたデータ・オブジェクトに対する特定の権限に関係なく、ワークスペース内で特定のカタログのみを使用可能にすることができます。ただし、ワークスペースを使用してユーザーデータへのアクセスを分離する場合は、カタログへのアクセスをアカウント内の特定のワークスペースに制限して、特定の種類のデータがそれらのワークスペースでのみ処理されるようにすることができます。たとえば、本番運用ワークスペースと開発ワークスペースを分けたり、個人データを処理するために別々のワークスペースが必要な場合があります。 これは、 ワークスペースとカタログのバインド と呼ばれます。「 カタログへのアクセスを特定のワークスペースに制限する」を参照してください。

注記

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

組織の 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ワークスペースを Unity Catalogにアップグレードする方法については、「Databricks ワークスペースを 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では、次のテーブル形式がサポートされています。

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

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

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など) の自動化を更新して、ワークスペース エンドポイントではなくアカウント エンドポイントを参照するようにします。グループソースを参照してください。
• 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 のリソース クォータの使用状況を監視する」を参照してください。

追加のリソース

• Databricks によるデータガバナンス
• Databricks ワークスペースを Unity Catalog にアップグレードする
• Unity Catalogのベストプラクティス