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

[アーティクル]
02/04/2025

このドキュメントでは、データガバナンスのニーズを満たすために Unity Catalog と Delta Sharing を使用するための推奨事項を示します。

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

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

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

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

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

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

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

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

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

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

Catalogs は、スキーマの論理的なグループを表します。通常は、データアクセス要件によって制限されます。 Catalogs 多くの場合、組織単位またはソフトウェア開発ライフサイクルスコープを反映します。たとえば、運用データの catalog と開発データ用の catalog、顧客以外のデータ用の catalog、機密の顧客データ用に 1 つを選択できます。

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

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

既定では、セキュリティ保護可能なオブジェクトのアクセス許可は、そのオブジェクトの子によって継承され、階層の一番上に catalogs されます。これにより、データの既定のアクセス規則をsetし、必要な場合にのみ階層の各レベルで異なる規則を指定することが、いっそう簡単になります。
Schema (データベース): スキーマ (データベースとも呼ばれます) は、表形式データ (tables と views)、表形式以外のデータ (volumes)、関数、機械学習モデルの論理グループです。これらは、catalogsよりも細かいデータへのアクセスを整理および制御する方法を提供します。通常、単一のユースケース、プロジェクト、チームサンドボックスを表します。

スキーマは、親 catalogと同じ物理ストレージに格納することも、親 catalogの残りの部分とは別に格納するように schema を構成することもできます。

メタストア管理者、親 catalog 所有者、および schema 所有者は、スキーマへのアクセスを管理できます。
Tables:Tables Unity Catalogの 3 レベルの名前空間の 3 番目のレイヤーに存在します。データの行が含まれます。

Unity Catalog を使うと、"マネージド tables"と "外部tables" を作成できます。

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

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

親 catalog 所有者と schema 所有者は、メタストア管理者 (間接的) と同様に、tablesへのアクセスを管理できます。
Views: ビューは、メタストア内の 1 つ以上の tables と views から派生した読み取り専用オブジェクトです。
行と columns: 行および columnレベルのアクセスやデータマスクは、動的な views または行フィルターと column マスクを使用して付与されます。動的viewsは読み取り専用です。
Volumes:Volumes Unity Catalogの 3 レベルの名前空間の 3 番目のレイヤーに存在します。表形式以外のデータを管理します。 volumes を使用すると、構造化データ、半構造化データ、非構造化データなど、任意の形式でファイルを格納、整理、アクセスできます。 volumes 内のファイルを tablesとして登録できません。
モデルと関数: 厳密に言うと、データ資産ではありませんが、登録済みモデルとユーザー定義関数も Unity Catalog 内で管理可能で、オブジェクト階層の最下位レベルに位置しています。「Unity Catalog 内でモデルライフサイクルを管理する」と「Unity Catalog のユーザー定義関数 (UDF)」を参照してください。

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

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

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

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

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

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

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

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

Unity Catalog を使用すると、一元化されたガバナンスモデルと分散ガバナンスモデルを選択できます。

一元化されたガバナンスモデルでは、ガバナンス管理者はメタストアの所有者であり、任意のオブジェクトと grant および revoke アクセス許可の所有権を取得できます。

分散ガバナンスモデルでは、catalogs の catalog または set がデータドメインです。その catalog の所有者は、すべての資産を作成して所有し、そのドメイン内のガバナンスを管理できます。特定のドメインの所有者は、他のドメインの所有者とは独立して運用できます。

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

所有者は、ユーザー、サービスプリンシパル、グループに MANAGE アクセス許可をgrantして、オブジェクトに対するgrantとrevokeのアクセス許可を許可できます。

Unity Catalog の所有権とアクセス

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

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

Unity Catalog では、そのような要件を満たすために、メタストア、catalog、または schema レベルでストレージの場所を構成できます。

たとえば、自分の組織に人事に関する運用データをコンテナー abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net に格納する必要がある会社のコンプライアンスポリシーがあるとします。 Unity Catalogでは、catalog レベルで場所を設定し、hr_prodなどの呼び出し catalog を作成し、その場所 abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog を割り当てることで、この要件を満たすことができます。つまり、hr_prodcatalog で作成されたマネージド tables または volumes (たとえば、CREATE TABLE hr_prod.default.table …を使用) は、そのデータを abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalogに格納します。必要に応じて、schemaレベルの場所を指定して、hr_prod catalog 内のデータをより細かいレベルで整理することもできます。

このようなストレージ分離が不要な場合は、メタストアレベルでストレージの場所を set できます。その結果、この場所は、メタストア内の catalogs とスキーマ全体にマネージド tables と volumes を格納するための既定の場所として機能します。

システムは、schema から catalog、メタストアへの記憶域の場所の階層を評価します。

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

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

Unity Catalog ストレージ階層

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

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

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

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

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

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

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

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

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

1 つのリージョンメタストアにアタッチされているすべてのワークスペースは、そのメタストアによって管理されるデータにアクセスできます。 metastores間でデータを共有する場合は、Delta Sharingを使用します。
各メタストアは、マネージド tables とマネージド volumesの格納に使用できるクラウドテナント内のマネージドストレージの場所 (ルートストレージとも呼ばれます) で構成できます。

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

