권장사항

다음 권장사항에서는 개인 정보 보호를 중시하고 성능이 우수한 쿼리를 개발하는 기법을 설명합니다.

개인 정보 보호 및 데이터 정확성

샌드박스 데이터에 대한 쿼리 개발

권장사항: 프로덕션 단계에 있을 때만 프로덕션 데이터를 쿼리합니다.

가능한 경우 쿼리 개발 중에는 샌드박스 데이터를 활용합니다. 샌드박스 데이터를 사용해도 데이터 차이 검사에서 쿼리 결과를 추가로 필터링할 수 있는 것은 아닙니다. 또한 개인 정보 보호 검사가 없어 샌드박스 쿼리가 더 빠르게 실행되므로 쿼리 개발 중에 더 빨리 반복할 수 있습니다.

실제 데이터에 대한 쿼리를 개발해야 하는 경우(예: 데이터 이동 색인을 사용하는 경우) 행이 중복될 가능성을 줄이려면 쿼리를 반복할 때마다 중복될 가능성이 작은 기간 및 기타 매개변수를 선택하세요. 마지막으로 원하는 데이터 범위에 대해 쿼리를 실행합니다.

이전 결과를 신중하게 고려

권장사항: 최근 실행한 쿼리 간에 결과 집합이 중복될 가능성을 줄입니다.

쿼리 결과 간의 변화율은 개인 정보 보호 검사로 인해 나중에 결과가 누락될 가능성에 영향을 미친다는 점에 유의하세요. 최근에 반환된 결과 집합과 매우 유사한 두 번째 결과 집합이 삭제될 수 있습니다.

대신 쿼리의 주요 매개변수(예: 기간 또는 캠페인 ID)를 수정하여 큰 중복 가능성을 줄입니다.

오늘의 데이터를 쿼리하지 않음

권장사항: 종료일이 오늘인 여러 개의 쿼리를 실행하지 않습니다.

종료일이 오늘인 여러 개의 쿼리를 실행하면 행이 필터링되는 경우가 많습니다. 이 지침은 어제의 데이터에 대해 자정 직후에 쿼리를 실행하는 경우에도 적용됩니다.

동일한 데이터를 필요 이상으로 쿼리하지 않음

권장사항:

  • 밀접하게 결합된 시작일과 종료일을 선택합니다.
  • 중복된 기간을 쿼리하는 대신 분리된 데이터 세트에서 쿼리를 실행한 다음 BigQuery에서 결과를 집계합니다.
  • 쿼리를 다시 실행하는 대신 저장된 결과를 사용합니다.
  • 쿼리하는 각 기간에 대한 임시 테이블을 만듭니다.

Ads Data Hub에서는 동일한 데이터를 쿼리할 수 있는 총횟수가 제한됩니다. 따라서 특정 데이터에 액세스하는 횟수를 제한해야 합니다.

동일한 쿼리에서 필요 이상으로 많은 집계를 사용하지 않음

권장사항:

  • 쿼리의 집계 수 최소화
  • 가능한 경우 쿼리를 다시 작성하여 집계 통합

Ads Data Hub에서는 서브 쿼리에서 사용할 수 있는 교차 사용자 집계 수를 100개로 제한합니다. 따라서 일반적인 그룹화 키와 복잡한 집계를 사용하는 열을 많이 출력하는 것보다 구체적인 키 그룹화와 단순한 집계를 사용하여 더 많은 행을 출력하는 쿼리를 작성하는 것이 좋습니다. 다음 패턴은 피해야 합니다.

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

동일한 필드 집합에 따라 이벤트를 집계하는 쿼리는 GROUP BY 문을 사용하여 다시 작성해야 합니다.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

BigQuery에서도 동일한 방식으로 결과를 집계할 수 있습니다.

하나의 배열에서 여러 열을 만든 후 나중에 집계하는 쿼리의 경우 다시 작성하여 이러한 단계를 병합해야 합니다. 

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

이전 쿼리를 다음과 같이 다시 작성할 수 있습니다.

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

서로 다른 집계에서 다양한 필드를 조합하여 사용하는 쿼리를 더욱 구체적인 여러 쿼리로 재작성할 수 있습니다.

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

이전 쿼리는 다음으로 나눌 수 있습니다.

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

및

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

이러한 결과를 별도의 쿼리로 나누거나, 단일 쿼리에서 테이블을 만들어 조인하거나, 스키마가 호환되는 경우 UNION과 결합할 수 있습니다.

조인 최적화 및 이해

권장사항: INNER JOIN 대신 LEFT JOIN을 사용하여 클릭 또는 전환을 노출로 조인합니다.

모든 노출이 클릭 또는 전환과 연결되는 것은 아닙니다. 따라서 노출에서 클릭 또는 전환을 INNER JOIN하면 클릭 또는 전환과 연결되지 않은 노출이 결과에서 필터링됩니다.

벤 다이어그램을 통해 여러 조인 유형을 보여주는 이미지

BigQuery에서 최종 결과 조인

