Unity Catalog のベスト プラクティス
このドキュメントでは、 Unity Catalog を使用してデータガバナンスのニーズを最も効果的に満たすための推奨事項について説明します。 Databricksのデータガバナンスの概要については、「Databricksを使用したデータガバナンス」を参照してください。Unity Catalog の概要については、「 Unity Catalog とは」を参照してください。
アイデンティティ
プリンシパル (ユーザー、グループ、およびサービスプリンシパル) は、Databricks セキュリティ保護可能なオブジェクトに対する特権を割り当てるために、 アカウントUnity Catalog レベルで定義する必要があります。Databricks では、SCIM を使用して IdP から Databricks アカウントにプリンシパルをプロビジョニングすることをお勧めします。
おすすめの方法:
-
ワークスペース レベルの SCIM プロビジョニングは避けます (既存のプロビジョニングはオフにします)。ワークスペースに直接プロビジョニング プリンシパルは、 Unity Catalogが有効になっていない従来のワークスペース用に予約する必要があります。 プロビジョニングは、アカウントレベルで完全に管理する必要があります。
-
IdP でグループを定義して管理します。これらは、組織グループの定義と一致している必要があります。
グループは、ユーザーやサービスプリンシパルとは異なる動作をします。 ワークスペースに追加したユーザーとサービスプリンシパルは Databricks アカウントと自動的に同期されますが、ワークスペース レベルのグループは同期されません。 ワークスペースローカルグループがある場合は、できればIdPでレプリケートし(必要な場合)、アカウントにプロビジョニングすることで、それらをアカウントに手動で移行する必要があります。
-
グループを効果的に使用して、データやその他の Unity Catalog セキュリティ保護可能なリソースへのアクセスを許可できるように、グループを設定します。可能な限り、ユーザーへの直接の付与は避けてください。
-
グループを使用して、ほとんどのセキュリティ保護可能なオブジェクトに所有権を割り当てます。
-
アカウントまたはワークスペースにユーザーを手動で追加することは避けてください。Databricks でグループを変更するのを避ける: IdP を使用してください。
-
サービスプリンシパル を使用してジョブを実行します。 サービスプリンシパル enable ジョブ オートメーション. 本番運用に書き込むジョブをユーザーで実行してしまうと、誤って本番運用のデータを上書きしてしまうおそれがあります。
詳細については、「ユーザー、サービスプリンシパル、グループを管理する」および「SCIMを使用して ID プロバイダーからユーザーとグループを同期する」を参照してください。
管理者の役割と強力な特権
管理者ロールと、 ALL PRIVILEGES
や MANAGE
などの強力な権限を割り当てるには、注意が必要です。
- アカウント管理者、ワークスペース管理者、メタストア管理者を割り当てる前に、その権限を理解してください。「Unity Catalog の管理者特権」を参照してください。
- 可能な限り、これらのロールをグループに割り当てます。
- メタストアの管理者はオプションです。必要な場合にのみ割り当ててください。ガイダンスについては、「 (省略可能) メタストア管理者ロールを割り当てる」を参照してください。
- オブジェクト所有権をグループに割り当てます (特に、オブジェクトが本番運用で使用される場合)。 オブジェクトの作成者は、その最初の所有者です。クリエイターは、所有権を適切なグループに再割り当てする必要があります。
- メタストアの管理者、所有者、およびオブジェクトに対する
MANAGE
権限を持つユーザーのみが、そのオブジェクトに対する権限を付与できます。親カタログと親スキーマの所有者は、カタログまたはスキーマ内のすべてのオブジェクトに対する権限を付与することもできます。所有権とMANAGE
特権の割り当てには寛大にしてください。 MANAGE
とEXTERNAL USE SCHEMA
を除くすべての特権を含むALL PRIVILEGES
の割り当てには注意してください。
特権の割り当て
Unity Catalog のセキュリティ保護可能なオブジェクトは階層的であり、特権は下位に継承されます。この継承階層を使用して、効果的な特権モデルを開発します。
おすすめの方法:
-
USE CATALOG
(またはUSE SCHEMA
)とBROWSE
の違いを理解します。USE CATALOG | SCHEMA
カタログまたはスキーマ内のデータを表示する機能を付与します。これらの権限だけでは、カタログまたはスキーマ内のオブジェクトに対するSELECT
やREAD
は付与されませんが、ユーザーにアクセス権を付与するための前提条件となります。これらの権限は、カタログまたはスキーマ内のデータを表示できるユーザーのみに付与します。USE CATALOG | SCHEMA
は、カタログまたはスキーマへのアクセスを制限することで、オブジェクトの所有者 (テーブル作成者など) が、アクセス権を持つべきでないユーザーにそのオブジェクト (テーブル) へのアクセスを誤って割り当てるのを防ぎます。通常、チームごとにスキーマを作成し、そのチームにのみUSE SCHEMA
とCREATE TABLE
を付与します (親カタログのUSE CATALOG
も併せて)。BROWSE
カタログ・レベルで広く付与して、ユーザーがカタログ内のオブジェクトに関連付けられたメタデータを表示できるようにすることができます。
-
オブジェクトの所有権と
MANAGE
権限の違いを理解します。- オブジェクトの所有者は、テーブル上の
SELECT
やMODIFY
など、オブジェクトに対するすべての権限を持ち、セキュリティ保護可能なオブジェクトに対する権限を他のプリンシパルに付与したり、所有権を他のプリンシパルに譲渡したりする権限も持ちます。 - 所有者は、オブジェクトの所有権機能を他のプリンシパルに委任する
MANAGE
権限を付与できます。 - カタログとスキーマの所有者は、カタログまたはスキーマ内の任意のオブジェクトの所有権を譲渡できます。
- 所有権を設定するか、すべてのオブジェクトに対する
MANAGE
権限を、オブジェクトに対する付与の管理を担当するグループに付与することをお勧めします。
- オブジェクトの所有者は、テーブル上の
-
サービスプリンシパルの本番運用テーブルへの直接
MODIFY
アクセスを予約します。
詳細については、「Unity Catalogでの権限の管理」を参照してください。
メタストア
メタストアを作成および管理するためのルールとベスト プラクティスを次に示します。
-
メタストアは、リージョンごとに 1 つだけ持つことができます。そのリージョン内のすべてのワークスペースは、そのメタストアを共有します。リージョン間でデータを共有するには、「 リージョン間およびプラットフォーム間の共有」を参照してください。
-
メタストアは、地域的な分離を提供しますが、データ分離のデフォルト単位として意図されたものではありません。 通常、データの分離はカタログ・レベルから始まります。ただし、より一元化されたガバナンス モデルを使用する場合は、メタストア レベルの管理ストレージを作成できます。推奨事項については、「 マネージド ストレージ」を参照してください。
-
メタストア管理者ロールは省略可能です。オプションのメタストア管理者を割り当てるかどうかの推奨事項については、「 管理者ロールと強力な特権」を参照してください。
頻繁にアクセスするテーブルを外部テーブルとして複数のメタストアに登録しないでください。 登録すると、メタストア A への書き込みの結果としてスキーマ、テーブル プロパティ、コメント、およびその他のメタデータが変更されても、メタストア B にはまったく登録されません。また、 Databricks コミット サービスで整合性の問題が発生する可能性があります。
カタログとスキーマ
カタログは、一般的な Unity Catalog データガバナンス モデルにおけるデータ分離の主要な単位です。 スキーマは、組織のレイヤーを追加します。
カタログとスキーマの使用に関するベスト プラクティス:
- データと AI オブジェクトを、組織の部門とプロジェクトを反映したカタログとスキーマに整理します。多くの場合、これは、カタログが環境スコープ、チーム、ビジネスユニット、またはこれらの組み合わせに対応していることを意味します。これにより、権限階層を使用してアクセスを効果的に管理しやすくなります。
- 作業環境とデータの両方に同じ分離要件がある場合は、カタログを特定のワークスペースにバインドできます。必要な場合は、限られたワークスペースのセットにスコープを設定できるカタログを作成します。
- 本番運用カタログとスキーマの所有権は、常に個々のユーザーではなくグループに割り当てます。
USE CATALOG
とUSE SCHEMA
は、それらに含まれるデータを表示またはクエリできる必要があるユーザーのみに付与します。
カタログおよびスキーマに対する権限の付与に関するアドバイスについては、 権限の割り当てを参照してください。
管理ストレージ
マネージドテーブルとボリューム、ライフサイクルがフルマネージド by Unity Catalogであるオブジェクトは、 マネージド ストレージ と呼ばれるデフォルトのストレージの場所に格納されます。 管理ストレージは、メタストア、カタログ、またはスキーマ レベルで設定できます。データは、階層内で使用可能な最も低い場所に格納されます。詳細については、「 管理されたストレージの場所の階層 」と 「Unity Catalog で管理されたストレージの場所を指定する」を参照してください。
管理されたストレージの場所に関するおすすめの方法:
-
カタログ・レベルのストレージを、データ分離の主要単位として優先します。
メタストア レベルのストレージは、初期の Unity Catalog 環境で必要でしたが、現在は必要ありません。
-
メタストア レベルの管理場所を作成する場合は、専用のバケットを使用します。
-
Unity Catalog の外部からアクセスできるバケットは使用しないでください。
外部サービスまたはプリンシパルがマネージドストレージの場所のデータにアクセスすると、マネージドテーブルとボリュームの Unity Catalog、アクセス制御、および監査可能性が損なわれます。
-
DBFSルート ファイル システムで使用されていたバケット、または使用されていたバケットは再利用しないでください。
管理テーブルと外部テーブル
マネージドテーブル は フルマネージド by Unity Catalog、つまり、 Unity Catalog は各マネージドテーブルのガバナンスと基になるデータ ファイルの両方を管理します。 それらは常に Delta または Apache Iceberg 形式です。
外部テーブル は、Databricks からのアクセスが Unity Catalog によって管理されているが、データ ライフサイクルとファイル レイアウトがクラウド プロバイダーやその他のデータ プラットフォームを使用して管理されているテーブルです。Databricksで外部テーブルを作成する場合は、そのロケーションを指定します。ロケーションは、Unity Catalog 外部ロケーション で定義されたパス上にある必要があります。
マネージドテーブルを使用します:
-
ほとんどのユースケースで対応します。Databricks マネージドテーブルとボリュームは、次のような Unity Catalog ガバナンス機能とパフォーマンスの最適化を最大限に活用できるため、マネージドテーブルとボリュームを推奨しています。
- 自動圧縮
- 自動最適化
- メタデータの読み取りの高速化 (メタデータのキャッシング)
- インテリジェントなファイルサイズの最適化
新しい Databricks 機能は、マネージドテーブルを優先します。
-
すべての新しいテーブル用。
外部テーブルを使用する場合:
-
すでにそれらを使用していて、 Hive metastore から Unity Catalogにアップグレードする場合。
- 外部テーブルを使用すると、データを移動せずに、迅速かつシームレスな「ワンクリック」アップグレードを提供できます。
- Databricks では、最終的には外部テーブルをマネージドテーブルに移行することをお勧めします。
-
このデータにディザスタリカバリ要件がある場合、マネージドテーブルでは満たすことができません。
マネージドテーブルは、同じクラウド内の複数のメタストアにまたがって登録することはできません。
-
外部のリーダーまたはライターが Databricks の外部からデータを操作できる必要がある場合。
通常、Unity Catalog に登録されている外部テーブルに対しても、外部からのアクセスを許可しないようにする必要があります。これにより、 Unity Catalog アクセス制御、監査、およびリネージがバイパスされます。 マネージドテーブルを使用し、 Delta Sharingを使用してリージョン間またはクラウドプロバイダー間でデータを共有することをお勧めします。 外部テーブルへの外部アクセスを許可する必要がある場合は、読み取りに制限し、すべての書き込みは Databricks と Unity Catalog を介して行われます。
-
Parquet、Avro、ORC などの非 Delta または Non-Iceberg テーブルをサポートする必要があります。
外部テーブルの使用に関するその他の推奨事項:
- スキーマごとに1つの外部ロケーションを使って外部テーブルを作成することをお勧めします。
- Databricks は、一貫性の問題のリスクがあるため、テーブルを複数のメタストアの外部テーブルとして登録しないことを強くお勧めします。 たとえば、1 つのメタストアでスキーマを変更しても、2 番目のメタストアには登録しません。 メタストア間でデータを共有するには、 Delta Sharing を使用します。 「 クロスリージョンおよびクロスプラットフォーム共有」を参照してください。
「Databricks テーブルの概要」も参照してください。
管理ボリュームと外部ボリューム
マネージドボリューム はフルマネージド by Unity Catalog、つまり、クラウドプロバイダーアカウント内のボリュームのストレージの場所へのアクセスを Unity Catalog が管理します。 外部ボリューム は、Databricks の外部で管理されているストレージの場所にある既存のデータを表しますが、Databricks 内からのアクセスを制御および監査するために Unity Catalog に登録されています。Databricksで外部ボリュームを作成する場合は、そのロケーションを指定します。ロケーションは、Unity Catalog 外部ロケーション で定義されたパス上にある必要があります。
管理ボリュームを使用する:
- ほとんどのユースケースで、Unity Catalog のガバナンス機能を最大限に活用します。
COPY INTO
または CTAS (CREATE TABLE AS
) ステートメントを実行せずに、ボリューム内のファイルからテーブルを作成する場合。
外部ボリュームを使用する:
- 外部システムによって生成された生データのランディングエリアを登録し、 ETL パイプラインなどのデータエンジニアリング活動の初期段階での処理を支援すること。
- インジェスト用のステージング場所を登録するには (たとえば、 Auto Loader、
COPY INTO
、または CTAS ステートメントを使用します)。 - マネージドボリュームがオプションではない場合に、データサイエンティスト、データアナリスト、機械学習エンジニアが探索的データ分析やその他のデータサイエンスタスクの一部として使用できるファイルストレージの場所を提供します。
- Databricks監視システムや デバイスによってキャプチャされた大量の非構造化データ(画像、オーディオ、ビデオ、PDFファイルなど)や、ローカルの依存関係管理システムやIoT パイプラインからエクスポートされたライブラリファイル(JARおよびPython wheel ファイル)など、他のシステムによって生成およびクラウドストレージに生成および保存された任意のファイルにCI/CD ユーザーがアクセスできるようにするため。
- 管理対象ボリュームがオプションでない場合に、ロギング・ファイルやチェックポイント・ファイルなどの運用データを保管する場合。
外部ボリュームの使用に関するその他の推奨事項:
- Databricksでは、1つのスキーマ内の1つの外部ロケーションから外部ボリュームを作成することをお勧めします。
データを別の場所にコピーする取り込みのユースケース ( Auto Loader や COPY INTO
など) では、外部ボリュームを使用します。 外部テーブルは、コピーを使わずにテーブルとしてデータをクエリする場合に使用します。
「管理ボリュームと外部ボリューム」および「外部ロケーション」も参照してください。
外部ロケーション
外部ロケーション Securable Objectsは、ストレージ資格情報とストレージ パスを組み合わせることで、ストレージ アクセスの強力な制御と監査可能性を提供します。 外部ロケーションとして登録されたバケットにユーザーが直接アクセスすることを防ぐことが重要で、 Unity Catalogによるアクセス制御をバイパスします。
外部ロケーションを効果的に使用するには:
-
外部ロケーションとして使用されているバケットに直接アクセスできるユーザーの数を制限してください。
-
ストレージアカウントが外部ロケーションとしても使用されている場合は、 DBFS にマウントしないでください。 は、Catalog Explorer Databricksを使用して、クラウドストレージの場所のマウントを の外部ロケーションに移行することをお勧めします。Unity Catalog
-
外部ロケーションを作成する権限を付与するのは、 Unity Catalog とクラウド ストレージ間の接続を設定するタスクを持つ管理者、または信頼できるデータ エンジニアのみです。
外部ロケーションは、 Unity Catalog 内からクラウドストレージ内の広範な場所、たとえば、バケットまたはコンテナ全体 (s3://mycompany-hr-prod) や広範なサブパス (s3://mycompany-hr-prod/unity-catalog) へのアクセスを提供します。 その意図は、クラウド管理者がいくつかの外部ロケーションの設定に関与し、それらのロケーションの管理責任を組織内の Databricks 管理者に委任できるようにすることです。 その後、 Databricks 管理者は、登録する external volumes または external table を外部ロケーションの下の特定のプレフィックスで指定することにより、外部ロケーションをより詳細な権限を持つ領域にさらに整理できます。
外部ロケーションは非常に包括的であるため、Databricksでは、Unity Catalogとクラウドストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみ
CREATE EXTERNAL LOCATION
アクセス許可を付与することをお勧めします。他のユーザーにより詳細なアクセスを提供するために、Databricksでは、外部ロケーションの上に外部テーブルまたはボリュームを登録し、ボリュームまたはテーブルを使用してデータへのアクセス権をユーザーに付与することをお勧めします。テーブルとボリュームはカタログとスキーマの子であるため、カタログ管理者またはスキーマ管理者は、アクセス許可を最終的に制御できます。また、外部ロケーションを特定のワークスペースにバインドすることで、外部ロケーションへのアクセスを制御することもできます。 (オプション)特定のワークスペースに外部ロケーションを割り当てるを参照してください。
-
外部ロケーションに対する一般的な
READ FILES
権限やWRITE FILES
権限をエンドユーザーに付与しないでください。ユーザーは、テーブル、ボリューム、または管理された場所を作成する以外に外部ロケーションを使用しないでください。 データサイエンスやその他の表形式以外のデータユースケースのパスベースのアクセスに外部ロケーションを使用しないでください。
表形式以外のデータへのパスベースのアクセスには、ボリュームを使用します。ボリューム パスの下のデータへのクラウド URI アクセスは、ボリュームが格納されている外部ロケーションで付与される特権ではなく、ボリュームで付与される特権によって制御されます。
ボリュームを使用すると、 SQL コマンド、dbutils、 Spark APIs、 REST APIs、 Terraformを使用してファイルを操作できます。また、ファイルのブラウズ、アップロード、ダウンロードを行うためのユーザ・インタフェースも使用できます。 さらに、ボリュームは、
/Volumes/<catalog_name>/<schema_name>/<volume_name>/
の下のローカル ファイル システム上でアクセス可能な FUSE マウントを提供します。FUSEマウントを使用すると、 data scientists エンジニアや ML エンジニアは、多くの機械学習やオペレーティングシステムのライブラリで必要とされているように、ローカルファイルシステムにあるかのようにファイルにアクセスできます。外部ロケーションにあるファイルへの直接アクセスを許可する必要がある場合(たとえば、ユーザーが外部テーブルまたはボリュームを作成する前にクラウドストレージ内のファイルを探索する場合)、
READ FILES
を付与できます。WRITE FILES
を付与するユースケースはまれです。 -
パスの重複の競合を回避する:外部ロケーションのルートに外部ボリュームまたはテーブルを作成しないでください。
外部ロケーションのルートで外部ボリュームまたはテーブルを作成する場合、外部ロケーションに追加の外部ボリュームまたはテーブルを作成することはできません。代わりに、外部ロケーション内のサブディレクトリに外部ボリュームまたはテーブルを作成します。
外部ロケーションは、次の目的でのみ使用してください。
- 外部テーブルとボリュームを登録するには、
CREATE EXTERNAL VOLUME
コマンドまたはCREATE TABLE
コマンドを使用します。 - ロケーションを管理ストレージとして登録する
CREATE MANAGED STORAGE
特権は前提条件です。 - 特定のプレフィックスで外部テーブルまたはボリュームを作成する前に、クラウドストレージ内の既存のファイルを探索します。
READ FILES
特権は前提条件です。この権限は慎重に割り当ててください。詳細については、前のリストの推奨事項を参照してください。
外部ロケーション vs. 外部ボリューム
ボリュームがリリースされる前は、一部の Unity Catalog 実装では、データ探索のために外部ロケーションに直接アクセス READ FILES
割り当てられていました。 構造化データ、半構造化データ、非構造化データなど、あらゆる形式でファイルを登録する ボリュームを使用できるため、テーブル、ボリューム、または管理された場所を作成する以外に外部ロケーションを使用する理由はまったくありません。 外部ロケーションを使用する場合とボリュームを使用する場合の詳細については、「 管理ボリュームと外部ボリューム」 および 「外部ロケーション」を参照してください。
地域間およびプラットフォーム間の共有
メタストアは、リージョンごとに 1 つだけ持つことができます。異なるリージョンのワークスペース間でデータを共有する場合は、Databricks-to-Databricks Delta Sharingを使用します。
おすすめの方法:
- 単一リージョンのメタストアは、開発、テスト、運用、販売、マーケティングなど、すべてのソフトウェア開発ライフサイクルのスコープとビジネスユニットに使用します。頻繁な共有データ アクセスを必要とするワークスペースが同じリージョンに配置されていることを確認します。
- クラウド リージョン間またはクラウド プロバイダー間で Databricks-to-Databricks Delta Sharing を使用します。
- Delta Sharing は、アクセス 頻度の低いテーブルに使用します。これは、クラウド リージョンからクラウド リージョンへのエグレス料金を負担するためです。頻繁にアクセスされるデータをリージョンまたはクラウド プロバイダー間で共有する必要がある場合は、「 Delta Sharing のエグレス コストの監視と管理 (プロバイダー向け)」を参照してください。
Databricks-to-Databricks共有を使用するときは、次の制限に注意してください。
- リネージグラフはメタストアレベルで作成され、リージョンやプラットフォームの境界を越えることはありません。 これは、リソースが同じ Databricks アカウント内のメタストア間で共有されている場合にも当てはまります: ソース からのリネージ情報は宛先に表示されず、その逆も同様です。
- アクセス制御はメタストア レベルで定義され、リージョンやプラットフォームの境界を越えることはありません。リソースに特権が割り当てられており、そのリソースがアカウント内の別のメタストアと共有されている場合、そのリソースに対する特権は宛先共有には適用されません。デスティネーション共有に対する権限を付与する必要があります。
コンピュートの構成
Databricks では、コンピュート ポリシーを使用して、一連のルールに基づいてクラスタリングを構成する機能を制限することをお勧めします。 コンピュート ポリシーを使用すると、ユーザーが Unity Catalog 対応クラスタリング、特に標準アクセス モード (以前の共有アクセス モード) または専用アクセス モード (以前のシングルユーザーまたは割り当てられたアクセス モード) を使用するクラスタリングを作成するように制限できます。
これらのアクセス・モードのいずれかを使用するクラスタリングのみが、 Unity Catalogのデータにアクセスできます。 すべてのサーバレス コンピュートと DBSQL コンピュートは の をサポートしています Unity Catalog。
Databricks では、すべてのワークロードに対して標準アクセス モードが推奨されます。専用アクセスモードは、必要な機能が標準アクセスモードでサポートされていない場合にのみ使用してください。「アクセスモード」を参照してください。