기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Trino Trino는 다양한 데이터 소스에 대한 대화형 방식 쿼리를 위해 설계된 오픈 소스 쿼리 엔진입니다. 여기에는 관계형 데이터베이스, 파일 기반 데이터, HDFS 데이터 등이 포함될 수 있습니다. Amazon EMR을 사용하는 Trino의 가장 일반적인 목적은 Amazon S3에 저장된 대규모 데이터 세트에서 복잡한 SQL 쿼리를 실행하는 것입니다. 또한 ANSI SQL을 준수하므로 SQL에 익숙한 데이터베이스 엔지니어, 데이터 분석가 및 데이터 과학자에게 친숙합니다. **참고** PrestoSQL은 2020년 12월에 Trino로 이름이 바뀌었습니다. Amazon EMR 버전 6.4.0 이상은 일반적으로 [Trino](https://trino.io/)를 참조하는 반면, 이전 릴리스 버전은 PrestoSQL을 참조하세요. **중요** 이전 버전의 Trino인 PrestoSQL은 Amazon EMR에서 계속 사용할 수 있습니다. 하지만, 향후 Amazon EMR에서 Trino를 사용할 것을 적극 권장합니다. 또한 Trino와 PrestoSQL은 동일한 클러스터에서 동시에 실행할 수 없습니다. 다음 테이블에는 Amazon EMR이 Trino를 통해 설치하는 구성 요소와 함께 Amazon EMR 7.x의 최신 릴리스에 포함된 Trino의 버전이 나열되어 있습니다. 이 릴리스에서 Trino와 함께 설치된 구성 요소의 버전은 [릴리스 7.12.0 구성 요소 버전을 참조하세요](emr-7120-release.md). **emr-7.12.0용 Trino(PrestoSQL) 버전 정보** | Amazon EMR 릴리스 레이블 | Trino(PrestoSQL) 버전 | Trino(PrestoSQL)와 함께 설치된 구성 요소 | | --- | --- | --- | | emr-7.12.0 | trino-prestosql 476-amzn-1 | emrfs, emr-goodies, hadoop-client, hadoop-hdfs-datanode, hadoop-hdfs-library, hadoop-hdfs-namenode, hadoop-hdfs-zkfc, hadoop-kms-server, hadoop-yarn-nodemanager, hadoop-yarn-resourcemanager, hadoop-yarn-timeline-server, hive-client, hudi, hudi-trino, hcatalog-server, mariadb-server, trino-coordinator, trino-worker | **Topics** + [Trino 기록 및 설계](emr-trino-intro-history.md) + [Trino 시작하기](emr-trino-getting-started.md) + [Amazon EMR에서 Trino 구성](emr-trino-config.md) + [Amazon EMR의 Trino에 대한 모범 사례](emr-trino-advanced.md) + [Trino 고려 사항](Trino-considerations.md) + [Trino 릴리스 기록](Trino-release-history.md) # Trino 기록 및 설계 Trino는 다양한 소스에서 대규모 데이터 세트를 쿼리하는 데 전문화되어 있습니다. Trino는 기존 빅 데이터 사용 사례에서 HDFS에 액세스하고 쿼리할 수 있지만 관계형 데이터베이스 및 NoSQL 데이터베이스와 같은 추가 소스를 쿼리할 수도 있습니다. Trino는 원래 2019년에 Presto 쿼리 엔진의 포크로 시작되었습니다. 이후 Presto 코드 베이스와 독립적으로 개발되었습니다. Trino 쿼리 엔진 및 사용 방법에 대한 자세한 내용은 [Trino 웹 사이트를](https://trino.io/) 참조하세요. Trino 소스 설명서를 읽으려면 [Trino 개요](https://trino.io/docs/current/overview.html)를 참조하세요. ## 아키텍처 개념 Trino는 클러스터 전체에서 병렬로 데이터를 처리하기 때문에 빠르고 효율적인 쿼리를 실행할 수 있습니다. 데이터 레이크는 일반적으로 Hadoop 및 HDFS와 관련된 사용 사례에서 대규모 데이터 볼륨에 대한 쿼리를 전문으로 하기 때문에 데이터 레이크 쿼리를 염두에 두고 설계되었습니다. 그러나 기존 관계형 데이터베이스도 쿼리할 수 있습니다. 자세한 내용은 *Trino 설명서*의 [아키텍처](https://trino.io/docs/current/overview/concepts.html#architecture)를 참조하세요. ### Trino의 구성 요소 Trino에는 쿼리를 빠르게 실행하기 위해 함께 작동하는 몇 가지 주요 아키텍처 구성 요소가 있습니다. 더 나은 성능을 위해 클러스터를 미세 조정할 때 이에 대한 실무 지식을 갖추는 데 도움이 됩니다. + **코디네이터**는 쿼리 오케스트레이션을 담당합니다. 들어오는 SQL 쿼리를 구문 분석 및 최적화하고, 실행 계획을 생성하고, 워커 노드에 작업을 할당하고, 쿼리 결과를 수집 및 수집합니다. 또한 리소스 사용량을 모니터링하고 워커 노드의 상태를 추적합니다. 자세한 내용은 *Trino 설명서*의 [코디네이터](https://trino.io/docs/current/overview/concepts.html#coordinator)를 참조하세요. + **워커 노드**는 쿼리에 대한 데이터 처리를 처리합니다. 코디네이터가 작업을 할당한 후 워커는 데이터를 검색하고, 조인 및 집계와 같은 필요한 작업을 수행하고, 중간 데이터를 다른 워커와 교환합니다. 자세한 내용은 *Trino 설명서*의 [작업자](https://trino.io/docs/current/overview/concepts.html#worker)를 참조하세요. + **커넥터**는 Trino가 다양한 데이터 소스에 연결하고 쿼리할 수 있는 플러그인입니다. 각 커넥터는 Amazon S3, Apache Hive 또는 관계형 데이터베이스와 같은 소스에서 데이터에 액세스하고 검색하는 방법을 알고 있습니다. 이러한 커넥터는 소스 데이터를 Trino의 스키마 구조에 매핑합니다. + **카탈로그**는 특정 커넥터와 연결된 스키마 및 테이블의 논리적 모음입니다. 조정자에 정의된 카탈로그를 사용하면 Trino가 다양한 데이터 소스를 단일 네임스페이스로 처리할 수 있습니다. 이를 통해 사용자는 동일한 쿼리에서 통합된 방식으로 Hive 및 MySQL과 같은 여러 소스를 함께 쿼리할 수 있습니다. + Trino CLI와 같은 **클라이언트**는 JDBC 및 ODBC 드라이버를 통해 Trino 조정자에 연결하여 SQL 쿼리를 제출합니다. 코디네이터는 쿼리 수명 주기를 관리하여 추가 분석 또는 보고를 위해 클라이언트에 결과를 제공합니다. ### 쿼리 실행 Trino가 SQL 문을 가져와 쿼리로 실행하는 방법을 이해하려면 *Trino 설명서*의 [Trino 개념](https://trino.io/docs/current/overview/concepts.html#query-execution-model)을 참조하세요. # Trino 시작하기 이 섹션의 절차에서는 Trino를 사용하여 메타스토어 데이터 소스를 쿼리하기 위해 Amazon EMR 클러스터를 설정하는 방법을 보여줍니다. Glue 데이터 카탈로그를 포함하는 이러한 AWS 메타스토어는 메타데이터 및 데이터베이스 객체를 저장하고 액세스 권한을 관리합니다. 이 절차에서는 사전 조건, 권장 구성 설정, 커넥터 생성 및 메타스토어 테이블에서 쿼리 실행을 다룹니다. **Topics** + [에서 Amazon EMR을 사용하기 위한 사전 조건 단계 완료 Trino](emr-trino-getting-started-pre.md) + [Trino로 Amazon EMR 클러스터 시작](emr-trino-getting-started-launch.md) + [Amazon EMR 클러스터의 프라이머리 노드에 연결하고 쿼리를 실행합니다.](emr-trino-getting-started-connect.md) # 에서 Amazon EMR을 사용하기 위한 사전 조건 단계 완료 Trino 를 사용하지 AWS않았거나 Amazon EMR 클러스터를 생성하지 않은 경우 Trino를 사용하여 Amazon EMR 클러스터를 생성하기 전에 다음 사전 조건 단계를 완료하세요. ## AWS 환경 설정 아직 AWS 계정을 구성하지 않았다면 다음 단계를 완료하세요. 1. AWS 아직 계정이 없는 경우 계정에 가입합니다. 자세한 내용은 [AWS 계정 관리 참조 안내서의 계정 생성을](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) *AWS 참조*하세요. 1. 관리자 계정으로 로그인합니다. 1. 그룹을 생성하고 그룹에 사용자를 할당합니다. 1. 나중에 SSH와의 리소스 간 통신을 보호하는 데 사용할 수 있는 Amazon EC2 키 페어를 생성합니다. 이 단계는 작업을 수행하기 위해 프라이머리 노드에 연결하려는 경우에 필요합니다. 자세한 내용은 [SSH를 사용하여 Amazon EMR 클러스터 프라이머리 노드에 연결](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html)을 참조하세요. # Trino로 Amazon EMR 클러스터 시작 다음은 Trino를 사용하여 클러스터를 생성할 때 올바른 구성 선택에 대해 설명합니다. ## Hive 커넥터를 사용하여 쿼리에 데이터를 사용할 수 있도록 설정 클러스터에서 메타스토어 데이터를 쿼리할 목적으로 Hive 메타스토어에 대한 Trino 커넥터를 구성할 수 있습니다. 메타스토어는 파일 기반 콘텐츠 또는 데이터를 테이블로 사용할 수 있도록 하는 추상화 계층이므로 쿼리하기 쉽습니다. 클러스터에서 Hive 메타스토어 테이블을 사용할 수 있도록 Amazon EMR에서 커넥터를 구성합니다. 다음 절차에서는 이 작업을 수행하는 방법을 보여 줍니다. 1. 콘솔에서 AWS Glue를 선택하고 Amazon S3의 소스 데이터를 기반으로 테이블을 생성합니다. AWS Glue 데이터 카탈로그의 테이블은 데이터에 대한 메타데이터 정의입니다. 이 컨텍스트에서는 테이블을 수동으로 생성하여 소스 데이터에서 원하는 대로 열을 생성하는 것이 좋습니다. Amazon S3의 반정형 데이터에서 AWS Glue의 테이블을 생성하는 방법에 대한 자세한 내용은 *AWS Glue 사용 설명서*의 [콘솔을 사용하여 테이블 생성을](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#console-tables) 참조하세요. 1. 클러스터 생성의 일부로 구성을 설정합니다. **구성** 탭을 선택합니다. 구성은 클러스터의 선택적 사양입니다. 구성을 입력할 때 다음 샘플과 같이 JSON을 추가합니다.이 샘플은 Trino에게 Glue 데이터 카탈로그를 테이블 메타데이터에 대한 외부 Hive AWS 메타스토어로 사용하도록 지시합니다. ``` { "classification": "trino-connector-hive", "properties": { "hive.metastore": "glue" } } ``` 또는 클러스터를 생성할 때 **소프트웨어 설정** 섹션에서 구성을 적용할 수 있습니다. 또한 Apache Iceberg 연결과 같은 다른 커넥터 유형을 설정할 수 있습니다. 자세한 내용은 *Amazon EMR 릴리스 안내서*의 [Trino에서 Iceberg 클러스터 사용](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-trino-cluster.html)을 참조하세요. 추가 설정 구성은 선택 사항입니다. 시작하기 단계를 계속하려면 [Amazon EMR 클러스터의 프라이머리 노드에 연결하고 쿼리를 실행합니다.](emr-trino-getting-started-connect.md) 섹션을 참조하세요. ## Trino로 클러스터 생성 다음은 Trino와 함께 사용할 클러스터를 생성할 때 올바른 구성 선택에 대해 설명합니다. **중요** 클러스터를 생성하기 전에 Glue 데이터 카탈로그 구성을 Hive AWS 메타스토어로 완료합니다.이 구성을 시작하는 것이 좋습니다. 자세한 내용은 [Hive 커넥터를 사용하여 쿼리에 데이터를 사용할 수 있도록 설정](#emr-trino-getting-started-connect-hive) 단원을 참조하십시오. 1. AWS 콘솔의 서비스에서 Amazon EMR을 선택합니다. Amazon EMR을 선택하면 기존 클러스터가 있는 경우 **EC2 클러스터의 EMR**이 나열됩니다. 1. **클러스터 생성**을 선택합니다. 여기에서 클러스터 빌드 프로세스를 시작합니다. 1. 클러스터에 이름을 지정하고 **Amazon EMR 릴리스**를 선택합니다. 자습서의 최신 릴리스를 선택할 수 있습니다. 1. **Trino** 애플리케이션이 미리 선택된 Trino 번들을 선택합니다. 번들은 클러스터의 목적을 미리 알고 있을 때 편의를 위해 설정됩니다. 그렇지 않으면 Trino의 확인란을 선택하기만 하면 됩니다. 1. **클러스터 구성**에서 **균일한 인스턴스 그룹**을 선택합니다. 계속해서 추가 인스턴스 그룹을 제거합니다. 1. **인스턴스 유형**을 선택합니다. 일반적으로 메모리가 16GiB 이상인 인스턴스 유형을 선택하는 것이 좋습니다. 또한 **클러스터 조정 및 프로비저닝**에서 **클러스터 크기 수동 설정**을 선택합니다. 1. 이때 Glue를 가리키도록 Hive AWS 메타스토어 구성을 설정합니다. 자세한 내용은 섹션을 참조하세요[Hive 커넥터를 사용하여 쿼리에 데이터를 사용할 수 있도록 설정](#emr-trino-getting-started-connect-hive). 클러스터를 빌드하기 전에 이 작업을 완료합니다. 1. **클러스터 생성**을 선택합니다. 이 과정을 완료하는 데 몇 분 정도 소요될 수 있습니다. 이 단계에서는 모든 구성 단계를 자세히 다루지는 않습니다. 클러스터 설정에 대한 자세한 내용은 [Amazon EMR 클러스터 계획, 구성 및 시작](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html)에서 확인할 수 있습니다. **참고** 동일한 클러스터에서 사용할 Presto와 Trino를 모두 선택하지 마세요. 이들을 함께 실행하는 것은 지원되지 않습니다. Trino를 실행하는 경우 Spark와 같은 다른 애플리케이션을 클러스터에서 실행하지 않는 것이 좋습니다. # Amazon EMR 클러스터의 프라이머리 노드에 연결하고 쿼리를 실행합니다. ## 테스트 데이터 프로비저닝 및 권한 구성 Glue Data Catalog 및 해당 Hive AWS 메타스토어를 사용하여 Trino로 Amazon EMR을 테스트할 수 있습니다. 이러한 사전 조건 단계에서는 테스트 데이터를 설정하지 않은 경우 설정 방법을 설명합니다. 1. 아직 생성하지 않은 경우 통신 암호화에 사용할 SSH 키를 생성합니다. 1. 여러 파일 시스템에서 선택하여 데이터 및 로그 파일을 저장할 수 있습니다. Amazon S3 버킷을 생성하려면 버킷에 고유한 이름을 지정합니다. 생성할 때 생성한 암호화 키를 지정합니다. **참고** 동일한 리전을 선택하여 스토리지 버킷과 Amazon EMR 클러스터를 모두 생성합니다. 1. 생성한 버킷을 선택합니다. **폴더 생성**을 선택하고 폴더에 기억하기 쉬운 이름을 지정합니다. 폴더를 생성할 때 보안 구성을 선택합니다. 상위에 대한 보안 설정을 선택하거나 보안 설정을 더 전문화할 수 있습니다. 1. 폴더에 테스트 데이터를 추가합니다. 이 자습서에서는 쉼표로 구분된 레코드의 .csv를 사용하여 이 사용 사례를 효과적으로 완료할 수 있습니다. 1. Amazon S3 버킷에 데이터를 추가한 후 데이터 쿼리를 위한 추상화 계층을 제공하도록 AWS Glue에서 테이블을 구성합니다. ## 쿼리 연결 및 실행 다음은 Trino를 실행하는 클러스터에 연결하고 쿼리를 실행하는 방법을 설명합니다. 이렇게 하기 전에 메타스토어 테이블이 표시되도록 이전 절차에서 설명한 Hive 메타스토어 커넥터를 설정합니다. 1. EC2 Instance Connect를 사용하여 클러스터에 연결하는 것이 좋습니다. 보안 연결을 제공하기 때문입니다. 클러스터 요약에서 **SSH를 사용하여 프라이머리 노드에 연결**을 선택합니다. 연결을 사용하려면 서브넷의 클라이언트에 대한 포트 22를 통한 연결을 허용하는 인바운드 규칙이 보안 그룹에 있어야 합니다. 또한 연결할 때 사용자 **hadoop**을 사용합니다. 1. `trino-cli`를 실행하여 Trino CLI를 시작합니다. 이 작업을 수행하면 Trino를 사용하여 명령을 실행하고 데이터를 쿼리할 수 있습니다. 1. `show catalogs;`를 실행합니다. **Hive** 카탈로그가 나열되어 있는지 확인합니다. 이는 데이터 스토어 또는 시스템 설정이 포함된 사용 가능한 카탈로그 목록을 제공합니다. 1. 사용 가능한 스키마를 보려면 `show schemas in hive;`를 실행합니다. 여기에서 `use schema-name;`을(를) 실행하고 스키마 이름을 포함할 수 있습니다. 그런 다음 `show tables;`를 실행하여 테이블을 나열할 수 있습니다. 1. 스키마의 테이블 이름을 사용하여 `SELECT * FROM table-name` 같은 명령을 실행하여 테이블을 쿼리합니다. 특정 스키마에 연결하기 위해 `USE` 문을 이미 실행한 경우 *schema*.*table* 같이 두 부분으로 구성된 표기법을 사용할 필요가 없습니다. # Amazon EMR에서 Trino 구성 **Topics** + [Trino용 커넥터 구성](#emr-trino-config-connector) + [모니터링](#emr-trino-monitoring) ## Trino용 커넥터 구성 ### Hive AWS 메타스토어로 Glue에 연결 Trino를 사용하여 쿼리를 실행할 때 AWS Glue 데이터 카탈로그를 Hive 메타스토어로 구성할 수 있다는 점을 이해하는 것이 중요하고 유용합니다. Hive 메타스토어로 클러스터를 설정하는 단계를 포함한 추가 정보는 [Glue 데이터 카탈로그를 Hive의 AWS 메타스토어로 사용을 참조하세요](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html). EMR on EKS를 AWS Glue와 통합하는 방법에 대한 자세한 내용은 [EMR Containers를 AWS Glue와 통합](https://aws.github.io/aws-emr-containers-best-practices/metastore-integrations/docs/aws-glue/)하는 모범 사례를 참조하세요. ### Amazon EMR에서 Trino를 사용할 때 Iceberg 테이블에 연결 Iceberg는 분석 테이블을 위한 오픈 테이블 형식입니다. Spark 및 Trino와 같은 엔진이 SQL 쿼리를 사용하여 동일한 테이블에서 빅 데이터를 쿼리하도록 생성되었습니다. 여기에는 데이터 읽기 및 쓰기 격리와 같은 기능이 포함되어 있으므로 리더는 예를 들어, 부분적으로 업데이트된 데이터를 쿼리하지 않아도 됩니다. 스냅샷과 같은 상태 기능도 지원합니다. 메타데이터 및 매니페스트 파일을 사용하여 추상화 계층을 제공합니다. 테이블 스키마를 설명하고 형식 지정 또는 구성 방법에 대한 많은 세부 정보를 알 필요 없이 데이터를 쉽게 쿼리할 수 있습니다. 연결된 경우 테이블 업데이트 데이터에서 데이터를 읽거나 기본 파일에 새 데이터를 쓸 수 있습니다. Amazon EMR 및 AWS Glue를 사용하여 Iceberg 테이블을 구성하는 방법을 보여주는 워크숍이 있습니다. 자세한 내용은 [분석 워크숍 - Data Lake에서 Apache Iceberg 테이블 설정 및 사용](https://youtu.be/SZDYmWIStUo?si=sW35AjSWIcHu5x_p)을 참조하세요. ### 클라이언트와 연결 사용 가능한 JDBC 드라이버를 사용하여 Trino에 연결할 수 있습니다. 자세한 내용은 *Trino 설명서*의 [JDBC 드라이버](https://trino.io/docs/current/client/jdbc.html)를 참조하세요. ## 모니터링 를 통해 Amazon EMR 클러스터를 모니터링할 수 있습니다 AWS Management Console. 자세한 내용은 [작업을 수행하는 경우 Amazon EMR 클러스터 보기 및 모니터링](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view.html)을 참조하세요. Amazon EMR은 모니터링 지표도 Amazon CloudWatch에 전송합니다. Amazon EMR 클러스터 모니터링에 대한 자세한 내용은 [Amazon EMR의Amazon CloudWatch 이벤트 및 지표]()를 참조하세요. # 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)를 참조하세요. # Trino 고려 사항 Amazon EMR에서 Trino를 실행할 때는 다음 사항을 고려합니다. ## 구성할 수 없는 Trino 배포 속성 아래 테이블에는 Trino `properties` 파일의 여러 가지 구성 옵션이 나와 있습니다. | 파일 | 구성 가능 | | --- | --- | | `log.properties` | Trino: Amazon EMR 버전 6.1.0 이상에서 구성할 수 있습니다. `prestosql-log` 또는 `trino-log` 구성 분류를 사용합니다. | | `config.properties` | Trino: Amazon EMR 버전 6.1.0 이상에서 구성할 수 있습니다. `prestosql-config` 또는 `trino-config` 구성 분류를 사용합니다. | | `hive.properties` | Trino: Amazon EMR 버전 6.1.0 이상에서 구성할 수 있습니다. `prestosql-connector-hive` 또는 `trino-connector-hive` 구성 분류를 사용합니다. | | `node.properties` | Trino: Amazon EMR 버전 6.1.0 이상에서 구성할 수 있습니다. `prestosql-node` 또는 `trino-node` 구성 분류를 사용합니다. | | `jvm.config` | 구성할 수 없습니다. | ## 추가 고려 사항 + EMR 버전 6.1.0 이상에 기반한 Trino의 경우 Amazon EMR은 클러스터 노드 간 안전한 내부 통신을 위해 공유 보안 암호 키를 자동으로 구성합니다. 이 보안 기능을 활성화하기 위해 추가 구성을 수행할 필요가 없으며 자체 보안 암호 키를 사용하여 구성을 재정의할 수 있습니다. Trino 내부 인증에 대한 자세한 내용은 [Trino 353 설명서: Secure internal communication](https://trino.io/docs/current/security/internal-communication.html)을 참조하세요. # Trino 릴리스 기록 릴리스 정보 섹션에서는 Amazon EMR 기반 Trino의 특정 버전에 대한 변경 사항 및 업데이트를 자세히 설명합니다. ## 버전별 Trino 릴리스 정보 + [Amazon EMR 7.6.0 - Trino 릴리스 정보](Trino-release-history-760.md) + [Amazon EMR 7.3.0 - Trino 릴리스 정보](Trino-release-history-730.md) + [Amazon EMR 6.9.0 - Trino 릴리스 정보](Trino-release-history-690.md) # Amazon EMR 7.6.0 - Trino 릴리스 정보 ## Amazon EMR 7.6.0 - Trino 새로운 기능 + 이제 Trino에는 장기 실행 쿼리를 지원하기 위해 내결함성 실행 메커니즘이 포함됩니다. 내결함성 실행은 실패한 쿼리 또는 구성 요소 작업을 재시도하여 쿼리 실패를 완화합니다. ## Amazon EMR 7.6.0 - Trino 변경 사항 **Amazon EMR 7.6.0 - Trino 변경 사항** | Type | 설명 | | --- | --- | | 업그레이드 | Trino를 457로 업그레이드 | # Amazon EMR 7.3.0 - Trino 릴리스 정보 ## Amazon EMR 7.3.0 - Trino 변경 사항 + 이 릴리스에서는 Trino를 버전 436에서 442로 업그레이드합니다. + 이 릴리스에서는 Hudi 쿼리를 새 Hudi 보정기로 리디렉션합니다. 이전 Hive 커넥터는 더 이상 Hudi 테이블을 읽을 수 없습니다. Note + 이 릴리스에서는 Rubix 모듈이 이제 오픈 소스에서 더 이상 사용되지 않으므로 Amazon EMR에서 Rubix 모듈을 제거합니다. + 이 릴리스에서는 `hive.security` 속성에서 [레거시 모드를 제거](https://github.com/trinodb/trino/pull/21013)합니다. 이제 기본값은 `allow-all`입니다. # Amazon EMR 6.9.0 - Trino 릴리스 정보 ## Amazon EMR 6.9.0 - Trino 새로운 기능 + 이제 Trino에는 장기 실행 쿼리를 지원하기 위해 내결함성 실행 메커니즘이 포함됩니다. 내결함성 실행은 실패한 쿼리 또는 구성 요소 작업을 재시도하여 쿼리 실패를 완화합니다. ## Amazon EMR 6.9.0 - Trino 변경 **Amazon EMR 6.9.0 - Trino 변경** | Type | 설명 | | --- | --- | | 업그레이드 | Trino를 398로 업그레이드 | | 업그레이드 | Hadoop 3.3.3에 대한 지원 | | 기능 | Tardigrade 지원: HDFS 및 Amazon S3에서 교환 스풀링에 대한 지원을 추가합니다. | | 버그 수정 | Trino Iceberg를 사용하고 Glue 카탈로그를 활성화한 경우 `iceberg.properties.`에서 메타스토어 URI를 추가하지 않습니다. | ## Amazon EMR 6.9.0 - Trino 알려진 문제 + Amazon EMR 릴리스 6.9.0의 경우 Trino는 Apache Ranger가 활성화된 클러스터에서 작동하지 않습니다. Ranger와 함께 Trino를 사용해야 하는 경우 [지원](https://console.aws.amazon.com/support/home#/)에 문의하세요.