アナリストがデータマート開発をするうえで気をつけること
データマートとは
本記事では、以下のように定義して話を進めます。
データウェアハウス層のデータを使用して、より分析で使用しやすいデータに加工したもの。
一般的には特定の部門やチームが使用する目的に特化したものをデータマートと呼びます。
しかし、実際はもう少し手前のトランザクションの段階で集計を止めた方が使いやすいケースも多いので、そういったテーブルもデータマートに含めて本記事では扱います。
よくあるローデータ
データアナリストが触れる機会の多いデータは以下の3種類。
トランザクションデータ
業務で発生する取引を記録したデータのこと。
例えば、注文データや配送データなど。
マスタデータ
基礎情報となるものをまとめたデータ。
例えば、商品マスタや顧客マスタなど。
イベントデータ
ユーザーの行動を記録したデータのこと。
例えば、Webサイト上やアプリ内での行動ログなど。
データマート開発の流れと留意点
データマートの要件定義
大きく以下の2つのアプローチがある。
ビジネス部門からのヒアリング
実際にデータマートを利用するメンバーが、どのようなデータマートを必要としているか調査する。
影響度や重要度をもとに、実装要否はアナリスト側で判断する必要がある。
一部の人が一定期間しか使わないような項目をすべて実装してしまうと、データマートが不必要に膨らんでしまうため。
今までの依頼内容を抽象化
よくある依頼、何度も書くSQLロジックはデータマート化を検討するタイミング。
ただし、依頼のたびにデータマート開発しているとスピード感が落ちる＆不要なデータマートが乱立するので、汎用性のない項目は集計のためだけにSQLを書いてしまった方がよい場合もある。
データモデルとデータマートの設計
以下の点に留意しつつ、設計を行う。
売上の計算やカテゴリ分類、返品の考慮など、全社で統一すべきロジックはデータマートの項目として作っておく。
集計のたびに担当者がSQLを書くと、人によって数値や名称が異なったりしてしまうため。
SQLは他のメンバーが改修する場合にもわかりやすいように可読性を意識する。
複雑なロジックはコメントをつけておいた方がよい。
PKを意識して利用者が意図せず重複カウントしてしまわないような設計にする。
データ分析の専門チーム以外が触るデータマートに関しては、ユーザー単位、注文単位などPKを明確にしてデータマートを作っておく。利用者は重複を意識せず単純にSUM、COUNTなどで集計するだけの前提で設計する。
ユーザー単位で丸めすぎない方が良い場合はトランザクションの粒度で止めておく。
すべてのデータマートをユーザー単位などで丸めすぎてしまうと、ロジックを変えて集計したい場合などに使いづらいことがある。なので、データ分析の専門チームが触るデータマートは、少し手前の状態で止めたデータマートにしておくと使いやすい。
データマートは段階的に作るとロジックが分散しなくてよい。
データマート例
注文商品データマート
内容：レコードは注文商品単位。社内で定義された商品カテゴリや、クーポンなどを考慮した金額を付与、返品も除外などをしておくと、そのあとのデータマートで使う項目のロジックが集約されていて便利。
目的：後続のデータマートで使うための一次加工テーブルとして。また、データマートの項目としてないものを、データチームメンバーが使いたい場合はここを参照できる。
参考SQL
ユーザー購買データマート
内容：レコードはユーザー単位。そのユーザーが購入した商品、流入経路、属性などを横持ちにしておく。
目的：ユーザー単位の購買分析はここを見ればできるようにしておく。
参考SQL
プロモーション分析データマート
内容：キャンペーンごとの売上効果、顧客の反応、プロモーションコストをまとめたテーブル。
目的：プロモーションのROI（投資利益率）分析と将来のキャンペーンの計画のため。
参考SQL
ユーザー行動ファネルデータマート
内容：レコードはユーザー単位。Webサイト内やアプリ内の行動など、到達度合いのファネルを横持ちにしておく。
目的：ユーザー単位のファネル分析はここを見ればできるようにしておく。
参考SQL