クエリ タグ付きの 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 行は、クエリを誰が所有しているか (チーム)、コストがどこに発生しているか (コスト_センター)、クエリが属するパイプライン (プロジェクト_名)、クエリが実行されている環境 (環境) の 4 つの次元でタグ付けしています。

モデルレベルのタグ

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

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

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

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

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

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

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

クエリタグによるコストアトリビューション

クエリタグを使用すると、SQLクエリを使用して詳細な使用状況の帰属を直接決定できるようになります。そのため、手動でのログ分析やウェアハウスリソースの分割は不要です。

どのDBTモデルが最も多くの倉庫リソースを消費していますか？

この問題に対する回答には、2つの方法があります。1つは、Genie にアドホックな調査を依頼することです。もう1つは、自分でSQLを記述することです。もう1つは、ダッシュボード対応の再現可能な結果を得ることです。 どちらも同じ system.query.history データから読み取ります。

オプション1：ジーニー

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

オプション 2: SQL

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

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

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

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

• KPI: タグ付きクエリの合計数、合計コンピューティング時間数、個別のデータベース モデル
• 毎日のアクティビティ: 1日あたりのクエリ数と計算時間(環境別)
• モデルの内訳: モデルごとの計算時間(マテリアライゼーションタイプ別に色付き)
• マテリアライゼーション分割: 計算量がテーブル、ビュー、メトリックビューにどのように分散されているかを示す円グラフ
• クエリ詳細テーブル: モデル、期間、環境、実行者を含むタグ付きのすべてのクエリ

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

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

メトリクスビューにタグ付けする

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

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

DBT プロジェクトにタグを付けるためのベストプラクティス

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

• 一貫したタグ階層を使用してください。 プロファイルレベル（チーム、コストセンター、プロジェクト名、環境）で組織全体のタグを定義し、例外的なケースのためにモデルレベルのタグを予約します。 これにより、タグを予測可能な状態に保ち、モデルごとの構成の無秩序な拡大を回避できます。
• 常に環境をタグ付けしてください。 ローカル開発（local-dev）とデプロイ済みジョブ（dev、staging、prod）には異なる env 値を使用してください。 これにより、アナリティクスにおけるアドホックな開発クエリとスケジュールされた本番稼働を分離できます。 私たちのリファレンスプロジェクトでは、ローカルプロファイルは "env": "local-dev" を設定し、デプロイされたプロファイルは "env": "dev" を設定します。
• パイプラインを区別するには、`project_name` を使用してください。 複数の dbt プロジェクトがウェアハウスを共有する場合、project_name を使用すると、ウェアハウスを分割することなく、パイプラインごとにコストを割り当てることができます。 自動注入と組み合わせることで@@dbt_model_name、プロジェクト→モデル→マテリアライゼーションといった完全なトレーサビリティを実現できます。
• 過剰なタグ付けをしないでください。 自動挿入されたタグには、モデル名、マテリアライゼーションタイプ、およびアダプターバージョンがすでに含まれています。 この情報をカスタム タグに複製する必要はほとんどありません。 カスタムタグは、dbt が推測できないビジネスコンテキスト（チームの所有権、コストセンター、プロジェクト ID）に焦点を当てます。
• メトリクスビューに明示的にタグ付けします。 メトリクスビューは新しいマテリアライゼーションであるため、メトリクスビューに機能キー（例：”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 上のあらゆる dbt プロジェクトで機能します。

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

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