1 of 42

実践的データ基盤への処方箋 読み会

​

2022/01/20

​

しんゆう 　@data_analyst_

2 of 42

本資料についての注意点

本資料について

  • 内容は資料公開時点における私見です
    • 後日意見が変わっているかもしれませんがご了承ください
  • 　　　　　　はコメントです

3 of 42

自己紹介

本資料について

  • 名前：しんゆう　@data_analyst_
  • ブログ：データ分析とインテリジェンスhttps://analytics-and-intelligence.net
  • 主な活動：データを使いやすくする人

（データアーキテクトまたはデータ整備人）

​

​

4 of 42

目次

  1. 1-5 データレイク層の一箇所にデータのソースのコピーを集約する
  2. 1-6 データウェアハウス層では分析用DBを使って共通指標を管理する
  3. 1-7 共通指標は本当に必要とされるものを用意する
  4. 1-8 特定用途に利用するデータマートはユースケースを想定してつくる
  5. まとめ

5 of 42

目次

  • 1-5 データレイク層の一箇所にデータのソースのコピーを集約する
  • 1-6 データウェアハウス層では分析用DBを使って共通指標を管理する
  • 1-7 共通指標は本当に必要とされるものを用意する
  • 1-8 特定用途に利用するデータマートはユースケースを想定してつくる
  • まとめ

6 of 42

データレイク層とは何か

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • データレイク（Data Lake）層とは、データを1つのシステムに集約したもの
  • データは、データソースと一対一
  • 何も加工していない、ただのコピーであることが重要
  • データの中身に誤りがあったとしても、修正や加工をせず、そのまま集約する

7 of 42

データレイク層とは何か

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • データレイク（Data Lake）層とは、データを1つのシステムに集約したもの
  • データは、データソースと一対一
  • 何も加工していない、ただのコピーであることが重要
  • データの中身に誤りがあったとしても、修正や加工をせず、そのまま集約する

図書館とか資料室も（ある意味）データレイク

8 of 42

どのようにデータレイクをつくるか

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • ファイル形式でデータを置くか、データウェアハウス製品という分析用DBに取り込むか
  • データがデジタル化されていない場合は、データ収集の業務を構築する必要がある
  • 紙の帳票・書類はキーボードでデータを入力したり、スキャナで取り込んで画像ファイルとして保存する

9 of 42

どのようにデータレイクをつくるか

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • ファイル形式でデータを置くか、データウェアハウス製品という分析用DBに取り込むか
  • データがデジタル化されていない場合は、データ収集の業務を構築する必要がある
  • 紙の帳票・書類はキーボードでデータを入力したり、スキャナで取り込んで画像ファイルとして保存する

​

デジタル化や整備に工数がかかりすぎるので非デジタルはそのまま、Excelとかはファイル形式＋あとはDWHと併せて３つの状態が平行になりがち

10 of 42

現場で生じるデータレイク層の課題

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • 「データレイクがデータレイクになっていない」
    • 分析用に集計してから連携してしまう
    • 複数箇所にデータレイクをつくってしまうケース

11 of 42

現場で生じるデータレイク層の課題

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • 「データレイクがデータレイクになっていない」
    • 分析用に集計してから連携してしまう
    • 複数箇所にデータレイクをつくってしまうケース

課題としては他にも

  • データレイクにアクセスする権限がない
  • データレイクにあるのかないのかがすぐにわからない

12 of 42

なぜデータを一箇所に集めるべきか

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • 集約すると部署横断のデータ活用が容易になる
  • 分散しているとその都度以下のことが必要
    • データがどこにあるのかを探す
    • データの利用申請を行う
    • システム要件を定めて開発を行う

13 of 42

なぜデータを一箇所に集めるべきか

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

  • 集約すると部署横断のデータ活用が容易になる
  • 分散しているとその都度以下のことが必要
    • データがどこにあるのかを探す
    • データの利用申請を行う
    • システム要件を定めて開発を行う

分析の事例は持っているデータしか見ない「分析の失敗」。可用性バイアスはデータレイクに集約されていても発生する

事前に準備しておくことの有用性が第一かなと思っている

14 of 42

目次

  • 1-5 データレイク層の一箇所にデータのソースのコピーを集約する
  • 1-6 データウェアハウス層では分析用DBを使って共通指標を管理する
  • 1-7 共通指標は本当に必要とされるものを用意する
  • 1-8 特定用途に利用するデータマートはユースケースを想定してつくる
  • まとめ

15 of 42

データウェアハウス層とは何か

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

  • 共通指標となるデータ、ならびにそのデータの置き場
  • 複数のデータを統合・蓄積して、整理したデータ
  • 分析用DBで集計・管理することが望ましい

​

16 of 42

データウェアハウス層とは何か

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

  • 共通指標となるデータ、ならびにそのデータの置き場
  • 複数のデータを統合・蓄積して、整理したデータ
  • 分析用DBで集計・管理することが望ましい

​

データそのものをDWHと呼ぶことは他では見たことない

データソースと同じではないがそのまま使えるほどでもないデータが入っているところはデータレイクなのかデータウエアハウスなのか

  • JSONをパースしただけのテーブル

