Upgrade to Pro — share decks privately, control downloads, hide ads and more …

dbtとLookerにたどり着いたデータ基盤 ~混ざり合う境界線を考える~

dbtとLookerにたどり着いたデータ基盤 ~混ざり合う境界線を考える~

「Looker User Meetup Online #8」にて登壇した内容となっております

tenajima

July 21, 2022
Tweet

More Decks by tenajima

Other Decks in Technology

Transcript

  1. © Unipos Inc. All Rights Reserved. dbtとLookerにたどり着いたデータ基盤 ~混ざり合う境界線を考える~ Looker User

    Meetup Online #8 2022/07/21 1 水谷 優斗
  2. © Unipos Inc. All Rights Reserved. 自己紹介 speaker 2 •

    水谷優斗 • インターネット 世界で @tenajima • Unipos 株式会社 ◦ 2018年新卒入社 • アナリティクスエンジニア ◦ (2018-2019)データサイエンティスト ◦ (2019-2020)データアナリスト • アイコン 妻が描いてくれました
  3. © Unipos Inc. All Rights Reserved. Uniposについて speaker 4 •

    Unipos と ピアボーナスを実現する Web サービ ス • 感謝や称賛、激励 メッセージに加えてポイントを添 えます、ポイント 金銭などに交換できます • 共感した投稿に対してワンクリックで称賛をすること ができます、拍手 ポイントとして投稿を送った人・ もらった人に送られます • 感情報酬を社会基盤に
  4. © Unipos Inc. All Rights Reserved. Unipos データ基盤 現在地 5

  5. © Unipos Inc. All Rights Reserved. Unipos社における前提 Unipos データ基盤 現在地

    6 • 投稿 内容、及 メールアドレス、ユーザー名など取り扱いに注意が必要なデータがある 
 ◦ そ ようなデータ 解約されて6ヶ月以上経過するとと削除される 
 ◦ DWH で そ ようなデータを持たない方針をとっている 
 • 取り扱っているデータ量 B オーダー 
 • Looker 導入 2021年11月 

  6. © Unipos Inc. All Rights Reserved. 現在 設計 Unipos データ基盤

    現在地 7 • Github Actions と Cloud Build 使って dbt をキックする 
 • DWH に Big Query を用いる 
 ◦ nipos が GCP ネイティブな で昔から Big Query を使う文化だった 
 • データ アクセスに Looker を用いる 
 ◦ 分析チームに分析依頼やデータ抽出依頼が殺到する を解消するため 
 ◦ データガバナンスを効かせるため 
 ◦ 導入 経緯 Google Cloud Japan Born Digital ummit で 話したも がある でよかった らご覧ください

  7. © Unipos Inc. All Rights Reserved. 釈迦に説法コーナー Unipos データ基盤 現在地

    8 • dbt と 
 ◦ QL コンパイルと QL 実行を行ってくれるツール 
 ◦ メリット
 ▪ コード 再利用性を上げてくれる 
 ▪ テストが書きやすい、実行しやすい 
 ▪ docs をコードとともに管理できる 
 ◦ デメリット
 ▪ ど ように実行するか考える必要がある 
 ▪ aa 版を使うとデメリット ほぼ全てが解消されるがお金がかかる 

  8. © Unipos Inc. All Rights Reserved. 混ざり合う境界線を考える 9

  9. © Unipos Inc. All Rights Reserved. 今至っている結論 混ざり合う境界線を考える 10 •

    ここまで DWH!ここから Looker!ってきれいに分けること 難しいんじゃないかなと思っていま す
 ◦ あまりそこまでしなくてもいい で ?とも思っています 
 • ユーザーにど ようにデータにアクセスさせられるかをコントロールできる がLooker 良いところ だと思っています
 ◦ 直接 DWH をクエリする と比較して 
 • ビジネス 事情、DWH 事情をいい感じに吸収してくれる良さが Looker 魅力だなと感じていま す

  10. © Unipos Inc. All Rights Reserved. フェーズ1 : スケジュールクエリで作られる DWH

    と Looker 混ざり合う境界線を考える 11 • 日毎 スケジュールクエリでDWHを作る 
 • スケジュールクエリ 作成を terraform で管理する でコミット難易度 高めと感じていた 
 ◦ データエンジニアが1人で頑張って作ってくれていた状態 
 ◦ 「使いやすい view をみんなで作ろうぜ」って話してたが、作られること なかった 
 • DWH スナップショットをちゃんととっていく役割を担っていた 
 • Looker データマートとして 役割と、分析都合 いろんなことを担当する役割を担っていた 

  11. © Unipos Inc. All Rights Reserved. フェーズ1を振り返って 混ざり合う境界線を考える 12 •

    DWH 側で 自動テストを実行できる状態になっていなかった 
 • マート層相当 Looker に任せるという 悪くない思想だなと 思っている 
 ◦ クエリ キャッシュとか PD 戦略とか Looker 側でなんとかするんで!という思想 
 ◦ DWH 修正コストと LookML 修正コストを比べて軽い方を選べ 良いと感じている 
 

  12. © Unipos Inc. All Rights Reserved. フェーズ1を振り返って 混ざり合う境界線を考える 13 •

    DWH で取り込み時間分割テーブルを使った 本当に間違いだった 
 ◦ Looker 側でずっと _partitiondate と付き合い続ける めになってしまった 
 ◦ タイムスタンプ カラム(ex. created_at )と _partitiondate をずっと二重管理し続けるとどんどん 気持ちが暗くなっていく 
 ◦ なん モデルを作るときも「どこ 日付に合わせるか」を指定し続ける職人芸が必要とされた 
 ◦ タイムスタンプ カラムを使ってパーティショニングしましょう 

  13. © Unipos Inc. All Rights Reserved. フェーズ2 : dbtで作られる DWH

    と Looker (今) 混ざり合う境界線を考える 14 • まるっと dbt で管理 
 ◦ snapshot も dbt snapshot を使うことで変更分 み取り込めるようになってデータ量を99.9%削 減
 ◦ 自動テストも書けるようになり、データ 品質も向上 
 • DWH と Looker 関係性 変わらず 
 ◦ 今 フェーズ1 DWH と平行して運用しながら徐々に dbt に絞って フェーズ1 引退させる 予定

  14. © Unipos Inc. All Rights Reserved. フェーズ3 : dbtで作られる DWH

    と Looker (未来) 混ざり合う境界線を考える 15 • マート層 できるだけ DWH に寄せたい 
 ◦ よく見る指標など DWH に寄せて管理したい 
 ▪ LookMLで 結構頑張って実現しているも があるから 
 ◦ LookML で 分析に必要な細々したこととデータガバナンスに集中できるようにしたい 
 • Looker 側でもロジック テストをしっかりしていく 

  15. © Unipos Inc. All Rights Reserved. フェーズによらず変わらないも 混ざり合う境界線を考える 16 •

    toB サービスをしているとどうしても C 経由で PII を取り扱う必要が出てくる 
 • データ基盤に PII を取り込まないようにしている 
 ◦ 解約後6ヶ月で削除するようにするなどを考えたくないから 
 • Looker を用いて、実績データ データ基盤、PII プロダクト バックアップそ も を見るようにす る( joinして、よしなに取り扱う) 
 ◦ プロダクト バックアップ 削除バッチが走る で、そこ データチームが担保しなくて良い 
 • Looker に データガバナンス 役割を担ってもらうようにする 

  16. © Unipos Inc. All Rights Reserved. 図で表す 混ざり合う境界線を考える 17

  17. © Unipos Inc. All Rights Reserved. 図で表す 混ざり合う境界線を考える 18

  18. © Unipos Inc. All Rights Reserved. 図で表す 混ざり合う境界線を考える 19

  19. © Unipos Inc. All Rights Reserved. 図で表す 混ざり合う境界線を考える 20

  20. © Unipos Inc. All Rights Reserved. レバーが2つ存在する良さ 21

  21. © Unipos Inc. All Rights Reserved. 一旦 LookML が引き受けてくれる(懐がある) レバーが2つある良さ

    22 • ショットで見たいも 、今後も引き続き使うかわからない指標を DWH 側で実装する が重い場合 LookML でクエリ書いてバックアップを見ちゃう 
 ◦ 結構使う指標だ ってなったら DWH 側に実装するようにして、 LookML 側 実装も修正する 
 ▪ どんくらいこ モデルが使われているか、誰が使っている かをLookerで追いやすい 
 ◦ dbt 導入で DWH 実装も軽くなった でここ もつ意味 徐々に減る 

  22. © Unipos Inc. All Rights Reserved. 一旦 LookML が引き受けてくれる(懐がある) レバーが2つある良さ

    23 • DWH リファクタリング 際に、LookML が DWH 役割を一旦担ってくれる 
 ◦ 大スナップショット時代から、dbt を用いたディメンジョナルモデリングへ お引越しをしていた 際とても助かりました 
 ◦ 「これ 一旦 LookML だけで対応するようにします」ができる 、開発リソースがそれほどな いチームに かなり助かった 

  23. © Unipos Inc. All Rights Reserved. 最後に 24

  24. © Unipos Inc. All Rights Reserved. 地雷をいっ い踏み抜いたけど 最後に 25

    • 今で 、PO が新機能 評価分析を自分でするようになったり、C データ抽出依頼をほぼ無くす ことができたり、データが価値を持って使われ始めた 
 • Looker アナリスト ことを、とても考えられて作られてるなって本当に感じる 
 • Looker 良い!といっても、DWH という足腰が頑丈じゃないとどこかで辛くなる で、DWH も軽視した らアカンすよ!
 • dbt もとてもアナリスト 事を考えて作られてると感じる で、ぜ 触ってみてください 

  25. © Unipos Inc. All Rights Reserved. +39pt Thank you! 26