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

[アーティクル]
11/07/2024

このドキュメントでは、お客様のデータガバナンスのニーズに合わせて Unity Catalog と Delta Sharing を使用するための推奨事項を提供します。

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

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

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

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

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

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

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

メタストアでは、データ資産 (テーブル、ビュー、ボリューム) と、それらへのアクセスを制御するアクセス許可が管理されます。 Azure Databricks アカウント管理者は、運用するリージョンごとにメタストアを作成し、同じリージョン内の複数の Azure Databricks ワークスペースにそれらを割り当てることができます。メタストア管理者は、メタストア内のすべてのオブジェクトを管理できます。メタストアに登録されているテーブルを読み取りおよび書き込みの直接アクセスはありませんが、データのオブジェクト所有者を転送できる権限を通して間接的にアクセスできます。

既定では、特定のメタストアの物理ストレージは、アカウント内の他のメタストアの物理ストレージから分離されます。

メタストアはリージョンの分離を提供しますが、データ分離の単位として意図されていません。データ分離はカタログレベルで開始する必要があります。
カタログ: カタログは、Unity Catalog メタストアによって管理されるデータ階層 (カタログ > スキーマ > テーブル/ビュー/ボリューム) の最上位レベルです。一般的な Azure Databricks データガバナンスモデルにおけるデータ分離の主な単位として意図されています。

カタログは、スキーマの論理的なグループを表します。通常は、データアクセス要件によって制限されています。多くの場合、カタログは組織単位やソフトウェア開発のライフサイクルスコープを反映します。たとえば、運用データ用のカタログと開発データ用のカタログ、または顧客以外のデータ用のカタログと顧客の機密データ用のカタログを所有することにするかもしれません。

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

カタログが Azure Databricks データガバナンスモデルのデータ分離の主要な単位である場合、"ワークスペース" がデータ資産を操作するための主要な環境です。メタストア管理者とカタログ所有者は、カタログへのアクセスをワークスペースとは別に管理できます。カタログを特定のワークスペースにバインドして、特定のデータの種類がそのワークスペース内でのみ処理されるようにすることもできます。たとえば、運用ワークスペースと開発ワークスペースを別々にする場合や、個人データを処理するための別個のワークスペースが必要な場合があります。

既定では、セキュリティ保護可能なオブジェクトのアクセス許可は、そのオブジェクトの子が継承し、階層の最上位にカタログがあります。これにより、データの既定のアクセス規則を設定し、階層の必要な箇所でのみ、各レベルで異なる規則を指定することがより簡単になります。
スキーマ (データベース): スキーマ (データベースとも呼ばれます) は、表形式データ (テーブルとビュー)、表形式以外のデータ (ボリューム)、関数、機械学習モデルの論理的なグループです。カタログよりも粒度が細かいデータへのアクセスを組織および制御する方法を提供します。通常、単一のユースケース、プロジェクト、チームサンドボックスを表します。

スキーマは親カタログと同じ物理ストレージに保存できます。スキーマがが親カタログの他のデータと別々に保存されるように構成することもできます。

メタストア管理者、親カタログ所有者、スキーマ所有者は、スキーマへのアクセスを管理できます。
テーブル: テーブルは、Unity Catalog の 3 レベルの名前空間の 3 番目のレイヤーにあります。データの行が含まれます。

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

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

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

親カタログ所有者とスキーマ所有者は、メタストア管理者と同様に (間接的に) テーブルへのアクセスを管理できます。
ビュー: ビューは、メタストア内の 1 つ以上のテーブルとビューから派生した読み取り専用オブジェクトです。
行と列: 行と列レベルのアクセスとデータマスキングは、動的ビューまたは行フィルターと列マスクのいずれかを使用して付与されます。動的ビューは読み取り専用です。
ボリューム: ボリュームは、Unity Catalog の 3 レベルの名前空間の 3 番目のレイヤーにあります。表形式以外のデータを管理します。ボリュームを使用すると、構造化データ、半構造化データ、非構造化データを含む、任意の形式でファイルを格納、整理、アクセスできます。ボリューム内のファイルをテーブルとして登録することはできません。
モデルと関数: 厳密にはデータ資産ではありませんが、登録されたモデルとユーザー定義関数も Unity Catalog で管理することができ、オブジェクト階層の最下層に存在します。「Unity Catalog 内でモデルライフサイクルを管理する」と「Unity Catalog のユーザー定義関数 (UDF)」を参照してください。

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

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

