기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS Clean Rooms란 무엇인가요? AWS Clean Rooms 를 사용하면 사용자와 파트너가 집합 데이터 세트를 분석하고 공동 작업하여 기본 데이터를 서로 공개하지 않고도 새로운 인사이트를 얻을 수 있습니다. AWS Clean Rooms 는 몇 분 만에 자체 클린룸을 생성하고 몇 단계만으로 집합 데이터 세트를 분석하는 안전한 공동 작업 영역입니다. 협업할 파트너를 선택하고, 데이터 세트를 선택하고, 해당 파트너에 대한 개인 정보 보호 강화 제어를 구성합니다. AWS Clean Rooms를 사용하면 이미 사용 중인 수천 개의 회사와 협업할 수 있습니다 AWS. 공동 작업에서는 데이터를 다른 클라우드 서비스 공급자로 이동 AWS 하거나 로드할 필요가 없습니다. 쿼리 또는 작업을 실행할 때는 해당 데이터의 원래 위치에서 데이터를 AWS Clean Rooms 읽고 기본 제공 분석 규칙을 적용하여 해당 데이터에 대한 제어를 유지하는 데 도움이 됩니다. AWS Clean Rooms 는 구성할 수 있는 기본 제공 데이터 액세스 제어 및 감사 지원 제어를 제공합니다. 이러한 제어에는 다음이 포함됩니다. + SQL 쿼리를 제한하고 출력 제약 조건을 제공하는 [분석 규칙](analysis-rules.md)입니다. + [용 암호화 컴퓨팅Clean Rooms](crypto-computing.md)은 쿼리가 처리되더라도 데이터를 암호화하여 엄격한 데이터 처리 정책을 준수합니다. + 에서 쿼리 및 작업을 검토하고 감사를 AWS Clean Rooms 지원하는 [분석 로그](query-logs.md)입니다. + 사용자 식별 시도로부터 보호하기 위한 [차등 프라이버시](differential-privacy.md)입니다. AWS Clean Rooms 차등 프라이버시는 몇 가지 단계에서 적용할 수 있는 수학적으로 지원되는 기술과 직관적인 제어를 통해 사용자의 프라이버시를 보호하는 완전 관리형 기능입니다. + [AWS Clean Rooms ML](machine-learning.md)은 두 당사자가 데이터를 서로 공유할 필요 없이 데이터에서 유사한 사용자를 식별할 수 있도록 허용합니다. 첫 번째 당사자는 훈련 데이터에서 유사 모델을 만들고 구성합니다. 그런 다음 시드 데이터를 공동 작업에 가져와서 훈련 데이터와 유사한 유사 세그먼트를 만듭니다. 다음 동영상에서는에 대해 자세히 설명합니다 AWS Clean Rooms. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/0S6icreVCO0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/0S6icreVCO0) ## 처음 AWS Clean Rooms 사용하시나요? 를 처음 사용하는 경우 먼저 다음 섹션을 읽는 것이 AWS Clean Rooms좋습니다. + [AWS Clean Rooms 작동 방식](#how-it-works) + [액세스 AWS Clean Rooms](#accessing-service) + [설 AWS Clean Rooms정](setting-up.md) + [AWS Clean Rooms 용어집](glossary.md) ## AWS Clean Rooms 작동 방식 에서 공동 작업을 AWS Clean Rooms생성하고 초대하려는 AWS 계정 를 추가하거나 초대받은 공동 작업에 참여할 멤버십을 생성합니다. 그런 다음 이벤트 데이터에 대해 구성된 테이블, ML 모델링에 대해 구성된 모델 또는 엔터티 확인을 위한 ID 네임스페이스 등 사용 사례에 필요한 데이터 리소스를 연결합니다. 분석 템플릿을 생성하거나 승인하여 공동 작업에서 허용하려는 정확한 쿼리 및 작업에 미리 동의할 수 있습니다. 마지막으로 구성된 테이블에서 SQL 쿼리 또는 PySpark 작업을 실행하거나, ID 매핑 테이블에서 개체 확인을 수행하거나, ML 모델링을 사용하여 유사 대상 세그먼트를 생성하여 관절 데이터를 분석합니다. 다음 다이어그램은의 AWS Clean Rooms 작동 방식을 보여줍니다. ![\[AWS Clean Rooms 작동 방식을 설명하는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/images/how-it-works.png) ## 관련 서비스 ### AWS 서비스 다음은 다음과 AWS 서비스 관련이 있습니다 AWS Clean Rooms. + **Amazon Athena** 공동 작업 구성원은 Amazon Athena에서 AWS Glue Data Catalog 뷰 AWS Clean Rooms 로 가져온 데이터를 저장할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요. 자세한 내용은 다음 항목을 참조하세요. [에서 쿼리를 위한 데이터 테이블 준비 AWS Clean Rooms](prepare-data.md) [구성된 테이블 생성 - Amazon Athena 데이터 소스](create-config-table-athena.md) [Amazon Athena 사용 설명서의 Amazon Athena란 무엇인가요?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) *Amazon Athena * + **CloudFormation** 에서 공동 CloudFormation작업, 구성된 테이블, 구성된 테이블 연결 및 멤버십 리소스를 생성합니다. 자세한 내용은 [를 사용하여 AWS Clean Rooms 리소스 생성 AWS CloudFormation](creating-resources-with-cloudformation.md) 단원을 참조하십시오. + **AWS CloudTrail** CloudTrail 로그 AWS Clean Rooms 와 함께를 사용하여 AWS 서비스 활동 분석을 개선합니다. 자세한 내용은 [를 사용하여 AWS Clean Rooms API 호출 로깅 AWS CloudTrail](logging-using-cloudtrail.md) 단원을 참조하십시오. + **AWS Entity Resolution** 와 AWS Clean Rooms 함께 AWS Entity Resolution 를 사용하여 개체 확인을 수행합니다. 자세한 내용은 [AWS Entity Resolution in AWS Clean Rooms](working-with-entity-resolution.md) 단원을 참조하십시오. + **AWS Glue** 공동 작업 구성원은에서 사용할 Amazon S3의 데이터에서 AWS Glue 테이블을 생성할 수 있습니다 AWS Clean Rooms. 자세한 내용은 다음 항목을 참조하세요. [에서 쿼리를 위한 데이터 테이블 준비 AWS Clean Rooms](prepare-data.md) AWS Glue 개발자 가이드의 [AWS Glue(이)란 무엇인가요?](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html)** + **Amazon Simple Storage Service(Amazon S3)** 공동 작업 구성원은 Amazon S3 AWS Clean Rooms 에서 가져온 데이터를 저장할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요. [에서 쿼리를 위한 데이터 테이블 준비 AWS Clean Rooms](prepare-data.md) [구성된 테이블 생성 - Amazon S3 데이터 소스](create-config-table-s3.md) *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3란 무엇입니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) + **AWS Secrets Manager** 공동 작업 구성원은 보안 암호를 생성하여 Snowflake에 저장된 데이터에 액세스하고 읽을 수 있습니다. 자세한 내용은 다음 항목을 참조하세요. [서비스 역할을 생성하여 Snowflake에서 데이터 읽기](setting-up-roles.md#create-service-role-third-party) [에서 쿼리를 위한 데이터 테이블 준비 AWS Clean Rooms](prepare-data.md) *AWS Secrets Manager 사용 설명서*의 [AWS Secrets Manager란 무엇입니까?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) ### 타사 서비스 다음 타사 서비스는 AWS Clean Rooms다음과 관련이 있습니다. + **Snowflake** 공동 작업 구성원은 Snowflake 웨어하우스 AWS Clean Rooms 에 가져온 데이터를 저장할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요. [에서 쿼리를 위한 데이터 테이블 준비 AWS Clean Rooms](prepare-data.md) [구성된 테이블 생성 - Snowflake 데이터 소스](create-config-table-snowflake.md) ## 액세스 AWS Clean Rooms 다음 옵션을 AWS Clean Rooms 통해에 액세스할 수 있습니다. + [https://console.aws.amazon.com/cleanrooms/](https://console.aws.amazon.com/cleanrooms/) AWS Clean Rooms 콘솔을 통해 직접. + AWS Clean Rooms API를 통해 프로그래밍 방식으로. 자세한 내용은 [https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)를 참조하세요. ## 에 대한 요금 AWS Clean Rooms 요금 정보는 [AWS Clean Rooms 요금](https://aws.amazon.com/clean-rooms/pricing/)을 참조하세요. **참고** Snowflake에 저장된 데이터를 연결한 공동 작업 구성원의 경우 해당 위치에 저장된 데이터를 사용하는 쿼리가 실행될 때마다 해당 데이터 웨어하우스 공급자 또는 클라우드 공급자가 데이터 송신 및 컴퓨팅 모두에 대해 요금을 청구합니다. ## 에 대한 결제 AWS Clean Rooms AWS Clean Rooms 는 공동 작업 생성자에게 공동 작업에서 쿼리 또는 작업 컴퓨팅 비용을 지불할 구성원을 지정할 수 있는 기능을 제공합니다. 대부분의 경우 [쿼리를 할 수 있는 구성원](glossary.md#glossary-member-who-can-query)과 [쿼리 컴퓨팅 비용을 지불하는 구성원](glossary.md#glossary-member-paying-for-query-compute)은 동일합니다. 하지만 쿼리를 할 수 있는 구성원과 쿼리 계산 비용을 지불하는 구성원이 다르면 쿼리를 할 수 있는 구성원이 자신의 구성원 리소스에 대해 쿼리를 실행하면 쿼리 계산 비용을 지불하는 구성원의 구성원 리소스에 요금이 청구됩니다. 쿼리 컴퓨팅 비용을 지불하는 회원은 CloudTrail Event 기록에서 쿼리가 실행되는 이벤트를 볼 수 없습니다. 지불자가 쿼리를 실행하는 사람도 아니고 쿼리가 실행되는 리소스의 소유자도 아니기 때문입니다. 그러나 지급인은 공동 작업에서 쿼리를 실행할 수 있는 구성원이 실행하는 모든 쿼리에 대해 멤버십 리소스에 생성된 요금을 볼 수 있습니다. 컬래버레이션을 생성하고 구성원이 쿼리 컴퓨팅 비용을 지불하도록 구성하는 방법에 대한 자세한 내용은 [공동 작업 생성](create-collaboration.md) 섹션을 참조하세요. # 의 분석 규칙 AWS Clean Rooms 공동 작업 분석에에서 테이블을 사용할 수 있도록 하기 AWS Clean Rooms 위해 공동 작업 구성원은 *분석 규칙을* 구성해야 합니다. 분석 규칙은 각 데이터 소유자가 구성된 테이블에 설정하는 개인 정보 보호 강화 컨트롤입니다. 분석 규칙은 구성된 테이블을 분석할 수 있는 방법을 결정합니다. 분석 규칙은 구성된 테이블(계정 수준 리소스)의 계정 수준 컨트롤이며, 구성된 테이블이 연결된 모든 공동 작업에 적용됩니다. 구성된 분석 규칙이 없는 경우 구성된 테이블을 공동 작업에 연결할 수는 있지만 쿼리할 수는 없습니다. 쿼리는 분석 규칙 유형이 동일한 구성된 테이블만 참조할 수 있습니다. 분석 규칙을 구성하려면 먼저 분석 유형을 선택한 다음 분석 규칙을 지정합니다. 두 단계 모두에서 활성화하려는 사용 사례와 기본 데이터를 보호하는 방법을 고려해야 합니다. AWS Clean Rooms 는 쿼리에서 참조되는 구성된 모든 테이블에 대해 보다 제한적인 제어를 적용합니다. 다음 예는 제한적 제어를 설명합니다. **Example 제한적 제어: 출력 제약조건** + 협업자 A의 식별자 열에 대한 출력 제한은 100입니다. + 협업자 B의 식별자 열에 대한 출력 제한은 150입니다. 구성된 두 테이블을 모두 참조하는 집계 쿼리의 경우 쿼리 출력에 표시되려면 출력 행 내에 최소 150개의 고유한 식별자 값이 있어야 합니다. 쿼리 출력은 출력 제한으로 인해 결과가 제거되었음을 나타내지 않습니다. **Example 제한적 제어: 분석 템플릿이 승인되지 않았습니다** + 협업자 A는 사용자 지정 분석 규칙에서 협업자 A와 협업자 B의 구성된 테이블을 참조하는 쿼리가 포함된 분석 템플릿을 허용했습니다. + 협업자 B는 분석 템플릿을 허용하지 않았습니다. 협업자 B가 분석 템플릿을 허용하지 않았기 때문에 쿼리할 수 있는 구성원은 해당 분석 템플릿을 실행할 수 없습니다. ## 분석 규칙 유형 분석 규칙에는 [집계](analysis-rules-aggregation.md), [목록](analysis-rules-list.md), [사용자](analysis-rules-custom.md) 지정의 세 가지 유형이 있습니다. 다음 표는 분석 규칙 유형을 비교합니다. 각 유형에는 분석 규칙 지정을 설명하는 별도의 섹션이 있습니다. **참고** ID 매핑 테이블 분석 규칙이라는 분석 규칙 유형이 있습니다. 그러나이 분석 규칙은에서 관리 AWS Clean Rooms 하며 수정할 수 없습니다. 자세한 내용은 [ID 매핑 테이블 분석 규칙](analysis-rules-id-mapping-table.md) 단원을 참조하십시오. 다음 단원에서는 분석 규칙 유형별 지원되는 사용 사례 및 컨트롤에 대해 설명합니다. ### 지원되는 사용 사례 다음 표에는 각 분석 규칙 유형별로 지원되는 사용 사례를 비교한 요약이 나와 있습니다. | 사용 사례 | [집계](analysis-rules-aggregation.md) | [목록](analysis-rules-list.md) | [사용자 지정](analysis-rules-custom.md) | | --- | --- | --- | --- | | 지원되는 분석 | 필요에 따라 측정기준과 함께 COUNT, SUM, AVG 함수를 사용하여 통계를 집계하는 쿼리 | 여러 테이블 간의 겹침에 대한 행 수준 목록을 출력하는 쿼리 | 모든 사용자 지정 분석(분석 템플릿 또는 분석 생성자가 검토되고 허용된 경우에 한함) | | 일반 사용 사례 | 세그먼트 분석, 측정, 속성 | 강화, 세그먼트 구축 | 퍼스트 터치 어트리뷰션, 증분 분석, 오디언스 디스커버리 | | SQL 구조 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules.html) | SELECT 명령으로 대부분의 SQL 함수 및 SQL 구문을 사용할 수 있습니다 | | 하위 쿼리 및 공통 테이블 표현식(CTE) | 아니요 | 아니요 | 예 | | 분석 템플릿 | 아니요 | 아니요 | 예 | ### 지원되는 컨트롤 다음 표는 각 분석 규칙 유형이 기본 데이터를 보호하는 방법을 비교 요약한 것입니다. | 컨트롤 | [집계](analysis-rules-aggregation.md) | [목록](analysis-rules-list.md) | [사용자 지정](analysis-rules-custom.md) | | --- | --- | --- | --- | | 제어 메커니즘 | 테이블의 데이터를 쿼리에 사용할 수 있는 방법을 제어합니다(예를 들어, hashed\$1email 열의 개수 및 합계를 허용합니다.)** | 테이블의 데이터를 쿼리에 사용할 수 있는 방법을 제어합니다(예를 들어, hashed\$1email 열은 조인에만 사용할 수 있습니다.)** | 테이블에서 실행할 수 있는 쿼리를 제어합니다(예: 분석 템플릿 "사용자 지정 쿼리 1"에 정의된 쿼리만 허용)** | | 기본 제공되는 개인 정보 보호 강화 기술 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules.html) | | 쿼리를 실행하기 전에 검토하세요 | 아니요 | 아니요 | 예, 분석 템플릿 사용 | 에서 사용할 수 있는 분석 규칙에 대한 자세한 내용은 다음 주제를 AWS Clean Rooms참조하세요. + [집계 분석 규칙](analysis-rules-aggregation.md) + [목록 분석 규칙](analysis-rules-list.md) + [의 사용자 지정 분석 규칙 AWS Clean Rooms](analysis-rules-custom.md) # 집계 분석 규칙 에서 *집계 분석 규칙* AWS Clean Rooms은 선택적 차원과 함께 COUNT, SUM 및/또는 AVG 함수를 사용하여 집계 통계를 생성합니다. 구성된 테이블에 집계 분석 규칙을 추가하면 쿼리를 할 수 있는 구성원이 구성된 테이블에서 쿼리를 실행할 수 있습니다. 집계 분석 규칙은 캠페인 계획, 미디어 도달 범위, 빈도 측정, 속성 등의 사용 사례를 지원합니다. 지원되는 쿼리 구조 및 구문은 [집계 쿼리 구조 및 구문](#agg-query-structure-syntax)에 정의되어 있습니다. [집계 분석 규칙 - 쿼리 제어](#agg-query-controls)에 정의된 분석 규칙의 매개 변수에는 쿼리 컨트롤 및 쿼리 결과 컨트롤이 포함됩니다. 쿼리 컨트롤에는 쿼리할 수 있는 구성원이 소유한 하나 이상의 구성된 테이블에 구성된 테이블을 직접 또는 전이적으로 조인하도록 요구하는 기능이 포함됩니다. 이 요구 사항을 통해 쿼리가 테이블과 해당 테이블의 교차점(INNERJOIN)에서 실행되도록 할 수 있습니다. ## 집계 쿼리 구조 및 구문 집계 분석 규칙이 있는 테이블에 대한 쿼리는 다음 구문을 준수해야 합니다. ``` --select_aggregate_function_expression SELECT aggregation_function(column_name) [[AS] column_alias ] [, ...] --select_grouping_column_expression [, {column_name|scalar_function(arguments)} [[AS] column_alias ]][, ...] --table_expression FROM table_name [[AS] table_alias ] [[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...] --where_expression [WHERE where_condition] --group_by_expression [GROUP BY {column_name|scalar_function(arguments)}, ...]] --having_expression [HAVING having_condition] --order_by_expression [ORDER BY {column_name|scalar_function(arguments)} [{ASC|DESC}]] [,...]] ``` 다음 표에서는 위 구문에 나열된 각 표현식에 대해 설명합니다. | 표현식 | 정의 | 예제 | | --- | --- | --- | | select\$1aggregate\$1function\$1expression | 다음 표현식을 포함하는 쉼표로 구분된 쉼표로 구분된 목록입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules-aggregation.html) `select_aggregate_expression`에 `select_aggregation_function_expression`이 하나 이상 있어야 합니다. | `SELECT SUM(PRICE), user_segment` | | select\$1aggregation\$1function\$1expression | 지원되는 집계 함수가 하나 이상의 열에 하나 이상 적용되었습니다. 열만 집계 함수의 인수로 사용할 수 있습니다. `select_aggregate_expression`에 `select_aggregation_function_expression`이 하나 이상 있어야 합니다. | `AVG(PRICE)` `COUNT(DISTINCT user_id)` | | select\$1grouping\$1column\$1expression | 다음을 사용하는 모든 식을 포함할 수 있는 표현식: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules-aggregation.html) `select_aggregate_expression`은 `AS` 매개 변수를 사용하거나 사용하지 않고 열에 별칭을 지정할 수 있습니다. 자세한 내용은 [AWS Clean Rooms SQL 참조](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) 섹션을 참조하세요. | `TRUNC(timestampColumn)` `UPPER(campaignName)` | | table\$1expression | 테이블 또는 테이블의 조인으로, 조인 조건식을 `join_condition`과 연결합니다. `join_condition`은 BOOLEAN을 반환합니다. `table_expression`은 다음을 지원합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules-aggregation.html) | 
FROM consumer_table 
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
| | where\$1expression | 부울을 반환하는 조건식. 다음과 같이 구성될 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules-aggregation.html) 지원되는 비교 조건은 (`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`)입니다. 지원되는 논리 연산자는 (`AND, OR`)입니다. `where_expression`은 선택 사항입니다. | `WHERE where_condition` `WHERE price > 100` `WHERE TRUNC(timestampColumn) = '1/1/2022'` `WHERE timestampColumn = timestampColumn2 - 14` | | group\$1by\$1expression | `select_grouping_column_expression`의 요구 사항과 일치하는 표혁식 목록으로, 쉼표로 구분됩니다. | `GROUP BY TRUNC(timestampColumn), UPPER(campaignName), segment` | | having\$1expression | 조건은 부울 결과가 있는 표현식입니다. 지원되는 집계 함수가 단일 열(예:`SUM(price)`)에 적용되며 숫자 리터럴과 비교됩니다. 지원되는 조건은 (`=, >, <, <=, >=, <>, !=`)입니다. 지원되는 논리 연산자는 (`AND, OR`)입니다. `having_expression`은 선택 사항입니다. | `HAVING SUM(SALES) > 500` | | order\$1by\$1expression | 앞에서 `select_aggregate_expression`에서 정의한 것과 동일한 요구 사항과 호환되는 표현식 목록으로 쉼표로 구분됩니다. `order_by_expression`은 선택 사항입니다. `order_by_expression`은 `ASC`와 `DESC` 매개변수를 허가합니다. 자세한 내용은 [AWS Clean Rooms SQL 참조](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html)의 ASC DESC 매개변수를 참조하세요. | `ORDER BY SUM(SALES), UPPER(campaignName)` | 집계 쿼리 구조 및 구문의 경우 다음 사항에 유의해야 합니다. + SELECT 이외의 SQL 명령은 지원되지 않습니다. + 하위 쿼리 및 공통 테이블 표현식(예:WITH)은 지원되지 않습니다. + 여러 쿼리를 결합하는 연산자(예:UNION)는 지원되지 않습니다. + TOP, LIMIT, 및 OFFSET 파라미터는 지원되지 않습니다. ## 집계 분석 규칙 - 쿼리 제어 집계 쿼리 컨트롤을 사용하면 테이블의 열을 사용하여 테이블을 쿼리하는 방법을 제어할 수 있습니다. 예를 들어 조인에 사용할 열, 계산할 수 있는 열 또는 WHERE 명령문에 사용할 수 있는 열을 제어할 수 있습니다. 다음 단원에서는 각 컨트롤에 대해 설명합니다. **Topics** + [집계 제어](#agg-functions) + [조인 컨트롤](#join-controls) + [치수 제어](#dimension-controls) + [스칼라 함수](#scalar-functions) ### 집계 제어 *집계 제어*를 사용하면 허용할 집계 함수와 해당 집계 함수를 적용해야 하는 열을 정의할 수 있습니다. 집계 함수는 SELECT, HAVING, 및 ORDER BY 표현식에서 사용할 수 있습니다. | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | aggregateColumns | 집계 함수 내에서 사용할 수 있도록 구성된 테이블 열의 열 | `aggregateColumns`은 SELECT, HAVING, 및 ORDER BY 표현식의 집계 함수 내에서 사용할 수 있습니다. 일부 `aggregateColumns`은 `joinColumn`(나중에 정의됨)으로 분류할 수도 있습니다. 주어진 `aggregateColumn`을 `dimensionColumn`(나중에 정의됨)으로도 분류할 수 없습니다. | | function | 카운트, 합계 및 평균 함수는 aggregateColumns 위에서 사용할 수 있습니다. | `function`은 관련된 `aggregateColumns`에 적용할 수 있습니다. | ### 조인 컨트롤 `JOIN` 절은 두 개 이상의 테이블에서 관련 열을 기반으로 두 개 이상의 테이블에서 행을 결합하는 데 사용됩니다. *조인 컨트롤*을 사용하여 테이블을의 다른 테이블에 조인하는 방법을 제어할 수 있습니다`table_expression`. INNER는 AWS Clean Rooms 만 지원합니다JOIN. INNER JOIN 문은 사용자가 정의한 컨트롤에 따라 분석 규칙`joinColumn`에서 로 명시적으로 분류된 열만 사용할 수 있습니다. INNER JOIN은 사용자가 구성한 테이블의 `joinColumn`과 공동 작업의 다른 구성된 테이블의 `joinColumn`에서 작동해야 합니다. 테이블에서 `joinColumn`으로 사용할 수 있는 열을 결정합니다. ON 절의 각 일치 조건은 두 열 간의 등식 비교 조건(`=`)을 사용해야 합니다. ON 절 내의 여러 일치 조건은 다음과 같을 수 있습니다. + `AND` 논리 연산자를 사용하여 조합합니다 + `OR` 논리 연산자를 사용하여 구분합니다 **참고** 모든 JOIN 일치 조건은 JOIN의 각 변의 한 행과 일치해야 합니다. `OR` 또는 `AND` 논리 연산자로 연결된 모든 조건문도 이 요구 사항을 준수해야 합니다. 다음은 `AND` 논리 연산자를 사용한 쿼리의 예입니다. ``` SELECT some_col, other_col FROM table1 JOIN table2 ON table1.id = table2.id AND table1.name = table2.name ``` 다음은 `OR` 논리 연산자를 사용하는 쿼리의 예입니다. ``` SELECT some_col, other_col FROM table1 JOIN table2 ON table1.id = table2.id OR table1.name = table2.name ``` | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | joinColumns | 쿼리를 할 수 있는 구성원이 INNER JOIN 명령문에서 사용할 수 있도록 허용하려는 열(있는 경우) | 특정 `joinColumn`을 `aggregateColumn`으로 분류할 수도 있습니다([집계 제어](#agg-functions) 참조). 동일한 열을 `joinColumn` 및 `dimensionColumns`으로 모두 사용할 수는 없습니다(나중에 참조). `aggregateColumn`으로 분류되지 않는 한, `joinColumn`은 INNER JOIN가 아닌 쿼리의 다른 부분에서는 사용할 수 없습니다. | | joinRequired | 쿼리할 수 있는 멤버에게 구성된 테이블이 있는 INNER JOIN이 필요한지 여부를 제어합니다. | 이 파라미터는 이 지정된 경우에만 INNER JOIN이 필요합니다. 이 매개 변수를 활성화하지 않는 경우 INNER JOIN은 선택 사항입니다. 이 매개 변수를 활성화하면 쿼리할 수 있는 구성원은 자신이 소유한 테이블을 INNER JOIN에 포함해야 합니다. 그들은 직접적으로든 간접적으로든(즉, 그들의 테이블을 다른 테이블에 조인하거나 그것이 자신의 테이블과 조인된 경우) 자신의 테이블과 JOIN해야 합니다 | 다음은 전이성의 예입니다. ``` ON my_table.identifer = third_party_table.identifier .... ON third_party_table.identifier = member_who_can_query_table.id ``` **참고** 쿼리할 수 있는 멤버도 `joinRequired` 파라미터를 사용할 수 있습니다. 이 경우 쿼리는 테이블을 하나 이상의 다른 테이블과 조인해야 합니다. ### 치수 제어 *차원 컨트롤*은 집계 열을 필터링, 그룹화 또는 집계할 수 있는 열을 제어합니다. | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | dimensionColumns | 쿼리할 수 있는 구성원이SELECT,WHERE, GROUP BY 및 ORDER BY에서 사용할 수 있도록 허용하는 열(있는 경우). | `dimensionColumn`은 SELECT(`select_grouping_column_expression`), WHERE, GROUPBY, 및 ORDER BY에서 사용할 수 있습니다. 동일한 열에 `dimensionColumn`, `joinColumn`, 및/또는`aggregateColumn`이 모두 있을 수는 없습니다. | ### 스칼라 함수 *스칼라 함수*는 차원 열에 사용할 수 있는 스칼라 함수를 제어합니다. | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | scalarFunctions | 쿼리의 `dimensionColumns`에서 사용할 수 있는 스칼라 함수. | `dimensionColumns`에 적용할 수 있는 스칼라 함수(있는 경우)를 지정합니다(예:CAST). 스칼라 함수는 다른 함수 위나 다른 함수 내에서 사용할 수 없습니다. 스칼라 함수의 인수는 열, 문자열 리터럴 또는 숫자형 리터럴일 수 있습니다. | 지원되는 스칼라 함수는 다음과 같습니다. + 수학 함수 — AABS, CEILING, FLOOR, LOG, LN, ROUND, SQRT + 데이터 형식 지정 함수 – CAST, CONVERT, TO\$1CHAR, TO\$1DATE, TO\$1NUMBER, TO\$1TIMESTAMP + 문자열 함수 - LOWER, UPPER, TRIM, RTRIM, SUBSTRING + RTRIM의 경우 트리밍할 사용자 정의 문자 세트를 사용할 수 없습니다. + 조건부 표현식 – COALESCE + 날짜 함수 - EXTRACT, GETDATE, CURRENT\$1DATE, DATEADD + 기타 함수 — TRUNC 자세한 내용은 [AWS Clean Rooms SQL 참조](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html)를 참조하세요. ## 집계 분석 규칙 - 쿼리 결과 제어 집계 쿼리 결과 컨트롤을 사용하면 각 출력 행이 충족해야 반환되는 조건을 하나 이상 지정하여 반환되는 결과를 제어할 수 있습니다. AWS Clean Rooms 은 `COUNT (DISTINCT column) >= X`와 같은 형식의 집계 제약 조건을 지원합니다. 이 양식을 사용하려면 각 행이 구성된 테이블에서 선택한 고유한 값을 X개 이상 집계해야 합니다(예: 고유 `user_id` 값의 최소 수). 제출된 쿼리 자체에서 지정된 열을 사용하지 않는 경우에도 이 최소 임계값은 자동으로 적용됩니다. 이 규칙들은 집합적으로 적용되며 쿼리에서 각 구성된 테이블에 걸쳐 적용되며, 공동 작업 참여자 각각의 구성된 테이블을 포함합니다. 구성된 각 테이블의 분석 규칙에는 하나 이상의 집계 제약조건이 있어야 합니다. 구성된 테이블 소유자는 여러 개의 `columnName`과 연결된 `minimum`을 추가할 수 있으며, 이는 일괄적으로 적용됩니다. ### 집계 제약 조건 *집계 제약 조건*은 쿼리 결과에서 반환되는 행을 제어합니다. 행이 반환되려면 집계 제약 조건에 지정된 각 열의 고유 값의 지정된 최소 개수를 충족해야 합니다. 이 요구 사항은 쿼리나 분석 규칙의 다른 부분에서 열이 명시적으로 언급되지 않은 경우에도 적용됩니다. | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | columnName | 각 출력 행이 충족해야 하는 조건에 사용되는 `aggregateColumn`입니다. | 구성된 테이블의 모든 열이 될 수 있습니다. | | minimum | 쿼리 결과에서 반환되기 위해 출력 행에 있어야 하는 연관된 `aggregateColumn`의 최소 고유값 수(예: COUNT DISTINCT)입니다. | `minimum`은 최소 2의 값이어야 합니다. | ## 집계 분석 규칙 구조 다음 예제에서는 집계 분석 규칙의 사전 정의된 구조를 보여줍니다. 다음 예제에서는 데이터 *`MyTable`*은 데이터 테이블을 나타냅니다. *user input placeholder*를 사용자의 정보로 바꿉니다. ``` { "aggregateColumns": [ { "columnNames": [MyTable column names], "function": [Allowed Agg Functions] }, ], "joinRequired": ["QUERY_RUNNER"], "joinColumns": [MyTable column names], "dimensionColumns": [MyTable column names], "scalarFunctions": [Allowed Scalar functions], "outputConstraints": [ { "columnName": [MyTable column names], "minimum": [Numeric value] }, ] } ``` ## 집계 분석 규칙 - 예제 다음 예제에서는 두 회사가 집계 분석을 AWS Clean Rooms 사용하여에서 협업하는 방법을 보여줍니다. 회사 A에는 고객 및 판매 데이터가 있습니다. 회사 A는 제품 반품 활동을 이해하는 데 관심이 있습니다. 회사 B는 회사 A의 소매업체 중 하나이며 반품 데이터를 보유하고 있습니다. 또한 B사는 A에 유용한 고객 세그먼트 속성을 가지고 있습니다(예: 관련 제품 구매, 소매업체의 고객 서비스 이용). 회사 B는 행 수준의 고객 반품 데이터 및 속성 정보를 제공하고 싶지 않습니다. 회사 B는 회사 A가 최소 집계 임계값으로 중복되는 고객에 대한 집계 통계를 얻을 수 있도록 일련의 쿼리를 활성화하려는 것뿐입니다. A사와 B사는 A사가 제품 반품 활동을 이해하고 B사 및 기타 채널에서 더 나은 제품을 제공할 수 있도록 협력하기로 결정했습니다. 공동 작업을 구축하고 집계 분석을 실행하기 위해 회사는 다음과 같은 작업을 수행합니다. 1. 회사 A는 공동 작업을 만들고 멤버십을 생성합니다. 공동 작업에는 회사 B가 협업의 또 다른 구성원으로 포함됩니다. 회사 A는 공동 작업에서 쿼리 로깅을 활성화하고 해당 계정에서 쿼리 로깅을 활성화합니다. 1. 회사 B는 공동 작업을 통해 멤버십을 생성합니다. 이를 통해 해당 계정에서 쿼리 로그인이 가능합니다. 1. 회사 A는 판매 구성 테이블을 생성합니다. 1. 회사 A는 판매 구성 테이블에 다음과 같은 집계 분석 규칙을 추가합니다. ``` { "aggregateColumns": [ { "columnNames": [ "identifier" ], "function": "COUNT_DISTINCT" }, { "columnNames": [ "purchases" ], "function": "AVG" }, { "columnNames": [ "purchases" ], "function": "SUM" } ], "joinColumns": [ "hashedemail" ], "dimensionColumns": [ "demoseg", "purchasedate", "productline" ], "scalarFunctions": [ "CAST", "COALESCE", "TRUNC" ], "outputConstraints": [ { "columnName": "hashedemail", "minimum": 2, "type": "COUNT_DISTINCT" }, ] } ``` `aggregateColumns`— 회사 A는 판매 데이터와 반품 데이터가 겹치는 순 고객 수를 세려고 합니다. 또한 A 회사는 `purchases` 제조 건수를 합산하여 `returns`의 수와 비교하려고 합니다. `joinColumns`— 회사 A는 판매 데이터의 고객과 반품 데이터의 고객을 매칭하는 데 `identifier`를 사용하려고 합니다. 이렇게 하면 회사 A가 올바른 구매에 대한 반품을 매칭하는 데 도움이 됩니다. 또한 A사가 중복되는 고객을 세분화하는 데도 도움이 됩니다. `dimensionColumns`— 회사 A는 특정 제품별로 필터링하고, 일정 기간 동안의 구매 및 반품을 비교하고, 반품 날짜가 제품 날짜 이후인지 확인하고, 중복되는 고객을 분류하기 위해 `dimensionColumns`을 사용합니다. `scalarFunctions`— 회사 A는 회사 A가 공동 작업에 연결하는 구성 테이블을 기반으로 필요한 경우 데이터 유형 형식을 업데이트하는 데 도움이 되는 `CAST` 스칼라 함수를 선택합니다. 또한 필요한 경우 열 서식을 지정하는 데 도움이 되는 스칼라 함수도 추가되었습니다. `outputConstraints`— 회사 A는 최소 출력 제약 조건을 설정합니다. 분석가가 판매 테이블에서 행 수준 데이터를 볼 수 있으므로 결과를 제한할 필요가 없습니다. **참고** 회사 A는 분석 규칙에 `joinRequired`을 포함하지 않습니다. 이를 통해 분석가는 유연하게 판매 테이블만 쿼리할 수 있습니다. 1. 회사 B는 반품 구성 테이블을 생성합니다. 1. 회사 B는 반품 구성 테이블에 다음과 같은 집계 분석 규칙을 추가합니다. ``` { "aggregateColumns": [ { "columnNames": [ "identifier" ], "function": "COUNT_DISTINCT" }, { "columnNames": [ "returns" ], "function": "AVG" }, { "columnNames": [ "returns" ], "function": "SUM" } ], "joinColumns": [ "hashedemail" ], "joinRequired": [ "QUERY_RUNNER" ], "dimensionColumns": [ "state", "popularpurchases", "customerserviceuser", "productline", "returndate" ], "scalarFunctions": [ "CAST", "LOWER", "UPPER", "TRUNC" ], "outputConstraints": [ { "columnName": "hashedemail", "minimum": 100, "type": "COUNT_DISTINCT" }, { "columnName": "producttype", "minimum": 2, "type": "COUNT_DISTINCT" } ] } ``` `aggregateColumns`— 회사 B를 사용하면 회사 A의 합계를 `returns` 구매 건수와 비교할 수 있습니다. 집계 쿼리를 활성화하기 때문에 집계 열이 하나 이상 있습니다. `joinColumns`— 회사 B를 사용하면 회사 A가 `identifier`에 참여하여 반품 데이터에 있는 고객과 판매 데이터를 바탕으로 고객을 매칭할 수 있습니다. `identifier` 데이터는 특히 민감한 데이터이므로 이를 `joinColumn`으로 설정하면 쿼리에서 데이터가 출력되지 않습니다. `joinRequired`— 회사 B에서는 반품 데이터에 대한 쿼리가 판매 데이터와 중복되도록 요구합니다. 회사 A가 데이터 세트에 있는 모든 개인을 쿼리할 수 있도록 하고 싶지는 않습니다. 또한 공동 작업 계약에서도 이러한 제한에 동의했습니다. `dimensionColumns`— 회사 B는 회사 A에 대한 분석에 도움이 될 수 있는 고유한 속성인 `state`, `popularpurchases`, 및 `customerserviceuser`를 기준으로 필터링 및 그룹화할 수 있도록 합니다. 회사 B는 회사 B를 통해 회사 A가 `returndate`를 사용하여 `purchasedate` 이후에 발생하는 `returndate`의 출력을 필터링할 수 있도록 합니다. 이 필터링을 사용하면 제품 변경의 영향을 평가하는 데 더 정확한 결과를 얻을 수 있습니다. `scalarFunctions`— 회사 B는 다음을 가능하게 합니다. + 날짜용 TRUNC + 데이터에 `producttype`이 다른 형식으로 입력된 경우 LOWER 및 UPPER를 사용합니다. + CAST 회사 A가 매출의 데이터 유형을 수익의 데이터 유형과 동일하게 변환해야 하는 경우 회사 A는 다른 스칼라 함수가 쿼리에 필요하지 않다고 생각하기 때문에 다른 스칼라 함수를 활성화하지 않습니다. `outputConstraints`— 회사 B는 고객을 재식별하는 능력을 줄이기 위해 `hashedemail`에 최소 출력 제약 조건을 설정합니다. 또한 반품된 특정 제품을 재식별하는 능력을 줄이기 위해 `producttype`에 최소 생산량 제한을 추가합니다. 생산량 규모에 따라 특정 제품 유형이 더 우세할 수 있습니다 (예: `state`). 회사 A가 데이터에 추가한 출력 제약 조건과 관계없이 해당 출력 제약은 항상 적용됩니다. 1. 회사 A는 공동 작업과 관련된 판매 테이블을 생성합니다. 1. 회사 B는 공동 작업에 대한 반품 테이블 연결을 생성합니다. 1. 회사 A는 다음 예와 같은 쿼리를 실행하여 2022년 위치별 총 구매액과 비교하여 회사 B의 반품 수량을 더 잘 파악합니다. ``` SELECT companyB.state, SUM(companyB.returns), COUNT(DISTINCT companyA.hashedemail) FROM sales companyA INNER JOIN returns companyB ON companyA.identifier = companyB.identifier WHERE companyA.purchasedate BETWEEN '2022-01-01' AND '2022-12-31' AND TRUNC(companyB.returndate) > companyA.purchasedate GROUP BY companyB.state; ``` 1. 회사 A와 회사 B는 쿼리 로그를 검토합니다. 회사 B는 쿼리가 공동 작업 계약에서 합의한 내용과 일치하는지 확인합니다. ## 집계 분석 규칙 문제 해결 여기에 있는 정보를 사용하여 집계 분석 규칙으로 작업할 때 흔히 발생하는 문제를 진단하고 해결하는 데 도움을 받을 수 있습니다. **Topics** + [쿼리에서 결과가 반환되지 않았습니다.](#query-no-results) ### 쿼리에서 결과가 반환되지 않았습니다. 일치하는 결과가 없거나 일치하는 결과가 하나 이상의 최소 집계 임계값을 충족하지 않을 때 이런 일이 발생할 수 있습니다. 최소 집계 임계값에 대한 자세한 내용은 [집계 분석 규칙 - 예제](#agg-analysis-rule-example) 섹션을 참조하세요. # 목록 분석 규칙 에서 AWS Clean Rooms*목록 분석 규칙*은 추가된 구성된 테이블과 쿼리할 수 있는 구성원의 구성된 테이블 간의 중첩 행 수준 목록을 출력합니다. 쿼리할 수 있는 구성원은 목록 분석 규칙이 포함된 쿼리를 실행합니다. 목록 분석 규칙 유형은 강화 및 대상 구축과 같은 사용 사례를 지원합니다. 이 분석 규칙의 사전 정의된 쿼리 구조 및 구문에 대한 자세한 내용은 [목록 분석 규칙 사전 정의된 구조](#intersection-list-params-template)을 참조하세요. [목록 분석 규칙 - 쿼리 제어](#parameters-list-query-controls)에 정의된 목록 분석 규칙의 매개 변수에는 쿼리 컨트롤이 있습니다. 쿼리 컨트롤에는 출력에 나열할 수 있는 열을 선택하는 기능이 포함됩니다. 쿼리에는 직접 또는 전이적으로 쿼리할 수 있는 구성원의 구성된 테이블을 사용한 조인이 하나 이상 있어야 합니다. [집계 분석](analysis-rules-aggregation.md) 규칙과 같은 쿼리 결과 컨트롤은 없습니다. 목록 쿼리는 수학 연산자만 사용할 수 있습니다. 다른 함수(예: 집계 또는 스칼라)는 사용할 수 없습니다. **Topics** + [쿼리 구조 및 구문 목록](#list-query-controls) + [목록 분석 규칙 - 쿼리 제어](#parameters-list-query-controls) + [목록 분석 규칙 사전 정의된 구조](#intersection-list-params-template) + [목록 분석 규칙 - 예제](#list-example) ## 쿼리 구조 및 구문 목록 목록 분석 규칙이 있는 테이블에 대한 쿼리는 다음 구문을 준수해야 합니다. ``` --select_list_expression SELECT DISTINCT column_name [[AS] column_alias ] [, ...] --table_expression FROM table_name [[AS] table_alias ] [[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...] --where_expression [WHERE where_condition] --limit_expression [LIMIT number] ``` 다음 표에서는 위 구문에 나열된 각 표현식에 대해 설명합니다. | 표현식 | 정의 | 예제 | | --- | --- | --- | | select\$1list\$1expression | 테이블 열 이름을 하나 이상 포함하는 쉼표로 구분된 목록입니다. `DISTINCT` 파라미터가 필요합니다. `select_list_expression`은 `AS` 매개변수를 포함하거나 포함하지 않고 열에 별칭을 지정할 수 있습니다. 자세한 내용은 [AWS Clean Rooms SQL 참조](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) 섹션을 참조하세요. | `SELECT DISTINCT segment` | | table\$1expression | `join_condition`를 `join_condition`에 연결하는 테이블 또는 테이블의 조인. `join_condition`은 BOOLEAN을 반환합니다. `table_expression`은 다음을 지원합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules-list.html) | 
FROM consumer_table 
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
| | where\$1expression | 부울을 반환하는 조건식입니다. 다음과 같이 구성될 수 있습니다:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/analysis-rules-list.html)지원되는 비교 조건은 (`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`)입니다.지원되는 논리 연산자는 (`AND, OR`)입니다.`where_expression`은 선택 사항입니다. | `WHERE state + '_' + city = 'NY_NYC'` `WHERE timestampColumn = timestampColumn2 - 14` | | limit\$1expression | 이 표현식은 양의 정수를 사용해야 합니다. `limit_expression`은 선택 사항입니다. | `LIMIT 100` | 목록 쿼리 구조 및 구문에 대해서는 다음 사항에 유의해야 합니다. + SELECT 이외의 SQL 명령은 지원되지 않습니다. + 하위 쿼리 및 공통 테이블 표현식(예:WITH)은 지원되지 않습니다 + HAVING GROUP BY, 및 BY ORDER 절은 지원되지 않습니다 + OFFSET 파라미터는 지원되지 않습니다 ## 목록 분석 규칙 - 쿼리 제어 목록 쿼리 컨트롤을 사용하면 테이블의 열을 사용하여 테이블을 쿼리하는 방법을 제어할 수 있습니다. 예를 들어, 조인에 사용되는 열 또는 SELECT 명령문 및 WHERE 절에서 사용할 수 있는 열을 제어할 수 있습니다. 다음 단원에서는 각 컨트롤에 대해 설명합니다. **Topics** + [조인 컨트롤](#list-controls-join-controls) + [목록 컨트롤](#list-controls) ### 조인 컨트롤 조인 컨트롤을 사용하면 테이블이 **table\$1expression**의 다른 테이블에 조인되는 방식을 제어할 수 있습니다. AWS Clean Rooms 은 INNER JOIN만 지원합니다.** 목록 분석 규칙에는 최소 하나 이상의 INNER JOIN이 필요하며 쿼리가 가능한 구성원은 자신이 소유한 테이블을 INNER JOIN에 포함해야 합니다. 즉, 직접 또는 전이적으로 테이블을 자신의 테이블과 조인해야 합니다. 다음은 전이성의 예입니다. ``` ON my_table.identifer = third_party_table.identifier .... ON third_party_table.identifier = member_who_can_query_table.id ``` INNER JOIN 문은 분석 규칙에서 명시적으로 `joinColumn`으로 분류된 열만 사용할 수 있습니다. INNER JOIN은 구성된 테이블의 `joinColumn`과 공동 작업의 다른 구성된 테이블의 `joinColumn`에 대해 작동해야 합니다. 테이블에서 `joinColumn`으로 사용할 수 있는 열을 결정합니다. ON 절의 각 일치 조건은 두 열 간의 등식 비교 조건(`=`)을 사용해야 합니다. ON 조항 내의 여러 일치 조건은 다음과 같을 수 있습니다. + `AND` 논리 연산자를 사용하여 조합합니다 + `OR` 논리 연산자를 사용하여 구분합니다 **참고** 모든 JOIN 일치 조건은 JOIN의 각 변의 한 행과 일치해야 합니다. `OR` 또는 `AND` 논리 연산자로 연결된 모든 조건문도 이 요구 사항을 준수해야 합니다. 다음은 `AND` 논리 연산자를 사용한 쿼리의 예입니다. ``` SELECT some_col, other_col FROM table1 JOIN table2 ON table1.id = table2.id AND table1.name = table2.name ``` 다음은 `OR` 논리 연산자를 사용하는 쿼리의 예입니다. ``` SELECT some_col, other_col FROM table1 JOIN table2 ON table1.id = table2.id OR table1.name = table2.name ``` | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | joinColumns | 쿼리를 할 수 있는 구성원이 INNER JOIN 문에서 사용할 수 있도록 허용하려는 열입니다. | 동일한 열을 `joinColumn`과 `listColumn`([목록 컨트롤](#list-controls) 참조) 모두로 분류할 수는 없습니다. `joinColumn`은 INNER JOIN 이외의 쿼리 다른 부분에서는 사용할 수 없습니다. | ### 목록 컨트롤 *목록 컨트롤*은 쿼리 출력에 나열될 수 있는 열(즉, SELECT 문에 사용) 또는 결과를 필터링하는 데 사용할 수 있는 열(즉, WHERE 문에서 사용)을 제어합니다. | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | listColumns | 쿼리할 수 있는 구성원이 SELECT와 WHERE에서 사용하도록 허용한 열 | listColumn은 SELECT 및 WHERE에서 사용할 수 있습니다.동일한 열을 `listColumn`과 `joinColumn` 둘 다로 사용할 수는 없습니다. | ## 목록 분석 규칙 사전 정의된 구조 다음 예제에는 목록 분석 규칙을 완성하는 방법을 보여주는 사전 정의된 구조가 포함되어 있습니다. 다음 예제에서는 *`MyTable`*은 데이터 테이블을 의미합니다. 각 *user input placeholder*를 사용자의 정보로 바꿀 수 있습니다. ``` { "joinColumns": [MyTable column name(s)], "listColumns": [MyTable column name(s)], } ``` ## 목록 분석 규칙 - 예제 다음 예제에서는 두 회사가 목록 분석을 AWS Clean Rooms 사용하여에서 협업하는 방법을 보여줍니다. 회사 A에는 고객 관계 관리(CRM) 데이터가 있습니다. 회사 A는 고객에 대해 더 자세히 알아보고 잠재적으로 속성을 다른 분석에 입력 자료로 사용할 수 있도록 고객에 대한 추가 세그먼트 데이터를 확보하고자 합니다. 회사 B는 자사 데이터를 기반으로 생성한 고유한 세그먼트 속성으로 구성된 세그먼트 데이터를 보유하고 있습니다. 회사 B는 고객 데이터와 회사 A 데이터 간에 중복되는 고객에 대해서만 회사 A에 고유한 세그먼트 속성을 제공하려고 합니다. 두 회사는 A사가 중복되는 데이터를 보강할 수 있도록 협력하기로 결정합니다. 회사 A는 쿼리를 할 수 있는 구성원이고 회사 B는 기여자입니다. 공동 작업을 생성하고 공동 작업으로 목록 분석을 실행하기 위해 회사는 다음과 같은 작업을 수행합니다. 1. 회사 A는 공동 작업을 만들고 멤버십을 생성합니다. 공동 작업에는 회사 B가 공동 작업의 또 다른 구성원으로 참여합니다. 회사 A는 공동 작업에서 쿼리 로깅을 활성화하고 해당 계정에서 쿼리 로깅을 활성화합니다. 1. 회사 B는 공동 작업 멤버십을 생성합니다. 이를 통해 해당 계정에서 쿼리 로깅이 가능합니다. 1. 회사 A는 CRM으로 구성된 테이블을 생성합니다 1. 회사 A는 다음 예에 나와 있는 대로 고객 구성 테이블에 분석 규칙을 추가합니다. ``` { "joinColumns": [ "identifier1", "identifier2" ], "listColumns": [ "internalid", "segment1", "segment2", "customercategory" ] } ``` `joinColumns`— 회사 A는 `hashedemail` 및/또는 `thirdpartyid`(ID 공급업체로부터 획득)를 사용하여 CRM 데이터의 고객과 세그먼트 데이터의 고객을 매칭하려고 합니다. 이를 통해 A사는 풍부한 데이터를 적합한 고객에게 매칭할 수 있습니다. 두 개의 JoinColumn이 있어 분석의 일치율을 잠재적으로 개선할 수 있습니다. `listColumns`— 회사 A는 자체 시스템에서 사용하는 `internalid` 외에도 풍부한 열을 얻기 위해 `listColumns`을 사용합니다. `segment1`, `segment2`, 및 `customercategory`를을 추가하여 필터에 사용함으로써 잠재적으로 특정 세그먼트로 보강을 제한할 수 있습니다. 1. 회사 B는 세그먼트 구성 테이블을 만듭니다. 1. 회사 B는 세그먼트 구성 테이블에 분석 규칙을 추가합니다. ``` { "joinColumns": [ "identifier2" ], "listColumns": [ "segment3", "segment4" ] } ``` `joinColumns`— 회사 B는 회사 A가 `identifier2`에서 조인하여 세그먼트 데이터에서 CRM 데이터로 고객을 일치시킬 수 있도록 지원합니다. 회사 A와 회사 B는 ID 공급업체와 협력하여 이번 공동 작업에 적합한 `identifier2`를 확보했습니다. `identifier2`가 가장 높고 정확한 일치율을 제공하며 다른 식별자는 쿼리에 필요하지 않다고 판단했기 때문에 다른 `joinColumns`을 추가하지 않았습니다. `listColumns`— 회사 B는 회사 A가 데이터 보강의 일부로(고객 A와 함께) 생성, 수집, 정렬한 고유 속성인 `segment3` 및 `segment4` 속성을 사용하여 데이터를 보강할 수 있도록 지원합니다. 그들은 A 회사가 행 수준에서 중복되는 부분에 대해 이러한 세그먼트를 확보하기를 원합니다. 이는 데이터 강화 공동 작업이기 때문입니다. 1. 회사 A는 공동 작업에 CRM 테이블 연결을 생성합니다. 1. 회사 B는 공동 작업에 대한 세그먼트 테이블 연결을 생성합니다. 1. 회사 A는 다음과 같은 쿼리를 실행하여 중복되는 고객 데이터를 보강합니다. ``` SELECT companyA.internalid, companyB.segment3, companyB.segment4 INNER JOIN returns companyB ON companyA.identifier2 = companyB.identifier2 WHERE companyA.customercategory > 'xxx' ``` 1. 회사 A와 회사 B는 쿼리 로그를 검토합니다. 회사 B는 쿼리가 공동 작업 계약에서 합의한 내용과 일치하는지 확인합니다. # 의 사용자 지정 분석 규칙 AWS Clean Rooms 에서 AWS Clean Rooms*사용자 지정 분석 규칙*은 구성된 테이블에서 사용자 지정 쿼리를 실행할 수 있는 새로운 유형의 분석 규칙입니다. 사용자 지정 SQL 쿼리는 여전히 SELECT 명령만 사용하는 것으로 제한되지만 [집계](analysis-rules-aggregation.md#agg-query-controls) 및 [목록](analysis-rules-list.md#list-query-controls) 쿼리보다 더 많은 SQL 구성을 사용할 수 있습니다(예: 창 함수, OUTER JOIN, CTE 또는 하위 쿼리가 있고, 전체 목록은 [AWS Clean Rooms SQL 참조](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html)를 참조하세요). 사용자 지정 SQL 쿼리는 [집계](analysis-rules-aggregation.md#agg-query-structure-syntax) 및 [목록](analysis-rules-list.md#list-query-controls) 쿼리와 같은 쿼리 구조를 따를 필요가 없습니다. 사용자 지정 분석 규칙은 사용자 지정 속성 분석, 벤치마킹, 증분 분석, 대상 발견과 같은 집계 및 목록 분석 규칙이 지원하는 것보다 더 고급 사용 사례를 지원합니다. 이는 집계 및 목록 분석 규칙이 지원하는 사용 사례의 일부에 추가됩니다. 사용자 지정 분석 규칙은 차등 프라이버시 기능도 지원합니다. 차등 프라이버시는 데이터 프라이버시를 보호하기 위해 수학적으로 엄격한 프레임워크입니다. 자세한 내용은 [AWS Clean Rooms 차등 프라이버시](differential-privacy.md) 단원을 참조하십시오. 분석 템플릿을 생성할 때 AWS Clean Rooms 차등 프라이버시는 템플릿을 확인하여 AWS Clean Rooms 차등 프라이버시에 대한 범용 쿼리 구조와 호환되는지 확인합니다. 이 검증을 통해 차등 프라이버시 보호 테이블에서 허용되지 않는 분석 템플릿을 생성하지 않을 수 있습니다. 사용자 지정 분석 규칙을 구성하기 위해 데이터 소유자는 [분석 템플릿](create-analysis-template.md)에 저장된 특정 사용자 지정 쿼리가 구성된 테이블에서 실행되도록 허용하도록 선택할 수 있습니다. 데이터 소유자는 사용자 지정 분석 규칙에서 허용된 분석 컨트롤에 추가하기 전에 분석 템플릿을 검토합니다. 분석 템플릿은 테이블이 다른 공동 작업과 연결되어 있더라도 해당 템플릿을 만든 공동 작업에서만 사용할 수 있고 볼 수 있으며 해당 공동 작업에서 쿼리할 수 있는 구성원만 실행할 수 있습니다. 또는 구성원이 다른 구성원(쿼리 제공자)이 검토 없이 쿼리를 생성하도록 허용할 수도 있습니다. 구성원은 사용자 지정 분석 규칙에서 허용된 쿼리 제공자가 제어하는 쿼리 제공자의 계정을 추가합니다. 쿼리 제공자가 쿼리를 수행할 수 있는 구성원인 경우 구성원은 구성된 테이블에서 직접 모든 쿼리를 실행할 수 있습니다. 쿼리 제공자는 [분석 템플릿을 생성하여 쿼리를 생성](create-analysis-template.md)할 수도 있습니다. 쿼리 공급자가 생성한 모든 쿼리는 AWS 계정 가 존재하고 테이블이 연결된 모든 공동 작업의 테이블에서 자동으로 실행될 수 있습니다. 데이터 소유자는 분석 템플릿 또는 계정만 쿼리를 생성하도록 허용할 수 있으며 둘 다 생성할 수는 없습니다. 데이터 소유자가 테이블을 비워 두면 쿼리를 할 수 있는 구성원은 구성된 테이블에서 쿼리를 실행할 수 없습니다. **Topics** + [사용자 지정 분석 규칙, 사전 정의된 구조](#custom-predefined-structure) + [사용자 지정 분석 규칙 예제](#custom-example) + [차등 프라이버시가 사용되는 사용자 지정 분석 규칙](#custom-diff-privacy) ## 사용자 지정 분석 규칙, 사전 정의된 구조 다음 예제에는 차등 프라이버시 기능을 켜고 사용자 지정 분석 규칙을 완성하는 방법을 보여 주는 사전 정의된 구조가 포함되어 있습니다. `userIdentifier` 값은 사용자를 고유하게 식별하는 열(예: *user\$1id*)입니다. 공동 작업에서 차등 프라이버시를 사용하는 테이블이 2개 이상 있는 경우 AWS Clean Rooms 은 2개 이상의 분석 규칙의 사용자 식별자 열과 동일한 열을 구성하여 테이블 간에 사용자에 대한 정의를 일관되게 유지해야 합니다. ``` { "allowedAnalyses": ["ANY_QUERY"] | string[], "allowedAnalysisProviders": [], "differentialPrivacy": { "columns": [ { "name": "userIdentifier" } ] } } ``` 다음 작업 중 하나를 수행할 수 있습니다. + 허용된 분석 제어에 분석 템플릿 ARN을 추가합니다. 이 경우 `allowedAnalysisProviders` 컨트롤은 포함되지 않습니다. ``` { allowedAnalyses: string[] } ``` + `allowedAnalysisProviders` 제어에 AWS 계정 IDs 추가합니다. 이 경우에는 `ANY_QUERY`를 `allowedAnalyses` 컨트롤에 추가합니다. ``` { allowedAnalyses: ["ANY_QUERY"], allowedAnalysisProviders: string[] } ``` ## 사용자 지정 분석 규칙 예제 다음 예제에서는 두 회사가 사용자 지정 분석 규칙을 AWS Clean Rooms 사용하여에서 협업하는 방법을 보여줍니다. 회사 A에는 고객 및 판매 데이터가 있습니다. 회사 A는 회사 B 사이트에서 광고 캠페인의 매출 증대를 파악하는 데 관심이 있습니다. 회사 B에는 회사에 유용한 시청률 데이터 및 세그먼트 속성(예: 광고를 볼 때 사용한 장치)이 있습니다. 회사 A에는 공동 작업에서 실행하려는 특정 증분 쿼리가 있습니다. 공동 작업을 생성하고 공동 작업을 통해 사용자 지정 분석을 실행하기 위해 회사는 다음을 수행합니다. 1. 회사 A는 공동 작업을 만들고 멤버십을 생성합니다. 공동 작업에는 회사 B가 공동 작업의 또 다른 구성원으로 참여합니다. 회사 A는 공동 작업에서 쿼리 로깅을 활성화하고 해당 계정에서 쿼리 로깅을 활성화합니다. 1. 회사 B는 공동 작업 멤버십을 생성합니다. 이를 통해 해당 계정에서 쿼리 로깅이 가능합니다. 1. 회사 A는 CRM으로 구성된 테이블을 생성합니다. 1. 회사 A는 판매 구성 테이블에 빈 사용자 지정 분석 규칙을 추가합니다. 1. 회사 A는 판매 구성 테이블을 공동 작업에 연결합니다. 1. 회사 B는 시청률 구성 테이블을 만듭니다. 1. 회사 B는 시청률 구성 테이블에 빈 사용자 지정 분석 규칙을 추가합니다. 1. 회사 B는 시청률 구성 테이블을 공동 작업과 연결합니다. 1. 회사 A는 공동 작업과 관련된 판매 테이블 및 시청률 테이블을 보고 캠페인 월의 증분 쿼리 및 매개 변수를 추가하여 분석 템플릿을 만듭니다. ``` { "analysisParameters": [ { "defaultValue": "" "type": "DATE" "name": "campaign_month" } ], "description": "Monthly incrementality query using sales and viewership data" "format": "SQL" "name": "Incrementality analysis" "source": "WITH labeleddata AS ( SELECT hashedemail, deviceid, purchases, unitprice, purchasedate, CASE WHEN testvalue IN ('value1', 'value2', 'value3') THEN 0 ELSE 1 END AS testgroup FROM viewershipdata ) SELECT labeleddata.purchases, provider.impressions FROM labeleddata INNER JOIN salesdata ON labeleddata.hashedemail = provider.hashedemail WHERE MONTH(labeleddata.purchasedate) > :campaignmonth AND testgroup = :group " } ``` 1. 회사 A는 사용자 지정 분석 규칙에서 허용된 분석 제공자 컨트롤에 해당 계정(예: 444455556666)을 추가합니다. 이들은 자신이 만든 모든 쿼리가 판매 구성 테이블에서 실행되도록 허용하기를 원하기 때문에 허용된 분석 공급자 컨트롤을 사용합니다. ``` { "allowedAnalyses": [ "ANY_QUERY" ], "allowedAnalysisProviders": [ "444455556666" ] } ``` 1. 회사 B는 공동 작업에서 생성된 분석 템플릿을 보고 쿼리 문자열 및 파라미터를 포함한 내용을 검토합니다. 1. 회사 B는 분석 템플릿이 증분 사용 사례를 충족하고 시청률 구성 테이블을 쿼리할 수 있는 방법에 대한 프라이버시 요구 사항을 충족한다고 판단합니다. 1. 회사 B는 시청률 테이블의 사용자 지정 분석 규칙에서 허용된 분석 컨트롤에 분석 템플릿 ARN을 추가합니다. 시청률이 구성된 테이블에서 증분 쿼리만 실행되도록 허용하려고 하기 때문에 허용된 분석 제어를 사용합니다. ``` { "allowedAnalyses": [ "arn:aws:cleanrooms:us-east-1:111122223333:membership/41327cc4-bbf0-43f1-b70c-a160dddceb08/analysistemplate/1ff1bf9d-781c-418d-a6ac-2b80c09d6292" ] } ``` 1. 회사 A는 분석 템플릿을 실행하고 매개변수 값 `05-01-2023`을 사용합니다. ## 차등 프라이버시가 사용되는 사용자 지정 분석 규칙 에서 사용자 지정 분석 규칙은 차등 프라이버시 AWS Clean Rooms를 지원합니다. 차등 프라이버시는 재식별 시도로부터 데이터를 보호하는 데 도움이 되는 수학적으로 엄격한 데이터 프라이버시 보호 프레임워크입니다. 차등 프라이버시는 광고 캠페인 계획, 광고 캠페인 후 측정, 금융 기관 컨소시엄의 벤치마킹, 의료 연구를 위한 A/B 테스트와 같은 집계 분석을 지원합니다. 지원되는 쿼리 구조 및 구문은 [쿼리 구조 및 구문](#dp-query-structure-syntax)에 정의되어 있습니다. ### 차등 프라이버시가 사용되는 사용자 지정 분석 규칙 예제 **참고** AWS Clean Rooms 차등 프라이버시는 데이터가 Amazon S3에 저장되는 공동 작업에만 사용할 수 있습니다. 이전 섹션에 제시된 [사용자 지정 분석 규칙 예제](#custom-example)를 생각해 봅니다. 이 예제는 차등 프라이버시를 사용하여 재식별 시도로부터 데이터를 보호하는 동시에 파트너가 데이터에서 비즈니스에 중요한 인사이트를 얻을 수 있도록 하는 방법을 보여 줍니다. 시청률 데이터를 보유한 회사 B가 차등 프라이버시를 통해 데이터를 보호하고자 한다고 가정해 보겠습니다. 차등 프라이버시 설정을 완료하기 위해 회사 B는 다음 단계를 완료합니다. 1. 회사 B는 시청률 구성 테이블에 사용자 지정 분석 규칙을 추가하면서 차등 프라이버시를 사용 설정합니다. 회사 B는 사용자 식별자 열로 `viewershipdata.hashedemail`을 선택합니다. 1. 회사 B는 시청률 데이터 테이블을 쿼리에 사용할 수 있도록 공동 작업에 [차등 프라이버시 정책을 추가](configure-differential-privacy.md)합니다. 회사 B는 설정을 빠르게 완료하기 위해 기본 정책을 선택합니다. 회사 B의 사이트에서 광고 캠페인의 매출 증대를 파악하려는 회사 A가 분석 템플릿을 실행합니다. 쿼리는 AWS Clean Rooms 차등 프라이버시의 범용 [쿼리 구조](#dp-query-structure-syntax)와 호환되므로 쿼리가 성공적으로 실행됩니다. ### 쿼리 구조 및 구문 차등 프라이버시 기능이 켜진 테이블이 적어도 하나 이상 포함된 쿼리는 다음 구문을 따라야 합니다. ``` query_statement: [cte, ...] final_select cte: WITH sub_query AS ( inner_select [ UNION | INTERSECT | UNION_ALL | EXCEPT/MINUS ] [ inner_select ] ) inner_select: SELECT [user_id_column, ] expression [, ...] FROM table_reference [, ...] [ WHERE condition ] [ GROUP BY user_id_column[, expression] [, ...] ] [ HAVING condition ] final_select: SELECT [expression, ...] | COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV FROM table_reference [, ...] [ WHERE condition ] [ GROUP BY expression [, ...] ] [ HAVING COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV | condition ] [ ORDER BY column_list ASC | DESC ] [ OFFSET literal ] [ LIMIT literal ] expression: column_name [, ...] | expression AS alias | aggregation_functions | window_functions_on_user_id | scalar_function | CASE | column_name math_expression [, expression] window_functions_on_user_id: function () OVER (PARTITION BY user_id_column, [column_name] [ORDER BY column_list ASC|DESC]) ``` **참고** 차등 프라이버시 쿼리 구조 및 구문에 대해서는 다음 사항에 유의해야 합니다. 하위 쿼리는 지원되지 않습니다. 테이블 또는 CTE에 차등 프라이버시로 보호되는 데이터가 포함된 경우 일반 테이블 표현식(CTE)에서 사용자 식별자 열을 내보내야 합니다. 필터, 그룹화 및 집계는 사용자 수준에서 수행해야 합니다. Final\$1select는 COUNT DISTINCT, COUNT, SUM, AVG, STDDEV 집계 함수를 허용합니다. 차등 프라이버시에서 지원되는 SQL 키워드에 대한 자세한 내용은 [AWS Clean Rooms 차등 프라이버시의 SQL 기능](dp-sql-capabilities.md) 섹션을 참조하세요. # ID 매핑 테이블 분석 규칙 에서 AWS Clean Rooms*ID 매핑 테이블 분석 규칙*은 독립 실행형 분석 규칙이 아닙니다. 이러한 유형의 분석 규칙은에서 관리 AWS Clean Rooms 하며 쿼리를 용이하게 하기 위해 서로 다른 자격 증명 데이터를 조인하는 데 사용됩니다. ID 매핑 테이블에 자동으로 추가되며 편집할 수 없습니다. 또한 공동 작업 내 다른 분석 규칙의 동작을 상속합니다. 단, 해당 분석 규칙들이 동질적이어야 합니다. ID 매핑 테이블 분석 규칙은 ID 매핑 테이블에 보안을 적용합니다. 이 규칙은 공동 작업 구성원이 ID 매핑 테이블을 사용하여 두 구성원의 데이터 세트 간에 중첩되지 않는 모집단을 직접 선택하거나 검사하는 것을 제한합니다. ID 매핑 테이블 분석 규칙은 다른 분석 규칙과 함께 쿼리에 암시적으로 사용될 때 ID 매핑 테이블의 민감한 데이터를 보호하는 데 사용됩니다. ID 매핑 테이블 분석 규칙을 사용하여는 확장된 SQL에서 ID 매핑 테이블의 양쪽에 중첩을 AWS Clean Rooms 적용합니다. 이를 통해 다음 작업을 수행할 수 있습니다: + JOIN 문에서 ID 매핑 테이블의 중첩을 사용할 수 있습니다. AWS Clean Rooms 는 중첩을 준수하는 경우 ID 매핑 테이블에서 INNERLEFT, 또는 RIGHT 조인을 허용합니다. 민감한 매핑 정보를 보호하려면 ID 매핑 테이블이 항상 JOIN 작업의 "inner" 측에 있어야 합니다. 예를 들어 다음 JOIN 작업이 유효합니다. + table LEFT JOIN id\$1mapping\$1table + id\$1mapping\$1table RIGHT JOIN table + table INNER JOIN id\$1mapping\$1table 다음 JOIN 작업은 유효하지 않습니다. + id\$1mapping\$1table LEFT JOIN table + table RIGHT JOIN id\$1mapping\$1table 이렇게 하면 데이터 세트에 일치하는 항목이 없는 매핑 레코드가 노출되는 것을 방지할 수 있습니다. 이러한 작업을 허용하면 다른 공동 작업 구성원의 데이터 매핑에 대한 민감한 정보가 잠재적으로 공개될 수 있습니다. + JOIN 문에서 매핑 테이블 열을 사용할 수 있습니다. 그러나 SELECT, WHERE, HAVING, GROUP BY 또는 ORDER BY 문에서는 매핑 테이블 열을 사용할 수 없습니다. 단, 소스 ID 네임스페이스 연결 또는 대상 ID 네임스페이스 연결에서 보호가 수정된 경우는 예외입니다. + 확장된 SQL에서는 OUTER , JOIN암시적 및 JOINCROSS AWS Clean Rooms 도 지원합니다JOIN. 이러한 조인은 중첩 요구 사항을 충족할 수 없습니다. 대신 `requireOverlap`를 AWS Clean Rooms 사용하여 조인해야 하는 열을 지정합니다. 지원되는 쿼리 구조 및 구문은 [ID 매핑 테이블 쿼리 구조 및 구문](#id-mapping-table-query-controls)에 정의되어 있습니다. [ID 매핑 테이블 분석 규칙 쿼리 컨트롤](#parameters-id-mapping-query-controls)에 정의된 분석 규칙의 파라미터에는 쿼리 컨트롤 및 쿼리 결과 컨트롤이 포함됩니다. 쿼리 컨트롤에는 JOIN 문에서 ID 매핑 테이블의 중첩을 요구하는 기능(즉, `requireOverlap`)이 포함됩니다. **Topics** + [ID 매핑 테이블 쿼리 구조 및 구문](#id-mapping-table-query-controls) + [ID 매핑 테이블 분석 규칙 쿼리 컨트롤](#parameters-id-mapping-query-controls) + [ID 매핑 테이블 분석 규칙의 사전 정의된 구조](#id-mapping-table-predefined-structure) + [ID 매핑 테이블 분석 규칙 - 예](#id-mapping-table-example) ## ID 매핑 테이블 쿼리 구조 및 구문 ID 매핑 테이블 분석 규칙이 있는 테이블에 대한 쿼리는 다음 구문을 준수해야 합니다. ``` --select_list_expression SELECT provider.data_col, consumer.data_col --table_expression FROM provider JOIN idMappingTable idmt ON provider.id = idmt.sourceId JOIN consumer ON consumer.id = idmt.targetId ``` ### 공동 작업 테이블 다음 표는 AWS Clean Rooms 공동 작업에 있는 구성된 테이블을 나타냅니다. **cr\$1drivers\$1license** 및 **cr\$1insurance** 테이블의 **id** 열은 ID 매핑 테이블과 일치하는 열을 나타냅니다. **cr\$1drivers\$1license** | | | | | --- |--- |--- | | id | driver\$1name | state\$1of\$1registration | | 1 | Eduard | TX | | 2 | Dana | MA | | 3 | Gweneth | IL | **cr\$1insurance** | | | | | --- |--- |--- | | id | policyholder\$1email | policy\$1number | | a | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 | | b | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 | | c | rosa@internal.company.com | d7692e84-3d3c-47b8-b46d-a0d5345f0601 | ### ID 매핑 테이블 다음 표는 **cr\$1drivers\$1license** 및 **cr\$1insurance** 테이블과 일치하는 기존 ID 매핑 테이블을 나타냅니다. 두 공동 작업 테이블에 대한 ID가 없는 항목도 있습니다. | | | | --- |--- | | cr\$1drivers\$1license\$1id | cr\$1insurance\$1id | | 1 | a | | 2 | null | | 3 | b | | null | c | ID 매핑 테이블 분석 규칙은 다음과 같이 중첩 데이터 세트에 대해서만 쿼리를 실행할 수 있도록 허용합니다. | | | | | | | | --- |--- |--- |--- |--- |--- | | cr\$1drivers\$1license\$1id | cr\$1insurance\$1id | driver\$1name | state\$1of\$1registration | policyholder\$1email | policy\$1number | | 1 | a | Eduard | TX | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 | | 3 | b | Gweneth | IL | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 | ### 예제 쿼리 다음 예제에서는 ID 매핑 테이블 조인의 유효한 위치를 보여줍니다. ``` -- Single ID mapping table SELECT [ select_items ]FROM cr_drivers_license cr_dl [ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id [ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id ; -- Single ID mapping table (Subquery) SELECT [ select_items ]FROM ( SELECT [ select_items ] FROM cr_drivers_license cr_dl [ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id [ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id ) ; -- Single ID mapping table (CTE) WITH matched_ids AS ( SELECT [ select_items ] FROM cr_drivers_license cr_dl [ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id [ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id )SELECT [ select_items ]FROM matched_ids ; ``` ### 고려 사항 ID 매핑 테이블 쿼리 구조 및 구문에 대해서는 다음 사항에 유의해야 합니다. + 편집할 수 없습니다. + 기본적으로 ID 매핑 테이블에 적용됩니다. + 공동 작업 내에서 소스 및 대상 ID 네임스페이스 연결을 사용합니다. + ID 매핑 테이블은 ID 네임스페이스에서 가져온 열에 대한 기본 보호를 제공하도록 기본적으로 구성됩니다. ID 네임스페이스(`sourceID` 또는 `targetID`)에서 가져온 열이 쿼리의 어느 곳에서든 허용될 수 있도록 이 구성을 수정할 수 있습니다. 자세한 내용은 [의 ID 네임스페이스 AWS Clean Rooms](working-with-id-namespaces.md) 단원을 참조하십시오. + ID 매핑 테이블 분석 규칙은 공동 작업 내 다른 분석 규칙의 SQL 제한을 상속합니다. ## ID 매핑 테이블 분석 규칙 쿼리 컨트롤 ID 매핑 테이블 쿼리 제어를 사용하여는 테이블의 열을 사용하여 테이블을 쿼리하는 방법을 AWS Clean Rooms 제어합니다. 예를 들어 조인에 사용되는 열과 중첩이 필요한 열을 제어합니다. ID 매핑 테이블 분석 규칙에는 JOIN 없이도 `sourceID`, `targetID` 또는 둘 다를 표시할 수 있는 기능도 포함되어 있습니다. 다음 표에서는 각 컨트롤에 대해 설명합니다. | 컨트롤 | 정의 | 사용법 | | --- | --- | --- | | joinColumns | 쿼리를 할 수 있는 구성원이 INNER JOIN 문에서 사용할 수 있는 열입니다. | INNER JOIN 이외의 다른 쿼리 부분에서는 joinColumns를 사용할 수 없습니다.자세한 내용은 [조인 컨트롤](analysis-rules-aggregation.md#join-controls) 단원을 참조하십시오. | | dimensionColumns | 쿼리할 수 있는 구성원이 SELECT 및 GROUP BY 문에서 사용할 수 있는 열입니다(있는 경우). | `dimensionColumn`은 SELECT 및 GROUP BY에서 사용할 수 있습니다. `dimensionColumn`은 `joinKeys`로 표시될 수 있습니다. 괄호 안에 지정한 경우에만 JOIN 절에서 `dimensionColumns`를 사용할 수 있습니다. | | queryContraints:RequireOverlap | 쿼리를 실행할 수 있도록 조인해야 하는 ID 매핑 테이블의 열입니다. | 이러한 열은 ID 매핑 테이블과 공동 작업 테이블을 조인하는 데 사용해야 합니다. | ## ID 매핑 테이블 분석 규칙의 사전 정의된 구조 ID 매핑 테이블 분석 규칙의 사전 정의된 구조에는 `sourceID` 및 `targetID`에 적용되는 기본 보호 기능이 포함되어 있습니다. 즉, 보호 기능이 적용된 열을 쿼리에 사용해야 합니다. ID 매핑 테이블 분석 규칙은 다음과 같은 방법으로 구성할 수 있습니다. + `sourceID` 및 모두 `targetID` 보호됨 이 구성에서는 `sourceID` 및 `targetID`를 모두 표시할 수 없습니다. ID 매핑 테이블을 참조할 경우에는 `sourceID` 및 `targetID`를 JOIN에 사용해야 합니다. + `targetID`만 보호됨 이 구성에서는 `targetID`를 표시할 수 없습니다. ID 매핑 테이블을 참조할 경우에는 `targetID`를 JOIN에 사용해야 합니다. `sourceID`는 쿼리에 사용할 수 있습니다. + `sourceID`만 보호됨 이 구성에서는 `sourceID`를 표시할 수 없습니다. ID 매핑 테이블을 참조할 경우에는 `sourceID`를 JOIN에 사용해야 합니다. `targetID`는 쿼리에 사용할 수 있습니다. + `sourceID` 또는 `targetID` 모두 보호되지 않음 이 구성에서는 ID 매핑 테이블에 대해 쿼리에 사용할 수 있는 특정 제한이 적용되지 않습니다. 다음 예시는 `sourceID`와 `targetID`에 기본 보호가 적용된 ID 매핑 테이블 분석 규칙의 사전 정의된 구조를 보여줍니다. 이 예시에서 ID 매핑 테이블 분석 규칙은 `sourceID` 열과 `targetID` 열 모두에 대한 INNER JOIN만 허용합니다. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [ "source_id", "target_id" ] } } ], "dimensionColumns": [] // columns that can be used in SELECT and JOIN } ``` 다음 예시는 `targetID`에 보호 기능이 적용된 ID 매핑 테이블 분석 규칙의 미리 정의된 구조를 보여줍니다. 이 예시에서 ID 매핑 테이블 분석 규칙은 `sourceID` 열에 대한 INNER JOIN만 허용합니다. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [ "target_id" ] } } ], "dimensionColumns": [ "source_id" ] } ``` 다음 예시는 `sourceID`에 보호 기능이 적용된 ID 매핑 테이블 분석 규칙의 미리 정의된 구조를 보여줍니다. 이 예시에서 ID 매핑 테이블 분석 규칙은 `targetID` 열에 대한 INNER JOIN만 허용합니다. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [ "source_id" ] } } ], "dimensionColumns": [ "target_id" ] } ``` 다음 예시는 `sourceID` 또는 `targetID`에 보호 기능이 적용되지 않은 ID 매핑 테이블 분석 규칙의 미리 정의된 구조를 보여줍니다. 이 예시에서 ID 매핑 테이블 분석 규칙은 `sourceID` 열과 `targetID` 열 모두에 대한 INNER JOIN을 허용합니다. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [] } } ], "dimensionColumns": [ "source_id", "target_id" ] } ``` ## ID 매핑 테이블 분석 규칙 - 예 예를 들어 개인 식별 정보(PII)를 참조하는 긴 워터폴 문을 작성하는 대신, 기업은 ID 매핑 테이블 분석 규칙을 통해 다자간 LiveRamp 트랜스코딩을 활용할 수 있습니다. 다음 예제에서는 ID 매핑 테이블 분석 규칙을 AWS Clean Rooms 사용하여에서 협업하는 방법을 보여줍니다. A사는 소스로 사용될 고객 및 판매 데이터를 보유한 광고주입니다. 또한 A사는 공동 작업의 당사자들을 대신하여 트랜스코딩을 수행하고 LiveRamp 자격 증명을 제공합니다. B사는 대상으로 사용될 이벤트 데이터를 보유한 게시자입니다. **참고** A사 또는 B사는 LiveRamp 트랜스코딩 자격 증명을 제공하고 트랜스코딩을 수행할 수 있습니다. 공동 작업을 생성하고 공동 작업을 통해 ID 매핑 테이블 분석을 수행하기 위해 두 회사는 다음과 같은 작업을 수행합니다. 1. A사는 공동 작업을 만들고 멤버십을 생성합니다. B사를 추가하고 이 회사의 공동 작업 멤버십도 생성합니다. 1. 회사 A는 기존 ID 네임스페이스 소스를 연결하거나 AWS Clean Rooms 콘솔을 AWS Entity Resolution 사용하여에서 새 ID 네임스페이스 소스를 생성합니다. A사는 판매 데이터로 구성된 테이블을 생성하고, 이 테이블에 ID 매핑 테이블의 `sourceId`에 연결된 열을 추가합니다. ID 네임스페이스 소스는 트랜스코딩할 데이터를 제공합니다. 1. 회사 B는 AWS Clean Rooms 콘솔을 AWS Entity Resolution 사용하여 기존 ID 네임스페이스 대상을 연결하거나에서 새 대상을 생성합니다. B사는 이벤트 데이터로 구성된 테이블을 생성하고, 이 테이블에 ID 매핑 테이블의 `targetId`에 연결된 열을 추가합니다. ID 네임스페이스 대상은 트랜스코딩할 데이터를 제공하지 않고 LiveRamp 구성과 관련된 메타데이터만 제공합니다. 1. A사는 공동 작업에 연결된 두 개의 ID 네임스페이스를 검색하고 ID 매핑 테이블을 생성하여 채웁니다. 1. A사는 ID 매핑 테이블을 기준으로 두 데이터세트를 조인하여 쿼리를 실행합니다. ``` --- this would be valid for Custom or List SELECT provider.data_col, consumer.data_col FROM provider JOIN idMappingTable-123123123123-myMappingWFName idmt ON provider.id = idmt.sourceId JOIN consumer ON consumer.id = idmt.targetId ``` # AWS Clean Rooms 차등 프라이버시 AWS Clean Rooms 차등 프라이버시를 사용하면 몇 번의 클릭만으로 직관적인 제어로 구현되는 수학 기반 기술을 통해 사용자의 개인 정보를 보호할 수 있습니다. 완전 관리형 기능으로 사용자의 재식별을 방지하는 데 도움이 되는 사전 차등 프라이버시 환경은 필요하지 않습니다.는 개별 수준 데이터를 보호하기 위해 런타임 시 쿼리 결과에 신중하게 보정된 양의 노이즈를 AWS Clean Rooms 자동으로 추가합니다. AWS Clean Rooms 차등 프라이버시는 광범위한 분석 쿼리를 지원하며 쿼리 결과의 소량의 오류로 인해 분석의 유용성이 손상되지 않는 다양한 사용 사례에 적합합니다. 이를 통해 파트너는 파트너 측면에서 추가 설정을 하지 않아도 광고 캠페인, 투자 결정, 임상 연구 등에 관한 비즈니스에 중요한 인사이트를 얻을 수 있습니다. AWS Clean Rooms 차등 프라이버시는 스칼라 함수 또는 수학 연산자 기호를 악의적으로 사용하는 오버플로 또는 잘못된 캐스트 오류로부터 보호합니다. AWS Clean Rooms 차등 프라이버시에 대한 자세한 내용은 다음 주제를 참조하세요. **Topics** + [차등 프라이버시](#dp-overview) + [의 차등 프라이버시 AWS Clean Rooms 작동 방식](#dp-how-it-works) + [차등 프라이버시 정책](dp-settings.md) + [AWS Clean Rooms 차등 프라이버시의 SQL 기능](dp-sql-capabilities.md) + [차등 프라이버시 쿼리 팁 및 예제](dp-query-tips-examples.md) + [AWS Clean Rooms 차등 프라이버시의 제한 사항](dp-limitations.md) ## 차등 프라이버시 차등 프라이버시를 사용하면 집계된 인사이트만 사용할 수 있고 해당 인사이트에 있는 개인 데이터의 기여도는 난독화됩니다. 차등 프라이버시는 특정 개인에 대해 학습한 결과를 수신할 수 있는 구성원에서 얻은 공동 작업 데이터를 보호합니다. 차등 프라이버시를 사용하지 않고 결과를 수신할 수 있는 구성원은 개인에 대한 기록을 추가하거나 제거하고 쿼리 결과의 차이점을 관찰하여 개별 사용자 데이터를 추론할 수 있습니다. 차등 프라이버시 기능이 켜져 있으면 쿼리 결과에 특정 양의 노이즈가 추가되어 개별 사용자의 기여도가 난독화됩니다. 결과를 받을 수 있는 구성원이 데이터 세트에서 개별에 대한 레코드를 제거한 후 쿼리 결과의 차이를 관찰하려고 하면 쿼리 결과의 변동성이 개별 데이터의 식별을 방지하는 데 도움이 됩니다. AWS Clean Rooms 차등 프라이버시는에서 개발한 검증된 올바른 샘플러 구현인 [SampCert](https://github.com/leanprover/SampCert) 샘플러를 사용합니다 AWS. ## 의 차등 프라이버시 AWS Clean Rooms 작동 방식 에서 차등 프라이버시를 활성화하는 워크플로에는 [워크플로를 완료할 때 AWS Clean Rooms](what-is.md#how-it-works) 다음과 같은 추가 단계가 AWS Clean Rooms 필요합니다. 1. [사용자 지정 분석 규칙](analysis-rules-custom.md)을 추가할 때 차등 프라이버시 기능을 켭니다. 1. 쿼리에 사용할 수 있는 차등 프라이버시 기능으로 데이터 테이블을 보호하도록 [공동 작업의 차등 프라이버시 정책을 구성합니다](configure-differential-privacy.md). 이 단계를 완료하면 쿼리할 수 있는 구성원이 차등 프라이버시 보호 데이터에 대한 쿼리 실행을 시작할 수 있습니다. 차등 프라이버시 정책을 준수하는 결과를 AWS Clean Rooms 반환합니다. AWS Clean Rooms 차등 프라이버시는 차량의 현재 연료 수준을 보여주는 자동차의 가스 게이지와 유사하게 실행할 수 있는 나머지 쿼리의 예상 수를 추적합니다. 쿼리할 수 있는 구성원이 실행할 수 있는 쿼리 수는 [차등 프라이버시 정책](dp-settings.md)에 설정된 **프라이버시 예산** 및 **쿼리당 추가된 노이즈** 파라미터에 따라 제한됩니다. ### 고려 사항 에서 차등 프라이버시를 사용할 때는 다음 사항을 AWS Clean Rooms고려하세요. + 결과를 수신할 수 있는 구성원은 차등 프라이버시 기능을 사용할 수 없습니다. 구성한 테이블에서 차등 프라이버시 기능이 꺼진 상태로 사용자 지정 분석 규칙을 구성할 수 있습니다. + 둘 이상의 데이터 공급자 모두에 차등 프라이버시 기능이 켜져 있으면 쿼리를 수행할 수 있는 구성원은 둘 이상의 데이터 공급자의 테이블을 조인할 수 없습니다. # 차등 프라이버시 정책 차등 프라이버시 정책은 쿼리할 수 있는 구성원이 공동 작업에서 실행할 수 있는 집계 함수의 수를 제어합니다. **프라이버시 예산**은 공동 작업의 모든 테이블에 적용되는 한정된 공통 리소스를 정의합니다. **쿼리당 추가되는 노이즈**는 프라이버시 예산이 고갈되는 비율을 결정합니다. 차등 프라이버시 테이블을 쿼리에 사용할 수 있게 하려면 차등 프라이버시 정책이 필요합니다. 이는 공동 작업에서 한 번만 실행되는 단계이며 다음 2가지를 입력해야 합니다. + **프라이버시 예산** - 엡실론의 측면에서 수치화하면 프라이버시 예산에서 프라이버시 수준을 제어할 수 있습니다. 여러 테이블에 정보가 있을 수 있는 사용자의 개인 정보를 보호하는 것이 목표이므로 공동 작업 시 차등 프라이버시로 보호되는 모든 테이블에 적용되는 일반적이고 유한한 리소스입니다. **프라이버시 예산**은 테이블에서 쿼리가 실행될 때마다 소비됩니다. 프라이버시 예산이 모두 소진되면 쿼리할 수 있는 공동 작업 구성원은 예산이 증대되거나 새로 고침될 때까지 추가 쿼리를 실행할 수 없습니다. 프라이버시 예산을 더 많이 설정하면 결과를 수신할 수 있는 구성원이 데이터 내 개인에 대한 불확실성을 줄일 수 있습니다. 비즈니스 의사 결정권자와 상의한 후 프라이버시 요구 사항과 공동 작업 요구 사항 간의 균형을 맞출 수 있는 프라이버시 예산을 선택합니다. 공동 작업에 새 데이터를 정기적으로 가져오려는 경우 **매월 프라이버시 예산 새로 고침**을 선택하여 매월 새 프라이버시 예산을 자동으로 생성할 수 있습니다. 이 옵션을 선택하면 새로 고침 과정에서 반복해서 쿼리할 때 데이터 행에 대해 임의의 양의 정보가 공개될 수 있습니다. 프라이버시 예산 새로 고침 사이에 동일한 행이 반복적으로 쿼리되는 경우에는 이 옵션을 선택하지 않습니다. + **쿼리당 추가되는 노이즈**는 기여도를 난독화하고 싶은 사용자의 수를 기준으로 측정됩니다. 이 값에 따라 프라이버시 예산이 고갈되는 비율이 결정됩니다. 노이즈 값이 클수록 프라이버시 예산이 고갈되는 비율이 감소하므로 데이터에 대해 더 많은 쿼리를 실행할 수 있습니다. 하지만 정확도가 떨어지는 데이터 인사이트를 릴리스하는 것과 균형을 맞춰야 합니다. 이 값을 설정할 때는 공동 작업 인사이트에 필요한 정확도를 고려합니다. 기본 차등 프라이버시 정책을 사용하여 설정을 빠르게 완료하거나 사용 사례에 따라 차등 프라이버시 정책을 사용자 지정할 수 있습니다. AWS Clean Rooms 차등 프라이버시는 정책을 구성하는 직관적인 제어를 제공합니다. AWS Clean Rooms 차등 프라이버시를 사용하면 데이터의 모든 쿼리에서 가능한 집계 수 측면에서 유틸리티를 미리 보고 데이터 공동 작업에서 실행할 수 있는 쿼리 수를 추정할 수 있습니다. 대화형 예제를 사용하여 다양한 **프라이버시 예산** 값 및 **쿼리당 추가되는 노이즈**가 다양한 유형의 SQL 쿼리 결과에 어떤 영향을 미치는지 이해할 수 있습니다. 일반적으로 허용하려는 쿼리 수 및 해당 쿼리의 정확성과 프라이버시 요구 사항의 균형을 맞춰야 합니다. **프라이버시 예산**을 줄이거나 **쿼리당 추가되는 노이즈**를 더 늘리면 사용자 프라이버시를 더 잘 보호할 수 있지만 공동 작업 파트너에게 의미 있는 인사이트를 제공하지 못할 수 있습니다. **쿼리당 추가되는 노이즈** 파라미터를 동일하게 유지하면서 **프라이버시 예산**을 늘리면 쿼리할 수 있는 구성원이 공동 작업에서 테이블에 대해 더 많은 집계를 실행할 수 있습니다. 공동 작업 중에 언제든지 **프라이버시 예산**을 늘릴 수 있습니다. **쿼리당 추가되는 노이즈** 파라미터를 동일하게 유지하면서 **프라이버시 예산**을 줄이면 쿼리할 수 있는 구성원이 실행할 수 있는 집계가 줄어듭니다. 쿼리할 수 있는 구성원이 데이터 분석을 시작하면 **프라이버시 예산**을 줄일 수 없습니다. **프라이버시 예산** 입력값을 동일하게 유지하면서 **쿼리당 추가되는 노이즈**를 늘리면 쿼리할 수 있는 구성원이 공동 작업에서 테이블에 대해 더 많은 집계를 실행할 수 있습니다. **프라이버시 예산** 입력값을 동일하게 유지하면서 **쿼리당 추가되는 노이즈**를 줄이면 쿼리할 수 있는 구성원이 실행할 수 있는 집계가 줄어듭니다. 공동 작업 기간 동안 언제든지 **쿼리당 추가되는 노이즈**를 늘리거나 줄일 수 있습니다. 차등 프라이버시 정책은 프라이버시 예산 템플릿 API 작업에서 관리됩니다. # AWS Clean Rooms 차등 프라이버시의 SQL 기능 AWS Clean Rooms 차등 프라이버시는 범용 쿼리 구조를 사용하여 복잡한 SQL 쿼리를 지원합니다. 사용자 지정 분석 템플릿은 차등 프라이버시로 보호되는 테이블에서 실행할 수 있도록 이 구조에 대해 검증됩니다. 다음 테이블에는 지원되는 함수가 나와 있습니다. 자세한 정보는 [쿼리 구조 및 구문](analysis-rules-custom.md#dp-query-structure-syntax) 섹션을 참조하세요. | 카테고리 | Spark 분석 엔진에서 지원되는 SQL 구문 | 공통 테이블 표현식(CTE) | SQL SELECT 절 | | --- |--- |--- |--- | | Aggregate functions | ANY\$1VALUE 함수 APPROXIMATE PERCENTILE\$1DISC 함수 AVG 함수 COUNT 및 COUNT DISTINCT 함수 MAX 함수 MEDIAN 함수 MIN 함수 PERCENTILE\$1CONT 함수 STDDEV\$1SAMP 및 STDDEV\$1POP 함수 SUM 및 SUM DISTINCT 함수 VAR\$1SAMP 및 VAR\$1POP 함수 | Supported with the condition that CTEs using differential privacy protected tables must result in data with user-level records. You should write the SELECT expression in those CTEs using `SELECT userIdentifierColumn...' format. | Supported aggregations: AVG, COUNT, COUNT DISTINCT, STDDEV, and SUM. | | CTEs | WITH clause, WITH clause subquery | Supported with the condition that CTEs using differential privacy protected tables must result in data with user-level records. You should write the SELECT expression in those CTEs using `SELECT userIdentifierColumn...' format. | N/A | | Subqueries | SELECT HAVING JOIN JOIN 조건 FROM WHERE | You can have any subquery that doesn't reference differential privacy relations in these constructs. You can have any subquery that references differential privacy relations in a FROM and JOIN clause only. | | Join clauses | INNER JOIN LEFT JOIN 왼쪽 세미 조인 왼쪽 안티 조인 RIGHT JOIN FULL JOIN [JOIN] OR 연산자 CROSS JOIN | 사용자 식별자 열의 동등 조인인 JOIN 함수만 조건으로 지원되며, 차등 프라이버시가 설정된 상태에서 둘 이상의 테이블을 쿼리할 때는 필수 상태로 지원됩니다. 필수 동등 조인 조건이 올바른지 확인합니다. 테이블 소유자가 모든 테이블에서 동일한 사용자 식별자 열을 구성하면 사용자 정의가 테이블 간에 일관되게 유지됩니다. 차등 프라이버시가 켜진 상태에서 둘 이상의 관계를 결합할 때 CROSS JOIN 함수는 지원되지 않습니다. | | Set operators | UNION, UNION ALL, INTERSECT, EXCEPT \$1 MINUS (these are synonyms) | UNION, UNION ALL, INTERSECT, EXCEPT \$1 MINUS (these are synonyms) | Not supported | | Window functions | 집계 함수 AVG 창 함수 COUNT 창 함수 CUME\$1DIST 창 함수 DENSE\$1RANK 창 함수 FIRST\$1VALUE 창 함수 LAG 창 함수 LAST\$1VALUE 창 함수 LEAD 창 함수 MAX 창 함수 MEDIAN 창 함수 MIN 창 함수 NTH\$1VALUE 창 함수 STDDEV\$1SAMP 및 STDDEV\$1POP 창 함수(STDDEV\$1SAMP 및 STDDEV는 동의어) SUM 창 함수 VAR\$1SAMP 및 VAR\$1POP 창 함수(VAR\$1SAMP 및 VARIANCE는 동의어) 순위 함수 DENSE\$1RANK 창 함수 NTILE 창 함수 PERCENT\$1RANK 창 함수 RANK 창 함수 ROW\$1NUMBER 창 함수 | All are supported with the condition that the user identifier column in the window function's partition clause is required when you query a relation with differential privacy turned on. | Not supported | | Conditional expressions | CASE 조건식 COALESCE 표현식 GREATEST 및 LEAST 함수 NVL 및 COALESCE 함수 NVL2 함수 NULLIF 함수 | All are supported | All are supported | | Conditions | 비교 조건 논리 조건 패턴 일치 조건 BETWEEN 범위 조건 NULL 조건 | exists and IN can't be used because they require subqueries. All others are supported. | All are supported | | Date-time functions | 트랜잭션의 날짜 및 시간 함수 연결 연산자 ADD\$1MONTHS 함수 CONVERT\$1TIMEZONE 함수 CURRENT\$1DATE 함수 DATEADD 함수 DATEDIFF 함수 DATE\$1PART 함수 DATE\$1TRUNC 함수 EXTRACT 함수 TO\$1TIMESTAMP 함수 날짜 또는 타임스탬프 함수의 날짜 부분 | All are supported | All are supported | | String functions | \$1\$1(연결) 연산자 BTRIM 함수 CHAR\$1LENGTH 함수 CHARACTER\$1LENGTH 함수 CONCAT 함수 LEFT 및 RIGHT 함수 LEN 함수 LENGTH 함수 LOWER 함수 LPAD 및 RPAD 함수 ltrim 함수 POSITION 함수 REGEXP\$1COUNT 함수 REGEXP\$1INSTR 함수 REGEXP\$1REPLACE 함수 REGEXP\$1SUBSTR 함수 REPEAT 함수 REPLACE 함수 REVERSE 함수 RTRIM 함수 SPLIT\$1PART 함수 SUBSTRING 함수 TRANSLATE 함수 TRIM 함수 UPPER 함수 | All are supported | All are supported | | Data type formatting functions | CAST 함수 TO\$1CHAR TO\$1DATE 함수 TO\$1NUMBER 날짜/시간 형식 문자열 숫자 형식 문자열 | All are supported | All are supported | | Hash functions | AES\$1ENCRYPT AES\$1DECRYPT ENCODE DECODE MD5 함수 SHA1 함수 SHA2 함수 XX\$1HASH64 | All are supported | All are supported | | Mathematical operator symbols | \$1, -, \$1, /, %, and @ | All are supported | All are supported | | Math functions | ABS 함수 ACOS 함수 ASIN 함수 ATAN 함수 ATAN2 함수 CBRT 함수 CEILING(또는 CEIL) 함수 COS 함수 COT 함수 DEGREES 함수 ltrim 함수 EXP 함수 FLOOR 함수 LN 함수 LOG 함수 MOD 함수 PI 함수 POWER 함수 RADIANS 함수 RANDOM 함수 ROUND 함수 SIGN 함수 SIN 함수 SQRT 함수 TRUNC 함수 | All are supported | All are supported | | VARBYTE functions | UNHEX, UNBASE64 16진수 HLL\$1SKETCH\$1AGG, HLL\$1SKETCH\$1ESTIMATE HLL\$1UNION HLL\$1UNION\$1AGG | All are supported | All are supported | | JSON | TO\$1JSON GET\$1JSON\$1OBJECT | All are supported | All are supported | | Array functions | ARRAY\$1CONTAINS ARRAY\$1DISTINCT ARRAY\$1EXCEPT ARRAY\$1INTERSECT ARRAY\$1JOIN ARRAY\$1REMOVE ARRAY\$1SORT ARRAY\$1UNION | Not supported | Not supported | | Extended GROUP BY | GROUPING SETS, ROLLUP, CUBE | Not supported | Not supported | | Sort operation | ORDER BY | Supported with the condition that an ORDER BY clause is only supported in a window function's partition clause when querying tables with differential privacy turned on. | Supported | | Row limits | LIMIT, OFFSET | Not supported in CTEs using differential privacy protected tables | All are supported | | Table and column aliasing | | Supported | Supported | | Math functions on aggregate functions | | Supported | Supported | | Scalar functions within aggregate functions | | Supported | Supported | ## 지원되지 않는 SQL 구성에 대한 공통 대안 | 카테고리 | SQL 구성 | 대안 | | --- |--- |--- | | 윈도우 함수 | LISTAGG PERCENTILE\$1CONT PERCENTILE\$1DISC | You can use the equivalent aggregate function with GROUP BY. | | Mathematical operator symbols | \$1column \$1\$1/ 2 \$1column \$1/ 2 \$1column ^ 2 | CBRT SQRT POWER(\$1column, 2) | | Scalar functions | SYSDATE \$1column::정수 convert(유형, \$1column) | CURRENT\$1DATE CAST \$1column AS 정수 CAST \$1column AS 유형 | | Literals | INTERVAL ‘1 SECOND' | INTERVAL '1' SECOND | | Row limiting | TOP n | LIMIT n | | Join | USING NATURAL | ON clause should explicitly contain a join criterion. | # 차등 프라이버시 쿼리 팁 및 예제 AWS Clean Rooms 차등 프라이버시는 [범용 쿼리 구조를](dp-sql-capabilities.md) 사용하여 데이터 준비를 위한 공통 테이블 표현식(CTEs) 및 `COUNT`또는와 같이 일반적으로 사용되는 집계 함수와 같은 다양한 SQL 구문을 지원합니다`SUM`. 런타임 시 집계 쿼리 결과에 노이즈를 추가하여 데이터에서 가능한 사용자의 기여도를 난독화하려면 AWS Clean Rooms 차등 프라이버시를 사용하려면 최종의 집계 함수가 사용자 수준 데이터에서 실행`SELECT statement`되어야 합니다. 다음 예제에서는 `athletic_brand_sales` 데이터가 포함된 스포츠 브랜드와 공동 작업하면서 차등 프라이버시를 사용하여 데이터를 보호하려는 미디어 게시자의 `socialco_impressions` 및 `socialco_users`라는 테이블 2개를 사용합니다. 미디어 게시자는 이 `user_id` 열을 사용자 식별자 열로 구성하면서 차등 프라이버시를 AWS Clean Rooms에서 사용 설정했습니다. 광고주는 차등 프라이버시 보호가 필요하지 않으므로 결합된 데이터에서 CTE를 사용하여 쿼리를 실행하려고 합니다. CTE는 차등 프라이버시 보호 테이블을 사용하기 때문에 광고주는 보호 테이블의 사용자 식별자 열을 CTE 열 목록에 포함시키고 사용자 식별자 열에 보호 테이블을 조인합니다. ``` WITH matches_table AS( SELECT si.user_id, si.campaign_id, s.sale_id, s.sale_price FROM socialco_impressions si JOIN socialco_users su ON su.user_id = si.user_id JOIN athletic_brand_sales s ON s.emailsha256 = su.emailsha256 WHERE s.timestamp > si.timestamp UNION ALL SELECT si.user_id, si.campaign_id, s.sale_id, s.sale_price FROM socialco_impressions si JOIN socialco_users su ON su.user_id = si.user_id JOIN athletic_brand_sales s ON s.phonesha256 = su.phonesha256 WHERE s.timestamp > si.timestamp ) SELECT COUNT (DISTINCT user_id) as unique_users FROM matches_table GROUP BY campaign_id ORDER BY COUNT (DISTINCT user_id) DESC LIMIT 5 ``` 마찬가지로 차등 프라이버시 보호 데이터 테이블에서 창 함수를 실행하려면 `PARTITION BY` 절에 사용자 식별자 열을 포함해야 합니다. ``` ROW_NUMBER() OVER (PARTITION BY conversion_id, user_id ORDER BY match_type, match_age) AS row ``` # AWS Clean Rooms 차등 프라이버시의 제한 사항 AWS Clean Rooms 차등 프라이버시는 다음 상황을 해결하지 않습니다. 1. AWS Clean Rooms 차등 프라이버시는 Amazon S3 지원 AWS Glue 테이블을 사용하는 쿼리만 지원합니다. Snowflake 또는 Amazon Athena 테이블을 사용한 쿼리는 지원하지 않습니다. 1. AWS Clean Rooms 차등 프라이버시는 타이밍 공격을 해결하지 않습니다. 예를 들어 개별 사용자가 많은 행을 제공하고 이 사용자를 추가하거나 제거하면 쿼리 계산 시간이 크게 달라지는 시나리오에서 이러한 공격이 발생할 수 있습니다. 1. AWS Clean Rooms 차등 프라이버시는 SQL 쿼리로 인해 특정 SQL 구문의 사용으로 인해 런타임에 오버플로 또는 잘못된 캐스트 오류가 발생할 수 있는 경우 차등 프라이버시를 보장하지 않습니다. 다음 표는 런타임 오류를 생성할 수 있으므로 분석 템플릿에서 확인해야 하는 일부 SQL 구문(전부는 아님) 목록입니다. 이러한 런타임 오류의 가능성을 최소화하는 분석 템플릿을 승인하고 쿼리 로그를 주기적으로 검토하여 쿼리가 공동 작업 계약에 부합하는지 확인하는 것이 좋습니다. 다음 SQL 구문은 오버플로 오류에 취약합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/dp-limitations.html) 1. CAST 데이터 유형 서식 설정 함수는 잘못된 캐스트 오류에 취약합니다. [로그 그룹에 대한 지표 필터를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)하도록 CloudWatch를 구성한 다음 해당 지표 필터에 대해 [CloudWatch 경보를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)하여 잠재적인 오버플로 또는 캐스팅 오류가 발생할 경우 알림을 받을 수 있습니다. 특히 오류 코드 `CastError`, `OverflowError`, `ConversionError`를 모니터링해야 합니다. 이러한 오류 코드는 잠재적인 부채널 공격을 나타내지만 잘못된 SQL 쿼리를 나타낼 수도 있습니다. 자세한 내용은 [의 분석 로깅 AWS Clean Rooms](query-logs.md) 단원을 참조하십시오. # AWS Clean Rooms ML AWS Clean Rooms ML을 사용하면 두 명 이상의 당사자가 데이터를 서로 공유할 필요 없이 데이터에 대해 기계 학습 모델을 실행할 수 있습니다. 이 서비스는 데이터 소유자가 데이터와 모델 IP를 안전하게 보호할 수 있는 개인 정보 보호 제어를 제공합니다. AWS 작성 모델을 사용하거나 자체 사용자 지정 모델을 가져올 수 있습니다. 작동하는 방식에 대한 자세한 설명은 [교차 계정 작업](ml-behaviors.md#ml-behaviors-cross-account-jobs) 섹션을 참조하세요. Clean Rooms ML 모델의 기능에 대한 자세한 내용은 다음 주제를 참조하세요. **Topics** + [AWS Clean Rooms ML 용어](#ml-terminology) + [AWS Clean Rooms ML이 AWS 모델과 작동하는 방식](#ml-how-it-works) + [AWS Clean Rooms ML이 사용자 지정 모델과 작동하는 방식](#custML-how-it-works) + [AWS Clean Rooms ML의 모델](aws-models.md) + [Clean Rooms ML의 사용자 지정 모델](custom-models.md) ## AWS Clean Rooms ML 용어 Clean Rooms ML을 사용할 때는 다음 용어를 이해하는 것이 중요합니다. + *훈련 데이터 공급자* – 훈련 데이터를 제공하고 유사 모델을 생성 및 구성한 다음 해당 유사 모델을 공동 작업에 연결하는 역할을 합니다. + *시드 데이터 공급자* - 시드 데이터를 제공하고 유사 세그먼트를 생성하여 유사 세그먼트를 내보내는 역할을 합니다. + *훈련 데이터* - 유사 모델을 생성하는 데 사용되는 훈련 데이터 공급자의 데이터입니다. 훈련 데이터는 사용자 동작의 유사성을 측정하는 데 사용됩니다. 훈련 데이터에는 사용자 ID, 항목 ID 및 타임스탬프 열이 포함되어야 합니다. 필요에 따라 훈련 데이터에 다른 상호작용을 수치적 특징 또는 범주형 특징으로 포함할 수 있습니다. 상호작용의 예로는 시청한 동영상, 구매한 항목, 읽은 기사 목록 등이 있습니다. + *시드 데이터* - 유사 세그먼트를 만드는 데 사용되는 시드 데이터 공급자의 데이터입니다. 시드 데이터는 직접 제공하거나 AWS Clean Rooms 쿼리 결과에서 가져올 수 있습니다. 유사 세그먼트는 시드 사용자와 가장 유사한 훈련 데이터의 사용자 집합입니다. + *유사 모델* - 다른 데이터 세트에서 유사한 사용자를 찾는 데 사용되는 훈련 데이터의 기계 학습 모델입니다. API를 사용할 때 *대상 모델*이라는 용어는 유사 모델과 동일하게 사용됩니다. 예를 들어 [CreateAudienceModel](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateAudienceModel.html) API를 사용하여 유사 모델을 만들 수 있습니다. + *유사 세그먼트* - 시드 데이터와 가장 유사한 훈련 데이터의 하위 집합입니다. API를 사용할 때 [StartAudienceGenerationJob](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_StartAudienceGenerationJob.html) API를 사용하여 유사 세그먼트를 생성합니다. 훈련 데이터 공급자의 데이터는 시드 데이터 공급자와 공유되지 않으며 시드 데이터 공급자의 데이터도 훈련 데이터 공급자와 공유되지 않습니다. 유사 세그먼트 출력은 훈련 데이터 공급자와 공유되지만 시드 데이터 공급자와는 공유되지 않습니다. ## AWS Clean Rooms ML이 AWS 모델과 작동하는 방식 ![\[AWS Clean Rooms ML이 AWS 모델과 작동하는 방식에 대한 개요입니다.\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/images/howItWorksML.png) 유사 모델을 사용하려면 훈련 데이터 공급자와 시드 데이터 공급자라는 두 당사자가 순차적으로에서 작업 AWS Clean Rooms 하여 데이터를 공동 작업으로 가져와야 합니다. 훈련 데이터 공급자가 먼저 완료해야 하는 워크플로는 다음과 같습니다. 1. 훈련 데이터 공급자의 데이터는 사용자-항목 상호 작용의 AWS Glue 데이터 카탈로그 테이블에 저장되어야 합니다. 훈련 데이터에는 최소한 사용자 ID 열, 상호 작용 ID 열 및 타임스탬프 열이 포함되어야 합니다. 1. 훈련 데이터 공급자는 훈련 데이터를에 등록합니다 AWS Clean Rooms. 1. 훈련 데이터 공급자는 여러 시드 데이터 공급자와 공유할 수 있는 유사 모델을 생성합니다. 유사 모델은 신경망이며, 훈련하는 데 최대 24시간이 걸릴 수 있습니다. 자동으로 재훈련되지 않으므로 매주 모델을 재훈련하는 것이 좋습니다. 1. 훈련 데이터 공급자는 관련성 지표 공유 여부 및 출력 세그먼트의 Amazon S3 위치를 포함하여 유사 모델을 구성합니다. 훈련 데이터 공급자는 단일 유사 모델에서 구성된 유사 모델을 여러 개 생성할 수 있습니다. 1. 훈련 데이터 공급자는 구성된 대상 모델을 시드 데이터 공급자와 공유하는 공동 작업에 연결합니다. 시드 데이터 공급자가 다음으로 완료해야 하는 워크플로는 다음과 같습니다. 1. 시드 데이터 공급자의 데이터는 Amazon S3 버킷에 저장하거나 쿼리 결과에서 가져올 수 있습니다. 1. 시드 데이터 공급자는 훈련 데이터 공급자와 공유하는 공동 작업을 엽니다. 1. 시드 데이터 공급자는 공동 작업 페이지의 Clean Rooms ML 탭에서 유사 세그먼트를 만듭니다. 1. 시드 데이터 공급자는 관련성 지표가 공유된 경우 이를 평가하고 유사 세그먼트를 내보내 AWS Clean Rooms외부에서 사용할 수 있습니다. ## AWS Clean Rooms ML이 사용자 지정 모델과 작동하는 방식 Clean Rooms ML을 사용하면 공동 작업 구성원이 Amazon ECR에 저장된 도킹된 사용자 지정 모델 알고리즘을 사용하여 데이터를 공동 분석할 수 있습니다. 이렇게 하려면 *모델 공급자*가 이미지를 생성하고 Amazon ECR에 저장해야 합니다. [Amazon Elastic Container Registry 사용 설명서](https://docs.aws.amazon.com/AmazonECR/latest/userguide/)의 단계에 따라 사용자 지정 ML 모델을 포함할 프라이빗 리포지토리를 생성합니다. 올바른 권한이 있는 경우 공동 작업의 모든 구성원이 *모델 공급자*가 될 수 있습니다. 공동 작업의 모든 구성원은 훈련 데이터, 추론 데이터 또는 둘 다를 모델에 제공할 수 있습니다. 이 안내서의 목적상 데이터를 제공하는 구성원을 *데이터 공급자*라고 합니다. 공동 작업을 생성하는 구성원은 *공동 작업 생성*자이며,이 구성원은 *모델 공급자*, *데이터 공급자* 중 하나 또는 둘 다일 수 있습니다. 가장 높은 수준에서 사용자 지정 ML 모델링을 수행하기 위해 완료해야 하는 단계는 다음과 같습니다. 1. 공동 작업 생성자는 공동 작업을 생성하고 각 구성원에게 적절한 구성원 기능 및 결제 구성을 할당합니다. 공동 작업 생성자는 모델 출력을 수신하거나 추론 결과를 수신할 수 있는 구성원 기능을이 단계의 적절한 구성원에게 할당해야 합니다. 공동 작업이 생성된 후에는 업데이트할 수 없기 때문입니다. 자세한 내용은 [AWS Clean Rooms ML에서 공동 작업 생성 및 참여](create-custom-ml-collaboration.md) 단원을 참조하십시오. 1. 모델 공급자는 컨테이너화된 ML 모델을 구성하여 공동 작업에 연결하고 내보낸 데이터에 대해 개인 정보 보호 제약 조건이 설정되도록 합니다. 자세한 내용은 [AWS Clean Rooms ML에서 모델 알고리즘 구성](configure-model-algorithm.md) 단원을 참조하십시오. 1. 데이터 공급자는 데이터를 공동 작업에 기여하고 개인 정보 보호 요구 사항이 지정되도록 합니다. 데이터 공급자는 모델이 데이터에 액세스할 수 있도록 허용해야 합니다. 자세한 내용은 [AWS Clean Rooms ML에서 훈련 데이터 기여](custom-model-training-data.md) 및 [AWS Clean Rooms ML에서 구성된 모델 알고리즘 연결](associate-model-algorithm.md) 섹션을 참조하세요. 1. 공동 작업 구성원은 모델 아티팩트 또는 추론 결과를 내보낼 위치를 정의하는 ML 구성을 생성합니다. 1. 공동 작업 구성원은 훈련 컨테이너 또는 추론 컨테이너에 입력을 제공하는 ML 입력 채널을 생성합니다. ML 입력 채널은 모델 알고리즘의 컨텍스트에서 사용할 데이터를 정의하는 쿼리입니다. 1. 공동 작업 구성원은 ML 입력 채널과 구성된 모델 알고리즘을 사용하여 모델 훈련을 호출합니다. 자세한 내용은 [AWS Clean Rooms ML에서 훈련된 모델 생성](create-trained-model.md) 단원을 참조하십시오. 1. (선택 사항) 모델 트레이너는 모델 내보내기 작업을 호출하고 모델 아티팩트는 모델 결과 수신기로 전송됩니다. 유효한 ML 구성을 가진 멤버와 모델 출력을 수신하는 멤버 기능만 모델 아티팩트를 수신할 수 있습니다. 자세한 내용은 [AWS Clean Rooms ML에서 모델 아티팩트 내보내기](export-model-artifacts.md) 단원을 참조하십시오. 1. (선택 사항) 공동 작업 구성원은 ML 입력 채널, 훈련된 모델 ARN 및 추론 구성 모델 알고리즘을 사용하여 모델 추론을 호출합니다. 추론 결과는 추론 출력 수신기로 전송됩니다. ML 구성이 유효하고 추론 출력을 수신할 수 있는 멤버만 추론 결과를 수신할 수 있습니다. 다음은 *모델 공급자*가 완료해야 하는 단계입니다. 1. SageMaker AI 호환 Amazon ECR Docker 이미지를 생성합니다. Clean Rooms ML은 SageMaker AI 호환 도커 이미지만 지원합니다. 1. SageMaker AI 호환 도커 이미지를 생성한 후 이미지를 Amazon ECR로 푸시합니다. [Amazon Elastic Container Registry 사용 설명서](https://docs.aws.amazon.com/AmazonECR/latest/userguide/)의 지침에 따라 컨테이너 훈련 이미지를 생성합니다. 1. Clean Rooms ML에서 사용할 모델 알고리즘을 구성합니다. 1. Amazon ECR 리포지토리 링크와 모델 알고리즘을 구성하는 데 필요한 인수를 제공합니다. 1. Clean Rooms ML이 Amazon ECR 리포지토리에 액세스할 수 있는 서비스 액세스 역할을 제공합니다. 1. 구성된 모델 알고리즘을 공동 작업과 연결합니다. 여기에는 컨테이너 로그, 실패 로그, CloudWatch 지표 및 컨테이너 결과에서 내보낼 수 있는 데이터의 양에 대한 제한에 대한 제어를 정의하는 개인 정보 보호 정책 제공이 포함됩니다. 다음은 *데이터 공급자*가 사용자 지정 ML 모델과 협업하기 위해 완료해야 하는 단계입니다. 1. 사용자 지정 분석 규칙을 사용하여 기존 AWS Glue 테이블을 구성합니다. 이렇게 하면 사전 승인된 특정 쿼리 세트 또는 사전 승인된 계정이 데이터를 사용할 수 있습니다. 1. 구성된 테이블을 공동 작업과 연결하고 AWS Glue 테이블에 액세스할 수 있는 서비스 액세스 역할을 제공합니다. 1. 구성된 모델 알고리즘 연결이 구성된 테이블에 액세스할 수 있도록 하는 [공동 작업 분석 규칙을 테이블에 추가합니다](add-collaboration-analysis-rule.md). 1. Clean Rooms ML에서 모델과 데이터를 연결하고 구성한 후 쿼리를 실행할 수 있는 구성원은 SQL 쿼리를 제공하고 사용할 모델 알고리즘을 선택합니다. 모델 훈련이 완료되면 해당 구성원은 모델 훈련 아티팩트 또는 추론 결과의 내보내기를 시작합니다. 이러한 아티팩트 또는 결과는 훈련된 모델 출력을 수신할 수 있는 기능을 가진 멤버에게 전송됩니다. 결과 수신자는 모델 출력을 수신하기 `MachineLearningConfiguration` 전에를 구성해야 합니다. # AWS Clean Rooms ML의 모델 AWS Clean Rooms ML은 두 당사자가 데이터를 서로 공유할 필요 없이 데이터에서 유사한 사용자를 식별할 수 있는 개인 정보 보호 방법을 제공합니다. 첫 번째 당사자는 유사 모델을 생성 및 구성하고 이를 공동 작업과 연결할 수 AWS Clean Rooms 있도록 훈련 데이터를에 가져옵니다. 그런 다음 시드 데이터를 공동 작업에 가져와서 훈련 데이터와 유사한 유사 세그먼트를 만듭니다. 작동하는 방식에 대한 자세한 설명은 [교차 계정 작업](ml-behaviors.md#ml-behaviors-cross-account-jobs) 섹션을 참조하세요. 다음 주제에서는 Clean Rooms ML에서 AWS 모델을 생성하고 구성하는 방법에 대한 정보를 제공합니다. **Topics** + [AWS Clean Rooms ML의 개인 정보 보호](ml-privacy.md) + [Clean Rooms ML의 훈련 데이터 요구 사항](ml-training-data-requirements.md) + [Clean Rooms ML의 시드 데이터 요구 사항](ml-seed-data-requirements.md) + [AWS Clean Rooms ML 모델 평가 지표](ml-metrics.md) # AWS Clean Rooms ML의 개인 정보 보호 Clean Rooms ML은 훈련 데이터 공급자가 시드 데이터에 있는 사용자를 알고 시드 데이터 공급자가 훈련 데이터에 있는 사용자를 알 수 있는 *멤버십 추론 공격*의 위험을 줄이도록 설계되었습니다. 이 공격을 방지하기 위해 취할 수 있는 몇 가지 단계가 있습니다. 첫째, 시드 데이터 공급자는 Clean Rooms ML 결과를 직접 관찰하지 않으며 훈련 데이터 공급자는 시드 데이터를 절대 관찰할 수 없습니다. 시드 데이터 공급자는 출력 세그먼트에 시드 데이터를 포함하도록 선택할 수 있습니다. 다음으로, 훈련 데이터의 랜덤 샘플에서 유사 모델을 만듭니다. 이 샘플에는 시드 대상과 일치하지 않는 상당수의 사용자가 포함되어 있습니다. 이 프로세스를 통해 사용자가 데이터에 없는지 확인하기가 더 어려워지며, 이는 멤버십 추론의 또 다른 방법입니다. 또한 시드별 유사 모델 훈련의 모든 파라미터에 여러 시드 고객을 사용할 수 있습니다. 이로 인해 모델이 오버피팅할 수 있는 양과 사용자에 대해 추론할 수 있는 양이 제한됩니다. 따라서 시드 데이터의 최소 크기는 사용자 500명으로 설정하는 것이 좋습니다. 마지막으로, 사용자 수준 지표는 훈련 데이터 공급자에게 절대 제공되지 않으므로 멤버십 추론 공격의 또 다른 수단이 없어집니다. # Clean Rooms ML의 훈련 데이터 요구 사항 유사 모델을 성공적으로 생성하려면 훈련 데이터가 다음 요구 사항을 충족해야 합니다. + 훈련 데이터는 Parquet, CSV 또는 JSON 형식이어야 합니다. **참고** Zstandard(ZSTD) 압축 Parquet 데이터는 지원되지 않습니다. + 훈련 데이터는 카탈로그로 작성해야 합니다 AWS Glue. 자세한 내용은 AWS Glue 개발자 안내서[의 AWS Glue 데이터 카탈로그 시작하기](https://docs.aws.amazon.com//glue/latest/dg/start-data-catalog.html)를 참조하세요. 스키마가 자동으로 추론되므로 AWS Glue 크롤러를 사용하여 테이블을 생성하는 것이 좋습니다. + 훈련 데이터 및 시드 데이터가 포함된 Amazon S3 버킷은 다른 Clean Rooms ML 리소스와 동일한 AWS 리전에 있습니다. + 훈련 데이터에는 항목 상호 작용이 각각 두 개 이상 있는 고유한 사용자 ID가 100,000개 이상 포함되어야 합니다. + 학습 데이터에는 최소 1백만 개의 레코드가 포함되어야 합니다. + [CreateTrainingDataset](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateTrainingDataset.html) 작업에 지정된 스키마는 AWS Glue 테이블이 생성될 때 정의된 스키마와 일치해야 합니다. + 제공된 표에 정의된 필수 필드는 [CreateTrainingDataset](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateTrainingDataset.html) 작업에 정의되어 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/ml-training-data-requirements.html) + 선택적으로 범주형 또는 숫자형 기능을 최대 10개 제공할 수 있습니다. 다음은 CSV 형식의 유효한 훈련 데이터 세트의 예입니다. ``` USER_ID,ITEM_ID,TIMESTAMP,EVENT_TYPE(CATEGORICAL FEATURE),EVENT_VALUE (NUMERICAL FEATURE) 196,242,881250949,click,15 186,302,891717742,click,13 22,377,878887116,click,10 244,51,880606923,click,20 166,346,886397596,click,10 ``` # Clean Rooms ML의 시드 데이터 요구 사항 유사 모델의 시드 데이터는 Amazon S3 버킷에서 직접 가져오거나 SQL 쿼리의 결과에서 가져올 수 있습니다. 직접 제공되는 시드 데이터는 다음 요구 사항을 충족해야 합니다. + 시드 데이터는 사용자 IDs. + 시드 크기는 25\$1500,000개의 고유 사용자 ID여야 합니다. + 최소 시드 사용자 수는 구성된 대상 모델을 생성할 때 지정된 최소 일치 시드 크기 값과 일치해야 합니다. 다음은 CSV 형식의 유효한 훈련 데이터 세트의 예입니다. ``` {"user_id": "abc"} {"user_id": "def"} {"user_id": "ghijkl"} {"user_id": "123"} {"user_id": "456"} {"user_id": "7890"} ``` # AWS Clean Rooms ML 모델 평가 지표 Clean Rooms ML은 리콜 및 관련성 점수를 계산하여 모델의 성능을 결정합니다.**** 리콜은 유사 데이터와 훈련 데이터 간의 유사성을 비교합니다. 관련성 점수는 모델 성능이 좋은지 여부가 아니라 대상의 규모를 결정하는 데 사용됩니다. *리콜*은 유사 세그먼트가 훈련 데이터와 얼마나 유사한지를 편향 없이 측정한 것입니다. 리콜은 대상 생성 작업을 통해 시드 대상에 포함된 훈련 데이터 샘플에서 가장 유사한 사용자(기본적으로 가장 유사한 20%)의 백분율입니다. 값의 범위는 0\$11이며, 값이 클수록 더 나은 대상을 나타냅니다. 최대 빈 백분율과 거의 동일한 리콜 값은 대상 모델이 무작위 선택과 동일함을 나타냅니다. Clean Rooms ML은 모델을 구축할 때 실제 부정적 사용자를 정확하게 분류하지 않기 때문에 정확도, 정밀도, F1 점수보다 이 평가 지표가 더 나은 평가 지표로 간주됩니다. 세그먼트 수준 *관련성 점수*는 -1(가장 유사하지 않음)에서 1(가장 유사함) 사이의 값을 갖는 유사성 척도입니다. Clean Rooms ML은 다양한 세그먼트 크기에 대한 관련성 점수 집합을 계산하여 데이터에 가장 적합한 세그먼트 크기를 결정하는 데 도움을 줍니다. 관련성 점수는 세그먼트 크기가 증가함에 따라 단조롭게 감소하므로 세그먼트 크기가 증가함에 따라 시드 데이터와 덜 유사할 수 있습니다. 세그먼트 수준 관련성 점수가 0에 도달하면 모델은 유사 세그먼트의 모든 사용자가 시드 데이터와 동일한 분포에 속한다고 예측합니다. 출력 크기를 늘리면 유사 세그먼트에 시드 데이터와 동일한 분포에 속하지 않는 사용자가 포함될 가능성이 높습니다. 관련성 점수는 단일 캠페인 내에서 정규화되므로 여러 캠페인을 비교하는 데 사용해서는 안 됩니다. 관련성 점수는 인벤토리 품질, 인벤토리 유형, 광고 시기 등과 같은 관련성 외에도 여러 복잡한 요인의 영향을 받기 때문에 비즈니스 성과에 대한 단일 소스 증거로 사용해서는 안 됩니다. 관련성 점수는 시드의 품질을 판단하는 데 사용할 것이 아니라 높이거나 낮출 수 있는지를 판단하는 데 사용해야 합니다. 다음 예제를 살펴보세요. + 전부 플러스인 점수 - 이는 유사 세그먼트에 포함된 것보다 유사한 것으로 예측된 출력 사용자가 더 많다는 것을 나타냅니다. 이는 지난 한 달 동안 치약을 구매한 모든 사람과 같이 규모가 큰 시장의 일부 시드 데이터에서 흔히 볼 수 있습니다. 지난 한 달 동안 치약을 두 번 이상 구매한 모든 사람과 같이 소규모 시드 데이터를 살펴보는 것이 좋습니다. + 원하는 유사 세그먼트 크기에서 전부 마이너스 점수 - 이는 Clean Rooms ML이 원하는 유사 세그먼트 크기에서 유사한 사용자가 충분하지 않을 것으로 예측한다는 것을 나타냅니다. 이는 시드 데이터가 너무 구체적이거나 시장 규모가 너무 작기 때문일 수 있습니다. 시드 데이터에 적용할 필터 수를 줄이거나 시장을 확대하는 것이 좋습니다. 예를 들어 원래 시드 데이터가 유모차와 카시트를 구매한 고객이었다면 유아용품을 여러 개 구매한 고객으로 시장을 확대할 수 있습니다. 훈련 데이터 공급자는 관련성 점수의 노출 여부와 관련성 점수를 계산하는 버킷 빈을 결정합니다. # Clean Rooms ML의 사용자 지정 모델 Clean Rooms ML을 사용하면 공동 작업 구성원이 Amazon ECR에 저장된 도킹된 사용자 지정 모델 알고리즘을 사용하여 데이터를 공동 분석할 수 있습니다. 이렇게 하려면 *모델 공급자*가 이미지를 생성하고 Amazon ECR에 저장해야 합니다. [Amazon Elastic Container Registry 사용 설명서](https://docs.aws.amazon.com/AmazonECR/latest/userguide/)의 단계에 따라 사용자 지정 ML 모델을 포함할 프라이빗 리포지토리를 생성합니다. 올바른 권한이 있는 경우 공동 작업의 모든 구성원이 *모델 공급자*가 될 수 있습니다. 공동 작업의 모든 구성원은 모델에 데이터를 제공할 수 있습니다. 이 안내서의 목적상 데이터를 제공하는 구성원을 *데이터 공급자*라고 합니다. 공동 작업을 생성하는 구성원은 *공동 작업 생성*자이며,이 구성원은 *모델 공급자*, *데이터 공급자* 중 하나 또는 둘 다일 수 있습니다. 다음 주제에서는 사용자 지정 ML 모델을 생성하는 데 필요한 정보를 설명합니다. **Topics** + [사용자 지정 ML 모델링 사전 조건](custom-model-prerequisites.md) + [훈련 컨테이너에 대한 모델 작성 지침](custom-model-guidelines.md) + [추론 컨테이너에 대한 모델 작성 지침](inference-model-guidelines.md) + [모델 로그 및 지표 수신](custom-model-logs.md) # 사용자 지정 ML 모델링 사전 조건 사용자 지정 ML 모델링을 수행하려면 먼저 다음 사항을 고려해야 합니다. + 훈련된 모델에 대한 모델 훈련과 추론을 공동 작업에서 수행할지 여부를 결정합니다. + 각 공동 작업 구성원이 수행할 역할을 결정하고 적절한 기능을 할당합니다. + 모델을 훈련하고 훈련된 모델에 대해 추론을 실행할 구성원에게 `CAN_QUERY` 기능을 할당합니다. + 공동 작업의 구성원 한 명 이상`CAN_RECEIVE_RESULTS`에게를 할당합니다. + 훈련된 모델 내보내기 `CAN_RECEIVE_MODEL_OUTPUT` 또는 추론 출력을 각각 받을 구성원에게 또는 `CAN_RECEIVE_INFERENCE_OUTPUT` 기능을 할당합니다. 사용 사례에 필요한 경우 두 기능을 모두 사용하도록 선택할 수 있습니다. + 내보내도록 허용할 훈련된 모델 아티팩트 또는 추론 결과의 최대 크기를 결정합니다. + 모든 사용자에게 역할에 연결된 `CleanrooomsFullAccess` 및 `CleanroomsMLFullAccess` 정책이 있는 것이 좋습니다. 사용자 지정 ML 모델을 사용하려면 AWS Clean Rooms 및 AWS Clean Rooms ML SDKs. + IAM 역할에 대한 다음 정보를 고려합니다. + 모든 데이터 공급자는가 AWS Glue 카탈로그 및 테이블과 기본 Amazon S3 위치에서 데이터를 AWS Clean Rooms 읽을 수 있도록 허용하는 서비스 액세스 역할이 있어야 합니다. 이러한 역할은 SQL 쿼리에 필요한 역할과 유사합니다. 이렇게 하면 `CreateConfiguredTableAssociation` 작업을 사용할 수 있습니다. 자세한 내용은 [서비스 역할을 생성하여 구성된 테이블 연결 생성](ml-roles.md#ml-roles-custom-configure-table) 단원을 참조하십시오. + 지표를 수신하려는 모든 멤버는 CloudWatch 지표 및 로그를 작성할 수 있는 서비스 액세스 역할이 있어야 합니다. 이 역할은 Clean Rooms ML에서 모델 훈련 및 추론 AWS 계정 중에 모든 모델 지표와 로그를 멤버의에 기록하는 데 사용됩니다. 또한 지표 및 로그에 액세스할 수 있는 구성원을 결정하기 위한 개인 정보 보호 제어 기능도 제공합니다. 이렇게 하면 `CreateMLConfiguration` 작업을 사용할 수 있습니다. 자세한 내용은 단원을 참조하십시오[사용자 지정 ML 모델링을 위한 서비스 역할 생성 - ML 구성](ml-roles.md#ml-roles-custom-configure). 결과를 수신하는 멤버는 서비스 액세스 역할에 Amazon S3 버킷에 쓸 수 있는 권한을 제공해야 합니다. 이 역할을 통해 Clean Rooms ML은 결과(학습된 모델 아티팩트 또는 추론 결과)를 Amazon S3 버킷으로 내보낼 수 있습니다. 이렇게 하면 `CreateMLConfiguration` 작업을 사용할 수 있습니다. 자세한 내용은 [사용자 지정 ML 모델링을 위한 서비스 역할 생성 - ML 구성](ml-roles.md#ml-roles-custom-configure) 단원을 참조하십시오. + 모델 공급자는 서비스 액세스 역할에 Amazon ECR 리포지토리 및 이미지를 읽을 수 있는 권한을 제공해야 합니다. 이렇게 하면 `CreateConfigureModelAlgorithm` 작업을 사용할 수 있습니다. 자세한 내용은 [서비스 역할을 생성하여 사용자 지정 ML 모델 제공](ml-roles.md#ml-roles-custom-model-provider) 단원을 참조하십시오. + 훈련 또는 추론`MLInputChannel`용 데이터 세트를 생성하기 위해를 생성하는 구성원은 Clean Rooms ML이 SQL 쿼리를 실행할 수 있도록 허용하는 서비스 액세스 역할을 제공해야 합니다 AWS Clean Rooms. 이렇게 하면 `CreateTrainedModel` 및 `StartTrainedModelInferenceJob` 작업을 사용할 수 있습니다. 자세한 내용은 [데이터 세트를 쿼리할 서비스 역할 생성](ml-roles.md#ml-roles-custom-query-dataset) 단원을 참조하십시오. + 모델 작성자는 [훈련 컨테이너에 대한 모델 작성 지침](custom-model-guidelines.md) 모델 입력 및 출력이 예상대로 구성되도록 [추론 컨테이너에 대한 모델 작성 지침모델 로그 및 지표 수신](inference-model-guidelines.md) 및를 따라야 합니다 AWS Clean Rooms. # 훈련 컨테이너에 대한 모델 작성 지침 이 섹션에서는 Clean Rooms ML용 사용자 지정 ML 모델 알고리즘을 생성할 때 모델 공급자가 따라야 하는 지침을 자세히 설명합니다. + SageMaker AI [개발자 안내서에 설명된 대로 적절한 SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg-ecr-paths/sagemaker-algo-docker-registry-paths.html) 훈련 지원 컨테이너 기본 이미지를 사용합니다. 다음 코드를 사용하면 퍼블릭 SageMaker AI 엔드포인트에서 지원되는 컨테이너 기본 이미지를 가져올 수 있습니다. ``` ecr_registry_endpoint='763104351884.dkr.ecr.$REGION.amazonaws.com' base_image='pytorch-training:2.3.0-cpu-py311-ubuntu20.04-sagemaker' aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ecr_registry_endpoint docker pull $ecr_registry_endpoint/$base_image ``` + 모델을 로컬에서 작성할 때 개발 인스턴스,의 SageMaker AI 훈련 및 AWS 계정 Clean Rooms ML에서 로컬에서 모델을 테스트할 수 있도록 다음을 확인하세요. + 다양한 환경 변수를 통해 훈련 환경에 대한 유용한 속성에 액세스하는 훈련 스크립트를 작성하는 것이 좋습니다. Clean Rooms ML은 `SM_MODEL_DIR`, `SM_OUTPUT_DIR`, `SM_CHANNEL_TRAIN`및 인수를 사용하여 모델 코드에 대한 훈련을 호출합니다`FILE_FORMAT`. 이러한 기본값은 Clean Rooms ML에서 모든 당사자의 데이터를 사용하여 자체 실행 환경에서 ML 모델을 훈련하는 데 사용됩니다. + Clean Rooms ML을 사용하면 Docker 컨테이너의 `/opt/ml/input/data/channel-name` 디렉터리를 통해 훈련 입력 채널을 사용할 수 있습니다. 각 ML 입력 채널은 `CreateTrainedModel` 요청에 `channel_name` 제공된 해당를 기반으로 매핑됩니다. ``` parser = argparse.ArgumentParser()# Data, model, and output directories parser.add_argument('--model_dir', type=str, default=os.environ.get('SM_MODEL_DIR', "/opt/ml/model")) parser.add_argument('--output_dir', type=str, default=os.environ.get('SM_OUTPUT_DIR', "/opt/ml/output/data")) parser.add_argument('--train_dir', type=str, default=os.environ.get('SM_CHANNEL_TRAIN', "/opt/ml/input/data/train")) parser.add_argument('--train_file_format', type=str, default=os.environ.get('FILE_FORMAT', "csv")) ``` + 모델 코드에 사용할 공동 작업자의 스키마를 기반으로 합성 또는 테스트 데이터 세트를 생성할 수 있는지 확인합니다. + 모델 알고리즘 AWS Clean Rooms 을 공동 작업에 연결하기 AWS 계정 전에 SageMaker AI 훈련 작업을 직접 실행할 수 있는지 확인합니다. 다음 코드에는 로컬 테스트, SageMaker AI 훈련 환경 테스트 및 Clean Rooms ML과 호환되는 샘플 Docker 파일이 포함되어 있습니다. ``` FROM 763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.3.0-cpu-py311-ubuntu20.04-sagemaker MAINTAINER $author_name ENV PYTHONDONTWRITEBYTECODE=1 \ PYTHONUNBUFFERED=1 \ LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib" ENV PATH="/opt/ml/code:${PATH}" # this environment variable is used by the SageMaker PyTorch container to determine our user code directory ENV SAGEMAKER_SUBMIT_DIRECTORY /opt/ml/code # copy the training script inside the container COPY train.py /opt/ml/code/train.py # define train.py as the script entry point ENV SAGEMAKER_PROGRAM train.py ENTRYPOINT ["python", "/opt/ml/code/train.py"] ``` + 컨테이너 장애를 가장 잘 모니터링하려면 오류로 인해 로그를 내보내고 디버깅하는 것이 좋습니다. 이에 `GetTrainedModel` 대한 응답으로 Clean Rooms ML은 아래의이 파일에서 처음 1024자를 반환합니다`StatusDetails`. + 모델 변경을 완료하고 SageMaker AI 환경에서 테스트할 준비가 되면 제공된 순서대로 다음 명령을 실행합니다. ``` export ACCOUNT_ID=xxx export REPO_NAME=xxx export REPO_TAG=xxx export REGION=xxx docker build -t $ACCOUNT_ID.dkr.ecr.us-west-2.amazonaws.com/$REPO_NAME:$REPO_TAG # Sign into AWS $ACCOUNT_ID/ Run aws configure # Check the account and make sure it is the correct role/credentials aws sts get-caller-identity aws ecr create-repository --repository-name $REPO_NAME --region $REGION aws ecr describe-repositories --repository-name $REPO_NAME --region $REGION # Authenticate Doker aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com # Push To ECR Images docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com$REPO_NAME:$REPO_TAG # Create Sagemaker Training job # Configure the training_job.json with # 1. TrainingImage # 2. Input DataConfig # 3. Output DataConfig aws sagemaker create-training-job --cli-input-json file://training_job.json --region $REGION ``` SageMaker AI 작업이 완료되고 모델 알고리즘에 만족하면 AWS Clean Rooms ML에 Amazon ECR 레지스트리를 등록할 수 있습니다. `CreateConfiguredModelAlgorithm` 작업을 사용하여 모델 알고리즘을 등록하고 `CreateConfiguredModelAlgorithmAssociation`를 사용하여 이를 공동 작업에 연결합니다. # 추론 컨테이너에 대한 모델 작성 지침 이 섹션에서는 Clean Rooms ML에 대한 추론 알고리즘을 생성할 때 모델 공급자가 따라야 하는 지침을 자세히 설명합니다. + SageMaker AI [개발자 안내서에 설명된 대로 적절한 SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg-ecr-paths/sagemaker-algo-docker-registry-paths.html) 추론 지원 컨테이너 기본 이미지를 사용합니다. 다음 코드를 사용하면 퍼블릭 SageMaker AI 엔드포인트에서 지원되는 컨테이너 기본 이미지를 가져올 수 있습니다. ``` ecr_registry_endpoint='763104351884.dkr.ecr.$REGION.amazonaws.com' base_image='pytorch-inference:2.3.0-cpu-py311-ubuntu20.04-sagemaker' aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ecr_registry_endpoint docker pull $ecr_registry_endpoint/$base_image ``` + 모델을 로컬에서 작성할 때 개발 인스턴스,의 SageMaker AI 배치 변환 AWS 계정및 Clean Rooms ML에서 로컬에서 모델을 테스트할 수 있도록 다음을 확인하세요. + Clean Rooms ML을 사용하면 추론의 모델 아티팩트를 Docker 컨테이너의 `/opt/ml/model` 디렉터리를 통해 추론 코드에서 사용할 수 있습니다. + Clean Rooms ML은 입력을 줄별로 분할하고 배치 `MultiRecord` 전략을 사용하며 변환된 모든 레코드의 끝에 줄 바꿈 문자를 추가합니다. + 모델 코드에 사용할 공동 작업자의 스키마를 기반으로 합성 또는 테스트 추론 데이터 세트를 생성할 수 있는지 확인합니다. + 모델 알고리즘을 공동 작업과 AWS Clean Rooms 연결하기 AWS 계정 전에 SageMaker AI 배치 변환 작업을 직접 실행할 수 있는지 확인합니다. 다음 코드에는 로컬 테스트, SageMaker AI 변환 환경 테스트 및 Clean Rooms ML과 호환되는 샘플 Docker 파일이 포함되어 있습니다. ``` FROM 763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:1.12.1-cpu-py38-ubuntu20.04-sagemaker ENV PYTHONUNBUFFERED=1 COPY serve.py /opt/ml/code/serve.py COPY inference_handler.py /opt/ml/code/inference_handler.py COPY handler_service.py /opt/ml/code/handler_service.py COPY model.py /opt/ml/code/model.py RUN chmod +x /opt/ml/code/serve.py ENTRYPOINT ["/opt/ml/code/serve.py"] ``` + 모델 변경을 완료하고 SageMaker AI 환경에서 테스트할 준비가 되면 제공된 순서대로 다음 명령을 실행합니다. ``` export ACCOUNT_ID=xxx export REPO_NAME=xxx export REPO_TAG=xxx export REGION=xxx docker build -t $ACCOUNT_ID.dkr.ecr.us-west-2.amazonaws.com/$REPO_NAME:$REPO_TAG # Sign into AWS $ACCOUNT_ID/ Run aws configure # Check the account and make sure it is the correct role/credentials aws sts get-caller-identity aws ecr create-repository --repository-name $REPO_NAME --region $REGION aws ecr describe-repositories --repository-name $REPO_NAME --region $REGION # Authenticate Docker aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com # Push To ECR Repository docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com$REPO_NAME:$REPO_TAG # Create Sagemaker Model # Configure the create_model.json with # 1. Primary container - # a. ModelDataUrl - S3 Uri of the model.tar from your training job aws sagemaker create-model --cli-input-json file://create_model.json --region $REGION # Create Sagemaker Transform Job # Configure the transform_job.json with # 1. Model created in the step above # 2. MultiRecord batch strategy # 3. Line SplitType for TransformInput # 4. AssembleWith Line for TransformOutput aws sagemaker create-transform-job --cli-input-json file://transform_job.json --region $REGION ``` SageMaker AI 작업이 완료되고 배치 변환에 만족하면 AWS Clean Rooms ML에 Amazon ECR 레지스트리를 등록할 수 있습니다. `CreateConfiguredModelAlgorithm` 작업을 사용하여 모델 알고리즘을 등록하고 `CreateConfiguredModelAlgorithmAssociation`를 사용하여 이를 공동 작업에 연결합니다. # 모델 로그 및 지표 수신 사용자 지정 모델 훈련 또는 추론에서 로그와 지표를 수신하려면 멤버가 필요한 CloudWatch 권한을 제공하는 유효한 역할로 [ML 구성을 생성](https://docs.aws.amazon.com/clean-rooms/latest/userguide/create-custom-ml-collaboration.html)해야 합니다(사용자 [지정 ML 모델링을 위한 서비스 역할 생성 - ML 구성](https://docs.aws.amazon.com/clean-rooms/latest/userguide/ml-roles.html#ml-roles-custom-configure) 참조). **시스템 지표** CPU 및 메모리 사용률과 같은 훈련 및 추론 모두에 대한 시스템 지표는 유효한 ML 구성을 사용하여 공동 작업의 모든 구성원에게 게시됩니다. 이러한 지표는 각각 `/aws/cleanroomsml/TrainedModels` 또는 `/aws/cleanroomsml/TrainedModelInferenceJobs` 네임스페이스의 CloudWatch 지표를 통해 작업이 진행됨에 따라 볼 수 있습니다. **모델 로그** 모델 로그에 대한 액세스는 구성된 각 모델 알고리즘의 개인 정보 보호 구성 정책에 의해 제공됩니다. 모델 작성자는 구성된 모델 알고리즘(콘솔 또는 `CreateConfiguredModelAlgorithmAssociation` API를 통해)을 공동 작업에 연결할 때 개인 정보 보호 구성 정책을 설정합니다. 개인 정보 보호 구성 정책을 설정하면 모델 로그를 수신할 수 있는 멤버가 제어됩니다. 또한 모델 작성자는 개인 정보 보호 구성 정책에서 필터 패턴을 설정하여 로그 이벤트를 필터링할 수 있습니다. 모델 컨테이너가 `stdout` 또는 로 보내고 필터 패턴(설정된 경우)`stderr`과 일치하는 모든 로그는 Amazon CloudWatch Logs로 전송됩니다. 모델 로그는 `/aws/cleanroomsml/TrainedModelInferenceJobs`각각 CloudWatch 로그 그룹 `/aws/cleanroomsml/TrainedModels` 또는에서 사용할 수 있습니다. **사용자 정의 지표** 모델 알고리즘을 구성할 때(콘솔 또는 `CreateConfiguredModelAlgorithm` API를 통해) 모델 작성자는 출력 로그에서 검색할 특정 지표 이름과 정규식 문을 제공할 수 있습니다. 이는 `/aws/cleanroomsml/TrainedModels` 네임스페이스의 CloudWatch 지표를 통해 작업이 진행됨에 따라 볼 수 있습니다. 구성된 모델 알고리즘을 연결할 때 모델 작성자는 지표 프라이버시 구성에서 선택적 노이즈 수준을 설정하여 사용자 지정 지표 추세에 대한 가시성을 제공하면서 원시 데이터를 출력하지 않도록 할 수 있습니다. 노이즈 수준이 설정된 경우 지표는 실시간으로가 아닌 작업 종료 시 게시됩니다. # Clean Rooms에 대한 암호화 컴퓨팅 Clean Rooms (C3R)에 대한 암호화 컴퓨팅은 [분석 규칙](analysis-rules.md) 외에도 사용할 수 AWS Clean Rooms 있는의 기능입니다. C3R을 사용하면 조직은 민감한 데이터를 한데 모아 데이터 분석을 통해 새로운 통찰력을 도출하는 동시에 프로세스에서 모든 당사자가 학습할 수 있는 내용을 암호학적으로 제한할 수 있습니다. 민감한 데이터로 공동 작업하고 싶지만 클라우드에서는 암호화된 데이터만 사용해야 하는 두 명 이상의 당사자가 C3R을 사용할 수 있습니다. C3R 암호화 클라이언트는 사용할 데이터를 암호화하는 데 사용할 수 있는 클라이언트 측 [암호화](glossary.md#glossary-encryption) 도구입니다 AWS Clean Rooms. C3R 암호화 클라이언트를 사용하는 경우 데이터는 AWS Clean Rooms 공동 작업에 사용되는 동안 암호화 방식으로 보호됩니다. 정기적인 AWS Clean Rooms 공동 작업과 마찬가지로 입력 데이터는 관계형 데이터베이스 테이블이며 계산은 SQL 쿼리로 표현됩니다. 하지만 C3R은 암호화된 데이터에 대한 제한된 SQL 쿼리 하위 집합만 지원합니다. 특히 C3R은 암호로 보호된 데이터에 대한 SQL JOIN 및 SELECT 명령문을 지원합니다. 입력 테이블의 각 열은 다음 SQL 문 유형 중 정확히 하나로 사용할 수 있습니다. + JOIN 명령문에 사용할 수 있도록 암호로 보호되는 열을 **fingerprint 열**이라고 합니다. + SELECT명령문에 사용할 수 있도록 암호로 보호되는 열을 **sealed 열**이라고 합니다. + JOIN 또는 SELECT 문에서 사용할 수 있도록 암호로 보호되지 않은 열을 **cleartext 열**이라고 합니다. 경우에 따라 fingerprint 열에서 GROUP BY 명령문이 지원됩니다. 자세한 내용은 [Fingerprint 열](crypto-computing-column-types.md#fingerprint-columns) 단원을 참조하십시오. 현재 C3R은 관련 분석 규칙에서 허용하는 경우라도 암호화된 데이터에 WHERE 절이나 SUM, AVERAGE와(과) 같은 집계 함수 같은 다른 SQL 구성을 사용하는 것을 지원하지 않습니다. C3R은 테이블의 개별 셀에 있는 데이터를 보호하도록 설계되었습니다. C3R의 기본 구성을 사용하면 고객이 공동 작업을 통해 제3자에게 제공하는 기본 데이터는 콘텐츠를 AWS Clean Rooms내에서 사용하는 동안 암호화된 상태로 유지됩니다. C3R은 모든 sealed 열에 업계 표준 AES-GCM 암호화를 사용하고 fingerprint 열 보호를 위해 해시 기반 메시지 인증 코드(HMAC)로 알려진 업계 표준 의사 랜덤 함수를 사용합니다. C3R은 테이블의 데이터를 암호화하지만 다음 정보는 여전히 유추할 수 있습니다. + 테이블의 열 수, 열 이름, 행 수 등 테이블 자체에 대한 정보. + 대부분의 표준 암호화 형식과 마찬가지로 C3R은 암호화된 값의 길이를 숨기려고 하지 않습니다. C3R은 암호화된 값을 패딩하여 일반 텍스트의 정확한 길이를 숨길 수 있는 기능을 제공합니다. 그러나 각 열의 일반 텍스트 길이의 상한선이 여전히 다른 당사자에게 공개될 수 있습니다. + 로깅 수준 정보(예: 암호화된 C3R 테이블에 특정 행이 추가된 시점). C3R에 대한 자세한 내용은 다음 주제를 참조하세요. **Topics** + [Clean Rooms에 대한 암호화 컴퓨팅 사용 시 고려 사항](crypto-computing-considerations.md) + [Clean Rooms용 암호화 컴퓨팅에서 지원되는 파일 및 데이터 유형](crypto-computing-file-types.md) + [Clean Rooms에 대한 암호화 컴퓨팅의 열 이름](crypto-computing-column-names.md) + [Clean Rooms용 암호화 컴퓨팅의 열 유형](crypto-computing-column-types.md) + [암호화 컴퓨팅 파라미터](crypto-computing-parameters.md) + [Clean Rooms용 암호화 컴퓨팅의 선택적 플래그](crypto-computing-optional-flags.md) + [Clean Rooms에 대한 암호화 컴퓨팅을 사용한 쿼리](crypto-computing-queries.md) + [C3R 암호화 클라이언트에 대한 지침](crypto-computing-guidelines.md) # Clean Rooms에 대한 암호화 컴퓨팅 사용 시 고려 사항 Clean Rooms에 대한 암호화 컴퓨팅(C3R)은 데이터 보호를 극대화하기 위한 것입니다. 그러나 일부 사용 사례에서는 추가 기능을 제공하는 대신 낮은 수준의 데이터 보호를 통해 혜택을 받을 수 있습니다. 가장 안전한 구성에서 C3R을 수정하여 이러한 특정 절충안을 만들 수 있습니다. 고객은 이러한 장단점을 인지하고 사용 사례에 적합한지 판단해야 합니다. 고려해야 할 중요한 요소는 다음과 같습니다. **Topics** + [테이블에 혼합 cleartext 및 암호화된 데이터 허용](#allow-mixed-plaintext-and-encrypted-data) + [fingerprint 열에 반복되는 값 허용](#allow-repeated-values) + [fingerprint 열 이름 지정 방법에 대한 제한 완화](#loose-restrictions-on-join-column-names) + [NULL 값 표현 방식 결정](#determine-null-values) 이들 파라미터를 설정하는 방법에 대한 자세한 내용은 [암호화 컴퓨팅 파라미터](crypto-computing-parameters.md) 섹션을 참조하세요. ## 테이블에 혼합 cleartext 및 암호화된 데이터 허용 모든 데이터를 클라이언트 측에서 암호화하면 데이터 보호를 극대화할 수 있습니다. 하지만 이렇게 하면 특정 종류의 쿼리(예: SUM 집계 함수)가 제한됩니다. cleartext 데이터를 허용할 경우 암호화된 테이블에 액세스할 수 있는 모든 사용자가 암호화된 값에 대한 일부 정보를 유추할 수 있다는 위험이 있습니다. 이는 cleartext 및 관련 데이터에 대한 통계 분석을 수행하여 수행할 수 있습니다. 예를 들어, `City` 및 `State`의 열이 있다고 가정해 보겠습니다. `City` 열은 cleartext이고 `State` 열은 암호화되어 있습니다. `City` 열에 `Chicago`라는 값이 표시되면 `State`가 `Illinois`일 확률이 높다는 것을 알 수 있습니다. 반대로, 한 열이 `City`이고 다른 열이 `EmailAddress`인 경우 cleartext `City`는 암호화된 `EmailAddress`에 대해 아무 것도 드러내지 않을 것입니다. 이 창의 파라미터에 대한 자세한 내용은 [cleartext 열 허용 매개 변수](crypto-computing-parameters.md#parameter-allowcleartext) 섹션을 참조하세요. ## fingerprint 열에 반복되는 값 허용 가장 안전한 접근 방식을 위해 모든 fingerprint 열에 정확히 하나의 변수 인스턴스가 포함되어 있다고 가정합니다. 하나의 fingerprint 열에서 어떤 항목도 반복할 수 없습니다. C3R 암호화 클라이언트는 이러한 cleartext 값을 임의 값과 구별할 수 없는 고유한 값으로 매핑합니다. 따라서 이러한 임의 값으로는 cleartext에 대한 정보를 유추할 수 없습니다. 하나의 fingerprint 열에 값이 반복되면 값이 반복되어 무작위로 보이는 값이 반복될 위험이 있습니다. 따라서 암호화된 테이블에 액세스할 수 있는 사람은 이론적으로 fingerprint 열에 대한 통계 분석을 수행하여 cleartext 값에 대한 정보를 확인할 수 있습니다. 다시 말하지만, fingerprint 열이 `State`이고 테이블의 모든 행이 미국 가정에 해당한다고 가정해 보겠습니다. 빈도 분석을 수행하면 어떤 상태가 `California`이고 어떤 상태가 `Wyoming`인지 높은 확률로 추론할 수 있습니다. 이러한 추론이 가능한 이유는 `California`의 거주자 수가 `Wyoming`보다 많기 때문입니다. 반대로, fingerprint 열이 세대 식별자에 관한 것이고 수백만 개의 항목이 있는 데이터베이스에서 각 가구가 데이터베이스에 1\$14번 나타났다고 가정해 보겠습니다. 빈도 분석을 통해 유용한 정보가 나올 가능성은 거의 없습니다. 이 시나리오의 파라미터에 대한 자세한 내용은 [중복 매개 변수 허용](crypto-computing-parameters.md#parameter-allowduplicates) 섹션을 참조하세요. ## fingerprint 열 이름 지정 방법에 대한 제한 완화 기본적으로 암호화된 fingerprint 열을 사용하여 두 테이블을 조인하면 각 테이블에서 해당 열의 이름이 같다고 가정합니다. 이 결과가 나오는 기술적인 이유는 기본적으로 각 fingerprint 열을 암호화하기 위해 서로 다른 암호화 키를 생성하기 때문입니다. 이 키는 공동 작업을 위한 공유 비밀 키와 열 이름의 조합에서 파생됩니다. 열 이름이 다른 두 열을 조인하려고 하면 다른 키가 파생되고 유효한 조인을 계산할 수 없습니다. 이 문제를 해결하려면 각 열 이름에서 키를 추출하는 기능을 끌 수 있습니다. 그러면 C3R 암호화 클라이언트는 모든 fingerprint 열에 단일 파생 키를 사용합니다. 위험은 정보를 드러낼 수 있는 또 다른 종류의 주파수 분석을 수행할 수 있다는 것입니다. `City`와 `State` 예제를 다시 사용해봅시다. 열 이름을 포함하지 않고 각 fingerprint 열에 대해 동일한 임의 값을 도출하는 경우 `New York`은 `City`및 `State` 열에 동일한 임의 값을 갖습니다. 뉴욕은 미국에서 `City` 이름과 같은 `State` 이름을 가진 몇 안 되는 도시 중 하나입니다. 반대로 데이터 세트의 각 열에 있는 값이 완전히 다른 경우에는 정보가 유출되지 않습니다. 이 시나리오의 파라미터에 대한 자세한 내용은 [이름이 다른 열의 JOIN 허용 매개변수](crypto-computing-parameters.md#parameter-allowjoin) 섹션을 참조하세요. ## NULL 값 표현 방식 결정 사용할 수 있는 옵션은 다른 값과 마찬가지로 NULL 값을 암호화(암호화 및 HMAC)로 처리할지 여부입니다. 다른 값처럼 NULL 값을 처리하지 않으면 정보가 노출될 수 있습니다. 예를 들어, cleartext의 `Middle Name` 열에 있는 NULL이 중간 이름이 없는 사람을 나타낸다고 가정해 보겠습니다. 이러한 값을 암호화하지 않으면 암호화된 테이블에서 중간 이름이 없는 사람들이 사용한 행이 유출됩니다. 이 정보는 일부 집단의 일부 사람들을 식별하는 신호가 될 수 있습니다. 그러나 NULL 값을 암호적으로 처리하는 경우 특정 SQL 쿼리는 다르게 작동합니다. 예를 들어 GROUP BY 절은 fingerprint 열의 fingerprint NULL 값을 함께 그룹화하지 않습니다. 이 시나리오의 파라미터에 대한 자세한 내용은 [NULL 값 보존(매개변수)](crypto-computing-parameters.md#parameter-preservenulls) 섹션을 참조하세요. # Clean Rooms용 암호화 컴퓨팅에서 지원되는 파일 및 데이터 유형 C3R 암호화 클라이언트는 다음 파일 유형을 인식합니다. + CSV 파일 + Parquet files C3R 암호화 클라이언트의 `--fileFormat` 플래그를 사용하여 파일 형식을 명시적으로 지정할 수 있습니다. 명시적으로 지정한 경우 파일 형식은 파일 확장자에 의해 결정되지 않습니다. **Topics** + [CSV 파일](#csv-file-type) + [Parquet files](#parquet-file-type) + [문자열이 아닌 값 암호화](#encrypt-non-string-values) ## CSV 파일 확장명이.csv인 파일은 CSV 형식이고 UTF-8 인코딩 텍스트를 포함하는 것으로 간주됩니다. C3R 암호화 클라이언트는 모든 값을 문자열로 취급합니다. ### .csv 파일에서 지원되는 속성 C3R 암호화 클라이언트를 사용하려면 .csv 파일에 다음과 같은 속성이 있어야 합니다. + 각 열의 이름을 고유하게 지정하는 초기 헤더 행을 포함할 수도 있고 포함하지 않을 수도 있습니다. + 쉼표로 구분. (현재 사용자 지정 구분 기호는 지원되지 않습니다.) + UTF-8 인코딩 텍스트. #### .csv 항목에서 스페이스 제거 선행 공백과 후행 스페이스 모두.csv 항목에서 제거됩니다. #### .csv 파일의 사용자 지정 NULL 인코딩 .csv 파일은 사용자 지정 NULL 인코딩을 사용할 수 있습니다. C3R 암호화 클라이언트에서는 `--csvInputNULLValue=` 플래그를 사용하여 입력 데이터의 NULL 항목에 대한 사용자 지정 인코딩을 지정할 수 있습니다. C3R 암호화 클라이언트는 `--csvOutputNULLValue=` 플래그를 사용하여 NULL 항목에 대해 생성된 출력 파일에서 사용자 지정 인코딩을 사용할 수 있습니다. **참고** NULL 항목은 내용이 부족한 것으로 간주됩니다. 특히 SQL 테이블과 같은 풍부한 테이블 형식의 컨텍스트에서는 더욱 그렇습니다.** .csv는 역사적 이유로 이 특성화를 명시적으로 지원하지 않지만, 스페이스만 포함된 빈 항목은 NULL로 간주하는 것이 일반적인 관례입니다 따라서 이는 C3R 암호화 클라이언트의 기본 동작이며 필요에 따라 사용자 지정할 수 있습니다. ### C3R에서.csv 항목을 해석하는 방법 다음 표는 `--csvInputNULLValue=` 및 `--csvOutputNULLValue=` 플래그에 제공된 값(있는 경우)에 따라 .csv 항목이 어떻게 마샬링되는지(명확성을 위해 cleartext에서 cleartext로 보여주는 예입니다. 따옴표 밖의 선행 및 후행 스페이스는 C3R이 값의 의미를 해석하기 전에 잘립니다. | `` | `` | 항목 | 출력 항목 | | --- |--- |--- |--- | | None | None | , 모든 제품, | , 모든 제품, | | None | None | , 모든 제품, | , 모든 제품, | | None | None | ,"모든 제품", | , 모든 제품, | | None | None | , "모든 제품" , | , 모든 제품, | | None | None | ,, | ,, | | None | None | , , | ,, | | None | None | ,"", | ,, | | None | None | ," ", | ," ", | | None | None | , " " , | ," ", | | "모든 제품" | "NULL" | , 모든 제품, | ,NULL, | | "모든 제품" | "NULL" | , 모든 제품, | ,NULL, | | "모든 제품" | "NULL" | ,"모든 제품", | ,NULL, | | "모든 제품" | "NULL" | , "모든 제품" , | ,NULL, | | None | "NULL" | ,, | ,NULL, | | None | "NULL" | , , | ,NULL, | | None | "NULL" | ,"", | ,NULL, | | None | "NULL" | ," ", | ," ", | | None | "NULL" | , " " , | ," ", | | "" | "NULL" | ,, | ,NULL, | | "" | "NULL" | , , | ,NULL, | | "" | "NULL" | ,"", | ,"", | | "" | "NULL" | ," ", | ," ", | | "" | "NULL" | , " " , | ," ", | | "\$1"\$1"" | "NULL" | ,, | ,, | | "\$1"\$1"" | "NULL" | , , | ,, | | "\$1"\$1"" | "NULL" | ,"", | ,NULL, | | "\$1"\$1"" | "NULL" | ," ", | ," ", | | "\$1"\$1"" | "NULL" | , " " , | ," ", | ### 헤더가 없는 CSV 파일 소스.csv 파일의 첫 번째 행에는 각 열의 이름을 고유하게 지정하는 헤더가 없어도 됩니다. 하지만 헤더 행이 없는.csv 파일에는 위치 암호화 스키마가 필요합니다. 헤더 행이 있는.csv 파일과 Parquet 파일 모두에 사용되는 일반적인 매핑 스키마 대신 위치 암호화 스키마가 필요합니다. 위치 암호화 스키마는 이름 대신 위치를 기준으로 출력 열을 지정합니다. 매핑된 암호화 스키마는 원본 열 이름을 대상 열 이름에 매핑합니다. 두 스키마 형식에 대한 자세한 설명과 예를 포함한 자세한 내용은 [매핑된 테이블 스키마와 위치 테이블 스키마](create-schema.md#mapped-and-positional-schemas)을 참조하세요. ## Parquet files .parquet 확장자가 있는 파일은 Apache Parquet와 같은 형식으로 간주됩니다. ### 지원되는 Parquet 데이터 형식 C3R 암호화 클라이언트는 AWS Clean Rooms에서 지원하는 데이터 유형을 나타내는 Parquet 파일에서 복잡하지 않은 데이터(즉, 기본 유형)를 모두 처리할 수 있습니다. 하지만 sealed 열에는 문자열 열만 사용할 수 있습니다. 지원되는 Parquet 데이터 유형은 다음과 같습니다: + 다음과 같은 논리적 주석이 포함된 `Binary` 기본 유형: + `--parquetBinaryAsString`이 설정된 경우, 없음(`STRING`데이터 유형) + `Decimal(scale, precision)`(`DECIMAL` 데이터 유형) + `String`(`STRING` 데이터 유형) + 논리적 주석이 없는 `Boolean` 기본 데이터 유형(`BOOLEAN` 데이터 유형) + 논리적 주석이 없는 `Double` 기본 데이터 유형(`DOUBLE` 데이터 유형) + `Decimal(scale, precision)` 논리적 주석이 있는 `Fixed_Len_Binary_Array` 기본 유형(`DECIMAL` 데이터 유형) + 논리적 주석이 없는 `Float` 기본 데이터 유형(`FLOAT` 데이터 유형) + 다음과 같은 논리적 주석이 포함된 `Int32` 기본 유형: + 없음(`INT` 데이터 유형) + `Date`(`DATE` 데이터 유형) + `Decimal(scale, precision)`(`DECIMAL` 데이터 유형) + `Int(16, true)`(`SMALLINT` 데이터 유형) + `Int(32, true)`(`INT` 데이터 유형) + 다음과 같은 논리적 주석이 포함된 `Int64` 기본 데이터 유형: + 없음(`BIGINT` 데이터 유형) + `Decimal(scale, precision)`(`DECIMAL` 데이터 유형) + `Int(64, true)`(`BIGINT` 데이터 유형) + `Timestamp(isUTCAdjusted, TimeUnit.MILLIS)`(`TIMESTAMP` 데이터 유형) + `Timestamp(isUTCAdjusted, TimeUnit.MICROS)`(`TIMESTAMP` 데이터 유형) + `Timestamp(isUTCAdjusted, TimeUnit.NANOS)`(`TIMESTAMP` 데이터 유형) ## 문자열이 아닌 값 암호화 현재 sealed 열에는 문자열 값만 지원됩니다. .csv 파일의 경우 C3R 암호화 클라이언트는 모든 값을 UTF-8 인코딩 텍스트로 취급하며 암호화 전에 이러한 값을 다르게 해석하려고 시도하지 않습니다. 핑거프린트 열의 경우 유형은 동등한 클래스로 그룹화됩니다. 등가 클래스는 대표적인 데이터 유형을 통해 동등성을 명확하게 비교할 수 있는 데이터 유형 집합입니다. 등가 클래스를 사용하면 원래 표현과 관계없이 동일한 지문을 동일한 시맨틱 값에 할당할 수 있습니다. 하지만 두 등가 클래스의 값이 같더라도 핑거프린트 열이 같아지지는 않습니다. 예를 들어, `INTEGRAL` 값 `42`는 원래 `SMALLINT`, `INT`, 또는 `BIGINT`였는지 여부에 관계없이 동일한 지문을 할당받게 됩니다. 또한 `INTEGRAL` 값 `0`은 `BOOLEAN` 값 `FALSE` (값 `0`으로 표시됨)와 절대 일치하지 않습니다. 지문 열에서 지원되는 등가 클래스 및 해당 AWS Clean Rooms 데이터 형식은 다음과 같습니다. | 등가 클래스 | 지원되는 AWS Clean Rooms 데이터 형식 | | --- | --- | | BOOLEAN | BOOLEAN | | DATE | DATE | | INTEGRAL | BIGINT, INT, SMALLINT | | STRING | CHAR, STRING, VARCHAR | # Clean Rooms에 대한 암호화 컴퓨팅의 열 이름 Clean Rooms에 대한 암호화 컴퓨팅의 경우 기본적으로 열 이름이 중요합니다. **이름이 다른 열 JOIN 허용** 매개 변수의 값이 **거짓**인 경우 열 암호화 시 fingerprint 열 이름이 사용됩니다. 따라서 기본적으로 협업자는 사전에 조율하여 쿼리에서 JOIN 문을 사용할 데이터에 대해 동일한 대상 열 이름을 사용해야 합니다. 기본적으로 열을 다른 JOIN 이름으로 암호화하면 어떤 값에서도 제대로 JOIN하지 않습니다. **이름이 다른 열의 JOIN 허용** 매개 변수의 값이 **참**인 경우 fingerprint 열로 암호화된 열 전체에서 JOIN 명령문이 성공합니다. 이 매개 변수로 데이터를 암호화하면 cleartext 값을 어느 정도 추론할 수 있습니다. 예를 들어 행의 `City` 열과 `State` 열 모두에 동일한 해시 기반 메시지 인증 코드(HMAC)값이 있는 경우 값은 `New York`과 같을 수 있습니다. ## 열 헤더 이름의 정규화 열 헤더 이름은 C3R 암호화 클라이언트에 의해 정규화됩니다. 변환된 출력에서는 선행 및 후행 스페이스가 모두 제거되고 열 이름은 소문자로 바뀝니다. 정규화는 열 이름의 영향을 받을 수 있는 다른 모든 계산, 연산 또는 기타 작업보다 먼저 적용됩니다. 내보낸 출력 파일에는 정규화된 이름만 포함됩니다. # Clean Rooms용 암호화 컴퓨팅의 열 유형 이 항목에서는 Clean Rooms용 암호화 컴퓨팅의 열 유형에 대한 정보를 제공합니다. **Topics** + [Fingerprint 열](#fingerprint-columns) + [밀폐형 열](#sealed-columns) + [Cleartext 열](#cleartext-columns) ## Fingerprint 열 Fingerprint 열은 JOIN 명령문에 사용할 수 있도록 암호로 보호되는 열입니다.** fingerprint 열의 데이터는 해독할 수 없습니다. 봉인된 열의 데이터만 해독할 수 있습니다. Fingerprint 열은 다음 SQL 절 및 함수에서만 사용해야 합니다. + JOIN (INNER, OUTER, LEFT, RIGHT, or FULL)을 다른 fingerprint 열과 대조합니다. + `allowJoinsOnColumnsWithDifferentNames` 매개 변수 값이 `false`로 설정된 경우 JOIN의 두 fingerprint 열 모두 이름이 같아야 합니다. + `SELECT COUNT()` + `SELECT COUNT(DISTINCT )` + `GROUP BY`(공동 작업에서 `preserveNulls` 파라미터 값을 `true`(으)로 설정한 경우에만 사용) 이러한 제약조건을 위반하는 쿼리는 잘못된 결과를 초래할 수 있습니다. ## 밀폐형 열 *봉인된 열*은 SELECT 명령문에 사용할 수 있도록 암호로 보호되는 열입니다. 봉인된 열은 다음 SQL 절 및 함수에서만 사용해야 합니다. + `SELECT` + `SELECT ... AS` + `SELECT COUNT()` **참고** `SELECT COUNT(DISTINCT )`는 지원되지 않습니다. 이러한 제약 조건을 위반하는 쿼리는 잘못된 결과를 초래할 수 있습니다. ### 암호화 전에 sealed 열의 데이터 패딩 하나의 열을 sealed 열로 지정하면 C3R은 어떤 종류의 패딩을 선택할지 묻습니다.** 암호화 전에 데이터 패딩은 선택 사항입니다. 패딩이 없는 경우(패드 유형`none`), 암호화된 데이터의 길이는 cleartext의 크기를 나타냅니다. 경우에 따라 cleartext의 크기로 인해 일반 텍스트가 노출될 수 있습니다. 패딩(패드 유형이 `fixed` 또는`max`인 경우)을 사용하면 모든 값이 먼저 공통 크기로 채워진 다음 암호화됩니다. 패딩을 사용하면 암호화된 데이터의 길이에 따라 데이터 크기에 상한이 주어지는 것 외에는 원래 cleartext 길이에 대한 정보가 제공되지 않습니다. 열에 패딩을 적용하고 해당 열에 있는 데이터의 최대 바이트 길이를 알고 있는 경우 `fixed` 패딩을 사용합니다. 적어도 `length` 열에 있는 가장 긴 값의 바이트 길이만큼 큰 값을 사용합니다. **참고** 값이 제공된 `length`보다 길면 오류가 발생하고 암호화에 실패합니다. 열에 패딩을 적용하고 해당 열에 있는 데이터의 최대 바이트 길이를 알 수 없는 경우 `max` 패딩을 사용합니다. 이 패딩 모드는 모든 데이터를 가장 긴 값에 추가 `length` 바이트를 더한 길이로 채웁니다. **참고** 데이터를 일괄적으로 암호화하거나 정기적으로 새 데이터로 테이블을 업데이트하는 것이 좋습니다. `max`패딩은 주어진 배치에서 가장 긴 일반 텍스트 항목의 길이 (`length`바이트를 더한 값) 로 항목을 채우게 된다는 점에 유의하세요. 즉, 사이퍼텍스트 길이는 배치마다 다를 수 있습니다. 따라서 열의 최대 바이트 길이를 알고 있는 경우에는 `max` 대신 `fixed`를 사용해야 합니다. ## Cleartext 열 *Cleartext 열*은 JOIN 또는 SELECT 문에서 사용할 때 암호로 보호되지 않는 열입니다. Cleartext 열은 SQL 쿼리의 어느 부분에서나 사용할 수 있습니다. # 암호화 컴퓨팅 파라미터 [공동 작업을 생성](create-collaboration.md)할 때 Clean Rooms(C3R)에 대한 암호화 컴퓨팅을 사용하는 공동 작업에 암호화 컴퓨팅 파라미터를 사용할 수 있습니다. AWS Clean Rooms 콘솔 또는 `CreateCollaboration` API 작업을 사용하여 공동 작업을 생성할 수 있습니다. 콘솔에서 **암호화 컴퓨팅 지원** 옵션을 켠 후 **암호화 컴퓨팅 매개 변수**의 매개 변수 값을 설정할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요. **Topics** + [cleartext 열 허용 매개 변수](#parameter-allowcleartext) + [중복 매개 변수 허용](#parameter-allowduplicates) + [이름이 다른 열의 JOIN 허용 매개변수](#parameter-allowjoin) + [NULL 값 보존(매개변수)](#parameter-preservenulls) ## cleartext 열 허용 매개 변수 콘솔에서 [공동 작업을 생성](create-collaboration.md)할 때 **cleartext 열 허용** 매개변수를 설정하여 암호화된 cleartext 데이터가 포함된 테이블에 데이터를 허용할지 여부를 지정할 수 있습니다. 다음 표에는 **cleartext 열 허용** 매개 변수의 값이 설명되어 있습니다. | 파라미터값 | 설명 | | --- | --- | | 아니요 | 암호화된 테이블에는 Cleartext 열을 사용할 수 없습니다. 모든 데이터는 암호로 보호됩니다. | | 예 | 암호화된 테이블에는 Cleartext 열을 사용할 수 있습니다. Cleartext 열은 암호로 보호되지 않으며 cleartext로 포함됩니다. 행의 cleartext 데이터가 테이블에 있는 다른 데이터에 대해 무엇을 알려줄 수 있는지 내용을 기록해 두어야 합니다. 특정 열에서 SUM 또는 AVG룰 실행하거나 해당 열이 cleartext 안에 있어야 합니다. | `CreateCollaboration` API 작업을 사용하여 `dataEncryptionMetadata` 매개변수의 경우 `allowCleartext`의 값을 `true` 또는 `false`로 설정할 수 있습니다. 이러한 API 작업을 사용하는 방법에 대한 자세한 내용은 [AWS Clean Rooms API 참조](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)를 참조하세요. Cleartext 열은 테이블별 스키마에서 cleartext로 분류된 열에 해당합니다. 이러한 열의 데이터는 암호화되지 않으며 어떤 방식으로든 사용할 수 있습니다. Cleartext 열은 데이터가 민감하지 않거나 암호화된 sealed 열 또는 fingerprint 열에서 허용하는 것보다 더 많은 유연성이 필요한 경우에 유용할 수 있습니다. ## 중복 매개 변수 허용 콘솔에서 [공동 작업을 생성](create-collaboration.md)할 때 **중복 허용** 매개변수를 설정하여 JOIN 쿼리용으로 암호화된 열에 NULL 값이 아닌 중복이 포함될 수 있는지 여부를 지정할 수 있습니다. **중요** **중복 허용**, [**이름이 다른 열의 JOIN 허용**](#parameter-allowjoin)[** 및 NULL 값 보존**](#parameter-preservenulls) 매개 변수는 별개이지만 서로 연관된 효과가 있습니다. 다음 표에는 **중복 허용** 매개 변수의 값이 설명되어 있습니다. | 파라미터값 | 설명 | | --- | --- | | 아니요 | 반복되는 값은 fingerprint 열에 허용되지 않습니다. 단일 fingerprint 열의 모든 값은 고유해야 합니다. | | 예 | 한 fingerprint 열에 반복되는 값을 사용할 수 있습니다. 반복되는 값이 있는 열을 결합해야 하는 경우 이 값을 **예**로 설정하세요. **예**로 설정하면 C3R 테이블 또는 결과의 fingerprint 열 내에 나타나는 빈도 패턴은 cleartext 데이터 구조에 대한 몇 가지 추가 정보를 암시할 수 있습니다. | `CreateCollaboration` API 작업을 사용하여 `dataEncryptionMetadata` 파라미터의 `allowDuplicates` 값을 `true` 또는 `false`로 설정할 수 있습니다. 이러한 API 작업을 사용하는 방법에 대한 자세한 내용은 [AWS Clean Rooms API 참조](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)를 참조하세요. 기본적으로 JOIN 쿼리에 암호화된 데이터를 사용해야 하는 경우 C3R 암호화 클라이언트는 해당 열에 중복 값이 없어야 합니다. 이 요구 사항은 데이터 보호를 강화하기 위한 노력입니다. 이 동작은 데이터에서 반복되는 패턴을 관찰할 수 없도록 하는 데 도움이 될 수 있습니다. 하지만 JOIN 쿼리에서 암호화된 데이터로 작업하고 싶고 값이 중복될 염려가 없는 경우에는 **중복 허용** 매개 변수를 사용하여 이러한 보수적 검사를 비활성화할 수 있습니다. ## 이름이 다른 열의 JOIN 허용 매개변수 콘솔에서 [공동 작업을 생성](create-collaboration.md)할 때 **이름이 다른 열의 JOIN 허용 ** 매개 변수를 설정하여 이름이 다른 열 간의 JOIN 명령문이 지원되는지 여부를 지정할 수 있습니다. 자세한 내용은 [열 헤더 이름의 정규화](crypto-computing-column-names.md#column-header-names-normalization) 섹션을 참조하세요. 다음 표에는 **이름이 다른 열의 JOIN 허용** 매개 변수의 값이 설명되어 있습니다. | 파라미터값 | 설명 | | --- | --- | | 아니요 | 이름이 다른 fingerprint 열의 조인은 지원되지 않습니다. JOIN 명령문은 이름이 같은 열에 대해서만 정확한 결과를 제공합니다. **아니오** 값을 사용하면 정보 보안이 강화되지만 협동 참여자가 열 이름에 대해 사전에 동의해야 합니다. fingerprint 열로 암호화할 때 두 열의 이름이 다르고 **이름이 다른 열 JOIN 허용** 이 **아니오**로 설정된 경우 해당 열에 대한 JOIN 명령문은 결과를 생성하지 않습니다. 이는 암호화 후 값이 두 항목 간에 공유되지 않기 때문입니다. | | 예 | 이름이 다른 fingerprint 열의 조인이 지원됩니다. 유연성을 높이기 위해 사용자는 이 값을 **예**로 설정할 수 있습니다. 이렇게 하면 열 이름에 관계없이 열에 JOIN 명령문을 입력할 수 있습니다. **예**로 설정하면 C3R 암호화 클라이언트는 fingerprint 열을 보호할 때 열의 이름을 고려하지 않습니다. 그 결과, C3R 테이블에서 서로 다른 fingerprint 열의 공통 값을 관찰할 수 있습니다. 예를 들어 행의 `City` 열과 `State` 열 모두에 동일한 암호화된 JOIN 값이 있는 경우 해당 값이 암호화된 `New York` 값이라고 추론하는 것이 합리적일 수 있습니다. | `CreateCollaboration` API 작업을 사용하여 `dataEncryptionMetadata` 매개 변수의 경우, `allowJoinsOnColumnsWithDifferentNames` 값을 `true` 또는 `false`로 설정할 수 있습니다. 이러한 API 작업을 사용하는 방법에 대한 자세한 내용은 [AWS Clean Rooms API 참조](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)를 참조하세요. 기본적으로 fingerprint 열 암호화는 [4단계: 표 형식 파일의 암호화 스키마 생성](gen-encryption-schema-csv.md)에 설정된 해당 열의 `targetHeader`에 영향을 받습니다. 따라서 동일한 cleartext 값이라도 암호화 대상 fingerprint 열마다 암호화된 표현이 서로 다릅니다. 이 매개 변수는 경우에 따라 cleartext 값 추론을 방지하는 데 유용할 수 있습니다. 예를 들어, fingerprint 열 `City`와 `State`에서 동일한 암호화된 값을 확인하면 해당 값이 `New York`라고 합리적으로 추론할 수 있습니다. 하지만 이 매개 변수를 사용하려면 쿼리에서 조인할 모든 열이 공유 이름을 갖도록 사전에 추가 조정이 필요합니다. **이름이 다른 열의 JOIN 허용** 매개 변수를 사용하여 이러한 제한을 완화할 수 있습니다. 매개 변수 값을`Yes`로 설정하면 이름에 관계없이 JOIN에 대해 암호화된 모든 열을 함께 사용할 수 있습니다. ## NULL 값 보존(매개변수) 콘솔에서 [공동 작업을 생성](create-collaboration.md)할 때 **NULL 값 보존** 매개변수를 설정하여 해당 열에 값이 없음을 표시할 수 있습니다. 다음 표에서는 **NULL값 보존** 매개 변수의 값을 설명합니다. | 파라미터값 | 설명 | | --- | --- | | 아니요 | NULL 값은 보존되지 않습니다. NULL 값은 암호화된 테이블에서 NULL처럼 표시되지 않습니다. NULL 값은 C3R 테이블에서 고유한 임의 값으로 나타납니다. | | 예 | NULL 값은 보존됩니다. NULL 값은 암호화된 테이블에서 NULL처럼 표시됩니다. NULL 값의 SQL 시맨틱이 필요한 경우 이 값을 예로 설정할 수 있습니다. 따라서 열의 암호화 여부와 중복 허용의 매개 변수 설정에 관계없이 NULL 항목이 C3R 테이블에서 NULL같이 나타납니다. | `CreateCollaboration` API 작업을 사용하여 `dataEncryptionMetadata` 매개변수의 `preserveNulls` 값을 `true` 또는 `false`로 설정할 수 있습니다. 이러한 API 작업을 사용하는 방법에 대한 자세한 내용은 [AWS Clean Rooms API 참조](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)를 참조하세요. 공동 작업을 위해 **NULL 값 보존** 매개변수를 **아니요**로 설정한 경우: 1. `cleartext` 열의 NULL 항목은 변경되지 않습니다. 1. 암호화된 `fingerprint` 열의 NULL 항목은 내용을 숨기기 위해 임의 값으로 암호화됩니다. 암호화된 열을 cleartext 열의 NULL 항목과 결합해도 해당 항목과 일치하는 NULL 항목이 하나도 생성되지 않습니다. 각각 고유한 무작위 콘텐츠를 받기 때문에 매칭이 이루어지지 않습니다. 1. 암호화된 `sealed` 열의 NULL 항목은 암호화됩니다. 공동 작업에 대해 **NULL값 보존** 매개 변수의 값을 **예**로 설정하면 열의 암호화 여부에 관계없이 모든 열의 NULL 항목이 NULL로 유지됩니다. **NULL값 보존** 매개변수는 NULL과 같이 표현된 정보가 부족한 부분을 공유하려는 데이터 보강과 같은 시나리오에서 유용합니다. **NULL값 보존** 매개변수는 JOIN 또는 GROUP BY로 변환하려는 열에 NULL 값이 있는 경우 fingerprint 또는 HMAC 형식에서도 유용합니다. **중복 허용** 및 값 **NULL보존 값** 매개 변수가 **아니요**로 설정된 경우 한 fingerprint 열에 NULL 항목이 두 개 이상 있으면 오류가 발생하고 암호화가 중지됩니다. 두 매개 변수 중 하나의 값이 **예**로 설정된 경우 해당 오류는 발생하지 않습니다. # Clean Rooms용 암호화 컴퓨팅의 선택적 플래그 다음 섹션에서는 표 형식 파일 사용자 지정 및 테스트를 위해 C3R 암호화 클라이언트를 사용하여 [데이터를 암호화](encrypt-data.md)할 때 설정할 수 있는 선택적 플래그에 대해 설명합니다. **Topics** + [`--csvInputNULLValue` 플래그](#optional-flags-CSVinputNullValue) + [`--csvOutputNULLValue` 플래그](#optional-flags-CSVoutputNullValue) + [`--enableStackTraces` 플래그](#optional-flags-enablestacktraces) + [`--dryRun` 플래그](#optional-flags-dry-run) + [`--tempDir` 플래그](#optional-flags-working-dir) ## `--csvInputNULLValue` 플래그 C3R 암호화 클라이언트를 사용하여 [데이터를 암호화](encrypt-data.md)할 때 `--csvInputNULLValue` 플래그를 사용하여 입력 데이터 NULL 항목의 사용자 지정 인코딩을 지정할 수 있습니다. 다음 표에는 이 플래그의 사용 및 매개변수가 요약되어 있습니다. | 사용법 | 파라미터 | | --- | --- | | 선택 사항. 사용자는 입력 데이터의 NULL 항목에 대해 사용자 지정 인코딩을 지정할 수 있습니다. | 입력 CSV 파일의 사용자 지정 NULL 값 인코딩 | NULL 항목은 특히 SQL 테이블과 같은 풍부한 표 형식의 컨텍스트에서 내용이 부족한 것으로 간주되는 항목입니다. .csv는 역사적 이유로 이 특성화를 명시적으로 지원하지 않지만, 스페이스만 포함된 빈 항목을 NULL로 간주하는 것이 일반적입니다. 따라서 이는 C3R 암호화 클라이언트의 기본 동작이며 필요에 따라 사용자 지정할 수 있습니다. ## `--csvOutputNULLValue` 플래그 C3R 암호화 클라이언트를 사용하여 [데이터를 암호화](encrypt-data.md)할 때 `--csvOutputNULLValue` 플래그를 사용하여 출력 데이터의 NULL 항목에 대한 사용자 지정 인코딩을 지정할 수 있습니다. 다음 표에는 이 플래그의 사용 및 매개변수가 요약되어 있습니다. | 사용법 | 파라미터 | | --- | --- | | 선택 사항. 사용자는 생성된 출력 파일에서 NULL 항목에 대한 사용자 지정 인코딩을 지정할 수 있습니다. | 출력 CSV 파일의 사용자 지정 NULL 값 인코딩 | NULL 항목은 특히 SQL 테이블과 같은 풍부한 표 형식의 컨텍스트에서 내용이 부족한 것으로 간주되는 항목입니다. .csv는 역사적 이유로 이 특성화를 명시적으로 지원하지 않지만, 스페이스만 포함된 빈 항목을 NULL로 간주하는 것이 일반적입니다. 따라서 이는 C3R 암호화 클라이언트의 기본 동작이며 필요에 따라 사용자 지정할 수 있습니다. ## `--enableStackTraces` 플래그 C3R 암호화 클라이언트를 사용하여 [데이터를 암호화](encrypt-data.md)하는 경우 `--enableStackTraces` 플래그를 사용하여 C3R에서 오류가 발생할 경우 오류 보고를 위한 추가 컨텍스트 정보를 제공합니다. AWS 는 오류를 수집하지 않습니다. 오류가 발생하면 스택 트레이스를 사용하여 오류를 직접 해결하거나 스택 트레이스를 지원 에 보내 도움을 받으세요. 다음 표에는 이 플래그의 사용 및 매개변수가 요약되어 있습니다. | 사용법 | 파라미터 | | --- | --- | | 선택 사항. C3R 암호화 클라이언트에서 오류가 발생할 경우 오류 보고를 위한 추가 컨텍스트 정보를 제공하는 데 사용됩니다. | 없음 | ## `--dryRun` 플래그 C3R 암호화 클라이언트 [암호화](encrypt-data.md) 및 [암호 해독](decrypt-data.md) 명령에는 선택 사항인 `--dryRun` 플래그가 포함되어 있습니다. 플래그는 사용자가 제공한 모든 인수를 가져와 유효성과 일관성을 검사합니다. `--dryRun` 플래그를 사용하여 스키마 파일이 유효하고 해당 입력 파일과 일치하는지 확인할 수 있습니다. 다음 표에는 이 플래그의 사용 및 매개변수가 요약되어 있습니다. | 사용법 | 파라미터 | | --- | --- | | 선택 사항. C3R 암호화 클라이언트가 매개변수를 분석하고 파일을 검사하지만 암호화나 암호 해독은 수행하지 않도록 합니다. | 없음 | ## `--tempDir` 플래그 설정에 따라 암호화된 파일이 암호화되지 않은 파일보다 클 수 있으므로 임시 디렉터리를 사용하는 것이 좋습니다. 또한 공동 작업별로 데이터 세트를 암호화해야 제대로 작동할 수 있습니다. C3R을 사용하여 [데이터를 암호화](encrypt-data.md)하는 경우 `--tempDir` 플래그를 사용하여 입력을 처리하는 동안 임시 파일을 생성할 수 있는 위치를 지정합니다. 다음 표에는 이 플래그의 사용 및 매개변수가 요약되어 있습니다. | 사용법 | 파라미터 | | --- | --- | | 사용자는 입력을 처리하는 동안 임시 파일을 생성할 수 있는 위치를 지정할 수 있습니다. | 기본값은 시스템 임시 디렉터리입니다. | # Clean Rooms에 대한 암호화 컴퓨팅을 사용한 쿼리 이 항목에서는 Clean Rooms에 대한 암호화 컴퓨팅을 사용하여 암호화된 데이터 테이블을 사용하는 쿼리 작성에 대한 정보를 제공합니다. **Topics** + [NULL에서 분기된 쿼리](#queries-branch-on-null) + [하나의 소스 열을 여러 대상 열에 매핑](#queries-mapping) + [JOIN 및 SELECT 쿼리 모두에 동일한 데이터 사용](#queries-using-same-data) ## NULL에서 분기된 쿼리 NULL 명령문에 쿼리 브랜치가 있다는 것은 `IF x IS NULL THEN 0 ELSE 1`와 같은 구문을 사용한다는 의미입니다. 쿼리는 항상 cleartext 열의 NULL 명령문에서 분기할 수 있습니다. **NULL 값 보존** 매개 변수(`preserveNulls`)의 값이 `true`로 설정된 경우에만 sealed 열과 fingerprint 열의 NULL 명령문에 대해 쿼리를 분기할 수 있습니다. 이러한 제약조건을 위반하는 쿼리는 잘못된 결과를 초래할 수 있습니다. ## 하나의 소스 열을 여러 대상 열에 매핑 하나의 소스 열을 여러 대상 열에 매핑할 수 있습니다. 예를 들어 하나의 열에 JOIN 및 SELECT 둘다를 모두 매핑하고 싶을 수 있습니다. 자세한 내용은 [JOIN 및 SELECT 쿼리 모두에 동일한 데이터 사용](#queries-using-same-data) 단원을 참조하십시오. ## JOIN 및 SELECT 쿼리 모두에 동일한 데이터 사용 열의 데이터가 민감하지 않은 경우 cleartext 대상 열에 표시되므로 어떤 용도로든 사용할 수 있습니다. 열의 데이터가 민감하고 JOIN 및 SELECT 쿼리 모두에 사용해야 하는 경우 해당 소스 열을 출력 파일의 두 대상 열에 매핑합니다. 한 열은 `type`을 fingerprint 열로 암호화하고, 한 열은 `type`을 봉인된 열로 암호화합니다. C3R 암호화 클라이언트의 대화형 스키마 생성은 헤더 접미사 `_fingerprint` 및 `_sealed`를 제안합니다. 이러한 헤더 접미사는 이러한 열을 빠르게 구분하는 데 유용한 규칙이 될 수 있습니다. # C3R 암호화 클라이언트에 대한 지침 C3R 암호화 클라이언트는 조직이 민감한 데이터를 한데 모아 데이터 분석에서 새로운 인사이트를 도출할 수 있도록 지원하는 도구입니다. 도구는 당사자 및 프로세스 AWS 에서 학습할 수 있는 내용을 암호화 방식으로 제한합니다. 이는 매우 중요하지만, 데이터를 암호화하여 보호하는 과정은 컴퓨팅 및 스토리지 리소스 측면에서 상당한 오버헤드를 유발할 수 있습니다. 따라서 각 설정 사용의 장단점을 이해하고 원하는 암호화 보장을 유지하면서 설정을 최적화하는 방법을 이해하는 것이 중요합니다. 이 항목에서는 C3R 암호화 클라이언트 및 스키마의 다양한 설정이 성능에 미치는 영향을 중점적으로 다룹니다. 모든 C3R 암호화 클라이언트 암호화 설정은 서로 다른 암호화 보장을 제공합니다. 공동 작업 수준 설정은 기본적으로 가장 안전합니다. 공동 작업을 생성하는 동안 추가 기능을 활성화하면 개인정보 보호가 약화되어 빈도 분석과 같은 활동이 사이퍼텍스트에서 수행될 수 있습니다. 이러한 설정이 사용되는 방식 및 그 영향에 대한 자세한 내용은 [Clean Rooms에 대한 암호화 컴퓨팅](crypto-computing.md)을 참조하세요. **Topics** + [열 유형에 대한 성능 영향](#performance-implications) + [예상하지 못한 사이퍼텍스트 크기 증가 문제 해결](#troubleshooting-ciphertext-size) ## 열 유형에 대한 성능 영향 C3R은 세 가지 열 유형(cleartext, fingerprint 및 sealed)을 사용합니다. 각 열 유형은 서로 다른 암호화 보장을 제공하며 용도도 다릅니다. 다음 섹션에서는 열 유형이 성능에 미치는 영향과 각 설정이 성능에 미치는 영향에 대해 설명합니다. **Topics** + [Cleartext 열](#cleartext-columns) + [Fingerprint 열](#guidelines-fingerprint-columns) + [Sealed 열](#guidelines-sealed-columns) ### Cleartext 열 Cleartext 열은 원래 형식에서 변경되지 않으며 어떤 방식으로도 암호화 처리되지 않습니다. 이 열 유형은 구성할 수 없으며 스토리지 또는 컴퓨팅 성능에 영향을 주지 않습니다. ### Fingerprint 열 Fingerprint 열은 여러 테이블의 데이터를 조인하는 데 사용됩니다. 이를 위해서는 결과 사이퍼텍스트 크기가 항상 같아야 합니다. 그러나 이러한 열은 공동 작업 수준 설정의 영향을 받습니다. Fingerprint 열은 입력에 포함된 cleartext 열에 따라 출력 파일 크기에 다양한 정도의 영향을 미칠 수 있습니다. **Topics** + [fingerprint 열의 기본 오버헤드](#fingerprint-columns-base-overhead) + [fingerprint 열에 대한 공동 작업 설정](#fingerprint-columns-collab-settings) + [fingerprint 열의 예제 데이터](#collab-set-sample-data) + [문제 해결 fingerprint 열](#fingerprint-columns-troubleshooting) #### fingerprint 열의 기본 오버헤드 fingerprint 열에 대한 기본 오버헤드가 있습니다. 이 오버헤드는 일정하며 cleartext 바이트 크기를 대체합니다. fingerprint 열의 데이터는 해시 기반 메시지 인증 코드(HMAC) 함수를 통해 암호화 처리되며, HMAC(해시 기반 메시지 인증 코드) 함수는 데이터를 32바이트 메시지 인증 코드(MAC)로 변환합니다. 그런 다음 이 데이터는 base64 인코더를 통해 처리되어 바이트 크기에 약 33% 가 추가됩니다. 데이터가 속하는 열의 유형과 해당 열을 생성한 클라이언트 버전을 지정하는 8바이트 C3R 지정이 앞에 추가됩니다. 최종 결과는 52바이트입니다. 그런 다음 이 결과에 행 수를 곱하여 총 기본 오버헤드를 구합니다 (`preserveNulls`이 참으로 설정된 경우 `null`이 아닌 총 값의 수 사용). 다음 이미지는 * `BASE_OVERHEAD = ` ** `C3R_DESIGNATION + ` ** `(MAC * 1.33)` * 방법을 보여줍니다 ![\[fingerprint 열의 52바이트 기본 오버헤드.\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/images/base-overhead-fingerprint.PNG) fingerprint 열의 출력 사이퍼텍스트은 항상 52바이트입니다. 입력 cleartext 데이터가 평균 52바이트를 초과하는 경우(예: 전체 주소) 스토리지가 크게 감소할 수 있습니다. 입력 cleartext 데이터가 평균 52바이트 미만인 경우(예: 고객 사용 기간) 스토리지가 크게 증가할 수 있습니다. #### fingerprint 열에 대한 공동 작업 설정 ##### `preserveNulls` 설정 공동 작업 수준 설정 `preserveNulls`이(가) `false`(기본값)인 경우, 각 `null` 값은 고유한 임의의 32바이트로 대체되어 `null`이(가) 아닌 것처럼 처리됩니다. 그 결과 이제 각 `null` 값은 52바이트가 되었습니다. 이렇게 하면 이 설정이 `true`이고 `null` 값이 `null`로 전달될 때와 비교하여 매우 희소한 데이터를 포함하는 테이블에 대한 스토리지 요구 사항이 크게 증가할 수 있습니다. 이 설정의 개인정보 보호가 필요하지 않고 데이터 세트 내에 `null` 값을 보관하고 싶다면 공동 작업을 만들 때 `preserveNulls` 설정을 활성화하세요. 공동 작업을 생성한 후에는 `preserveNulls` 설정을 변경할 수 없습니다. #### fingerprint 열의 예제 데이터 다음은 재현할 설정이 있는 fingerprint 열의 입력 및 출력 데이터 세트 예제입니다. `allowCleartext`와(과) `allowDuplicates`같은 다른 공동 작업 수준 설정은 결과에 영향을 주지 않으므로 로컬에서 재현하려는 경우, `true` 또는 `false`(으)로 설정할 수 있습니다. **공유 비밀의 예:** `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` **공동 작업 ID 예시**: `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` **allowJoinsOnColumnsWithDifferentNames**: `True` 이 설정은 성능이나 스토리지 요구 사항에 영향을 주지 않습니다. 하지만 이 설정을 사용하면 다음 표에 표시된 값을 재현할 때 열 이름을 선택할 필요가 없습니다. **예제 1.** | | | | --- |--- | | 입력 | null | | preserveNulls | TRUE | | 출력 | null | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 0 | **예제 2.** | | | | --- |--- | | 입력 | null | | preserveNulls | FALSE | | 출력 | 01:hmac:3lkFjthvV3IUu6mMvFc1a\$1XAHwgw/ElmOq4p3Yg25kk= | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 52 | **예제 3** | | | | --- |--- | | 입력 | empty string | | preserveNulls | - | | 출력 | 01:hmac:oKTgi3Gba\$1eUb3JteSz2EMgXUkF1WgM77UP0Ydw5kPQ= | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 52 | **예 4** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | 출력 | 01:hmac:kU/IqwG7FMmzzshr0B9scomE0UJUEE7j9keTctplGww= | | DETERMINISTIC | Yes | | 입력 바이트 | 26 | | 출력 바이트 | 52 | **예 5** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | 출력 | 01:hmac:ks3htnQbw2vdhCRFF6JNzW5LMndJaHG57uvE26mBtSs= | | DETERMINISTIC | Yes | | 입력 바이트 | 62 | | 출력 바이트 | 52 | #### 문제 해결 fingerprint 열 **fingerprint 열의 사이퍼텍스트 텍스트가 그 안에 들어간 cleartext 열의 크기보다 몇 배나 큰 이유는 무엇인가요?** fingerprint 열의 사이퍼텍스트 길이는 항상 52바이트입니다. 입력 데이터가 작을 경우(예: 고객 연령) 크기가 크게 증가합니다. `preserveNulls` 설정이 `false`(으)로 설정된 경우에도 이런 일이 발생할 수 있습니다. **fingerprint 열의 사이퍼텍스트가 그 안에 들어간 cleartext 열의 크기보다 몇 배나 작은 이유는 무엇인가요?** fingerprint 열의 사이퍼텍스트 길이는 항상 52바이트입니다. 입력 데이터가 큰 경우(예: 고객의 전체 주소) 크기가 크게 줄어듭니다. **`preserveNulls`에서 제공하는 암호화 보증이 필요한지 어떻게 알 수 있나요?** 안타깝게도 답은 상황에 따라 다르다는 것입니다. 최소한 `preserveNulls` 설정이 데이터를 어떻게 보호하는지 [암호화 컴퓨팅 파라미터](crypto-computing-parameters.md)을 검토해야 합니다. 하지만 조직의 데이터 처리 요구 사항 및 각 공동 작업에 적용되는 모든 계약을 참조하는 것이 좋습니다. **base64의 오버헤드가 발생해야 하는 이유는 무엇입니까?** CSV와 같은 표 형식 파일 형식과의 호환성을 허용하려면 base64 인코딩이 필요합니다. Parquet와 같은 일부 파일 형식은 데이터의 바이너리 표현을 지원할 수 있지만 올바른 쿼리 결과를 얻으려면 공동 작업의 모든 참여자가 동일한 방식으로 데이터를 나타내는 것이 중요합니다. ### Sealed 열 Sealed 열은 공동 작업 구성원 간에 데이터를 전송할 때 사용됩니다. 이러한 열의 사이퍼텍스트는 결정적이지 않으며 열 구성 방식에 따라 성능과 스토리지 모두에 상당한 영향을 미칩니다. 이러한 열은 개별적으로 구성할 수 있으며 대개 C3R 암호화 클라이언트의 성능과 결과 출력 파일 크기에 가장 큰 영향을 미칩니다. **Topics** + [sealed 열의 기본 오버헤드](#sealed-columns-base-overhead) + [sealed 열에 대한 공동 작업 설정](#sealed-columns-collab-settings) + [스키마 설정 sealed 열: 패딩 유형](#sealed-collab-pad-type) + [sealed 열에 대한 예제 데이터](#sealed-collab-sample-data) + [문제 해결 sealed 열](#troubleshooting-sealed-columns) #### sealed 열의 기본 오버헤드 sealed 열에는 기본 오버헤드가 있습니다. 이 오버헤드는 일정하며, cleartext 및 패딩(있는 경우) 바이트의 크기와 함께 발생합니다. 암호화하기 전에는 sealed 열의 데이터 앞에 포함되는 데이터 유형을 지정하는 1바이트 문자가 추가됩니다. 패딩을 선택하면 데이터가 채워지고 패드 크기를 나타내는 2바이트가 추가됩니다. 이러한 바이트가 추가되면 AES-GCM을 사용하여 데이터를 암호화 처리하여 IV (12바이트), nonce (32바이트) 및 (16바이트) 로 저장합니다. Auth Tag 그런 다음 이 데이터는 base64 인코더를 통해 처리되어 바이트 크기에 약 33% 가 추가됩니다. 데이터 앞에 7바이트 C3R 지정이 추가되어 데이터가 속하는 열 유형과 데이터를 생성하는 데 사용된 클라이언트 버전을 지정합니다. 결과적으로 최종 베이스 오버헤드는 91바이트입니다. 그런 다음 이 결과에 행 수를 곱하여 총 기본 오버헤드를 구할 수 있습니다(`preserveNulls`이 참으로 설정된 경우 null이 아닌 총 값 수 사용). 다음 이미지는 * `BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)` * 방법을 보여줍니다 ![\[sealed 열의 91바이트 기본 오버헤드.\]](http://docs.aws.amazon.com/ko_kr/clean-rooms/latest/userguide/images/base-overhead-sealed.PNG) #### sealed 열에 대한 공동 작업 설정 ##### `preserveNulls` 설정 공동 작업 수준 설정 `preserveNulls`이(가) `false`(기본값)인 경우 각 `null` 값은 고유한 32바이트의 무작위 값이며, `null`이(가) 아닌 것처럼 처리됩니다. 그 결과 이제 각 `null` 값은 91바이트가 됩니다(패딩된 경우 더 많음). 이렇게 하면 이 설정이 `true`이고 `null` 값이 `null`로 전달될 때와 비교하여 매우 희박한 데이터가 포함된 테이블의 경우 상당한 스토리지 요구 사항이 추가될 수 있습니다. 이 설정의 개인정보 보호가 필요하지 않고 데이터 세트 내에 `null` 값을 보관하고 싶다면 공동 작업을 만들 때 `preserveNulls` 설정을 활성화하세요. 공동 작업을 생성한 후에는 `preserveNulls` 설정을 변경할 수 없습니다. #### 스키마 설정 sealed 열: 패딩 유형 **Topics** + [패드 유형: `none`](#pad-type-none) + [패드 유형: `fixed`](#pad-type-fixed) + [`max`의 패드 유형](#pad-type-max) ##### 패드 유형: `none` `none` 패드 유형을 선택하면 패딩이 cleartext에 추가되지 않으며 앞서 설명한 기본 오버헤드에 추가 오버헤드가 추가되지 않습니다. 패딩이 없으면 출력 크기가 가장 공간 효율적입니다. 그러나 `fixed` 및 `max` 패딩 유형과 동일한 개인 정보 보호 보장을 제공하지는 않습니다. 이는 사이퍼텍스트의 크기로 기본 cleartext 파일의 크기를 식별할 수 있기 때문입니다. ##### 패드 유형: `fixed` `fixed` 패드 유형을 선택하면 개인 정보 보호를 위해 열에 포함된 데이터의 길이를 숨길 수 있습니다. 이는 암호화하기 전에 모든 cleartext를 제공된 `pad_length`에 패딩하는 방식으로 수행됩니다. 데이터가 이 크기를 초과하면 C3R 암호화 클라이언트가 실패합니다. 암호화되기 전에 cleartext에 패딩이 추가된다는 점을 감안할 때, AES-GCM은 cleartext를 사이퍼텍스트 바이트에 1대 1로 매핑합니다. base64 인코딩은 33% 를 추가할 것입니다. 패딩의 추가 스토리지 오버헤드는 `pad_length`의 값에서 cleartext의 평균 길이를 뺀 다음 1.33을 곱하여 계산할 수 있습니다. 결과는 레코드당 평균 패딩 오버헤드입니다. 그런 다음 이 결과에 행 수를 곱하여 총 패딩 오버헤드를 구할 수 있습니다(`preserveNulls`이 `true`로 설정된 경우 `null`이 아닌 총 값의 수 사용). `PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT` 열의 가장 큰 값을 포함하는 최소 `pad_length`를 선택하는 것이 좋습니다. 예를 들어, 가장 큰 값이 50바이트인 경우 50의 `pad_length`면 충분합니다. 이보다 큰 값은 스토리지 오버헤드만 추가될 뿐입니다. 고정 패딩은 큰 컴퓨팅 오버헤드를 추가하지 않습니다. ##### `max`의 패드 유형 `max`의 패드 유형을 선택하면 개인 정보 보호를 위해 열에 포함된 데이터의 길이를 숨길 수 있습니다. 암호화하기 전에 모든 cleartext를 열의 가장 큰 값에 더한 추가 `pad_length`로 모두 채워 넣으면 됩니다. 일반적으로 `max` 패딩은 단일 데이터 세트의 `fixed` 패딩과 동일한 보장을 제공하지만 열의 가장 큰 cleartext을(를) 알 수 없도록 합니다. 그러나 개별 데이터 세트에서 가장 큰 값이 다를 수 있으므로 `max` 패딩은 업데이트 전반의 `fixed` 패딩과 동일한 개인정보 보호 보장을 제공하지 않을 수 있습니다. `max` 패딩을 사용할 때는 `pad_length`를 0으로 추가 선택하는 것이 좋습니다. 이 길이는 모든 값을 열의 가장 큰 값과 같은 크기로 채웁니다. 이보다 큰 값은 스토리지 오버헤드만 추가될 뿐입니다. 해당 열의 최대 cleartext 값이 알려진 경우 `fixed` 패드 유형을 대신 사용하는 것이 좋습니다. `fixed` 패딩을 사용하면 업데이트된 데이터 세트 간에 일관성을 유지할 수 있습니다. `max` 패딩을 사용하면 각 데이터 하위 집합이 하위 집합에 있었던 가장 큰 값으로 채워집니다. #### sealed 열에 대한 예제 데이터 다음은 재현할 설정이 있는 sealed 열의 입력 및 출력 데이터 세트 예제입니다. `allowCleartext`, `allowJoinsOnColumnsWithDifferentNames`, 및 `allowDuplicates`같은 기타 공동 작업 수준 설정은 결과에 영향을 주지 않으며 로컬에서 재현하려는 경우 `true` 또는 `false`(으)로 설정할 수 있습니다. 이러한 설정이 재현을 위한 기본 설정이긴 하지만 sealed 열은 결정적이지 않으므로 값이 매번 변경됩니다. 목표는 입력 바이트와 출력 바이트를 비교하여 표시하는 것입니다. 예제 `pad_length` 값은 의도적으로 선택되었습니다. `fixed` 패딩을 사용하면 권장되는 최소 `pad_length` 설정 또는 추가 패딩이 필요한 경우 `max` 패딩과 동일한 값을 얻을 수 있습니다. **공유 비밀의 예**: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` **공동 작업 ID 예시**: `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` **Topics** + [`none`의 패드 유형](#sealed-pad-type-none) + [`fixed`의 패드 유형(예 1)](#sealed-pad-type-fixed) + [`fixed`의 패드 유형(예 2)](#sealed-pad-type-fixed-2) + [`max`의 패드 유형(예시 1)](#sealed-pad-type-max) + [패드 유형 `max` (예 2)](#sealed-pad-type-max-2) ##### `none`의 패드 유형 **예제 1.** | | | | --- |--- | | 입력 | null | | preserveNulls | TRUE | | 출력 | null | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 0 | **예제 2.** | | | | --- |--- | | 입력 | null | | preserveNulls | FALSE | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSPbNIJfG3iXmu6cbCUrizuV | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 91 | **예제 3** | | | | --- |--- | | 입력 | empty string | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSPEM6qR8DWC2PB2GMlX41YK | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 91 | **예 4** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9sGL5VLDQeHzh6DmPpyWNuI= | | DETERMINISTIC | No | | 입력 바이트 | 26 | | 출력 바이트 | 127 | **예 5** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | DETERMINISTIC | No | | 입력 바이트 | 62 | | 출력 바이트 | 175 | ##### `fixed`의 패드 유형(예 1) 이 예제에서 `pad_length`는 62이고 최대 입력은 62바이트입니다. **예제 1.** | | | | --- |--- | | 입력 | null | | preserveNulls | TRUE | | 출력 | null | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 0 | **예제 2.** | | | | --- |--- | | 입력 | null | | preserveNulls | FALSE | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 175 | **예제 3** | | | | --- |--- | | 입력 | empty string | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 175 | **예 4** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | | DETERMINISTIC | No | | 입력 바이트 | 26 | | 출력 바이트 | 175 | **예 5** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | DETERMINISTIC | No | | 입력 바이트 | 62 | | 출력 바이트 | 175 | ##### `fixed`의 패드 유형(예 2) 이 예제에서 `pad_length`는 162이고 최대 입력은 62바이트입니다. **예제 1.** | | | | --- |--- | | 입력 | null | | preserveNulls | TRUE | | 출력 | null | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 0 | **예제 2.** | | | | --- |--- | | 입력 | null | | preserveNulls | FALSE | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 307 | **예제 3** | | | | --- |--- | | 입력 | empty string | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 307 | **예 4** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | | DETERMINISTIC | No | | 입력 바이트 | 26 | | 출력 바이트 | 307 | **예 5** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | | DETERMINISTIC | No | | 입력 바이트 | 62 | | 출력 바이트 | 307 | ##### `max`의 패드 유형(예시 1) 이 예제에서 `pad_length`는 0이고 최대 입력은 62바이트입니다. **예제 1.** | | | | --- |--- | | 입력 | null | | preserveNulls | TRUE | | 출력 | null | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 0 | **예제 2.** | | | | --- |--- | | 입력 | null | | preserveNulls | FALSE | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 175 | **예제 3** | | | | --- |--- | | 입력 | empty string | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 175 | **예 4** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | | DETERMINISTIC | No | | 입력 바이트 | 26 | | 출력 바이트 | 175 | **예 5** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | | DETERMINISTIC | No | | 입력 바이트 | 62 | | 출력 바이트 | 175 | ##### 패드 유형 `max` (예 2) 이 예제에서 `pad_length` 는 100이고 최대 입력은 62바이트입니다. **예제 1.** | | | | --- |--- | | 입력 | null | | preserveNulls | TRUE | | 출력 | null | | DETERMINISTIC | Yes | | 입력 바이트 | 0 | | 출력 바이트 | 0 | **예제 2.** | | | | --- |--- | | 입력 | null | | preserveNulls | FALSE | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 307 | **예제 3** | | | | --- |--- | | 입력 | empty string | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | | DETERMINISTIC | No | | 입력 바이트 | 0 | | 출력 바이트 | 307 | **예 4** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyz | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | | DETERMINISTIC | No | | 입력 바이트 | 26 | | 출력 바이트 | 307 | **예 5** | | | | --- |--- | | 입력 | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | | preserveNulls | - | | 출력 | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | | DETERMINISTIC | No | | 입력 바이트 | 62 | | 출력 바이트 | 307 | #### 문제 해결 sealed 열 **sealed 열의 사이퍼텍스트가 그 안에 들어간 cleartext 열의 크기보다 몇 배나 큰 이유는 무엇인가요?** 이는 여러 요인에 따라 달라집니다. 예를 들어, Cleartext 열의 사이퍼텍스트 길이는 항상 91바이트 이상입니다. 입력 데이터가 작을 경우(예: 고객 연령) 크기가 크게 증가합니다. 둘째, `preserveNulls`이 `false`로 설정되어 있고 입력 데이터에 `null` 값이 많이 포함되어 있는 경우, 각 `null` 값은 91바이트의 사이퍼텍스트로 변환됩니다. 마지막으로, 패딩을 사용하면 정의상 데이터가 암호화되기 전에 cleartext 데이터에 바이트가 추가됩니다. **sealed 열에 있는 대부분의 데이터는 매우 작아서 패딩을 사용해야 합니다. 스페이스를 절약하기 위해 큰 값을 제거하고 개별적으로 처리해도 될까요?** 큰 값을 삭제하고 별도로 처리하지 않는 것이 좋습니다. 이렇게 하면 C3R 암호화 클라이언트가 제공하는 개인 정보 보호 보장이 변경됩니다. 위협 모델로서 관찰자가 암호화된 데이터 세트를 모두 볼 수 있다고 가정해 봅시다. 관찰자는 한 데이터 하위 집합의 열이 다른 하위 집합보다 훨씬 많거나 적게 채워진 것을 발견하면 각 하위 집합의 데이터 크기를 추론할 수 있습니다. 예를 들어 한 파일에서는 `fullName` 열이 총 40바이트로 채워지고 다른 파일에서는 800바이트로 채워져 있다고 가정해 보겠습니다. 관찰자는 한 데이터 세트에 세계에서 가장 긴 이름 (747바이트) 이 포함되어 있다고 가정할 수 있습니다. **`max` 패딩 유형을 사용할 때 추가 패딩을 제공해야 하나요?** `max` 패딩을 사용하는 경우 열에서 가장 큰 값을 *초과*하는 추가 패딩이라고도 하는 `pad_length`를 0으로 설정하는 것이 좋습니다. **가장 큰 값이 맞을지 걱정하지 않도록 `fixed` 패딩을 사용할 때 큰 `pad_length`를 선택해도 되나요?** 네, 하지만 패드 길이가 길면 비효율적이며 필요 이상으로 많은 저장 공간을 사용합니다. 가장 큰 값이 얼마나 큰지 확인하고 `pad_length`를 해당 값으로 설정하는 것이 좋습니다. **`preserveNulls`에서 제공하는 암호화 보증이 필요한지 어떻게 알 수 있나요?** 안타깝게도 답은 상황에 따라 다르다는 것입니다. 최소한 `preserveNulls` 설정이 데이터를 어떻게 보호하는지 [Clean Rooms에 대한 암호화 컴퓨팅](crypto-computing.md)을 검토해야 합니다. 하지만 조직의 데이터 처리 요구 사항 및 각 공동 작업에 적용되는 모든 계약을 참조하는 것이 좋습니다. **base64의 오버헤드가 발생해야 하는 이유는 무엇입니까?** CSV와 같은 표 형식 파일 형식과의 호환성을 허용하려면 base64 인코딩이 필요합니다. Parquet같은 일부 파일 형식은 데이터의 바이너리 표현을 지원할 수 있지만 올바른 쿼리 결과를 얻으려면 공동 작업의 모든 참여자가 동일한 방식으로 데이터를 나타내는 것이 중요합니다. ## 예상하지 못한 사이퍼텍스트 크기 증가 문제 해결 데이터를 암호화했는데 결과 데이터의 크기가 놀라울 정도로 크다고 가정해 보겠습니다. 다음 단계는 크기 증가가 발생한 위치와 취할 수 있는 조치(있는 경우)를 식별하는 데 도움이 될 수 있습니다. ### 크기 증가가 발생한 위치 식별 암호화된 데이터가 cleartext 데이터보다 훨씬 큰 이유를 해결하려면 먼저 크기가 어디서 증가했는지 확인해야 합니다. Cleartext 열은 변경되지 않으므로 무시해도 됩니다. 나머지 fingerprint 열과 sealed 열을 살펴보고 중요해 보이는 열을 선택하세요. ### 크기 증가가 발생한 원인 파악 fingerprint 열 또는 sealed 열이 크기 증가에 영향을 줄 수 있습니다. **Topics** + [fingerprint 열에서 크기가 커졌나요?](#size-increase-from-fingerprint) + [sealed 열을 통해 크기가 커졌나요?](#size-increase-from-sealed) #### fingerprint 열에서 크기가 커졌나요? 스토리지 증가에 가장 큰 영향을 미치는 fingerprint 열인 경우, cleartext 데이터가 적기 때문일 수 있습니다(예: 고객 연령). 결과로 생성되는 각 fingerprint 사이퍼텍스트의 길이는 52바이트입니다. 안타깝게도 이 문제에 대해 열별로 수행할 수 있는 작업은 없습니다. 이 열이 스토리지 요구 사항에 미치는 영향을 포함하여 이 열에 대한 자세한 내용은 [fingerprint 열의 기본 오버헤드](#fingerprint-columns-base-overhead)을(를) 참조하세요. fingerprint 열의 크기가 증가하는 다른 가능한 원인은 공동 작업 설정인 `preserveNulls`입니다. `preserveNulls`에 대한 공동 작업 설정을 사용하지 않도록 설정하면(기본 설정) fingerprint 열의 모든 `null` 값이 52바이트의 사이퍼텍스트가 됩니다. 현재 공동 작업에서는 이에 대해 수행할 수 있는 작업이 없습니다. `preserveNulls` 설정은 공동 작업을 생성할 때 설정되며 올바른 쿼리 결과를 얻으려면 모든 협업자가 동일한 설정을 사용해야 합니다. `preserveNulls` 설정 및 설정 활성화가 데이터의 개인 정보 보장에 미치는 영향에 대한 자세한 내용은 [Clean Rooms에 대한 암호화 컴퓨팅](crypto-computing.md)을 참조하세요. #### sealed 열을 통해 크기가 커졌나요? 저장용량 증가에 가장 큰 영향을 미치는 sealed 열이 열인 경우 크기 증가에 기여할 수 있는 몇 가지 세부 정보가 있습니다. cleartext 데이터가 작은 경우(예: 고객 연령) 결과로 생성되는 각 sealed 사이퍼텍스트의 길이는 91바이트 이상입니다. 안타깝게도 이 문제에 대해서는 아무 것도 할 수 없습니다. 스토리지 요구 사항에 미치는 영향을 포함하여 이 열에 대한 자세한 내용은 [sealed 열의 기본 오버헤드](#sealed-columns-base-overhead)에 대한 세부 정보를 참조하세요. sealed 열 스토리지 증가의 두 번째 주요 원인은 패딩입니다. 패딩은 데이터 세트에서 개별 값의 크기를 숨기기 위해 암호화하기 전에 cleartext에 추가 바이트를 추가합니다. 패딩을 데이터 세트의 가능한 최소값으로 설정하는 것이 좋습니다. 최소한 열에서 가능한 가장 큰 값을 포함하도록 `fixed`에 대한 `pad_length` 패딩을 설정해야 합니다. 이보다 높게 설정해도 개인 정보 보장이 추가되지는 않습니다. 예를 들어 열의 가능한 최대 값이 50바이트라는 것을 알고 있는 경우 `pad_length`를 50바이트로 설정하는 것이 좋습니다. 그러나 sealed 열이 `max` 패딩을 사용하는 경우에는 `pad_length`를 0바이트로 설정하는 것이 좋습니다. 이는 `max` 패딩이 열의 가장 큰 값을 초과하는 *추가* 패딩을 의미하기 때문입니다. sealed 열의 크기가 커질 수 있는 마지막 원인은 공동 작업 설정인 `preserveNulls`입니다. `preserveNulls`에 대한 공동 작업 설정을 사용하지 않도록 설정하면(기본 설정) sealed 열의 모든 `null` 값이 91바이트의 사이퍼텍스트가 됩니다. 현재 공동 작업에서는 이에 대해 수행할 수 있는 작업이 없습니다. `preserveNulls` 설정은 공동 작업이 생성될 때 설정되며 올바른 쿼리 결과를 얻으려면 모든 협업자가 동일한 설정을 사용해야 합니다. 이 설정의 영향 및 활성화가 데이터의 개인 정보 보호 보장에 미치는 영향에 대한 자세한 내용은 [Clean Rooms에 대한 암호화 컴퓨팅](crypto-computing.md)을 참조하세요.