クエリタグを使用したdbtパイプラインの詳細な使用状況の割り当て

dbtプロジェクトは毎晩80個のモデルを実行しています。前四半期、ウェアハウスの請求額は倍増しました。モデルのパフォーマンスは大きく異なり、直近の最適化の効果は不明確です。財務部門から、どのチームに責任があるのかと尋ねられます。クエリ履歴を開くと、そこには「Databricks Dbt」とラベル付けされた80行の同一の行が……。健闘を祈ります。

Query Tags（現在パブリックプレビュー中）を使用すると、データチームは、すべての実行を強化するdbt_model_nameなどの自動挿入タグをすぐに利用できるようになります。また、パイプラインが生成するすべてのクエリに、チーム、コストセンター、環境など、独自のカスタムタグを付与することもできます。

タグはsystem.query.historyに記録されるため、コストの割り当て、パフォーマンスのデバッグ、ワークロードの監視を、簡単なSQLクエリを実行するだけで行えます（詳細はドキュメントを参照してください）。

このブログでは、設定からコスト割り当てダッシュボードまで、Query Tagsをエンドツーエンドで実証する、完全なオープンソースのdbtプロジェクトについて解説します。ここで説明する内容はすべて、クローンしてご自身のワークスペースにデプロイできるGitHubリポジトリとして公開されています。または、Genieに尋ねることもできます。

dbt-databricksとQuery Tagsの統合方法

dbt-databricksアダプター（バージョン1.11以降）は、Query Tagsをネイティブにサポートしています。タグを適用できるレベルは3つあり、それぞれ前のレベルをベースに構築されています。

自動挿入タグ

カスタムタグに加えて、dbt-databricksは各モデルの実行に関するメタデータを自動的に挿入します。

これらの自動タグにより、設定なしでモデルごとの可視性を得ることができます。アダプターがすべて自動で行います。

プロファイルレベルのタグ

最もシンプルなアプローチは、dbtプロファイルの特定のターゲットにquery_tagsフィールドを追加することです。プロジェクト内のすべてのクエリが、これらのタグを自動的に継承します。

たとえば、この1行だけで、すべてのクエリに4つのディメンション（所有者（team）、コストの帰属先（cost_center）、所属するパイプライン（project_name）、実行環境（env））のタグが付けられます。

モデルレベルのタグ

より詳細な割り当てを行うには、dbt_project.yml内の特定のモデル、またはSQL定義内のモデル設定でタグを指定できます。

モデルレベルのタグは、プロファイルレベルのタグとマージされます。両方で同じキーが定義されている場合は、モデルレベルの値が優先されます。

タグの表示場所 – system.query.history

dbt runの実行後、すべてのSQLステートメントがsystem.query.historyに表示され、query_tags列にMAPとしてデータが挿入されます。標準的なマップアクセス構文を使用して、これをクエリできます。

これにより、過去7日間のすべてのタグ付きクエリが返され、カスタムタグと自動挿入タグが個別の列に抽出され、すぐに集計できる状態になります。

また、実行したクエリのQuery Tagsは、Query History UIまたはSQL Warehouse Monitoring UIでも確認できます。

Query Profileの右下に定義したQuery Tagsが表示され、必要なすべての情報を一目で確認できます。

Query Tagsによるコストの割り当て

Query Tagsを使用すると、SQLクエリを介して詳細な使用状況の割り当てを直接特定できるため、手動でのログ分析やウェアハウスリソースの分割が不要になります。

どのdbtモデルが最も多くのウェアハウスリソースを消費しているか？

これには2つの方法で答えることができます。アドホックな探索のために自然言語でGenieに尋ねるか、ダッシュボードで再利用可能な結果を得るために自身でSQLを記述するかです。どちらも同じsystem.query.historyデータから読み取ります。

オプション1：Genie

Genieが同等のクエリを記述して実行するため、SQLを一切触ることなく、後続の質問でドリルダウンを続けることができます。

オプション2：SQL

どちらの方法でも同じ結果が得られます。リファレンスプロジェクトでは、4つのマートテーブル（tableとしてマテリアライズド）がコンピュート時間を占有しており、ステージングビューとメトリックビューはほぼ瞬時に処理されます。これにより、最適化の取り組みをどこに集中させるべきかがすぐにわかります。

自己監視ダッシュボードの構築

リファレンスプロジェクトには、プロジェクト独自のクエリタグでフィルタリングされたsystem.query.historyをクエリするAI/BIダッシュボードが含まれています。その結果、請求データを分析するパイプラインが自身のコストも追跡するようになり、Query Tagsのドッグフーディング（自社利用）が実現します。

ダッシュボードには以下が含まれます。

• KPI：タグ付きクエリの総数、総コンピュート秒数、一意のdbtモデル数
• 日次アクティビティ：環境ごとに分割された、1日あたりのクエリ数とコンピュート時間
• モデルの内訳：マテリアライズのタイプごとに色分けされた、モデルごとのコンピュート時間
• マテリアライズの分割：table、view、metric_viewにおけるコンピュートの分散を示す円グラフ
• クエリ詳細テーブル：モデル、実行時間、環境、エグゼキューターを含む、タグ付けされたすべてのクエリ

