Databricksでdbtを最大限に活用する方法

何万もの組織がデータ変換に dbtを利用しています。どこで実行するかによって、dbt パイプラインの実行コスト、開発速度、運用作業の負担など、すべてが左右されます。Databricks 上で dbt を実行することで、dbt ワークロードに オープンなプラットフォームと統合されたパイプラインを提供できます。

3,000 以上の組織が Databricks 上で dbt を実行しており、ほとんどのチームがさらに多くの成果を引き出すことができます。このブログでは、Databricks 上で dbt パイプラインをより安く、速く、かつシンプルに運用するためのプラクティスを紹介します。

dbt パイプラインをより安く、より速くする

dbt の利用料金が増加する主な原因は、繰り返す必要のない作業にあります。フルリビルド（全件再構築）は変更のないデータを再計算し、クエリの高速化維持には手動チューニングが必要で、コストが急増した際もどの dbt モデルが原因なのか明確に特定できません。このセクションのプラクティスを導入することで、パイプラインは次のように改善されます：

• 実際に変更されたデータのみを再構築
• パーティションキーの選定や付け直しをすることなく高速性を維持
• post-hooks なしでテーブルメンテナンスを自動実行
• すべてのコストを特定のモデルまで追跡

1. 増分戦略で変更されたデータのみを構築

テーブル全体のフルリビルドは、ほとんどの dbt プロジェクトにおいて回避可能な最大のコストです。実行間に少量のデータしか変更されない場合、テーブル全体を再計算するとコンピュートリソースが無駄になり、料金が増加します。 dbt の増分戦略（incremental strategies）は、すべて dbt-databricks でサポートされており、各モデルが新しいデータのみを処理できるようになります。最適な選択肢は、データが実際にどのように届くかによって決まります。

ほとんどのプロジェクトでは、より限定的な戦略で十分な場合でも、デフォルトで merge を使用しがちです。述語（predicate）で変更データを指定できる場合、replace_where は一致箇所を見つけるためにターゲットをスキャンする必要がある merge よりも処理量を抑えられます。それが難しい場合でも、merge で incremental_predicates を使用することで、スキャン範囲を幅広く絞り込むことができます。

上記の戦略はすべて、各自で選択しメンテナンスし続ける必要があります。次のプラクティスでは、プラットフォームにこの処理を自動でお任せする方法を紹介します。

2. マテリアライズドビューによる増分処理の自動化

マテリアライズドビューは増分処理を自動化します。モデルを通常の SQL として定義するだけで、Databricks がどの基礎データが変更されたかを追跡し、影響を受ける結果のみをリフレッシュします。dbt-databricks では、マテリアライズドビューは ネイティブなマテリアライゼーションとして提供されるため、設定変更は 1 行で済みます：

マテリアライズドビューはサービング層（serving layer）に最適です。頻繁に変更されるソース上の集計、特にダッシュボードのバックエンドとして常に最新状態を保つ必要がある高負荷な集計に適しています。TPC-DI ベンチマークでは、サービング層でのフル再計算をマテリアライズドビューに切り替えることで、17 倍の高速化を実現しました。

3. パフォーマンスチューニングのためのデータレイアウト自動化

パーティションキーの選択、クエリパターンの変更に伴う見直し、および post-hooks での OPTIMIZE、VACUUM、ANALYZE のスケジューリングには、いずれもエンジニアリングの時間と工数がかかります。 

予測最適化（Predictive Optimization）は、管理対象テーブルで OPTIMIZE、VACUUM、および統計情報の収集を自動的に実行し、各テーブルのクエリ方法に基づいて実行内容とタイミングを選択します。カタログまたはスキーマレベルで 1 度有効にすれば、テーブル維持のために dbt プロジェクトで積み重なりがちな post-hooks を削除できます。 

データレイアウトについては、 Liquid Clustering がパーティション設計に代わり、自己調整型のレイアウトを提供します。テーブルが実際にどのようにクエリされるかに基づいてデータを整理し、過剰なパーティション分割によるスモールファイルの爆発を回避し、クエリパターンの変化に適応します。また、予測最適化を活用した 自動 Liquid Clustering (CLUSTER BY AUTO) を使用すれば、Databricks がクエリ履歴から自動的に判断・調整を行います。プロジェクトレベルの設定が 1 つあれば、プロジェクトが作成するすべての新しいテーブルがクラスタリングされます。

どちらの機能も、一度設定すれば済むように設計されています。 自動アップグレード（Automatic upgrades）により、Unity Catalog の管理対象テーブルは、Databricks から提供される新しい最適化機能を自動的に享受し続けることができます。

4. クエリタグであらゆるコストを特定

四半期の終わりに、財務部門から「なぜウェアハウスの請求額が上がったのか」と尋ねられることがあります。ほとんどの環境では、使用状況データのクエリがそれを発行した dbt モデルと紐付けられていないため、誰も答えることができません。

クエリタグ（Query tags）により、この紐付けが自動化されます。Databricks 上で dbt が実行するすべてのクエリに、モデル名、dbt バージョン、マテリアライゼーションタイプが 自動でスタンプ付与されます。組織の予算管理基準に合わせたカスタムタグを追加することも可能です：

タグは system.query.historyに表示され、 system.billing.usageと結合することで、サーバーレス ウェアハウスの支出をタグがサポートする任意のグループ（モデル別、チーム別、ドメイン別、マテリアライゼーション別のコスト）に紐付けます。どのモデルに最もコストがかかっているかを正確に把握できます。 

dbt パイプラインのシンプル化

