書籍:実践的データ基盤への処方箋
第1章「データ活用のためのデータ整備」のメモです。
▪️全体の流れ
1、ユースケース、そのためのデータ活用方法を検討
2、そこから逆算する形でデータ収集、整備の投資判断を行う
データ基盤の担当者はビジネスとデータを繋げることを意識しよう
思考の多くをユースケースに充てよう
▪️データの流れ
データソース
↓
データ収集
↓
データレイク
↓
データウェアハウス
↓
データマート
↓
ユースケース
・入り口(データソース)と出口(ユースケース)を洗い出す
・思考の順番(ユースケースから考える)とは異なるので、あくまでデータ自体の流れとして捉える
▪️入り口と出口をマッピングする方法
誰がどのデータに対して、どのような処理を行うのかをCRUD表を作成して管理
・Create
・Read
・Update
・Delete
▪️用語集をまとめる
人によって言葉の捉え方が異なるので定義を取り決める
(例:売上とは税込か否かなど)
▪️データソースの品質にはこだわる
・データが取れない、誤っていると分析に繋げられないため
→下流から上流へフィードバックすると良い
▪️データの生成過程を知る
・例:売上はデータベースと銀行振込履歴どちらを採用すべきか
→両方見る
理由;データベースは障害の可能性があり、銀行振込は購入日から時差がある可能性あり、それぞれ一長一短なため
▪️データベースの詳細を把握するために
ER図を描こう
▪️データソースの生成過程を業務レイヤで整理しよう
データ生成の現場 | 例 |
---|---|
ロール | 顧客 |
オペレーション | スマホから購入ボタンクリック |
アプリケーション | ECサイト |
ストレージ | データベース |
これをもとに現状と理想のギャップを把握
→原因と改善案を考える
データ生成者とデータ活用者では利害が一致していない
・データ生成者:商談に集中したいので紙のメモが良い
・データ活用者:データ分析しやすい形で保存してほしい
解決案:
・議論をする場を作る
・解決したいと思える状態作り(例:インセンティブ設計)
・簡単に解決できる環境作り(例:ツールの導入)
▪️マスターデータの整備
同じものを指すのに部署によって使っている言葉が異なる場合がある
→社内に周知の上、部署横断のマスターデータを整備しよう
▪️商品IDを生成しよう
似た商品名を一緒にしてしまう or 同じ商品なのに分けてしまうといったことを防ぐ
→全社共通の商品IDを作成する
▪️履歴データを生成しよう
データを上書きした場合、後で確認する必要が出てきた際や、分析の観点で新旧を比較したい際に困る。
→履歴テーブルを持つなど履歴を管理しよう。
▪️データレイク
・データレイクはデータをそのままコピーするだけ。無闇に加工したり集計したりしてから入れない。
・データレイクは1つだけ。複数あると混乱の元となる
▪️データウェアハウス
・分析用DB
・部門横断の共通指標はデータウェアハウスで管理する
・指標は全社で定義を統一させる。
▪️データウェアハウス層の作り方
1、データクレンジング:できるだけデータウェアハウスの段階で行う
2、スタースキーマの作成:ファクトテーブル+ディメンションテーブル
3、共通指標の作成
データウェアハウスを作るタイミング
→一番最後
まずは両端を充実させる
・データソース→データレイク
・ユースケース→データマート
ある程度使い道が見えてきたらデータウェアハウスに落とし込む
▪️データマート
・ユーズケースごとに作る
・データマートが充実してきて、業務知識が体系化されてきたらデータウェアハウスを作る
・データウェアハウスとデータマートの依存関係を1つのワークフローエンジンで管理する
・データマートが散乱し出したら
解決策:
・クリーニングの仕組みを全社で作る
・2つのステップでデータマートを作るようにする
1、とりあえずBIツール、Excelなどで集計する
2、データ活用が運用に乗ったらデータマートを作る
▪️ユースケース
・データの利用状況の解像度を上げよう
→5W1Hで考える
・データを活用してもらうために
→部署のよって使い慣れているツールが異なる(BIツール、Excel、SQLなど)
→自分の都合でツールを押し付けるのはよそう
▪️メタデータ
このデータはどのようなデータかという情報を持つデータ
・メタデータを管理して、データの調査コストを減らそう
・メタデータの管理は、分析用DBやメタデータ管理ツールでできる
・メタデータの管理に最も適しているのはデータ生成者
・更新が追いつかないなどの困難さを伴うので、キュおりょくしてもらえるような関係作りが必要
▪️サービスレベル
サービスの品質水準
以下のサイクルを回して改善していく
・目標設定
・関係者との合意
・現状の計測
・課題の特定
・必要な施策の実施
・結果の振り返り
品質のコントロールをしよう
・過剰な品質要求はデータ整備の負担が増すばかりである
→全てのデータを対象にするのではなく、実際に計測が必要なデータの種類はどれかを検討しよう
▪️データスチュアード
データマネージャと呼ばれることもある。
役割:
・データの問い合わせ対応
・データ整備の推進
データ整備推進の流れ:
問い合わせの対応
↓
要望(ユースケース)の把握
↓
サービスレベルの定義
↓
メタデータで計測
↓
目標と現状を把握し、解決策を検討
↓
データ生成者と協力しデータソースを整備
必要に応じて、データレイク、データウェアハウス、データマートを整備