Unity Catalogによる分散データガバナンスと環境の分離

[Isolated environments for Distributed governance with Unity Catalog \- The Databricks Blog](https://www.databricks.com/blog/2023/03/09/distributed-data-governance-and-isolated-environments-unity-catalog.html)の翻訳です。

:::note warn
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

自身のオペレーションにおいてデータ、分析、AIを頼りにしているすべての企業においては、効果的なデータガバナンスは重要となります。多くの企業においては、集中管理されたデータガバナンスがもたらす価値に対する認知が高まっています。しかし、ベストな意図においても、適切な組織上のプロセスやリソースなしに集中管理されたガバナンスの実装は困難です。チーフデータオフィサー(CDO)が多くの企業に設けられるようになっていますが、組織全体におけるデータガバナンスポリシーの定義と実行を誰が行うのかという質問は放置されています。

このため、組織におけるデータガバナンスポリシーの定義と実行の責任は集中化されず、組織内でのポリシーの違い、ビジネスライン、サブユニット、その他の部門ごとのガバナンス部門が生まれることになります。シンプルにするために、我々はこのように集中管理されたデータガバナンス機能を必要とせず、これらの統治部門間の違いに合意しているパターンを分散ガバナンスと呼びます。

この記事では、レイクハウスのデータ、分析、AIに対する統合ガバナンスソリューションを提供するDatabricksの[Unity Catalog](https://www.databricks.com/jp/product/unity-catalog)を用いた分散ガバナンスモデルの実装を探索します。

# Databricksにおけるデータガバナンスの進化

Unity Catalogを導入する前は、ワークスペースのコンセプトは、ワークスペースごとにメタストア、ユーザー管理、テーブルACLストアを持つモノリシックなものでした。これはワークスペースの間に固有のデータとガバナンス境界を生み出し、それらにおける一貫性に対応するために重複する労力を必要としていました。

これに対応するために、いくつかのお客様はメタストアとACLを同期するためのパイプラインやコードを実行するようになり、他のお客様はワークスペース横断で使用するためのセルフマネージドのメタストアをセットアップしていました。しかし、これらのソリューションはさらなるオーバーヘッドやメンテナンスコストを引き起こし、組織でどのようにデータのパーティションを作成するのかに関するアーキテクチャ上の意思決定を強いることで、データのサイロを生み出しました。

## Unity Catalogによるデータガバナンス

この制限を打ち破るために、Databricksではコラボレーションやデータを共有するための能力を最大化しつつも、データガバナンスの実装を容易にすることを狙いとしたUnity Catalogを開発しました。これを達成する最初のステップは、組織内のすべてのデータへのアクセスを可能とする共通の名前空間を実装することでした。

このアプローチは、上述した分散ガバナンスパターンでは問題になるように見えますが、従来であれば企業が複数のHiveメタストアで対応していた機能を、Unity Catalogではこの名前空間における新たな分離メカニズムを提供します。これらの分離機構によって、グループは最小限、あるいはインタラクションなしに独立にオペレーションを行えるようになり、プロダクション環境や開発環境のような他のシナリオにおいても分離を実現することができます。

## DatabricksにおけるHiveメタストアとUnity Catalog

Hiveを用いることでメタストアがサービス境界となり、複数のメタストアを持つことは、別のホスティングされたHiveサービスとデータベースを持つことを意味します。Unity CatalogがDatabricksレイクハウスプラットフォームにおけるプラットフォームとなり、考慮すべきサービス協会はありません。

Unity Catalogは、一箇所でデータを統治、監査できる共通の名前空間を提供します。

Hiveを使用する際は複数のメタストアを使うことが一般的であり、開発環境、プロダクション環境の間の分離を実現するため、あるいは、オペレーションを行うユニット間のデータ分離を実現するために、それぞれが自身の名前空間を持つことになります。

Unity Catalogでは、データの共有やコラボレーションの能力に妥協することなしに、名前空間に対する動的な分離機構を通じてこれらの要件を解決することができ、初期の後戻りできないアーキテクチャの意思決定を必要としません。

# 異なるチームや環境での作業

データプラットフォームを活用する際、組織におけるdev/prod、ビジネスグループやチーム、オペレーションユニットのような環境間の分離境界を設ける強いニーズがあることがあります。

Databricksのようなデータプラットフォームにおける分離境界を定義するところからスタートしましょう。

1. ユーザーは同意されたアクセスルールに基づいてのみデータにアクセスできるべきです
1. 指定された人々やチームによってデータを管理することができます
1. ストレージにおいてデータは物理的に分離されるべきです
1. 当該データの目的に基づいて、データは指定された環境でのみアクセスできるべきです

## ユーザーは同意されたアクセスルールに基づいてのみデータにアクセスできるべきです

通常、企業はデータをセキュアに保つために重要な組織的/規制上のいくつかの要件に基づいたデータアクセスに関する厳密な要件があります。典型的な例は、従業員の給与情報やクレジットカード支払い情報です。

このタイプの情報は、通常は厳密にコントロールされ、定期的に監査されます。Unity Catalogはこれらの業界標準に応えるために、企業にカタログのデータ資産に対するきめ細かいコントロールを提供します。このコントロールによって、Unity Catalogはユーザーが参照、クエリーできるデータのみを参照、クエリーできるようになります。

## 指定された人々やチームによってデータを管理することができます

Unity Catalogによって、みなさまは集中管理されたガバナンスモデル、分散ガバナンスモデルを選択することが可能となります。

集中管理ガバナンスモデルにおいては、ガバナンス管理者は、メタストアのオーナーとなり、すべてのオブジェクトのオーナーシップを持ち、ACLやポリシーを設定することができます。

分散ガバナンスモデルにおいては、カタログや一連のカタログをデータドメインと考えることができます。このカタログのオーナーは、すべての資産を所有することができ、当該ドメインにおけるガバナンスを管理することができます。この結果、ドメインのオーナーは他のドメインの他のオーナーとは独立してオペレーションを行うことができます。

ツールを用いて管理が行われる場合には、両方のオプションにおいてオーナーのグループやサービスプリンシパルを設定することを強くお勧めします。
![](https://cms.databricks.com/sites/default/files/inline-images/db-529-blog-img-1.png)

## ストレージにおいてデータは物理的に分離されるべきです

UCのメタストアを作成する際、デフォルトではDatabricksアカウント管理者は、マネージドテーブルのデフォルトロケーションとしての単一のストレージロケーションと資格情報を指定します。

規制上の理由、あるいは、SDLCスコープ、ビジネスユニット、コスト按分プロセスなどの理由からデータの物理的な分離を必要とする企業は、カタログレベルあるいはスキーマレベルでデータソースの機能を検討しなくてはなりません。

Unity Catalogによって、ストレージにおいてデータをどのように分離するのかのデフォルトを選択できるようになります。デフォルトでは、すべてのデータはメタストアに格納されます。[カタログ](https://docs.databricks.com/data-governance/unity-catalog/create-catalogs.html#create-a-catalog)や[スキーマ](https://docs.databricks.com/data-governance/unity-catalog/create-schemas.html#create-a-schema)におけるマネージドデータソースの機能サポートによって、データストレージやアクセスを物理的に分離することができ、企業が自分たちのガバナンスやデータマネジメントの要件を達成する助けとなります。

マネージドテーブルを作成する際、(指定された場合)カタログロケーション、(指定された場合)スキーマロケーションを用いてデータが格納され、それら2つが指定されていない場合にはメタストアロケーションのみを使用します。
![](https://cms.databricks.com/sites/default/files/inline-images/db-529-blog-img-2.png)

## 当該データの目的に基づいて、データは指定された環境でのみアクセスできるべきです

多くの場合、組織的、コンプライアンス要件は、他の環境ではなく特定の環境でのみ特定のデータにアクセスできることを保証します。この例には、devやproduction、分析のためのPIIデータを含むHIPAA、PII環境があり、誰がデータにアクセスできるのか、どの環境がそのデータにアクセスできるのかに関する特殊なルールが講じられます。時にはこの要件は、特定のデータセットやドメインの横断や組み合わせを禁じることがあります。

Databricksにおいては、ワークスペースを環境と考えることができます。Unity Catalogでは、ワークスペースにカタログを**バインド**する機能があります。これらの環境を識別するACLによって、ユーザー個人のACLに関係なく、ワークスペース内で利用できるカタログを限定することが可能となります。これは、メタストア管理者やカタログオーナーは、データカタログにアクセスできるワークスペースを定義することができます。これは、UIやインテグレーションAPI/terraform経由でコントロールできます。皆様固有のガバナンスモデルにフィットさせる助けとなる、[terraform経由でのUnity Catalogのコントロール](https://www.databricks.com/blog/2022/12/08/automated-guide-distributed-and-decentralized-management-unity-catalog.html)方法に関する記事を最近公開しました。
![](https://cms.databricks.com/sites/default/files/inline-images/db-529-blog-img-3.png)

# まとめ

Unity Catalogを皆様のレイクハウスアーキテクチャの中心に据えることで、効果的にデータを管理、共有する能力を犠牲にすることなしに、柔軟でスケーラブルなガバナンス実装を実現することができます。Unity Catalogを用いることで、既存のHiveメタストアの制限や制約を打ち破り、皆様固有のビジネス要件に応じてデータの分離やコラボレーションをより容易なものとします。使い始めるにはUnity Catalogガイドを([AWS](https://docs.databricks.com/data-governance/unity-catalog/index.html)、[Azure](https://learn.microsoft.com/ja-jp/azure/databricks/data-governance/unity-catalog/))ご覧ください。皆様のデータレイクハウスにおける効果的なガバナンス戦略を構築するためのベストプラクティスの詳細については、[データ、分析、AIガバナンスに関する無料のebook](https://www.databricks.com/resources/ebook/data-analytics-and-ai-governance)をダウンロードしてください。


### Databricksクイックスタートガイド

[Databricksクイックスタートガイド](https://www.amazon.co.jp/dp/B09V1YXFVQ/)


### Databricks無料トライアル

[Databricks無料トライアル](https://databricks.com/jp/try-databricks)