Databricksによるデータマートの再設計 ― メダリオンアーキテクチャ × Unity Catalog × Liquid Clusteringの実践記

1. はじめに

はじめまして。ARISEanalyticsの佐藤です。私のチームでは、運用新技術・特化技術を利用して業務を効率化するための取り組みを行っています。

本記事では、EKS上でチームごとにバラバラに管理されていたデータマートを、Databricksを中核としたモダンな分析基盤へ移行したプロジェクトについてご紹介します。移行にあたっては、メダリオンアーキテクチャによるデータ設計、Unity Catalogによる統合管理、Liquid Clusteringによるクエリパフォーマンスの最適化を採用しました。

この記事は、以下のような方を想定しています。

• 分析基盤の移行・刷新を検討しているデータエンジニア
• データマートの乱立やガバナンスの課題を抱えている方
• Databricksの主要機能の実践的な活用事例を知りたい方

設計判断の背景や移行の中で得た実践知見を、できるだけ率直にお伝えしたいと思います。

2. 移行前の課題

データ分析基盤の運用が長期化すると、多くの組織で共通の課題が顕在化してきます。データマートがチームごとに独自に発展し、全体としての統制が取りづらくなるというのは、成長フェーズの企業ではよく聞く話ではないでしょうか。私たちの環境も例外ではありませんでした。

当時はEKS上にデータ処理基盤を構築していましたが、組織の拡大に伴ってチームごとにデータマートが独立して発展しており、全社横断で活用できるデータ基盤としては改善の余地がある状態でした。具体的には、以下のような課題を感じていました。

データガバナンスの不在

 テーブルの命名やスキーマ定義がチームごとに異なるというのは、組織が大きくなる過程で自然と発生しやすい問題です。私たちの環境でも同様で、例えば「売上」を意味するテーブルが sales_summary だったり uriage_mart だったりと、チームの文化や経緯によって表現が異なっていました。カラムの定義が十分に整備されていないテーブルもあり、データの意味を正確に把握するには担当チームへの確認が必要な場面が少なくありませんでした。 

データの重複と不整合

複数のチームが同じソースデータをもとに、それぞれの目的に合わせたマートを構築していたため、似て非なるテーブルが複数存在する状態になっていました。これもデータ基盤が分散している環境ではありがちな課題ですが、集計ロジックの微妙な違いから「どの数字を基準にすべきか」の判断に迷うケースが出てきていました。

チーム横断のデータ活用が困難

あるチームのマートを別のチームが活用したい場合、S3上のどこにデータが格納されているかを探すところから始まり、テーブル定義の確認、データ品質の検証と、相応の調整コストが発生していました。こうした摩擦の積み重ねが、チームをまたいだデータ活用のハードルになっていたと感じています。

運用・保守コストの肥大化

チームごとにデータ加工の仕組みが独自に発展した結果、その成熟度にはばらつきがありました。きちんとしたETLパイプラインとして整備されているものもあれば、Notebookのスクリプトを手動実行しているものもあり、処理の全体像を横断的に把握することが難しくなっていました。

これらは個々に見れば珍しい課題ではありませんが、放置すればデータ活用の推進にとって大きなボトルネックになりかねないものです。こうした認識がチーム内で共有されたことを契機に、分析基盤を再設計するプロジェクトが始動しました。

3. 目指した姿

移行で達成したかったこと

前章で触れたような課題を踏まえ、移行プロジェクトで達成したいゴールを大きく4つ定めました。 

1. データガバナンスの確立：データ構造の標準化とメタデータの整備による統一管理
2. データの一元化：チーム横断で信頼できる単一のデータソースを提供
3. 分析の民主化：適切な権限さえあれば、誰でも必要なデータにアクセスできる状態の実現
4. 運用コストの削減：データ加工・最適化にかかる保守負荷を軽減し、持続可能な運用体制を構築

これらのゴールを実現するために、Databricksの機能群をどう活用するかを設計の軸としました。

各課題に対する解決アプローチ

4つのゴールを達成するために、前章で示した課題それぞれに対して以下のようなアプローチで解決を図りました。なお、分析基盤のプラットフォームとしてDatabricksを採用することは全社的な方針として決定されていたため、我々のチームではDatabricksの機能群を最大限に活かしたアプローチを設計しました。