권장사항: 집계된 결과를 조인하는 Ads Data Hub 쿼리를 사용하지 않습니다. 대신 별도의 쿼리 2개를 작성하고 BigQuery에서 결과를 조인합니다.

집계 요구사항을 충족하지 않는 행은 결과에서 필터링됩니다. 따라서 쿼리가 불충분하게 집계된 행과 충분히 집계된 행을 조인하면 결과 행이 필터링됩니다. 또한 여러 집계가 있는 쿼리는 Ads Data Hub에서 성능이 떨어집니다.

Ads Data Hub의 여러 집계 쿼리의 결과를 BigQuery에서 조인할 수 있습니다. 일반 쿼리를 사용하여 계산된 결과는 최종 스키마를 공유합니다.

다음 쿼리는 개별 Ads Data Hub 결과(campaign_data_123 및 campaign_data_456)를 가져와 BigQuery에서 조인합니다.

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

필터링된 행 요약 사용

권장사항: 쿼리에 필터링된 행 요약을 추가합니다.

필터링된 행 요약은 개인 정보 보호 검사로 인해 필터링된 데이터를 집계합니다. 필터링된 행의 데이터가 합산되어 포괄 행에 추가됩니다. 필터링된 데이터는 추가로 분석할 수 없지만 결과에서 필터링된 데이터 양에 대한 요약 정보는 확인할 수 있습니다.

0으로 설정된 사용자 ID 고려

권장사항: 결과에서 0으로 설정된 사용자 ID를 고려합니다.

광고 개인 최적화 선택 해제, 규제상의 이유 등 여러 가지 이유로 최종 사용자의 ID가 0으로 설정될 수도 있습니다. 따라서 여러 사용자가 생성한 데이터가 user_id 0에 입력됩니다.

총노출수 또는 클릭수 등의 데이터 총계를 이해하려면 이러한 이벤트를 포함해야 합니다. 그러나 이 데이터는 고객에 관한 통계를 얻는 데는 유용하지 않으므로 이러한 분석을 하는 경우에는 필터링해야 합니다.

쿼리에 WHERE user_id != "0"을 추가하여 결과에서 이 데이터를 제외할 수 있습니다.

성능

재집계 방지

권장사항: 사용자 간에 여러 집계 레이어를 사용하지 않습니다.

여러 GROUP BY를 사용하는 쿼리 또는 중첩된 집계와 같이 이미 집계된 결과를 결합하는 쿼리를 처리하려면 더 많은 리소스가 필요합니다.

여러 집계 레이어를 사용하는 쿼리를 구분하여 성능을 개선할 수 있는 경우가 많습니다. 처리하는 동안 이벤트 또는 사용자 수준에서 행을 유지한 다음 단일 집계와 결합해야 합니다.

다음 패턴은 피해야 합니다.

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

여러 집계 레이어를 사용하는 쿼리는 단일 집계 레이어를 사용하도록 다시 작성해야 합니다.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

쉽게 구분할 수 있는 쿼리는 나눠야 합니다. BigQuery에서 결과를 조인할 수 있습니다.

BigQuery에 최적화

일반적으로 더 적은 수의 작업을 실행하는 쿼리의 성능이 더 좋습니다. 쿼리 성능을 평가할 때 필요한 작업량은 다음과 같은 요인에 따라 달라집니다.

쿼리 실행이 서비스수준계약을 충족하지 않거나 리소스 고갈 또는 시간 초과로 인해 오류가 발생한 경우 다음을 고려하세요.

  • 다시 계산하는 대신 이전 쿼리의 결과를 사용합니다. 예를 들어 주간 총계를 BigQuery에서 7일 집계 쿼리의 합계로 계산할 수 있습니다.
  • 쿼리를 논리적 서브 쿼리로 분해(예: 여러 조인을 여러 쿼리로 분할)하거나 처리 중인 데이터 세트를 다른 방식으로 제한합니다. 개별 작업의 결과를 BigQuery에서 단일 데이터 세트로 결합할 수 있습니다. 이렇게 하면 리소스 소진을 늦출 수 있지만 쿼리 속도가 느려질 수 있습니다.
  • BigQuery에서 리소스 초과 오류가 발생하는 경우 임시 테이블을 사용하여 쿼리를 여러 BigQuery 쿼리로 분할해 보세요.
  • 단일 쿼리에서 더 적은 수의 테이블을 참조하면 많은 양의 메모리를 사용하므로 쿼리가 실패할 수 있습니다.
  • 더 적은 수의 사용자 테이블을 조인하도록 쿼리를 다시 작성합니다.
  • 동일한 테이블이 다시 조인되지 않도록 쿼리를 다시 작성합니다.

쿼리 어드바이저

SQL은 유효하지만 과도한 필터링을 트리거할 수 있는 경우 원치 않는 결과를 피할 수 있도록 쿼리 어드바이저가 쿼리 개발 프로세스 중에 실행 가능한 조치를 표시합니다.

트리거에는 다음과 같은 패턴이 포함됩니다.

쿼리 어드바이저를 사용하려면 다음 안내를 따르세요.