Unity Catalogのベストプラクティス

本文書では、データガバナンスのニーズを満たすためにUnity CatalogとDelta Sharingを使用するための推奨事項を説明します。

Unity Catalog は、Databricks プラットフォーム上のデータと AI のためのきめ細かなガバナンス ソリューションです。 データアクセスを一元的に管理および監査する場所を提供することで、データのセキュリティとガバナンスを簡素化します。 Delta Sharing は、Databricks のデータを組織外のユーザーと共有できる安全なデータ共有プラットフォームです。 Unity Catalog を使用して、共有動作を管理および監査します。

データガバナンスとデータ分離の構成要素

組織に適したデータガバナンスモデルとデータ分離計画を開発するには、Databricksでデータガバナンスソリューションを作成するときに利用できる主要な構成要素を理解することが役立ちます。

次の図は、Unity Catalog のプライマリ データ階層を示しています (一部のセキュリティ保護可能なオブジェクトは、カタログで管理されるオブジェクトの階層を強調するために淡色表示されています)。

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

その階層内のオブジェクトには、次のものが含まれます:

  • Metastore:Metastoreは、Unity Catalog内のオブジェクトの最上位のコンテナです。Metastoreはアカウントレベルで存在し、Databricksのデータガバナンスモデルのピラミッドの頂点として機能します。

    Metastoreは、データ資産(テーブル、ビュー、ボリューム)と、それらへのアクセスを制御する権限を管理します。Databricksアカウント管理者は、オペレーションするリージョンごとにMetastoreを作成し、同じリージョン内のDatabricksワークスペースに割り当てることができます。Metastore管理者は、Metastore内のすべてのオブジェクトを管理できます。Metastoreに登録されているテーブルに直接読み書きすることはできませんが、データオブジェクトの所有権を譲渡できるため、間接的にアクセスできます。

    デフォルトでは、特定のMetastoreの物理ストレージは、アカウント内の他のMetastoreのストレージから分離されています。

    Metastoreは地域の分離を提供しますが、データの分離単位としては意図されていません。データの分離は、カタログレベルで開始する必要があります。

  • カタログ:カタログは、Unity Catalog Metastoreによって管理されるデータ階層(カタログ > スキーマ > テーブル/ビュー/ボリューム)の最上位レベルです。これらは、典型的なDatabricksデータガバナンスモデルにおけるデータ分離の主要な単位として意図されています。

    カタログはスキーマの論理グループを表し、通常はデータアクセス要件によって制限されます。カタログは、多くの場合、組織単位またはソフトウェア開発ライフサイクルの範囲を反映しています。たとえば、本番データ用のカタログと開発データ用のカタログ、または非顧客データ用のカタログと機密性の高い顧客データ用のカタログを選択できます。

    カタログは、メタストア レベルで格納することも、親メタストアの残りの部分とは別に格納するようにカタログを構成することもできます。 ワークスペースで Unity Catalog が自動的に有効になった場合、メタストア レベルのストレージは存在しないため、カタログを作成するときにストレージの場所を指定する必要があります。

    カタログがDatabricksデータガバナンスモデルにおけるデータ分離の主要な単位である場合、ワークスペースはデータ資産をオペレーションするための主要な環境です。Metastore管理者とカタログ所有者は、ワークスペースとは独立してカタログへのアクセスを管理したり、カタログを特定のワークスペースにバインドして、特定の種類のデータがそれらのワークスペースでのみ処理されるようにしたりできます。たとえば、実稼働ワークスペースと開発ワークスペースを個別に用意したり、個人データを処理するためのワークスペースを個別に用意したりすることが必要な場合があります。

    既定では、セキュリティ保護可能なオブジェクトのアクセス許可は、そのオブジェクトの子によって継承され、カタログは階層の最上位に配置されます。これにより、データの既定のアクセスルールを設定し、階層の各レベルで必要な場合にのみ異なるルールを指定することが容易になります。

  • スキーマ(データベース):データベースとも呼ばれるスキーマは、テーブル形式のデータ(テーブルとビュー)、非テーブル形式のデータ(ボリューム)、関数、および機械学習モデルを論理的にグループ化したものです。これらは、カタログよりも詳細にデータへのアクセスを整理および制御する方法を提供します。通常、これらは単一のユースケース、プロジェクト、またはチームのサンドボックスを表します。

    スキーマは、親カタログと同じ物理ストレージに保存することも、親カタログの残りの部分とは別に保存されるようにスキーマを構成することもできます。

    Metastore管理者、親カタログ所有者、およびスキーマ所有者は、スキーマへのアクセスを管理できます。

  • テーブル:テーブルは、Unity Catalogの3レベルの名前空間の3番目のレイヤーに存在します。テーブルにはデータ行が格納されています。

    Unity Catalogを使用すると、マネージドテーブル外部テーブルを作成できます。

    管理対象テーブルの場合、Unity Catalogはライフサイクルとファイルレイアウトを完全に管理します。既定では、マネージドテーブルは、Metastoreの作成時に設定したルートストレージの場所に格納されます。代わりに、管理テーブルのストレージをカタログレベルまたはスキーマレベルで分離することを選択できます。

    外部テーブルは、Unity Catalogではなく、クラウドプロバイダーやその他のデータプラットフォームを使用してデータライフサイクルとファイルレイアウトが管理されるテーブルです。通常、大量の既存データを登録する場合、またはDatabricksクラスターおよびDatabricks SQLウェアハウスの外部のツールを使用してデータへの書き込みアクセスも必要な場合は、外部テーブルを使用します。外部テーブルがUnity Catalog Metastoreに登録されると、マネージドテーブルの場合と同様に、そのテーブルへのDatabricksアクセスを管理および監査できます。

    親カタログ所有者とスキーマ所有者は、Metastore管理者と同様に、(間接的に)テーブルへのアクセスを管理できます。

  • ビュー:ビューは、Metastore内の1つ以上のテーブルとビューから派生した読み取り専用オブジェクトです。

  • 行と列: 行レベルおよび列レベルのアクセスは、データマスキングと共に、動的ビューまたは行フィルターと列マスクを使用して付与されます。 ダイナミック ビューは読み取り専用です。

  • ボリューム:ボリュームは、Unity Catalogの3階層ネームスペースの第3層に存在します。これらのボリュームは非表形式のデータを管理します。ボリュームを使用して、構造化データ、半構造化データ、非構造化データなど、あらゆる形式のファイルを保存、整理、アクセスできます。ボリューム内のファイルをテーブルとして登録することはできません。