17 of 42

なぜ共通指標を集計すべきか

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

  • 部署ごとに独自の指標を集計してしまうと、部署横断のデータ活用は進まない
  • SSOT（Single Source of Trust：信頼できる唯一の情報源）として、一箇所で定めておく

18 of 42

なぜ共通指標を集計すべきか

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

  • 部署ごとに独自の指標を集計してしまうと、部署横断のデータ活用は進まない
  • SSOT（Single Source of Trust：信頼できる唯一の情報源）として、一箇所で定めておく

共通指標を集計することは同意。ないと部署どころか隣の人とも違う定義で集計を行って間違い探し大会が頻繁に起きる

ただしガバナンスの話なのでDWHと併せて考えないほうがいいかも

19 of 42

なぜ分析用DBで共通指標を集計・管理すべきか

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

  • 分析用DBはユースケースで用いられるツールと適切に連携できる
  • 一方で表計算ソフトや BIツールで共通指標を管理すると、多様なユースケースに対応できなくなる

20 of 42

なぜ分析用DBで共通指標を集計・管理すべきか

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

  • 分析用DBはユースケースで用いられるツールと適切に連携できる
  • 一方で表計算ソフトや BIツールで共通指標を管理すると、多様なユースケースに対応できなくなる

ユースケースとは「データ基盤の用途」のこと。詳細は１－９

集計や管理を表計算やBIで行わない方がいいのは本当にその通りだけどそのためのクエリは別に考えた方がいいかも（現在のところはDWHと呼ばれるところに置かれるのが主流、ぐらい）

21 of 42

目次

  • 1-5 データレイク層の一箇所にデータのソースのコピーを集約する
  • 1-6 データウェアハウス層では分析用DBを使って共通指標を管理する
  • 1-7 共通指標は本当に必要とされるものを用意する
  • 1-8 特定用途に利用するデータマートはユースケースを想定してつくる
  • まとめ

22 of 42

どのようにデータウェアハウス層をつくるか

1-7 共通指標は本当に必要とされるものを用意する

  • データクレンジング
  • スタースキーマの作成
  • 共通指標の集計

23 of 42

どのようにデータウェアハウス層をつくるか

1-7 共通指標は本当に必要とされるものを用意する

  • データクレンジング
  • スタースキーマの作成
  • 共通指標の集計

今なら「とりあえずBigQueryに突っ込んでおけばいいのでは」で済みそうだけどDWHの選定どうしてます？

24 of 42

手順①：データクレンジングの実施

1-7 共通指標は本当に必要とされるものを用意する

  • データを利用可能な状態へと修正する
  • 理想としてはデータ基盤で行うのではなく、大元のデータソースを修正すべき
  • データレイク層ではなくデータウェアハウス層で行う

25 of 42

手順①：データクレンジングの実施

1-7 共通指標は本当に必要とされるものを用意する

  • データを利用可能な状態へと修正する
  • 理想としてはデータ基盤で行うのではなく、大元のデータソースを修正すべき
  • データレイク層ではなくデータウェアハウス層で行う

クレンジングの方針（品質レベルや方法）の決め方の方針はあるのだろうか

26 of 42

手順②：スタースキーマの作成

1-7 共通指標は本当に必要とされるものを用意する

  • ファクトテーブルとディメンションテーブル
    • ファクトテーブルはイベントごとに1レコード
    • ディメンションテーブルとは分析の切り口となる属性値

27 of 42

手順②：スタースキーマの作成

1-7 共通指標は本当に必要とされるものを用意する

  • ファクトテーブルとディメンションテーブル
    • ファクトテーブルはイベントごとに1レコード
    • ディメンションテーブルとは分析の切り口となる属性値

使う際にはJOINすることになる

  • 誰でも同じ結果になるなら事前にJOINしておけばいいのでは
  • そうでなければ集計する人によって定義が変わってしまう余地がありそのまま使うのは危険。たとえば店舗マスタで起きること
    • 店舗IDは同じだが店舗名が変更された
    • 店舗名は同じだが店舗IDが代わった
    • 複数の店舗が合併して別の店舗IDが振られた

いまだに良い解決方法が思いつかない

28 of 42

手順③：共通指標の集計

1-7 共通指標は本当に必要とされるものを用意する

  • 月次でモニタリングするには「購入履歴」について「年月」「商品」「場所」といった切り口（ディメンション）で「売上」や「購入数」を集計
  • 用途が異なるデータはデータマート層で管理する

​

29 of 42

手順③：共通指標の集計

1-7 共通指標は本当に必要とされるものを用意する

  • 月次でモニタリングするには「購入履歴」について「年月」「商品」「場所」といった切り口（ディメンション）で「売上」や「購入数」を集計
  • 用途が異なるデータはデータマート層で管理する

​

月次モニタリングの例はデータマートなのでは

共通指標を作ることの意義はガバナンスにあり、部門横断の集計ができるかどうかではない気がする（DWHに無くても必要なら作れるので）

30 of 42

初期段階ではデータウェアハウス層をつくらない

