Databricks Unity Catalog への移行と MCP 活用

はじめに

こんにちは。開発本部開発1部デリッシュリサーチチームの江﨑です。

本記事では、これまでHive Metastore上のDeltaテーブルで管理していたデリッシュリサーチ用データ（約40テーブル）をUnity Catalogへ移行したプロジェクトの全体像を、インフラ整備からAthena連携・Databricks Managed MCP活用まで紹介します。

はじめに
背景：なぜ Unity Catalog に移行したか
- 課題 1：テーブルスキーマが「コードを読まないと分からない」
- 課題 2：データリネージを Mermaid で管理していた
Unity Catalog とは
マネージドテーブル vs 外部テーブル
移行手順の全体像
Step 1：インフラ整備
- IAMロールの設定
- Catalogの作成
Step 2：Unity Catalog テーブルの作成
- 移行スクリプトの流れ
Step 3：既存 ETL コードの変更
- 主な変更：テーブル参照パスの書き換え
Step 4：Athena から Unity Catalog のデータを参照する
- 実際に行った変更
Step 5：Quick Suite のデータセット移行
移行結果 Before / After
- Before（Hive Metastore 時代）
- After（Unity Catalog 移行後）
Databricks Managed MCP
まとめ

背景：なぜ Unity Catalog に移行したか

移行前、デリッシュリサーチではDatabricksのHive Metastore上で約40個のDeltaテーブルを運用していました。その中で、運用上の課題が積み重なってきていました。

課題 1：テーブルスキーマが「コードを読まないと分からない」

「このテーブルに user_id カラムってあったっけ？」という確認をするたびに、Notebookを開いて display(spark.table("schema.table")) を実行するか、ETLコードを読み返す必要がありました。テーブルが増えるほど、この手間もかさんでいきます。

課題 2：データリネージを Mermaid で管理していた

テーブル間の依存関係（「このテーブルはどのテーブルから作られているか」）をMermaidのコードで手作業管理していましたが、40テーブルを超えると複雑すぎてメンテナンスが限界になり放置されていました。テーブルを追加するたびにMermaidを手で更新する運用は、明らかにスケールしません。

これらの課題を解消するためにUnity Catalogへの移行を決めました。

Unity Catalog とは

Unity CatalogはDatabricksの統合データガバナンスソリューションです。Hive Metastoreとの最大の違いは、三層の名前空間（Catalog > Schema > Table）を持つ点です。

Catalog（例: marketing_research）
  └── Schema（例: search）
        └── Table（例: search_count）

Hive Metastoreでは schema.table の二層構造でしたが、Unity Catalogでは catalog.schema.table の三層になります。この変更によって、チームやプロジェクトを跨いだデータの整理がしやすくなります。

主な機能は以下の3点です：

データカタログ：テーブルのスキーマ・カラムの説明文をUI上で管理・参照できる
データリネージ：データの流れ（どのテーブルがどのテーブルを参照しているか）を自動追跡・可視化
アクセス制御：行・列レベルの細粒度なセキュリティ設定

Unity Catalogのオブジェクト階層。今回の移行ではCatalog > Schema > Tableの三層構造を利用。（出典: Databricks公式ドキュメント）

Unity CatalogのUI。テーブルを選択するとカラム名・データ型・コメントを一覧で確認できる。

マネージドテーブル vs 外部テーブル

Unity Catalogへの移行を検討するとき、決めなければならないのがテーブルタイプです。

観点	マネージドテーブル	外部テーブル
データ保管場所	Unity Catalogが管理するパス	任意のストレージパス（S3など）
S3パスの形式	自動生成されたID形式になる	任意のS3パスを指定できる
テーブル削除時	データも削除される	データは残る
Databricksの推奨	ほとんどのユースケース	既存ストレージとの互換性が必要な場合

Databricksはマネージドテーブルを推奨していますが、本プロジェクトでは外部テーブルを選択しました。

その理由は、データ参照構成にあります。デリッシュリサーチではダッシュボードを Amazon Quick Suite(以下Quick Suite) → Athena → Glue Crawler → S3 という構成で構築しています。Glue Crawlerはクロール先のS3パスを読み取ってテーブル名を付与します。

