기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

비교 제어

SQL에서 리터럴 비교는 데이터 세트의 열을 쿼리에 직접 입력된 리터럴 값과 일치시킵니다. 열 비교는 동일한 테이블 내에서 또는 조인된 테이블 간에 서로 다른 두 열의 값을 일치시킵니다.

기본 동작

비교 컨트롤은 허용 목록입니다. 를 설정한 후에는 나열한 열allowedLiteralComparisonColumns만 리터럴 값과 비교할 수 있으며 나열하지 않은 모든 열은 차단됩니다. column-to-column 비교의 allowedColumnComparisonColumns 경우에도에 적용됩니다. 한 허용 목록에 열을 추가해도 다른 허용 목록에는 추가되지 않습니다.

를 구성하지 않으면 비교 제한이 comparisonControls AWS Clean Rooms 적용되지 않습니다. 쿼리는 모든 열을 리터럴 값 또는 다른 열과 비교할 수 있습니다.

를 구성하지 comparisonControls 않지만 최소 집계 임계값을 설정하면 비교가 제한되지 않습니다. 그러나에 나열된 열에 대한 리터럴 비교를 허용하지 AWS Clean Rooms 않습니다identityColumns. 이러한 제한은 임계값 자체에서 비롯되므로 비교 제어를 구성하는지 여부에 관계없이 적용됩니다. 자세한 내용은 최소 집계 임계값 단원을 참조하십시오.

허용되지 않는 출력 열과 comparisonControls 함께를 구성하는 경우 두 컨트롤은 독립적이며 둘 다 적용됩니다. 비교 제어는 쿼리가 비교할 수 있는 열을 제어하고, 허용되지 않는 출력 열은 쿼리 결과에 나타날 수 있는 열을 제어합니다. 비교에서 열을 허용해도 결과에서 계속 금지할 수 있습니다. 자세한 내용은 허용되지 않는 출력 열 단원을 참조하십시오.

리터럴 비교

리터럴 비교는 하드코딩된 단일 상수(문자열, 숫자 또는 날짜)를 기준으로 열을 평가합니다. 쿼리 실행 중에는 연산자의 오른쪽이 변경되지 않습니다. 구문 예제는 다음과 같습니다.

최소 집계 임계값를 사용하는 경우 identityColumns 값에 대한 리터럴 비교를 허용하지 AWS Clean Rooms 않습니다. 이렇게 하면 쿼리 실행기가 개별 또는 특정 사용자 집합으로 필터링된 쿼리를 제출할 수 없습니다. 소그룹 또는 개별 데이터 주체를 제거할 수 있는 낮은 카디널리티 열에서 리터럴 비교를 허용하지 마세요.

{
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "status",
      "price"
    ]
  }
}

예: 캠페인 열에서 리터럴 비교 허용

게시자는 모든 출력 행이 최소 100명의 개별 사용자()를 나타내도록 최소 집계 임계값으로 사용자 지정 분석 규칙을 구성합니다user_id. 광고주는이 테이블에 대해 쿼리를 실행하지만 분석 범위를 특정 광고 캠페인으로 지정해야 합니다. 예를 들어 한 번에 하나의 캠페인에 대한 도달 범위를 측정해야 합니다.

user_id는 자격 증명 열이므로 리터럴과 비교할 수 없으므로 광고주는 결과를 단일 사용자로 필터링할 수 없습니다. 그러나 campaign_id 및 event_date는 카디널리티가 높고 식별되지 않는 차원이므로 게시자는 이를에 추가하므로 광고주는 캠페인별로 필터링하고 분석 범위를 날짜 범위로 지정할 수 allowedLiteralComparisonColumns있습니다.

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id", "event_date"]
  }
}

이전 구성을 고려할 때이 쿼리는 허용됩니다.

-- Allowed: campaign_id and event_date are both in allowedLiteralComparisonColumns
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE campaign_id = 'CMP-1024'
  AND event_date >= '2026-01-01'
GROUP BY campaign_id;

동일한 구성을 고려할 때이 쿼리는 차단됩니다.

