オープンなプラットフォーム、統合されたパイプライン：Databricks 上の dbt が加速する理由

dbt はデータ変換ワークフローに構造をもたらします。チームはこれを使用して、BI ダッシュボード、AI/ML モデル、部門横断的なレポートなどの下流の消費を強化するキュレーション済みデータセットに生データを変換します。

しかし、現実には、dbt はそれが実行されるデータプラットフォームと同じくらい強力であるということです。

ほとんどのデータスタックでは、ストレージ、コンピューティング、ガバナンス、オーケストレーション、監視を複数のシステムにまたがって連携させる必要があります。その結果はどうなるでしょうか？データの重複、権限の一貫性のなさ、オブザーバビリティの断片化、そしてパートタイムの仕事になるパフォーマンスチューニング。だからこそ、ますます多くのチームが dbt ワークフローを Databricks に統合しているのです。

dbt を効果的に実行するには、プラットフォームには 4 つの要素が必要です。

1. オープンな基盤 dbt ワークフローがプロプライエタリなスタックにロックされないようにするため
2. シームレスなオーケストレーション dbt パイプラインを 1 か所でエンドツーエンドで実行するため
3. 組み込みのガバナンス デフォルトの dbt ワークフローの一部であること
4. 強力な価格性能 dbt が手動チューニングなしで最初から高速に実行されるようにするため

Databricks は、これら 4 つのすべてを 1 つのプラットフォームでネイティブに統合して提供します。Databricks 上で dbt を実行すると、オープン性、ガバナンス、パフォーマンス、運用上のシンプルさを最初から念頭に置いて設計されたレイクハウス アーキテクチャ上に dbt 開発者エクスペリエンスが得られます。これらが実際にどのように機能するかを見てみましょう。

Databricks 上で dbt を実行したことで、散在していたノートブックと 7 つ以上のソースシステムのレガシーを、単一の管理されたデータプラットフォームに統合することができました。Unity Catalog を使用すると、カタログレベルの分離を通じて 341 のテナント、複数の環境、および外部パートナーのデータ共有を管理できます。dbt ドキュメントは UC に直接フローするため、アナリストはボトルネックなしでセルフサービスできます。オープンフォーマットと Delta Sharing に公開することで、パートナーや下流チームは、ツールや環境全体で dbt で生成されたデータセットを簡単に消費できます。構築のための 1 つのプラットフォームですが、消費のためのオープンなプラットフォームです。 —Sohan Chatterjee, Head of Data and Analytics, iSolved

ベンダーロックインなしでオープンな基盤上で dbt を実行する

ベンダーロックインは、組織のデータ戦略にとって最も重大な戦略的リスクの 1 つです。dbt はオープンアダプターフレームワークで構築されており、変換ロジックが単一のプラットフォームにロックされないことを意味します。dbt は設計上オープンであり、Databricks はそれを実行するためのオープンなプラットフォームを提供します。多くの最新のデータスタックは、短期的な利便性を提供するプロプライエタリなストレージレイヤーを中心に構築されていますが、長期的な摩擦を生み出します。時間の経過とともに、これはさまざまなコンシューマーに対応するためのデータの重複とエクスポートパイプライン、相互運用性を制限するストレージフォーマット、およびプラットフォーム要件の進化に伴うスイッチングコストのエスカレーションにつながります。

Databricks はオープンレイクハウスです。データがオープンテーブルフォーマットで存在し、オープンインターフェイスを通じてアクセスできる統合プラットフォームであり、ストレージとガバナンスが単一のクエリエンジンに依存しないことを保証します。Databricks では、dbt モデルはオープンフォーマットのテーブルになり、Delta Lake およびApache Iceberg になり、変換されたデータがエクスポートや並列コピーの維持なしにデータランドスケープ全体でアクセス可能であることを保証します。このオープン性は、特に dbt ワークフローにとって重要です。慎重にモデリングされたシルバーおよびゴールドテーブルは、dbt が実行されるプラットフォームだけでなく、あらゆるクエリエンジンを通じて下流ユーザーが消費できる再利用可能なデータプロダクトになります。

このオープン性はストレージを超えて拡張されます。Unity Catalog は、外部エンジンからのガバナンスされた読み書きをサポートするオープンカタログおよびアクセス標準を中心に構築されています。Databricks SQL は ANSI 標準に準拠しており、クエリがプラットフォーム間でポータブルであり、ベンダー固有の書き換えを削減することを保証します。つまり、dbt ワークフローはロックインではなくポータビリティのために設計されたスタックで実行されます。

Lakeflow Jobs で dbt パイプラインをエンドツーエンドでオーケストレーションする

オーケストレーションは、運用上の複雑さが蓄積される場所です。dbt と Databricks に加えて外部オーケストレーターをペアリングすることは、2 つのシステムを運用し、2 つのデバッグ場所があり、それらの間の不確かな連携を意味します。