データ分離モデルを計画する

組織がDatabricksのようなデータプラットフォームを使用する場合、多くの場合、環境間(開発と運用など)または組織の運用単位間にデータ分離境界を設ける必要があります。

分離基準は組織によって異なる場合がありますが、通常は次のことが期待されています:

  • ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセスできる。

  • データは、指定された人物またはチームのみが管理できる。

  • データはストレージ内で物理的に分離されている。

  • データは指定された環境でのみアクセスできる。

データ分離の必要性により、環境がサイロ化され、データガバナンスとコラボレーションの両方が不必要に困難になる可能性があります。Databricksは、統一されたデータガバナンスプラットフォームを維持しながら、多数のデータ分離オプションを提供するUnity Catalogを使用してこの問題を解決します。このセクションでは、Databricksで利用できるデータ分離オプションと、集中型データガバナンスモデルを好むか、分散型データガバナンスモデルを好むかに応じたその使用方法について説明します。

ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセスできる

ほとんどの組織では、内部要件や規制要件に基づいて、データアクセスに関する厳しい要件が定められています。安全性を確保しなければならないデータの典型例としては、従業員の給与情報やクレジットカードの決済情報などがあります。この種の情報へのアクセスは通常厳しく管理され、定期的に監査されます。Unity Catalogは、このような業界標準を満たすために、カタログ内のデータ資産をきめ細かく制御します。Unity Catalogが提供するコントロールにより、ユーザーは閲覧およびクエリーする権利があるデータのみを閲覧およびクエリーすることができます。

