クエリタグ：データウェアハウスのクエリが欠いていたコンテキスト

Databricks SQLは、誰が、どのウェアハウスで、どのツールからクエリを実行したかといった、各クエリの重要な属性を自動的に記録します。しかし、それだけでは不十分な場合が多くあります。

Power BI クエリの実行が遅い場合、それが Power BI から来たことはわかりますが、どのダッシュボードを修正すべきかはわかりません。コストが急増した場合、どのユーザーがクエリを実行したかはわかりますが、どのコストセンターやプロジェクトに請求すべきかはわかりません。不足しているのはカスタムコンテキストであり、まさにそれが Query Tags が追加するものです。

本日、Query Tags をパブリックプレビューで導入しました。Query Tags を使用すると、各 SQL 実行にビジネスコンテキストをキーと値のペアとしてアタッチでき、標準 SQL を使用してシステムテーブル経由でクエリを実行できます — または Genie に尋ねるだけで済みます。Query Tags は Query Profile UI にも表示されます（Query History UI での検索サポートは近日公開予定です）。

Query Tags はすでに多くの採用実績があり、数百の顧客が毎週数百万のクエリにタグを付けています。

タグ付けするだけ：Query Tags のご紹介

Query Tags を使用すると、カスタムキーと値のペア（例：「project」：「finance_planning」）を各 SQL 実行にアタッチできます。これらのタグはクエリと共に移動し、Query History System Table に記録されるため、ワークロードのグループ化、フィルタリング、分析に利用できます。

タグは 3 つのシナリオで価値を発揮します：

1. パートナーツール：dbt、Power BI、Tableau を使用する場合、dbt モデル名、Power BI レポート ID、Tableau ワークブック名などの識別子を各クエリに伝播させます。
2. カスタムアプリケーション：SQL Statement Execution API またはコネクタを通じてアプリケーションを構築する場合、`customerid`、`applicationname`、`app_version` などのメタデータを各実行にアタッチします。
3. Databricks UI でのアドホック作業：開発環境と本番環境、コストセンター、実験名、チームなど、関連するディメンションでクエリにタグを付けます。

これらのシナリオについて詳しく見ていきましょう。

(1) 各パートナーツールのクエリをソースにトレースする

dbt、Power BI、Tableau からのクエリはウェアハウスに流れ込みますが、タグがないと、ユーザー ID とどのツールから来たか以外は追跡できません。これらのツールは、手動でのタグ付けなしで、Query Tags を自動的に注入することでこれを解決します。

dbt は、モデル名、コアバージョン、アダプターバージョン、マテリアライゼーションタイプですべてのクエリに自動的にタグを付けます。dbt モデルのパフォーマンスが突然低下した場合、どのモデル、どのバージョン、いつ発生したかを正確に特定できます：

ASOS のスタッフエンジニアリングリードである Dipesh Bhundia と Dave Couse は次のように述べています：

「何も設定せずに、各 SQL ワークロードをそれが由来する dbt モデルにマッピングできます。Query Tags を使用すると、dbt を実行しているチームごとにウェアハウスのコストを正確に分割できるようになりました。」

Power BI とTableau は、接続レベルでカスタム Query Tags をサポートしています。一度設定すれば、その接続からのすべてのクエリが自動的にタグを付けられます。Tableau の場合、顧客は [WorkbookName] のようなパラメータをタグ値として使用すると便利だと考えています。これにより、ワークブックがリネームされても属性が保持されます。

Query Tags をサポートするパートナーツールの全リストについては、ドキュメントを参照してください。お使いのツールがリストにない場合は、アカウントチームにお問い合わせください。

(2) 匿名 API クエリをトレース可能なワークロードに変換する

カスタムアプリケーションは API やコネクタを通じてウェアハウスにアクセスしますが、生成されるクエリにはアプリケーションコンテキスト（アプリ名、チーム名、顧客 ID など）が含まれていません。Query Tags を使用すると、このメタデータを接続レベルまたはステートメントレベルでアタッチできます。

SQL Statement Execution API は、ステートメントレベルでのタグ付けをサポートしています。パラメータとして渡されたタグは、その特定の実行に適用されます：

Python Connector は、接続レベルとステートメントレベルの両方のタグ付けをサポートしています。接続にチーム名を設定し、必要に応じてステートメントごとに上書きできます：

Unit21 の DevOps エンジニアである Matthew Haber 氏は次のように述べています：