Lakeflow Jobs は、dbt を統合パイプライン内のファーストクラスのタスクタイプ として扱うことで、その複雑さを解消します。個別のオーケストレーションレイヤーを維持する代わりに、チームは単一のワークフローで、アップストリームの取り込みやダウンストリームのアクションと共に dbt を実行します。たとえば、Auto Loader を使用して生データを取り込み、dbt モデルでデータを変換し、ダッシュボードの更新や ML 再トレーニングをトリガーすることができます。これらすべてを単一のパイプラインで、統合された再試行ロジックと依存関係管理を使用して実行できます。Databricks 上の dbt は、ストリーミングテーブル を介した直接の取り込みも可能にします。dbt Platform ユーザーの場合、dbt Platform タスク (ベータ版) により、Lakeflow は dbt Platform で実行されている dbt ワークフローをトリガーおよび管理できます。

Lakeflow を介して dbt がオーケストレーションされると、障害、再試行、およびコンテキストが 1 か所で可視化されます。個別の dbt オーケストレーターと Databricks ログを切り替える代わりに、同じジョブ実行ビューで障害、影響を受ける下流タスク、および影響を受けるダッシュボードを確認できます。

ガバナンスをデフォルトの dbt ワークフローの一部にする

dbt ワークフローがスケーリングするにつれて、ガバナンスがボトルネックになります。チームは、テーブルの内容、所有権、およびアクセス権に関する明確な回答を必要とします。従来のスタックでは、このコンテキストは、個別のカタログツール、権限システム、およびエンドツーエンドで接続されない不完全なリネージビューに断片化されています。

Databricks は、Unity Catalog を使用してこれを解決します。これは、dbt 内だけでなく、取り込み、BI、ML/AI など全体にわたる、レイクハウス全体のアクセス制御、検出、およびリネージを統合します。Unity Catalog を使用すると、dbt がテーブルを再作成するたびに付与ステートメントを再実行する必要がなくなります。権限はスキーマレベルで管理され、テーブルの再構築全体で持続します。行レベルフィルター、列マスク、および属性ベースのアクセス制御 のようなきめ細かな制御は、dbt、BI ツール、およびノートブック全体で一貫して適用されます。

たとえば、dbt の persist_docs 機能を使用して dbt ドキュメントを Unity Catalog に永続化すると、dbt で作成された列の説明とコンテキストは、データがクエリおよび消費される場所で検出可能になります。Unity Catalog は、生の取り込みから dbt 変換、下流の使用までのデータフローをトレースする列レベルのデータリネージ を提供します。ソーススキーマが変更されると、どの dbt モデルと下流アセットが影響を受けるかを即座に確認できます。このレベルの可視性は、データパイプラインが切断されたシステムにまたがる場合には不可能です。

コストガバナンスはデータガバナンスと同じくらい重要です。 クエリタグを使用すると、dbtの実行にビジネスコンテキストを添付し、 システムテーブルを介してチーム、プロジェクト、または環境ごとに支出を追跡できます。チームは、推定ではなく、実際のデータを使用して「マーケティング分析のdbtパイプラインはいくらコストがかかるのか？」という疑問に最終的に答えることができます。さらに、DBSQLのきめ細かなコスト監視（プライベートプレビュー中）は、すべてのdbtワークロードにわたる集計コスト監視も提供します。

初日から強力な価格性能でdbtを実行

データウェアハウスのパフォーマンスを最適化するには、通常、継続的な手作業が必要です。チームは開発者の速度とパフォーマンスの衛生状態をトレードオフすることがよくあります。

Databricksは、高性能な実行エンジンとdbtとネイティブに連携する機能を組み合わせることで、この複雑さを抽象化し、手作業のオーバーヘッドなしで速度の向上を提供します。

組み込みパフォーマンス

• Photonエンジンは、ベクトル化された実行によりSQLワークロードを高速化し、クラウドデータウェアハウスと比較して最大12倍の価格性能を実現します。サーバーレスSQLウェアハウスにはデフォルトでPhotonが含まれているため、チームは追加コストなしで高速なパフォーマンスを得られます。
• Predictive Optimizationは、AIを使用してテーブルを監視し、メンテナンスを自動化することで、最大20倍の高速クエリを実現します。これにより、dbtエンジニアが歴史的に依存していた手動のOPTIMIZE post-hookの必要性が軽減されます。

dbt configを通じてロック解除されたパフォーマンス機能

• データボリュームの増加に合わせて動的に調整される柔軟なアプローチで、厳密なパーティショニング戦略を置き換えるLiquid Clusteringとのdbtの統合。これにより、手動チューニングなしで最大 10倍の高速化が実現します。
• dbtのマテリアライズドビューは、オープンソースのSpark Declarative Pipelinesによって強化されており、増分処理を自動的に処理します。Databricksは、更新が必要なものを判断する複雑さを管理し、データセット全体を再計算するのではなく、新しく変更されたレコードのみを処理します。これにより、非効率的なスケジュール済みバッチリフレッシュと比較して、コンピューティングコストが削減されます。

これらの機能により、ユーザーはチューニングに費やす時間を減らし、データセットが増加してもパフォーマンスを維持するパイプラインの構築により多くの時間を費やすことができます。2025年だけで、Databricks SQLは、追加の構成を必要とせずに、ETLワークロード（書き込みを伴うクエリ）で10％のパフォーマンス向上を達成しました。

今日から始めましょう

Databricksは、オープンストレージ、統合ガバナンス、強力な価格性能、統合運用をdbtワークフローのために1か所にまとめます。すでにDatabricksでdbtを実行している2900以上の顧客に参加してください。クイックスタートガイドに従って開始してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事