データは指定された人またはチームのみが管理できる

Unity Catalogを使用すると、集中型ガバナンスモデルと分散型ガバナンスモデルのどちらかを選択できます。

集中管理モデルでは、ガバナンス管理者はMetastoreの所有者であり、あらゆるオブジェクトの所有権を取得し、権限を付与および取り消すことができます。

分散ガバナンスモデルでは、カタログまたはカタログのセットがデータドメインとなります。そのカタログのオーナーは、すべてのアセットを作成して所有し、そのドメイン内のガバナンスを管理することができます。あるドメインの所有者は、他のドメインの所有者から独立して活動することができます。

データドメインとしてMetastoreを選択するかカタログを選択するかに関係なく、DatabricksではグループをMetastore管理者またはカタログ所有者として設定することを強くお勧めします。

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 内のデータをより詳細なレベルで整理できます。

このようなストレージの分離が不要な場合は、メタストア レベルでストレージの場所を設定できます。 その結果、この場所は、メタストア内のカタログとスキーマにまたがってマネージド テーブルとボリュームを格納するための既定の場所として機能します。

システムは、スキーマからカタログ、メタストアまでのストレージの場所の階層を評価します。

たとえば、テーブル myCatalog.mySchema.myTablemy-region-metastoreで作成されている場合、テーブルの格納場所は次のルールに従って決定されます。

  1. mySchemaの場所が提供されている場合は、そこに保存されます。

  2. そうでなく、 myCatalogで場所が提供されている場合は、そこに保存されます。

  3. 最後に、 myCatalogで場所が指定されていない場合は、 my-region-metastoreに関連付けられた場所に保存されます。

Unity Catalogのストレージ階層

指定された環境でのみデータにアクセス可能

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

Databricksでは、ワークスペースがプライマリデータ処理環境であり、カタログがプライマリデータドメインです。Unity Catalogを使用すると、Metastore管理者とカタログ所有者は、カタログをワークスペースに割り当てる、つまり「バインド」できます。これらの環境対応バインディングにより、ユーザーに付与されたデータオブジェクトに対する特定の権限に関係なく、ワークスペース内で特定のカタログのみを使用できるようになります。

ここで、ニーズを満たすためにUnity Catalogをセットアップするプロセスを詳しく見てみましょう。

Unity Catalog Metastoreを構成する

メタストアは、Unity Catalog 内のオブジェクトの最上位のコンテナーです。 メタストアは、データ資産 (テーブル、ビュー、ボリューム) と、Unity Catalog によって管理されるその他のセキュリティ保護可能なオブジェクトを管理します。 セキュリティ保護可能なオブジェクトの完全な一覧については、「 Unity Catalog のセキュリティ保護可能なオブジェクト」を参照してください。

この項では、メタストアを作成および構成するためのヒントを提供します。 ワークスペースで Unity Catalog が自動的に有効になった場合は、メタストアを作成する必要はありませんが、このセクションに示す情報は引き続き役立つ場合があります。 「 Unity Catalog の自動有効化」を参照してください。

