Databricks SQLのクエリ履歴を使った監査・分析・性能改善

クエリ履歴は「誰が・いつ・どのWarehouseで・どんなSQLを・どれくらいの時間で」実行したかを俯瞰できる中核データです。運用では監査・SLA確認・コスト最適化、資格試験ではログ活用や性能観測の文脈で問われます。

本稿はUI/REST API/System Tablesの取り扱いを整理し、実務でそのまま使えるクエリ例と判断基準を提示します。バージョンで挙動が変わり得る箇所は注意書きを添えて、公式仕様に沿って解説します。

クエリ履歴の全体像と前提

Databricks SQLのQuery historyは、SQL Warehouse上の実行履歴を集約表示する機能です。一般に表示される主な属性は、実行開始時刻、実行者、SQLテキスト、Warehouse、所要時間、ステータス（成功/失敗）などです。履歴はUIでの可視化に加え、REST APIから機械的に取得できます。

権限と可視性はワークスペース設定やロールに依存します。多くの環境では、一般ユーザーは自身の履歴、管理者（もしくは適切な権限付与済みのユーザー）は広範な履歴を参照できます。監査要件が強い環境では、Unity CatalogのSystem Tables（例: system.access.audit）やアカウント監査ログと併用するのが定石です。

• 対象: Databricks SQL Warehouseで実行されたクエリ
• 主要項目: 実行者、開始/終了、Warehouse、SQL、所要時間、ステータス
• 用途: 監査、SLA/遅延把握、ボトルネック調査、コスト最適化の判断材料

クエリ実行から履歴参照までの流れ

コンテキストの確認（安全に実行できる最小コマンド）

SELECT current_user() AS user, current_catalog() AS catalog, current_schema() AS schema;

取得手段の選び方：UI / REST API / System Tables

クエリ履歴の取り出しは、UIのQuery history、REST API、Unity CatalogのSystem Tables（監査系）という三本柱で検討します。運用自動化や横断分析を行うならREST APIやSystem Tables、即時トラブルシュートならUIが素早いです。

REST APIの利用ではフィルタ条件（期間、ユーザー、Warehouseなど）を指定してページング取得し、Deltaテーブルへ着地させると二次利用が容易になります。System Tablesはガバナンス基盤として履歴・監査イベントをSQLで横断集計できるのが長所です。

• UI: 人手での調査・確認に最適
• REST API: スケジュール取得・ダッシュボード化に最適
• System Tables: 組織横断の監査・集計・相関分析に最適

REST APIでクエリ履歴を取得してDeltaに着地（例）

curl -s -X POST \
  -H "Authorization: Bearer DAPIxxxxxxxx" \
  -H "Content-Type: application/json" \
  https://YOUR-WORKSPACE.cloud.databricks.com/api/2.0/sql/history/queries \
  -d '{
        "filter_by": {
          "query_start_time_range": {
            "start_time_ms": 1719878400000,
            "end_time_ms": 1719964800000
          }
        },
        "max_results": 1000
      }'

# 取得JSONをノートブックで処理し、from_jsonでスキーマ化してDeltaに書き出すのが定番です。
# 実際のリクエスト/レスポンスはドキュメントの最新版を参照してください。

監査：誰が・いつ・どこで・何を実行したか

監査の第一歩は、ユーザー、時間帯、接続元（IP/クライアント）、対象カタログ/スキーマ/テーブルの把握です。UIでは個別クエリの責任追跡が容易ですが、組織全体の動向や期間横断の検証はSystem Tablesとの組み合わせが強力です。

Unity CatalogのSystem Tables（例: system.access.audit）が有効化されている場合、SQLだけで監査証跡を横断集計できます。フィールド名や構造は環境で差異があるため、実スキーマをDESCRIBEで確認しつつJSON抽出関数を使うのが実務的です。

• 最小セット: ユーザー、時刻、Warehouse、SQLテキスト、結果（成功/失敗）
• 機微情報: SQLテキストの取扱いは社内ポリシーに従う
• 長期保管: REST APIで定期取得し、Deltaに保存・権限管理

System Tablesで監査集計（代表例・実スキーマ要確認）

