기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EMR의 Trino에 대한 모범 사례
Trino의 아키텍처는 각 구성 요소가 쿼리 실행에 특별한 역할을 하는 코디네이터-워커 모델에 따라 여러 데이터 소스의 대규모 데이터 세트에 대한 빠른 분산 SQL 쿼리를 위해 설계되었습니다. 최상의 성능을 위해 Trino를 실행하는 Amazon EMR 클러스터를 구성하기 위해 집중할 수 있는 몇 가지 영역 또는 범주가 있습니다. 여기에는 다음이 포함됩니다.
+ 메모리 최적화를 위한 클러스터 구성 설정 조정.
+ 데이터 파티셔닝 및 데이터 배포를 위한 설정 최적화.
+ 동적 필터링을 사용하여 쿼리 결과 수를 줄입니다.
이러한 설정 중 일부는 Amazon EMR에서 Trino를 사용할 때 자동으로 조정됩니다. 콘솔 또는 CLI 명령을 통해 수동으로 설정할 수 있습니다. 이 섹션의 주제는 데이터와 클러스터를 최적으로 구성하는 데 도움이 됩니다.
**Topics**
+ [성능 개선을 위한 주요 중점 영역](emr-trino-performance-areas.md)
+ [테이블 통계 수집 및 활용](emr-trino-performance-areas-collect-stats.md)
+ [Trino 워크로드 확장 시 일반적인 문제](emr-trino-common-issues.md)
# 성능 개선을 위한 주요 중점 영역
Trino는 쿼리 병렬 처리 및 메모리 최적화를 극대화합니다. 이 아키텍처는 효율적으로 규모를 조정하면서 다양한 여러 데이터 소스를 쿼리할 수 있도록 하여 유연성을 제공합니다. Trino에서 성능 개선의 주요 영역에는 아래 나열된 영역이 포함됩니다.
## 메모리 최적화
Trino의 메모리 관리는 특히 크고 복잡한 쿼리를 실행할 때 고성능과 안정성을 달성하는 데 매우 중요합니다. Trino는 분산 메모리 모델을 사용합니다. 이 모델에서는 작업, 집계, 조인 및 기타 작업을 처리하기 위해 워커 노드에 메모리가 할당됩니다. 다음 목록은 이러한 설정 모음을 소개합니다.
+ **query.max-memory** – 전체 클러스터에서 단일 쿼리에 사용할 수 있는 최대 메모리를 설정합니다. 이는 하드 제한입니다. 쿼리가 이 메모리를 초과하면 실패합니다.
+ **query.max-memory-per-node** - 쿼리가 각 워커 노드에서 사용할 수 있는 최대 메모리를 정의합니다. 이를 설정하면 단일 쿼리가 워커의 리소스를 독점하지 않습니다.
+ **JVM 힙 크기 **- JVM 수준에서 구성되며 각 노드에서 Trino 서버 프로세스의 최대 힙 크기를 설정합니다. 이 값은 일반적으로 Trino의 메모리 관련 구성(**query.max-memory-per-node** 및 **memory.heap-headroom-per-node**의 합계)보다 커야 JVM 수준에서 시스템의 메모리 부족을 방지할 수 있습니다.
+ **memory.heap-headroom-per-node** - 쿼리가 아닌 작업의 경우 JVM 힙 크기를 벗어나도록 메모리의 버퍼 양을 지정합니다. 이는 내부 작업 및 가비지 수집을 위한 충분한 오버헤드를 보장하는 데 매우 중요합니다.
## 동적 필터링
Trino의 동적 필터링은 특히 조인 중에 처리되는 데이터의 양을 줄여 쿼리 성능을 개선하는 최적화 기법입니다. 필터 조건을 동적으로 적용하여 다른 쪽에서 볼 수 있는 데이터를 기반으로 조인의 한쪽에서 스캔하는 데이터를 제한합니다. 이는 조인의 한쪽이 매우 선택적인(즉, 작은 데이터 하위 집합을 포함하는) 쿼리에 특히 유용합니다. Amazon EMR에서 기본적으로 활성화됩니다. 다음은 쿼리의 예입니다.
```
SELECT orders.order_id, orders.total_amount
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE customers.country = 'France';
```
동적 필터링이 없는 경우 Trino는 조인에서 전체 주문 테이블을 스캔하지만, 일부 고객(프랑스)만 관련이 있습니다. 이 방법은 **주문** 테이블의 모든 행을 읽어 I/O 및 처리 비용이 높습니다. 동적 필터링을 사용하면 Trino는 처음에 더 작은 **customers** 테이블을 스캔하고 프랑스의 고객에 대해서만 customer\$1id 값을 검색한 다음이 하위 집합을 주문에 필터로 적용합니다. 즉, customer\$1id가 필터링된 하위 집합과 일치하는 **orders**의 관련 행만 스캔되므로 처리된 레코드가 크게 줄어듭니다.
## 디스크에 유출
Trino에서 디스크 유출을 사용하면 중간 쿼리 결과를 디스크로 오프로드할 수 있으므로 `query_max_memory` 또는 `query_max_memory_per_node`에서 설정한 메모리 제한을 초과하더라도 메모리 집약적인 쿼리를 완료할 수 있습니다. 기본적으로 Trino는 이러한 제한을 적용하여 공정한 메모리 할당을 보장하고 클러스터 교착 상태를 방지합니다. 그러나 대규모 쿼리가 이러한 제한을 초과하면 종료될 위험이 있습니다. 디스크 유출은 `revocable memory`를 사용하여 이 문제를 해결하므로 다른 곳에서 리소스가 필요한 경우 취소할 수 있는 추가 메모리를 쿼리에서 빌릴 수 있습니다. 메모리가 취소되면 중간 데이터가 디스크로 유출되어 메모리 제한을 초과하지 않고 쿼리를 계속 처리할 수 있습니다. 강제로 디스크로 유출되는 쿼리는 실행 시간이 길어질 수 있으므로 기본적으로 비활성화되어 있습니다. Amazon EMR에서 유출을 활성화하려면 다음 구성을 사용합니다.
+ `spill-enabled=true` - 메모리 사용량이 사용 가능한 임계값을 초과할 때 디스크 유출을 활성화합니다.
+ `spill-paths` - 유출된 데이터가 저장되는 `spill-paths=/mnt/spill` 디렉터리를 정의합니다.
# 테이블 통계 수집 및 활용
테이블 통계를 수집하면 Trino의 비용 기반 최적화 프로그램이 조인 주문, 필터 푸시다운 및 파티션 정리에 대해 정보에 입각한 결정을 내릴 수 있으므로 성능이 향상됩니다.
`ANALYZE` 명령을 사용하여 Hive 또는 Iceberg 테이블에 대한 통계를 수집할 수 있습니다.
```
ANALYZE sales;
```
넓은 테이블에 대한 통계를 수집하면 리소스에 대한 세금이 부과될 수 있습니다. 조인, 필터 또는 그룹화 작업에 사용되는 열의 하위 집합을 지정하는 것이 좋습니다.
이 명령은 또 다른 유용한 명령입니다. 테이블에 대한 현재 통계를 표시하여 통계가 최신 상태인지 확인합니다.
```
show stats for table_name;
```
# Trino 워크로드 확장 시 일반적인 문제
Trino와 함께 Amazon S3를 사용할 때 얻을 수 있는 주요 이점은 대용량 데이터 볼륨에 맞게 확장할 수 있는 Amazon S3의 기능과 Amazon S3의 비용 효율성입니다. 그러나 대용량 데이터 볼륨을 쿼리할 때 관련 성능 문제 모음이 가끔 발생할 수 있습니다. 이는 데이터 저장 방법, 우수한 성능을 제한하는 구성 설정 또는 기타 이유로 인해 발생할 수 있습니다. 이러한 문제가 발생하면 이를 방지하거나 완화하기 위해 취할 수 있는 효과적인 단계가 있습니다.
이 섹션은 대용량 데이터 볼륨에서 쿼리 성능을 높이기 위해 구현할 수 있는 일반적인 최적화 목록으로 시작합니다. 그런 다음 일반적인 문제가 자세히 설명되고 각 문제에 대한 완화 조치가 제공됩니다.
이 주제는 [대규모 성능 가속화: Amazon S3를 사용한 Trino 모범 사례](https://www.youtube.com/watch?v=cjUUcHlUKxQ) 컨퍼런스 프레젠테이션에서 발췌한 것입니다.
## 대규모 데이터 세트에 대한 데이터 레이아웃 최적화
대용량 데이터 세트를 쿼리할 때는 성능 병목 현상이 자주 발생하지 않습니다. 하지만 Trino를 사용하여 Amazon S3의 데이터를 쿼리할 때 헤드 스타트를 제공하기 위해 구현할 수 있는 모범 사례가 있습니다. 여기에는 다음이 포함됩니다.
+ **파티셔닝** - 파티셔닝은 계층 구조에서 데이터를 구성하고 관련 속성을 기반으로 관련 데이터를 함께 저장하는 것을 의미합니다. 파티셔닝을 사용하면 쿼리가 관련 없는 데이터를 많이 스캔할 필요가 없으므로 쿼리 성능이 향상됩니다. 소스 데이터를 접두사, 특히 날짜 범위 리전 또는 기타 속성으로 정렬하는 등 다양한 파티셔닝 전략을 사용할 수 있습니다. 성능을 높이기 위해 Amazon S3에서 데이터를 파티셔닝하는 방법에 대한 자세한 내용은 블로그 게시물 [AWS Glue 데이터 카탈로그에서 지원하는 Amazon S3 테이블의 파티션 관리를 시작하기](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) 또는 상위 [10개 성능 튜닝 팁 게시물을 참조하세요 Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/).
+ **버킷팅** - 버킷팅은 관련 데이터를 공통 파일로 그룹화합니다. 예를 들어, 상태와 같은 지리적 리전에 따라 데이터를 쿼리하는 경우 동일한 파일 또는 파일 그룹에서 특정 상태에 대한 모든 데이터를 그룹화하여 쿼리 성능을 높일 수 있습니다. 이를 가장 잘 수행하려면 예를 들어, 주 또는 도와 같이 카디널리티가 높은 데이터 속성을 기반으로 버킷팅합니다. 또한 쿼리 패턴을 고려할 수 있습니다. 쿼리가 일반적으로 해당 상태의 데이터를 함께 읽는 경우 캘리포니아와 오리건에 대한 데이터를 그룹화하는 것을 예로 들 수 있습니다.
+ **Amazon S3 접두사 관리** - Amazon S3 접두사를 사용하여 파티셔닝 전략을 구현할 수 있습니다. 예를 들어, 특정 날짜와 같은 Amazon S3 버킷에 단일 접두사만 사용하는 경우 요청 수가 많아지고 HTTP 503 오류가 발생할 수 있습니다. 접두사를 사용하여 조건을 추가하고 소스 데이터를 보다 효과적으로 구성하는 것이 좋습니다. 자세한 내용은 Amazon S3 사용 설명서의 [접두사를 사용하여 객체 구성하기](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html)를 참조하세요. 다음 간단한 예제는 요청 처리량을 높이는 접두사(`s3://bucket/country=US/dt=2024-06-13`)를 보여줍니다. 이 샘플에서는 국가와 날짜가 모두 접두사에 포함되므로 접두사에 날짜만 포함된 경우보다 읽기 수가 적습니다.
HTTP 503 오류 완화는 이 주제에서 이어지는 *HTTP 속도 저하* 섹션에서 자세히 설명합니다.
+ **데이터 크기 최적화** - OPTIMIZE 명령을 실행하여 성능이 더 좋은 쿼리에 도움이 되는 구성을 설정할 수 있습니다. Hive 외부 테이블에 대해 실행하려면 다음 단계를 따르세요.
+ `OPTIMIZE`에 다음 파라미터 `hive.non-managed-table-writes-enabled=true`를 사용합니다. 이 속성에 대한 자세한 내용은 [Hive 일반 구성 속성](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties)을 참조하세요.
+ 다음 `SET SESSION` `catalog.non_transactional_optimize_enabled=true` 세션 파라미터를 설정합니다.
+ `OPTIMIZE` 명령(`ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`)을 실행합니다. 이 경우 `file_size_threshold`는 기본적으로 100MB입니다. 샘플에서 볼 수 있듯이 이 임계값을 높이면 128MB 미만의 파일이 병합됩니다.
+ **재시도 구성** - `s3.max-error-retries`를 설정하여 HTTP 503 오류 가능성을 완화할 수 있는 재시도 제한을 늘릴 수 있습니다. 이는 TrinoFileSystem API 및 Trino 449 버전 이상을 사용할 때 적용됩니다. 반면 Trino와 함께 Amazon EMR을 사용하는 경우 EMRFS를 사용하여 Amazon S3에 액세스합니다. EMRFS를 사용하면 `fs.s3.maxRetries` 파라미터를 변경하여 사용 중지 수를 늘릴 수 있습니다.
+ **Amazon S3 스토리지 클래스 선택** - 수명 주기의 여러 지점에서 데이터에 적합한 스토리지 클래스를 선택하면 특정 데이터 수집에 대한 요구 사항에 따라 성능과 비용 모두에 도움이 될 수 있습니다. 자세한 내용은 Amazon S3 사용 설명서의 [Amazon S3 스토리지 클래스 이해 및 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm) 섹션을 참조하세요.
+ **Iceberg로 마이그레이션** - 성능 문제, 특히 작은 파일에서 쿼리를 실행하는 것과 관련된 문제를 완화하는 또 다른 솔루션은 Iceberg 테이블로 마이그레이션하는 것입니다. Iceberg에는 작은 파일을 잘 처리하는 기능이 있습니다.
+ **자동 데이터 압축 사용** - Iceberg 테이블을 사용하는 경우 AWS Glue 데이터 카탈로그를 사용한 자동 데이터 압축은 데이터 크기를 최적화하고 쿼리 성능을 개선할 수 있습니다.
## 대규모 데이터 세트를 쿼리할 때 발생하는 일반적인 문제
이 섹션에서는 Amazon S3에 대용량 데이터 세트를 누적하여 Trino로 쿼리할 때 발생할 수 있는 일반적인 문제 모음을 나열합니다. 각 섹션에서는 문제를 해결하거나 쿼리에 미치는 영향을 줄이는 방법을 보여줍니다. 다음 섹션에 설명된 각 문제는 Hive 커넥터를 사용하여 재현 및 테스트되었습니다.
### 대규모 데이터 스캔
쿼리가 대용량 데이터 세트를 스캔해야 하는 경우 쿼리 성능 저하 및 스토리지 비용 상승과 같은 문제가 발생할 수 있습니다. 대용량 데이터 볼륨은 빠른 데이터 증가 또는 계획으로 인해 적절한 기간 내에 레거시 데이터를 이동하지 못할 수 있습니다. 이로 인해 쿼리가 느려질 수 있습니다.
대용량 데이터 세트 스캔으로 인한 성능 저하를 완화하려면 파티셔닝 및 버킷팅을 활용하는 것이 좋습니다.
+ 파티셔닝은 속성을 기반으로 관련 데이터를 그룹화합니다. 파티셔닝을 효과적으로 사용하면 쿼리 성능이 크게 향상될 수 있습니다.
+ 버킷팅은 특정 관련 데이터 열에 따라 파일 또는 버킷의 데이터를 그룹화하는 것을 말합니다. 버킷팅은 일반적으로 관련 소스 데이터 파일을 물리적으로 함께 보관하는 것을 의미합니다.
대규모 데이터 스캔에서 완화가 어떻게 작동하는지 설명하기 위해 캘리포니아 또는 알래스카에 할당할 수 있는 상태 속성이 있는 레코드가 있고 이 상태 속성이 쿼리 조건 중 하나인 데이터를 저장하고 쿼리한다고 가정합니다. S3 접두사를 사용하여 각 상태에 대한 데이터를 별도의 S3 버킷에 저장하거나 상태에 따라 데이터를 파티셔닝하여 쿼리 성능을 개선할 수 있습니다. 이 파티셔닝 및 버킷팅은 날짜 속성과 같은 추가 열을 기반으로 하는 경우에도 성능을 개선할 수 있습니다.
**참고**
열의 카디널리티가 높고 이를 사용하여 데이터를 그룹화하려는 경우이 경우 버킷팅을 사용하는 것이 좋습니다. 반면, 일반적으로 파티션 키는 카디널리티가 더 낮아야 합니다.
**다양한 S3 스토리지 유형 사용**
일반적으로 워크로드의 성능, 데이터 액세스, 복원력 및 비용 요구 사항을 기반으로 스토리지 유형을 선택합니다. 비용과 성능 간에 절충이 있을 수 있습니다. 데이터 액세스 패턴과 일치하는 적절한 Amazon S3 스토리지 클래스를 선택하는 것이 중요합니다. 두 가지 주요 액세스 패턴이 있습니다.
+ 알려지거나 예측 가능한 방식으로 액세스되는 데이터입니다. 일반적으로 자주 액세스하지 않는 데이터가 있는 경우 비용을 절감하는 데 도움이 되므로 S3 Standard IA를 선택하는 것이 좋습니다. 데이터에 자주 액세스한 경우 S3 Standard는 Amazon EMR 및 Trino를 사용한 액세스에 가장 적합합니다.
+ 알 수 없거나 예측할 수 없는 방식으로 액세스되는 데이터입니다. 이는 다른 Amazon S3 스토리지 클래스를 사용하기 위해를 호출할 수 있습니다. Amazon S3 스토리지 클래스 간에 절충이 있습니다. 여기에는 지연 시간, 스토리지 비용 및 가용성이 포함됩니다. 워크로드 및 액세스 패턴에 따라 적절한 S3 스토리지 유형을 선택할 수 있습니다. 각 클래스의 이점에 대한 설명은 [Amazon S3 스토리지 클래스를 참조하세요]().
**압축 사용**
Iceberg 테이블을 사용하면 Iceberg 자동 압축을 사용하여 파일 크기를 최적화하여 쿼리 효율성을 높일 수도 있습니다. 자세한 내용은 [이제AWS Glue Data Catalog에서 Apache Iceberg 테이블의 자동 압축 지원](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/) 섹션을 참조하세요.
### HTTP 속도 저하 오류
이는 요청 속도가 Amazon S3 접두사에 대해 미리 구성된 임계값을 초과할 때 발생합니다. 이 상태에 도달할 때 가장 일반적으로 발생하는 HTTP 오류는 **오류 503: 요청 속도를 줄이세요** 오류입니다. 이 문제의 소스는 데이터를 읽기 위해 생성해야 하는 *분할* 수가 많기 때문에 작은 파일이 많을 때 루트가 될 수 있습니다. 문제를 완화하는 몇 가지 방법이 있습니다.
+ Trino에서 Amazon S3 요청에 대한 재시도 제한을 늘립니다. 이는 Trino 449에서 `fs.s3.maxretries`을(를) 사용하는 EMRFS에 대해 설정됩니다.
+ 파일 크기를 최적화하면 요청 속도가 낮아질 수도 있습니다.
Trino가 쿼리할 데이터 세트의 분할 수를 결정하는 방법에 대한 자세한 내용은 Hive 커넥터 설명서의 [성능 튜닝 구성 속성](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties)을 참조하세요.
### 작은 파일을 쿼리하기 어려움
많은 작은 파일을 쿼리하면 GET 및 LIST 요청 수가 많아서 I/O 오버헤드가 높아져 쿼리 성능에 부정적인 영향을 미칠 수 있습니다. 파일 크기를 최적화하면 쿼리 성능이 향상될 수 있습니다. 몇 가지 방법으로 수행할 수 있습니다.
+ 데이터를 더 적은 수의 더 큰 파일로 통합합니다. (일반적으로 파일 크기는 약 128MB로 유지하는 것이 좋습니다.) ETL 파이프라인과 같이 데이터를 수집할 때 도구를 사용하여 이 작업을 수행하거나 데이터를 수동으로 통합할 수 있습니다. 이러한 솔루션을 사용할 수 없는 경우 나머지 옵션이 더 적합할 수 있습니다.
+ `OPTIMIZE` 명령을 실행합니다.
+ `SESSION` 파라미터를 설정합니다.
Iceberg에는 작은 파일을 자동 압축인 더 큰 파일로 병합할 수 있는 기능이 있습니다. AWS Glue 데이터 카탈로그로 관리되는 파일에서 작동합니다. 자세한 내용은 [이제AWS Glue Data Catalog에서 Apache Iceberg 테이블의 자동 압축 지원](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/) 섹션을 참조하세요.
### 필요하지 않은 데이터가 포함된 쿼리
데이터가 증가하는 것은 일반적이므로 데이터 액세스 패턴을 추적하고 데이터가 노후화되거나 관련이 없게 되면 데이터를 적절하게 이동합니다. 이는 데이터가 증가함에 따라 쿼리 실행 시 스캔할 데이터의 양이 많기 때문에 시간이 지남에 따라 쿼리 성능이 저하될 수 있기 때문입니다. Amazon S3 및 기타 서비스는 데이터 수명 주기 마이그레이션에 대한 지침을 제공합니다.이 지침은 데이터를 다른 스토리지 위치로 이동하는 전략을 보여줍니다. 이 작업을 수행하면 스토리지 비용 이점도 있습니다.
데이터 마이그레이션 외에도 실행 중인 쿼리와 관련이 없는 소스 데이터 제거와 같은 다른 전략을 사용할 수 있습니다. 이는 소스 데이터 스키마를 변경하는 것을 의미할 수 있으므로 일부 작업이 필요할 수 있습니다. 그러나 긍정적인 결과는 데이터 볼륨을 줄이고 쿼리 속도를 높이는 것입니다. 자세한 내용은 [객체 수명 주기 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)를 참조하세요.