ここで問題になるのが、マネージドテーブルのS3パス形式です。マネージドテーブルに移行すると、S3パスは s3://unity-catalog-metastore/__unitystorage/... のような __unitystorage 配下のシステム管理ディレクトリ（ランダム生成IDを含むパス）に配置されます。Glue CrawlerはS3プレフィックス/フォルダ名ベースでテーブル名を付けるため、Athena側のテーブル名が人間可読でない名前になり、現実的な運用が難しくなります。

外部テーブルであればS3パスを s3://<バケット名>/table_name のようにテーブル名ベースで保持できるため、Athena上のテーブル名が人間にとって分かりやすい名前のままになり、移行コストを抑えつつ今後の管理も楽になります。

移行手順の全体像

移行は以下の5ステップで実施しました。

Step 1：インフラ整備（IAM・Catalogの作成）
Step 2：Unity Catalogテーブルの作成
Step 3：既存ETLコードの変更（テーブル参照パスの更新）
Step 4：AthenaからUnity Catalogのデータを参照できるようにする
Step 5：Quick Suiteのデータセット移行

Step 1：インフラ整備

Unity Catalogを有効化するにあたって、AWS・Databricks側でいくつかの設定が必要でした。

IAMロールの設定

DatabricksがS3バケットにアクセスするためのIAMロールと、それをDatabricks側に登録するストレージクレデンシャルを新規作成しました。インフラ変更はTerraformで管理しています。概念的には以下のような構成です。

resource "aws_iam_role" "databricks_unity_catalog" {
  name = "<ロール名>"
  assume_role_policy = jsonencode({
    Statement = [{
      Effect    = "Allow"
      Principal = { AWS = "arn:aws:iam::<Databricks の AWS アカウント ID>:role/unity-catalog-prod-role" }
      Action    = "sts:AssumeRole"
      Condition = { StringEquals = { "sts:ExternalId" = <databricks_sts_external_id> } }
    }]
  })
}

Catalogの作成

Unity Catalogを利用するには、Databricks上にCatalogを作成する必要があります。Catalog作成時のmanaged storage location指定は任意ですが、今回は運用上の理由から指定のS3バケットをmanaged storage locationとして指定しました。

参照：Unity Catalog の Catalog を作成する（Databricks 公式ドキュメント）

Step 2：Unity Catalog テーブルの作成

インフラが整ったら、既存のHive MetastoreテーブルのデータをUnity Catalogの外部テーブルとして再作成します。旧パスから schema/table というパス構成に移行するため、CTAS（CREATE TABLE AS SELECT）を使いました。

移行スクリプトの流れ

旧パスのDeltaテーブルを SELECT * で読み取る
schema/table 形式のパスにDelta形式で書き込みながらUnity Catalogの外部テーブルを作成

# 旧 Delta からデータをコピーしながら UC 外部テーブルを作成
spark.sql(f"""
  CREATE TABLE IF NOT EXISTS {catalog}.{schema}.{table_name}
  USING DELTA
  LOCATION '{new_s3_path}'
  AS SELECT * FROM delta.`{old_s3_path}`
""")

Step 3：既存 ETL コードの変更

主な変更：テーブル参照パスの書き換え

Hive MetastoreではS3パスを直接指定してデータを読み書きしていましたが、Unity Catalogでは catalog.schema.table の三層構造で参照するよう書き換えました。

# Before（Hive Metastore）：S3 パスを直接指定
df = spark.read.format("delta").load("s3://path/to/delta")
df.write.format("delta").save("s3://path/to/delta")

# After（Unity Catalog）：カタログ名で参照
df = spark.table("catalog.schema.table")
df.write.saveAsTable("catalog.schema.table")

Step 4：Athena から Unity Catalog のデータを参照する

前述の通り、Quick Suiteのデータソースは Athena → Glue Crawler → S3 という構成です。Unity Catalogに移行しても、この構成を維持する必要があります。

実際に行った変更

Glue Crawlerのクロール先を、Unity Catalog外部テーブルのS3パスに変更しました。

Before：
旧 S3 バケット（Hive Metastore 用）→ Glue Crawler → Athena

After：
Unity Catalog 外部テーブルの S3 バケット → Glue Crawler → Athena

具体的な変更内容：

Glue Crawlerのクロール先S3パスをUnity Catalog外部テーブルのパスに変更
GlueのIAMポリシーにS3バケットへのアクセス権限を追加

