Snowflakeデータ基盤の信頼性をTerraformによるCI/CDとdbt testで高める

【関西開催】まだ間に合う！Snowflake Summit最新情報キャッチアップ【Snowflake WESTユーザー会】で登壇した際の資料になります。

https://techplay.jp/event/951200

Transcript

1. 
 Snowflakeデータ基盤の信頼性をTerraform によるCI/CDとdbt testで高める 
 2024/07/29(月)15:00 〜 18:00　
 【関西開催】まだ間に合う！Snowflake Summit最新情報キャッチアップ【Snowflake WESTユーザー会】
 是枝達也

2. 2 自己紹介
 名前 是枝達也 略歴 クリエイティブサーベイ データエンジニア 趣味 ・バイオインフォマティクス（遺伝子・ゲノム解析） ・AI創薬研究 好きなSnowflakeの機能 ・Snowpark Container Service 活動 Zenn/Mediumでの記事執筆 称号 Snowflake Squad 2024（日本人初）
3. 3
 はじめに
4. Confidential © CREATIVE SURVEY 目次 1. Terraform 導⼊背景 2. dbt test導⼊背景 3. dbt testによるデータ取り込み品質の取り組み a. Snowflakeの便利関数を使った類似度推定テスト（カスタムGenericテスト） b. Genericテストの適⽤ 4. dbt 開発tips 5. まとめ
5. 5
 Terraform導⼊背景
6. CI/CDフローのBefore/After 
 6 • GitHub Actions（GHA） + Terraformの デプロイパイプラインはできていた（※） • 課題 ◦ 本番環境しかコード化されていない ◦ ⼀部のリソースはTerraformに未反映 ◦ SnowflakeのGUI‧クエリで変更を加えた後に terraform importする運⽤ • 少⼈数での運⽤なので問題なかったが、 データエンジニア以外のエンジニアも データ基盤に変更を加える可能性がある ※ Github Actions + Terraformを使ったSnowflakeリソース管理のCI/CDパイプラインの構築（Zenn） • 本番/ステージング/開発環境をコード管理 • 本番/ステージング環境はGHAからterraform apply • Terraformへのインポートとリファクタリング ◦ Terraform管理されていないリソースはimport ◦ 複数環境に対応するためTerraformモジュール化 • CI部分を強化 ◦ GitHub Pull Request（PR）作成時に 本番/ステージング環境にterraform plan ◦ plan結果をPRコメントに記載 Before After
7. CI/CDフロー 〜開発〜 
 7 • Snowflakeは本番/ステージング/開発の3環境
 ◦ 開発環境は開発者が自由に変更を加えることができる
 ◦ Role/WarehouseはTerraformによる管理
 • AWSは本番/ステージングの2環境
 • mainブランチへのPR作成後
 ◦ AWS・Snowflakeの本番/ステージング環境にterraform plan
 ◦ plan結果がPRコメントに記載
 
 
 
 
 
 • PRマージ後、AWS・Snowflakeステージング環境にapply

8. CI/CDフロー 〜リリース〜 
 8 • GitHubのリリース機能を利用
 ◦ 新しいリリースのバージョン番号のタグを作成、Publish
 ◦ リリースノートとしてリリース履歴が残る
 • AWS・Snowflake本番環境にterraform apply

9. Terraformのディレクトリ構成や実装について 
 9 terraform ├── aws │ ├── modules │ │ ├── apigateway │ │ …… │ ├── prod │ └── stg └── snowflake ├── modules │ ├── database │ │ ├── main.tf │ │ ├── outputs.tf │ │ ├── provider.tf │ │ └── variables.tf │ ├── file_format │ ├── procedure │ …… ├── prod │ ├── main.tf │ ├── provider.tf │ └── variables.tf ├── stg └── dev • terraformディレクトリ以下にAWSとSnowflakeで分ける
 • 環境名ディレクトリ(dev/stg/prod)には、環境ごとに異なる設定値やプロバイダを定義
 • modulesディレクトリ以下にリソースを定義している
 • Snowflakeではリソース作成時にロール指定が必要なため、エイリアスを利用
 • テーブル、ビュー以外のSnowflakeリソースをTerraformで管理
 ◦ テーブル、ビューはdbt管理
 provider "snowflake" { alias = "default" role = "TERRAFORM" warehouse = "TERRAFORM_WH" } provider "snowflake" { alias = "useradmin" role = "USERADMIN" warehouse = "TERRAFORM_WH" } provider "snowflake" { alias = "securityadmin" role = "SECURITYADMIN" warehouse = "TERRAFORM_WH" } provider "snowflake" { alias = "sysadmin" role = "SYSADMIN" warehouse = "TERRAFORM_WH" } # main.tfでモジュール呼び出す処理 module "xxxxxxx" { source = "../modules/xxxxxxx" providers = { snowflake = snowflake.default snowflake.useradmin = snowflake.useradmin snowflake.securityadmin = snowflake.securityadmin snowflake.sysadmin = snowflake.sysadmin } } # モジュール内 resource "snowflake_role" "foo" { # SECURITYADMINロールを指定 provider = snowflake.securityadmin name = "foo" } resource "snowflake_warehouse" "bar" { # SYSADMINロールを指定 provider = snowflake.sysadmin name = "bar" }
