広告レポーティング基盤に、dbtを導入したら別物になった話 / tokyo-dbt-meetup-4

# Event

https://www.meetup.com/tokyo-dbt-meetup/events/287833176/

Tokyo dbt Meetupについて
データを扱うすべての人が参加できるネットワーキングイベントです。トークは主にコミュニティメンバーのdbtの経験に焦点を当てていますが、アナリティクスエンジニアリング、データスタック、データマネージメント、モデリング、テスト、チーム構造など、より幅広いトピックに関するプレゼンテーションを聞くことができます。

Transcript

1. 広告レポーティング基盤に、
   dbtを導入したら別物になった話
   dbtで作る理想のデータパイプライン
   Tokyo dbt Meetup #4
   

   View Slide

2. 別物になったのは、運用コスト。
   本当に楽になった。ありがとうdbt。
   

   View Slide

3. 理想に近づけるコストが、
   劇的に下がった。
   

   View Slide

4. 今日話さないこと
   dbtの機能説明。
   

   View Slide

5. アジェンダ
   ● 自己紹介
   ● 背景
   ● 変わったこと
   

   View Slide

6. 自己紹介
   ぺい
   @pei0804
   近森淳平(チカモリ　ジュンペイ)
   CARTA HOLDINGS （旧VOYAGE GROUP）
   Zucks アドプロダクト事業本部 エンジニア
   

   View Slide

7. techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
   

   View Slide

8. アジェンダ
   ● 自己紹介
   ● 背景
   ● 変わったこと
   

   View Slide

9. dbtの導入先
   https://speakerdeck.com/pei0804/hokufalsekankaer
   uzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian-
   analytics-modernization
   一年ほど前に発表した
   レポーティング基盤の
   データ変換部分に導入しました。
   

   View Slide

10. どういう基盤？三行まとめ
    ● S3にひたすら吐かれるログをRedshiftへ
    ロードし、変換し、レポーティングする。
    ● 1種類のログで8億/dayレコードになることがある。
    ● モデリングには、ディメンションモデリングを採用。
    

    View Slide

11. なぜ？dbtが必要になったのか？
    

    View Slide

12. クエリとワークフローエンジンを、
    いい感じに調整しながら、
    モデリングも頑張るのが辛すぎた。
    

    View Slide

13. dbt導入前の課題
    ● 仕事が増えてクエリが分割したくても、ワークフローから見直す気力が
    湧いてこないので、いまあるクエリでどうにかしたくなる。
    ● データの依存関係が、実装を見ないと分からない。
    ● カラム追加・・・うぉおお依存するテーブル全部変更やんけ・・・
    細かいことを書くと本当に色々ある。
    

    View Slide

14. 面倒 > いい感じにするモチベ
    

    View Slide

15. こうすると良くなるが、
    見えていても、やるのが非常に面倒。
    

    View Slide

16. dbtを導入したことで、
    アイデアの実行が簡単になった。
    

    View Slide

17. 様々な課題が解消されましたけど、
    その中でも、革新的だったものを紹介します。
    

    View Slide

18. アジェンダ
    ● 自己紹介
    ● 背景
    ● 変わったこと
    

    View Slide

19. パイプライン実装が、低コスト。
    

    View Slide

20. 旧データパイプライン
    AWS Step FunctionsでECS Fargate（java.sql）をいい感じに依存関係を
    組んで、Redshiftにクエリして、ELTする素朴な構成だった。
    当初はこれで十分回っていたけど・・・
    

    View Slide

21. 旧データパイプラインの構成
    それぞれのスキーマの説明
    ● Raw
    ○ S3 -> RedshiftへCOPYしたテーブル郡（正確にはちょっと手間加えてる）
    ● Warehouse
    ○ ディメンションモデリングをしたテーブル郡
    ● Reporting
    ○ レポート向けのテーブル郡
    

    View Slide

22. すごい色んなことするクエリとは
    これは歴史的経緯もあるけど、ツギハギで色んな文脈が１クエリになっていた。
    ● 重複排除
    ● カラムRename
    ● お値段計算
    ● JOIN、GROUP BY
    ● etc…
    分けろって感じですよね。わかりますよ。
    けど、それはワークフローの実装から直すことになって・・・そして・・・
    

    View Slide

23. 面倒 > いい感じにするモチベ
    （再掲）
    

    View Slide

24. dbtだと、データの依存関係をクエリで
    書いていけばいいだけなので、
    あるべき姿を追い求めるコストが低い。
    

    View Slide

25. 面倒
    < いい感じにするモチベ
    

    View Slide

26. dbt導入後のデータパイプライン
    

    View Slide

27. 実際に作ったデータパイプラインと役割
    ● Raw
    ○ 生データ。サーバーから吐き出されたまま。
    ● Staging [New]
    ○ データクリーニング、カラムのrenameやちょっとした変換。
    ● Warehouse
    ○ ディメンションモデリングする。
    ● Reporting
    ○ 用途に合わせたデータを提供する。
    ● それぞれの層/Intermediate [New]
    ○ それぞれの層でややこしい処理などを閉じ込める中間レイヤー
    

    View Slide

28. 元々仕事を分けたい構想はあった。
    

    View Slide

29. 面倒 > いい感じにするモチベ
    （再掲）
    

    View Slide

