今回の課題
今回は、以前下記の記事で使用した、
S3からSnowflakeにデータをロードするためのクエリをGitHubで管理できるように、
Snowflakeのworksheetではなく、dbtでクエリを実行するように実装した。
※ストレージ統合CREATE STORAGE
や外部ステージCREATE STAGE
の作成のための、
クエリはdbtではなくSnowflakeのworksheet上で実行する必要があったため、
dbt経由でGitHubにpushしてコード管理することはできなかった。
◼︎前回の記事
前回の記事までで、実装している内容は下記。
- S3データをロードする用のdatabase, schema, tableの作成
- ステージとファイルフォーマットの定義
- S3データをロードする用のtableにS3のデータを格納
今回実装した手順
1)generate_schema_nameマクロの定義を変更する
dbt projectのmacros
ディレクトリ直下に、get_custom_schema.sql
ファイルを作成して、
下記のように記述してマクロの定義を変更した。
{% macro generate_schema_name(custom_schema_name, node) -%}
{%- set default_schema = target.schema -%}
{%- if custom_schema_name is none -%}
{{ default_schema }}
{%- else -%}
{{ custom_schema_name | trim }}
{%- endif -%}
{%- endmacro %}
generate_schema_nameマクロとは
デフォルトで定義されているマクロで、dbtがスキーマを生成する時のロジックが記述されているマクロのこと。
デフォルトでは、全てのmodel
はターゲットで指定されたスキーマに対してビルドされているため、
上記のmacro
では、作成したデータロード用のschemaにデータがロードされるようにマクロの内容を書いている
※ターゲットで指定されたスキーマ以外のことをカスタムスキーマと言う。
dbt Cloud IDEの場合、下記の画像のようにターゲットの定義は、
Your Profile
>Credentials
をクリックして出てくるConnection Details
から確認することができる。
2)dbtを使ってロードする
2)-1.データをロードするためのmodelを格納するディレクトリを作る
models
ディレクトリの配下にload
というディレクトリを作成し、
dbt_project
を下記のように変更する。
models:
my_new_project:
# models/load/配下のmaterializedをtableに定義しておく。
load:
materialized: table
2)-2.loadディレクトリ直下にロードするためのmodelを作成する
※こちらをdbt run
すれば、Snowflakeの指定のテーブルにデータがロードされる。
SELECT
$1:dt::varchar
, $1:order_id::varchar
, $1:user_id::varchar
, $1:purchase_amount::varchar
FROM -- ここでのEXTERNAL_TABLEは外部ステージの名前のこと。
@DEMO_DB.PUBLIC.EXTERNAL_TABLE/mysnapshot20230402043959/rails_test_app_test/rails_test_app_test.purchase_log/1/part-00000-cc307475-00bf-4e8f-a351-b358a1636058-c000.gz.parquet
(file_format => 'parquet')
3)Git Hubにpushする
dbtの右上のCommit and sync
をクリックして、GitHubに簡単にpushできる。
以上!
まとめ
dbtは簡単にGitHubと連携できる機能があるので、
その機能を使えば、GitHubで簡単にクエリ履歴の管理をすることができることが分かった。
dbtでETLをしたクエリであれば、簡単にGitHubでクエリ履歴の管理ができるので便利だと感じた。
外部ステージ作成や統合ストレージの作成は、Snowflake内のworksheetでクエリを実行する必要があり、dbt経由ではクエリの管理ができないというところが気になった。
参考記事