データガバナンスの不在 に対しては、メダリオンアーキテクチャに基づくレイヤー設計を導入し、データの品質と加工段階を構造的に管理する仕組みを整えました。データの格納先としてはDelta Lakeを採用し、ACIDトランザクションやスキーマの強制といった機能によりデータ品質を担保しています。あわせて、Unity Catalog上でテーブル・カラムにメタデータを整備することで、データの意味や定義をセルフサービスで参照できる状態を実現しました。（→ 第4章・第5章で詳述）

データの重複と不整合 に対しては、メダリオンアーキテクチャの各レイヤーに加工ロジックを集約することで、同じソースデータに対する重複した加工を解消し、信頼できる単一のデータソースを提供する設計としました。（→ 第4章で詳述）

チーム横断のデータ活用の困難さ に対しては、Unity Catalogによるデータ構造の標準化と発見性の向上で対応しました。S3上に散在していたデータをカタログ・スキーマ・テーブルの階層に整理し、誰でも必要なデータにたどり着ける環境を構築しました。（→ 第5章で詳述）

運用・保守コストの肥大化 に対しては、レイヤー設計による保守性の向上に加え、Liquid Clusteringの採用によりテーブルの最適化にかかる運用負荷を軽減しました。従来のパーティショニングやZ-Orderingと比べて運用コストが低く、クラスタリングキーの変更も柔軟に行えるため、継続的な運用に適した選択です。（→ 第4章・第6章で詳述）

4. メダリオンアーキテクチャに基づくデータ設計

メダリオンアーキテクチャとは

メダリオンアーキテクチャは、データレイクハウスにおけるデータの品質と構造を段階的に整理するための設計パターンです。データをBronze（生データ）、Silver（クレンジング・加工済み）、Gold（ビジネスロジック適用済み・分析用途）の3層に分けることで、データ品質の段階的な向上と再利用性の確保を両立させます。

 メダリオンアーキテクチャの概念図（databricks公式ドキュメントより引用: https://www.databricks.com/jp/blog/what-is-medallion-architecture ） 

自社での各レイヤーの設計と適用

このメダリオンアーキテクチャの考え方をベースに、自社の環境では当初、以下の4層構成で設計を行いました。一般的なメダリオンアーキテクチャの3層（Bronze / Silver / Gold）に対して、Silver層とGold層の間にPlatinum層を設けたのは、クレンジングとデータの加工・結合を明確に分離したいという意図からです。

この構造により、共通的な加工が上流のレイヤーに集約され、同じソースデータに対する加工ロジックの重複が削減されました。あるテーブルのロジックを修正する際にも影響範囲が明確になり、保守性が向上しています。 

結果・考察

うまくいったこと

各レイヤーの基本方針を設計の初期段階でチーム内で合意したことは、その後の開発をスムーズに進める土台になりました。完璧なガイドラインではなかったものの、「Bronze層では源泉データを変えない」「Gold層ではビジネスロジックを最小限にする」といった大方針があったことで、個別の判断に迷った際に立ち返る軸ができました。

特にGold層のビジネスロジックを最小限にする方針は、マートの汎用性を高め、チーム横断での再利用を現実的にする効果がありました。ビジネスロジックの適用を各分析チームに委ねることで、Gold層の保守コストを抑えつつ、各チームが自身のユースケースに柔軟に対応できる設計になっています。

想定通りにいかなかったこと

正直に書くと、現時点ではSilver層はほとんど利用されていません。設計段階では「クレンジング」と「ロジックの適用」を明確に分離する意図でSilver層を設けましたが、実際に移行を進めてみると、クレンジングが必要なデータが想定よりも少なかったことに加え、「どこまでがクレンジングで、どこからがビジネスロジックなのか」の境界が曖昧であることが課題として浮かび上がりました。結果として、Bronze層から直接Gold層へデータを流すケースが大半を占めており、Silver層が実質的にスキップされている状態です。4層構成を設計した時点で「クレンジング」の定義が抽象的なまま進めてしまったことが根本的な原因だと考えています。