リファレンスプロジェクトでは、4つのマートモデルがコンピュート時間の92%を占めていました。クエリタグがなければ、このインサイトを可視化することはできませんでした。

Genie Codeを使用すれば、このダッシュボードを数分で自分で作成できます。クエリタグでフィルタリングされた system.query.history からdbtモデルごとのコンピュート時間を尋ねるだけで、SQLが作成され、ビジュアルが組み立てられます。完成した結果に直接進みたい場合は、このダッシュボードはリファレンスプロジェクトにも含まれており、dbtジョブと一緒に1回の databricks bundle deploy でデプロイできます（詳細なガイドについては、 Githubリポジトリを参照してください）。

メトリックビューのタグ付け

Databricksのメトリックビュー（ dbt-databricks 1.12以降で利用可能）は、Unity Catalog内にディメンションとメジャーの形式で再利用可能なビジネスセマンティクスを直接定義する、新しいマテリアライズタイプです（詳細は ドキュメントを参照してください）。これらは、 query_tags 構成パラメータを使用して、他のモデルと同様にクエリタグを保持できます。

違いに注意してください。 query_tags はメトリックビューを 作成または更新するSQLクエリ（ system.query.history で追跡）に付与されます。一方、 databricks_tags は Unity Catalogタグであり、 オブジェクト自体に付与されます（ガバナンスと検出用）。前者はクエリレベルの追跡用であり、後者はデータ全体の検出可能性を高めるための Unity Catalogオブジェクトレベルのタグです。

dbtプロジェクトのタグ付けにおけるベストプラクティス

こちらの記事では、クエリタグがコスト配分の基盤となる、強固なFinOpsプラクティスを構築するための包括的なプロセスについて説明しました。リファレンスプロジェクトの構築や、dbtのパワーユーザーとの対話から得られた知見を以下に紹介します：

• 一貫したタグ階層を使用する。プロファイルレベルで組織全体のタグ（team、 cost_center、 project_name、 env）を定義し、モデルレベルのタグは例外的なケースのために予約しておきます。これにより、タグの予測可能性が維持され、モデルごとの構成の無秩序な増加を防ぐことができます。
• 常に環境をタグ付けする。ローカル開発（local-dev）とデプロイされたジョブ（dev、 staging、 prod）で異なる env 値を使用します。これにより、分析においてアドホックな開発クエリとスケジュールされた本番実行を区別できます。リファレンスプロジェクトでは、ローカルプロファイルに "env": "local-dev" を設定し、デプロイされたプロファイルには "env": "dev" を設定しています。
• `project_name` を使用してパイプラインを区別する。複数のdbtプロジェクトがウェアハウスを共有している場合、 project_name を使用することで、ウェアハウスを分割することなくパイプラインごとにコストを配分できます。自動挿入される @@dbt_model_name と組み合わせることで、プロジェクト → モデル → マテリアライズという完全なトレーサビリティが得られます。
• 過剰なタグ付けを避ける。自動挿入されるタグには、モデル名、マテリアライズタイプ、アダプターのバージョンがすでに含まれています。カスタムタグでこれらの情報を重複して設定する必要はほとんどありません。カスタムタグは、dbtが推測できない ビジネスコンテキスト（チームの所有権、コストセンター、プロジェクトの識別など）に焦点を当ててください。
• メトリックビューを明示的にタグ付けする。メトリックビューは比較的新しいマテリアライズであるため、機能キー（例： "feature": "metric_view"）でタグ付けしておくと、コスト分析でメトリックビュー作成クエリを簡単にフィルタリングできて便利です。

実際にお試しください

完全なリファレンスプロジェクトはGitHubで公開されています： github.com/databricks-solutions/dbt-query-tags

開始するには：

1. リポジトリをクローンします
2. Python 3.12の仮想環境を作成し、依存関係をインストールします： pip install dbt-databricks>=1.12.0a1
3. profiles.yml を、ワークスペースのホスト、SQLウェアハウスのHTTPパス、カタログ、およびカスタムクエリタグで更新します
4. dbt deps && dbt run --profiles-dir . を実行してパイプラインを実行します
5. system.query.history をクエリして、タグが機能していることを確認します
6. dbt_profiles/profiles.yml と databricks.yml を更新して、正しい構成を指すようにします。
7. スケジュール実行と分析ダッシュボード用に、 databricks bundle deploy でデプロイします

独自のチーム名やコストセンターの値に置き換えてください。このパターンは、Databricks上のあらゆるdbtプロジェクトに適用できます。

今すぐリポジトリをクローンしましょう！プロファイルに1行追加するだけで、ウェアハウス全体でモデルレベルの使用状況の割り当てを可視化できるようになります。

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