Datamart作成Tips

SQL
Author

Ryo Nakagami

Published

2025-06-28

Modified

2025-08-26

データマートとは?

Definition 1 データマート

  • 特定のクエリ群で必要とされるデータだけを保持する,相対的に小さなサイズのテーブルのこと
  • アクセス対象テーブルサイズを小さくすることでI/O量を減らすのが種目的

Definition 2 ゾンビマート

  • もう参照されていないのに無駄に同期処理が行われているデータマート

データマートの実装方法

データマートをどう構築するかは要件次第で,大きく分けると以下の方法があります.

方法A: 物理テーブルに実装

  • データマート専用のテーブルを作成し,ETL/ELT処理で定期的にロードする
  • 長所: 高速,データが安定している
  • 短所: ETLコストが高い,ストレージ消費が大きい

方法B: ビュー (View) で実装

  • DWHの基盤テーブルに対するSQLを「ビュー」として定義し,利用者はビューを参照
  • 長所: 柔軟で開発が早い,ストレージ不要
  • 短所: 元テーブルに毎回クエリが走るため重い集計では遅くなる

方法C: マテリアライズドビューで実装

  • 上記の「ビュー」の欠点を補う形で,集計結果をあらかじめ保存
  • 基本的に「単一テーブルに対する単純な集計」が対象
  • 長所: 高速,利用者からはビュー同様に見える
  • 短所: 更新タイミングの設計が必要(鮮度とパフォーマンスのトレードオフ)
BigQuery のマテリアライズドビューに関する制限事項
  • マテリアライズドビューで使える集計関数は限定的で,「基本的な集約 + 一部の近似集計やビット演算」に限られる
  • 自己結合や RIGHT/FULL OUTER JOIN はサポートされていない
  • ユーザー定義関数(UDF)やウインドウ関数などは使用することができない

データマート作成にあたっての観点

1: データ同期のタイミング
  • オリジナルテーブルとの動機タイミングが短いほどデータ鮮度は新しくなる
  • 一方,更新頻度が多いほどDWHに与える負荷は大きくなる
  • 一般的には,同期は夜間バッチにおいて実行されることが多く,この場合のデータ鮮度は最低1日前となる
2: データマートのサイズ
  • オリジナルテーブルとサイズがあまり変わらないデータマートを作ってもI/O量の節約にはつながらない
  • データマート設計段階で,取引単位や日次集計かなどを観測単位を設計し,事前にGROUP BY処理を実施することが推奨
3: データマートの数
  • データマートは分析用途ごとに作成されることが多く,数が増えるほど管理工数やストレージ負荷が増加する
  • 同じ指標やマスタを複数のデータマートでばらばらに管理すると,分析結果の整合性が崩れるリスクがある
  • 過剰に細分化すると更新処理や同期の複雑さが増すため,必要最小限の粒度で統合・共通化を検討
4: バッチウィンドウ
  • データマートのETL処理自体にもコンピュテーションリソースを消費する
  • 夜間や利用が少ない時間帯にバッチ処理を集中させることで,システム負荷を分散できる
  • バッチウィンドウの長さが短い場合,大規模データや複雑な処理が間に合わないリスクがある
5: データ品質・正規化
  • 欠損値や異常値の補正方針を明確にしておく
  • 名寄せやコード体系の統一(部門コード・商品コードなど)が必要
  • データマート内のデータ品質を保証することで,分析結果の信頼性を向上
6: パフォーマンス最適化
  • インデックスやパーティション分割の活用を検討
  • データマートの実装方法として,materialized viewでの実装を検討
  • クエリ実行時間やI/O負荷を抑え,利用者のストレスを低減

References