Metastoreを構成するためのヒント:

  • Databricksワークスペースがあるリージョンごとに1つのMetastoreを設定する必要があります。

    1 つの地域メタストアにアタッチされているすべてのワークスペースは、メタストアによって管理されるデータにアクセスできます。 メタストア間でデータを共有する場合は、 Delta Sharingを使用します。

  • 各メタストアは、マネージド テーブルとマネージド ボリュームの格納に使用できるクラウド テナント内のマネージド ストレージの場所 (ルート ストレージとも呼ばれます) を使用して構成できます。

    メタストア レベルの管理対象ロケーションを作成する場合は、ユーザーがそのロケーションに直接アクセスできないようにする必要があります (つまり、そのロケーションを含むクラウド アカウントを介して)。 このストレージの場所へのアクセス権を付与すると、ユーザーが Unity Catalog メタストアのアクセス制御をバイパスし、監査可能性を損なう可能性があります。 これらの理由から、メタストア管理ストレージは専用のバケットにする必要があります。 DBFSルート・ファイル・システムでもあるバケットや、以前はDBFSルート・ファイル・システムであったバケットを再利用しないでください。

    また、カタログ レベルとスキーマ レベルで管理ストレージを定義して、メタストアのルート ストレージの場所をオーバーライドすることもできます。 ほとんどのシナリオでは、Databricks では、マネージド データをカタログ レベルで格納することをお勧めします。

  • Unity Catalogで有効になっているワークスペースのワークスペース管理者の権限を理解し、既存のワークスペース管理者の割り当てを確認する必要があります。

    ワークスペース管理者は、ユーザーやサービス プリンシパルの追加、クラスターの作成、他のユーザーのワークスペース管理者への委任など、ワークスペースの操作を管理できます。 ワークスペースで Unity Catalog が自動的に有効になっている場合、ワークスペース管理者は、カタログと他の多くの Unity Catalog オブジェクトをデフォルトに作成できます。 「ワークスペースが Unity Catalog に対して自動的に有効になっている場合のワークスペース管理者特権」を参照してください

    ワークスペース管理者は、ジョブの所有権の管理やノートブックの表示などのワークスペース管理タスクを実行する機能も備えており、Unity Catalog に登録されているデータに間接的にアクセスできる場合があります。 ワークスペース管理者は、慎重に分散する必要がある特権ロールです。

  • ワークスペースを使用してユーザー データ アクセスを分離する場合は、ワークスペースとカタログのバインドを使用できます。 ワークスペース・カタログ・バインディングを使用すると、ワークスペース境界によってカタログ・アクセスを制限できます。 たとえば、ワークスペースの管理者とユーザーが、本番運用ワークスペース環境 prod_workspaceからprod_catalog内の本番運用データにのみアクセスできるようにすることができます。デフォルトは、現在のメタストアに接続されているすべてのワークスペースとカタログを共有することです。 「(オプション) カタログを特定のワークスペースに割り当てる」を参照してください。

    ワークスペースで Unity Catalog が自動的に有効になっていた場合、事前にプロビジョニングされたワークスペース カタログは、デフォルトによってワークスペースにバインドされます。

「Unity Catalog Metastoreの作成」を参照してください。

外部ロケーションとストレージ認証情報を設定する

外部ロケーションを使用すると、Unity Catalogはユーザーに代わってクラウドテナント上のデータを読み書きできます。外部ロケーションは、クラウドストレージへのパスとして定義され、その場所へのアクセスに使用できるストレージ資格情報と組み合わされます。

外部ロケーションを使用して、Unity Catalogの外部テーブルおよび外部ボリュームを登録できます。これらのエンティティのコンテンツは、ユーザーがボリュームまたはテーブルを作成するときに参照される外部ロケーションのサブパスに物理的に配置されます。

ストレージ資格情報は、クラウドストレージにアクセスするための長期的なクラウド資格情報をカプセル化します。たとえば、AWSでは、S3バケットにアクセスするようにIAMロールを構成できます。

ヒント

外部ロケーションは、ストレージ資格情報とストレージ パスを組み合わせることで、ストレージ アクセスの強力な制御と監査可能性を提供します。 ユーザーが Unity Catalog によって提供されるアクセス制御をバイパスしないようにするには、外部ロケーションとして使用されているバケットに直接アクセスできるユーザーの数を制限する必要があります。 同じ理由で、ストレージ アカウントが外部ロケーションとしても使用されている場合は、DBFS にマウントしないでください。 Databricks では、 カタログ エクスプローラーを使用して、クラウド ストレージの場所にあるマウントを Unity Catalog の外部ロケーションに移行することをお勧めします。

外部ロケーションを管理するためのベスト プラクティスのリストについては、 「外部ロケーション、外部テーブル、および外部ボリュームの管理」を参照してください。 「外部ロケーションを作成してクラウド ストレージを Databricks に接続する」も参照してください。