一般的な dbt のセットアップは、データの取り込み用システム、プロジェクトを実行する外部オーケストレーター、同じメトリクスを個別に再定義する BI ツール、dbt プロジェクト外にあるガバナンスなど、さまざまなツールのスタックに依存しています。それぞれが管理対象を増やし、不一致を招く要因となります。このセクションのプラクティスを採用することで、1 つの dbt プロジェクトで以下を実現できます。

• プロジェクトにデータを直接取り込む
• 管理が必要なサードパーティ製オーケストレーターなしで、Databricks から実行・デプロイする
• ガバナンスされた 1 つのメトリクス定義をすべてのツールに提供する
• dbt モデルとともにバージョン管理された独自のガバナンスルールを運用する

1. ストリーミングテーブルにより、取り込み処理を dbt プロジェクトに集約する

取り込み処理は、従来 dbt の外部で運用されていたパイプラインの一部であり、統一されたリネージの概要が存在しない分散したアーキテクチャを引き起こしていました。 streaming_table materialization はその分断を解消します。ストリーミングテーブルとしてマテリアライズされた dbt モデルは、新しいファイルやイベントが到着するたびに増分で取得するため、取り込み処理は DAG 内の普通のモデルの 1 つになります。

そこから、パイプラインの残りの部分（シルバーモデルおよびゴールドモデル）は ref()でストリーミングテーブルを参照でき、テストやドキュメントがすべてのレイヤーに適用され、リネージは生ファイルから最終マートまでの全経路をカバーします。

2. Unity Catalog Semantics でメトリクスを標準化する

すべての BI ツール、エージェント、その他のデータコンシューマーがそれぞれ独自にメトリクスを定義すると、ステークホルダー間の混乱や認識の相違につながります。 メトリクスビュー（metric view）は定義をガバナンスされた 1 つの場所に統合します。メジャーとディメンションを一度宣言すれば、すべてのコンシューマーが同じロジックをクエリできます。

dbt-databricks は メトリクスビューをネイティブなマテリアライゼーションタイプとして提供するため、定義は dbt プロジェクト内に配置され、他のモデルと同様にバージョン管理およびレビューが行われます。 

ユーザーはクエリ実行時に MEASURE() 関数を使って独自のグループ化を選択できるため、同じ定義を SQL エディタ、BI ダッシュボード、ノートブック、Genie で利用できます。

3. Lakeflow Jobs により dbt をネイティブにオーケストレートする

dbt の実行だけでパイプライン全体が完結することはめったにありません。アップストリームとダウンストリームのステップが異なるツールにある場合、ツールの追加管理、費用、セキュリティ対策のオーバーヘッドが増え、リネージも分散してしまいます。

Lakeflow Jobs は、 dbt をネイティブタスクとして組み込み、それらを 1 つの Directed Acyclic Graph（DAG）に集約します。取り込みタスクが dbt タスクにデータを供給し、完了時にダウンストリームタスクがトリガーされ、プラットフォームによって依存関係が強制されます。スケジューリング、自動再試行、実行履歴、アラートなどの運用レイヤーが標準で組み込まれているため、追加のインフラを管理する必要はありません。Jobs は dbt Core と dbt Platform をサポートしており、dbt Core v2.0 のサポートも予定されています。

4. Declarative Automation Bundles でコードとしてデプロイする

UI で手動作成されたジョブは、バージョン管理、レビュー、再現が困難です。 Declarative Automation Bundles（DAB）は、ジョブ定義をコードリポジトリの一部にすることでこの問題を解決します。Lakeflow Job、そのスケジュール、コンピュート設定、dbt プロジェクトがすべて YAML で宣言され、1 つのパッケージとしてデプロイされます。

 --target dev でデプロイするとパイプライン全体の隔離されたコピーが作成され、 --target prod で昇格されます。

プロジェクト内のすべてのモデルを毎回のスケジュールで実行する必要はありません。dbt YAML で実行周期ごとにモデルにタグを付け、各周期にそのタグを持つモデルのみをビルドする専用ジョブを割り当てます。モデルを日次から時間次に変更する作業も 1 行の変更で完了します。

5. プロジェクト内でガバナンスを定義する

ガバナンスは通常、モデルの実行後に設定され、データを構築する dbt プロジェクトとは分離されています。ガバナンスが dbt プロジェクトの外にあるため、dbt の実行との間で同期がずれる可能性があります。 

モデルがすでに配置されている dbt プロジェクト内でガバナンスを定義してください。プロジェクト設定としてコードとともに提供され、コードと同様にレビューされ、Unity Catalog がすべてのクエリに対してこれを適用します。

タグ、権限（grants）、行レベルおよび列レベルの保護はすべて、 dbt_project.yml のプロジェクト全体の設定で定義できます。 databricks_tags は分類とポリシーを推進し、 grants はテーブルを読み取れるユーザーを制御し、 row_filters と column_masks は各ユーザーが表示できる内容を制御します。

大規模環境では、 属性ベースのアクセス制御（ABAC）によって重複した作業が不要になります。ガバナンス対象のタグにポリシーを1つ定義すれば、そのタグを持つすべてのテーブルに適切な行フィルターと列マスクが適用されるため、 piiのタグが付いた新しいモデルは作成された瞬間に保護対象となります。モデルごとのフィルターやマスクは、マルチテナント分離のようにロジックが本当にモデル固有である場合にのみ使用してください。

これらの実践に共通するのは、増分処理、データレイアウト、テーブルのメンテナンス、ガバナンスの適用、オーケストレーションなどの運用作業をプラットフォームに委ねる点です。dbtプロジェクトに残るのは、バージョン管理されテスト済みの変換ロジックのみです。現在のプロジェクトが抱える課題に対処できる実践方法を1つ選び、そこから始めましょう。

Databricks上でdbtを活用している3,000以上の組織の仲間に加わりましょう。まずは dbt-databricksアダプターから始めましょう。

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