Snowflake x dbt x Terraform マルチデータプロダクト基盤 [DataOps Night #4]

2024/7/10 に実施された DataOps Night #4 の登壇資料です。
Snowflake と dbt そして Terraform でマルチデータプロダクトを取り扱うための基盤を作った際の工夫や課題についてまとめました。

https://finatext.connpass.com/event/320643/

Transcript

1. © 2015 - 2024 Nowcast Inc. Snowflake x dbt x Terraform マルチデータプロダクト基盤 2024/7/10 株式会社ナウキャスト 大野巧作　@Kevinrobot34 DataOps Night #4 1
2. © 2015 - 2024 Nowcast Inc. アジェンダ アジェンダ 1. 自己紹介・会社紹介 2. 既存の課題 3. 現在のデータ基盤の構成 4. 今後の課題 2
3. © 2015 - 2024 Nowcast Inc. 3 1. 自己紹介・会社紹介
4. © 2015 - 2024 Nowcast Inc. 4 1. 自己紹介・会社紹介 • 名前：大野巧作 ◦ 大体けびんと呼ばれています ◦ X(旧Twitter) は @Kevinrobot34 • 役職：Data Engineer / Data Platform Engineer @ Nowcast ◦ POSデータのパイプライン作成・運用 ◦ Snowflake x dbt x terraform な社内データ基盤構築・運用 ◦ 2020年卒の社会人５年目です • 最近興味のある技術 ◦ Apache Iceberg 自己紹介 会社のメンバーでSnowflake Summit に行った時の写真→
5. © 2015 - 2024 Nowcast Inc. 5 1. 自己紹介・会社紹介 オルタナティブデータとは、利活用の進んでいないビッグデータの総称 オルタナティブデータとは、元々は金融領域の用語で、伝 統的に使われてきた財務情報や経済統計のようなデータ （Traditional Data）に対して、これまで利活用の進んで こなかったビッグデータのことを指します。 データ利活用が活発なアメリカでは、様々な種類のオルタ ナティブデータがサービスとして実際に提供されていま す。 参考) オルタナティブデータとは
6. © 2015 - 2024 Nowcast Inc. 6 1. 自己紹介・会社紹介 データの保有側・利用側の双方に価値を提供するオルタナティブデータの Two-Sided Platformを展開します
7. © 2015 - 2024 Nowcast Inc. 7 1. 自己紹介・会社紹介 データ利用者に応じた様々なプロダクトを展開 日銀黒田元総裁講演資料で引用 日本銀行の金融緩和の決定など、 政策意思決定にも活用されています。 レジャー消費、EC消費がわかる数少ない指 標として、260件以上のメディア、調査レポー トで引用されています WBS等多くのメディア露出
8. © 2015 - 2024 Nowcast Inc. 8 1. 自己紹介・会社紹介 自社データプロダクト提供と顧客支援と２つのビジネスを推進してます Data Service Business ビッグデータを用いたプロダクトを提供する事業。 Data & AI Solution Business データとAIで顧客のDXを支援する事業。 Data Service Platform Unit 事業横断でデータ基盤の高度化、R&Dなどを行うチーム。 Investment Research Unit 機関投資家向けに ビッグデータ分析 SaaSを提供 Real Estate Unit 商圏分析や売上予測 モデルによる店舗物 件の診断サービスを 不動産会社に提供 Data Holder Unit 提供元からデータを受領し、データパイプラインの構築を行うチーム。 Engineering Team データエンジニアリングと生成AI活用に 精通したエンジニアリングチーム。 Consultant Team データとAIを用いたDXに特化した コンサルティングチーム。 Economic Research Unit ビッグデータから計 算したマクロ指数を 金融機関・官公庁等 に提供
9. © 2015 - 2024 Nowcast Inc. 9 2. 現状の課題
10. © 2015 - 2024 Nowcast Inc. 10 2. 現状の課題 昨年夏頃にデータ基盤を作り、秋冬にかけて社内で普及をしてきた。 昨年 Snowflake x dbt x Terraform でデータ基盤を作った
11. © 2015 - 2024 Nowcast Inc. 11 2. 現状の課題 増えるデータソース・データプロダクト • 増えるデータソース ◦ 求人ビッグデータ ◦ 新しいPOSデータなどのオルタナティブデータ ◦ Snowflake marketplace から入手したデータ（truestar 社の PODB など） ◦ … • 増えるデータプロダクト ◦ 賃金指数であるHRog賃金Now ◦ 不動産会社向けの商圏分析・売上予測アプリ ◦ … Snowflake x dbt x Terraform のデータ基盤を利用することで • 新しいデータソースのパイプライン立ち上げが PythonベースのETLに比べ迅速になった • サイロ化を解消し、複数のデータを組み合わせた データプロダクトの開発が以前より容易になった といったメリットが生まれた。
12. © 2015 - 2024 Nowcast Inc. 12 2. 現状の課題 浮かび上がった課題と解決策 増えるデータソース・データプロダクトをデータ基盤上でパイプライン開発・分析をしていたが、 その中でいくつか課題が浮かびつつあった • UDF / Procedure などのリソースの管理方法が確立されていなかった ◦ → Snowflake CLI で解決 • dbt のレポジトリ構成がよくなく、複数のデータソース・プロダクトを取り扱いにくかった ◦ → ディレクトリ構成・ブランチ構成を変更し、プロジェクトごとに疎結合で 　 使いやすい新しいレポジトリ（boilerplate 付きのモノレポ）を作り解決 • CIが弱かった ◦ → デフォルトで用意したCIを増やし、プロジェクト・環境ごとにカスタマイズもしやすくした • メタデータ管理が dbt docs のみだった ◦ → OpenMetadata を導入・検証して解決を目指しているところ 今後、よりパイプライン構築・データプロダクト開発を加速させるために、ここの解消が不可欠だった。 この辺りを2024年以降に修正していった。
13. © 2015 - 2024 Nowcast Inc. 13 3. 現在のデータ基盤の構成
14. © 2015 - 2024 Nowcast Inc. 14 3. 現在のデータ基盤の構成 • DWHはSnowflake • Snowflake のリソース管理 ◦ table / view → dbt ◦ udf / proc / SiS→ Snowflake CLI ◦ それ以外 → Terraform • Airflow から ECS task を呼び dbt build を定期実行 Snowflake x dbt x Terraform の基盤の全体像 • dbt モデルはモノレポで管理 ◦ boilerplate の用意 ◦ GitHub Flow なブランチ管理 ◦ projects/環境ごとにdirを分け、それぞれCI/CD • [WIP] OpenMetadata でメタデータ管理 ◦ Snowflake からメタデータ取得 ◦ dbt artifact を連携する仕組み
15. © 2015 - 2024 Nowcast Inc. 15 3. 現在のデータ基盤の構成 Snowflake のリソース管理 リソースごとに管理・デプロイ方法を選んでいる • table / view → dbt ◦ 細かいデプロイ方法や管理するレポジトリ構成は後述 • UDF / Procedure / Streamlit in Snowflake → Snowflake CLI • それ以外 → Terraform ◦ Terraform Provider も以前に比べ安定感・開発速度が 上がっており、開発しやすくなっている ◦ 基本的には2つのモジュールを作りリソースを管理 ▪ Schema と Schema Objects そしてその権限管理の ための Role を管理するモジュール ▪ Role と Warehouse を管理するモジュール 外部テーブルに必要な情報 マスターや公的統計スキーマには 読 み込み権限 warehouse のサイズ POSのスキーマには書き込み権限 DATAHUB_DEV.POS_A スキーマに 必要なオブジェクト・権限設定は 全てこれだけで作られる
16. © 2015 - 2024 Nowcast Inc. 16 3. 現在のデータ基盤の構成 Snowflake のリソース管理 リソースごとに管理・デプロイ方法を選んでいる • table / view → dbt • UDF / Procedure / Streamlit in Snowflake → Snowflake CLI ◦ GitHub Actions & Snowflake CLI の CI/CD パイプラインを作りそれでデプロイできるようにした ◦ Snowflake CLI は2024年2月にV2がリリースされたツール ▪ snow streamlit deploy / snow snowpark deploy などで簡単にデプロイできる ▪ 詳細は以下の２つのブログを参照！ • それ以外 → Terraform
17. © 2015 - 2024 Nowcast Inc. 17 3. 現在のデータ基盤の構成 • モノレポ • ブランチ戦略は Git Flow 的な感じ ◦ feature ブランチを develop ブランチにマージしたら開発環境にデプロイ ◦ develop ブランチを master ブランチにマージしたら本番環境にデプロイ • dbt project は一つ ◦ 複数のデータプロダクトの dbt model が一つのプロジェクトに乗っていた ▪ models/ いかにディレクトリを切っていた ◦ 複数のデータを組み合わせて分析する要件などが増えてきていたため、 全体のデータリネージュをみたりしたかった • SQLFluff によるCIも共通化して設定を省力化 • 問題点 ◦ dbt project が一つなため名前空間が共有され dbt model の 名前が衝突し得る ◦ 複数プロジェクトのデプロイのタイミングを制御できない ◦ あるプロジェクトのエラーが他のプロジェクトに波及し得る ◦ → 複数プロジェクトが密結合な構成となってしまってた dbt レポジトリの旧構成 old-dbt-repo/ ├─ README.md ├─ Dockerfile ├─ pyproject.toml ├─ scripts/ └─ dbt/ ├─ dbt_project.yml ├─ models/ │ ├─ POS_A/ │ ├─ POS_B/ │ ├─ ...
18. © 2015 - 2024 Nowcast Inc. 18 3. 現在のデータ基盤の構成 • モノレポ ◦ 複数プロジェクト間で共通化したい設定を簡単に配布するため • ブランチ戦略は GitHub Flow 的な感じ ◦ master ブランチにマージされたらデプロイ ◦ デプロイ先は変更があったディレクトリに応じて決定する • dbt project などはプロジェクト・環境ごとに一つ • ディレクトリは projects/<proj-name>/<env-name>/ と階層を作る • boilerplate を用意し、必要なファイルをコマンド一つで作成できるように ◦ 右の POS_A/ 以下の全ファイルが簡単に生成されるイメージ ◦ GitHub Actions の workflow も合わせて自動生成される • → 複数プロジェクトを疎結合な構成にし、デプロイも容易に • 問題点 ◦ POS_A/dev/ と POS_A/prod/ のようにdev/とprod/でDRYでない ▪ dev/とprod/を比較して差があればコメントをする CIを用意しておくことでドリフトを防ぐ dbt レポジトリの新構成 new-dbt-repo/ ├─ README.md ├─ scripts/ ├─ templates/ └─ projects/ ├─ POS_A/ │ ├─ dev/ │ │ ├─ dbt/ │ │ │ ├─ models/ │ │ │ ├─ dbt_project.yml │ │ │ ├─ ... │ │ ├─ functions/ │ │ ├─ pyproject.toml │ │ ├─ Dockerfile │ │ ├─ ... │ └─ prod/ ├─ POS_B/ ├─ ...
19. © 2015 - 2024 Nowcast Inc. 19 3. 現在のデータ基盤の構成 • 以前の弱かったCI ◦ 一応 SQLFluff は入っていたが遅すぎて一部オフにされていた • 現在のCI ◦ paths でプロジェクト・環境ごとに疎結合に ▪ boilerplate から自動生成される ◦ 種類 ▪ SQL の linter / formatter • sqlfmt + SQLFluff • 変更があったモデルの分だけチェックする仕組み ◦ → CI の高速化 • dbt templater も入れ、コンパイルされるように ◦ → 事前にエラーを見つけやすく ▪ yaml の formatter ▪ dev/ と prod/ を比較するやつ ▪ UDF / Procedure をテストする pytest の CI ▪ dbt coverage を用いた coverage の計測 → 適宜増やし、より開発しやすい環境づくりを進めている 旧レポではCIが弱かった
20. © 2015 - 2024 Nowcast Inc. 20 4. 今後の課題
21. © 2015 - 2024 Nowcast Inc. 21 4. 今後の課題 CIの充実化 ナウキャストはデータをプロダクトとして売っている会社であり、データパイプラインの開発を安全かつ高速に行うため にCIをより充実化させていく必要がある。 • dbt unit test の導入 ◦ ここは現在検証・開発中 ◦ 様々なデータが存在するので、サクッと各チームで unit test を書けるような工夫を考えたい • CI で dbt build をやる ◦ 「SnowflakeのゼロコピークローンでCI専用環境を作り、そこで dbt build を行う」というCIを一度作ったが いくつかの問題があり現在は撤廃している ▪ 外部テーブルなどクローンに対応していないリソースがある ▪ 全体的にデータ量が大きく、適当に dbt build を実行すると CI が長時間かかり開発者体験がよくない&コ ストがかかる • 検証してみたいものはその他色々... ◦ dbt-project-evaluator ◦ dbt macro のテスト ◦ …
22. © 2015 - 2024 Nowcast Inc. 22 4. 今後の課題 Snowflake のコスト管理 Snowflake はコンサンプションモデルなのでデータ利活用が進むにつれてコストは増えていく。データ利活用を進めつ つ、コスト管理もできるようにするために以下の２つが大事と考えていて、ここは現在取り組んでいるところ。 • コストを可視化できるようにしておく ◦ 具体的には以下の２軸は分離できる仕組みが大事 ▪ 「定期バッチ」or「一時的な開発」 ▪ 「既存プロダクト（AWSから移行予定）」or「新規プロダクト」 ◦ 考えている対応方法 ▪ Warehouse の適切な分割 • Terraform でモジュールを作り Warehouse を分割しやすい環境にはしているが、 一つの Warehouse が複数のワークロードで使われてしまっている ▪ Query Tag の利用 • Warehouse は同じでもコスト分解をできるようにしたい • コストを分析・適宜通知できるようにする ◦ SiS で内製のアプリを作っている ◦ Snowflakeコスト最適化 SaaS である SELECT の導入を検討 ◦ 分析するための情報へのアクセス権限をエンジニアに配布する ▪ Snowsight の一部のコスト系の機能は ACCOUNTADMIN などでないと使えない
23. © 2015 - 2024 Nowcast Inc. 23 4. 今後の課題 メタデータ管理 現在データ基盤に乗っているデータソース・プロジェクトは20種を超え、複数のデータソースを利用した分析プロジェ クト・データプロダクトも出てくるようになった。 → データ利活用をより進めるためにはメタデータ管理が大事 OpenMetadata をセルフホストして使い始めつつある。 Snowflake の認証情報を設定し、スキーマ情報などは収集し簡単に検索もできるようになった また dbt の manifest.json などの artifact をS3経由で連携できる仕組みを作り、 リネージュなども見られるようになった。 しかし運用は正直まだまだ未知数。
24. © 2015 - 2024 Nowcast Inc. 24 4. 今後の課題 データエンジニア絶賛募集中！ データエンジニアがまだまだ足りていません！ ナウキャストで • モダンなデータ基盤を作ったり、 • その上で様々なデータを分析したりパイプライン作ったり、 • お客様のデータ基盤構築・生成AI活用支援したり、 しませんか！ • 会社紹介 ◦ 「ナウキャスト SpeakerDeck」で検索してみてください ◦ https://speakerdeck.com/finatext/nowcast-are-hiring ◦ https://speakerdeck.com/finatext/nowcast-data-and-ai-solution • 募集中のポジション ◦ 「ナウキャスト Herp」で検索してみてください ◦ https://herp.careers/v1/finatexthd/Zed_DMxiz8cY など 気になることがあればXで @Kevinrobot34 や @mt_musyu に気軽にご連絡ください！
25. © 2015 - 2024 Nowcast Inc. 25 Appendix
26. © 2015 - 2024 Nowcast Inc. 26 Appendix GitHub Discussions による ADR 管理 データ基盤に関するレポジトリではこのスライドで紹介した通り様々な工夫が実装されている。 将来のメンバーが、現在の構成になった背景・選択などをキャッチアップしやすいように ADR (Architecture Decision Records) を書くようにしている。 ADR の保管場所として GitHub Discussions を利用している。 • コードと距離が近く、参照しやすい • テンプレートが作成できる • ラベルでステータスの管理が容易にできる といった利点がある。
27. © 2015 - 2024 Nowcast Inc. 27