📚 関連書籍

『Databricks──ゼロから触ってわかった！Databricks非公式ガイド（2026年更新版）』

クラウド時代の分析基盤を “体験的” に学べるベストセラー入門書。
Databricksの操作、SQL／DataFrame、Delta Lakeの基本、ノートブック操作、SDP（宣言型パイプライン）
Serverless、Genieなどを初心者でも迷わず進められる構成で解説しています。
https://amzn.to/4uIqEj4

『ゼロから触ってわかった！ Snowflake × Databricks次世代データ基盤PoC実践 非公式ガイド』

本書を読み終えたとき、「POCって何から始めればよいのか」が明確になり、「自分たちにもできる」という確信を持てることを目指しています。
https://amzn.to/43qI0oR

『ゼロから触ってわかった！ Snowflake × Databricksでつくる次世代データ基盤 - 比較・共存・連携 非公式ガイド』

SnowflakeとDatabricks――二つのクラウドデータ基盤は、これまで「どちらを選ぶか」で語られることが多くありました。本書は、両プラットフォームをゼロから触り、構築・運用してきた実体験をもとに、比較・共存・連携のリアルを丁寧に解説する“非公式ガイド”です。
https://amzn.to/4efDkIk

Snowflake

ゼロから触ってわかった！Snowflake非公式ガイド ― 基礎から理解するアーキテクチャとCortexによる次世代AI基盤

初めてSnowflakeに触れる方には「最初の一冊」として。
なんとなく使っているけれどモヤモヤしている方には「頭の中を整理する一冊」として。
AI時代のエンジニアを目指すための、確かな燃料となる一冊です。
https://amzn.to/4x1VvZm

開発エコシステムdbtはもう不要？Snowflake Dynamic TablesとSQLMesh on Databricksの台頭がもたらす影響

1. なぜ今「dbtはもう不要？」と言われるのか ⚡

モダンデータスタックにおいて、dbtはSQLによるデータ変換をソフトウェア開発のように管理する仕組みとして広く普及しました。

dbtを使うことで、データエンジニアやアナリティクスエンジニアは次のような機能を利用できます。

• SQLモデルの依存関係管理
• テストの自動化
• ドキュメント生成
• Gitによるバージョン管理
• 開発環境と本番環境の分離
• インクリメンタル更新
• CI/CDとの連携

これまでSnowflakeやDatabricksは、主にSQLを実行するデータプラットフォームでした。

その上にdbtを配置し、変換ロジックや依存関係を管理する構成が定番だったのです。

しかし現在は状況が変わり始めています。

SnowflakeではDynamic Tablesが登場し、SQLで完成形を定義するだけで、依存関係や更新タイミングをプラットフォーム側が管理できるようになりました。

Databricksでも、Databricks SQL、Lakeflow、ストリーミングテーブル、マテリアライズドビューなど、宣言的なパイプラインを構築する機能が強化されています。

さらに、独立したOSSであるSQLMeshをDatabricksへ接続すれば、SQLモデルの変更計画、仮想環境、差分評価などを管理できます。

こうした機能を見ると、「変換処理を管理するためだけに、dbtを別途導入する必要はないのでは？」という疑問が出てくるのは自然です。

ただし、結論を先に言えば、プラットフォームネイティブ機能が増えたからといって、dbtの役割がそのまま消えるわけではありません。

変わり始めているのは、dbtを使うか使わないかではなく、どの責務をdbtに持たせるかです。

2. Snowflake Dynamic Tablesが変えるパイプライン開発 ❄️

Snowflake Dynamic Tablesは、変換後のテーブルをどのような状態にしたいかをSQLで宣言し、その状態をSnowflakeが自動的に維持する仕組みです。

開発者は、従来のように細かな実行スケジュールを一つずつ設計するのではなく、データに求める鮮度を指定します。

例えば、売上集計テーブルを元データから最大10分以内の遅延に保ちたい場合、ターゲットラグを設定します。

その後の更新タイミングや依存関係は、Snowflake側が管理します。

この仕組みには、次のようなメリットがあります。

• TaskやStreamを細かく組み合わせる必要が減る
• パイプラインの依存関係をSnowflake側で管理できる
• 対応可能な処理では増分更新を利用できる
• バッチと準リアルタイム処理を統一的に考えられる
• SQL中心のチームでも運用しやすい

従来は、変換処理の順序を考えながら複数のTaskを作成し、失敗時の再実行や依存関係を設計する必要がありました。