10. • クリエイティブサーベイにおけるデータ基盤（AWS/Snowflake）のCI/CDフローを紹介
 • PR作成時にterraform plan結果を記載することでレビューしやすくなる
 • リソース変更をGHAに寄せることで、実装者（データエンジニア/開発エンジニア）は強い権限を持たずに開発できる
 • GitHub Releaseにリリース履歴が残っているため、いつ誰がリリースしたのかが分かる
 
 今後
 • CI/CDフローにdbtを組み込む
 ◦ 本番環境しか利用できていないため、ステージング環境でも利用できるようにする
 • ワークフローツールの導入
 ◦ Aurora MySQLからのデータ取り込みとdbt実行がひとつのパイプラインで実行できるようにする
 Terraform のCI/CD まとめ 
 10
11. 11
 1. dbt test導⼊背景
12. Confidential © CREATIVE SURVEY データ品質をチェックするきっかけ - dbtのIncremental Modelでインフラコストの削減ができないか調査して いた時のこと > 洗い替えから増分更新にしたい > Incremental Modelのstrategy(merge)ってやつが良さげ - 試しに⽇次更新のIncremental Modelのパイプラインを構築した
13. Confidential © CREATIVE SURVEY データ品質をチェックするきっかけ - データソースのsnapshotとIncremental Modelの間にデータずれが発⽣ > データずれの原因 - 私のデータの仕様の認識不⾜ - dbt Incremental Modelの理解不⾜ > strategy(merge)は論理削除に対しデータソース側は物理削除 > snapshotよりIncremental Modelのレコード数が多い事態に - Modelの改修によるコスト削減より、データ品質に関するニーズが⾼まる →データ品質保証のためdbt test導⼊へ
14. 14
 2. dbt testによるデータ品質活動
15. Confidential © CREATIVE SURVEY データ品質に取り掛かるまでにやること多い - modelのデータ品質をdbt testでどのくらい保証できるのか試したい - データ品質というと広いので、データを取り込む際の品質について考えていく > > - 今回dbt testで⽬指すこと データソースのSnapshotを Snowflakeへ取り込む前後でデータずれがないかテストする
16. Confidential © CREATIVE SURVEY dbt testでやったこと - データソースのsnapshotとmodelの類似度を測るカスタムGenericテストの作 成 > Snowflakeの関数 MinhashとAPPROXIMATE_SIMILARITYを利⽤ - サンプルコードや内部的な動作は参考記事を参照 - Minhashで作成するハッシュ関数の数など、関数のパラメータはドキュメントの推奨値をそ のまま使⽤ - Generic tests(汎⽤テスト)の適⽤ > modelなどのリソースにテストを設定するyml（プロパティ）に書きこんでいく > 始めから⽤意されているGenericテストがある - unique, not_null, accepted_values, relationships 「参考：Snowflake Document 『2つ以上のセットの類似性の推定 』」
17. Confidential © CREATIVE SURVEY 類似度推定テスト（カスタムGenericテスト） - このテストの良いところ > データ同⼠の類似度を測ることができる > 実⾏時間が対象テーブルのカラム数に依存し ないところ - カラム数の多さに実⾏時間の増加を受けるこ となく、類似度を測定できる データソース
18. Confidential © CREATIVE SURVEY 類似度推定テストの効果と発⾒ - 効果 > 37分程度でデータソース（約91.8億レコード）の類 似度をチェック出来るように - 発⾒ > testに失敗する怪しいmodelを⾒つけるきっかけに > ⼿軽に対象データの品質担保に使えそう
19. Confidential © CREATIVE SURVEY どこまでGenericテスト(汎⽤テスト)するべきか - ⼀度ほぼ全てのカラムにGenericテストを適⽤した - 結果 > ⼗中⼋九成功するテストや、ビジネスキー以外に対するテストは、テストを⾏う効果が感じづら く、それよりもコストの⽅が気になった - どの程度のカラムに適⽤すべき？ > チームで会話した結果、ビジネス要件を満たす最低限のデータ品質を担保するためにテストする > ビジネスキーに絞ってunique, not_nullを適⽤することにした - Genericテストをやって学んだこと > データ品質要件とデータ量や複雑なテストから⽣じるインフラコストはトレードオフ > 重要なのは何のために⾏うテストか、やればいいものではない
20. 20
 3. dbt開発 tips
21. Confidential © CREATIVE SURVEY dbtのpackageの情報収集に役⽴つdbt Package hub - dbt Package hub > 今回model作成時に利⽤した便利パッケージ：dbt_snow_mask - その中でも気になっているパッケージ > elementary - 可観測性レポート、dbt testによる異常検出、dbt_artifact、Slackアラート、データリネージ 可視化 > dbt_utils - 含まれるテスト17個（ver1.1.1時点） > dbt_expectations - 含まれるテスト62個（ver0.10.3時点) > dbt_meta_testing ＆ dbt-coverage(後者はdbt core向けっぽい) - テストを継続的に⾏うためのテストやメタ情報のカバレッジのチェックや可視化に使える
22. 22
 4. まとめ
23. Confidential © CREATIVE SURVEY dbt testまとめ データ品質の向上‧担保を⾏うコストや時間が⾜りない⽅へ - ⼿始めに類似度推定テストやってみるのはいかがでしょうか - dbtのコミュニティはとても活発なので、パッケージをどんどん活⽤しよう チームとしての今後の展望 - elementaryの導⼊など、さらなるデータ品質の向上‧担保へ向けた取り組 みをしていく