以下、データパイプラインからTransformationまでの流れを勉強する中での個人的なメモ記事です。正確な情報は各社サイト・ブログなど参照してください。また、こんなアイデアや見方あるよ等、もし違う視点があれば、ご教示いただければ嬉しいです。
FivetranのTransformations機能について
dbt CoreによるTransformations
- Fivetranはdbt Coreをホストしており、Gitリポジトリからプロジェクトを取得し、変換（SQLモデルの実行）を自動実行可能
- dbt Coreはオープンソースの無償ツールで、自身でCLIまたはdbt Cloudでプロジェクトを開発可能
- Fivetranのダッシュボード上でジョブを作成し、スケジュールを設定。これにより、Fivetranが抽出・ロード完了のタイミングに合わせてdbt Coreによる変換を実施するELTのオーケストレーションが可能
- サポートされているデスティネーションには、Snowflakeを含む多数の主要データウェアハウス
dbt Cloudとの連携（本格的なモデル変換）
- Fivetranはdbt Cloudとのオーケストレーション連携を提供
- Fivetran UI上でdbt Cloudジョブを選び、Fivetranのコネクタ（抽出・ロードの完了）に応じて自動で変換をキック
- ダッシュボード上でジョブ選択、スケジュール設定、実行ログのモニタリングが一元化でき、本格的なチーム開発やCI/CD、Web IDEなどの利点を享受可能
- Teradataとの事例でも、Fivetran → データロード → dbt Cloudでの変換をFivetran上のスケジュール/トリガーで一連に統合して実現している例
dbt Core vs. dbt Cloud の整理（Fivetran視点）
| 項目 | dbt Core | dbt Cloud |
|---|---|---|
| 提供形態 | オープンソース、CLIでローカル実行 | 有償（＋一部機能は無料）、WebベースIDE + スケジューラーなど付き |
| 開発環境 | ローカルIDE（VS Codeなど）やGit | ブラウザ上のIDEでの開発、ジョブ管理 |
| オーケストレーション | Fivetranがスケジュール実行可能（追加費用なし） | Fivetranと連携し、抽出・ロード完了時に自動ジョブ起動可能 |
| ログ・モニタリング | Fivetranダッシュボードで表示 | 同上（むしろより詳細・統合的な管理） |
Snowflake の「dbt Projects」機能
- プレビュー（Preview）機能として2025年6月27日より提供開始
- Snowflakeでネイティブに dbt Core プロジェクトを作成・実行できる機能
- Snowsight（SnowflakeのWeb UI）内で dbt プロジェクトを作成・編集・テスト・実行・管理可能。dbt Core のプロジェクトディレクトリをSnowflake内に配置し、スキーマレベルの DBT PROJECT オブジェクトとして扱う形
- Workspaces（統合IDE）が提供されており、ファイル編集・Git連携・プロジェクトの可視化（DAG、依存関係など）が可能
- 作成された DBT PROJECT は、Snowflakeのスキーマオブジェクトとして扱われ、バージョン管理やRBACによるアクセス制御 が適用可能
- 実行は、SQLコマンド（EXECUTE DBT PROJECT） や Snowflake CLI（snow dbt execute／snow dbt deploy） によって実施
- スケジューリング・オーケストレーションは Snowflake Tasks で管理可能
- モニタリングは Snowsight上の専用ダッシュボードや、Snowflakeのイベントテーブル（OpenTelemetry対応）で行える
Snowflake dbt Projects と Fivetran Transformations（dbt Core）の主な違い
| 比較項目 | Snowflake：dbt Projects | Fivetran：Transformations for dbt Core |
|---|---|---|
| 実行場所・環境 | Snowflake内（Workspaces ⭢ DBT PROJECT オブジェクト） |
Fivetran上（変換ステップとしてGit管理されたdbt Coreプロジェクトを呼び出す形） |
| 開発・編集環境 | Snowsight内のWeb IDE（Workspaces）＋Git連携 | 外部（ローカルIDEやdbt Cloud）で開発し、Git経由でFivetranが取得 |
| プロジェクト管理 | スキーマオブジェクト＋バージョン管理＋RBAC | Gitレポジトリで管理。Fivetranはその内容を取得して実行 |
| 実行・スケジューリング | Snowflake TasksやSQLでスケジュール可 | Fivetran側のスケジューラで、データロード完了後に変換をトリガー |
| モニタリング・ログ | Snowsight d.b.a ダッシュボード、Event Table、ログ出力あり | Fivetranダッシュボードで実行結果・ログ・成功／失敗通知が閲覧可能 |
| CI/CD・デプロイ | Snowflake CLI（snow dbt deploy）によるオブジェクト更新／バージョン管理対応 |
Gitフローでプロジェクト管理。Fivetran側に直接デプロイする仕組み |
| 対象dbtタイプ | dbt Core のみ（バージョン1.9.4など） | dbt Core（Fivetran Transformations）および dbt Cloud とも連携可能 |
| 精度・対象ユーザー層 | Snowflakeネイティブで完結させたいユーザー向け | 他クラウドやETL管理ツールとも統合して使いたいユーザー向け |
それぞれに向いているユースケース
Snowflake dbt Projects が適しているケース
- Snowflake上で ELTのさらに上流・下流を一元的に管理したい（開発・実行・監視・保守をSnowflake内で完結）。
- スキーマオブジェクト＋RBAC＋バージョン管理 の一体化された統制が求められる環境。
- Snowflake Tasks による Snowflakeネイティブなスケジューリングとオーケストレーションを重視する場合。
Fivetran Transformations（dbt Core）が適しているケース
- Fivetranでのデータロードと変換を一体で扱いたい場合。
- 既に dbt Cloud や CLI で開発されており、Fivetranのパイプラインに組み込みたい場合。
- 多様なデータソースへの接続やロード後の即時変換を柔軟に設定したい場合
もう一声：料理に例えた場合
以下の感じでしょうか？？
-
FivetranのTransformations = 「仕入れと下ごしらえを一緒にやってくれるスーパー」
→ 家族が喜ぶ毎日毎食の料理のために適切な食材（データ）を安全且つ安定的に集めてきて、必要に応じて包丁で切ったり味付けの下地を作ってくれる。家庭で料理（分析）をすぐに始められる。 -
Snowflakeのdbt Projects = 「自社キッチンにある本格的な調理設備」
→ 食材（データ）は既に冷蔵庫（Snowflake）にある状態で、専用の厨房設備でシェフ（データチーム）がじっくり仕込み・調理できる。お店のオペレーションの一部として統合されている。
データチーム視点の利用
目的とユースケース次第ってことは想像できたが、ここで思うのが、dbt core利用という意味では両者とも重なる部分はあり、データエンジニアやデータチーム視点では、Fivetran, Snowflake, dbt自体で変換（dbt）の実行がいろんな場所に散在していると管理が大変・煩雑ではないか？
ジョブ管理の煩雑さ
- FivetranのUIにも変換スケジュール
- SnowflakeのTasks/Projectsにもジョブ
- dbt Cloudにもスケジューラ・CI/CD
→ どこが“正”の実行元かが分かりにくくなる
権限・アクセス管理の分散
- FivetranでGit接続
- SnowflakeでRBAC管理
- dbt Cloudでユーザー・ロール管理
→ 運用ルールや権限の一貫性が保ちにくい
トラブルシューティングが難しい
- 失敗したら「Fivetran側か？Snowflake側か？dbt側か？」と切り分けが必要
- ログがツールごとに散在しており、統合ビューがない
この課題に対する整理の方向性
🔹 PoCや小規模利用
👉 Fivetran Transformationsに寄せる
- ロードと変換を一体で回せるので「早く結果を出す」には最適
- 将来スケールする場合には、徐々にSnowflake/dbt Cloudへ移行
🔹 本格的なデータ基盤運用
👉 dbt Cloudを「変換の正規の場所」として一本化
- Fivetranはロード専用にする
- Snowflakeは実行環境として活用し、オーケストレーションはAirflowやDagsterなど外部ツールに統合するケースも多い