Dynamic Tablesでは、「いつ実行するか」よりも「どの程度新しい状態を維持するか」を中心に設計できます。

これは、命令型のパイプラインから宣言型のパイプラインへの変化です✨

一方で注意も必要です。

Dynamic TablesはSnowflake内部で完結する変換には強いものの、複数プラットフォームを横断する開発標準を提供するものではありません。

また、すべてのSQL処理が同じように効率的な増分更新へ変換されるわけではありません。

ターゲットラグを短く設定しすぎると、更新頻度が増えてコンピュートコストが上昇する可能性もあります。

つまりDynamic Tablesは、dbtの完全な代替というより、Snowflake上の更新・実行管理を大きく簡素化する機能と考える方が正確です。

3. SQLMesh on Databricksが注目される理由 🚀

SQLMeshはDatabricks固有の製品ではありません。

SQLを中心としたデータ変換プロジェクトを管理する独立系のOSSであり、Databricksを含む複数の実行エンジンへ接続できます。

SQLMeshが注目される理由の一つは、変更をすぐに本番適用するのではなく、変更による影響を計画として確認できる点です。

SQLモデルを変更した場合、どのモデルが影響を受け、どの期間のデータを再計算する必要があるのかを判断します。

主な考え方は次のとおりです。

• SQLモデルの依存関係を管理する
• 変更による影響範囲を確認する
• 仮想環境で変更を検証する
• 必要な範囲だけを再計算する
• 本番環境への反映計画を管理する

大規模なデータ基盤では、SQLを1行変更しただけでも、下流にある多数のテーブルやダッシュボードへ影響することがあります。

そのたびに全期間のデータを再計算すると、時間もDatabricksのコンピュート費用も増加します。

SQLMeshのような仕組みは、変更内容と再計算範囲を分離して考えやすくします💡

Databricksには、Databricks SQL、Workflows、Lakeflowなどのネイティブ機能があります。

そのためSQLMeshは、Databricksの実行基盤を置き換えるものではありません。

Databricksを実行エンジンとして利用しながら、SQLモデルの開発・変更・環境管理を外側から支える役割を担います。

ここはSnowflake Dynamic Tablesとの大きな違いです。

Dynamic Tablesはプラットフォーム内部のネイティブ機能です。

一方SQLMeshは、データプラットフォームの外側から開発ライフサイクルを管理するツールです。

同じ「SQLパイプラインを簡単にする技術」に見えても、担当するレイヤーは異なります。

4. dbt・Dynamic Tables・SQLMeshの違いを整理する 👀

3つの選択肢は、完全な競合関係ではありません。

それぞれが得意とする領域を整理すると、違いが見えやすくなります。

• dbt：SQL変換プロジェクト全体の標準化
• Dynamic Tables：Snowflake内部の鮮度ベース自動更新
• SQLMesh：SQLモデル変更の計画・環境・再計算管理

dbtの強みは、特定のデータプラットフォームだけに閉じない開発体験です。

SnowflakeとDatabricksを併用している企業でも、モデル、テスト、ドキュメント、CI/CDの考え方を共通化できます。

Dynamic Tablesの強みは、Snowflake内部に閉じることで得られる自動化です。

実行タイミングや依存関係をSnowflakeへ委ねられるため、運用部品を減らせます。

SQLMeshの強みは、変更影響と環境管理を中心に据えた開発モデルです。

大規模な履歴データを持つ環境では、必要なデータだけを再計算する考え方がコスト削減につながります。

したがって、比較するときは「どれが最も高機能か」ではなく、次の観点を見る必要があります。

• 単一基盤かマルチプラットフォームか
• 変換ロジックをどこで管理するか
• テストとドキュメントをどこまで共通化するか
• 再計算コストをどのように抑えるか
• ベンダーロックインを許容できるか
• 運用担当者がどのツールに習熟しているか

ツール選定は、機能比較だけでは決まりません。

組織構造や開発プロセスとの相性が重要です。

5. dbtが不要になりやすいケースと残りやすいケース 🔍

Snowflakeだけでデータ基盤が完結し、変換処理も比較的シンプルな場合は、Dynamic Tablesによってdbtの利用範囲を縮小できる可能性があります。

例えば、次のような環境です。

• データ変換がSnowflake内で完結する
• SQLモデル数がそれほど多くない
• 複雑なCI/CDを必要としない
• ドキュメントやテストを別の仕組みで補える
• データ鮮度を基準に更新したい

この場合、Dynamic Tablesを使うことで、外部オーケストレーターや大量のTaskを減らせます。

