dbt の実行処理がウェアハウスのコンピュート費用を密かに押し上げていませんか？

dbt（現在は Fivetran と同一企業）は、すべてのモデルをウェアハウス内部で実行します。これはインプレース処理の観点からは極めて理にかなったアーキテクチャです。しかし同時に、処理の非効率性が「エラー」として表面化しないという落とし穴を抱えています。過去 1 年分の履歴データを毎晩無駄に全件再計算しているモデルであっても、実行自体は正常終了（グリーン）し、その無駄なコストは月末のクラウド請求額として静かに請求されるだけです。

コンピュート費用が膨張する理由

• 全件再構築（フルリビルド）がデフォルトになりがち： table マテリアライゼーションは、実行ごとにテーブルを破棄して再作成します。増分更新（Incremental）に対応させるにはモデルごとの個別実装が必要であり、その作業はプロジェクトの初期段階では往々にして先送りされます。
• 増分ロジックが開発者ごとに属人化する： ユニークキーの指定、ルックバック期間、マージ戦略の書き方は開発者によって異なり、プロジェクト全体で品質のバラつきが生じます。
• DAG の実行範囲が必要以上に広がる： 1 つのインプットの変更が下流の多数のモデルの実行を誘発し、その多くは昨日と全く同じ結果を出力するために無駄なコンピュートを消費します。
• 誰もコストプロファイリングを行わない： パイプラインが成功すればタスク完了とみなされ、モデルごとのコンピュート消費量はウェアハウスの管理画面に埋もれたままになります。

これは dbt ツールの欠陥ではありません。手書きの変換ロジックの効率性は、それを書いたエンジニアがどれだけパフォーマンスチューニングに時間を割けたかに依存しているからです。

パフォーマンス効率が本来属するべき場所

• 差分ロードを唯一の標準とする： ロードパターンがモデルから自動生成されるのであれば、増分更新は納期と相談しながら書くオプションではなく、すべてのロード処理における絶対的なデフォルトとなります。
• 履歴管理を単一の場所に隔離する： 変更履歴は Satellite 内で時系列に管理されるため、データマート層が「現在の数値」を算出するために過去の履歴全体を再集計する必要はなくなります。
• ターゲットエンジンに最適化されたセットベース SQL： 開発者がモデルごとに手作業で SQL をチューニングするのではなく、プラットフォームが対象エンジンに合わせて極限まで最適化されたネイティブ SQL を一貫して生成します。

Datavault Builder による変革

Datavault Builder は、ターゲットエンジン向けに最適化された Hub、Link、Satellite のためのセットベース差分ロードを自動生成し、パイプラインの最もコンピュートを消費する部分が「変更されたデータのみ」を処理するように徹底します。

• 構造的にすべてのロードが差分処理： すでに履歴保持されているデータと照合し、新規および変更された行のみを検出して処理します。テーブルを破棄して全件再作成することは一切ありません。
• 履歴は Satellite に蓄積： 過去時点の問い合わせ（as-was）には、蓄積された変更データから直接回答できるため、毎晩過去全体を再計算する必要はありません。バイテンポラル（二重時間軸）ロードや Point-in-Time（PIT）テーブルも、マクロを手作りすることなく標準パターンとして利用できます。
• 実行範囲はモデルの依存関係に連動： 依存関係がモデルから導出されるため、変更があった箇所とその直近の影響範囲のみがロードされ、無関係な下流モデルが無駄に再実行されることはありません。
• dbt との併用時も効果を発揮： dbt での運用を継続する場合でも、Datavault Builder が生成した dbt モデルを活用でき、dbt State によるスキップ機能の恩恵を受けられます。さらにその下流の Vault 層は最初から差分処理のみを行っているため、二重の最適化が働きます。
• 予測可能なコンピュートコスト： ロード費用はウェアハウス全体の総容量ではなく、ソースデータの「変更量」にのみ比例するため、コストの推移を正確に予測・監視できます。

今すぐ判断すべきこと

過去 1 ヶ月のウェアハウスのクエリ実行履歴から、最もコンピュート費用を消費した上位 10 個のモデルを抽出してみてください。もしそれらの大半が、全件再構築されているステージングモデルや履歴計算モデルであるなら、それこそがモデル駆動型の自動生成レイヤーへ移行すべき決定的な証拠です。