はじめに

2023年11月より、Unity Catalogの自動有効化のロールアウト（展開）が開始されました。新規のDatabricksユーザーが新規に作成するワークスペースではUnity Catalogが自動有効化されるようになりました。既存のDatabricksユーザーが管理する既存ワークスペースについては利用状況などを元に順次展開される予定です。Unity Catalogの自動有効化の詳細については以下のドキュメントをご覧ください。

本記事では、新規ユーザーの新規Azure Databricksワークスペースを対象として、Unity Catalogが自動有効化された各種画面の様子を概観したいと思います。
（注釈）記事中では、Azure DatabricksをADB、Unity CatalogをUCと略したりします。

Azure Databricksワークスペース

次のキャプチャは、ADBワークスペースを作成後、カタログエクスプローラーにアクセスした画面です。これまでの新規ADBワークスペースでは hive_metastore と samples の2つのカタログがありました。
UCが自動有効化されたワークスペースでは、これらに加えてワークスペース名と同名のカタログ（キャプチャ中では hinak_adb_ejp）、system の2つのカタログが自動的に追加されています。
便宜上、前者のカタログをワークスペースカタログと呼びます。（公式のドキュメントでもそう呼称されています）
細かい話ですが、ワークスペース名に含まれるハイフンは、ワークスペースカタログ名ではアンダースコアに自動的に変換されています。また、管理者が後からワークスペースカタログ名を変更することも可能です。

すべてのカタログを展開してみましょう。hive_metastore と samplesの配下のスキーマやテーブルを閲覧するにはDatabricks SQLウェアハウスが必要ですが、UC管理下のワークスペースカタログ（ここでは hinak_adb_ejp）および system カタログは、SQLウェアハウスなしでも配下のスキーマがちゃんと見えています。

ワークスペースカタログの概観

ここから、ワークスペースカタログ（ここでは hinak_adb_ejp）を概観していきます。

スキーマ

ワークスペースカタログの[スキーマ]タブを見ると default と information_schema の2つがあります。

詳細

続いてワークスペースカタログの[詳細]タブを見てみましょう。ストレージルート、ストレージの場所を見ると、ADBワークスペース作成時にセットで作成されるストレージアカウントのパスが自動的に指定されています。つまり、ワークスペースカタログでマネージドテーブルなどを作成すると、データの実体がこのパスに保存されることになります。

Azureポータルでストレージアカウントを見てみると、たしかにパスに指定されているコンテナーが自動作成されていることが分かります。

権限

次にワークスペースカタログの[権限]タブを見てみます。プリンシパルの _workspace_users_... は、このADBワークスペースのユーザーが所属するグループです。キャプチャの上の方にある[所有者]を見るとわかるように、ADBワークスペースの管理者がワークスペースカタログの所有者になります。

ワークスペースカタログに対するユーザーのデフォルトの権限
詳細は公式ドキュメントをご覧ください。

すべてのワークスペースユーザーは、ワークスペースカタログの default スキーマでオブジェクトを作成できます。
ワークスペース管理者は、ワークスペースカタログを所有し、そのカタログおよびそのカタログ内のオブジェクトへのアクセス権を付与できます。
ワークスペース管理者は、新しいカタログと新しいカタログ内のオブジェクトを作成し、それらにアクセス権を付与できます。

ワークスペース

続いて[ワークスペース]タブを見てみましょう。今アクセスしているADBワークスペース hinak-adb-ejp だけが、このワークスペースカタログにアクセス可能なワークスペースとして割り当てられています。

アカウントコンソール

続いてアカウントコンソール (https://accounts.azuredatabricks.net) にアクセスしてみます。metastore_azure_japaneastという名前のメタストアが作成されています。このキャプチャでは新規作成したADBワークスペースと同じJapan Eastになっています。

Unity Catalogのメタストアについて
メタストアはUnity Catalogにおける最上位のリソースで、カタログなどを子要素として持ちます。メタストアは、ADBワークスペースのリージョンごとに作成する必要があります。リージョンごとに作成できるメタストアの数は1つです。リソースの階層構造は以下の図がわかりやすいと思います。

画像出典: Unity Catalog のベストプラクティス - Azure Databricks | Microsoft Learn

メタストアの概観

ここから、メタストア（ここでは metastore_azure_japaneast）を概観していきます。

構成

メタストアの[構成]タブにアクセスします。特筆すべきは、ADLS Gen2パスがブランクになっているという点です。これまでメタストアを作成する際にはADLS Gen2パスを設定する必要があったのですが、UCの自動有効化の導入などに伴ってメタストアのADLS Gen2パスの設定がオプションになりました。後からパスを設定することもできます。（一度設定すると変更不可な点は注意しましょう）

ワークスペース

メタストアの[ワークスペース]を見ると、新規作成したADBワークスペースが割り当てられていることが確認できます。

個人的にとても嬉しいポイント

Unity Catalogのメタストアにクラウドストレージのパスを指定する必要がなくなった点、さらにカタログやスキーマ単位でクラウドストレージのパスを指定できるというのが、複数サブスクリプションでADBを使う際のUCの設計がかなりやりやすくなって、個人的にとても嬉しいです。

従前の仕様と課題

これまでのAzure DatabricksのUnity Catalogのメタストアの仕様は以下のようなものでした。

リージョンごとに作成可能なメタストアは1つのEntra IDテナントで1つのみ（こちらは現在も同じ仕様です）
メタストアと同じリージョンにあるADLS Gen2を関連付ける必要がある

Azureでは環境（例：開発、検証、本番）や組織（例：A部門、グループ会社X）、用途（例：外販システム、社内向け）でAzureサブスクリプションを分けることをよくやります。上記の仕様2によって、複数サブスクリプションでADBを使う場合、どのサブスクリプションのADLS Gen2をメタストアに関連付けるのかを検討する必要がありました。

何がどう良くなったのか？

UCメタストアのクラウドストレージのパスを省略できるようになったことで、この検討が不要になりました。カタログやスキーマ単位でクラウドストレージのパスを指定できるので、環境や組織、用途などに合わせてADLS Gen2を作ることで、データの物理的な場所についても分かりやすく管理できるようになりました。

画像出典: Unity Catalog のベストプラクティス - Azure Databricks | Microsoft Learn

おわりに

Unity Catalogを導入することでガバナンスやセキュリティを向上させられるのはもちろんなのですが、Databricksの開発体験がグンと向上します。
UCはDatabricks内のリソースや起きたイベントなど、ほとんどすべてのことを知っていますから、カタログエクスプローラーから詳細な情報が取得できますし、検索ボックスやリネージ（データの処理の流れ図）を駆使することで、知りたいリソースに素早くアクセスできます。また、LakehouseIQやVolumesなど、UCを前提とした新機能も増えてきています。
ぜひUnity Catalogを有効化して、Databricksでのデータ + AIの開発を楽しみましょう！