Snowflakeとdbtを併せて使うと何が良いのか? #SnowflakeDB #dbt

2021.12.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

※本エントリは、Snowflakeをより使いこなそう! Advent Calendar 2021の18日目の記事となります。

さがらです。

最近データエンジニアリング界隈で日本でも聞くようになってきた「dbt」について、Snowflakeと併せて使うと何がよいのか、この記事でまとめてみます。

前置き:ELTについて

dbtとSnowflakeの話に入る前に、昨今のデータパイプライン構築にあたり一般的な考えとなってきているELTについておさらいしておきます。

従来のDWHでは、柔軟なスケールアップ・アウトが難しかったり、そもそもサーバースペックが足りないという課題があり、データをDWHに取り込む際はデータソースからExtractしたデータに対してフィルタや集計などのTransformを行って、絞り込んだデータをLoadする「ETL」が一般的でした。

しかし、昨今のクラウドベースのDWHは柔軟なスケールアップ・アウトが可能でコンピューティング処理能力が高いため、ExtractしたデータをそのままDWHへLoad、その後で活用に適した形に整えるためのTransformを必要に応じて実施する、「ELT」が一般的となってきています。

SnowflakeにおけるELTについて

ここで、SnowflakeでのELTはどういった機能が該当しているか、簡単にまとめておきたいと思います。

SnowflakeのExtract

Extractは、Salesforceなどのアプリケーションや業務システムのRDBのテーブルからデータを抽出することを意味しています。

そして、Extractに関してはSnowflakeだけでは実現が難しい点でもあります。(厳密にはSalesforceのSync Out機能などもありますが、”SnowflakeのExtract機能”と言われるとちょっと違う気もするので…)

しかしこれがSnowflakeの弱い所かというとそうでもなく、他のDWH(BigQuery、Redshift)でもExtractについては別のサービスを使ったり自身でプログラムを書いたりするケースが一般的です。

サービスを使用する場合は、Loadまで担ってくれるケースが多いと思います。弊社でも取り扱っているFivetranや、OSSだとAirbyteなども最近は耳にしますね。

SnowflakeのLoad

Loadに関して、Snowflakeでは大きく以下2つの機能を持っています。

  • COPYコマンドを用いたバルクロード
  • Snowpipeを用いた継続的なロード

これらの機能を使う場合は、AWSのS3などに事前にLoadしたいデータをCSVやJSONなどの形式で保持しておくことが一般的です。

SnowflakeのTransform

Transformに関して、Snowflakeでは大きく以下の方法があります。

  • CREATE TABLE/VIEW ... AS SELECTINSERTなどのSQLコマンドを用いて目的のテーブルやビューを作成
  • 定期的なTransformは、タスク機能を用いて任意のSQLコマンドをスケジューリングする

Snowflakeだけでもこれらの機能により充分にTransformは実現可能です。しかし、Transform対象のテーブルの数が多くなってきたりパイプラインが複雑化してくると、以下のような課題が出てきます。

  • Snowflake単体では記述したクエリのバージョン管理機能がないため、ふと過去のクエリを確認したくなったときなど容易に確認できない&戻せない
  • 管理するテーブルやパイプラインの数が大量になると、運用方法によっては各テーブルやパイプラインに関する仕様が管理しきれなくなる

dbtは「Transform」を担当するツール

ここでようやく、dbtの話になります!

dbtは一言で言うと、ELT(Extract、Load、Transform)における「Transform(変換)」を担当するツールです。 使用する場面としては下図のように、Extractしただけの生データをdbtを用いて必要な形にTransformして、BIツールなどで活用するイメージですね。

dbtの主な特徴としては、以下の4点が挙げられます。

  • SELECT文を記述することで、返ってくる結果がテーブルとして作成される
  • ref機能を用いることで依存関係を設定して目的のテーブルを構築するまでのフロー(DAG)も構築可能
  • Gitリポジトリを用いたバージョン管理が可能。過去のある時点のテーブル仕様のクエリも確認が可能
  • 処理で作られたデータに問題ないかを確認するテストや、コードの内容に応じたドキュメントの生成にも対応している

