背景・目的
Databricksでは、Unity Catalogというものがあります。本記事では特徴を整理し、Unity Catalogを作成します。
まとめ
- Unity CatalogはDatabricksのデータガバナンスソリューションの一つ。
- Unity Catalogを使用すると、複数のDtabricks ワークスペースで下記の機能が可能になる。
- 一元化されたアクセス制御
- 監査
- リネージ
- データ検出機能
概要
データガバナンス
Unity Catalog は、Databricksのガバナンスソリューションの一つです。
ここでは、Unity Catalogの整理の前にDatabricksにおけるデータガバナンスについて調べます。
Databricksではデータガバナンスを構成するソリューションには、下記のものがあげられています。
| ソリューション | 説明 |
|---|---|
| Unity Catalog | レイクハウスのデータとAIのためのきめ細かいガバナンスソリューション。データアクセスを管理及び監査するための一元的な場所を提供し、データのセキュリティとガバナンスを簡素化出来る |
| Data Explorer | データ、スキーマ（データベース）、テーブル、アクセス許可の探索と管理に使用できるデータディスカバリーUI |
| 監査ログ | Databricksアカウントとワークスペース全体の使用パターンに関する詳細を監視できる。 |
※Hive metastoreテーブルアクセスコントロールと、認証情報パススルーはレガシーなソリューションという位置づけのようなので省略しています。
データガバナンスのベストプラクティス
データガバナンスの必要性と、組織全体にこれらの手法を実装するために使用できるベストプラクティスと戦略について記載します。
データガバナンスが重要な理由
データガバナンスは、データが価値をもたらし、ビジネス戦略をサポートすることを保証するための監視です。 データガバナンスは、組織内のデータ資産を安全に管理するために実装されたポリシーとプラクティスをカプセル化します。 データの量と複雑さが増すにつれて、ますます多くの組織が、コアビジネスの成果を確保するためにデータガバナンスを検討しています。
- データに価値をもたらし、ビジネス戦略をサポートすることを保証するとのこと。
- 組織内のデータ資産を安全に管理するために実装されたポリシーとプラクティスをカプセル化する。
- データ量と複雑さが増すことに伴い、データガバナンスも必要性が増している。
- データガバナンスにより得られる効果は下記のとおりです。
- アナリティクスと機械学習の基盤としての一貫した高いデータ品質。
- 結果を得るまでの時間の短縮
- 組織内のすべての人がデータドリブンの意思決定を行えるようになる。
- HIPPA、FedRAMP、GDPR、CCPA などの業界規制のリスクとコンプライアンスをサポートする。
- コストの最適化 (たとえば、ユーザーが大規模なクラスターを起動できないようにしたり、高価な GPU インスタンスを使用するためのガードレールを作成したりします)。
優れたデータ ガバナンス ソリューションとはどのようなものか
データドリブン企業は通常、レイクハウスで分析用のデータ アーキテクチャを構築します。データ レイクハウスは、データ レイクに保存されている膨大な量のデータに対して、効率的かつ安全なデータ エンジニアリング、機械学習、データ ウェアハウジング、ビジネス インテリジェンスを直接可能にするアーキテクチャです。データ レイクハウスのデータ ガバナンスは、次の主要な機能を提供します。
レイクハウスアーキテクチャを採用することで、データレイクに保存されている膨大な量のデータに対して効率的に様々な事が可能になる。
レイクハウスのデータガバナンスは下記の主要な機能を提供します。
| 機能 | 説明 |
|---|---|
| Unified catalog | 各データのオブジェクトのメタデータに加えて、全てのデータ、機械学習モデル、Analyticsアーティファクトが格納される。既存のHive metasotreなどの他のデータカタログのデータも含めることが可能 |
| Unified data access controls | すべてのデータ資産とすべてのクラウドに渡る単一の統一されたアクセス許可モデル。個人を特定できる情報の属性ベースのアクセス制御（ABAC）が含まれる。 |
| Data isolation | アクセスと監査を一元的に管理する機能を保持したまま、複数のレベル（環境、ストレージ、データオブジェクト）で独立した制御が可能。 |
| Data auditing | アラートと監視機能で一元的に監査可能 |
| Data quality management | 組み込みの品質管理機能で、テスト、モニタリング、堅牢なデータ品質管理により、ダウンストリームBI,アナリティクス、機械学習のワークロードで正確で有用なデータを利用できるようにする。 |
| Data lineage | レイクハウス内のデータがソースからコンシュームまでどのように流れるか可視化する。 |
| Data discovery | 各ロールが関連するデータを素早く見つけて参照し、価値実現までの時間を短縮できる |
| Data sharing | クラウドやプラットフォーム間で共有できる。 |
データガバナンス
Unity CatalogとDelta Sharingを使用することでデータとAIのいち原価されたガバナンスを提供できる。
- Uniti Catalog
- データアクセス管理と監査するための一元的な場所を提供することで、データのセキュリティとガバナンスを簡素化できる
- Delta Sharing
- 使用するコンピューティングプラットフォームに関係なく、他の組織や組織内の他のチームと安全なデータ共有を行う事が可能。
Identity configuration
優れたデータガバナンスの実現のために、ID基盤が必要。IDのベストプラクティスは別途整理します。
Unity Catalogとは
上記では、Databricks上で実現するデータガバナンスについて、解説しました。
ここでは、データガバナンスのソリューションの一つであるUnity Catalogについて整理します。
Unity Catalogの概要
複数のDtabricks ワークスペースで下記の機能が利用できます。
- 一元化されたアクセス制御
- 監査
- リネージ
- データ検出機能
※出典 ： Databricksデータガバナンスガイド＞Unity Catalogとは＞Unity Catalogの概要
Unity Catalogの主要な機能は下記のとおりです。
| 機能 | 説明 |
|---|---|
| Define once, secure everywhere | データアクセスポリシーを1か所で管理可能 |
| Standards-compliant security model | 権限付与は、ANSI SQLによりカタログ、DB（スキーマ）、テーブル、ビューに対して可能。 |
| Built-in auditing and lineage | Unity Catalog は、データへのアクセスを記録するユーザーレベルの監査ログを自動的にキャプチャする。Unity Catalogは、すべての言語とペルソナでデータアセットがどのように作成および使用されるかを追跡するリネージデータもキャプチャする。 |
| Data discovery | Unity Catalogではデータアセットにタグを付けて文書化でき、またデータ利用者がデータを見つけるのに役立つ検索インターフェースを利用できる。 |
| System tables (Public Preview) | Unity カタログを使用すると、監査ログ、課金対象の使用状況、リネージ等、アカウントの運用データに簡単にアクセスしてアクセスが可能 |
Unity Catalogオブジェクトモデル
Unity Catalogでは、データ オブジェクトの階層は下記のとおりになっています。
| 構成要素 | 説明 |
|---|---|
| Metastore | メタデータのトップレベルコンテナ。各メタストアではデータを管理するための3つのレベルの名前空間が公開される。（catalog.schema.table） |
| Catalog | オブジェクトの1番目のレイヤ。データアセットの整理に使用される |
| Schema | DBとも呼ばれる。テーブルとビューが格納される |
| Table | external（クラウドストレージ内の外部の場所に格納される。）と、マネージドテーブル（Databricks用に明示的に作成したクラウドストレージ内のストレージコンテナに格納される）を選択できる |
| View | スキーマ内に含まれる1つ以上のテーブルから作成された読み取り専用オブジェクト |
| Model | 登録済みモデル。スキーマ内に含まれる登録済みモデル。 |
| Function | スキーマ内に含まれるユーザ定義関数。 |
| Volume | Volumeは、external（クラウドストレージ内の外部の場所に格納される。）と、マネージドテーブル（Databricks用に明示的に作成したクラウドストレージ内のストレージコンテナに格納される）を選択できる |
| Storage credential | Unity Catalogメタストア内に含まれるクラウドストレージへのアクセスを提供するCredential をカプセル化するオブジェクト |
| External location | Storage credential への参照と、Unity Catalogメタストア内に含まれるクラウドストレージパスを含むオブジェクト |
| Share | Dalta Sharingを使用して共有するテーブルの論理グループ。 |
| Recipient | Delta Sharingを使用してデータを共有できる組織またはユーザのグループを識別するオブジェクト。 |
| Provider | Delta Sharingを使用してデータを共有できる組織またはグループを識別するオブジェクト |
| Connection | レイクハウスフェデレーションで外部のデータベースシステムにアクセスするためのパスとCredentialを指定するオブジェクト |
Metastores
メタストアは、 Unity Catalogのオブジェクトの最上位コンテナです。 これは、データ資産 (テーブルとビュー) とそれらへのアクセスを制御するアクセス許可に関するメタデータを格納します。 Databricks アカウント管理者は、操作するリージョンごとに 1 つのメタストアを作成し、同じリージョン内の Databricks ワークスペースに割り当てる必要があります。 ワークスペースで Unity Catalogを使用するには、 Unity Catalog メタストアがアタッチされている必要があります。
- メタデータを格納するもの
- リージョンに一つのメタストア
- 同一リージョン内のワークスペースにアサインする
- 各メタストアは、AWS アカウントの S3 バケット内のマネージドストレージの場所を使用して設定される。
Managed storage
アカウント管理者がメタストアを作成するときは、 マネージドストレージとして使用するために、AWS アカウントの S3 バケット内のストレージの場所を関連付ける必要があります。 Unity Catalog では、管理ストレージの場所をカタログおよびスキーマに関連付けることもできます。
- メタストアを作成するときAWSアカウントのS3バケット内のストレージの場所を関連付ける。
Storage CredentialとExternal Location
外部テーブル、外部ボリューム、マネージドストレージの基盤となるクラウドストレージへのアクセスを管理するために、Unity Catalog には次のオブジェクトタイプが導入されています。
- ストレージ資格情報は、クラウドストレージにアクセスするための長期的なクラウド資格情報をカプセル化します。たとえば、S3バケットにアクセスできるIAMロールなどです。
- 外部ロケーションには、ストレージ資格情報とクラウドストレージパスへの参照が格納されています。
- Credentialとストレージパスをカプセル化したもの
Catalog
データセットの整理に利用。ユーザは、use catalogデータ権限が割り当てられているすべてのカタログを表示可能。
Schema
データベースとも言われる。テーブルとビュー等を整理する
Volume
ボリュームには、任意の形式で格納されたデータのディレクトリとファイルが含まれている。
ボリュームはデータへの非表形式のアクセスを提供するため、ボリューム内のファイルをテーブルとして登録できない。
Managed Volume
ファイルが含まれているスキーマの Unity Catalog 既定のストレージの場所にファイルを格納する。
External Volume
Unity Catalog 外部の場所に登録され、データ移行を必要とせずにクラウドストレージ内の既存のファイルへのアクセスを提供する。 ユーザーが外部ボリュームを作成するには、外部ロケーションに対する CREATE EXTERNAL VOLUME 権限が必要。
Table
データが格納されている。
Managed Table
Unity Catalogでテーブルを作成するデフォルトの方法。Unity Catalog はこれらのテーブルのライフサイクルとファイルレイアウトを管理する。メタストアの作成時に設定したルートストレージの場所に格納される。
デフォルトでは、Deltaテーブル形式になる。
External Table
データのライフサイクルとファイルレイアウトがUnity Catalogで管理されていないテーブル。
下記の場合に、使用する。
- 大量の既存データをUnity Catalogに登録する場合
- Databricksクラスタ、DatabricksSQLウェアハウスの外部にあるツールを使用してデータに直接アクセスする場合
- 下記のファイル形式を使用できる
- DELTA
- CSV
- JSON
- AVRO
- PARQUET
- ORC
- TEXT
View
メタストア内の 1 つ以上のテーブルとビューから作成される読み取り専用オブジェクト。
Model
MLflow モデルレジストリに登録されている機械学習モデルを指している。
Unity Catalogでモデルを作成するには、カタログまたはスキーマに対する CREATE MODEL 権限が必要。
Unity CatalogのID管理
DatabricksアカウントのIDを使用して、ユーザー、サービスプリンシパル、グループを解決し、権限を適用する。
※詳細は、ユーザー、サービスプリンシパル、およびグループを管理するを参照。
Unity Catalogの管理者ロール
Unity Catalogの管理には、次の管理者ロールが必要になる。
| ロール | 説明 |
|---|---|
| アカウント管理者 | ID、クラウドリソース、ワークスペース、Unity Catalogメタストアを管理できる |
| メタストア管理者 | カタログの作成、テーブルのクエリを実行できるユーザ、メタストア内のすべてのセキュリティ保護可能なオブジェクト権限と所有権を管理できる |
| ワークスペース管理者 | Databricksワークスペースへのユーザの追加、ワークスペース管理者ロールの割り当て、ワークスペース内のオブジェクトと機能へのアクセス管理ができる。 |
Unity Catalogのデータ権限
Unity Catalogでは、データはデフォルトで保護されます。最初は、ユーザーはメタストア内のデータにアクセスできません。アクセスは、メタストア管理者、オブジェクトの所有者、またはオブジェクトが格納されたカタログまたはスキーマの所有者のいずれかが許可できます。Unity Catalogのセキュリティ保護可能なオブジェクトは階層構造で、権限は上位から下位に継承されます。
- データはデフォルトで保護される。
- 保護可能なオブジェクトは階層構造で、上位から下位の継承さえっる。
Unity Catalogのクラスターアクセスモード
Unity Catalogのデータにアクセスするには、クラスターを正しい アクセスモードで構成する必要があります。Unity Catalog はデフォルトで安全です。 クラスターが Unity Catalog 対応アクセスモードのいずれか (つまり、共有または割り当て) で構成されていない場合、クラスターは Unity Catalog内のデータにアクセスできません。
Unity Catalogのデータリネージ
Unity Catalogを使用すると、DatabricksクラスターまたはSQLウェアハウスで実行される任意の言語の複数のクエリにまたがるランタイムデータリネージをキャプチャできます。リネージは列レベルまでキャプチャされます。このリネージには、クエリに関連するノートブック、ワークフロー、ダッシュボードが含まれます。
- リネージは、クラスタ、SQLWarehouseで実行される任意の言語の複数のクエリまたがるランタイムのリネージをキャプチャできる
- 列レベルまでキャプチャされる
Lakehouse Federation and Unity Catalog
レイクハウスフェデレーションは、Databricksのクエリーフェデレーションプラットフォームです。 クエリー フェデレーション という用語は、すべてのユーザーを統一されたシステムに移行しなくても、ユーザーとシステムが複数のサイロ化された Data に対してクエリーを実行できるようにする機能のコレクションを表します。
Databricks は、 Unity Catalog を使用してクエリー フェデレーションを管理します。 Unity Catalog を使用して、一般的な外部データベース システムへの読み取り専用 接続 を構成し、外部データベースをミラーリングする 外部カタログ を作成します。 Unity Catalog のデータガバナンスとデータリネージ ツールを使用すると、Databricks ワークスペース内のユーザーが作成したすべてのフェデレーション クエリーのデータ アクセスが管理および監査されます。
- 外部データベースに対して、外部カタログを作成する。
- クエリのデータアクセスが監査される
サポートされているデータファイル形式
- Managed tables delta テーブル形式を使用する必要があります。
- External tables 、 delta、CSV、JSON、avro、parquet、ORC、または textを使用できます。
制限
一般的な制限
Scala、R、および機械学習にDatabricks Runtimeを使用するワークロードは、シングルユーザーアクセスモードを使用するクラスターでのみサポートされます。これらの言語のワークロードでは、行レベルおよび列レベルのセキュリティでのダイナミックビューの使用はサポートされていません。
Databricks Runtime 13.1 以降では、既存のUnity CatalogマネージドテーブルからUnity Catalog マネージドテーブルを作成するために、シャロークローンがサポートされています。Databricks Runtime 13.0 以前では、Unity Catalogはシャロンクローンをサポートしていません。「Unity Catalogマネージドテーブルのシャロークローン」を参照してください。
バケット化は、Unity Catalogテーブルではサポートされません。Unity Catalogでバケットテーブルを作成しようとするコマンドを実行すると、例外がスローされます。
- Bucktingはサポートされない
一部のクラスターのみがUnity Catalogにアクセスし、他のクラスターがアクセスしない場合、複数のリージョンのワークスペースから同じパスまたはDelta Lakeテーブルに書き込むと、パフォーマンスの信頼性が低下する可能性があります。
- Unity Catalogの使用差異によるコンカレンシーで、複数リージョンワークスペースから同じパスに書き込むとパフォーマンス劣化が起こり得る
ALTER TABLE ADD PARTITIONなどのコマンドを使用して作成されたカスタムパーティションスキームは、Unity Catalogのテーブルではサポートされていません。Unity Catalogは、ディレクトリスタイルのパーティション分割を使用するテーブルにアクセスできます。
- Add PartitionはUnity Catalogではサポt−押されない
Unity CatalogへのDataFrame書き込み操作の上書きモードは、Deltaテーブルでのみサポートされ、他のファイル形式ではサポートされません。ユーザーは、親スキーマに対するCREATE権限を持っている必要があり、また既存のオブジェクトの所有者であるか、オブジェクトに対するMODIFY権限を持っている必要があります。
- Unity CatalogのDataFrameのOverwriteはDeltaテーブルのみサポート
Spark 送信ジョブは、シングル ユーザー アクセスでサポートされますが、共有クラスターではサポートされません。
- ジョブは共有クラスタではサポートされない。
Databricks Runtime 13.1 以前では、Spark (applyInPandas および mapInPandas) で UDAF、UDTF、 Pandas などの Python UDF を使用することはできません。Databricks Runtime 13.2 以降では、Python UDF がサポートされています。
- 過去バージョンではPython UDFは使用できない
以前にワークスペースで作成されたグループ (つまり、ワークスペース レベルのグループ) は、 Unity Catalog GRANT ステートメントでは使用できません。 これは、複数のワークスペースにまたがることができるグループの一貫したビューを確保するためです。 GRANT ステートメントでグループを使用するには、アカウント レベルでグループを作成し、プリンシパルまたはグループ管理の自動化 (SCIM、Okta および AAD コネクタ、Terraform など) を更新して、ワークスペース エンドポイントではなくアカウント エンドポイントを参照します。 Difference between account groups and workspace-local groupsを参照してください。
標準のScalaスレッドプールはサポートされていません。代わりに、org.apache.spark.util.ThreadUtilsの特殊なスレッドプール（org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPoolなど）を使用します。ただし、ThreadUtilsのスレッドプール（ThreadUtils.newForkJoinPoolおよびScheduledExecutorServiceスレッドプール）はサポートされません。
- Scalaスレッドプールはサポートされない
Unity Catalog ベストプラクティス
データ ガバナンスのニーズを満たすために Unity Catalog と Delta Sharing を使用するための推奨事項について説明します。
データ分離モデルを計画する
組織が利用する場合、多くの場合、環境間 (開発と運用など) 間または組織の運用単位間にデータ分離境界が必要。
- ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセスできます。
- データは、指定された人またはチームのみが管理できます。
- データはストレージ内で物理的に分離されています。
- データには、指定された環境でのみアクセスできます。
データの分離の必要性により、データガバナンスとコラボレーションの両立が必要になる。DatabricksではこれをUnity Catalogにより解決する。
ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセス可能
通常、規制や内部の要件によりアクセスに関する厳格な要件がある。Unity Catalogが提供するコントロールを使用することでユーザは表示やクエリする権限を持つデータのみを表示およびクエリできる。
指定された人またはチームのみがデータを管理可能
Unity Catalog では、集中型ガバナンス モデルと分散型ガバナンス モデルのどちらかを選択が可能。
| ガバナンス管理者 | 特徴 | |
|---|---|---|
| 集中型 | メタストアの所有者 | 任意のオブジェクトの所有権を取得し、アクセス許可を付与および取り消すことが可能 |
| 分散型 | 任意の所有者 | 所有するすべての資産についてガバナンス管理が可能. 他のドメインと独立している |
※出典 Unity Catalog>Unity Catalogのベストプラクティスから引用
データはストレージ内で物理的に分離されている
Databricks アカウント管理者が Unity Catalog メタストアを作成すると、マネージドテーブルのデフォルトの場所として 1つのクラウド ストレージの場所とCredentialが提供される。
ただし、下記のような理由からデータを物理的に分離する必要がある組織は、カタログレベルとスキーマレベルで物理的に分離されたデータストレージの場所を割り当てることが可能。
- 規制
- SDLCスコープ間
- ビジネスユニット間
- コスト配分
指定された環境でのみデータにアクセス可能
組織とコンプライアンスの要件では、多くの場合、個人データなどの特定のデータに特定の環境でのみアクセスできるように指定されている。 また、運用データを開発環境から分離したり、特定のデータ セットとドメインが結合されないようすることも可能。
Databricks では、下記の整理になっている。
- ワークスペースがプライマリデータ処理環境
- カタログがプライマリ データ ドメイン
Unity Catalog 、メタストア管理者とカタログ所有者は、カタログをワークスペースに割り当てる (バインドする) ことが可能。
これらの環境対応バインディングを使用することで、ユーザーに付与されたデータ・オブジェクトに対する特定の特権に関係なく、ワークスペース内で特定のカタログのみが使用可能になる。
Unity Catalog メタストアの構成
メタストアは、 Unity Catalogのオブジェクトの最上位コンテナです。 メタストアは、データアセット(テーブル、ビュー、ボリューム)と、Unity Catalog によって管理されるその他のセキュリティ保護可能なオブジェクトを管理します。
メタストアを構成するためのヒントは下記の通り。
- Databricks ワークスペースがあるリージョンごとに 1 つのメタストアを設定する必要がある
- 1 つのリージョンメタストアにアタッチされているすべてのワークスペースは、メタストアによって管理されるデータにアクセスできる。 メタストア間でデータを共有する場合は、 Delta Sharingを使用する。
- 各メタストアは、管理対象テーブルや管理対象ボリュームなどの管理対象オブジェクトに使用できるルート・ストレージの場所で構成される。
- この管理対象ストレージの場所に直接アクセスできるユーザーがいないことを確認する必要がある。
- このストレージの場所へのアクセス権を付与すると、ユーザーが Unity Catalog メタストアのアクセス制御をバイパスし、監査機能を中断する可能性がある。
- これらの理由から、メタストアのルート ストレージは専用のバケットにする必要がある。
- DBFSルートファイルシステムでもあるバケット、または以前に DBFSルートファイルシステムであったバケットは再利用しないこと。
- カタログ レベルとスキーマ レベルで管理ストレージを定義し、メタストアのルート ストレージの場所をオーバーライドすることもできる。
- Unity Catalogが有効になっているワークスペースのワークスペース管理者の権限を理解し、既存のワークスペース管理者の割り当てを確認する必要がある。
- ワークスペース管理者は、ユーザーとサービスプリンシパルの追加、クラスターの作成、他のユーザーのワークスペース管理者への委任など、ワークスペースの操作を管理できる。
- ワークスペース管理者は、メタストア管理者と同じ方法で Unity Catalog に格納されているデータへのアクセスを管理することはできないが、ジョブの所有権の管理やノートブックの表示などのワークスペース管理タスクを実行する機能は可能。
- Unity Catalogに登録されているデータに間接的にアクセスできる可能性があります。 ワークスペース管理者は特権ロールであり、慎重に配布する必要がある。
- ワークスペースを使用してユーザーデータアクセスを分離する場合は、ワークスペースとカタログのバインドを使用できる。
- ワークスペースとカタログのバインドを使用すると、ワークスペースの境界によってカタログへのアクセスを制限できる。
- たとえば、ワークスペース管理者とユーザーが、 prod_catalog の運用ワークスペース環境 ( prod_workspace) からのみ運用データにアクセスできるようにすることができる。
- デフォルトでは、現在のメタストアに接続されているすべてのワークスペースとカタログを共有する。
外部の場所とストレージ資格情報を構成する
外部の場所 を使用すると、Unity Catalog はユーザーに代わってクラウドテナント上のデータを読み書きできる。 外部の場所は、クラウド ストレージへのパスとして定義され、その場所へのアクセスに使用できる ストレージ資格情報 と組み合わされる。
外部ロケーションを使用して、 Unity Catalogの外部テーブルおよび外部ボリュームを登録できる。 これらのエンティティのコンテンツは、ユーザーがボリュームまたはテーブルを作成するときに参照される外部の場所のサブパスに物理的に配置される。
ストレージ資格情報は、クラウド ストレージへのアクセスを提供する長期的なクラウド 資格情報 をカプセル化する。
たとえば、AWS では、S3 バケットにアクセスするように IAMロールを設定できる。
外部の場所を構成するためのヒント:
- 外部の場所は、ストレージ資格情報とストレージ・パスを組み合わせることにより、ストレージ・アクセスの強力な制御と監査可能性を提供する。
- ユーザーが Unity Catalog によって提供されるアクセス制御をバイパスできないようにするには、外部の場所として使用されているバケットに直接アクセスできるユーザーの数を制限する必要がある。
- 同じ理由で、ストレージ アカウントが外部の場所としても使用されている場合は、DBFS にマウントしないこと。
- Databricks では、 Data Explorer を使用して、クラウドストレージの場所のマウントを Unity CatalogのExternal Locationに移行することを推奨する。
データを整理する
Databricks では、カタログを使用して、組織の情報アーキテクチャ全体で分離を提供することを推奨する。多くの場合、これは、カタログがソフトウェア開発環境のスコープ、チーム、または部署に対応することを意味する。
ワークスペースをデータ分離ツールとして使用する場合 (たとえば、運用環境と開発環境に異なるワークスペースを使用する場合や、機密性の高いデータを操作するために特定のワークスペースを使用する場合)、カタログを特定のワークスペースにバインドすることも可能。 これにより、指定したデータのすべての処理が適切なワークスペースで処理されます。
※出典 Unity Catalog>Unity Catalogのベストプラクティスから引用
- 管理対象オブジェクト
- Unity Catalogでデータ オブジェクトを作成するためのデフォルトの方法
- Unity Catalog 、これらのセキュリティ保護可能なリソースのライフサイクルとファイル レイアウトを管理する。
- Databricks の外部でツールを使用して、マネージ テーブルまたはボリューム内のファイルを直接操作しないこと。
- デフォルトでは、マネージド テーブルとボリュームは、メタストアの作成時に構成したルート ストレージの場所に格納されれる。
- オプションで、カタログ・レベルまたはスキーマ・レベルで管理対象ストレージ・ロケーションを指定して、ルート・ストレージ・ロケーションをオーバーライドできる。
- Managed Table とVolumesは、外部の場所とストレージ資格情報を作成および管理するためのオーバーヘッドなしに、コンテンツの管理された場所をプロビジョニングする場合に便利なソリューション。
- 外部オブジェクト
- データのライフサイクルとファイル・レイアウトが Unity Catalogによって管理されないセキュリティ保護可能なリソース
- 外部ボリュームとテーブルは外部の場所に登録され、データコピーアクティビティを必要とせずにクラウドストレージにすでに存在する多数のファイルへのアクセスを提供する。
- 他のシステムによって生成されたファイルがあり、Databricks 内からアクセスできるようにステージングする場合、または Databricks の外部のツールがこれらのファイルに直接アクセスする必要がある場合は、外部オブジェクトを使用する。
- 外部テーブルは、 Delta Lake および Parquet、JSON、CSV などの他の多くのデータ形式をサポートしている。
- 管理対象ボリュームと外部ボリュームの両方を使用して、任意の形式 (構造化、半構造化、または非構造化) のファイルにアクセスして保管することができる。
外部ロケーション、外部テーブル、および外部ボリュームの管理
下図は、1 つのクラウドストレージバケットのファイルシステム階層を表しており、1 つのストレージ認証情報を共有する 4 つの外部ロケーションがあることを示している。
※出典 Unity Catalog>Unity Catalogのベストプラクティスから引用
外部の場所の使用に関する推奨事項
外部の場所に対するアクセス許可を付与するための推奨事項は、下記の通り
-
外部の場所を作成する権限は、Unity Catalog とクラウドストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみ付与する。
- 外部ロケーションは、 Unity Catalog 内からクラウドストレージ内の広範な場所 (バケット全体 (s3://mybucket) や広範なサブパス (s3://mybucket/alotofdata) など) へのアクセスを提供する。
- その目的は、クラウド管理者がいくつかの外部の場所の設定に関与し、それらの場所を管理する責任を組織内の Databricks 管理者に委任できるようにすること。
- Databricks 管理者は、外部の場所の下の特定のプレフィックスで外部ボリュームまたは外部テーブルを登録することで、外部の場所をより詳細なアクセス許可を持つ領域にさらに整理できる。
- 外部の場所は非常に包括的であるため、Databricks では、Unity Catalog とクラウド ストレージ間の接続を設定するタスクである管理者、または信頼できるデータエンジニアにのみ CREATE EXTERNAL LOCATION アクセス許可を付与することを推奨する。
- 他のユーザーにより詳細なアクセスを提供するために、Databricks では、外部の場所の上に外部テーブルまたはボリュームを登録し、ボリュームまたはテーブルを使用してデータへのアクセス権をユーザーに付与することを推奨する。
- 表とボリュームはカタログとスキーマの子であるため、カタログ管理者またはスキーマ管理者はアクセス許可を最終的に制御できる。
-
外部の場所に対する一般的な READ FILES または WRITE FILES アクセス許可をエンドユーザーに付与しないこと。
- ボリュームが利用できるようになったため、ユーザーはテーブル、ボリューム、または管理された場所の作成以外に外部の場所を使用しないこと。
- データサイエンスやその他のTable形式以外のデータのユースケースのパスベースのアクセスに外部の場所を使用しないこと。
- ボリュームは、SQL コマンド、dbutils、Spark APIs、REST APIs、Terraform、およびファイルの参照、アップロード、ダウンロードのためのユーザー インターフェイスを使用したファイルの操作をサポートする。
- さらに、ボリュームは、 /Volumes////のローカルファイルシステムからアクセスできるFUSEマウントを提供する。 FUSEマウントを使用すると、データサイエンティストやMLエンジニアは、多くの機械学習やオペレーティングシステムライブラリで必要とされるように、ローカルファイルシステムにあるかのようにファイルにアクセスできる。
- 外部の場所にあるファイルへの直接アクセスを許可する必要がある場合 (たとえば、ユーザーが外部テーブルまたはボリュームを作成する前にクラウド ストレージ内のファイルを探索する場合)、 READ FILESを付与できる。WRITE FILES を付与するユースケースは例外である。
-
外部の場所を使用して、次の操作を行う必要がある。
- CREATE EXTERNAL VOLUME または CREATE TABLE コマンドを使用して外部テーブルとボリュームを登録
- 特定のプレフィックスで外部テーブルまたはボリュームを作成する前に、クラウドストレージ内の既存のファイルを探索する。
- READ FILES 特権は前提条件
- 登録するメタストアのルートバケットではなく、カタログとスキーマの管理ストレージとしての場所。
- CREATE MANAGED STORAGE 特権は前提条件
-
外部の場所を使用するためのその他の推奨事項:
- パスの重複の競合を回避すること。外部の場所のルートに外部ボリュームまたはテーブルを作成しないこと。
- 外部ロケーションのルートに外部ボリュームまたはテーブルを作成する場合、外部ロケーションに追加の外部ボリュームまたはテーブルを作成することはできない。代わりに、外部ロケーション内のサブディレクトリに外部ボリュームまたはテーブルを作成する。
外部ボリュームの使用に関する推奨事項
外部ボリュームを使用して、次の操作を行う必要がある。
- 登録する ETL パイプラインやその他の data engineering 活動の初期段階での処理をサポートするために、外部システムによって生成された生データのランディング エリア。
- 登録する インジェストのステージング場所 (たとえば、 Auto Loader、COPY INTO、または CTAS (CREATE TABLE AS) ステートメントを使用する。
- 管理対象ボリュームがオプションとしてない場合に、データサイエンティスト、データアナリスト、および機械学習エンジニアが探索的データ分析やその他のデータサイエンスタスクの一部として使用できるファイル保存場所を提供する。
- Databricks ユーザーに、監視システムや IoT デバイスによってキャプチャされた非構造化データ (画像、オーディオ、ビデオ、PDF ファイルなど) の大規模なコレクションや、ローカル依存関係管理システムや CI/CD パイプラインからエクスポートされたライブラリ ファイル (JAR やホイール) など、他のシステムによってクラウド ストレージに生成および預けられた任意のファイルへのアクセス権を付与する。
- ログ記録やチェックポイント・ファイルなどの運用データを、管理対象ボリュームがオプションにない場合に保管する。
- 外部ボリュームの使用に関するその他の推奨事項
- Databricks では、1 つのスキーマ内の 1 つのExternal Locationから外部ボリュームを作成することを推奨する。
外部テーブルの使用に関する推奨事項
マネージド テーブルを作成することがオプションではない場合は、外部テーブルを使用して、クラウド ストレージに格納されているデータに対して通常のクエリ パターンをサポートする必要がある。
外部テーブルの使用に関するその他の推奨事項は下記の通り。
- Databricks では、1 つのスキーマ内の 1 つの外部の場所から外部テーブルを作成することを推奨する。
- Databricks では、整合性の問題のリスクがあるため、テーブルを複数のメタストアの外部テーブルとして登録しないことを強く推奨する。
- たとえば、1 つのメタストアでスキーマを変更しても、2 番目のメタストアでは登録されない。
- メタストア間でデータを共有するには、 Delta Sharing を使用する。
アクセス制御を構成する
Unity Catalog 内のセキュリティ保護可能な各オブジェクトには所有者がいる。オブジェクトを作成するプリンシパルが初期所有者になる。
オブジェクトの所有者は、テーブルに対する SELECT や MODIFY など、オブジェクトに対するすべての権限と、セキュリティ保護可能なオブジェクトに対する権限を他のプリンシパルに付与する権限を持つ。 セキュリティ保護可能なオブジェクトの所有者のみが、そのオブジェクトに対する特権を他のプリンシパルに付与する権限を持つ。 したがって、すべてのオブジェクトの所有権を、そのオブジェクトに対する許可の管理を担当 するグループに 構成することがベスト・プラクティス。
所有者とメタストアの両方の管理者は、セキュリティ保護可能なオブジェクトの所有権をグループに譲渡できる。 さらに、オブジェクトがカタログ内 (テーブルやビューなど) に含まれている場合、カタログとスキーマの所有者はオブジェクトの所有権を変更できる。
Unity Catalog 内のセキュリティ保護可能なオブジェクトは階層構造であり、特権は下位に継承される。
つまり、カタログまたはスキーマに対する特権を付与すると、カタログまたはスキーマ内の現在および将来のすべてのオブジェクトに特権が自動的に付与される。
テーブルまたはビューからデータを読み取るには、ユーザーに次の権限が必要。
- SELECT テーブルまたはビュー上
- USE SCHEMA テーブルを所有するスキーマ
- USE CATALOG スキーマを所有するカタログ
USE CATALOG 権限付与対象ユーザーに対し、子オブジェクトにアクセスするためにカタログを走査できるようにし USE SCHEMA権限付与対象ユーザー子オブジェクトにアクセスするためにスキーマを走査できるようにする。
たとえば、テーブルからデータを選択するには、ユーザーはそのテーブルに対する SELECT 権限と、親カタログに対する USE CATALOG 権限、およびその親スキーマに対する USE SCHEMA 権限を持っている必要がある。
したがって、この特権を使用して、データ名前空間のセクションへのアクセスを特定のグループに制限できる。
一般的なシナリオは、チームごとにスキーマを設定し、そのチームだけがスキーマに USE SCHEMA と CREATE を設定すること。 つまり、チーム メンバーが作成したテーブルは、チーム内でのみ共有できる。
クラスター構成の管理
Databricks では、クラスター ポリシーを使用して、一連のルールに基づいてクラスターを構成する機能を制限することを推奨する。
クラスターポリシーを使用すると、Unity カタログが有効なクラスターのみを作成するようにアクセスを制限できる。
クラスター ポリシーを使用すると、使用可能な選択肢が減り、ユーザーのクラスター作成プロセスが大幅に簡素化され、ユーザーがシームレスにデータにアクセスできるようになる。 クラスターポリシーを使用すると、クラスターごとの最大コストを制限することでコストを制御することも可能。
アクセス制御の整合性を確保し、強力な分離保証を適用するために、Unity Catalog はコンピュートリソースにセキュリティ要件を課している。 このため、 Unity Catalog ではクラスターのアクセスモードの概念を導入している。 Unity Catalog はデフォルトで安全。クラスターが適切なアクセスモードで構成されていない場合、クラスターは Unity Catalog内のデータにアクセスできない。
Databricks では、クラスターを共有する場合は共有アクセス モードを使用し、自動化されたジョブと機械学習ワークロードにはシングル ユーザー アクセス モードを使用することを推奨する。
アクセスの監査
完全なデータガバナンスソリューションでは、データへのアクセスを監査し、アラート機能と監視機能を提供する必要がある。
Unity Catalog はメタストアに対して実行されたアクションの監査ログをキャプチャし、これらのログは Databricks 監査ログの一部として配信される。
監査ログを構成する。これには、Databricks が指定した S3 バケットに監査ログを配信できるように、適切なアクセスポリシーを構成することが含まれる。 監査ログは通常 15 分以内にログに記録される。 Databricks では、アカウント内のすべてのワークスペースに対して同じ監査ログ構成を共有することを推奨する。
Delta Sharingを使用してデータを安全に共有する
Delta Sharing は、使用するコンピューティング プラットフォームに関係なく、他の組織や組織内の他の部門と安全にデータを共有するために Databricks によって開発されたオープン プロトコルである。メタストアで Delta Sharing が有効になっている場合、 Unity Catalog は Delta Sharing サーバーを実行する。
メタストア間でデータを共有するには、 Databricks-to-Databricks Delta Sharingを利用できる。これにより、異なるリージョンのメタストアからテーブルを登録できる。 これらのテーブルは、使用するメタストアに読み取り専用オブジェクトとして表示されます。 これらのテーブルには、 Unity Catalog内の他のオブジェクトと同様にアクセス権を付与できる。
Databricks 間 Delta Sharing を使用してメタストア間で共有する場合は、アクセス制御が 1 つのメタストアに制限されることに注意すること。テーブルなどのセキュリティ保護可能なオブジェクトに許可があり、そのリソースがアカウント内メタストアで共有されている場合、ソースからの許可は宛先共有には適用されない。宛先共有は、独自の許可を設定する必要がある。
実装
概要
Databricksアカウントを設定し、Unity Catalogを使用して最初のテーブルを作成する方法まで試します。
Unity Catalogの使用を開始するを元に試してみます。
要件
- Databricksアカウント管理者で操作できること。
- Databricksアカウントは、プレミアムプランであること
- AWSでは、S3、IAMロールとポリシー、クロスアカウントの信頼関係を作成できる必要がある。
- Unity Catalogで使用するワークスペースが少なくても1つ必要である。
Unity Catalog用にDatabricksアカウントを設定する
DatabricksアカウントでUnity Catalogを使用できるようにするには、次の手順を実行します。
- Unity CatalogがAWSアカウントのマネージドテーブルデータの保存とアクセスに使用できるS3バケットとIAMロールを設定
- 組織が運営を行っているリージョンごとにメタストアを作成。※このメタストアは、Unity Catalog内のすべてのデータのトップレベルコンテナとして機能するもの。
- ワークスペースをメタストアに割り当てる。各ワークスペースには、Unity Catalogで管理するデータの同じビューがあります。
- ユーザー、グループ、およびサービスプリンシパルをDatabricksアカウントに追加する。※既存のDatabricksアカウントの場合、これらのIDは既に存在する。
- （オプション）メタストア管理者ロールをグループに譲渡する。
ユーザーのデータアクセスを設定する
ユーザーのデータアクセスを設定するには、次の手順を実行します。
- ワークスペースで、少なくとも1つのコンピュートリソース（クラスターまたはSQLウェアハウス）を作成する。このコンピュートリソースは、Unity Catalogで保護されているデータオブジェクトに対するgrantステートメントを含むクエリやコマンドを実行するときに使用します。
- 少なくとも1つのカタログを作成します。
- カタログはスキーマ（データベース）を保持し、スキーマ（データベース）はユーザーが操作するテーブルを保持します。
- 少なくとも1つのスキーマを作成します。
- テーブルを作成します。
データ階層のレベル (カタログ、スキーマ、テーブル) ごとに、ユーザー、グループ、またはサービスプリンシパルに権限を付与する。 ※dynamic viewsを使用して、行レベルまたは列レベルの権限を付与することもできます。
AWSでのストレージバケットとIAMロールの設定
このステップでは、AWSアカウントにマネージドテーブルデータを保存してアクセスする際にUnity Catalogで必要となるAWSオブジェクトを作成する。
事前準備
- Unity Catalogを使用するワークスペースが少なくとも1つ必要です。こちらの記事で【Databricks】ワークスペースを作成してみたに書いていますので、よろしければご確認ください。
S3バケットの作成
- AWSで、S3バケットを作成します。
- これは、DatabricksのUnitiy CatalogのManaged Table のルートストレージになる。メタストアごとに専用のS3バケットを使用して、データにアクセスするワークスペースと同じリージョンに配置する。
- デフォルトの格納場所は、カタログとスキーマレベルでオーバーライドできる
- S3バケットでKMS暗号化を有効にする場合は、KMS暗号化キーの名前をコピーしておく。（今回は、SSE-S3で保存するので対応しない。）
IAMロールの作成
S3バケットへのアクセスを許可するIAMロールを作成します。
- このポリシーは、Unity CatalogがDatabricksユーザーに代わってバケット内のデータにアクセスするロールを引き受けることができるように、クロスアカウントの信頼関係を確立する。
- これは、PrincipalセクションのARNによって指定される。。Databricksによって作成されたロールを参照する静的な値のため、変更しないこと。
-
IAMロールの画面で、「ロールの作成」をクリックします。
-
信頼されたエンティティタイプで「カスタム信頼ポリシー」を選択します。
-
下記のカスタム信頼ポリシーを貼り付け、「次へ」をクリックします。※ は、DatabricksのアカウントIDに置き換えます。
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "<DATABRICKS-ACCOUNT-ID>" } } }] } -
アクセス許可の追加は、何もせずに「次へ」をクリックします。
-
IAMロール名を入力し、「ロールを作成」をクリックし、保存します。
信頼関係ポリシーの設定
信頼関係ポリシーを変更し、自己引受型にする。
-
作成した、IAMロールを選択し、「信頼関係」タブ、「信頼関係ポリシーを編集」をクリックします。
-
下記のARNをPrincipalに追加します。下記の値は、それぞれ置き換え、「ポリシーを更新」をクリックします。
- YOUR-AWS-ACCOUNT-ID
- THIS-ROLE-NAME
"arn:aws:iam::<YOUR-AWS-ACCOUNT-ID>:role/<THIS-ROLE-NAME>"
IAMポリシーの設定
IAMポリシーを作成し、上記で作成したIAMロールにアタッチします。
-
IAMポリシーで「ポリシーの作成」をクリックします。
-
JSONエディタに切り替えます。
-
下記のIAMポリシーを貼り付け、「次へ」をクリックします。なお、各項目については、適宜変換、（KMSを使用してない場合は）削除します。
- BUCKET：前のステップで作成したS3バケットの名前
- KMS-KEY：オプション。暗号化が有効になっている場合は、S3バケットの内容を暗号化するKMSキーの名前を指定します。暗号化が無効になっている場合は、IAMポリシーのKMSセクション全体を削除します。
- AWS-ACCOUNT-ID：現在のAWSアカウントのアカウントID（Databricksアカウントではありません）。
- AWS-IAM-ROLE-NAME：前のステップで作成したAWS IAMロールの名前。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket", "s3:GetBucketLocation", "s3:GetLifecycleConfiguration", "s3:PutLifecycleConfiguration" ], "Resource": [ "arn:aws:s3:::<BUCKET>/*", "arn:aws:s3:::<BUCKET>" ], "Effect": "Allow" }, { "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*" ], "Resource": [ "arn:aws:kms:<KMS-KEY>" ], "Effect": "Allow" }, { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::<AWS-ACCOUNT-ID>:role/<AWS-IAM-ROLE-NAME>" ], "Effect": "Allow" } ] } -
ポリシーの詳細で、ポリシーの名前を入力し「ポリシーの作成」をクリックします。
-
作成したIAMポリシーをIAMロールにアタッチします。
最初のメタストアの作成とワークスペースへのアタッチ
Unity Catalogを使用するには、メタストアを作成する必要があります。メタストアは、Unity Catalogのデータのトップレベルコンテナです。各メタストアでは、データを整理できる3つのレベルの名前空間（catalog.schema.table）が公開されます。
メタストアは、組織が運営を行っているリージョンごとに作成します。これらの各リージョンのメタストアは、その地域の任意の数のワークスペースにリンクできます。リンクされた各ワークスペースには、メタストア内のデータの同じビューがあり、データアクセス制御はワークスペース間で管理できます。他のメタストアのデータにアクセスするには、Delta Sharingを使用します。
メタストアの作成
-
Databricksのアカウントコンソールにサインインします。
-
ナビゲーションペインの「データ」をクリックします。
-
「メタストアを作成する」をクリックします。
-
下記を入力し、「作成」をクリックします。
- 名前：任意のメタストアの名前
- リージョン：データへアクセスするワークスペースと同一リージョン、および上記で作成したS3バケットと同一にする。
- S3バケットのパス：上記で作成したS3バケット
- IAMロールARN：上記で作成したIAMロールARNを指定
-
メタストアが追加されました。(2つになりました。)
ワークスペースの Unity Catalogを有効にする
-
【Databricks】ワークスペースを作成してみたで、作成したワークスペース名をクリックします。
-
①「ワークスペース」タブをクリックし、②「ワークスペースに割り当てる」をクリックします。
-
ワークスペースを選択し、「割り当てる」をクリックします。
-
Unity Catalogを有効化しますか？のポップアップが表示されるので、「有効化」をクリックします。
-
メタストアの「ワークスペース」タブに追加したワークスペースが表示されました。
考察
今回はUnity Catalogについて整理し、実際にUnity Catalogを作成＆Workspaceに紐付けまで行いました。
今後は、作成したUnity Catalogを介して、各種オブジェクトの作成等を行っていく予定です。
参考