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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

安心してください。オプションあります。 > 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/conﬁguring-incremental-models#what-if-the-columns- of-my-incremental-model-change

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

dbtがない時〜

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

dbtがある時〜

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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