[登壇レポート]dbt Cloudの新機能を紹介!データエンジニアリングの民主化:GUIで操作、SQLで管理する新時代のdbt Cloud

[登壇レポート]dbt Cloudの新機能を紹介!データエンジニアリングの民主化:GUIで操作、SQLで管理する新時代のdbt Cloud

Clock Icon2025.06.13

さがらです。

2025年6月5日に弊社主催のウェビナー「dbt Cloudの新機能を紹介!データエンジニアリングの民主化:GUIで操作、SQLで管理する新時代のdbt Cloud」が開催されました。

https://events.classmethod.jp/seminar/250605-dbt-cloud-webinar/

このウェビナーで新機能紹介とデモンストレーションを行いましたので、本記事では登壇資料・質疑応答・登壇を終えての所感についてまとめます。

登壇資料

質疑応答

select * from ( ref(XXX))で書いた場合、実際にはビュー参照する形でしょうか?それとも物理コピーされるのでしょうか?

各Modelごとに、Materializationを指定でき、ビューとして生成することも出来ますし、テーブルとして生成することも可能です。

https://docs.getdbt.com/docs/build/materializations

SELECT INSERTのような書き方もできる?

基本的にはSELECT文で書いたものが、CTASなどのクエリに変換されて接続先のDWH/DBに反映される形となります。

INSERTやDELETEなどについては、hookやmacroを用いることで実装は可能です。

https://docs.getdbt.com/reference/resource-configs/pre-hook-post-hook

https://docs.getdbt.com/docs/build/jinja-macros

Canvas機能はどのプランで使えますか?

新プランのEnterprise以上でご利用可能です。

旧プランの契約のお客様は、2025年8月末までしかご利用ができなくなります。継続してご利用する場合は、新プランへのお切り替えが必要になります。(※変更になる可能性もあるため、現時点での回答となることをご承知おきください。)

https://www.getdbt.com/pricing

現在Databricksを利用しておりdbtの導入を検討しております。dbt Coreとdbt Cloudのうちどちらを採用するか、もしくはdbtを使わないか(databricksの機能で行う)の3択で悩んでおります。今回ご紹介いただいようにGUIが魅力的なのでdbt cloudがいいのかな?と思っているのですがdbt cloudを導入すべき組織の条件(技術力が高くなくてもいいなど)などあれば教えていただきたいです。

Databricksにもネイティブでデータパイプラインを実装できる機能(DLTなど)があり、dbtの処理をジョブとして実行できる機能もあるため、これらの機能で問題なく開発・運用できる場合にはdbt Cloudを必須で導入しなくても良いと思います。

一方で、dbt Cloudの良さとしては、今回のウェビナーでご紹介したCanvasはもちろん、開発前後でデータの差分がわかるAdvanced CI、プルリクエストのMerge時に自動で差分のモデルを実行できるMerge Job、などの便利な機能があるため、環境構築や開発プロセスの簡略化ができます。これにより、組織内でのdbtの開発プロセスの統制・より対象ユーザーを広げた開発が可能となります。こういったニーズがある場合には、dbt Cloudが刺さると思います。

Snowflakeではエイリアスに日本語を記述できますが、dbtでも記述して実行することは可能でしょうか?

Snowflakeで実行できるSELECT文ならばエイリアスに日本語があっても問題ないため、可能です。

Canvasでサブクエリーは別ノードになるのでしょうか?

サブクエリの内容にもよりますが、Formulaノードなどで計算ロジックをそのノード内で定義する場合には、単一ノードとなります。

Semantic layerの定義はコードベースのままでしょうか?

現状は、Semantic Layerの定義はコードベースでのみ可能です。

テストの実装もCanvas上で可能ですか?

現時点では不可能なのですが、公式ブログにてDefine dbt tests and unit tests directly in Canvasと言及があるため、実装予定はあります。

Canvasで最初に取り込んだデータの定義は事前にコードで定義する必要があるのでしょうか?

現在は、「Sourceとして定義」「Modelとして定義」のいずれかの方法でコードによる定義が必要となります。

Canvasを生成AIで作成できるとのことですが、完璧でないのなら、コード自体を生成AIで作ればそれでいいのでは?とおもったのですが、そう考えると、Canvasの生成AI機能の意義って何なのでしょうか?

ご認識どおりで、dbt Cloudではコードベース編集時にもCopilotの機能を用いる事が可能です、そのため、コードが書ける方はコードの方でCopilotを用いた方が良いと思います。

Canvasの生成AI機能の意義としては、「SQLがわからないユーザーでも、Canvasでフローを作成する際のベースラインが簡単に作れる」というところになると思います。

登壇を終えて

まず、今回のイベントに申し込んで頂いた皆様、誠にありがとうございました!大変多くの方に参加いただけて、とても嬉しかったです。

今回のイベントでは、dbt Cloudの新機能である「Canvas」を中心にご紹介しました。Canvasは、従来のGUIベースのデータ変換ツールだと運用・保守が非常に難しくなる問題を、dbtならではの「ノードの処理をSQLに変換して管理できる」というアプローチで解決した機能です。

GUIベースのツールで一度でも開発・運用の経験のある方であれば尚更のこと、「SQLで管理できる」ことのありがたみを強く感じられるのではないでしょうか。昨今は生成AIの技術が革新的に進化をしており、SQLで管理することでそのSQLの内容をすぐに生成AIに解説してもらうことも可能になってきているため、「コードで管理できる」ことの重要性が更に高まっております。

「GUIで操作、SQLで管理する」ことができるCanvasが気になった方は、dbt Cloudはトライアルも可能ですのでぜひ弊社までご連絡ください!

https://classmethod.jp/partner/dbt/

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.