使用 SQL 對結構化事件去重

重複資料刪除首先是一個業務定義問題，然後才是一個 SQL 問題。兩個看起來相似的事件可能表示重複傳遞、有意重試或兩個有效的使用者操作。從源生成的邏輯事件或交付識別符號開始。不要從時間戳和訊息字串推斷身分，除非生產者合約保證該組合是唯一的。

為每個穩定識別符號選擇一行

WITH ranked AS (
  SELECT
    event_id,
    account_id,
    event_name,
    timestamp_utc,
    received_at,
    ROW_NUMBER() OVER (
      PARTITION BY event_id
      ORDER BY received_at ASC
    ) AS delivery_rank
  FROM product_events
  WHERE timestamp_utc >= now() - INTERVAL '7 days'
)
SELECT
  account_id,
  event_name,
  timestamp_utc
FROM ranked
WHERE delivery_rank = 1;

此版本保留第一個收到的副本。狀態同步資料表可能會保留最新記錄。將選擇寫在查詢旁邊，因為更改順序會更改結果的含義。

在刪除重複項之前測量它們

計算原始行、不同識別符號以及多次交付的識別符號。當這些維度可以識別來源時，按生產商、SDK 版本、發布或交付路徑細分結果。重複資料刪除 CTE 可以使下游儀表板正確，同時隱藏日益嚴重的攝取問題。

不要單獨對 account_id 和 event_name 進行重複資料刪除。一個帳戶可以合法地多次完成同一操作。同樣，當問題是可靠性時，即使產品轉化只計算最終的成功結果，重試也可能是有效的分析事件。

晚期事件需要有界的修正視窗。報告匯出後到達的副本可能會更改最終計數，因此請記錄報告截止日期以及結果是否是臨時的。

使用 重複的事件 ID 配方 量化源重複，使用 視窗函式 瞭解排名操作。 事件架構指南 解釋瞭如何新增使規則可審查的識別符號。