[Trino] Trino의 구조 및 설정

이번 글에서는 저번 글에 이어, Trino의 구조와 설정에 대해서 알아볼 예정입니다. 해당 글에서는 Trino의 구조 및 설정 튜닝의 이해를 목표로 합니다.

 

---

Trino 구조

Server types

Trino는 두 가지의 서버 타입이 있습니다. 하나는 Coordinator, 다른 하나는 Worker입니다.

 

Coordinator

Coordinator는 구문 분석, 쿼리 계획, Worker 노드 관리와 같은 일을 합니다. 즉, Client로 부터 쿼리문을 수신하여 구문을 분석하고 쿼리를 계획합니다. 추가적으로 Worker 노드를 관리하는 역할을 하는 서버입니다. Coordinator는 REST API를 통해 클러이언트 및 Worker와 통신합니다. 

 

Worker

Worker는 실제 Task을 실행하고, 데이터 처리를 담당합니다. 즉, Coordinator로 부터 할당받은 Task을 수행하고, 데이터 처리 역할을 수행합니다. Worker노드는 connector에서 데이터를 가져오고 서로 중간 데이터를 교환합니다. Coordinator는 Worker로 부터 결과를 가져가 클라이언트에게 최종 결과를 반환합니다. worker 노드는 프로세스가 시작되면 Coordinator의 Discovery server(service)에 자신의 존재를 알림으로 Coordinator가 작업 실행을 위해 workder 노드를 사용할 수 있도록 합니다. 

 

Coordinator와 Worker 노드는 REST API를 통해 통신하며, Worker 노드들 끼리도 동일합니다. (Test 목적인 경우, Coordinator와 worker가 같은 서버에 있을 수도 있습니다.)

 

Data sources

Connector

connector는 Hive 또는 RDBMS와 같은 데이터 소스에 Trino를 연결합니다. Database의 driver와 동일한 역할을 수행하며, 데이터 소 스에서 데이터를 읽을 수 있도록 Coordinator, Worker와 데이터소스를 연결해주는 역할을 합니다. Catalog는 특정  connector와 연결이 되는데, Catalog config 파일을 보면 각각에 필요한 필수 속성 값이 포함되어 있습니다. "connector.name" (예, connector.name=mysql)값을 통해 지정할 수 있습니다.

 

Catalog

Catalog는 스키마를 포함하고, 커넥터를 통해 데이터 소스를 참조합니다. 즉, Trino는 Catalog에 마운트된 connector를 통해 데이터 소스에 접근합니다. 예를 들어, Hive Connector로 Hive warehouse에 접근하기 위해서는 /etc/catalog 위치의 Hive Catalog(hive.properties)를 구성 해야 합니다. (Catalog안에는 Schema들이 존재합니다.)

 

Schema

스키마는 테이블을 구성하는 방법이며, DB와 유사한 개념입니다. 

 

Table

Table은 열로 구성된 정렬되지 않은 행 집합으로 DB의 table과 동일합니다.

 

Query 실행 모델

Stage

Trino는 Query를 실행할 때 계층 구조로 분할하여 쿼리를 실행합니다. 예를 들어 Trino가 데이터를 집계해야 하는 경우, 루트 Stage를 만들어 여러 Stage의 출력을 집계합니다. 이 단계는 모두 분산 쿼리 계획의 다른 섹션을 구현하도록 설계되었습니다. 쿼리를 구성하는 Stage의 계층 구조는 트리와 유사합니다. Stage는 Coordinator가 분산 쿼리 계획을 모델링하는데 사용하지만, Stage 자체는 Trino Worker에게 실행되지 않습니다. 

 

Task

Stage는 분산 쿼리 계획의 특정 섹션을 모델링하지만 Stage 자체는 Trino Worker에서 실행되지 않습니다. 분산 쿼리 계획은 연속된 Stage 들이 분해되어 Task로 되며, Task는 Split 작업을 실행합니다. Stage가 일련의 Task에 의해 병렬로 실행될 수 있는 것처럼 Task는 일련의 Driver와 병렬로 실행됩니다.

 

Split

Trino가 쿼리를 스케쥴링 할때, Coordinator는 split의 리스트를 connector에게 쿼리합니다. Coordinator는 어떤 Taks를 실행하고, 어떤 Taks가 어떤 split을 처리하는지 추적합니다.

 

Driver

Task에는 하나 이상의 병렬 driver가 포함됩니다. Driver는 Operator를 결합하여, 집계된 다음 다른 Stage의 다른 Task에 전달되는 출력을 생성합니다.

 

Trino 동작 순서

Trino 동작 순서

