테이블 최적화

제한 문제가 발생하는 경우 데이터를 구조화하는 것이 중요합니다. Amazon S3는 대량의 데이터를 처리할 수 있지만 데이터가 구조화되는 방식 때문에 때때로 제한이 발생합니다.

다음 섹션에서는 제한 문제를 방지하기 위해 Amazon S3에서 데이터를 구조화하는 방법에 대한 몇 가지 제안을 제공합니다.

파티셔닝 사용

파티셔닝을 사용하면 언제든지 액세스해야 하는 데이터의 양을 제한하여 제한을 줄일 수 있습니다. 특정 열에서 데이터를 파티셔닝하면 요청을 여러 객체에서 고르게 분산하고 단일 객체에 대한 요청 수를 줄일 수 있습니다. 스캔해야 하는 데이터의 양을 줄이면 쿼리 성능이 향상되고 비용이 절감됩니다.

테이블을 생성할 때 가상 열 역할을 하는 파티션을 정의할 수 있습니다. CREATE TABLE 문에서 파티션이 있는 테이블을 생성하려면 PARTITIONED BY (column_name data_type) 절을 사용하여 데이터를 파티셔닝하는 키를 정의합니다.

쿼리에서 스캔하는 파티션을 제한하기 위해 쿼리의 WHERE 절에서 파티션을 조건자로 지정할 수 있습니다. 따라서 필터로 자주 사용되는 열이 파티셔닝에 적합합니다. 시간 간격에 따라 데이터를 파티셔닝하는 것이 일반적이며, 이때 여러 수준의 파티셔닝 체계가 형성될 수 있습니다.

파티셔닝에도 비용이 듭니다. 테이블에서 파티션 수를 늘리면 파티션 메타데이터를 검색하고 처리하는 데 필요한 시간도 늘어납니다. 따라서 과도하게 파티셔닝하면 보다 신중한 파티셔닝으로 얻을 수 있는 혜택이 사라질 수 있습니다. 데이터가 한 파티션 값으로 심하게 편중되고 대부분의 쿼리에서 이 값을 사용하는 경우 추가 오버헤드가 발생할 수 있습니다.

Athena에서 파티셔닝에 대한 자세한 내용은 파티셔닝이란 무엇인가요? 섹션을 참조하세요.

데이터 버킷팅

데이터를 파티셔닝하는 또 다른 방법은 데이터를 단일 파티션 내에 버킷팅하는 것입니다. 버킷팅에서는 함께 그룹화하려는 행이 포함된 하나 이상의 열을 지정합니다. 그런 다음 해당 행을 여러 버킷에 넣습니다. 이 방식으로 읽어야 하는 버킷만 쿼리하여 스캔해야 하는 데이터 행 수를 줄일 수 있습니다.

버킷팅에 사용할 열을 선택하는 경우 카디널리티가 높고(즉, 개별 값이 많음) 균일하게 분산되었으며 데이터를 필터링하는 데 자주 사용되는 열을 선택합니다. 버킷팅에 사용하기에 좋은 열의 예로는 ID 열과 같은 기본 키가 있습니다.

Athena에서 버킷팅 사용에 대한 자세한 내용은 버킷팅이란 무엇인가요? 섹션을 참조하세요.

AWS Glue 파티션 인덱스 사용

AWS Glue 파티션 인덱스를 사용하여 하나 이상의 파티션 값을 기반으로 테이블의 데이터를 구성할 수 있습니다. AWS Glue 파티션 인덱스를 사용하면 데이터 전송 횟수, 데이터 처리량, 쿼리 처리 시간을 줄일 수 있습니다.

AWS Glue 파티션 인덱스는 파티션 키 및 해당 값을 포함하여 테이블의 파티션에 대한 정보가 들어 있는 메타데이터 파일입니다. 파티션 인덱스는 Amazon S3 버킷에 저장되며 테이블에 새 파티션이 추가되면 AWS Glue에 의해 자동으로 업데이트됩니다.

AWS Glue 파티션 인덱스가 존재하면 테이블의 모든 파티션을 로드하는 대신 쿼리에서 파티션의 하위 세트를 가져오려고 합니다. 쿼리는 쿼리와 관련된 데이터의 하위 세트에서만 실행됩니다.

AWS Glue에서 테이블을 생성할 때 테이블에 정의된 파티션 키 조합에서 파티션 인덱스를 생성할 수 있습니다. 테이블에서 파티션 인덱스를 하나 이상 생성한 후에는 파티션 필터링을 활성화하는 속성을 테이블에 추가해야 합니다. 그런 다음 Athena에서 테이블을 쿼리할 수 있습니다.

