Databricks SQL Alertsで実現する監視・ダッシュボード運用

「売上が前日比20%以上下がったら即座に知りたい」「ETLの取込件数がゼロだったらアラートを出したい」 ——こうしたビジネスメトリクスの異常検知は、Databricks SQL Alertsで実現できます。 SQLクエリの実行結果に条件を設定し、条件を満たしたときにEmail・Slack・Webhook等に自動通知する仕組みです。 この記事では、Alertの作成手順、クエリ設計、通知先の構成、そしてJobs Notificationとの使い分けを整理します。

SQL Alertの概要

SQL Alertは以下の3つの要素で構成されます。

1. クエリ: 評価対象となるSQLクエリ（数値カラムを返す）
2. 条件: クエリ結果に対する閾値判定（例: value > 100, value == 0）
3. 通知先: 条件が満たされたときの通知送信先（Email, Slack, Webhook等）

Alertはスケジュールに基づいて定期的にクエリを実行し、条件を評価します。 条件を満たした場合に通知を送信し、満たさなくなったら通知を停止します。

Alert作成手順

ステップ1: 監視用クエリの作成

Databricks SQL Editorで、監視したいメトリクスを返すクエリを作成します。 Alertの条件評価では、クエリ結果の最初の行・最初のカラムの値が使われます。 したがって、クエリは数値1つを返すように設計します。

-- 例1: 直近1時間のエラー件数を監視
SELECT COUNT(*) AS error_count
FROM catalog.schema.application_logs
WHERE log_level = 'ERROR'
  AND event_time > CURRENT_TIMESTAMP() - INTERVAL 1 HOUR;

-- 例2: 日次ETLの取込件数がゼロかを監視
SELECT COUNT(*) AS ingested_rows
FROM catalog.schema.daily_ingestion_log
WHERE ingestion_date = CURRENT_DATE();

-- 例3: 売上の前日比を監視
SELECT
  (today.total_sales - yesterday.total_sales) / yesterday.total_sales * 100
    AS daily_change_pct
FROM (
  SELECT SUM(amount) AS total_sales
  FROM catalog.schema.sales
  WHERE order_date = CURRENT_DATE()
) today
CROSS JOIN (
  SELECT SUM(amount) AS total_sales
  FROM catalog.schema.sales
  WHERE order_date = CURRENT_DATE() - INTERVAL 1 DAY
) yesterday;

ステップ2: Alertの条件設定

Databricks SQL UIの「Alerts」セクションから新規Alertを作成し、以下を設定します。

Notification frequencyが重要です。「Just once」に設定すると、条件が最初に満たされたときのみ 通知が送信され、条件が継続している間は再通知されません。条件が一度解除されてから再度満たされると再通知されます。 「Every time」に設定すると、条件が満たされるたびに毎回通知が送信されます。

ステップ3: 通知先の設定

Alertがトリガーされたときの通知送信先を設定します。

Alert Destinationの設定

EmailはDatabricksユーザーに直接送信できますが、Slack・Webhook・PagerDutyは 事前に「Alert Destination」を管理者が設定する必要があります。

Slack連携の設定手順

1. Slack側でIncoming Webhook URLを発行する
2. Databricks SQL → SQL Admin Console → Alert Destinationsを開く
3. 「New Alert Destination」→ Slackを選択
4. Webhook URLを入力し、通知先の名前を設定
5. Alertの通知先に作成したDestinationを選択

Webhook連携のペイロード

Webhookに送信されるJSONペイロードには以下の情報が含まれます。

{
  "alert_id": "abc-123",
  "alert_name": "daily_error_count_high",
  "alert_state": "triggered",
  "alert_url": "https://workspace.databricks.com/sql/alerts/abc-123",
  "query_name": "daily_error_count",
  "query_url": "https://workspace.databricks.com/sql/queries/xyz-456",
  "column": "error_count",
  "value": 152,
  "threshold": 100,
  "condition": "above"
}

実務で使えるAlert設計パターン

パターン1: データ鮮度の監視

-- テーブルの最終更新からの経過時間（時間単位）
SELECT
  TIMESTAMPDIFF(HOUR, MAX(updated_at), CURRENT_TIMESTAMP()) AS hours_since_update
FROM catalog.schema.fact_orders;
-- Alertの条件: hours_since_update > 4（4時間以上未更新で通知）

パターン2: データ品質の監視

-- NULL率が閾値を超えたら通知
SELECT
  COUNT(CASE WHEN customer_id IS NULL THEN 1 END) * 100.0 / COUNT(*)
    AS null_rate_pct
FROM catalog.schema.transactions
WHERE transaction_date = CURRENT_DATE();
-- Alertの条件: null_rate_pct > 5（NULL率5%超で通知）

パターン3: コスト異常の監視

-- 日次DBU消費量が直近7日平均の1.5倍を超えたら通知
WITH daily AS (
  SELECT usage_date, SUM(usage_quantity) AS daily_dbu
  FROM system.billing.usage
  WHERE usage_date >= CURRENT_DATE() - INTERVAL 8 DAY
  GROUP BY usage_date
)
SELECT
  MAX(CASE WHEN usage_date = CURRENT_DATE() THEN daily_dbu END)
    / AVG(CASE WHEN usage_date < CURRENT_DATE() THEN daily_dbu END) AS ratio
FROM daily;
-- Alertの条件: ratio > 1.5

Alert vs Job Notification 比較表

試験で問われるポイント

• 「クエリ結果が特定の条件を満たしたときに通知する方法」→ SQL Alert
• 「Alertの評価対象はクエリ結果のどの値か」→ 最初の行の指定カラム
• 「Alert Destinationとは何か」→ Slack / Webhook / PagerDuty等の外部通知先の登録
• 「AlertとJob Notificationの違い」→ Alertはクエリ結果ベースの条件通知、Job Notificationはジョブ状態ベースの通知

問題で確認

よくある質問