データマート入門：概要から設計・運用まで、クラウド時代のベストプラクティス
エバープレイ編集部データマートとは — 概要
データマート（data mart）は、組織内の特定部門や業務ニーズに特化して設計された、分析・報告用のデータの集合（サブセット）です。全社的なデータウェアハウス（DW）の一部として位置づけられることが多く、部門ごとに最適化されたデータモデル、集計、アクセス権限を備えることで、BI（ビジネスインテリジェンス）やセルフサービス分析の応答性と利便性を向上させます。
データマートの基本的な特徴
- 対象：特定の業務領域（販売、在庫、会計、人事、マーケティング等）にフォーカス。
- 規模：データウェアハウスより小さく、特定の分析ニーズに合わせて最適化される。
- 設計：分析クエリやレポートを高速に実行できるよう、スタースキーマ等のデータモデリングが採用されることが多い。
- 運用：アクセス権管理・データ品質・更新頻度（バッチまたはリアルタイム）など運用要件が明確。
データマートの分類
一般的に以下の3種類に分類されます。
- 依存型データマート（Dependent Data Mart）：全社DWや統合データレイクを上流ソースとし、そこから抽出／変換して作るデータマート。データ整合性が確保しやすい。
- 独立型データマート（Independent Data Mart）：部門ごとに独自に構築するもので、運用の自由度は高いが全社横断の整合性・重複管理が課題となる。
- ハイブリッド型：上記を組み合わせたアプローチ。共通のマスターはDWで管理し、部門特有の変換や集計は各データマートで行う等。
データマートとデータウェアハウスの違い
両者は密接に関連しますが、役割とスコープが異なります。データウェアハウスは組織横断の統合データを長期保存し、データ統合・正規化・履歴管理を目的とします。一方、データマートは特定の分析用途に最適化した「局所的なビュー」を提供します。設計思想としては、Bill Inmonの「トップダウン（DWを先に作る）」とRalph Kimballの「ボトムアップ（部門別のマートを作り統合する）」の議論が有名です。
データモデリング：スタースキーマとスノーフレーク
データマートでは主に次の2つのスキーマが使われます。
- スタースキーマ（Star Schema）：中央にファクト（事象や取引を表すテーブル）、周囲にディメンション（日時・製品・顧客など）を配置するシンプルなモデル。クエリ性能と理解しやすさでBIに適する。
- スノーフレーク（Snowflake Schema）：ディメンションをさらに正規化して階層化したモデル。ストレージ効率やデータ重複削減に有利だが、クエリはやや複雑になる。
設計時には「ファクトの粒度（grain）」を明確に定義することが重要です。粒度が不一致だと集計や結合時に誤差が生じます。
ETL vs ELT — データ取込みの流れ
従来はETL（Extract, Transform, Load）が主流で、ソースから抽出→変換処理→データマートへロードする手法でした。クラウドと大規模ストレージ／クエリ性能の向上により、近年はELT（Extract, Load, Transform）が増えています。ELTではまずデータをターゲット（データレイクやクラウドDWH）にロードし、ターゲット上で変換や集計を行います。選択はデータ量、変換の複雑さ、コスト、運用体制によります。
データマート設計のアプローチ
- 要件定義：ユーザー（分析者／部門）の要求、必要なKPI、更新頻度、遅延許容時間を明確化。
- データソースの特定：業務システム、外部データ、マスターを洗い出し、正確で一貫したソースを選定。
- データモデル設計：ファクトとディメンション、粒度、キー設計、履歴管理方式（SCD：Slowly Changing Dimension）を決める。
- パイプライン実装：ETL/ELTツールやジョブスケジューラで抽出・変換・ロードを自動化。ログ・監視を組み込む。
- テストと検証：データ品質・性能・権限の検証。サンプルユーザーによる受け入れテスト（UAT）。
- 運用と改善：モニタリング、コスト管理、定期的なスキーマや集計の見直し。
パフォーマンス最適化の手法
- 適切なパーティション設計とクラスタリング（日時や地域で分割）
- インデックス、マテリアライズドビュー、集計テーブルの活用
- 必要な列だけを保持する幅の狭いテーブル設計
- キャッシュやデータベースの列指向ストレージを利用した高速化（例：Amazon Redshift、Snowflake、BigQuery）
- クエリのリファクタリングやBIツール側での集計制御
セキュリティとガバナンス
データマートは部門特化であっても、個人情報や機密情報を含む場合が多く、適切なガバナンスが不可欠です。主な対策は以下の通りです。
- アクセス制御（ロールベース、列レベル/行レベルセキュリティ）
- データマスキングやトークナイゼーション
- 監査ログと変更履歴の保存
- データカタログやメタデータ管理によるデータ系統（Data Lineage）の可視化
- 定期的なデータ品質チェックとSLAの管理
クラウド時代のデータマート
クラウドデータプラットフォーム（Snowflake、BigQuery、Redshift、Azure Synapse等）やデータレイク／レイクハウス（Delta Lake等）の普及により、データマートの実装形態も多様化しています。ポイントは次の通りです。
- ストレージとコンピュートの分離でスケールしやすい
- ELTを採用しやすく、処理の柔軟性が高い
- サーバーレスやオンデマンド課金により小規模チームでも導入しやすい
- データメッシュやデータプロダクトの考え方と親和性が高く、部門が自律的にマートを管理する運用モデルが増加
導入時のベストプラクティス
- ビジネス指標（KPI）起点で設計し、使用ケースを限定する
- スキーマ変更に備えたバージョニングとCI/CDパイプラインの導入
- データ品質ルールと監視（アラート）を自動化する
- メタデータ管理とデータカタログで再利用性を高める
- コスト監視（クエリコスト、ストレージ）を実装する
- ユーザー教育とセルフサービスBIの促進
典型的なユースケース
- 販売データマート：日次売上、SKU別実績、プロモーション効果分析
- マーケティングデータマート：キャンペーン効果、チャネル別ROI、顧客セグメンテーション
- 財務データマート：月次決算、コスト配分、予実管理
- 供給チェーンデータマート：在庫推移、リードタイム分析、供給障害のトラッキング
課題と落とし穴
- 独立型マートの乱立によるデータのサイロ化と整合性低下
- 要件が曖昧なまま作ると不要なテーブルや集計が増加し、保守性が低下
- データガバナンス（誰が責任を取るか）の不明確さ
- リアルタイム要件が高い場合、従来のバッチ処理では遅延が問題になる
- クラウドコストの監視不足で予期せぬ高額請求に陥るリスク
まとめ
データマートは、部門別の分析ニーズに特化したデータ集約基盤であり、適切に設計・運用すればBIの応答性と働きやすさを大きく向上させます。一方でサイロ化、整合性、ガバナンスの課題を招かないよう、企業全体のデータ戦略（データウェアハウス、データレイク、データカタログ、ガバナンス体制）と整合させることが重要です。クラウドやレイクハウスの技術進化により、データマートはより短期間で柔軟に構築できるようになりましたが、要件定義と運用設計を丁寧に行うことは以前として不可欠です。
参考文献
- Wikipedia: Data mart
- The Kimball Group — Ralph Kimball（スター・スキーマ、ボトムアップの理論）
- Bill Inmon（トップダウンDWの考え方）
- Microsoft Learn: What is a data mart?（Azure Synapse のドキュメント）
- AWS: Data lakes and analytics（AWS のデータ分析関連資料）
- Google Cloud: Data warehouse overview（データウェアハウスとマートの位置づけ）
- Snowflake（クラウドDWHとデータマート構築のプラットフォーム）
- Databricks: What is a data lakehouse?（レイクハウスとデータマートの関係）