データを整理する

Databricks では、カタログを使用して、組織の情報アーキテクチャ全体で分離を提供することをお勧めします。 多くの場合、これは、カタログがソフトウェア開発環境のスコープ、チーム、または部署に対応することを意味します。 ワークスペースをデータ分離ツールとして使用する場合 (たとえば、運用環境と開発環境に異なるワークスペースを使用する場合や、機密性の高いデータを操作するために特定のワークスペースを使用する場合)、カタログを特定のワークスペースにバインドすることもできます。 これにより、指定したデータのすべての処理が適切なワークスペースで処理されます。 「 (オプション) 特定のワークスペースにカタログを割り当てる」を参照してください。

Unity Catalogカタログ

スキーマ (データベースとも呼ばれます) は、Unity Catalog の 3 レベルの名前空間の 2 番目のレイヤーであり、テーブル、ビュー、ボリュームを整理します。 スキーマを使用して、アセットのアクセス許可を整理および定義できます。

Unity Catalogが管理するオブジェクトは、管理することも外部にすることもできます:

  • 管理対象オブジェクトは、Unity Catalogでデータオブジェクトを作成するデフォルトの方法です。

    Unity Catalog、これらのセキュリティ保護可能なリソースのライフサイクルとファイルレイアウトを管理します。Databricksの外部でツールを使用して、マネージドテーブルまたはボリューム内のファイルを直接オペレーションしないでください。

    マネージド テーブルとマネージド ボリュームは、特定のテーブルまたはボリュームのメタストア、カタログ、またはスキーマ レベルで存在できる マネージド ストレージに格納されます。 ストレージ内でデータが物理的に分離されているを参照してください。

    Managed Table and Volumesは、外部ロケーションとストレージ資格情報を作成および管理するためのオーバーヘッドなしに、コンテンツの管理された場所をプロビジョニングする場合に便利なソリューションです。

    マネージドテーブルでは常にDeltaテーブル形式が使用されます。

  • 外部オブジェクトは、データのライフサイクルとファイルレイアウトがUnity Catalogによって管理されないセキュリティ保護可能なリソースです。

    外部ボリュームとテーブルは外部ロケーションに登録され、データコピーアクティビティを必要とせずにクラウドストレージにすでに存在する多数のファイルへのアクセスを提供します。他のシステムによって生成されたファイルがあり、Databricks内からアクセスできるようにステージングする場合、またはDatabricksの外部のツールがこれらのファイルに直接アクセスする必要がある場合は、外部オブジェクトを使用します。

    外部テーブルは、Delta Lakeや、Parquet、JSON、CSVなどの他の多くのデータ形式をサポートしています。管理ボリュームと外部ボリュームの両方を使用して、任意の形式のファイルにアクセスして保存できます。データは構造化、半構造化、または非構造化のいずれかです。

テーブルとボリュームの作成の詳細については、「 Unity Catalog でのテーブル の作成」と「 ボリュームの作成と操作」を参照してください。

外部の場所、外部テーブル、外部ボリュームを管理する

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

外部ロケーション

Unity Catalogで外部ロケーションを構成したら、外部ロケーション内のディレクトリに外部テーブルとボリュームを作成できます。その後、Unity Catalogを使用して、これらのテーブルとボリュームへのユーザーおよびグループのアクセスを管理できます。これにより、特定のユーザーまたはグループに特定のディレクトリとクラウド上のストレージバケットにあるファイルへのアクセスを提供できます。

ボリュームを定義すると、ボリューム パスの下のデータへのクラウド URI アクセスは、ボリュームの権限によって管理されます。

外部の場所を使用する場合の推奨事項