また、ガイドラインの粒度も不十分でした。基本方針は合意していたものの、具体的な加工パターンごとの判断基準までは明文化できておらず、「NULLの補完はSilverなのかGoldなのか」「コードマスタとの結合はPlatinumなのかGoldなのか」といった実装レベルの判断が開発者ごとにばらつく結果となりました。

次にやるならこうする

この経験を踏まえ、次にレイヤー設計を行うなら以下の点を改善したいと考えています。

まず、レイヤーを増やす前に、各層に実際のワークロードがあるかを確認することです。レイヤーの数は目的ではなく手段であり、抽象的な分離の美しさよりも、実際にそのレイヤーを通るデータがどれだけあるかが設計の判断基準になるべきでした。

次に、ガイドラインは抽象的な方針だけでなく、具体的な加工パターン×レイヤーの対応表まで作ることです。「この種類の加工はこのレイヤーで行う」という具体例が揃っていれば、開発者間の解釈のずれを大幅に減らせたはずです。

そして、棚卸しの段階で各テーブルの加工内容をレイヤーの設計方針と突き合わせるところまで踏み込むことです。ここが不十分だったために、移行フェーズで既存マートのリバースエンジニアリングに想定以上の工数を取られる結果になりました。

メダリオンアーキテクチャはあくまで設計パターンであり、自社の運用実態に合わせてどこまで忠実に適用するかは組織ごとの判断になります。完璧な設計を最初から目指すよりも、まずは基本方針を定めて運用を始め、実態に合わせて改善していくアプローチが現実的だと感じています。

5. Unity CatalogによるDelta Lakeの統合管理

Unity Catalogとは

Unity CatalogはDatabricksが提供する統合ガバナンスソリューションで、データとAIアセットの一元的な管理を実現します。3層のネームスペース（カタログ → スキーマ → テーブル）を通じてデータを体系的に整理し、アクセス制御やリネージの追跡を統合的に行えます。

 UnityCatalogの概念図（databricks公式ドキュメントより引用: https://docs.databricks.com/gcp/ja/data-governance/unity-catalog/ ） 

階層設計・メタデータ整備・アクセス権限管理

我々の環境では、Unity Catalogの階層を以下のように設計しました。

catalog: 社内部門用カタログ
  └── schema: bronze / silver / platinum / gold
        └── table: テーブル名
    

スキーマレベルでメダリオンアーキテクチャのレイヤーを表現し、各スキーマ内にテーブルを配置するシンプルな構成としています。

今回の移行で特に重視したのは、テーブルの命名規則を厳密に統一することよりも、各テーブルにメタデータとして情報を充実させることでした。テーブルやカラムに対してコメント（説明文）を付与し、データの概要、カラムの意味といった情報をUnity Catalog上で直接確認できるようにしています。

アクセス制御については、Unity Catalogが提供するスキーマ単位での権限管理を活用しています。我々の環境ではメダリオンアーキテクチャの各レイヤーがそのままスキーマに対応しているため、例えば「このチームにはGoldスキーマの参照権限を付与する」といった制御がシンプルに実現できます。テーブル一つひとつに個別の権限を設定する必要がなく、管理の手間が大幅に軽減されています。現時点では、Gold層のデータを利用するチームのみに権限を付与するシンプルな運用としていますが、今後のデータ利用の拡大に伴い、スキーマ単位の権限管理を活かしながらポリシーを段階的に整備していく方針です。

結果・考察

うまくいったこと

Unity Catalogの導入によって、最も大きく改善されたのはデータの発見可能性です。以前の環境では、各チームがS3上のどこにどのようなデータを格納しているのかが不透明で、「使いたいデータがどこにあるのかわからない」という状態が常態化していました。Unity Catalogによってカタログ・スキーマ・テーブルという標準化されたデータ構造のもとにデータが整理されたことで、分析者はUI上でデータを横断的に検索・閲覧でき、必要なデータに迷わずたどり着けるようになっています。

また、データリネージの可視化により、あるGold層のマートがどのテーブルに由来するのかをUnity Catalog上で追跡できるようになり、障害発生時の影響範囲の特定やロジック変更時の影響分析が格段に容易になっています。

