Overview

本記事ではデータプラットフォームを構築する場合に知っておくべき基本的な概念について整理する。

シニアエグゼクティグなどが「データ分析をするために DWH を構築する」と言ったときに、実際には何が欲しいのか。 おそらく特定のユースケースのデータマートで、いくつかの KPI を見たい場合が多いと思うがエンジニアリング視点ではデータマートを構築するためにはいくつかのステップが必要。 エンジニア側と各ステークホルダーの理解を合わせる必要があるため、本記事は単語や概念の理解の齟齬をなくすために使えるメモとして作る。

DWH 構築にあたってまず考えるもの

ユニバーサル言語

DDD と同様にデータ処理環境構築においても非エンジニアを含むステークホルダーと開発するエンジニアで共通言語を保つ必要がある。

データソース

オリジナルデータやデータの発生源のこと。

• 各アプリケーションの OLTP 用の RDB
• Webs サーバーのログ
• スクレイピングなどを行う外部のデータ

データレイク

多様なデータを集約する場所。データソースのデータをそのままコピーしたデータや置き場を指す。 加工や結合をしておらず、データソースと 1 対 1 であるべき。

• 販売情報など
• GCS などのオブジェクトストレージに置く事が多い

データウェアハウス

DWH と表現することが多い。加工・結合したデータの置き場を指す。 より多くの情報に基づく意思決定を行うための分析可能なデータの集中管理場所。

• 売上情報サマリーなど
• BigQuery や Hadoop など大規模なデータを高速に処理可能な基盤に置く

データマート

加工・結合したデータの置き場。特定用途向けのデータ、またその置き場を指す。 複数のチャネルでの売上データをアグリゲーションし作った統合価格テーブルなど。

• DWH から必要な情報を抽出した View
• DWH からデータを抽出して RDB に挿入したもの

データパイプライン

データソースから取得したデータを DWH やデータマートに格納する過程で、ETL ¹ などを用いて情報収集・蓄積・加工・抽出などを行う一連のフローのこと。 データ処理のワークフロー。

バッチ処理

大量のデータを一度に処理するために定期的に実行する処理。

ストリーム処理

データの発生時点でリアルタイムに加工・抽出・保存などを行う処理。

その他ドメイン独自の用語

EC なら Product や Order、SaaS なら MAU、MRR、Churn など業務ドメイン独自の単語が出てくるので、これらも認識をあわせるべき。

例えば商品配送のことを Shipment と表現したり Fulfillment と表現することが有るが、これらは同じものなのか、利用する場面や背景が異なるのかがわからない。 エンジニア側とステークホルダー側で用語ごとの認識合わせを行うべき。

[図 1: Google Cloud の導入を促進する 13 のサンプル アーキテクチャ²より]

CRUD 表

データの出入り口を理解するために CRUD 表を作ると良い

	社外	社外	社内	社内	社内	社内
	競合 A	比較サイト	EC サイト	調達	マーケティング	経理
商品	CUD	CU	CRU	R	R	R
価格	CU	CU	CRU	R	R	R
在庫	CU		CRU	R	R
クーポン			R		C	R

組織を超えたコラボレーション

データの生成者と利用者でお互いにフィードバックを与えられる文化を醸成する必要がある。

• データの生成者は提供するデータで有用だと思えるのに活用されていないものを伝える
• データの利用者は足りないデータを生成するよう伝える

各レイヤーで気をつけるべきポイント

データソースレイヤー

オリジナルデータやその発生源。EC サイトなら購買履歴などの OLTP の DB などを指し、外部のデータなら API を提供しているサービスやスクレイピングする対象の Web サイトを指す。

データソースの品質

Garbage in, garbage out

• この段階でデータがダメだとその先持つ買い物にならない
• 必要なデータが無いとそもそも分析できない

データの品質はデータソースで確保する必要があり、下流(データ利用者)から上流(データ提供者)へフィードバックする必要がある。

データの生成過程を知る

データがどのような形で作られているのか理解する。 同じようなデータでも精度が異なる場合や、リアルタイムなのか一定時間毎に更新されるのかという点が異なる場合があり、データの信頼性に影響する。

業務のフローを理解することも重要で、ユーザーストーリーなどを確認し(作成し)、業務中での登場人物や各ステップで行うこと、生成されるデータを書き出すと良い。

特に管理するべきデータ

マスタデータ

同じものを指すのに入力者やデータ取得元が違うと異なる表現になるとデータの利用が難しくなる。 部署やアプリケーションを横断して表記の差異が無いようにマスタデータの管理が必要。