1-7 共通指標は本当に必要とされるものを用意する

  • 実態にそぐわない共通データができあがってしまい、現場で使われない
  • 最初にデータマート層をつくるときはデータレイク層を直接参照する
  • 最初から完成形をつくろうとするのではなく、段階的にシステムを進化させる

​

31 of 42

初期段階ではデータウェアハウス層をつくらない

1-7 共通指標は本当に必要とされるものを用意する

  • 実態にそぐわない共通データができあがってしまい、現場で使われない
  • 最初にデータマート層をつくるときはデータレイク層を直接参照する
  • 最初から完成形をつくろうとするのではなく、段階的にシステムを進化させる

​

実態にそぐわない（ので使われない）共通データが出来るのはエンジニアが利用者の話を聞かないで作ってしまったから、というのはしばしば見かける

最低限のDWHはあったほうがいいのでは（JSONをパースしただけのテーブルをデータレイクと解釈するならなくてもいいかもしれないけど）

32 of 42

目次

  • 1-5 データレイク層の一箇所にデータのソースのコピーを集約する
  • 1-6 データウェアハウス層では分析用DBを使って共通指標を管理する
  • 1-7 共通指標は本当に必要とされるものを用意する
  • 1-8 特定用途に利用するデータマートはユースケースを想定してつくる
  • まとめ

33 of 42

データマート層とは何か

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • 「特定の利用者」「特定の用途」向けに加工・整理したデータ、ならびにそのデータの置き場
  • データマート層は用途（ユースケース）と一対一
  • あるデータについて「データウェアハウス層に置くべ

きか」「データマート層に置くべきか」を判断できないときは、時期尚早なのでデータマート層に置く

​

34 of 42

データマート層とは何か

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • 「特定の利用者」「特定の用途」向けに加工・整理したデータ、ならびにそのデータの置き場
  • データマート層は用途（ユースケース）と一対一
  • あるデータについて「データウェアハウス層に置くべ

きか」「データマート層に置くべきか」を判断できないときは、時期尚早なのでデータマート層に置く

​

DHW同様データそのものをデータマートと呼ぶことは他では見たことない

35 of 42

なぜユースケースごとにデータを管理すべきか

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • ユースケースごとにデータを管理するメリット
    • 影響範囲を制限できる
    • 集計ロジックを再利用できる
    • システムの応答時間が速くなる
  • データ利用者の視点に立つと「試行錯誤が容易になること」「過去のロジックを再利用できること」「システムの応答時間が速くなること」

36 of 42

なぜユースケースごとにデータを管理すべきか

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • ユースケースごとにデータを管理するメリット
    • 影響範囲を制限できる
    • 集計ロジックを再利用できる
    • システムの応答時間が速くなる
  • データ利用者の視点に立つと「試行錯誤が容易になること」「過去のロジックを再利用できること」「システムの応答時間が速くなること」

一押しは「システムの応答時間が速くなる」。なのでツールが進化すれば将来的には現在の「データマート」は不要になるのかもしれない（Lookerとか）

37 of 42

どのようにデータマートをつくるか

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • 「週次×◯◯ジャンル×売上」といった形で指標を組み合わせて集計
  • 次のような構成だとわかりやすい
    • データソースとデータレイクが一対一の関係にある
    • データレイクとデータウェアハウスとデータマートの依存関係が1つのワークフローエンジンで管理されている
    • データマートとユースケースが一対一の関係にある

38 of 42

どのようにデータマートをつくるか

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • 「週次×◯◯ジャンル×売上」といった形で指標を組み合わせて集計
  • 次のような構成だとわかりやすい
    • データソースとデータレイクが一対一の関係にある
    • データレイクとデータウェアハウスとデータマートの依存関係が1つのワークフローエンジンで管理されている
    • データマートとユースケースが一対一の関係にある

「複数の集計軸×指標」は後で追加変更が頻繁におきるので拡張性を考えたクエリを書くことも大切

39 of 42

現場で生じるデータマート層の課題とその解決法

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • メンテナンス難。ガバナンスが効きにくい
  • データマートが多すぎるなら利用が減ったデータを検知し、不要になったデータマートを削除
  • ツールが分断されるのを避けるには最初の試行錯誤は BIツールや表計算ソフトで、運用に乗ったらSQL

​

40 of 42

現場で生じるデータマート層の課題とその解決法

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

  • メンテナンス難。ガバナンスが効きにくい
  • データマートが多すぎるなら利用が減ったデータを検知し、不要になったデータマートを削除
  • ツールが分断されるのを避けるには最初の試行錯誤は BIツールや表計算ソフトで、運用に乗ったらSQL

​

定期的に見続けるデータは少ないので「データマートをすぐに作らない、あるいはすぐに消えるようにしておく」のも選択肢

41 of 42

まとめ

42 of 42

読んで思ったこと

まとめ

  • 主にテクノロジーで解決するための方法が書かれている印象を受けた
  • データ整備は対人スキルも必要になるケースが多くそのあたりを埋めるコンテンツにはまだまだ需要がありそう（なので誰か書いて欲しい）

整備の実務について自分もブログ書いています

データ分析とインテリジェンス：https://analytics-and-intelligence.net

質問・疑問などお気軽にご連絡ください　@data_analyst_

​