探索和視覺化結構化事件

它是如何運作的

從訊號到決策的可審查工作流程

首先檢查樣品

在聚合欄位之前確認欄位包含預期的值和型別。這可以及早發現埋點錯誤。

選擇公制和粒度

選擇與問題匹配的聚合、數字欄位、時間段和過濾器。請記住不完整的最新儲存桶。

推廣有用的觀點

當結果成為重複工作流程的一部分時，將結果新增到儀表板或警示中。使用 Query 實現多資料表和多 CTE 邏輯。

探索結構化事件

真實的產品捕獲從事件樣本到過濾器、聚合和視覺結果。

邊界

這不能取代什麼

Explore 針對單資料表調查進行了最佳化；連線、多個 CTE 和可重用的分析定義屬於 Query。
海圖無法彌補不完整的儀表、混合單位或不穩定的路線和事件名稱。
高基數原始識別符號更適合用於受限的向下鑽取，而不是用作頂級圖表維度。

可檢查的證明路徑

從事件契約到可見的答案

此範例使用宣告的架構、只讀 SQL 和確定性合成結果。它示範了工作流程，但沒有提供範例資料作為客戶基準。

1. 活動合約

一排進入 api_requests，並明確查詢所使用的型別。

timestamp_utc: Timestamp
route_template: Utf8
status_code: Int64
latency_ms: Float64

瀏覽活動合約

2.只讀SQL

哪些 API 路由具有最高的有意義 5xx 錯誤率？

SELECT
  route_template,
  COUNT(*) AS requests,
  SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors,
  100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
HAVING COUNT(*) >= 20
ORDER BY error_rate_pct DESC
LIMIT 10;