事件結構
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| timestamp_utc | Timestamp | 完成事件的 UTC 時間;在正式環境中應使用固定的分析時段。 |
| job_id | Utf8 | 每列代表一個虛構的已完成邏輯任務。 |
| schema_version | Int64 | 事件格式版本;第 1 版使用 duration_ms,第 2 版使用 latency_ms。 |
| duration_ms | Int64 | 第 1 版的耗時;第 2 版為 null。 |
| latency_ms | Int64 | 第 2 版的耗時;第 1 版為 null。 |
DataFusion SQL
複製查詢
sql
WITH normalized AS (
SELECT
job_id,
schema_version,
duration_ms,
CASE schema_version
WHEN 1 THEN duration_ms
WHEN 2 THEN latency_ms
END AS measured_ms
FROM job_finished
)
SELECT
COUNT(*) AS completed_jobs,
COUNT(duration_ms) AS jobs_in_old_average,
ROUND(AVG(duration_ms), 1) AS old_average_ms,
COUNT(measured_ms) AS jobs_with_duration,
SUM(CASE WHEN measured_ms IS NULL THEN 1 ELSE 0 END) AS unmeasured_jobs,
ROUND(100.0 * COUNT(measured_ms) / NULLIF(COUNT(*), 0), 1)
AS duration_coverage_pct,
ROUND(AVG(measured_ms), 1) AS schema_aware_average_ms
FROM normalized;此只讀查詢是針對空型別資料表計劃和執行的 阿帕奇 DataFusion 45.2.0。確定性樣本輸出是綜合的並單獨審查;根據您自己的資料驗證欄位型別、閾值和業務定義。 閱讀測試方法。
查詢結果
看似合理的平均值可能只涵蓋一半任務
舊欄位只計入兩個虛構任務,平均為 475 毫秒;依版本對應欄位後,四個任務的平均為 580 毫秒。
| completed_jobs | jobs_in_old_average | old_average_ms | jobs_with_duration | unmeasured_jobs | duration_coverage_pct | schema_aware_average_ms |
|---|---|---|---|---|---|---|
| 4 | 2 | 475 | 4 | 0 | 100 | 580 |
綜合範例輸出。在將其用於操作決策之前,針對您自己的事件架構和閾值執行查詢。
SQL 是如何工作的
- 1舊查詢 AVG(duration_ms) 仍回傳 475 毫秒,因為 SQL 平均值會略過 null;四個已完成任務中只有兩個被計入。
- 2依版本判斷的 CASE 將第 1 版對應 duration_ms、第 2 版對應 latency_ms,因此四個虛構任務的平均為 580 毫秒。
- 3將耗時欄位覆蓋率與平均值並列。未知版本或缺少欄位時,平均值可能不變,但覆蓋率會下降。
需要檢查的邊界情況
- 比較版本時使用固定的 UTC 時段;本例的四筆虛構資料全部納入計算。
- 本例假設每個已完成的邏輯任務只有一筆完成事件。用於實際任務計數前,應依 job_id 去除重複的完成事件。
- 只有兩個版本測量相同起點、終點且使用相同單位時,改名後的欄位才可比較。
- 缺少或未知的 schema_version 會對應為 null,並降低覆蓋率;不要悄悄改用舊欄位補值。
- 這四筆資料是虛構的,不代表客戶、真實事故或實測產品效能。
推薦儀表板
- 表格:依版本顯示已完成任務數、耗時覆蓋率與平均值
- 趨勢:部署前後的耗時欄位覆蓋率
設定此查詢需要的事件
相關埋點和指南
繼續分析
在你的事件上執行
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。