dbt x Snowflake x GithubActions 構成例

概要

https://www.youtube.com/watch?v=snp2hxxWgqk

Snowflakeをdbtで管理する
GitActionsでCI/CDを行う

そんな動画がYoutubeにありました。その中に、非常に参考になるものがあったので、こちらを調べてみたいと思います。

https://github.com/randypitcherii/cloud_cost_monitoring
こちらが動画内でデモにも使われていたレポジトリ

動画の説明

CIとは

• DEV : 開発者がブランチで作業する際に使用
• TEST : ブランチが承認される前にコードを配置し、テストするために使用される
• PRD　: エンドユーザが使用。マスターブランチで公開

Automation with Github Actions

dbtを用いる。dbtは、ELTツールで取り込んだRawDataを変換するツール。

EL（T）ツールとして、Fivetranで、データを　DWH（Snowflake）に投入し、それをT（Transform）するのがdbtでマートなどを生成する。

Hans-on with Workflows

Production deployment from master

https://github.com/randypitcherii/cloud_cost_monitoring/actions/workflows/ci_prod.yml
こちらは、masterブランチにマージされて、本番環境にDeployするワークフロー
レポジトリ的には workflows/ディレクトリに存在している。

https://github.com/randypitcherii/cloud_cost_monitoring/actions/runs/30786133/workflow

• masterブランチにPushされた時に起動
• envにて環境変数をセット
  • targetは、prod
  • PASSWORDなどは secrets　に入れてる
• jobs : 起動するDockerイメージ（？）
  • dbt run --profiles-dir ./ci_profiles
  • dbt test --profiles-dir ./ci_profiles

Scheduled production run

こちらは、GitActionで定期的にDeployするワークフロー
レポジトリ的には workflows/ディレクトリに存在している。

https://github.com/randypitcherii/cloud_cost_monitoring/actions/runs/47803001/workflow

