データマートとは、特定の業務部門やユースケースに最適化されたデータストアで、DWHのサブセットとして構築されるケースと独立して構築されるケースがあります。DWHが「倉庫」なら、データマートは「部門ごとの売り場」にあたります。実装自体は難しくない一方で、部門ごとの要望に応えて増やしていくと「マート作りすぎ問題」が発生し、指標が乱立してデータ基盤の信頼性を損ねます。本記事では定義、DWHとの違い、代表的な3つの設計パターン、作りすぎ問題の原因と5つの防止策、dbt時代の設計指針までを解説します。
データマートとは何か――「部門向けに最適化されたデータの窓口」
データマート(Data Mart)とは、特定の業務部門やユースケースのために、分析しやすい形に整形されたデータストアのことです。営業部門向けの売上分析マート、マーケティング部門向けの顧客分析マート、財務部門向けのPLマート――このように、利用者の視点でデータを切り出し、クエリが簡単に書ける状態で提供します。
DWH全体が「巨大な倉庫」なら、データマートは「倉庫から選別して並べた売り場の棚」です。データマートには2種類の生まれ方があります。1つはDWHから派生する「依存型マート(Dependent Data Mart)」で、DWHを単一の情報源とし、そこから部門向けに切り出します。もう1つは「独立型マート(Independent Data Mart)」で、DWHを経由せず直接ソースシステムからデータを取得して構築します。依存型のほうが指標の一貫性を保ちやすく、モダンデータスタックではほぼ依存型一択です。独立型は一見手軽ですが、マート同士で指標定義がずれ、データサイロの温床になります。
データマートとDWHの違い
DWHとデータマートは親子関係にあることが多いですが、性格は大きく異なります。
| 観点 | DWH | データマート |
|---|---|---|
| スコープ | 全社横断(エンタープライズ) | 特定部門・ユースケース |
| データ量 | 大(全社の履歴データ) | 小〜中(必要部分のみ) |
| 利用者 | データエンジニア、アナリスト | 部門の分析担当、BI利用者 |
| 設計の自由度 | 全社ルールに従う | 部門ニーズに応じて最適化 |
| 更新頻度 | 日次〜ニアリアルタイム | ユースケースに応じて可変 |
| クエリ性能 | 汎用(多目的クエリ向け) | ユースケース特化で高速 |
【DWHとデータマートの関係】
[ソースシステム群]
(RDB / SaaS / API / ログ)
|
v
[DWH層]
全社共通の統合データ
|
+-----------+-----------+
| | |
v v v
[営業マート] [マーケマート] [財務マート]
売上・受注 顧客・CVR 収益・経費
| | |
v v v
営業BI マーケBI 財務BI
※ 依存型マートはDWHを唯一の情報源として派生するデータマートの設計パターン3選
データマートの設計には、代表的な3つのパターンがあります。用途・BIツール・チームスキルによって適する選択が異なります。
パターン1：スタースキーマベース
ファクトテーブル（計測値）とディメンションテーブル（分析軸）で構成する古典的ながら強力な設計です。売上分析ならfct_salesを中心に、dim_customers、dim_products、dim_datesがぶら下がる形になります。JOINの数が少なく、BIツールとの相性が良いのが利点で、Tableau、Looker、Power BIのどれでも素直に接続できます。ディメンショナルモデリングの詳細はA-13で解説しています。
パターン2：ワイドテーブル(One Big Table)
JOINを事前にすべて解消し、1つの巨大な非正規化テーブルに詰め込む設計です。クラウドDWH(BigQuery、Snowflakeなど)のカラムナーストレージと相性が良く、スキャン性能が最速になります。ただし冗長性が増し、ディメンション属性の変更時にはテーブル全体の再生成が必要になるため、更新ロジックの自動化（dbtのincremental models）が前提になります。特定ダッシュボード専用の分析マートでよく採用されます。
パターン3：メトリクスレイヤー(Semantic Layer)
物理的にテーブルを増やすのではなく、指標（Metrics）を定義したセマンティックレイヤーを介して仮想的にマートを提供する設計です。dbt Semantic Layer、Cube、Looker LookMLなどのツールを使い、「売上」「粗利」「LTV」といったビジネス指標をコードで一元定義します。物理マートの増殖を抑え、指標の一貫性を保てるのが最大の利点で、近年この方向が主流になりつつあります。
dbtでスタースキーマのファクトテーブルを定義する例は次のとおりです。
-- models/marts/sales/fct_orders.sql
{{ config(materialized='incremental', unique_key='order_id') }}
SELECT
o.order_id,
o.customer_id,
o.product_id,
o.order_date,
o.quantity * p.unit_price AS order_amount
FROM {{ ref('stg_orders') }} o
LEFT JOIN {{ ref('dim_products') }} p USING (product_id)
{% if is_incremental() %}
WHERE o.order_date >= (SELECT MAX(order_date) FROM {{ this }})
{% endif %}| パターン | 複雑さ | クエリ性能 | 保守性 | 適するツール |
|---|---|---|---|---|
| スタースキーマ | 中 | 高 | 高(変更に強い) | Tableau、Looker、Power BI全般 |
| ワイドテーブル | 低(クエリ側) | 最高 | 中(再生成コスト) | BigQuery、Snowflake特化 |
| メトリクスレイヤー | 高(初期設計) | 中〜高 | 最高(一元管理) | dbt Semantic Layer、Cube、LookML |
「マート作りすぎ問題」はなぜ起きるのか
データマートは便利ゆえに増殖しやすく、気がつけば数百のマートが乱立してメンテナンス不能になる――これが多くの組織が直面する「マート作りすぎ問題」です。原因は主に3つあります。
- 部門ごとの「うちだけのマートが欲しい」要求：「共通マートは汎用すぎて使いづらい」「自分たちの定義で切り直したい」という声が次々と上がり、データエンジニアが要望を断りきれずに類似マートを量産します。
- 似て非なるマートの乱立：営業部門の「売上」とCS部門の「売上」で集計期間や返金の扱いが微妙に異なり、結果として同じ名前で異なる数字を返す複数のマートが並びます。経営会議で「うちの数字とあなたの数字が違う」論争の温床になります。
- 誰が管理しているかわからないマートの放置：マートを作った担当者が異動・退職し、誰も定義を知らないまま動き続けるマートが放置されます。壊れた際のインパクト評価も困難になり、誰も触れない「聖域」となっていきます。
結果として起きる問題は深刻です。まず指標の不一致が経営の意思決定を混乱させます。次に、使われていないマートがストレージとコンピュートのコストを食い続けます。さらに、上流のDWHに変更が入ったときに、どのマートに影響するかの棚卸しが不可能になり、安全な変更ができなくなります。データ基盤の信頼性とアジリティが同時に失われていく悪循環です。
マート作りすぎを防ぐ5つの施策
予防こそ最良の治療です。以下の5つを組み合わせて運用することで、マートの増殖を抑えつつ、必要なマートが健全に育つ状態を作れます。
- メトリクス定義の一元管理（Semantic Layer）：指標定義をdbt Semantic LayerやCubeで一元管理し、マート側では物理化された結果を提供する形にします。「売上」の定義が1箇所に集約されることで、部門間の齟齬が構造的に防げます。
- マート棚卸しの定期実施：四半期に1度、全マートのオーナー、最終更新日、利用頻度を棚卸しし、3ヶ月以上使われていないマートを削除候補に挙げます。「使われていないマートは負債である」という共通認識を持つことが重要です。
- 利用状況の可視化（クエリログ分析）：DWHのクエリログからマートごとのアクセス数・ユーザー数を集計し、ダッシュボードで公開します。データが見えれば判断できる、という基本原則をマート運用自体にも適用します。
- 命名規約とドキュメンテーションの徹底：fct_、dim_、mart_などのプレフィックス規約と、dbtのschema.ymlによるドキュメント必須化でマートの見通しを保ちます。新規マート作成時にはオーナーと利用目的の記載を必須とします。
- データコントラクトの導入：上流DWHとマート間でスキーマ・品質・SLAの契約を結び、変更の影響範囲を明示的に管理します。詳細はA-16 データコントラクトで解説しています。
dbt時代のデータマート設計
dbtの普及によってデータマート設計の常識は大きく変わりました。dbtのモデルレイヤーは典型的に次の3層構造で組まれます。
- staging層(stg_)：ソースシステムからの取り込み直後の軽い整形。1ソース＝1モデルが原則。
- intermediate層(int_)：複数のstagingを結合・加工する中間処理。ビジネスロジックを凝集する場所。
- marts層(fct_ / dim_)：最終的な分析用マート。BIツールが直接参照する層。
このレイヤー構造によって、マートの責務が明確になり、依存関係の追跡が容易になります。マートはあくまで「marts層」に限定し、部門要望はintermediate層までで処理するのが規律です。
models/
├── staging/
│ ├── stg_orders.sql
│ ├── stg_customers.sql
│ └── stg_products.sql
├── intermediate/
│ ├── int_orders_enriched.sql
│ └── int_customer_metrics.sql
└── marts/
├── sales/
│ ├── fct_orders.sql
│ └── dim_customers.sql
└── marketing/
└── fct_campaign_performance.sqlまとめ――データマートは「作る」より「管理する」が難しい
- データマートは特定部門・ユースケース向けに最適化されたデータストアで、DWHのサブセットとして構築するのが現代の主流です。
- 設計パターンはスタースキーマ、ワイドテーブル、メトリクスレイヤーの3系統で、用途とBIツールに応じて使い分けます。
- 「マート作りすぎ問題」は部門要望の積み重ねと類似マートの乱立から生まれ、指標の不一致とコスト肥大を招きます。
- 予防策はメトリクス一元管理、定期棚卸し、利用状況可視化、命名規約、データコントラクトの5つです。
- dbtの3層構造(staging → intermediate → marts)を守ることが、スケーラブルなマート運用の基礎になります。
併せて読みたい関連記事として、A-12 データモデリング、B-01 dbt入門、C-02 3層アーキテクチャをご参照ください。DE-STKでは、マート乱立に苦しむ組織に対してセマンティックレイヤーへの移行支援を行っています。
よくある質問(FAQ)
Q. データマートとDWHの違いは何ですか?
DWHは企業全体のデータを統合する基盤で、データマートは特定部門やユースケースに最適化されたサブセットです。マートはDWHから必要なデータを抽出・加工して構築するのが一般的で、依存型マートと呼ばれます。独立型マートは一見手軽ですが指標の不一致を生みやすいため、現代では依存型が推奨されます。
Q. データマートはいくつ作るべきですか?
正解はありませんが、目安として「ビジネスドメイン単位」で設計するのが推奨です。部門ごとに個別のマートを作ると増殖しやすいため、メトリクス定義の一元管理と定期的な棚卸しが重要です。数百のマートが並んでいる組織は、まずセマンティックレイヤーへの集約を検討するとよいでしょう。
Q. データマートの設計にはどのツールを使いますか?
dbtが最も普及しており、staging→intermediate→martsの3層構造でマートを定義・管理できます。BIツール側のSemantic Layer（LookML、Cube等）を活用する方法もあります。dbt Semantic Layerとの組み合わせで、物理マートを最小化しつつ指標定義を一元化する構成が現在の主流です。