データマートとは？DWHとの違い・設計パターン・作りすぎ問題の防ぎ方

データマートとは、特定の業務部門やユースケースに最適化されたデータストアで、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との組み合わせで、物理マートを最小化しつつ指標定義を一元化する構成が現在の主流です。