外部ロケーションに対するアクセス許可を付与するための推奨事項:

  • 外部ロケーションを作成する権限は、Unity Catalogとクラウドストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみ付与します。

    外部ロケーションは、Unity Catalog 内からクラウド ストレージ内の広範な場所 (バケットまたはコンテナー全体 (s3://mybucket) や広範なサブパス (s3://mybucket/alotofdata) など) へのアクセスを提供します。 その目的は、クラウド管理者がいくつかの外部ロケーションの設定に関与し、それらの場所を管理する責任を組織内の Databricks 管理者に委任できるようにすることです。 その後、Databricks 管理者は、外部ロケーションの下の特定のプレフィックスで外部ボリュームまたは外部テーブルを登録することで、外部ロケーションをより詳細なアクセス許可を持つ領域にさらに整理できます。

    外部ロケーションは非常に包括的であるため、Databricksでは、Unity Catalogとクラウドストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみCREATE EXTERNAL LOCATIONアクセス許可を付与することをお勧めします。他のユーザーにより詳細なアクセスを提供するために、Databricksでは、外部ロケーションの上に外部テーブルまたはボリュームを登録し、ボリュームまたはテーブルを使用してデータへのアクセス権をユーザーに付与することをお勧めします。テーブルとボリュームはカタログとスキーマの子であるため、カタログ管理者またはスキーマ管理者はアクセス許可を最終的に制御できます。

  • 外部ロケーションに対する一般的なREAD FILESまたはWRITE FILESアクセス許可をエンドユーザーに付与しないでください。

    ボリュームが利用できるようになったため、ユーザーはテーブル、ボリューム、または管理された場所の作成以外に外部ロケーションを使用しないでください。データサイエンスやその他の表形式以外のデータのユースケースのパスベースのアクセスに外部ロケーションを使用しないでください。

    ボリュームは、SQLコマンド、dbutils、Spark API、REST API、Terraformを使用したファイルオペレーションのサポートと、ファイルの参照、アップロード、ダウンロードのためのユーザーインターフェイスを提供します。さらに、ボリュームは、/Volumes/<catalog_name>/<schema_name>/<volume_name>/の下のローカルファイルシステム上でアクセスできるFUSEマウントを提供します。FUSEマウントを使用すると、データサイエンティストやMLエンジニアは、多くの機械学習やオペレーティングシステムライブラリで必要とされるローカルファイルシステム内にあるかのようにファイルにアクセスできます。

    外部ロケーションにあるファイルへの直接アクセスを許可する必要がある場合(たとえば、ユーザーが外部テーブルまたはボリュームを作成する前にクラウドストレージ内のファイルを探索する場合)、READ FILESを付与できます。WRITE FILESを付与するユースケースはまれです。

外部ロケーションを使用して、次のオペレーションを行う必要があります:

  • 外部テーブルとボリュームを登録するには、CREATE EXTERNAL VOLUMEコマンドまたはCREATE TABLEコマンドを使用します。

  • 特定のプレフィックスで外部テーブルまたはボリュームを作成する前に、クラウドストレージ内の既存のファイルを探索します。READ FILES特権は前提条件です。

  • Metastoreルートバケットの代わりに、カタログとスキーマの管理ストレージとして場所を登録します。CREATE MANAGED STORAGE特権は前提条件です。

外部ロケーションを使用するためのその他の推奨事項:

  • パスの重複の競合を回避する:外部ロケーションのルートに外部ボリュームまたはテーブルを作成しないでください。

    外部の場所のルートに外部ボリュームまたは外部テーブルを作成する場合、その外部の場所に追加の外部ボリュームまたは外部テーブルを作成することはできません。代わりに、外部の場所内のサブディレクトリに外部ボリュームまたは外部テーブルを作成します。

外部ボリュームの使用に関する推奨事項

外部ボリュームを使用して、次のことを行う必要があります:

  • 外部システムによって生成された生データのランディングエリアを登録して、ETLパイプラインやその他のデータエンジニアリング活動の初期段階での処理をサポートします。

  • たとえば、Auto Loader、COPY INTO、またはCTAS(CREATE TABLE AS)ステートメントを使用して、インジェストするステージング場所を登録します。

  • 管理ボリュームがオプションではない場合に、データサイエンティスト、データアナリスト、機械学習エンジニアが探索的データ分析やその他のデータサイエンスタスクの一部として使用できるファイルストレージの場所を提供します。

  • Databricksユーザーに、他のシステムによって作成されクラウド ストレージに保存された任意のファイル (たとえば、監視システムやIoTデバイスによってキャプチャされた非構造化データの大規模なコレクション (画像、音声、ビデオ、PDF ファイルなど)、またはライブラリ ファイル ( JAR およびPython wheelファイル) は、ローカルの依存関係管理システムまたはCI/CDパイプラインからエクスポートされます。

  • 管理対象ボリュームがオプションにならない場合、ロギングファイルやチェックポイントファイルなどの運用データを保管します。

外部ボリュームの使用に関するその他の推奨事項:

  • Databricksでは、1つのスキーマ内の1つの外部ロケーションから外部ボリュームを作成することをお勧めします。

ヒント

データが別の場所にコピーされる取り込みユースケース(たとえばAuto LoaderやCOPY INTOを使用する)の場合は、外部ボリュームを使用します。コピーを使用せずに、テーブルとしてその場でデータをクエリーする場合は、外部テーブルを使用します。

外部テーブルの使用に関する推奨事項

管理テーブルを作成できない場合は、クラウドストレージに保存されているデータに対する通常のクエリーパターンをサポートするために外部テーブルを使用する必要があります。

外部テーブルの使用に関するその他の推奨事項:

  • Databricks では、スキーマごとに 1 つの外部ロケーションを使用して外部テーブルを作成することをお勧めします。

  • Databricks では、整合性の問題のリスクがあるため、テーブルを複数のメタストアの外部テーブルとして登録しないことを強くお勧めします。 たとえば、1 つのメタストアでスキーマを変更しても、2 番目のメタストアでは登録されません。 メタストア間でデータを共有するには、 Delta Sharing を使用します。 Delta Sharingを使用したデータの安全な共有を参照してください。

アクセスコントロールの設定

Unity Catalog内のセキュリティ保護可能なオブジェクトにはそれぞれ所有者がいます。オブジェクトを作成したプリンシパルは、そのオブジェクトの最初の所有者となります。オブジェクトの所有者は、テーブルに対するSELECTやMODIFYなど、オブジェクトに対するすべての権限を持ち、また、セキュリティ保護可能なオブジェクトに対する権限を他のプリンシパルに付与する権限も持ちます。セキュリティ保護可能なオブジェクトの所有者のみが、そのオブジェクトに対する権限を他のプリンシパルに付与する権限を持ちます。したがって、ベストプラクティスは、すべてのオブジェクトの所有権を、オブジェクトに対する許可の管理を担当するグループに構成することです。所有者とMetastore管理者の両方が、セキュリティ保護可能なオブジェクトの所有権をグループに譲渡できます。さらに、オブジェクトがカタログ(テーブルやビューなど)内に含まれている場合、カタログとスキーマの所有者はオブジェクトの所有権を変更できます。

Unity Catalog 内のセキュリティ保護可能なオブジェクトは階層構造であり、特権は下位に継承されます。つまり、カタログまたはスキーマに対する特権を付与すると、カタログまたはスキーマ内の現在および将来のすべてのオブジェクトに特権が自動的に付与されます。 詳細については、「 継承モデル」を参照してください。

テーブルまたはビューからデータを読み取るには、ユーザーは次の権限を持っている必要があります:

  • SELECT テーブルやビュー

  • USE SCHEMA テーブルを所有するスキーマ

  • USE CATALOG スキーマを所有するカタログ

USE CATALOG 権限付与対象ユーザーが子オブジェクトにアクセスするためにカタログを走査できるようにし USE SCHEMA 、権限付与対象ユーザーが子オブジェクトにアクセスするためにスキーマを走査できるようにします。 たとえば、テーブルからデータを選択するには、そのテーブルに対する SELECT 権限、親カタログに対する USE CATALOG 権限、および親スキーマに対する USE SCHEMA 権限が必要です。 したがって、この特権を使用して、データ名前空間のセクションへのアクセスを特定のグループに制限できます。 一般的なシナリオは、そのチームだけがスキーマに USE SCHEMACREATE を持つチームごとにスキーマを設定することです。 つまり、チーム メンバーが作成したテーブルは、チーム内でのみ共有できます。

次のSQL構文を使用して、テーブルへのアクセスを保護できます:

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

次のSQL構文に示すように、セカンダリスキーマのダイナミックビューを使用して列へのアクセスを保護できます:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

次のSQL構文に示すように、セカンダリスキーマの動的ビューを使用して行へのアクセスを保護できます:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

また、行フィルターと列マスクを使用して、テーブルへの安全なアクセスをユーザーに付与することもできます。 詳細については、「 行フィルターと列マスクを使用して機密テーブル データをフィルター処理する」を参照してください。

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

クラスター構成の管理

Databricksでは、クラスターポリシーを使用して、一連のルールに基づいてクラスターを構成する機能を制限することをお勧めします。クラスターポリシーを使用すると、Unity Catalogが有効なクラスターの作成のみにアクセスを制限できます。クラスターポリシーを使用すると、利用可能な選択肢が減り、ユーザーのクラスター作成プロセスが大幅に簡素化され、データにシームレスにアクセスできるようになります。クラスターポリシーを使用すると、クラスターごとの最大コストを制限することでコストを制御することもできます。

アクセス制御の整合性を確保し、強力な分離保証を適用するために、Unity Catalog ではコンピュート リソースにセキュリティ要件が課されます。 このため、Unity Catalog ではクラスターのアクセス モードの概念が導入されています。 Unity Catalog は default によってセキュリティで保護されています。クラスターが適切なアクセス モードで構成されていない場合、クラスターは Unity Catalog 内のデータにアクセスできません。 「 Unity Catalog でサポートされているコンピュートとクラスターのアクセス モード」を参照してください。

Databricks では、クラスターを共有する場合は共有アクセスモードを使用し、自動ジョブと機械学習ワークロードにはシングルユーザーアクセスモードを使用することをお勧めします。

以下のJSONは、共有アクセスモードを使用したクラスターのポリシー定義を提供します:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

以下のJSONは、シングルユーザーアクセスモードでの自動ジョブクラスターのポリシー定義を提供します。

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

監査アクセス

完全なデータガバナンスソリューションには、データへのアクセスを監査し、警告機能と監視機能を提供する必要があります。Unity CatalogはMetastoreに対して実行されたアクションの監査ログをキャプチャし、これらのログはDatabricksの監査ログの一部として配信されます。

システムテーブルを使用してアカウントの監査ログにアクセスできます。監査ログシステムテーブルの詳細については、「 監査ログシステムテーブルリファレンス」を参照してください。

Databricks Data Intelligence Platform に関連する重要なイベントを完全に可視化する方法の詳細については、「 監査ログを使用した Databricks Data Intelligence プラットフォーム 」を参照してください。

Delta共有を使用したデータの安全な共有

Delta Sharingは、Databricks社が開発したオープンなプロトコルで、他の組織や組織内の他部門がどのコンピューティングプラットフォームを使用しているかに関係なく、安全にデータを共有することができます。DeltaシェアリングがMetastoreで有効になっている場合、Unity CatalogはDeltaシェアリングサーバーを実行します。

メタストア間でデータを共有するには、 Databricks対Databricks Delta Sharingを利用できます。これにより、異なるリージョンのメタストアからテーブルを登録できます。 これらのテーブルは、使用するメタストアに読み取り専用オブジェクトとして表示されます。 これらのテーブルには、 Unity Catalog内の他のオブジェクトと同様にアクセス権を付与できます。

Databricks間でのDelta共有を使用してMetastore間で共有する場合、アクセス制御は1つのMetastoreに制限されることに注意してください。テーブルなどのセキュリティ保護可能なオブジェクトに権限があり、そのリソースがアカウント内Metastoreに共有されている場合、ソースからの権限は宛先共有には適用されません。宛先のシェアは独自にグラントを設定する必要があります。