# Lake Formation에 등록된 데이터를 쿼리할 때의 고려 사항 및 제한 사항
Athena를 사용하여 Lake Formation에 등록된 데이터를 쿼리할 때는 다음을 고려하세요. 추가 정보는 *AWS Lake Formation 개발자 안내서*의 [AWS Lake Formation의 알려진 문제](https://docs.aws.amazon.com/lake-formation/latest/dg/limitations.html)를 참조하세요.
**Topics**
+ [일부 상황에서 열에 대한 데이터 권한이 없는 사용자에게 표시되는 열 메타데이터](#lf-athena-limitations-column-metadata)
+ [뷰에 대한 Lake Formation 권한 작업](#lf-athena-limitations-permissions-to-views)
+ [Iceberg DDL 지원](#lf-athena-limitations-iceberg-ddl-operations)
+ [Lake Formation 세분화된 액세스 제어 및 Athena 작업 그룹](#lf-athena-limitations-fine-grained-access-control)
+ [Lake Formation에 등록되지 않은 Amazon S3의 Athena 쿼리 결과 위치](#lf-athena-limitations-query-results-location)
+ [Athena 작업 그룹을 사용하여 쿼리 기록에 대한 액세스 제한](#lf-athena-limitations-use-workgroups-to-limit-access-to-query-history)
+ [Lake Formation에 등록된 CSE-KMS Amazon S3 위치를 Athena에서 쿼리할 수 없음](#lf-athena-limitations-cse-kms)
+ [Lake Formation에 등록된 분할된 데이터 위치는 테이블 하위 디렉터리에 있어야 함](#lf-athena-limitations-partioned-data-locations)
+ [CTAS(Create Table As Select) 쿼리에 Amazon S3 쓰기 권한 필요](#lf-athena-limitations-ctas-queries)
+ [기본 데이터베이스에 대해 DESCRIBE 권한 필요](#lf-athena-limitations-describe-default)
## Avro 및 Custom SerDe를 사용하여 일부 상황에서 권한이 없는 사용자에게 표시되는 열 메타데이터
Lake Formation 열 수준 권한 부여를 통해 사용자가 Lake Formation 권한이 없는 열의 데이터에 액세스하는 것을 방지할 수 있습니다. 그러나 특정 상황에서 사용자는 데이터에 대한 권한이 없는 열을 포함하여 테이블의 모든 열을 설명하는 메타데이터에 액세스할 수 있습니다.
이 현상은 열 메타데이터가 Apache Avro 스토리지 형식을 사용하거나 테이블 스키마가 SerDe(Serializer/Deserializer) 정의와 함께 테이블 속성에 정의된 사용자 지정 SerDe를 사용하는 테이블의 테이블 속성에 저장될 때 발생합니다. Lake Formation과 함께 Athena를 사용할 때는 Lake Formation에 등록한 테이블 속성의 콘텐츠를 검토하고, 가능한 경우 테이블 속성에 저장된 정보를 제한하여 민감한 메타데이터가 사용자에게 표시되지 않도록 하는 것이 좋습니다.
## Lake Formation 및 뷰 이해
Lake Formation에 등록된 데이터의 경우 Athena 사용자는 `VIEW`가 기반으로 하는 테이블, 열 및 소스 Amazon S3 데이터 위치에 대한 Lake Formation 권한이 있는 경우에만 `VIEW`를 생성할 수 있습니다. Athena에서 `VIEW`를 생성한 후 Lake Formation 권한을 `VIEW`에 적용할 수 있습니다. `VIEW`에는 열 수준 권한을 사용할 수 없습니다. `VIEW`에 대한 Lake Formation 권한은 있지만 뷰의 기반이 되는 테이블 및 열에 대한 권한이 없는 사용자는 `VIEW`를 사용하여 데이터를 쿼리할 수 없습니다. 그러나 이러한 혼합 권한이 있는 사용자는 `DESCRIBE VIEW`, `SHOW CREATE VIEW` 및 `SHOW COLUMNS`와 같은 문을 사용하여 `VIEW` 메타데이터를 볼 수 있습니다. 그러므로 각 `VIEW`에 대한 Lake Formation 권한을 기본 테이블 권한에 맞춰야 합니다. 테이블에 정의된 셀 필터는 해당 테이블의 `VIEW`에 적용되지 않습니다. 리소스 링크 이름이 원래 계정의 리소스와 같아야 합니다. 크로스 계정 설정에서 뷰 작업을 수행할 때 추가 제한 사항이 있습니다. 계정 간에 공유되는 뷰에 대한 권한 설정에 대한 자세한 내용은 [크로스 계정 데이터 카탈로그 액세스 구성](lf-athena-limitations-cross-account.md)을 참조하세요.
## Iceberg DDL 지원
Athena는 현재 Lake Formation에 위치가 등록된 Iceberg 테이블에 대한 DDL 작업을 지원하지 않습니다. 이러한 Iceberg 테이블 중 하나에서 DDL 쿼리를 실행하려고 하면 Amazon S3 액세스 거부 오류가 반환되거나 쿼리 시간 초과로 실패할 수 있습니다. Iceberg 테이블에서 DDL 작업을 수행하려면 사용자가 Iceberg 테이블 위치에 직접 액세스할 수 있는 Amazon S3 권한이 있어야 합니다.
## Lake Formation 세분화된 액세스 제어 및 Athena 작업 그룹
동일한 Athena 작업 그룹의 사용자는 Lake Formation 세분화된 액세스 제어를 통해 작업 그룹에 액세스할 수 있도록 구성한 데이터를 볼 수 있습니다. Lake Formation에서 세분화된 액세스 제어를 사용하는 방법에 대한 자세한 내용은 *AWS 빅 데이터 블로그*의 [AWS Lake Formation을 사용하여 세분화된 액세스 제어 관리](https://aws.amazon.com/blogs/big-data/manage-fine-grained-access-control-using-aws-lake-formation/)를 참조하세요.
## Lake Formation에 등록되지 않은 Amazon S3의 Athena 쿼리 결과 위치
Amazon S3의 Athena 쿼리 결과 위치는 Lake Formation에 등록할 수 없습니다. Lake Formation 권한은 이러한 위치에 대한 액세스를 제한하지 않습니다. 액세스를 제한하지 않는 한 Athena 사용자는 데이터에 대한 Lake Formation 권한이 없어도 쿼리 결과 파일과 메타데이터에 액세스할 수 있습니다. 이를 방지하려면 작업 그룹을 사용하여 쿼리 결과의 위치를 지정하고 작업 그룹 구성원에 맞게 Lake Formation 권한을 조정하는 것이 좋습니다. 그런 다음 IAM 권한 정책을 사용하여 쿼리 결과 위치에 대한 액세스를 제한할 수 있습니다. 쿼리 결과에 대한 자세한 내용은 [쿼리 결과 및 최근 쿼리 작업](querying.md) 단원을 참조하세요.
## Athena 작업 그룹을 사용하여 쿼리 기록에 대한 액세스 제한
Athena 쿼리 기록은 저장된 쿼리 및 전체 쿼리 문자열 목록을 드러냅니다. 작업 그룹을 사용하여 쿼리 기록에 대한 액세스를 분리하지 않으면 Lake Formation에서 데이터를 쿼리할 권한이 없는 Athena 사용자가 열 이름, 선택 기준 등을 비롯해 해당 데이터에 대해 실행되는 쿼리 문자열을 볼 수 있습니다. 작업 그룹을 사용하여 쿼리 기록을 분리하고 Athena 작업 그룹 구성원에 맞게 Lake Formation 권한을 조정하여 액세스를 제한하는 것이 좋습니다. 자세한 내용은 [작업 그룹을 사용하여 쿼리 액세스 및 비용 제어](workgroups-manage-queries-control-costs.md) 섹션을 참조하세요.
## Lake Formation에 등록된 CSE\_KMS 암호화 테이블 쿼리
다음과 같은 특성을 가진 Apache Iceberg와 같은 OTF(오픈 테이블 형식) 테이블은 Athena로 쿼리할 수 없습니다.
+ 테이블은 Lake Formation에 등록된 Amazon S3 데이터 위치를 기반으로 합니다.
+ Amazon S3의 객체가 CSE(클라이언트 측 암호화)를 사용하여 암호화됩니다.
+ 암호화에서는 AWS KMS 고객 관리형 키(`CSE_KMS`)를 사용합니다.
`CSE_KMS` 키로 암호화된 OTF가 아닌 테이블을 쿼리하려면 CSE 암호화에 사용하는 AWS KMS 키의 정책에 다음 블록을 추가하세요. {{}}은 데이터를 암호화하는 AWS KMS 키의 ARN입니다. {{}}은 Lake Formation에 Amazon S3 위치를 등록하는 IAM 역할의 ARN입니다.
```
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "kms:Decrypt",
"Resource": "{{}}",
"Condition": {
"ArnLike": {
"aws:PrincipalArn": "{{}}"
}
}
}
```
## Lake Formation에 등록된 분할된 데이터 위치는 테이블 하위 디렉터리에 있어야 함
Lake Formation에 등록된 분할된 테이블은 Amazon S3 테이블의 하위 디렉터리인 디렉터리에 분할된 데이터가 있어야 합니다. 예를 들어, 위치가 `s3://amzn-s3-demo-bucket/mytable`이고 파티션이 `s3://amzn-s3-demo-bucket/mytable/dt=2019-07-11`, `s3://amzn-s3-demo-bucket/mytable/dt=2019-07-12` 등인 테이블은 Lake Formation에 등록하고 Athena를 사용하여 쿼리할 수 있습니다. 반면, 위치가 `s3://amzn-s3-demo-bucket/mytable`이고 파티션이 `s3://amzn-s3-demo-bucket/dt=2019-07-11`, `s3://amzn-s3-demo-bucket/dt=2019-07-12` 등인 테이블은 Lake Formation에 등록할 수 없습니다. 이러한 파티션은 `s3://amzn-s3-demo-bucket/mytable`의 하위 디렉토리가 아니기 때문에 Athena에서 읽을 수도 없습니다.
## CTAS(Create Table As Select) 쿼리에 Amazon S3 쓰기 권한 필요
CTAS(Create Table As Statements)에는 테이블의 Amazon S3 위치에 대한 쓰기 액세스 권한이 필요합니다. Lake Formation에 등록된 데이터에 대해 CTAS 쿼리를 실행하려면 Athena 사용자는 데이터 위치를 읽을 수 있는 적절한 Lake Fomation 권한과 더불어 테이블의 Amazon S3 위치에 쓸 수 있는 IAM 권한이 있어야 합니다. 자세한 내용은 [쿼리 결과에서 테이블 생성(CTAS)](ctas.md) 단원을 참조하세요.
## 기본 데이터베이스에 대해 DESCRIBE 권한 필요
Lake Formation에서 볼 수 있으려면 `default` 데이터베이스에 대한 Lake Formation `DESCRIBE` 권한이 필요합니다. 다음 예제에서는 AWS CLI 명령으로 AWS 계정 `111122223333`의 `datalake_user1` 사용자에게 `default` 데이터베이스에 대한 `DESCRIBE` 권한을 부여합니다.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Database": {"Name":"default"}}
```
자세한 내용은 *AWS Lake Formation 개발자 안내서*의 [DESCRIBE](https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-reference.html#perm-describe)를 참조하세요.