dbtについてのより詳細な説明や画面イメージを見たい方は、ぜひ下記のブログやYouTubeをご覧ください。

他にも、dbtに関しては弊社でも多くの記事やYouTubeで動画を投稿しております。こちらも是非ご覧ください。

Snowflakeとdbtを併せて使うと何が良いのか?

ここでブログタイトルの回収です!Snowflakeとdbtを併せて使用すると何がよいのか、説明していきます。詳細は以下に記しますが、dbtはSnowflakeを用いたELTのTransformで痒い所を必要十分にカバーしてくれるサービスです!

クエリのバージョン管理が可能

これは上述のSnowflakeのTranformの所でも説明しましたが、Snowflake単体では記述したクエリのバージョン管理が出来ません。Gitを用いたバージョン管理ができることにより、複数の開発者によるシステムコンフリクトを避けたり、 プルリクエストを通したコードだけデプロイする、ということが実現可能です。

リネージ、テスト、ドキュメント生成というTransformをより強固にするための機能が使用できる

TransformするだけならSnowflakeでもよいのですが、以下の痒い所をdbtはカバーできます。

  • 目的のテーブルに至るまでフローを図示して確認する機能がない➟dbtにはリネージ機能がある
  • Transform処理実行のテーブルに問題がないかを確認する機能がない➟dbtにはテスト機能がある
  • 開発した処理の仕様書は別途記述しないといけない➟dbtにはドキュメントの自動生成機能がある

定型処理の実行に関するオプションが豊富

Snowflakeだけだと定期的なクエリ実行にはタスクを使うしかなく標準機能だけではエラー発生時のSlack通知なども出来ませんが、dbtを用いる場合、多様なパターンに対応できます。

  • Snowflakeのタスクは親タスクを1つしか設定できないが、dbtではref機能により複数の親テーブルの更新処理完了後に目的のテーブル更新処理の実行が可能
  • dbt Cloudならば、Slackへの通知設定がGUIベースで可能

Snowflake×dbtは海外での事例も豊富で情報が多い

実はdbtは海外(特に米国など)ですでにELTのTを担うサービスとして広く普及しており、Slackのコミュニティには22803人在籍しています。(2021年12月18日時点)

さらに面白いのが、dbtのコミュニティでは各DWHごとのチャンネルもあるのですが、Snowflakeのチャンネルが最も在籍人数が多いのです。(2021年12月18日時点)

  • db-snowflake:3501人
  • db-bigquery:1706人
  • db-redshift:1288人

Snowflake×dbtでの情報(そもそもdbt自体の情報も)は日本語ではまだ少ないのが正直なところですが、DeepLやGoogle翻訳を駆使すれば海外のDeveloperが実運用上で困っている内容とその対策に関する情報をたくさん得ることができます。

コミュニティが大きいサービスと小さいサービスを比較すると、やはりコミュニティが大きければ大きいほどインターネット上で情報を拾いやすくなり、迅速な問題解決にも繋がってくるものです。このコミュニティが大きいことも、Snowflake×dbtの強さだと感じています。

まとめ

ELTのおさらいから、Snowflakeとdbtを併せて使うことの良さまで説明しました。

Snowflakeでは足りない痒い所を補うことができるのがdbtですので、「Snowflake内での加工処理(Transform)、どうやって実装しよう…」とお悩みの方にはぜひ使用して頂きたいサービスです!

※もちろん、dbtはBigQueryやRedshiftをご利用中の方にも刺さるサービスですよ!

次回

Snowflakeをより使いこなそう! Advent Calendar 2021、次回の19日目では、「Snowflake×dbtを試してみた~Part1:基本設定編~」というタイトルで執筆します。お楽しみに!

※12/18~12/24まで、毎日Snowflake×dbtの記事を書きます!!