Terraformで管理しているIAMポリシーとGlueリソースを更新し、terraform apply 後にGlueコンソールからクローラーを手動実行してテーブルが正しく作成されることを確認しました。

Step 5：Quick Suite のデータセット移行

Step 4でGlue → Athena側の変更が完了したら、Quick Suiteのデータセット参照先を新しいAthenaテーブルに切り替えます。

変更自体はQuick SuiteのUIから接続設定を変更するだけで完結しますが、切り替え前にテーブルスキーマの互換性確認が重要です。カラム名・データ型が一致していないと、ダッシュボードの集計が壊れます。

移行結果 Before / After

移行の成果をBefore / Afterでまとめます。

Before（Hive Metastore 時代）

項目	状態
テーブルスキーマ確認	Notebookを実行するかコードを読む必要がある
データリネージ	Mermaidで手作業管理

After（Unity Catalog 移行後）

項目	状態
テーブルスキーマ確認	Unity CatalogのUIでカラム一覧・データ型・説明文を即時参照
データリネージ	UI上で自動生成・可視化（Mermaidでの手作業管理が不要に）

特にデータリネージの自動可視化は、Mermaidの維持コストをゼロにしてくれる大きな恩恵でした。Unity CatalogにETLジョブが書き込むと、どのテーブルがどのテーブルから作られているかが自動でグラフとして記録されていきます。

Unity Catalogのデータリネージ画面。どのテーブルがどのテーブルから作られているかが自動でグラフ表示される。

Databricks Managed MCP

Unity Catalogへの移行をきっかけに、Databricks Managed MCPも使えるようになったので紹介します。

Databricks Managed MCP とは

Databricks Managed MCPとは、DatabricksがホストするMCP（Model Context Protocol）サーバーです。Claude CodeなどのAIエージェントからDatabricksのリソースをツールとして呼び出せるようにする仕組みです。

Databricks Managed MCPはUnity Catalogとの統合を前提に設計されています。今回の移行後、実際に使えるようになりました。

DBSQL MCP：ETL 開発が変わる

Databricks Managed MCPの中でも、ETL開発が中心のデリッシュリサーチにとって特に相性が良さそうだと感じたのが DBSQL MCP です。これはClaude CodeやCursorのMCPとして設定することで、ETL開発中にSQLをその場で実行・確認できるようになるツールです。

提供されるツール：

execute_sql_read_only：テーブルの内容・カラム定義・データ分布をその場で確認
execute_sql：SQLの実行
poll_sql_result：長時間クエリの結果をポーリング

※ ツール名や提供機能はアップデートで変更される可能性があります。上記は執筆時点（2026年3月6日）で使用できるツールです。

具体的な開発体験

ETLコードを書きながら、Claude Codeに対して次のような依頼ができるようになります：

「catalog.schema.table のカラム構成を確認して」
「product_id カラムのユニーク数を調べて」
「このテーブルとJOINするテーブルのスキーマを見せて」

DBSQL MCPを使うことでCursorやVS CodeなどのエディタからDatabricksのテーブルの中身・スキーマをリアルタイムで確認しながらコーディングができます。

なお、DBSQL MCP以外にもUnity Catalog functionsやGenie spaceなども使えるようになっています。

参照：Databricks Managed MCP 公式ドキュメント

MCPの詳細な設定方法や活用例については、こちらの記事も参照してください。

まとめ

約40テーブルのHive Metastore → Unity Catalog移行を通じて得た主な成果を3点でまとめます。

データカタログとデータリネージの整備：Unity CatalogのUIでスキーマ情報を参照でき、データリネージも自動管理されるため、「コードを読まないと分からない」問題が解消されました
外部テーブルで構成互換性を維持：Athena連携（Glue Crawler）がある場合は外部テーブルを選ぶことで、既存のBI構成に影響を与えずに移行できました
Databricks Managed MCPが使えるようになった：ETL開発中にエディタから出ずにテーブル情報を確認できるようになり、開発体験が向上しました

今後は、Unity Catalogへの移行によって使えるようになった機能の検証・活用をしていきたいと考えています。

Unity Catalogへの移行を検討している方の参考になれば幸いです。

every Tech Blog

株式会社エブリーのTech Blogです。