こんにちは。Supershipの@y-ishiguroです。
この記事はSupershipグループ Advent Calendar 2025の13日目の記事です。
はじめに
業務で新たなSnowflakeデータ基盤を作成する場面があり、そのETL処理にdbtを利用してみた所感をまとめてみます。
dbtを使ってみた
これまでのETL処理
既存のSnowflakeデータ基盤のETL処理にはAWSのMWAAを利用しており、複雑に絡み合うクエリの処理順序をDAGで定義してデータの加工を行っています。
ただ、以下のような課題があります。
- 独自のヘルパーを使っているので、初期の学習コストが高い
- 決まった書き方を真似すれば動くが、何をしてるかちゃんと理解しようとすると大変
- データの依存関係をDAGの処理順へ反映するのは人力で行う必要がある
- テーブル同士の関係性に詳しくないと手を出し難い
dbtを利用することでこれらの問題の解決に繋がらないか？と検討していたところに新規基盤開発の機会が訪れたため、まずはそちらでdbtを利用してみることにしました。
project構成
データ設計としてメダリオンアーキテクチャを採用したため、model配下のディレクトリの切り方はそれに沿った3層構造(取ってきたもの/中間加工/ビジネス利用可能なもの)にしました。
命名は若干異なるものの、概念としては公式のベストプラクティスの構成に近いものです。
└models/
└ bronze/
└ source.yml
└ silver/
└ db_a
└ schema_x
└ schema.yml
└ table_1.sql
└ table_2.sql
└ ...
└ schema_y
└ ...
└ gold/
└ db_x
└ db_y
└ ...
SQL
dbtのSQLにはjinjaの構文を使うことができ、ここでテーブル同士の依存関係を明確にしておくと、runの実行順序に反映されます。
-- table_2.sql
-- table_1に依存しているため、run時はtable_1より後に実行される
SELECT
table_1.id,
table_1.name
FROM {{ ref('table_1') }} AS table_1
デプロイ
はじめはdbt Projects on Snowflakeを利用してコンソールからデプロイする方法を検討していましたが、後々CI/CD化することなどを考えて最終的にはローカルからのsnowflake CLIでのデプロイになりました。
$ snow dbt deploy ~~~
おわりに
はじめはdbtに不慣れでとっつきにくかった部分もあったのですが、MWAAの構成と比較するとスッキリ書くことができる等、メリットが多いと感じました。
特に実行順序がdbt側で自動的に組み立てられるのは大きなアドバンテージだと感じており、今後基盤が大きくなってテーブル同士の依存が複雑になっていくと真価をより発揮するのではないかと思っています。
一方で、dbtを定期実行するtaskなどのリソースはterraformでの管理を行っているため、role周りの管理が複雑になってしまっているなどの課題も残っています。
dbtの練度を上げ、今後は上手い共存の形を見つけられたら良いなと思っています。
最後に宣伝です。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership 採用サイト
是非ともよろしくお願いします。