このマスタデータは全体で共有の ID で運用される必要がある。

履歴データ

データが上書きされるとある時点での状態がわからなくなる。

データ分析チームや、カスタマーサポート、監査やリーガルなどのチームでは履歴情報が重要。 特にマスタデータの場合は削除や更新するのではなく、バージョニングするべき。

データレイクレイヤー

データレイクは元のデータをコピーして一つのシステムに集約したもの。

形式はオブジェクトストレージに保存するか、分析用 DB に保存することが多い。

データの加工をしない

データレイクレイヤーでは分析用に集計しなりせず、何も加工していないのが重要。仮に中身に誤りがあっても修正や加工をせずそのまま集約する。

• 分析の視点が変わったときにデータが無いことを防ぐ
• 加工していた場合データが間違っているときに元データが間違っているのか、加工時点で間違えたのかがわからなくなる

同一箇所に作る

データレイクを複数箇所に作るのはバッドプラクティス

• コピーされたデータとコピーされてないデータの管理が難しい
• 処理の変更があった場合に複数箇所の変更が必要
• チームや組織を横断したデータの活用が行いやすい

DWH レイヤー

分析対象の指標などのデータやその置き場。

• DWH は全体の SSOT ³ として共通の ID を用いて、同一箇所で運用するべき
• 指標の基準をあわせる
  • 売上は税込みか税抜きか
  • 利益マージンの計算方法

DWH 構築時の処理

DWH の構築は何段階かの処理を経て実現される。

データクレンジング

データソース (データレイク) のデータは完全な状態でなかったり、複数の データソースを参照する場合に表記が異なる事がある。

データクレンジングでは主に以下のような処理を行う。

• 欠損データ埋め
• 重複削除
• データの名寄せ・共通化

ディメンショナルデータモデリング

ディメンショナルデータモデリングではスノーフレーク・スキーマやスター・スキーマと呼ばれるような形でスキーマを定義し、データを保持する。 この段階により、多次元分析で行われる軸の入れ替えやドリルダウン＆ドリルアップ、次元のスライスといった操作を可能にする。

例えば次の時間軸や地域を次の例のように分割することで分析の粒度を調整しやすくなる。

year	quarter	month	day
2022	Q1	2	13
2022	Q1	3	14

country	prefecture	city	area
Japan	Tokyo	Minato	Akasaka
Japan	Tokyo	Shibuya	Yoyogi

指標のアグリゲーション

DWH では年月や商品、場所、そのた属性情報などのディメンションデータを用いて指標の集計を行う。

部署によって用途が異なるデータはデータマート層で扱うのが良いが、売上などのチームを横断して共通の指標は DWH 層で扱うと良い。

データマートレイヤー

データマートとは、特定の利用者や用途向けに加工・整理したデータやその置き場を指すし、基本的にデータのユースケースと一対一となる。

DWH を構築出来るほど業務知識が体系化されていない場合には、データレイクをさんしょうしてデータマートを作り、DWH の早すぎる最適化を防ぐ方法もある。

ユースケースごとにデータマート作る

1. 影響範囲を制限する
   • 新たなデータソースを使ったり、ユースケースを使うときに他へ影響を気にしたくない
2. パフォーマンス
   • 利用するデータを絞ることで影響範囲を制限する
   • 事前に必要な集計処理を行う

ユースケース

ここでのユースケースはデータ基盤を用いたデータの用途を指す。ユースケースには以下のような例がある。

• 売上高、在庫状態、販売・仕入れ、利益マージン・広告コストなどの KPI モニタリング
• 商談開始から契約完了までの状態
• 機能開発や、AB テストの結果の計測
• 売買と地域性の分析
• アプリケーションログを用いたユーザー解析
• 障害発生時の影響範囲特定

ユースケースの計画

以下のポイントを考慮してデータを処理するためにユースケースを事前に計画する。

• データの必要なタイミング
  • バッチ処理でよいのか、ストリーム処理が必要なのか
• データを用いて何を見たいのか、どんな意思決定をしたいのか
• データ利用の 5W1H を予め想定する

参考

全体

• 実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ
• データウェアハウスの概念
• Converging Architectures: Bringing Data Lakes and Data Warehouses Together
• データレイクとしての Cloud Storage

ディメンショナルモデリング

• ディメンショナル・データ・モデル - IBM
• スター スキーマと Power BI での重要性を理解する

Footnotes

1. Extract, Transform, Load ↩

2. https://cloud.google.com/blog/ja/products/application-development/13-popular-application-architectures-for-google-cloud ↩

3. Single Source Of Trust ↩