AWS Glue에서 파티션 인덱스 생성에 대한 자세한 내용은 AWS Glue 개발자 안내서의 Working with partition indexes in AWS Glue를 참조하세요. 파티션 필터링을 활성화하기 위해 테이블 속성을 추가하는 방법에 대한 자세한 내용은 AWS Glue 파티션 인덱싱 및 필터링을 통한 쿼리 최적화 섹션을 참조하세요.

데이터 압축 및 파일 분할 사용

파일이 최적 크기이거나 파일을 논리적 그룹으로 분할할 수 있는 경우 데이터 압축을 통해 쿼리 속도를 크게 높일 수 있습니다. 일반적으로 압축률이 높을수록 데이터를 압축하고 압축 해제하는 데 더 많은 CPU 사이클이 필요합니다. Athena의 경우 기본적으로 데이터를 압축하는 Apache Parquet 또는 Apache ORC를 사용하는 것이 좋습니다. Athena의 데이터 압축에 대한 자세한 내용은 Athena에서 압축 사용 섹션을 참조하세요.

파일을 분할하면 Athena에서 단일 파일을 읽는 작업을 여러 리더에 분산시켜 병렬 처리 성능을 높일 수 있습니다. 단일 파일을 분할할 수 없는 경우 하나의 리더만 파일을 읽고 다른 리더가 유휴 상태로 둘 수 있습니다. Apache Parquet 및 Apache ORC도 분할 가능한 파일을 지원합니다.

최적화된 열 기반 데이터 스토어 사용

데이터를 열 형식으로 변환하면 Athena 쿼리 성능이 크게 향상됩니다. 열 기반 파일을 생성할 때 고려할 한 가지 최적화 기법은 파티션 키를 기준으로 데이터를 정렬하는 것입니다.

Apache Parquet 및 Apache ORC는 흔히 사용되는 오픈 소스 열 기반 데이터 스토어입니다. 기존 Amazon S3 데이터 소스를 이러한 형식 중 하나로 변환하는 방법에 대한 자세한 내용은 열 기반 형식으로 변환 섹션을 참조하세요.

하나의 큰 Parquet 블록 크기 또는 ORC 스트라이프 크기 사용

Parquet 및 ORC에는 최적화를 위해 조정할 수 있는 데이터 스토리지 파라미터가 있습니다. Parquet에서는 블록 크기를 최적화할 수 있습니다. ORC에서는 스트라이프 크기를 최적화할 수 있습니다. 블록이나 스트라이프가 클수록 각 블록이나 스트라이프에 저장할 수 있는 행 수가 많아집니다. 기본적으로 Parquet 블록 크기는 128MB이고 ORC 스트라이프 크기는 64MB입니다.

ORC 스트라이프가 8MB(기본값 hive.orc.max_buffer_size) 미만인 경우 Athena는 전체 ORC 스트라이프를 읽습니다. 스트라이프 크기가 작은 경우 Athena는 초당 입력 및 출력 작업과 열 선택성 사이에서 이와 같이 절충합니다.

열 수가 매우 많은 테이블의 경우 블록 또는 스트라이프 크기가 작으면 필요 이상으로 많은 데이터가 스캔될 수 있습니다. 이 경우에는 블록 크기가 클수록 효율적입니다.

복잡한 유형에 대해 ORC 사용

현재 Parquet에 저장된 복잡한 데이터 형식(예: array, map 또는 struct)의 열을 쿼리하는 경우 Athena는 지정된 열만 선택적으로 읽는 대신, 전체 데이터 행을 읽습니다. 이것은 Athena에서 알려진 문제입니다. 이 문제를 해결하려면 ORC를 사용합니다.

압축 알고리즘 선택

사용자가 구성할 수 있는 또 다른 파라미터는 데이터 블록의 압축 알고리즘입니다. Athena에서 Parquet 및 ORC용으로 지원되는 압축 알고리즘에 대한 자세한 내용은 Athena 압축 지원을 참조하세요.

Athena에서 열 기반 스토리지 형식 최적화에 대한 자세한 내용은 AWS 빅 데이터 블로그 게시물 Top 10 Performance Tuning Tips for Amazon Athena의 'Optimize columnar data store generation' 섹션을 참조하세요.

Iceberg 테이블 사용

Apache Iceberg는 Amazon S3에서 최적화된 사용을 위해 설계된 초대형 분석 데이터 세트를 위한 오픈 테이블 형식입니다. Iceberg 테이블을 사용하면 Amazon S3에서 제한을 줄이는 데 도움이 될 수 있습니다.

Iceberg 테이블은 다음과 같은 이점을 제공합니다.

Apache Iceberg에 대한 자세한 내용은 Apache Iceberg를 참조하세요. Athena에서 Apache Iceberg 테이블 사용에 대한 자세한 내용은 Iceberg 테이블 사용을 참조하세요.