一方で、dbtが残りやすいのは次のような環境です。

• SnowflakeとDatabricksを併用している
• 開発標準を複数チームで統一したい
• テスト、ドキュメント、メタデータを一元管理したい
• Gitを中心としたレビューを徹底したい
• データプロダクト間の契約を管理したい
• 将来的な実行基盤の変更可能性を残したい

特にSnowflake × Databricksの共存環境では、プラットフォームごとのネイティブ機能だけを使うと、開発方法が分断される可能性があります。

SnowflakeチームはDynamic Tables、DatabricksチームはLakeflowやSQLMeshという状態になると、命名、テスト、リリース方法、障害対応が別々になりかねません。

dbtの価値は単なるSQL実行ではありません。

組織横断の開発ルールを作る共通言語としての価値があります。

6. Snowflake × Databricks環境での現実的な使い分け 🧩

共存環境では、すべてを一つのツールへ統一しようとしない方が現実的です。

例えば、次のような役割分担が考えられます。

• Snowflake Dynamic Tables：Snowflake内の準リアルタイム集計
• Databricks Lakeflow：大規模ETLやストリーミング処理
• Databricks SQL：SQL分析やマート作成
• SQLMesh：Databricks上のSQLモデル変更管理
• dbt：両基盤をまたぐ開発標準・テスト・ドキュメント

この構成では、プラットフォームネイティブ機能の性能と自動化を活かしつつ、dbtを共通管理層として残します。

ただし、同じ処理をdbtとネイティブ機能の両方で管理すると、責任範囲が曖昧になります。

そのため、次のルールを明確にする必要があります。

• モデル定義の正本はどこか
• 実行スケジュールを誰が管理するか
• テスト結果をどこへ集約するか
• 障害時にどのチームが対応するか
• データリネージをどこで確認するか

ツールを増やすこと自体が高度化ではありません。

責務を整理せずに複数ツールを導入すると、開発エコシステムはかえって複雑になります。

7. 開発エコシステムは「ツール中心」から「責務中心」へ ✨

これまでのデータ基盤では、「変換処理ならdbt」というように、ツールを中心に設計する傾向がありました。

しかし今後は、責務ごとに最適な機能を選ぶ考え方が重要になります。

例えば、

• データ更新：Dynamic TablesやLakeflow
• SQL開発：dbtやSQLMesh
• オーケストレーション：TasksやWorkflows
• ガバナンス：HorizonやUnity Catalog
• 品質管理：dbt testsやパイプラインの品質ルール
• セマンティック管理：各プラットフォームのメトリクス機能

という分担です。

プラットフォーム側が高機能になるほど、外部ツールが完全に不要になるように見えます。

しかし実際には、ネイティブ機能が増えるほど、どの責務をどこへ配置するかというアーキテクチャ設計が重要になります。

dbtが生き残るかどうかを決めるのは、SQL変換機能の数ではありません。

組織横断で利用できる開発標準、レビュー、テスト、ドキュメント、メタデータ管理に、どれだけ価値を提供できるかです。

8. まとめると ✨

Snowflake Dynamic TablesやDatabricksのネイティブデータエンジニアリング機能、そしてSQLMeshの台頭によって、dbtだけがSQL変換を管理する時代ではなくなりました。

Snowflake Dynamic Tablesは、Snowflake内部の依存関係とデータ鮮度をプラットフォームへ委ねられます。

SQLMeshは、Databricksなどの実行エンジンを利用しながら、SQLモデルの変更計画や環境管理を支援します。

一方dbtには、

• マルチプラットフォーム対応
• テスト
• ドキュメント
• CI/CD
• 開発ルールの標準化

という役割が残っています。

したがって、「dbtはもう不要か」という問いへの答えは、単純なYesでもNoでもありません。

単一のSnowflake環境で、鮮度ベースのSQL変換をシンプルに構築するなら、Dynamic Tablesによってdbtの役割を縮小できる可能性があります。

SnowflakeとDatabricksを横断し、複数チームの開発方法を統一するなら、dbtの価値は依然として大きいでしょう。

重要なのは、流行しているツールを並べることではありません。

更新、変換、テスト、ドキュメント、デプロイ、監視という責務を整理し、それぞれをどの機能へ持たせるかを決めることです。

dbtが消えるのではなく、dbtが担当してきた責務が、プラットフォームネイティブ機能や新しいOSSへ再配分され始めている。

これが、Snowflake Dynamic TablesとSQLMesh on Databricksの台頭がもたらす本当の変化です。