• 起動は、cron　( '0 */1 * * *' # Run every hour )
• envにて環境変数
  • targetは "prod"
• jobs :
  • dbt run --profile-dir ./ci_profiles

使い方としては、定期的に追加されるデータの変換処理などに使うのに良さそう。

dbt run --select tag:hourly

のように通のが良さそう

profiles.ymlの中では、testとprodの設定が一緒になっているが、ビルドステージによって異なる意味を持っている　・・・・　（意味がよくわからん・・・・それぞれの環境で異なることもあるからわけておいたほうがいいってことかな・・・）

<profile-name>:
  target : <target-name>
  outputs:
    <target-name>:
      type : snowflake

などとなっている。こちらのプロジェクトでは

cloud_cost_monitoring:
  target: "{{ env_var('DBT_PROFILE_TARGET') }}"

  outputs: # test and prod are identical, but their target names has significance in different build stages
    test:
      type: snowflake
      ....
    prod:
      type: snowflake

となっており、２行目の targetが環境変数で決まり、その<target-name>が、outputs配下のtargetを選んでいると思われる。

Test deployment from a PR

https://github.com/randypitcherii/cloud_cost_monitoring/actions/runs/30785503/workflow

target : test になっている。
jobsの中で

• export DBT_PROFILE_SCHEMA=pr_$(date +%s)
• dbt run --profiles-dir ./ci_profiles →　target=test
• dbt test --profiles-dir ./ci_profiles → target=test

テスト環境なので出力先のスキーマが pr_20220101みたいな名前にしているのだと思う。
ここのネーミング規則は、プロジェクトにより適切な命名規則をつけるのがいいと思われる。
例えば、 <ブランチ名>_<日付>とかもあり

Pull-Requestをなげたら

「Test deployment from a PR」ワークフローが発火して、テストが走る。
この際テストが動くスキーマは、下記のようになる。

• PR_20220102_REPORTING
• PR_20220302_STAGING

https://github.com/randypitcherii/cloud_cost_monitoring/blob/master/workflows/ci_test.yml#L34
の記載で、export DBT_PROFILE_SCHEMA=pr_$(date +%s)が設定

macos/get_custom_schema.sql で、prod環境以外では、<default_schema>_<custome_schema_name>となるように上書きしているので、PR_20220102_REPORTINGというカスタムスキーマ名になる。

で、テストが通ったら、masterブランチにマージボタンが有効化して、マージができるようになる。

Generate Docs

$ dbt docs generate --target prod && dbt docs serve

こちらで、dbtドキュメントを生成し、webサーバを立ち上げる。
→ http://127.0.1

dbtプロジェクトの構成

• ci_profiles
  • profiles.yml
• macros
  • get_custom_schema.sql
• models
  • reporting
    • reporting.yml
    • snowflake_rolling_sum_of_usage.sql
  • staging
    • aws
      • aws.yml
      • stg_hashmap_aws_costs.sql
    • snowflake
      • snowflake.yml
      • stg_hashmap_snowflake_daily_usage.sql
      • stg_hashmap_snowflake_usage.sql
• snowflake_setup
  • service_accounts
    • dbt_prod.sql
    • dbt_test.sql
    • singa_computing.sql
  • cloud_cost_monitorging_base.sql
  • teardown.sql
• tests
  • staging
    • snowflake
      • asser_usage_for_every_day.sql
• workflows
  • ci_prod.yml
  • ci_test.yml
  • scheduled_prod.yml
• dbt_project.yml

という構成になっている。

ci_profiles/profiles.yml

https://github.com/randypitcherii/cloud_cost_monitoring/blob/master/ci_profiles/profiles.yml

target: "{{ env_var('DBT_PROFILE_TARGET') }}" となっているので、 workflowによって、prodやtestが設定される。

このファイルでは、targetが、testとprodがあり、それぞれの設定が同一・・・一応、Deploy環境で違うので・・・環境（target）ごとに作成しておいて、なにか違うポリシーを適用するのに、作っておいて損はないか・・・

macros/get_custome_schema.sql

macros/get_custom_schema.sql
スキーマ名を独自のものに変更するマクロで上書きをしている。

• デフォルトスキーマは、target.schame
• custom_schamaが設定されていなければ、デフォルトスキーマ
• もし、target=prodなら、カスタムスキーマ名
• それ以外の環境なら　デフォルトスキーマ名_カスタムスキーマ名

models

staging/snowflake/snowflake.yml

models/staging/snowflake/snowflake.yml

freshness:
    warn_after: { count: 24, period: hour }
    error_after: { count: 48, period: hour }

※error_afterは、解説のために私が追加。

freshnessでは、「現在の時刻とデータの時刻がこれだけ離れていたら警告/エラーを出す」という定義をしている。
２４時間以上前ならば、警告
４８時間以上前ならば、エラー
を通知する設定となっている　（※通知？　Deploy時のwarn/errorになると思われる）
この状態で、dbt source snapshot-freshnessを実行すると、データの鮮度がチェックできる。
仮に、２４時間以上前の場合は、WARNが通知される。

参考
https://dev.classmethod.jp/articles/dbt-sources/

staging/snowflake/stg_hashmap_snowflake_usage.sql

models/staging/snowflake/stg_hashmap_snowflake_usage.sql

with usage as (
  select 
    * 
  from 
    {{ source('snowflake_usage', 'warehouse_metering_history') }}
)

select * from usage

なぜ、WITH句を使っているかがわからない・・・

select * from {{ source(source_name, table_name) }}

で、 models/staging/snowflake/snowflake.yml　 に設定している sources: nameとsources:tables:name:を使って、データソーステーブル（リネージュの大元）を指定している。

staging/snowflake/stg_hashmap_snowflake_daily_usage.sql

prehookが指定してあり、CREATE SEQUENCEを実行している。

カラムは、snowflake.ymlに記載があり、そちらでtests:not_nullやuniqueが指定しており、そちらでデータのテストが実施される。

snowflake_setup

このディレクトリには、ｄｂｔを使う前の環境設定が行われている

├　service_accounts : WAREHOUSE, ROLE, Privilage , SERVICE ACCOUNTの作成
| ├ dbt_prod.sql
| ├ dbt_test.sql
| └ sigma_computing.sql
├ cloud_cost_monitoring_base.sql : DATABASE, SCHEMA, WAREHOUSE, ROLE, PRIVILAGE 
└ teardown.sql : DATABASE, WAREHOUSE, ROLE, USERの削除のSQL

こちらのプロジェクトでは、ソーステーブルは、Fivetranで取得、作成しているので、CREATE TABLEのSQLは存在していない。

が、Snowpipeなど、SnowflakeでExtract-Loadを行うのであれば、テーブル定義や取り込み設定もこちらに書くべきだろ

また、この部分は、 terraformやschemachangeなどのプロダクトを使うのがいいかも

tests

tests/staging/snowflake/assert_usage_for_every_day.sql

先頭ブロックの{{ config(severity='warn') }}は、このテストを実施した場合に、WARNで警告を出す設定。 serverity=重要度

ここは、出ちゃだめな条件を記載する。

こちらのSQLでは、

where num_rows != num_days

で、これは正常なデータではありえない！　のでNG。出力があると 警告　となる。

workflows

ci_prod.yml

• ブランチ「master」にPushされたら起動する
• env:にて、設定。
  • secrets にパスワード
  • target : prod
• jobs:
  • docker-imageの指定
  • ブランチのチェックアウト
  • Python3.7のインストール
  • DBTのインストール
  • DBTコマンドの実行
    • dbt run --profiles-dir ./ci_profiles
    • dbt test --profiles-dir ./ci_profiles

ci_test.yml

• PRが作成されたときに起動
• env:
  • target は test → profiles.ymlに関係する
  • secretsを使っている
• jobs:
  • docker-imageの指定？
  • checkout
  • Python3.7のインストール
  • DBTのインストール
  • DBTコマンドの実行
    • DBT_PROFILE_SCHAMAを　　PR_20220314　などに設定
      • PR_20220314_REPORTING、PR_20220320_STAGING　などのカスタムスキーマに構築される。
    • dbt run --profiles-dir ./ci_profiles
    • dbt test --profiles-dir ./ci_profiles

scheduled_prod.yml

• cronのスケジュールで起動 0 */1 * * * ※毎時起動
• env:
  • target = prd
  • secretsを使用　※パスワードとかハードコーディングしない！Gitに挙げない！！
• jobs:
  • dbt run --profiles-dir ./ci_profiles

dbt_project.yml

profileは、cloud_cost_monitoringを使用
ci_profiles/profiles.yml でこの名前のprofileを作っている

基本的なディレクトリ構成は、デフォルトのママ

modelsにて
stagingは、カスタムスキーマ：stagingで、 view で作成
reportingは、カスタムスキーマ:reportingで、tableで作成指定