👻

読み合せ会「実践的データ基盤への処方箋」第3回

2022/02/03に公開

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

tech

過去の読み合せ会

なぜ読み合せ会？という形式をとって開催しているか？も記載してます。

読み合せ会「実践的データ基盤への処方箋」第1回　(　はじめに、1-1, 1-2）
読み合せ会「実践的データ基盤への処方箋」第2回　（1-3, 1-4, 1-5)
読み合せ会「実践的データ基盤への処方箋」第3回　(1-6, 1-7, 1-8)
読み合せ会「実践的データ基盤への処方箋」第4回　(1-9, 1-10)
読み合せ会「実践的データ基盤への処方箋」第5回　(1-11, 1-12)
読み合せ会「実践的データ基盤への処方箋」第6回　(2-1, 2-2)
読み合せ会「実践的データ基盤への処方箋」第7回　(2-3, 2-4, 2-5)

使用する本

を使っています

読み合せ会

輪読会ではなく、読み合せ会！

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

メンバーの意見をまとめてます

データウェアハウス層は、「共通指標を乗せる場所」、複数のデータを統合・蓄積して、意思決定に使うデータ
部署ごとに定義が違うものができる（例として、「売上」　・・税込み、税抜など）を共通指標として
- 実際、弊社のとある部門でそんな事が起きて大変な目にあっていた
BIツールは共通指標作りには向かない（ツール内での定義が他に利用できない）
- BIツールは、属人化しやすい
DWH層：用途が1：1に対応していないところが、マートとの違いを感じた

（所感）
BIツールの弱点というところがとても共感しましたね。TableauとかだとカスタムSQLとかでもできたりするし、Tableau内の計算式で色々やれちゃうしね。
Tableau Prepで加工したものをDWHにいれるなら・・・まぁ、ありかな？

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

参加者の意見をまとめてます

初期段階ではそれぞれのステップを手動で作ってるけど、ワークフローエンジンで自動化したい
データクレンジングは終わりなき戦い。チェックリストがあるといい！
早すぎるデータウェアハウス層はつくらないほうがいい！？！？
スタースキーマだと作業者がテーブル結合やデータ構造が把握しやすい
欠損に関しては、質問表や大元のデータ作成者に問い合わせる
- データソースの修正はOK、データレイクでのデータ修正はNG

（所感）
早すぎるウェアハウスは作らないほうがいい・・・・という話題があったんだけど、それは違うんでね？なんて思ったんですが
うちの場合は、POSなどにマスターをくっつけるとか、アプリとの突合がおおいので、ある程度形が決まってきていて、最終形が無意識の中で自分の中にあって、ウェアハウス層を作ってるのかな？と思いました
ある程度形が決まってるものは、最初からウェアハウス層を作ってもいいのでは？と思います。
ただ、一度作って終わりではないので、継続的にメンテナンスしていかねばなと思います

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

参加者の意見をまとめています

データマート層は、ユースケースと１：１
データの置く場所に困ったら、まずは「マート層」
ユースケース＝マートの肥大化問題、クリーニング・棚卸しは随時必要、データスチュワードが役割を担うのが良さそう
ユースケースごとにデータ管理　は　メリットが多い
- 利用者制限
- 集計早くできる
- ロジックを使い回せる　→　すごくいい！　けど、誤ったものが広がるリスクもなくはない
マートを作る際は、BIなどで試行錯誤→SQLに置き換えてワークフローで自動化などが良さそう

（所感）
BIなどで小さく作って、固まったらワークフローなどで自動化・・・てのは、やはりいいなーと思いました。

シリーズ