特にやってよかったのは、テーブル・カラムのメタデータ整備を移行作業とセットで行ったことです。もしこれを後回しにしていたら、「移行はしたがデータの中身がわからない」という別の課題を生んでいた可能性があります。移行というタイミングだからこそ、既存マートの内容を棚卸しする過程でメタデータの整備も同時に進められたのは大きなメリットでした。

想定通りにいかなかったこと

分析者への新環境のオンボーディングが十分ではありませんでした。Unity Catalogでのデータの探し方や、各レイヤーの意味といった情報の共有を、移行と並行してもっと早い段階から進めておくべきでした。移行が完了してから案内を始めたため、UnityCatalog上でのデータに関する問い合わせを何件かいただきました。せっかくデータの発見性が向上しても、その使い方が伝わっていなければ効果は限定的です。

次にやるならこうする

移行作業と並行して、分析者向けのオンボーディングを早期に開始することです。Unity Catalogの使い方やデータの探し方を事前に共有しておけば、移行完了後すぐに新環境を活用してもらえる状態を作れたはずです。技術基盤の整備と、それを使う人への情報共有は、同時並行で進めるべきだと感じています。

6. Liquid Clusteringによるマートの最適化

Liquid Clusteringとは

Delta Lakeにおけるクエリパフォーマンスの最適化手法としては、従来からパーティショニングとZ-Orderingが広く利用されてきました。しかし、パーティショニングはキーの選定を誤るとパフォーマンスが悪化するリスクがあり、データの偏りが大きい場合にはスモールファイル問題も発生しやすくなります。Z-Orderingは OPTIMIZE コマンドを定期的に実行する必要があり、実行のたびにデータ全体を書き換えるためコストが高くなりがちです。

Liquid Clustering は、Databricks が提供する比較的新しいデータレイアウト最適化機能で、これらの課題を解消する特徴を持っています。

• インクリメンタルな最適化：OPTIMIZE 実行時に、変更があったデータのみを対象とするため、コストが低く抑えられます
• クラスタリングキーの柔軟な変更：テーブルの再作成なしにキーを変更でき、分析パターンの変化に追従しやすい設計です
• 自動的なデータレイアウトの調整：書き込み時にもクラスタリングが段階的に適用されるため、常に一定の最適化状態が維持されます

 Liquid Clusteringの概念図（Databricks公式ドキュメントより引用:https://www.databricks.com/jp/blog/announcing-automatic-liquid-clustering ） 

Liquid Clusteringを採用した最大の理由は、運用負荷の低さです。我々のGold層のマートは、分析要件の変化に応じてクエリパターンが変わる可能性があります。従来のパーティショニングではキーの変更が実質的にテーブルの再作成を意味しましたが、Liquid Clusteringであれば ALTER TABLE でクラスタリングキーを変更するだけで対応可能です。また、今回の移行は新規にテーブルを構築するタイミングであったため、既存テーブルとの互換性を気にすることなくLiquid Clusteringを最初から適用できるという好条件もありました。

クラスタリングキーの設計と適用

Liquid Clusteringのクラスタリングキーは、データの物理配置を最適化しデータスキップの効率を高めるための指定です。パーティショニングのようにデータを厳密に分割するのではなく、あくまでも最適化の足がかりとなるカラムを指定するものであるため、選定にあたってはシンプルな方針を採りました。

我々のGold層マートでは、分析クエリの大半が時間軸でのフィルタリングを伴います。そのため、基本的には年（y）・月（m）といった時間情報のカラムをクラスタリングキーとして設定しました。時間情報は分析における最も一般的なフィルタ条件であり、適度なカーディナリティを持つため、データスキップの恩恵を受けやすいカラムです。

Liquid Clusteringではクラスタリングキーの変更が ALTER TABLE で柔軟に行えるため、まずは時間軸をベースとし、今後クエリパターンの変化に応じてキーの見直しを行っていく方針としています。

結果・考察

うまくいったこと

特定のマートにて先行的に移行を実施し、手順や課題を洗い出せたことが有効でした。先行移行で得た知見をもとに移行手順をブラッシュアップできたため、今後ほかのマートを移行する際にも手戻りを減らすことができると感じています。新しい技術を全面適用する前に小さく試すアプローチは、リスクを抑えつつ実践知見を蓄積するうえで効果的でした。