SELECT
  event_time,
  user_identity.email       AS user_email,
  service_name,
  action_name,
  request_params:warehouse_id    AS warehouse_id,
  request_params:statement_text  AS sql_text,
  response_status:status_code    AS status_code
FROM system.access.audit
WHERE service_name = 'sql'
  AND action_name LIKE 'execute%'
  AND event_time >= TIMESTAMP('2024-06-01')
ORDER BY event_time DESC
LIMIT 200;

-- 補足: request_params/response_status などのJSONフィールド名は環境で異なることがあります。

性能分析：遅いクエリの特定と対策

実務では、95パーセンタイルの所要時間やリトライ頻度、長大なSQLテンプレートの特定が有用です。即席の原因切り分けはUIのQuery historyとQuery profileで、構造的改善はEXPLAINで実行計画を把握するのが基本線です。

繰り返し遅いパターンには、適切なパーティションフィルタ、集計の事前計算、ジョインキーのカーディナリティ見直し、Delta最適化（ファイルサイズ適正化、Z-ORDERなど）の効果検証を進めます。

• まずはUIのQuery profileでスキャン量・ステージ時間を確認
• 同系統のクエリはテンプレート化して根本原因を潰す
• EXPLAINでジョイン順序・フィルタ推進度を点検

EXPLAINで実行計画を把握（Databricks SQL）

EXPLAIN
SELECT c.customer_id, SUM(o.amount) AS revenue
FROM sales.orders o
JOIN sales.customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= DATE_SUB(CURRENT_DATE(), 30)
GROUP BY c.customer_id;

コスト管理とSLA：Warehouse運用と履歴の読み解き

クエリ履歴は、Warehouseサイズ/並列度/自動停止の調整根拠になります。ピーク時間帯の同時実行数と遅延の関係を把握し、必要に応じてスケールアップ/アウトやスケジューリングの見直しを行います。

継続監視は、REST APIで取得した履歴をDelta化し、クエリ数・失敗率・P95時間をダッシュボード化するのが実務的です。運用の初期段階では日次バッチ、成熟後は15分程度の増分収集がバランスです。

• ピーク帯の同時実行数と遅延を相関で確認
• 小さなWarehouseの長時間実行 vs 大きなWarehouseの短時間実行を比較
• 自動停止・自動起動のしきい値を履歴からチューニング

監査ログから5分粒度のクエリ本数を概観（代表例）

WITH events AS (
  SELECT
    window(event_time, '5 minutes') AS w,
    COUNT_IF(action_name LIKE 'execute%') AS qps
  FROM system.access.audit
  WHERE service_name = 'sql'
    AND event_time >= date_sub(current_timestamp(), 7)
  GROUP BY window(event_time, '5 minutes')
)
SELECT w.start AS window_start, w.end AS window_end, qps
FROM events
ORDER BY window_start;

Data Analyst試験向け観点と落とし穴

試験では、履歴の活用方針（UI/REST API/System Tablesの使い分け）や、遅いクエリの切り分け（EXPLAIN、フィルタ適用、ジョイン戦略）といった“実務の定石”が問われやすいです。特定のエンドポイントの暗記より、用途ごとの選択ができるかに比重があります。

用語の混同に注意しましょう。クエリ履歴は実行ログの一覧であり、テーブル変更履歴（DeltaのDESCRIBE HISTORY）とは別物です。監査と性能解析のデータソースが異なり得る点も意識しておくと安全です。

• UIは単発トラブル対応、REST APIは継続監視、System Tablesは監査集計
• 遅延の初動はQuery profile、恒常対策はEXPLAINとデータ配置の見直し
• Deltaのテーブル履歴とSQLのクエリ履歴を混同しない

P95所要時間の集計（履歴をDelta化済みの想定）

SELECT
  date_trunc('day', start_time) AS day,
  APPROX_PERCENTILE(duration_ms, 0.95) AS p95_ms,
  COUNT(*) AS total_queries
FROM analytics.query_history_delta
WHERE start_time >= date_sub(current_date(), 14)
GROUP BY 1
ORDER BY 1;

問題で確認

よくある質問