また、catalog レベルと schema レベルでマネージドストレージを定義し、メタストアのルートストレージの場所をオーバーライドすることもできます。ほとんどのシナリオでは、Databricks では、catalog レベルでマネージドデータを格納することをお勧めします。
Unity Catalogが有効になっているワークスペースのワークスペース管理者の特権を理解し、既存のワークスペース管理者の割り当てを確認する必要があります。

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

ワークスペース管理者は、ジョブの所有権の管理やノートブックの表示などのワークスペース管理タスクを実行することもできます。これにより、Unity Catalogに登録されたデータに間接的にアクセスできます。ワークスペース管理者は、慎重に配布する必要がある特権ロールです。
ワークスペースを使用してユーザーデータアクセスを分離する場合は、ワークスペースcatalog バインドを使用できます。ワークスペース -catalog バインドを使用すると、ワークスペースの境界によってlimitcatalogのアクセスが可能になります。たとえば、ワークスペース管理者とユーザーが、運用ワークスペース環境 (prod_catalog) から prod_workspace の運用データにのみアクセスできるようになります。既定では、現在のメタストアにアタッチされているすべてのワークスペースと catalog を共有します。特定 Limitcatalog ワークスペースへのアクセスを参照してください。

ワークスペースが Unity Catalog に対して自動的に有効になっている場合、事前プロビジョニングされたワークスペース catalog は既定でワークスペースにバインドされます。

「Unity Catalog メタストアを作成する」を参照してください。

外部の場所とストレージ credentials を構成する

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

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

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

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

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

ヒント

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

外部の場所を管理するためのベストプラクティスの list については、「外部の場所、外部 tables、および外部 volumesの管理」を参照してください。「クラウドストレージを Azure Databricks に接続するための外部の場所の作成」も参照してください。

データを整理する

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

Unity Catalog のcatalogs

schema (データベースとも呼ばれます) は、Unity Catalog3 レベルの名前空間の 2 番目のレイヤーであり、tables、views、および volumesを整理します。スキーマを使用して、資産のアクセス許可を整理および定義できます。

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

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

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

マネージド tables と volumes は、特定の table またはボリュームのメタストア、catalog、または schema レベルに存在できる、マネージドストレージに格納されます。「データは、ストレージ内で物理的に分離されます」を参照してください。

マネージド tables と volumes は、外部の場所とストレージ credentialsを作成および管理するオーバーヘッドなしで、コンテンツの管理場所をプロビジョニングする場合に便利なソリューションです。

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

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

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

tablesとvolumesの作成について詳しくは、「tablesとviewsとは」と「Unity Catalog volumesとは?」をご覧ください。

外部の場所、外部tables、外部volumesを管理する

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

外部の場所

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

Note

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

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

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

Grant 外部の場所を作成する機能は、Unity Catalog とクラウドストレージの間の connections の設定を任されている管理者、または信頼できるデータエンジニアに対してのみ行うことができます。

