Unity Catalogとは
この記事では、Databricks 上のデータと AI 資産の統合ガバナンス ソリューションである 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オブジェクトモデル
Unity Catalog では、すべてのメタデータがメタストアに登録されます。 任意の Unity Catalog メタストア内のデータベース オブジェクトの階層は 3 つのレベルに分かれており、テーブル、ビュー、ボリューム、モデル、関数を参照するときに 3 レベルの名前空間 ( catalog.schema.table-etc
) として表されます。
メタストア
メタストアは、Unity Catalog 内のメタデータの最上位コンテナーです。 データとAIアセットに関するメタデータと、それらへのアクセスを管理する権限を登録します。 ワークスペースで Unity Catalog を使用するには、Unity Catalog メタストアがアタッチされている必要があります。
ワークスペースがあるリージョンごとに 1 つのメタストアが必要です。 ワークスペースはどのようにしてメタストアにアタッチされますか? 「組織の Unity Catalog を設定する方法」を参照してください。
メタストア内のオブジェクト階層
Unity Catalogメタストアでは、3 レベルのデータベース オブジェクト階層は、スキーマを含むカタログで構成され、スキーマにはテーブルやモデルなどのデータとAIオブジェクトが含まれます。
レベル1:
カタログ は、データ資産を整理するために使用され、通常はデータ分離スキームの最上位レベルとして使用されます。 カタログは多くの場合、組織単位またはソフトウェア開発ライフサイクルの範囲を反映します。 「Databricks のカタログとは何ですか?」を参照してください。
ストレージの資格情報や外部ロケーションなど、データのセキュリティ保護できないオブジェクトは、Unity Catalogでデータガバナンス モデルを管理するために使用されます。これらもメタストアの直下に存在します。 これらについては、「 その他のセキュリティ保護可能なオブジェクト」で詳しく説明します。
レベル2:
スキーマ(データベースとも呼ばれます) には、テーブル、ビュー、ボリューム、AI モデル、および関数が含まれます。 スキーマは、データと AI アセットをカタログよりも細かい論理カテゴリに整理します。 通常、スキーマは単一のユースケース、プロジェクト、またはチーム サンドボックスを表します。 「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 は次のセキュリティ保護可能なオブジェクトを使用してデータへのアクセスも管理します。
サービス資格情報は、外部サービスへのアクセスを提供する長期的なクラウド資格情報をカプセル化します。 「 サービス資格情報を使用して外部クラウド サービスへのアクセスを管理する」を参照してください。
ストレージ資格情報は、クラウド ストレージへのアクセスを提供する長期的なクラウド資格情報をカプセル化します。 「 AWS S3 に接続するためのストレージ認証情報を作成する」を参照してください。
ストレージ資格情報とクラウド ストレージ パスへの参照を含む外部ロケーション。外部ロケーション を使用して、外部テーブルを作成したり、マネージドテーブルとボリュームの マネージドストレージロケーション を割り当てたりできます。 クラウド ストレージを Databricksに接続するための外部ロケーションを作成する、マネージドストレージを使用したデータの分離、およびUnity Catalogでのマネージドストレージの場所の指定を参照してください。
Connections は、レイクハウスフェデレーションを使用してMySQLなどのデータベース システム内の外部データベースへの読み取り専用アクセスを許可する資格情報を表します。 レイクハウスフェデレーションとUnity Catalog 、レイクハウスフェデレーションとは何ですか? 。
クリーン ルームは、複数の参加者が基礎となるデータを相互に共有することなくプロジェクトで共同作業できる、Databricks 管理環境を表します。 「Databricks クリーンルームとは何か?」を参照してください。
Shares は、データ プロバイダーが 1 人以上の受信者と共有するデータと AI アセットの読み取り専用コレクションを表す Delta Sharing オブジェクトです。
受信者: データ プロバイダーから共有を受け取るエンティティを表す Delta Sharing オブジェクトです。
プロバイダーは、受信者とデータを共有するエンティティを表す Delta Sharing オブジェクトです。
Delta Sharingセキュリティ保護可能なオブジェクトの詳細については、 Delta Sharingは何ですか?」を参照してください。
Unity Catalog 内のデータベース オブジェクトやその他のセキュリティ保護可能なオブジェクトへのアクセスの許可と取り消し
セキュリティ保護可能なオブジェクトへのアクセスは、メタストア自体を含め、階層内の任意のレベルで許可および取り消すことができます。 オブジェクトにアクセスすると、アクセスが取り消されない限り、そのオブジェクトのすべての子に同じアクセス権が暗黙的に付与されます。
一般的な ANSI SQL コマンドを使用して、Unity Catalog 内のオブジェクトへのアクセスを許可および取り消すことができます。 例えば:
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のクエリーフェデレーションプラットフォームです。 クエリー フェデレーション という用語は、すべてのユーザーを統一されたシステムに移行しなくても、ユーザーとシステムが複数のサイロ化された Data に対してクエリーを実行できるようにする機能のコレクションを表します。
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 metastoreHive metastoreUnity Catalogは非推奨になっており、Unity Catalog の優れたガバナンス機能とパフォーマンスを活用するには、できるだけ早く のデータを に移行する必要があります。
移行には、次のものが含まれます。
ワークスペースのローカル グループをアカウント レベルのグループに変換します。 Unity Catalog は、アカウント レベルで ID 管理を集中化します。
Hive metastoreで管理されているテーブルとビューをUnity Catalogに移行します。
クエリとジョブを更新して、古い テーブルではなく新しいUnity Catalog Hive metastoreテーブルを参照するようにします。
移行の管理に役立つのは、次の点です。
Databricks Labs プロジェクトである UCX は、Unity Catalog 以外のワークスペースを Unity Catalog にアップグレードするのに役立つツールを提供します。 UCX は、大規模な移行に適しています。 「UCX ユーティリティを使用してワークスペースを Unity Catalog にアップグレードする」を参照してください。
移行するテーブルの数が少ない場合は、Databricks が提供する UI ウィザードと SQL コマンドを使用できます。 「Hive テーブルとビューを Unity Catalog にアップグレードする」を参照してください。
同じワークスペースでHive metastoreのテーブルをUnity Catalogのデータベース オブジェクトと一緒に使用する方法については、 Unity Catalogと従来のHive metastoreの操作」を参照してください。
Unity Catalogの要件と制限
Unity Catalog 、以下で説明する特定の種類のコンピュートおよびファイル形式が必要です。 また、以下に、すべての Databricks Runtime バージョンの Unity Catalog で完全にサポートされていない Databricks 機能もいくつか示します。
リージョンのサポート
すべてのリージョンで Unity Catalog がサポートされています。 詳細については、「Databricks のクラウドとリージョン」を参照してください。
コンピュートの要件
Unity Catalogは、Databricks Runtime 11.3 LTS以上を実行するクラスターでサポートされます。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内のすべてのオブジェクト名には、次の制限が適用されます。
オブジェクト名は 255 文字を超えることはできません。
次の特殊文字は使用できません。
期間 (
.
)スペース (
スラッシュ (
/
)すべての ASCII 制御文字 (00-1F 16 進数)
削除文字 (7F 16 進数)
Unity Catalog は、すべてのオブジェクト名を小文字で格納します。
SQL で UC 名を参照する場合は、バッククォートを使用して、ハイフン (
-
) などの特殊文字を含む名前をエスケープする必要があります。
注
列名には特殊文字を使用できますが、特殊文字を使用する場合は、すべての SQL ステートメントで名前をバッククォートでエスケープする必要があります。 Unity Catalog では列名の大文字と小文字の区別が保持されますが、 Unity Catalog テーブルに対するクエリーでは大文字と小文字が区別されません。
制限
Unity Catalog には以下の制限があります。 これらの一部は、古いDatabricks Runtimeバージョンおよびコンピュート アクセス モードに固有のものです。
構造化ストリーミング ワークロードには、Databricks Runtime とアクセス モードに応じて追加の制限があります。 Unity Catalogのコンピュート アクセス モードの制限を参照してください。
Databricks は、このリストを定期的に縮小する新しい機能をリリースします。
ワークスペースで以前に作成されたグループ (つまり、ワークスペース レベルのグループ) は、 Unity Catalog
GRANT
ステートメントでは使用できません。 これは、ワークスペース全体にまたがるグループの一貫したビューを確保するためです。GRAN
T ステートメントでグループを使用するには、アカウント レベルでグループを作成し、プリンシパルまたはグループ管理の自動化 ( SCIM 、 Okta およびMicrosoft Entra ID コネクタ、 Terraformなど) を更新して、ワークスペース エンドポイントの代わりにアカウント エンドポイントを参照します。 。 「アカウント グループとワークスペース ローカル グループの違い」を参照してください。R のワークロードは、 Databricks Runtime 15.3 以下を実行しているコンピュート上の行レベルまたは列レベルのセキュリティのための動的ビューの使用をサポートしていません。
動的ビューをクエリする R のワークロードには、 Databricks Runtime 15.4 LTS 以降を実行しているシングル ユーザー コンピュート リソースを使用します。 このようなワークロードには、サーバレス コンピュートが有効になっているワークスペースも必要です。 詳細については、「 シングル ユーザー コンピュートでのきめ細かなアクセス制御」を参照してください。
12.2 Unity Catalog以下を実行しているコンピュートのDatabricks RuntimeLTS では、浅いクローン機能はサポートされていません。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 リソース クォータ APIsを使用して監視できます。 「Unity Catalog のリソース クォータの使用状況を監視する」を参照してください。