구조적 이벤트를 위한 SQL 중복 제거

중복 제거는 SQL 문제이기 이전에 비즈니스 정의 문제입니다. 유사해 보이는 두 개의 이벤트는 중복된 배달, 의도적인 재시도 또는 두 개의 유효한 사용자 작업을 나타낼 수 있습니다. 논리적 이벤트 또는 전달에 대한 소스 생성 식별자로 시작합니다. 프로듀서 계약에서 조합이 고유하다고 보장하지 않는 한 타임스탬프와 메시지 문자열에서 ID를 추론하지 마세요.

각 안정적인 식별자에 대해 하나의 행을 선택하세요.

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 중복 레시피를 사용하여 소스 중복을 정량화하고 창 기능을 사용하여 순위 연산을 이해합니다. 이벤트 스키마 가이드에서는 규칙을 감사 가능하게 만드는 식별자를 추가하는 방법을 설명합니다.