外部の場所は、Unity Catalog 内から、バケットまたはコンテナー全体 (abfss://my-container@storage-account.dfs.core.windows.net) や広範なサブパス (abfss://my-container@storage-account.dfs.core.windows.net/path/to/サブディレクトリ) など、クラウドストレージ内の広範な場所へのアクセスを提供します。その目的は、クラウド管理者がいくつかの外部の場所の設定に関与し、それらの場所を管理する責任を組織の Azure Databricks 管理者に委任できることです。 Azure Databricks 管理者は、外部の場所の下の特定のプレフィックスに外部 volumes または外部 tables を登録することで、外部の場所をより詳細なアクセス許可を持つ領域にさらに整理できます。

外部の場所は非常に包括的であるため、Databricks では、Unity Catalog とクラウドストレージの間の connections の設定を任されている管理者、または信頼できるデータエンジニアにのみ、CREATE EXTERNAL LOCATION アクセス許可を付与することをお勧めします。他のユーザーにより詳細なアクセスを提供するために、Databricks では、外部の場所に外部 tables または volumes を登録することを推奨しています。そして、volumes または tablesを使用することで、ユーザーにデータへのアクセスを許可します。 tables と volumes は catalog と schemaの子であるため、catalog または schema の管理者はアクセス許可を最終的に制御できます。

特定のワークスペースにバインドすることで、外部の場所へのアクセスを制御することもできます。「(省略可能) 外部の場所を特定のワークスペースに割り当てる」を参照してください。
エンドユーザーに対して、外部の場所に対する一般的な READ FILES または WRITE FILES アクセス許可をgrantしないでください。

volumesが利用できる場合、ユーザーは外部の場所を使用せず、tables、volumes、または管理された場所を作成する必要があります。データサイエンスやその他の表形式以外のデータユースケースのために、パスベースのアクセスに外部の場所を使用しないでください。

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

外部の場所にあるファイルに直接アクセス grant 必要がある場合 (ユーザーが外部の table やボリュームを作成する前にクラウドストレージ内のファイルを探索する場合など)、grantREAD FILESできます。 WRITE FILES を付与するユースケースはまれです。

外部の場所は、次のことを行う場合に使用してください。

CREATE EXTERNAL VOLUME または CREATE TABLE コマンドを使用して、外部 tables と volumes を登録します。
特定のプレフィックスで外部 table またはボリュームを作成する前に、クラウドストレージ内の既存のファイルを調べる。 READ FILES 特権が前提条件です。
メタストアルートバケットではなく、catalogs とスキーマのマネージドストレージとして場所を登録します。 CREATE MANAGED STORAGE 特権が前提条件です。

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

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

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

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

外部 volumes を使用して、次の操作を行う必要があります。

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

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

Databricks では、1 つの schema内の 1 つの外部の場所から外部 volumes を作成することをお勧めします。

ヒント

データが別の場所にコピーされるインジェストのユースケース (自動ローダーや COPY INTOの使用など) には、外部 volumesを使用します。データをコピーなしで tableとしてクエリしたい場合は、外部 tables を使用します。

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

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

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

Databricks では、schemaごとに 1 つの外部場所を使用して外部 tables を作成することをお勧めします。
Databricks では、整合性の問題が生じるリスクがあるため、table を外部 table として複数のメタストアに登録しないことを強くお勧めします。たとえば、あるメタストアの schema に対する変更は、2 番目のメタストアには登録されません。 Delta Sharing を使用して、metastores間でデータを共有します。「Delta Sharing を使用してデータを安全に共有する」を参照してください。

アクセスの制御の構成

Unity Catalog のセキュリティ保護可能な各オブジェクトには所有者がいます。オブジェクトを作成するプリンシパルが、その最初の所有者になります。オブジェクトの所有者には、tableの SELECT や MODIFY など、オブジェクトに対するすべての権限と、セキュリティ保護可能なオブジェクトに対する権限を他のプリンシパルに grant する権限があります。所有者は、そのオブジェクトに対する権限を他の主体に grant することができます。これには、オブジェクトの権限を grant する能力を委任するための MANAGE 権限が含まれます。所有者、メタストア管理者、および MANAGE 特権を持つユーザーは、セキュリティ保護可能なオブジェクトの所有権をグループに譲渡できます。さらに、オブジェクトが catalog (table やビューなど) 内に含まれている場合、catalog と schema 所有者は、オブジェクトの所有権を変更できます。

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

table またはビューからデータを読み取るには、ユーザーに次の権限が必要です。

tableまたはビューに対する SELECT
tableを所有するschemaに対する USE SCHEMA
schemaを所有するcatalogに対する USE CATALOG

USE CATALOG すると、権限付与対象ユーザーは子オブジェクトにアクセスするために catalog を走査でき、USE SCHEMA 権限付与対象ユーザーは子オブジェクトにアクセスするために schema を走査できます。たとえば、tableからデータを select するには、その table に対する SELECT 特権と、その親 catalogに対する USE CATALOG 特権と、その親 schemaに対する USE SCHEMA 特権が必要です。このため、この権限を使用して、データの名前空間のセクションへのアクセスを特定のグループに制限できます。よくあるシナリオは、チームごとにschemaをsetし、そのチームだけがschemaに対して USE SCHEMA と CREATE を持つようにすることです。つまり、チームメンバーによって生成された tables は、チーム内でのみ共有できます。

次の SQL 構文を使用して、table へのアクセスをセキュリティで保護できます。

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 構文に示すように、セカンダリ schema の動的ビューを使用して、columns へのアクセスをセキュリティで保護できます。

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 構文に示すように、セカンダリ schema の動的ビューを使用して行へのアクセスをセキュリティで保護できます。

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 >;

また、行フィルターとcolumnsマスクを使用して、ユーザーにtablesへのセキュリティで保護されたアクセス権をgrantすることもできます。詳細については、「行フィルターと column マスクを使用して機密 table データをフィルター処理する」を参照してください。

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

コンピューティングの構成を管理する

Databricks では、コンピューティングポリシーを使い、一連のルールに基づいてクラスターを構成する能力をlimitすることをお勧めします。コンピューティングポリシーを使用すると、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 監査ログの一部として配信されます。

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

Databricks Data Intelligence Platform に関連する重要なイベントを完全に視覚化する方法の詳細については、監査ログを使った Databricks Data Intelligence Platform の監視に関するブログをご覧ください。

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

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

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

詳細情報

SetUnity Catalog の設定と管理
Delta Sharing とは
Hive とを Unity にアップグレードする

次の方法で共有

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

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

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

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

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

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

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

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

外部の場所とストレージ credentials を構成する

データを整理する

外部の場所、外部tables、外部volumesを管理する

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

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

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

アクセスの制御の構成

コンピューティングの構成を管理する

アクセスを監査する

詳細情報

フィードバック

その他のリソース

次の方法で共有

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

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

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

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

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

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

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

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

外部の場所とストレージ credentials を構成する

データを整理する

外部の場所、外部tables、外部volumesを管理する

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

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

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

アクセスの制御の構成

コンピューティングの構成を管理する

アクセスを監査する

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

詳細情報

フィードバック

その他のリソース

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

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