本エントリは「ZOZO Advent Calendar 2025」の16日目の記事です。
はじめに
こんにちは、株式会社ZOZOの髙木です。データ推進ブロックでリーダーをしており、全社のデータガバナンス・データマネジメントに関連する課題解決を担当しています。
ZOZOでは、データ基盤ブロックと共に「Core DataMarts」というデータマート群を構築・運用しています。本記事では、SSoT(Single Source of Truth)を実現するCore DataMartsの概要と、その中の一つであるDimensional DataMartsの運用方法について紹介します。
詳細なアーキテクチャやレイヤリング/モデリングは以下をご参照ください。
参考: ZOZO Tech Meetup ～データガバナンス / データマネジメント～
Core DataMartsとは
Core DataMartsは、ZOZOのデータ基盤の中核を担うデータマート群です。BigQueryとdbt Coreをベースに構築されており、用途に応じた3種類のデータマートで構成されています。
なぜ複数のデータマートが必要なのか
データ活用の現場では、様々な要求があります：
- データアナリスト: 「今すぐこの数字が知りたい！」（即時性重視）
- プロダクトチーム: 「このデータを自社サービスに組み込みたい」（安定性重視）
- MLエンジニア: 「長期的に使える特徴量が欲しい」（再利用性重視）
これらすべてを1つのデータマートで満たそうとすると、以下の問題が発生します：
- 頻繁な変更で後続システムに影響が出る
- パフォーマンスとメンテナンス性のトレードオフ
- 責任範囲が不明確になる
そこでZOZOでは、用途に応じて最適化された3つのデータマート群を提供しています。
図1: Core DataMarts概要
3種類のデータマート
Core DataMartsは以下の3種類で構成されています。
1. Analysis DataMarts（即時性重視）
アドホック分析・ダッシュボード作成向けのワイドテーブルです。ドメインごとに分けてはいるものの、ある程度JOINせずに使える形式で、サービス別（ZOZOTOWN、WEARなど）に分離しています。
システム・プロダクトからの参照は原則NGとしています。ビジネス要件の変化に応じて迅速に改修できる環境を保つためです。
2. Data Products（安定性重視）
特定システム・プロダクト向けに特化した安定データセットです。リバースETLなど、対象システムの要件に100%合わせて設計しています。ステークホルダーと障害対応方針が明確なため、安定運用が可能です。
3. Dimensional DataMarts（再利用性重視）
汎用的で長期利用可能な共通データ基盤です。ディメンショナルモデリング（Fact/Dimensionテーブル）を採用し、ビジネス構造を客観的に表現しています。一度正しく設計すれば将来のビジネス変化にも耐えられる堅牢性があり、MLパイプラインなどシステムへの組み込みに適しています。
正規化されているため、利用者はテーブル間の関連性を理解してJOINする必要があります。アドホック分析ではAnalysis DataMartsの方が使いやすいケースもあります。
比較表
| 特徴 | Analysis DataMarts | Data Products | Dimensional DataMarts |
|---|---|---|---|
| 主な用途 | アドホック分析・可視化 | 特定システム | 汎用的 |
| データ構造 | ワイドテーブル | 特化型 | 正規化（スタースキーマ） |
| 変更頻度 | 多い | 要件変更に依存 | 少ない |
| システムなどの後続利用 | 原則NG | OK（特定用途） | OK（汎用） |
| 学習コスト | 中 | 特定の用途のためなし | 高い |
Dimensional DataMartsの運用
「長期利用・再利用性重視」という特性上、Dimensional DataMartsはアドホックな分析だけでなく、多様なシステムから利用されます。そのため、リリース当初から以下の運用設計を組み込みました。
運用の全体像
1. サービスアカウントの許可制
Dimensional DataMartsへのシステムからのアクセスは、サービスアカウントの申請ベースで管理しています。
- 申請時の必須項目: 責任者、利用目的
これにより「誰が・何の目的で使っているか」を常に把握できます。
個人ユーザー（アナリスト等）は申請不要です。全社共通のadhoc用の容量コミットメントを利用し、ユーザーごとの消費スロットの閾値で管理しています。
2. SA管理簿の仕組み
申請されたサービスアカウントは、Googleスプレッドシートで管理しています。このスプレッドシートを外部表としてスキーマ定義することで、BigQueryから直接参照できるようにしています。
この仕組みにより、後述する未登録SA検知のクエリで管理簿と突合できます。
3. 利用状況の監視
クエリログをもとに、以下を日次でダッシュボード化しています：
- クエリ実行数
- サービスアカウント別のクエリコスト
異常な増加があれば早期に検知できます。
4. 未登録サービスアカウントの自動検知
INFORMATION_SCHEMA.JOBSのクエリ実行ログと、SA管理簿（外部表）を突合し、未登録のサービスアカウントを日次で検知しています。
検知にはCoppe（社内の監視パイプライン基盤）を使用し、未登録SAが見つかった場合はSlackに通知されます。
参考: BigQueryにおけるデータ品質監視をCoppeで構築する
運用の成果
これらの取り組みにより、以下を実現しています：
- 用途不明なアクセスの防止: 許可制により事前に把握
- 問題の早期発見: 監視と自動検知で迅速に対応
- コスト最適化: 利用状況の可視化で無駄を削減
おわりに
本記事では、ZOZOにおけるCore DataMartsについて、「即時性」「安定性」「再利用性」という3つの軸でデータマートを分けた背景と使い分け、および運用方法を紹介しました。
データ基盤は「作って終わり」ではありません。特に長期利用されるDimensional DataMartsでは、申請フロー・監視・自動検知を初期段階から組み込み、継続的に健全性を維持しています。
もしデータマートの運用に悩んでいるなら、「用途別の分離」と「最初から運用を設計する」という視点が参考になれば幸いです。
参考資料
- ZOZO Tech Meetup ～データガバナンス / データマネジメント～ - データ基盤の構成、dbtでのレイヤリング・モデリング
- BigQueryにおけるデータ品質監視をCoppeで構築する - 本記事で触れたCoppeの詳細