この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
さがらです。
2022年6月9日に、dbt×Fivetran×SnowflakeによるModern Data Stack～データ活用までの準備を楽々に～といったタイトルでウェビナーを開催しました。
本記事では、このウェビナーの内容を簡単にまとめた上で、質疑応答の内容もまとめていきます。
dbtの概要
弊社の堀本より、dbtの概要について説明しました。
堀本が登壇レポートブログを執筆しておりますので、こちらの記事もぜひ御覧ください。
dbt×Fivetran×SnowflakeによるModern Data Stackのご紹介
私さがらより、dbt・Fivetran・Snowflakeを組み合わせたModern Data Stackについて、FivetranとSnowflakeはそれぞれどういったサービスなのか、dbtとFivetran・Snowflakeを組み合わせるとどういったメリットがあるのか、というお話をしました。
登壇資料
Modern Data Stackとは
まず、私の発表のタイトルにある「Modern Data Stack」についてです。
Modern Data Stackを一言で表すと、クラウドネイティブなサービスで構成されたデータ基盤のことです。
データ基盤は、「データの取り込み」「データの蓄積（データウェアハウス）」「BIツールやデータサイエンスによるデータ活用・分析」という大きく3つのフェーズに分かれますが、最近はそれぞれの分野でクラウドベースのサービスがいくつも提供されています。
具体的には、
- データの取り込み
- 弊社での取り扱いもあるFivetranだけでなく、StitchやAirbyteといったサービスもあります。
- データの蓄積（データウェアハウス）
- 今日のタイトルにもあるSnowflakeだけでなく、AWSのRedshift、GoogleCloudのBigQueryあたりも有名なサービスです。
- BIツール
- LookerやModeといったサービスがクラウドを用いたSaaSとして提供されています。
そしてこれらのサービスを組み合わせるだけで、データ基盤を構築することが出来ます。 これにより、データ取り込み処理の開発やサーバーの準備や運用などを気にせず、データ分析をすぐに始めることが出来ます。
Fivetranとは
Fivetranとは一言でいうと、開発や運用作業が不要なELT、つまりデータの取り込みを担うサービスです。
Fivetranは、「データを抽出してデータウェアハウスに保存する」工程の全てを担ってくれます。 具体的には、データ抽出後の加工から、データロード時のスキーマ設計、抽出用のAPIに変更があったときの対応、など、全てFivetran側で行ってくれます。
これにより、データウェアハウスにデータが入ってからのデータマート開発やBIツールでのダッシュボード開発などに専念できるようになり、組織のデータ活用をより早く進める事ができます。
下図のスライドでは、Fivetranによる構成される、オンラインストアなどのeコマースプラットフォームを展開するShopifyに関するスキーマのER図を示しています。
1つ1つのテーブルを見ると、主キーから外部キーまで明記されており、各テーブル間のJOINに必要な情報もすぐわかるようになっています。
このように具体的なER図は、AirbyteやStitchといった、Fivetranと類似する他製品にはありません。 AirbyteやStitchでは、各データソースのAPIドキュメントへのリンクを貼るだけだったり、テーブル定義があってもただ羅列をしているだけ、というケースが多いです。
そのため、このFivetranにより構築されるスキーマに関する詳細なER図があるというのは、Fivetran独自の強みと言えます。
また、Fivetranは160種類以上のコネクタを提供しております。公式ページにすべて一覧がありますので、ぜひこちらを見て頂き、皆様が使用されているデータソースがあるかどうか見て頂けると幸いです。
dbt×Fivetranの強み
上述したFivetranとdbtを組み合わせた時の強みとしては、「dbt Transformation」「Fivetran用のdbt package」があります。
まず「dbt Transformation」は、Fivetranのデータロード処理が完了したことをトリガーに、dbtのデータ変換処理を実行できる機能です。
通常、データロード後にデータ変換処理を実行する場合、自分でデータの取り込みが終わったことを示すイベント通知処理を開発して、後のデータ変換処理を実行したり、Airflowなどのワークフロー管理ツールが必要となってくるケースが多いです。
しかし、Fivetranとdbtは標準機能で連携できるようになっており、こういった処理の開発やワークフロー管理ツールが不要となります。
また、Fivetranには元々データロード後に続けて、SQLで記述したデータ変換を行う機能はあるのですが、それはSQLをFivetranのGUI上にベタ書きするしかなく、環境の切り分けやコードのバージョン管理ということができません。 そのため、dbtの良さも活きてくる機能となります。
次に「Fivetran用のdbt package」についてです。
前提知識としてdbt packageとは、一般的なプログラミング言語でいうライブラリのdbt版と思って頂ければOKです。 dbt packageの中身としては、modelやmacroが含まれており、すぐに開発に使えるコードがまとまっています。
そして、このdbt packageについて、Fivetran用のdbt packageが用意されています。
具体的には、Fivetranにより構築されたスキーマを用いた、すぐに活用できるデータマートを生成するdbtのmodelが、このpackageには含まれています。
１つ例として、Salesforce用のdbt packageには、チーム/メンバー/商談ごとに、各種金額や商談に関する集計値を出してくれるmodelがまとまったpackageなどがあります。
そして、この2つの強みを組み合わせる、つまりdbt packageを用いてdbt Transformationを実装すると、dbtの開発作業も不要で、実務に使えるデータがすぐに出来ます。
もちろんdbt packageの内容だけで全て賄えるとは思いませんが、Fivetranでロード後のデータ変換の開発時に参考になるdbt packageがあるのは、メリットであると言えるのではないでしょうか。
Snowflakeとは
次にSnowflakeの説明ですが、Snowflakeを一言で言うならば、クラウドのメリットを最大限活かしたデータウェアハウスです。
大きく、４つの特徴があると考えています。
コンピューティングとストレージの分離
まず1つ目の強み「コンピューティングとストレージの分離」についてです。
こちらについては下図のスライドの右下の図を見ていただきたいのですが、 操作対象とするデータベースは１つなのですが、コンピュートリソースは用途に応じて複数に分けて使うことが出来ます。 これにより、リソースの取り合いがなくなり、用途ごとに最適なスペックのコンピュートリソースを使用する事ができます。
具体的に用途を分けるパターンとしては、重い処理が必要な機械学習用途にはスペックが高いコンピュートリソース1つを使用して、軽めのクエリが多数発行されるBIツール用途には中間スペックのウェアハウスをオートスケーリングの設定を適用した上で1台～4台適用させる、ということが想定されます。
Snowflakeならば、GUI操作でもSQLでも、このコンピュートリソース周りの操作をとても簡単に設定することが可能です。
ちなみに、この右下の図では、コンピュートリソースのスペックをMやXLなどで表現していますが、実際にユーザーが設定する際もこの服のサイズを使用します。「Sで遅ければMにすればいい」みたいに直感的でわかりやすく、面白いなー、と私は感じています。
クローン・タイムトラベルなどの独自機能
次に2つ目、「クローン・タイムトラベルなどの独自機能」についてです。
まずクローンですが、既存のデータをコピーすることなく複製出来る機能です。 こう聞くと、データベースのビューと同じ物を想像するかもしれませんが、クローン先とクローン元それぞれへ違う更新処理が可能です。違う更新処理が行われた場合、それぞれの差分だけを新しく作成し、保持します。
もう一つ、タイムトラベルですが、設定に応じて最大で90日間、過去のデータに遡れる機能です。 クエリ一つで以前のデータを復元可能なので、万が一のトラブルにもすぐに対応可能です。
そして、このクローンやタイムトラベルといった機能を実現できるのも、Snowflakeは差分が発生する度に、一定の粒度で不変なデータを新規作成して保持するアーキテクチャをしているからです。
具体的には、マイクロパーティションという形でデータを保持しています。マイクローパーティションについては下記リンク先のブログにわかりやすくまとめられていますので、ぜひ御覧ください。
マルチクラウド対応
続いて3つ目の強み、「マルチクラウド対応」です。
Snowflakeの特徴として、AWS・GoogleCloud・Azure、どのクラウドプラットフォーム上でもSnowflakeは動作できます。
これによるメリットを2つ、説明します。
1つ目は、S3・GCS・Blob Storage、どこからでも容易にロード可能である、ということです。
DWHにデータをロードする際は、事前にS3やGCSなどのストレージサービスにデータを置くことが多いと思います。 例えばBigQueryだと、BigQueryOmniなどオプション的なサービスを使わないとAWSのS3やAzureのBlob Storageのデータを参照できません。
しかし、Snowflakeだと、特に追加オプションは不要で、AWS・GoogleCloud・Azure、全てのストレージサービスに対応しています。どのクラウドを使っていても、柔軟に対応できるのが魅力ですね。
2つ目のメリットは、違うクラウドプラットフォーム間のレプリケーションが容易に可能である、ということです。
事前にSnowflakeのアカウントを各クラウドプラットフォーム上に作成しておけば、SQLコマンドをいくつか実行するだけで、クラウドプラットフォーム間のレプリケーションが可能です。 具体的には、AWS Tokyoリージョンにあるデータベースを、AzureのアメリカにあるEastUs2というリージョンに、すぐにレプリケーション出来ます。
マルチクラウドに対応していることで、どのプラットフォームでも柔軟に対応できるのが、Snowflakeの魅力ですね。
外部へのデータシェアリング
最後に4つ目の強み、「外部へのデータシェアリング」です。
これは、データの移動・コピー・ETL処理を不要で、外部のユーザーに対して最新のデータを共有することができる、という機能です。 最近だとRedshiftやBigQueryでもデータ共有できるようになってきましたが、RedshiftだとRA3ノードタイプのみ、BigQueryだAnalytics Hubという機能が該当すると思いますが2022年6月9日時点はまだプレビュー版、ということで制約があったりします。 そのため、データシェアリングはSnowflakeが先駆者の機能でもあります。
また、Snowflakeのデータシェアリングの特徴として、共有先がSnowflakeのアカウントを持っていなくても、リーダーアカウントという読み取り専用のアカウントを設定することで共有可能です。 アカウントを発行すればインターネットブラウザからデータを参照できるので、誰にでもデータを簡単に共有できる機能となっています。
dbt×Snowflakeの強み
上述したFivetranとdbtを組み合わせた時の強みとしては、「Snowflake用のdbt package」「dbtからSnowflakeの各種設定変更」があります。
まず1つ目「Snowflake用のdbt package」についてです。
Fivetranについても専用のdbt packageのお話をしましたが、Snowflakeにも専用のdbt packageがいくつかあります。
具体的には、Snowflakeのデータマスキングの処理をdbtから行えるmacroを持つpackageや、クローンの制御をdbtから行うためのmacroや、Snowflakeのデータロード履歴やクエリ履歴をより使いやすい形に加工するmodelを持つpackageなどが用意されています。
これがなぜ強みと言えるのかというと、他のDWHでは、Redshift専用のdbt packageはなく、BigQuery専用のdbt packageも自分が2022年6月9日時点で確認したところではBQMLに関するpackage１つしかなかったためです。 それだけ、dbtとSnowflakeを組み合わせるパターンが賑わっている、ということの裏付けとも言えると思います。
この登壇では、Snowflakeのダイナミックデーマスキングをdbtから実装できる、dbt_snow_maskについてお話しました。
こちらについては、手前味噌ながら私も検証ブログを執筆しておりますので、こちらも併せて御覧ください。
2つ目は「dbtからSnowflakeの各種設定変更」ができる、ことです。
これはどういうことかといいますと、SnowflakeはSQLでほぼ全ての操作を完結出来るため、dbtのhookなどの機能を使って任意のSQLを発行できるdbtから、Snowflakeに対する様々な設定を変更できる、ということです。
具体的にSQLで設定できるSnowflakeの機能としては、 コンピュートリソースのスペック変更、先程Snowflakeの強みとして触れたタイムトラベル、クローン、データシェアリング、dbt packageで触れた行レベル・列レベルのセキュリティ、などがあります。
この登壇では、「dbt project上のフォルダやmodelごとに、使用するウェアハウスの設定を変更する」方法について簡単に説明をしました。
dbtでデータ変換処理を開発していく中で、あるフォルダ中のmodelで使用するウェアハウスを変える、あるmodelだけウェアハウスのサイズが大きくないと処理が重くなってしまう、といったケースは起こりうると思います。 そんなときには、dbtのmodel実行前後に指定したクエリを実行できるhookの機能を使い、使用するウェアハウスのサイズを変更することができます。
こういった形で、dbtからSnowflakeのコンピュートリソースにあたるウェアハウスの設定を簡単に切り換えることができます。これはdbtとSnowflakeを組み合わせたときの強みだと、私は感じています。
dbtからSnowflakeのウェアハウスを変更するところについては、最近私も2本ブログを書いていますので、ぜひこちらも御覧ください。
dbtとSnowflakeの組み合わせのまとめとなりますが、Snowflakeは柔軟なアーキテクチャかつ多様な機能をもち、ほぼ全ての操作をSQLで操作可能です。 一方でdbtは、Snowflakeだけでは難しい、クエリのバージョン管理や環境の分離、データリネージやテストなどの独自機能があり、Snowflake専用のpackageも備わっています。
そのため、dbtとSnowflakeを組み合わせることで、コンピュートリソースの管理やデータ変換の開発のプロセス設計など、人的リソースが必要となるところの負荷を減らすことが出来ます。
これが、Snowflake×dbtの強みです。
まとめ
今日の発表では、dbtとFivetran、dbtとSnowflake、と2製品の組み合わせを中心に説明しましたが、 dbtとFivetranとSnowflake、3製品を組み合わせた事例は多くあります。
このスライドでは3つの例を載せています。
一番左はAulaという教育関係のプラットフォームを運営する企業の、データ基盤のアーキテクチャです。 具体亭には、S3上のデータや顧客のフィードバックを得るためのAlchemer（アルケマー）というサービスのデータをFivetranで収集しSnowflakeに入れ、dbtでデータを加工し、MetabaseやJupyterで活用する、ということを行っているようです。
中央は、ご存知の方も多いかもしれない、GitLabというGitリポジトリをホスティング出来るサービスを運営する企業の、データ基盤のアーキテクチャです。 具体的には、SalesforceやMarketo、GoogleAnalyticsのデータをFivetranで収集しSnowflakeに入れ、dbtでデータを加工し、Sisenseでダッシュボードを構築するだけでなく、dbtで加工したデータをMarketoやSalesforceにReverseETL、ということもやっているようです。
一番右は、Snowflake社の記事の引用ですが、マーケティング関係のデータを扱うための基盤の事例として、Fivetran、dbt、Snowflakeの組み合わせを紹介しています。
このように、海外ではよく使われている組み合わせであることがわかると思います。
dbtとFivetranを組み合わせると、Fivetran➟dbtの連携はGUIベースで簡単に実現可能であり、Fivetran用のdbt packageがあれば、開発作業不要でデータのロード～実務に使えるデータ作成がすぐに可能です。
dbtとSnowflakeを組み合わせると、Snowflakeはほぼ全ての操作をSQLで操作できるため、dbtから様々な設定が出来る上、Snowflakeの柔軟なアーキテクチャを活かせるため、コンピュートリソースの管理などに悩むことはなくなります。
そして、dbtとFivetranとSnowflake、この3つが組み合わさると、データ基盤整備の開発や運用の負荷を減らし、データ基盤を構築する目的である「データ活用」により、専念できるようになります！
質疑応答
以下、ウェビナー中に口頭で回答した内容も含め、全ての質問への回答を記載しておりますので、御覧ください。
dbt素敵だと思うんですが、今やってる前処理が全部SQLで書けるのかが不安です。SQLだとできないorできても超複雑で、pythonでやった方がシンプルなようなものって、あったりしないでしょうか？ もしあるなら、dbt使う状況では、どのように扱えばよいのでしょうか？
現時点では、dbtはSQLのみ対応しております。もし、Pythonでないと実現できない処理があり、Pythonとdbtを組み合わせて使う場合には、Airflowなどのワークフロー管理ツールを別途用意して、dbtの処理とPythonの処理を1つのワークフロー上で管理する必要が出てくると思います。
また、まだ私も試せていないのですが、dbt上でPythonを記述したmodelを実行する、という動きも出てきているようです。こちらのDiscussionも参考になると幸いです。
fivetran×dbtでELTを実現するとき、データソースからロードしたデータを、そのままの状態（source層？）と、型修正や日時補正とかした状態（Interface層？）を設けることがあると思うのですが、ここの変換って、どちらでやるものでしょうか？ やはりdbtでしょうか？
Fivetranでは基本的に型修正などが出来ないため、dbt側で行う処理になります。
Fivetranでロードしたデータを少しだけ型修正する層、ということで、質問文にもありますInterface層や、Staging層、といった層にあたるレイヤーで実装するのが良いと思います。
例えばSalesforceではカスタムテーブルやカスタムカラムを自由に作れますが、それらもFivetranでER図として表示され、dbt packageを使ってもデータ取得されるのでしょうか？
まず、ER図についてはどのサービスについても固定のスライドがFivetranのドキュメント上に記載のあるだけです。そのため、カスタムテーブルやカスタムカラムには対応をしておりません。
加えてdbt packageは、Fivetranにより同期される標準のテーブルを用いたmodelが実装されています。そのため、カスタムテーブルやカスタムカラムを用いたデータ加工については、別途ユーザー側でdbt上で新しくmodelの開発を行った上で、dbt Transformationにそのmodelを指定する必要があります。
例えば Redshift のような DWH ではプライマリキー制約をかけられないため、前段の処理で慎重にチェックする必要があって運用上のつらさを感じています。fivetran x dbt はそのような問題へのソリューションになり得ますか？
dbtのtest機能が使えると思います。dbtで実施できる2種類のテストの内「Schema test」という方法で、dbtにより生成されるテーブルの各カラムに対して、yamlファイル上にtestsパラメータの記述をすれば対応可能です。
dbtのtestについては弊社でも記事を書いておりますので、こちらもぜひ併せて御覧ください。
ウェビナーを終えて
dbt・Fivetran・Snowflakeを組み合わせた時に出来ることと強みについて、本ウェビナーでご紹介をさせて頂きました。
発表の最後にも少し触れましたが、データ基盤は、データ活用のための1つの手段です。※データ活用も、実際はビジネスを促進するための手段とも言えますが…
そのため、データ基盤にかけるリソースを減らせるに越したことはないと、私は考えています。データ基盤にかけるリソースが不要というわけではなく、減らすことが出来るリソースは減らしていこう、という考えですね。
もちろん、今回ご紹介しましたSaaSを導入してデータ基盤の問題を全て解決！といえるものではないのですが、要件によっては手間がかかっている処理の開発・運用の負荷を大幅に下げることが出来ると思います。
dbtは無償版が、FivetranやSnowflakeはトライアルが、それぞれ用意されていますので、ぜひ一度試して頂けると嬉しいです。
11