1. Trino Worker 프로세스가 시작하면, Coordinator의 Discovery Service 에 등록합니다. Discovery Service에 등록되어야, Coordinator가 Task를 Worker에 배정할 수 있습니다. (Discovery service ↔ Worker, 주기적으로 하트비트 신호를 보냅니다.)
2. Client는 HTTP기반 프로토콜을 사용하여 Coordinator에게 쿼리 전송합니다.
3. Coordinator는 쿼리를 구문 분석하고 query plan이라고 하는 실행 계획 생성합니다.
   • Query plan = 데이터를 처리하고 결과를 반환하는데 까지의 모든 단계
   • Parser/analyzer = 테이블, 컬럼 및 타입에 대한 정보 수집
   • Planner = row개수 및 테이블 크기에 대한 정보 수집
   • Schduler = Query plan 생성
4. Coordinator가 query plan에 필요한 스키마 데이터를 connector Plugin에 요청합니다.
5. Coordinator에서 Worker로 수행해야 할 task를 전달합니다.
6. Worker는 Connector Plugin을 통해서 Data Sources로 부터 데이터를 읽어옵니다.
7. Worker들은  query plan에 따라 할당된 task를 메모리에서 수행합니다.
8. 실행 결과를 Coordinator을 거쳐 Client에 전달합니다.

 

Configuration

 

config.properties (Trino 서버 구성정보)

# coordinator configuration
coordinator=true 
node-scheduler.include-coordinator=false 
http-server.http.port=9999
query.max-memory=4GB #(Worker)
query.max-memory-per-node=1GB 
discovery.uri=http://{cluster_node}:9999 # coodinator

# worker configuration
coordinator=False
http-server.http.port=9999
query.max-memory=4GB #(Worker)
query.max-memory-per-node=1GB 
discovery.uri=http://{cluster_node}:9999 # coodinator

 

node.properties

각 노드들의 설정, 노드 아이피 명시, 환경명 명시합니다. (클러스터들끼리 동일한 환경의 이름을 가져야 합니다.) Production일 경우, 환경명을 production으로 수정해서 사용합니다.

node.environment=production # trino web Ui header tag node
node.id={cluster_node}
node.data-dir=/trino/data

 

jvm.config

-server
-Xmx8G # maximum heap space Trino
-XX:-UseBiasedLocking
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+ExplicitGCInvokesConcurrent
-XX:+ExitOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:ReservedCodeCacheSize=512M
-XX:PerMethodRecompilationCutoff=10000
-XX:PerBytecodeRecompilationCutoff=10000
-Djdk.attach.allowAttachSelf=true
-Djdk.nio.maxCachedBufferSize=2000000

 

catalog.properties

커넥터 구성으로서, Trino는 카탈로그에 탑제된 커넥터를 통해 데이터에 엑세스할 수 있습니다.  예를 들어, catalog/hive.properties와 같은 catalog를 생성해야, trino가 hive(hivemetastore)와 연결이 가능합니다. Catalog는 /catalog (Trino의 catalog path 확인 필요) 디렉토리에 카탈로그 속성 파일을 생성하여 등록합니다. 예를 들어, 커넥터를 카탈로그로 /catalog/jmx. properties 마운트하려면 "connector.name=jmx" 같이 작성을 해주어야 합니다. 

# hive catalog
connector.name=hive
hive.metastore.uri=thrift://{hivemetastore uri} # Hive Thrift uri

 

Trino Web UI

States

• QUEUED: 큐에 대기중인 상태
• PLANNING: 쿼리 계획중인 상태
• STARTING: 쿼리 실행 시작하는 상태
• RUNNING: 쿼리에 실행중인 Task가 존재하는 상태
• BLOCKED: 쿼리가 차단되고 메모리, 버퍼 공간 등을 기다리는 상태
• FINISHING: 쿼리가 커밋이 진행중이고 완료되는 상태
• FINISHED: 쿼리 실행이 완료된 상태
• FAILED: 쿼리 실행이 실패한 상태

 

Connector

트리노에서는 다양한 소스의 커넥터를 제공합니다. (https://trino.io/docs/current/connector.html)

 

• BigQuery
• Cassandra
• Elasticsearch
• Google Sheets
• Hive
• JMX
• Kafka
• Kinesis
• Local File
• Memory
• MongoDB
• MySQL
• Oracle
• PostgreSQL
• Prometheus
• Redis
• Redshift
• System
• Thrift

 

reference

• https://trino.io/docs/current/overview/use-cases.html

Use cases — Trino 435 Documentation

• https://data-engineer-tech.tistory.com/53