分離の標準は組織によって異なる場合がありますが、通常は次の要件が含まれます。

ユーザーは、指定されたアクセス規則に基づいてのみデータにアクセスできる。
データは、指定されたユーザーまたはチームのみが管理できる。
データは、ストレージ内で物理的に分離される。
データは、指定された環境でのみアクセスできる。

データ分離の必要があると、サイロ化された環境が発生する可能性があります。その場合、データガバナンスとコラボレーションの両方が不必要に困難になる可能性があります。 Azure Databricks では、Unity Catalog を使用してこの問題を解決します。Unity Catalog は、さまざまなデータ分離オプションを提供しながら、統合されたデータガバナンスプラットフォームを維持します。このセクションでは、一元的および分散型のどちらのデータガバナンスモデルを使用するかに関係なく、Azure Databricks で使用できるデータ分離オプションとその使用方法について説明します。

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

ほとんどの組織では、データアクセスに関して、内部要件または規制要件に基づいた厳しい要件があります。セキュリティで保護する必要があるデータの一般的な例として、従業員の給与情報やクレジットカードの支払情報などがあります。通常、このような情報へのアクセスは、厳密に管理され、定期的に監査されます。これらの業界標準を満たすため、Unity Catalog では、カタログ内のデータ資産を細かな制御が提供されます。 Unity Catalog が提供する制御により、ユーザーは、自分が表示およびクエリする権利があるデータだけを表示およびクエリできます。

データは、指定されたユーザーやチームだけが管理できます

Unity Catalog を使用すると、一元的なガバナンスモデルまたは分散型ガバナンスモデルから選択できます。

一元的なガバナンスモデルでは、ガバナンス管理者がメタストアの所有者であり、任意のオブジェクトの所有権を取得し、アクセス許可を付与および取り消すことができます。

分散型ガバナンスモデルでは、カタログまたはカタログのセットがデータドメインです。そのカタログの所有者は、すべての資産を作成および所有し、そのドメイン内のガバナンスを管理できます。特定のドメインの所有者は、他のドメインの所有者とは独立して運用できます。

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

Unity Catalog の所有権とアクセス

データは、ストレージ内で物理的に分離されます

組織は、特定の種類のデータをクラウドテナントの特定のアカウントまたはバケット内に格納することを要求できます。

Unity Catalog では、このような要件を満たすために、メタストア、カタログ、またはスキーマレベルで格納場所を構成できます。

たとえば、自分の組織に人事に関する運用データをコンテナー abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net に格納する必要がある会社のコンプライアンスポリシーがあるとします。 Unity Catalog では、カタログレベルで場所を設定し、hr_prod などのカタログを作成し、abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog という場所をそれに割り当てることで、この要件を達成できます。つまり、hr_prod カタログで作成された管理テーブルまたはボリューム (CREATE TABLE hr_prod.default.table … の使用など) は、abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog にデータを格納します。オプションで、hr_prod catalog 内のデータをより細かいレベルで整理するためにスキーマレベルの場所を指定することもできます。

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

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

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

mySchema に場所が指定されている場合は、その場所に格納されます。
そうでない場合は、myCatalog に場所が指定されていると、その場所に保存されます。
最後に、myCatalog で場所が指定されていない場合は、my-region-metastore に関連付けられた場所に格納されます。

Unity Catalog ストレージの階層

データは、指定された環境でのみアクセスできます

多くの場合、組織の要件およびコンプライアンス要件では、個人データなどの特定のデータを特定の環境内でのみアクセス可能にすることが指定されています。また、運用データが開発データから分離された状態を維持するか、特定のデータセットとドメインが結合されないようにする必要もあります。

Databricks で、ワークスペースは主なデータ処理環境で、カタログは主なデータドメインです。 Unity Catalog を使用すると、メタストア管理者とカタログ管理者は、カタログを指定のワークスペースに割り当てる (または "バインドする") ことができます。環境によって認識されるこれらのバインドにより、データオブジェクトに対してユーザーに付与されている特定のアクセス許可に関係なく、ワークスペース内で特定のカタログだけが使用できるようにする機能が提供されます。

次に、お客様のニーズに合わせて Unity Catalog を設定するプロセスについて詳しく見てみましょう。