30. データパイプラインを分けたことによる価値
    それぞれの層（スキーマ）の仕事が明確になった。
    つまり、どの時点で、どういうデータになっていてほしいかが決まる。
    故にどこで、どういうクエリを書けばいいかは自明になり、
    さらにdbt testの機能を組み合わせると、
    データ品質を強固に担保出来るようになった。
    そして、トラブルシューティングも簡単になる。
    例えば、「想定より大きい数値になっている」であれば、
    「データクリーニングしているStagingが怪しい」が分かる。　
    

    View Slide

31. dbtは銀の弾丸ではない。
    dbtで勘違いしてほしくないのは、
    dbtはあくまでクエリランナーであること。
    辛いモデリングをすると、辛いクエリは当然生まれる。
    ゴールイメージがあってこそ、価値を発揮するのがdbt。
    正解が見えてないなら、dbt使ってもいい感じにはならない。
    

    View Slide

32. モデリングは避けて通れない技術
    https://speakerdeck.com/pei0804/modeling-over-shiny-tech
    

    View Slide

33. テーブルマイグレーションをdbtに任せる。
    

    View Slide

34. テーブルマイグレーションをdbtに任せる
    dbtを使い始めて、すぐに気づいた違和感。
    テーブルスキーマの更新どうやってやるの？という疑問。
    アプリケーションデータベースのイメージだと、
    「テーブルマイグレーションやらない？なるほど？正気か？」となる。
    ※正確にはやるんだけど、Flywayなど使わずに、dbtに全部任せる
    しかし、これが革新的なアイデアであることを伝えたい。
    

    View Slide

35. docs.getdbt.com, Why can't I just write DML in my transformations? , 2022/08/20,
    https://docs.getdbt.com/faqs/project/why-not-write-dml
    

    View Slide

36. 従来のマイグレーションツールの課題
    ディメンションモデリングを真面目にやると、
    一箇所の変更だけで、済まなくなる（変更が伝播しない）。
    これにより、ある面倒が発生する。
    例えば、何らかのテーブルにカラムを追加するといった
    よくあるストーリーでさえ、かなりの苦痛を伴う。
    

    View Slide

37. データ変換の流れ
    raw -> fact -> 集計みたいなデータフローがあったとします。
    

    View Slide

38. ケース：カラム追加
    raw_ordersにあるmargin_yensをaggreagte_ordersにも追加したい。
    

    View Slide

39. ケース：カラム追加
    rawの後段のテーブル全てのカラムを追加していく必要がある。
    

    View Slide

40. カラム追加はそれなりに発生する。
    その都度Alterを複数回実行する必要がある。
    

    View Slide

41. 面倒 > いい感じにするモチベ
    （再掲）
    （仕事だからやるんだけど・・・ね？）
    

    View Slide

42. dbtはこの面倒を解消してくれる。
    

    View Slide

43. dbtによるカラム追加は非常にスムーズ
    SELECTに新たなカラムを追加する。これで終わり。
    

    View Slide

44. テーブルマイグレーションをdbtに任せるリスク
    Redshiftと扱っているデータの性質的に、
    考えられる最大のリスクとしては、意図しないカラム削除だった。
    データ量がそれなりにあるので、
    カラムを誤って消す相当のオペレーションをしてしまうと、
    復元するには、膨大なデータを処理する必要があるため、
    消してしまった場合の復旧に現実味がない。
    

    View Slide

45. 安心してください。オプションあります。
    > append_new_columns: Append new columns to the existing
    table. Note that this setting does not remove columns from the
    existing table that are not present in the new data.
    現状は、急に消されないオプションにして、運用してみてます。
    docs.getdbt.com, What if the columns of my incremental model change? , 2022/08/20,
    https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models#what-if-the-columns-
    of-my-incremental-model-change
    

    View Slide

46. 詳しくは紹介しないけど、すごいやつ
    ● dbt-labs/dbt-utils
    ○ 大体ほしいやつがある。
    ● dbt test
    ○ テストも出来て、ドキュメントにもなるし、拡張も簡単！
    ● dbt docs
    ○ メタデータドキュメントがいい感じに出来上がる。
    ● dbt関連の記事が学びに溢れている
    ○ https://docs.getdbt.com/guides/best-practices/how-we-s
    tructure/1-guide-overview
    

    View Slide

47. まとめ
    

    View Slide

48. dbtがない時〜
    

    View Slide

49. 面倒 > いい感じにするモチベ
    

    View Slide

50. dbtがある時〜
    

    View Slide

51. 面倒
    < いい感じにするモチベ
    

    View Slide

52. まとめ
    dbtは銀の弾丸ではない。正解が見えてないなら、意味がない。
    けど、正解が見えていて、同じことをやるなら楽をしたい。
    しかも、それが、ワークフロー、クエリランナー的な部分な場合、
    非常に強力な力を発揮するだろう。
    一方で、そんなんええから、dbt入れとけっていう気持ちもある。
    なぜなら、dbtのドキュメント読んで、実装するだけで、
    それなりに筋が良いデータ基盤になってしまう気がするので・・・ｗ
    

    View Slide

53. 朗報です。
    実はエンジニア採用してます。
    

    View Slide

54. https://engineering.cartaholdings.co.jp/
    

    View Slide