クエリ タグ付きの dbt パイプラインのきめ細かな使用状況帰属 - クローン済み

dbt プロジェクトでは毎晩 80 個のモデルが実行されます。 ウェアハウスの請求額は前四半期に倍増しました。モデルのパフォーマンスは大きく異なり、最新の最適化の効果は不明です。 財務担当者はどのチームが責任を負っているかを尋ねています。 クエリ履歴を開くと、「Databricks Dbt」というラベルが付いた 80 個の同一の行が表示されます。幸運を祈ります

。クエリタグ（現在はパブリックプレビュー版）を使用することで、データチームは、dbt_model_name など、すぐに使用できる自動挿入タグのメリットを享受できるようになりました。これにより、すべての実行を充実させられます。 また、パイプラインが生成するすべてのクエリに独自のカスタムタグ（チーム、コストセンター、環境など）を付けることもできます。

タグは system.query.history に記録されるため、コストの帰属、パフォーマンスのデバッグ、ワークロードの監視などをシンプルな SQL クエリで実行できます（詳細についてはドキュメントを参照）。

このブログでは、構成からコスト帰属ダッシュボードまで、クエリ タグをエンドツーエンドで実証する完全なオープンソースの dbt プロジェクトについて説明します。ここで説明されているすべての情報は、GitHub リポジトリとして利用できます。複製して自分のワークスペースにデプロイすることもできます。また、Genie に問い合わせることもできます

。dbt-databricks とクエリ

タグの統合方法dbt-databricks アダプター（バージョン 1.11 以降）はクエリタグをネイティブでサポートしています。 タグを適用できるレベルは 3 つあり、それぞれが前のレベルを基盤としています。

自動挿入されたタグ

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

これらの自動タグを使用すると、設定なしでモデルごとに可視性が得られます。つまり、アダプターが代わりにそれを行います。

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

たとえば、この 1 行は、クエリを所有している人（team）、コストがどこに発生しているか（cost_center）、クエリが属しているパイプライン（project_name）、クエリが実行されている環境（env）という 4 つの次元でタグ付けします。

4 モデルレ

ベルのタグより詳細なアトリビューションを行うには、dbt_project.yml で特定のモデルに関するタグを指定するか、SQL 定義でモデル設定を指定できます。 

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

'タグが表示される場所 – system.query.

historydbt run を実行すると、すべての SQL ステートメントが system.query.history に表示され、query_tags カラムが MAP として入力されます。 この情報は、標準のマップアクセス構文を使用してクエリできます。

これは、過去 7 日間のタグ付きクエリをすべて返します。カスタムタグと自動挿入タグは個々の列に抽出され、集計の準備が整っています。

また、実行したクエリのクエリタグは、クエリ履歴 UI または SQL ウェアハウス モニタリング UI でも確認できます。

次の場所で クエリプロファイルの右下に、定義したクエリタグが表示され、必要なすべての情報が一目でわかります。

クエリタグを使用したコストアトリビューションクエリタグを使用すると、詳細な使用状況アトリビューションをSQLクエリから直接決定できます。

手動でのログ分析やウェアハウスリソースの分割の必要性を排除します。

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

この質問に答えるには、平易な言語でGenieにアドホックな調査を依頼するか、繰り返し可能なダッシュボード対応の結果を得るために自分でSQLを書くという2つの方法があります。どちらも同じ system.query.history データから読み取ります。

オプション 1: Genie

Genie は同等のクエリを書き込みおよび実行します。そのため、SQL に触れることなく、フォローアップの質問を継続的に掘り下げることができます。

オプション 2: SQL

どちらのパスも同じ結果を返します。 私たちのリファレンスプロジェクトでは、4 つの mart テーブル (テーブルとしてマテリアライズされたもの) がコンピューティング時間を支配していますが、ステージング ビューとメトリック ビューはほぼ瞬時に処理されます。 これにより、最適化作業の重点がどこにあるかをすぐに把握できます。自己監視ダッシュボ

ードの構

築私たちのリファレンスプロジェクトには、プロジェクト独自のクエリタグでフィルタリングされた system.query.history へのクエリを行う AI/BI ダッシュボードが含まれています。 その結果、課金データを分析するパイプラインは、自らのコストも追跡しており、クエリタグを自社製品の試用（ドッグフーディング）に活用しています

。ダッシュボードには次の情報が含まれています。

• KPI: タグ付きクエリの合計数、合計計算時間数、個別のdbtモデル、毎日のアクティビティ: 1日あたりのクエリ数と計算時間（
• 環境別に分割）、
• モデル内訳: モデルあたりの計算時間（マテリアライゼーションタイプ別に色付き）
• マテリアライゼーション分割：計算がテーブル、ビュー、および metric_view にどのように分散しているかを示す円グラフ
• ：クエリの詳細テーブル： モデル、期間、環境、エグゼク

タを含むすべてのタグ付きクエリ私たちのリファレンスプロジェクトでは、4 つのマートモデルがコンピューティング時間の 92% を占めていました。クエリタグがなければ、このインサイトは見えませんでした。このダッシュボードを自分で構

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

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

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

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

db

t プロジェクトにタグを付けるためのベストプラクティスこの記事では、クエリタグがコストアトリビューションの基礎となる堅実な FinOps プラクティスを構築するための総合的なプロセスについて説明しました。 以下は、リファレンス プロジェクトを構築し、dbt のパワー ユーザーと話をすることで学んだことです。

• 一貫したタグ階層を使用してください。 プロファイルレベル（チーム、コストセンター、プロジェクト名、環境）で組織全体のタグを定義し、例外的なケースのためにモデルレベルのタグを予約します。 これにより、タグを予測可能な状態に保ち、モデルごとの構成の無秩序な拡大を回避できます。
• 常に環境にタグを付けます。 ローカル開発（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.0a
3. 1ワークスペースホスト、SQL ウェアハウスの HTTP パス、カタログ、カスタムクエリタグを使用して profiles.yml を更新します
4. dbt deps を実行する && dbt run --profiles-dir . を実行してパイプ
5. ラインを実行します。system.query.history をクエリして、実際にタグが
6. 機能していることを確認します。dbt_profiles/profiles.yml と databricks.yml を更新して、正しい設定を指すようにします。databricks bundle deploy を使用してデプロイし、スケジュールされた実行とアナリティクスダッシュ

ボードを利用できるようにします

。独自のチームとコストセンターの値に入れ替えてください。このパターンは、Databricks 上のあらゆる dbt プロジェクトで機能します。

今すぐリポジトリをクローンしましょう！ プロファイルに 1 行追加するだけで、ウェアハウス全体にわたってモデルレベルの使用状況アトリビューションの可視性を確保できます。

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