Unity Catalog メタストアを構成する

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

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

メタストアを構成するためのヒント:

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

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 メタストアを作成する」を参照してください。

外部の場所とストレージの資格情報を構成する

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

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

"ストレージの資格情報" を使って、クラウドストレージへのアクセスを提供する長期的なクラウドの資格情報をカプセル化します。 Azure マネージド ID (強くお勧めします) またはサービスプリンシパルのいずれかにすることができます。 Azure マネージド ID の使用は、次の点でサービスプリンシパルの使用よりも優れています。

マネージド ID では、資格情報を維持したり、シークレットをローテーションしたりする必要がありません。
Azure Databricks ワークスペースがご自身の VNet にデプロイされている (VNet インジェクションとも呼ばれます) 場合は、ストレージファイアウォールによって保護されている Azure Data Lake Storage Gen2 アカウントに接続できます。

データの分離を強化するために、サービス資格情報、ストレージ資格情報、および外部の場所を特定のワークスペースにバインドできます。「 (省略可能) 特定のワークスペースにサービス資格情報を割り当てる、 (省略可能) 特定のワークスペースに外部の場所を割り当てる (省略可能) ストレージ資格情報を特定のワークスペースに割り当てるを参照してください。

ヒント

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

外部の場所を管理するためのベストプラクティスの一覧については、「外部の場所、外部テーブル、外部ボリュームを管理する」を参照してください。「クラウドストレージを Azure Databricks に接続するための外部の場所の作成」も参照してください。

データを整理する

Databricks では、カタログを使って組織の情報アーキテクチャ全体で分離を実現することをお勧めします。多くの場合、これは、カタログがソフトウェア開発環境のスコープ、チーム、またはビジネスユニットに対応することを意味します。ワークスペースをデータ分離ツールとして使用する場合 (たとえば、運用環境と開発環境にそれぞれ別のワークスペースを使用する場合や、機密性の高いデータの処理用に特定のワークスペースを使用する場合など) は、カタログを特定のワークスペースにバインドすることもできます。こうすると、指定されたデータのすべての処理が適切なワークスペースで行われます。「特定のワークスペースにカタログアクセスを制限する」を参照してください。

Unity Catalog のカタログ

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

Unity Catalog によって管理されるオブジェクトは、"マネージド" にすることも "外部" にすることもできます。

マネージドオブジェクトは、Unity Catalog でデータオブジェクトを作成するための既定の方法です。

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

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

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

マネージドテーブルでは、常に Delta テーブル形式を使用します。
外部オブジェクトは、データライフサイクルとファイルレイアウトが Unity Catalog によって管理されないセキュリティ保護可能なリソースです。

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

外部テーブルは、Delta Lake と他の多くのデータ形式 (Parquet、JSON、CSV など) をサポートします。マネージドボリュームと外部ボリュームはいずれも、任意の形式のファイルにアクセスして格納するために使用できます。データは、構造化、半構造化、または非構造化にすることができます。

テーブルとボリュームの作成の詳細については、「テーブルとビューとはと Unity カタログボリュームとはを参照してください。

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

次の図は、1 つのクラウドストレージコンテナーのファイルシステム階層を表しており、1 つのストレージ資格情報を共有する 4 つの外部の場所があります。

外部の場所

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

Note

外部ボリュームを定義すると、ボリュームパスの下にあるデータへのクラウド URI アクセスは、ボリュームが格納されている外部の場所で付与された特権ではなく、ボリュームに付与された特権によって制御されます。

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

外部の場所へのアクセス許可を付与するための推奨事項:

外部の場所を作成できる権限は、Unity Catalog とクラウドストレージ間の接続の設定を任されている管理者、または信頼できるデータエンジニアにのみ付与します。

