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

by tenajima

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© Unipos Inc. All Rights Reserved. Unipos社における前提 Unipos データ基盤現在地 6 ● 投稿内容、及メールアドレス、ユーザー名など取り扱いに注意が必要なデータがある   ○ そようなデータ解約されて6ヶ月以上経過するとと削除される   ○ DWH でそようなデータを持たない方針をとっている   ● 取り扱っているデータ量 B オーダー   ● Looker 導入 2021年11月  

Slide 6

Slide 6 text

© 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 で話したもがあるでよかったらご覧ください 

Slide 7

Slide 7 text

© Unipos Inc. All Rights Reserved. 釈迦に説法コーナー Unipos データ基盤現在地 8 ● dbt と   ○ QL コンパイルと QL 実行を行ってくれるツール   ○ メリット  ■ コード再利用性を上げてくれる   ■ テストが書きやすい、実行しやすい   ■ docs をコードとともに管理できる   ○ デメリット  ■ どように実行するか考える必要がある   ■ aa 版を使うとデメリットほぼ全てが解消されるがお金がかかる  

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© Unipos Inc. All Rights Reserved. 今至っている結論混ざり合う境界線を考える 10 ● ここまで DWH！ここから Looker！ってきれいに分けること難しいんじゃないかなと思っています  ○ あまりそこまでしなくてもいいで？とも思っています   ● ユーザーにどようにデータにアクセスさせられるかをコントロールできるがLooker 良いところだと思っています  ○ 直接 DWH をクエリすると比較して   ● ビジネス事情、DWH 事情をいい感じに吸収してくれる良さが Looker 魅力だなと感じています 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

© Unipos Inc. All Rights Reserved. フェーズ1を振り返って混ざり合う境界線を考える 12 ● DWH 側で自動テストを実行できる状態になっていなかった   ● マート層相当 Looker に任せるという悪くない思想だなと思っている   ○ クエリキャッシュとか PD 戦略とか Looker 側でなんとかするんで！という思想   ○ DWH 修正コストと LookML 修正コストを比べて軽い方を選べ良いと感じている    

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© Unipos Inc. All Rights Reserved. フェーズ3 : dbtで作られる DWH と Looker (未来) 混ざり合う境界線を考える 15 ● マート層できるだけ DWH に寄せたい   ○ よく見る指標など DWH に寄せて管理したい   ■ LookMLで結構頑張って実現しているもがあるから   ○ LookML で分析に必要な細々したこととデータガバナンスに集中できるようにしたい   ● Looker 側でもロジックテストをしっかりしていく  

Slide 15

Slide 15 text

© Unipos Inc. All Rights Reserved. フェーズによらず変わらないも混ざり合う境界線を考える 16 ● toB サービスをしているとどうしても C 経由で PII を取り扱う必要が出てくる   ● データ基盤に PII を取り込まないようにしている   ○ 解約後6ヶ月で削除するようにするなどを考えたくないから   ● Looker を用いて、実績データデータ基盤、PII プロダクトバックアップそもを見るようにする( joinして、よしなに取り扱う)   ○ プロダクトバックアップ削除バッチが走るで、そこデータチームが担保しなくて良い   ● Looker にデータガバナンス役割を担ってもらうようにする  

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© Unipos Inc. All Rights Reserved. 一旦 LookML が引き受けてくれる(懐がある) レバーが２つある良さ 22 ● ショットで見たいも、今後も引き続き使うかわからない指標を DWH 側で実装するが重い場合 LookML でクエリ書いてバックアップを見ちゃう   ○ 結構使う指標だってなったら DWH 側に実装するようにして、 LookML 側実装も修正する   ■ どんくらいこモデルが使われているか、誰が使っているかをLookerで追いやすい   ○ dbt 導入で DWH 実装も軽くなったでここもつ意味徐々に減る  

Slide 22

Slide 22 text

© Unipos Inc. All Rights Reserved. 一旦 LookML が引き受けてくれる(懐がある) レバーが２つある良さ 23 ● DWH リファクタリング際に、LookML が DWH 役割を一旦担ってくれる   ○ 大スナップショット時代から、dbt を用いたディメンジョナルモデリングへお引越しをしていた際とても助かりました   ○ 「これ一旦 LookML だけで対応するようにします」ができる、開発リソースがそれほどないチームにかなり助かった  

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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