Zenn
👻

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

2022/02/03に公開
実践的データ基盤への処方箋
tech

過去の読み合せ会

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

使用する本

https://gihyo.jp/book/2021/978-4-297-12445-8
を使っています

読み合せ会

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

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などで小さく作って、固まったらワークフローなどで自動化・・・てのは、やはりいいなーと思いました。

シリーズ

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

Discussion