「コスト削減のために、チームごとに 1 つのウェアハウスから共有ウェアハウスに移行しましたが、どのチームが支出を牽引しているかの可視性を失いました。Query Tags を使用すると、Databricks SQL Connector for Python ワークロードからチーム名を渡すだけで、その属性を取り戻すことができます。ウェアハウスを再度分割する必要はありません。」

コネクタおよびドライバー（Node.js、Go、JDBC など）のサポート全リストについては、ドキュメントを確認してください。

(3) ノイズに埋もれないように自分の作業にラベルを付ける

アナリストは週に数百ものクエリ（探索、本番、デバッグなど）を実行しますが、ラベルがないと、システムテーブルではすべて同じように見えます。Query Tags を使用すると、実務家は SQL の 1 行で、SQL Editor、Notebooks、Dashboards、Alerts など、クエリを送信する場所ならどこでも、その場でタグを付けることができます。

設定すると、セッション内の後続のすべてのステートメントは自動的にそのタグを付けられます。すべてのクエリを個別に注釈付けする必要はありません。たとえば、AI/BI ダッシュボードの各データセットクエリに SET QUERY_TAGS ステートメントを追加すると、そのダッシュボードからのすべてのクエリに「environment: production」というタグが付けられます。

データ実務家はこれを使用して以下を行うことができます：

• プロジェクトまたはチームでアドホック分析にタグを付ける
• 実験または A/B テストをマークする
• 開発環境と本番環境のワークロードを識別する
• 問題を調査する際にデバッグコンテキストをアタッチする

タグから回答へ：システムテーブルによる監視

クエリがタグ付けされると、タグはquery_tags 列のQuery History System Table に記録されます。これで、難しい質問が簡単な SQL になります。

どのチームがウェアハウスのコストを牽引していますか？

多くの組織では、チームや製品ごとに共有ウェアハウスのコストを配賦する必要があります。クエリタグを使用すれば、これは単一のクエリで実現できます。ウェアハウスの分割や推測は不要です。

どのdbtモデルがリグレッションを導入しましたか？

パイプラインが遅くなった場合、どのウェアハウスかだけでなく、どのモデルが原因かを知る必要があります。自動挿入されたdbtモデル名のタグで system.query.history をフィルタリングして、問題を特定します。

または、SQLをまったく書かずに、Genieに尋ねることもできます。クエリタグはシステムテーブルにビジネスコンテキストを保存するため、Genieは自然言語でワークロードデータを推論できます。たとえば、「どのdbtモデルが最も多くのクエリを実行しましたか？最も長い平均クエリ時間を持つモデルはどれですか？」

クエリタグは、さらに多くのモニタリングユースケースを可能にします。

1. チャージバックのために query_tags['cost_center'] でグループ化
2. パイプラインの正常性を監視するために query_tags['@@dbt_model_name'] でフィルタリング
3. Tableauワークブックごとの長時間実行クエリを特定
4. query_tags['env'] を比較して、開発トラフィックと本番トラフィックを分離

次のステップ

クエリタグは現在、SQLウェアハウス向けにパブリックプレビューで提供されており、お客様のモニタリングエクスペリエンスをさらに向上させるために、すでに作業を進めています。最新情報については、ドキュメントを参照してください。

• Power BI の自動タグ付け: Power BI は、設定不要で、DatasetId や ReportId などのメタデータをすべてのクエリに自動的に付加します。現在、ドキュメントの手順に従うことで、これを手動で有効にできます。次回の Power BI リリースでは、自動タグ付けがデフォルトで有効になります。
• より広範なコネクタサポート: Python に加えて、Go および Node.js でステートメントレベルのタグ付けが利用可能になりました。
• UI での検索可能性: 近日中にクエリ履歴 UI での検索をサポートする予定です。これにより、特定のタグを持つクエリ（例：「@@dbt_model_name」：「my_model」）を検索できるようになります。
• SQLウェアハウス以外のサポート: Serverless Notebooks および Jobs にクエリタグを導入し、同じタグ付けと属性モデルをノートブックワークロードにも拡張します。ads.

今すぐクエリタグを試す

タグ付けされていないクエリは、属性設定の機会損失です。チームごとのウェアハウスコストの分割、遅いクエリの特定のダッシュボードへの追跡、プロジェクトごとのアナリスト作業のラベル付けなど、クエリタグはそれを行うためのコンテキストを提供します。

dbt を使用している場合、すでにタグ付けされています（クエリ履歴システムテーブルを確認してください）。Power BI、Tableau、カスタムアプリケーションの場合は、セットアップに数分かかります。アドホックな作業の場合は、SQL 1 行で済みます。

クエリタグは現在、すべてのクラウドでパブリックプレビューで利用可能です。ドキュメントで開始してください。

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