外部の場所は、Unity Catalog 内から、バケットまたはコンテナー全体 (abfss://my-container@storage-account.dfs.core.windows.net) や広範なサブパス (abfss://my-container@storage-account.dfs.core.windows.net/path/to/subdirectory) など、クラウドストレージ内の広範な場所へのアクセスを提供します。その目的は、クラウド管理者がいくつかの外部の場所の設定に関与し、それらの場所を管理する責任を組織の Azure Databricks 管理者に委任できることです。その後、Azure 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 特権が前提条件です。
カタログとスキーマのマネージドストレージとして、メタストアルートバケットではなく場所を登録する。 CREATE MANAGED STORAGE 特権が前提条件です。

外部の場所を使用するためのその他の推奨事項:

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

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

既存のボリュームを使用するための推奨事項

次のことを行う場合は既存のボリュームを使用してください。

ETL パイプラインやその他のデータエンジニアリングアクティビティの初期段階での処理をサポートするために、外部システムによって生成された生データのランディング領域を登録する。
インジェストのためのステージング場所を登録する (たとえば自動ローダー COPY INTO または CTAS (CREATE TABLE AS) ステートメントを使用)。
データサイエンティスト、データアナリスト、機械学習エンジニアが探索的データ分析やその他のデータサイエンスタスクの一部として使用するためのファイルストレージの場所を提供する (マネージドボリュームが選択肢ではない場合)。
Azure Databricks ユーザーに、他のシステムによってクラウドストレージに生成および堆積された任意のファイルへのアクセスを提供します。たとえば、監視システムや IoT デバイスによってキャプチャされた大量の非構造化データ (画像、オーディオ、ビデオ、PDF ファイルなど) や、ローカル依存関係管理システムまたは CI/CD パイプラインからエクスポートされたライブラリファイル (JAR と Python ホイールファイル) など。
ログ記録やチェックポイント処理ファイルなどのオペレーショナルデータを格納する (マネージドボリュームが選択肢ではない場合)。

既存のボリュームを使用するためのその他の推奨事項:

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

ヒント

自動ローダーや COPY INTO などを使用して別の場所にデータがコピーされるインジェストのユースケースでは、外部ボリュームを使用します。コピーを伴わず、テーブルとして存在するデータをクエリする場合は、外部テーブルを使用します。

外部テーブルを使用するための推奨事項

マネージドテーブルの作成が選択肢でない場合は、クラウドストレージに格納されているデータの上で通常のクエリパターンをサポートするために、外部テーブルを使用する必要があります。

外部テーブルを使用するためのその他の推奨事項:

Databricks では、スキーマごとに 1 つの外部の場所を使用して外部テーブルを作成することをお勧めします。
Databricks では、一貫性の問題のリスクがあるため、テーブルを複数のメタストアに外部テーブルとして登録することをお勧めしません。たとえば、1 つのメタストアのスキーマを変更した場合、別のメタストアには変更が登録されません。メタストア間でデータを共有するには、Delta Sharing を使用します。「Delta Sharing を使用してデータを安全に共有する」を参照してください。

アクセスの制御の構成

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

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

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

テーブルまたはビューに対する SELECT
テーブルを所有するスキーマに対する USE SCHEMA
スキーマを所有するカタログに対する USE CATALOG

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

テーブルへのアクセスは、次の 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 は、既定ではセキュリティで保護されています。クラスターが適切なアクセスモードで構成されていない場合、クラスターは 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 によって、メタストアに対して実行されたアクションの監査ログがキャプチャされます。これらのログは、Azure Databricks 監査ログの一部として配信されます。

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

Databricks Data Intelligence Platform に関連する重要なイベントを完全に視覚化する方法の詳細については、「Monitoring Your Databricks Data Intelligence Platform with Audit Logs (監査ログを使った Databricks Data Intelligence Platform の監視)」を参照してください。

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

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

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

次の方法で共有

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

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

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

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

データは、指定されたユーザーやチームだけが管理できます

データは、ストレージ内で物理的に分離されます

データは、指定された環境でのみアクセスできます

Unity Catalog メタストアを構成する

外部の場所とストレージの資格情報を構成する

データを整理する

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

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

既存のボリュームを使用するための推奨事項

外部テーブルを使用するための推奨事項

アクセスの制御の構成

クラスター構成を管理する

アクセスを監査する

詳細情報

フィードバック

その他のリソース

次の方法で共有

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

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

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

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

データは、指定されたユーザーやチームだけが管理できます

データは、ストレージ内で物理的に分離されます

データは、指定された環境でのみアクセスできます

Unity Catalog メタストアを構成する

外部の場所とストレージの資格情報を構成する

データを整理する

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

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

既存のボリュームを使用するための推奨事項

外部テーブルを使用するための推奨事項

アクセスの制御の構成

クラスター構成を管理する

アクセスを監査する

Delta Sharing を使用してデータを安全に共有する

詳細情報

フィードバック

その他のリソース

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

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