また、今回の移行が新規にテーブルを構築するタイミングであったため、既存テーブルとの互換性を気にすることなくLiquid Clusteringを最初から適用できたことも好条件でした。実際の運用においても、Gold層のマートに対するクエリのレスポンスは分析者から好評を得ており、体感レベルでのパフォーマンスの問題は報告されていません。

想定通りにいかなかったこと

EKS上の旧環境とDatabricks上の新環境という、基盤そのものが異なるプラットフォーム間での移行であったため、Liquid Clusteringの効果を同一条件で比較する実測ベンチマークの実施が困難でした。Databricksの公式ドキュメントおよびベンチマーク結果を参考にしつつも、自社環境での定量的な効果検証ができていない点は課題として残っています。

次にやるならこうする

 運用データが蓄積された段階で、クラスタリングキーの最適性やOPTIMIZEの実行頻度について定量的な検証を行う予定です。また、Liquid Clusteringではクラスタリングキーの変更が ALTER TABLE で柔軟に行えるため、クエリパターンの変化に応じてキーの見直しも継続的に検討していきます。

7. 移行を通じての総括

技術的なサマリー

今回の移行では、3つの技術を組み合わせることで、第2章で整理した課題の解決を図りました。

メダリオンアーキテクチャによるレイヤー設計は、データの加工ロジックを構造的に整理し、重複の削減と保守性の向上に寄与しました。Gold層のビジネスロジックを最小限にする方針が、マートの汎用性とチーム横断での再利用を実現した一方、Silver層が実質的に未使用であるなど、設計と運用実態の間にギャップが生じている部分もあり、今後のレイヤー構成の見直しが課題として残っています。

Unity Catalogは、データの発見性とメタデータ管理において最も大きな改善をもたらしました。S3上に散在していたデータが標準化された構造のもとに整理され、「データがどこにあるかわからない」という根本的な課題が解消されています。メタデータの整備を移行とセットで行ったことで、移行完了時点でセルフサービスでのデータ参照が可能な状態を実現できました。

Liquid Clusteringは、運用負荷の低い最適化手法として期待通りの役割を果たしています。新規構築のタイミングで導入できたことでスムーズに適用が進み、特定マートでの先行移行によって手順の検証も行えました。

プロジェクト全体を通じた学び

個別の技術以上に、移行プロジェクト全体を通じて得た学びがあります。

最も苦労したのは、既存マートのリバースエンジニアリングです。チームごとに独立して管理されていた既存マートはドキュメントが整備されていないケースも多く、ETLのコードやSQLを読み解きながら一つひとつ紐解いていく必要がありました。加えて、Gold層の設計方針として「ビジネスロジックは各分析チームに委ねる」と定めたため、既存マートに埋め込まれたビジネスロジックのうち、どこまでをGold層に残し、どこからを排除するかの線引きが非常に困難でした。第4章でも触れた通り、棚卸しの段階でレイヤーの設計方針と突き合わせるところまで踏み込んでいれば、この工数を大幅に削減できたはずです。

また、レイヤー設計のガイドラインの粒度や、分析者への新環境のオンボーディングなど、技術選定以外の「人と組織に関わる準備」の重要性を改めて実感しました。技術的にはモダンな基盤を構築できても、それを使う人への情報共有が不十分であれば、移行の効果は十分に発揮されません。

8. おわりに

本記事では、EKS上でサイロ化していたデータマートをDatabricksへ移行し、メダリオンアーキテクチャ × Unity Catalog × Liquid Clusteringによって分析基盤を再設計した取り組みをご紹介しました。

振り返ってみると、今回の移行は単なるプラットフォームの変更ではなく、データに対する考え方そのものを変える取り組みとなりました。チームごとに閉じていたデータを全社的な資産として再定義し、適切なガバナンスのもとで活用できる基盤を整えたことが、最も大きな成果だと考えています。

今後は、運用実態を踏まえたメダリオンアーキテクチャのレイヤー構成の見直しや、蓄積された運用データをもとにしたLiquid Clusteringのチューニング、データ品質の自動監視の仕組みの導入、さらには機械学習パイプラインとの連携といった発展的なテーマにも取り組んでいく予定です。

この記事が、同じような課題を抱えている方の参考になれば幸いです。最後までお読みいただきありがとうございました。