-- Blocked: user_id is the identity column and can never be compared to a literal
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE user_id = 'U-88231'
GROUP BY campaign_id;

첫 번째 쿼리는 여전히 최소 100명의 개별 사용자가 지원하는 행만 반환하는 반면, 리터럴 비교campaign_id는 고려되는 행을 event_date 필터링합니다. 두 번째 쿼리는 개별 데이터 주체를 제거하려고 시도하기 때문에 거부됩니다.

열 비교

열 비교는 모든 단일 행에 대해 한 열의 값을 다른 열의 값과 동적으로 평가합니다. 구문 예제는 다음과 같습니다.

최소 집계 임계값를 사용할 때 데이터 공급자는 대상 중복 보고서와 같이 테이블 간에 조인해야 하는 사용 사례의 identityColumns 값에 대한 열 비교를 허용할 수 있습니다.

{
  "comparisonControls": {
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  }
}

예: 중복 보고서의 자격 증명 열에 대한 열 비교 허용

게시자와 광고주는 개별 사용자가 누구인지 어느 당사자도 학습하지 않고 두 데이터 세트에 표시되는 사용자 수와 같은 대상 중복을 측정하려고 합니다. 이를 위해서는 column-to-column 비교user_id인에서 두 테이블을 조인해야 합니다. 게시자를 통해 광고주는 특정 캠페인 IDs.

user_id는 자격 증명 열이므로 게시자는 이미 리터럴 비교를 차단했습니다(따라서 아무도 특정 개인으로 필터링할 수 없음). 테이블 간 조인을 활성화하기 위해 게시자는에 user_id를 추가합니다allowedColumnComparisonColumns. 캠페인 필터링을 활성화하기 위해 게시자는에 campaign_id를 추가합니다allowedLiteralComparisonColumns.

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id"],
    "allowedColumnComparisonColumns": ["user_id"]
  }
}

이전 구성을 고려할 때이 쿼리는 허용됩니다.

-- Allowed: user_id is compared against another column (column-to-column join)
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
ON p.user_id = a.user_id;

동일한 구성을 고려할 때이 쿼리는 차단됩니다.

-- Blocked: email is not in allowedColumnComparisonColumns
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
  ON p.email = a.email;

column-to-column 비교는 행별로 동적으로 평가되고 쿼리 실행기가 알려진 값을 대상으로 지정하지 않기 때문에 조인이 성공합니다. 결과는 최소 집계 임계값을 적용하여 중첩 수가 최소 100명의 개별 사용자를 나타내는 경우에만 반환되도록 합니다. 가 allowedColumnComparisonColumns 허용 목록에 없고 비교에 사용할 수 없으므로 두 번째 쿼리email는 차단됩니다. 만 사용할 user_id 수 있습니다.

비교 제어 및 표현식

비교 제어는 직접 WHERE column = 'literal' 조건자뿐만 아니라 간접 리터럴 비교를 따릅니다. 를 통해 집계 함수 ANY_EXPRESSION 내부를 허용하는 경우 allowedAggregateExpressionType비교 제어는에 없는 열에 대한 리터럴 비교를 여전히 차단합니다allowedLiteralComparisonColumns. 이는 리터럴이 표현식 내에 중첩된 경우에도 적용됩니다.

다음 예제에서는 리터럴이 직접 조건자로 작성zip_code되지 않고 CASE 표현식 내에 있더라도가 허용 목록에 없기 때문에 차단된 상태로 유지되는 쿼리를 보여줍니다.

-- Blocked: zip_code is not in allowedLiteralComparisonColumns,
-- even though the literal comparison is nested inside a CASE expression
SELECT SUM(CASE WHEN zip_code = '00001' THEN salary ELSE 0 END) AS total
FROM employees;

이것이 두 컨트롤이 보완적인 이유입니다. 집계 내에서 표현식을 허용하면 쿼리가 계산할 수 있는 범위가 넓어지는 반면 비교 컨트롤은 쿼리가 값별로 구분할 수 있는 열을 여전히 제한합니다. 자세한 내용은 집계 함수에서 중첩 표현식 허용 단원을 참조하십시오.