広告レポーティング基盤に、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
2. 別物になったのは、運用コスト。 本当に楽になった。ありがとうdbt。
3. 理想に近づけるコストが、 劇的に下がった。
4. 今日話さないこと dbtの機能説明。
5. アジェンダ • 自己紹介 • 背景 • 変わったこと
6. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) CARTA HOLDINGS （旧VOYAGE GROUP） Zucks アドプロダクト事業本部 エンジニア
7. techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
8. アジェンダ • 自己紹介 • 背景 • 変わったこと
9. dbtの導入先 https://speakerdeck.com/pei0804/hokufalsekankaer uzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian- analytics-modernization 一年ほど前に発表した レポーティング基盤の データ変換部分に導入しました。
10. どういう基盤？三行まとめ • S3にひたすら吐かれるログをRedshiftへ ロードし、変換し、レポーティングする。 • 1種類のログで8億/dayレコードになることがある。 • モデリングには、ディメンションモデリングを採用。
11. なぜ？dbtが必要になったのか？
12. クエリとワークフローエンジンを、 いい感じに調整しながら、 モデリングも頑張るのが辛すぎた。
13. dbt導入前の課題 • 仕事が増えてクエリが分割したくても、ワークフローから見直す気力が 湧いてこないので、いまあるクエリでどうにかしたくなる。 • データの依存関係が、実装を見ないと分からない。 • カラム追加・・・うぉおお依存するテーブル全部変更やんけ・・・ 細かいことを書くと本当に色々ある。
14. 面倒 > いい感じにするモチベ
15. こうすると良くなるが、 見えていても、やるのが非常に面倒。
16. dbtを導入したことで、 アイデアの実行が簡単になった。
17. 様々な課題が解消されましたけど、 その中でも、革新的だったものを紹介します。
18. アジェンダ • 自己紹介 • 背景 • 変わったこと
19. パイプライン実装が、低コスト。
20. 旧データパイプライン AWS Step FunctionsでECS Fargate（java.sql）をいい感じに依存関係を 組んで、Redshiftにクエリして、ELTする素朴な構成だった。 当初はこれで十分回っていたけど・・・
21. 旧データパイプラインの構成 それぞれのスキーマの説明 • Raw ◦ S3 -> RedshiftへCOPYしたテーブル郡（正確にはちょっと手間加えてる） • Warehouse ◦ ディメンションモデリングをしたテーブル郡 • Reporting ◦ レポート向けのテーブル郡
22. すごい色んなことするクエリとは これは歴史的経緯もあるけど、ツギハギで色んな文脈が１クエリになっていた。 • 重複排除 • カラムRename • お値段計算 • JOIN、GROUP BY • etc… 分けろって感じですよね。わかりますよ。 けど、それはワークフローの実装から直すことになって・・・そして・・・
23. 面倒 > いい感じにするモチベ （再掲）
24. dbtだと、データの依存関係をクエリで 書いていけばいいだけなので、 あるべき姿を追い求めるコストが低い。
25. 面倒 < いい感じにするモチベ
26. dbt導入後のデータパイプライン
27. 実際に作ったデータパイプラインと役割 • Raw ◦ 生データ。サーバーから吐き出されたまま。 • Staging [New] ◦ データクリーニング、カラムのrenameやちょっとした変換。 • Warehouse ◦ ディメンションモデリングする。 • Reporting ◦ 用途に合わせたデータを提供する。 • それぞれの層/Intermediate [New] ◦ それぞれの層でややこしい処理などを閉じ込める中間レイヤー
28. 元々仕事を分けたい構想はあった。
29. 面倒 > いい感じにするモチベ （再掲）
30. データパイプラインを分けたことによる価値 それぞれの層（スキーマ）の仕事が明確になった。 つまり、どの時点で、どういうデータになっていてほしいかが決まる。 故にどこで、どういうクエリを書けばいいかは自明になり、 さらにdbt testの機能を組み合わせると、 データ品質を強固に担保出来るようになった。 そして、トラブルシューティングも簡単になる。 例えば、「想定より大きい数値になっている」であれば、 「データクリーニングしているStagingが怪しい」が分かる。　
31. dbtは銀の弾丸ではない。 dbtで勘違いしてほしくないのは、 dbtはあくまでクエリランナーであること。 辛いモデリングをすると、辛いクエリは当然生まれる。 ゴールイメージがあってこそ、価値を発揮するのがdbt。 正解が見えてないなら、dbt使ってもいい感じにはならない。
32. モデリングは避けて通れない技術 https://speakerdeck.com/pei0804/modeling-over-shiny-tech
33. テーブルマイグレーションをdbtに任せる。
34. テーブルマイグレーションをdbtに任せる dbtを使い始めて、すぐに気づいた違和感。 テーブルスキーマの更新どうやってやるの？という疑問。 アプリケーションデータベースのイメージだと、 「テーブルマイグレーションやらない？なるほど？正気か？」となる。 ※正確にはやるんだけど、Flywayなど使わずに、dbtに全部任せる しかし、これが革新的なアイデアであることを伝えたい。
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
36. 従来のマイグレーションツールの課題 ディメンションモデリングを真面目にやると、 一箇所の変更だけで、済まなくなる（変更が伝播しない）。 これにより、ある面倒が発生する。 例えば、何らかのテーブルにカラムを追加するといった よくあるストーリーでさえ、かなりの苦痛を伴う。
37. データ変換の流れ raw -> fact -> 集計みたいなデータフローがあったとします。
38. ケース：カラム追加 raw_ordersにあるmargin_yensをaggreagte_ordersにも追加したい。
39. ケース：カラム追加 rawの後段のテーブル全てのカラムを追加していく必要がある。
40. カラム追加はそれなりに発生する。 その都度Alterを複数回実行する必要がある。
41. 面倒 > いい感じにするモチベ （再掲） （仕事だからやるんだけど・・・ね？）
42. dbtはこの面倒を解消してくれる。
43. dbtによるカラム追加は非常にスムーズ SELECTに新たなカラムを追加する。これで終わり。
44. テーブルマイグレーションをdbtに任せるリスク Redshiftと扱っているデータの性質的に、 考えられる最大のリスクとしては、意図しないカラム削除だった。 データ量がそれなりにあるので、 カラムを誤って消す相当のオペレーションをしてしまうと、 復元するには、膨大なデータを処理する必要があるため、 消してしまった場合の復旧に現実味がない。
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
46. 詳しくは紹介しないけど、すごいやつ • dbt-labs/dbt-utils ◦ 大体ほしいやつがある。 • dbt test ◦ テストも出来て、ドキュメントにもなるし、拡張も簡単！ • dbt docs ◦ メタデータドキュメントがいい感じに出来上がる。 • dbt関連の記事が学びに溢れている ◦ https://docs.getdbt.com/guides/best-practices/how-we-s tructure/1-guide-overview
47. まとめ
48. dbtがない時〜
49. 面倒 > いい感じにするモチベ
50. dbtがある時〜
51. 面倒 < いい感じにするモチベ
52. まとめ dbtは銀の弾丸ではない。正解が見えてないなら、意味がない。 けど、正解が見えていて、同じことをやるなら楽をしたい。 しかも、それが、ワークフロー、クエリランナー的な部分な場合、 非常に強力な力を発揮するだろう。 一方で、そんなんええから、dbt入れとけっていう気持ちもある。 なぜなら、dbtのドキュメント読んで、実装するだけで、 それなりに筋が良いデータ基盤になってしまう気がするので・・・ｗ
53. 朗報です。 実はエンジニア採用してます。
54. https://engineering.cartaholdings.co.jp/