Trino의 주요 기능 정리

Trino는 어느새 레이크하우스의 기본 SQL 엔진이 되었습니다. 현대적인 데이터 플랫폼을 운영한다면, 인터랙티브 분석이든 BI이든 애드혹 탐색이든 페더레이션 쿼리든, 스택 어딘가에서 Trino나 그 상용 배포판이 돌고 있을 가능성이 매우 높습니다.

---

1. Trino란

Trino 공식 문서의 정의는 명확합니다.

"Trino는 하나 이상의 이종 데이터 소스에 분산된 대규모 데이터셋을 쿼리하기 위해 설계된 분산 SQL 쿼리 엔진이다."

두 가지 강조점이 중요합니다.

• 분산 SQL 쿼리 엔진. 데이터베이스가 아닙니다. Trino는 데이터를 소유하지 않으며, 다른 곳에 있는 데이터를 쿼리합니다.
• 이종 데이터 소스. 하나의 SQL 표면으로 여러 시스템을 다룹니다 — 오브젝트 스토리지(Iceberg, Delta, Hive, Hudi), RDBMS(PostgreSQL, MySQL, Oracle, SQL Server), NoSQL(MongoDB, Cassandra), 검색/로그(Elasticsearch, OpenSearch, Loki), 데이터 웨어하우스(BigQuery, Snowflake, Redshift) 등.

그리고 Trino가 무엇이 아닌지도 문서에 분명하게 적혀 있습니다.

"Trino는 범용 관계형 데이터베이스가 아니다. MySQL, PostgreSQL, Oracle 같은 데이터베이스의 대체재가 아니다. … OLTP(Online Transaction Processing)를 처리하도록 설계되지 않았다."

올바른 관점은 이렇습니다. Trino는 하나 또는 여러 소스에 걸친 대규모, 스캔 위주의 쿼리에 강한 OLAP / 분석용 SQL 엔진입니다. 고객 대면 트랜잭션 쓰기가 들어갈 자리는 아닙니다.

---

2. 아키텍처 — 코디네이터, 워커, 그리고 쿼리의 라이프사이클

Trino는 전형적인 MPP(Massively Parallel Processing) 시스템입니다. 공식 문서의 concepts 페이지가 구성 요소를 정의합니다.

역할

• Coordinator — "쿼리문을 파싱하고 실행 계획을 세우며, Trino 워커 노드들을 관리하는 서버." 클러스터의 두뇌이자 클라이언트의 진입점입니다.
• Worker — "Trino 인스톨레이션에서 태스크를 실행하고 데이터를 처리하는 서버." 커넥터를 통해 데이터를 가져오고 중간 결과를 서로 교환합니다.
• Node — 클러스터 안의 어떤 Trino 서버(JVM 프로세스).

쿼리가 무엇으로 변하는가

코디네이터에 SQL 문이 도착하면, 이 계층 구조로 변환됩니다.

SQL 문
   ↓
Query           (전체 분산 실행 계획)
   ↓
Stages          (계획의 계층적 구획)
   ↓
Tasks           ("일꾼" — 워커에서 실체화된 스테이지)
   ↓
Drivers         (태스크 내의 병렬 파이프라인)
   ↓
Operators       (테이블 스캔, 필터, 해시 조인, 집계 등)
   ↓
Splits          (오퍼레이터가 소비하는 소스 데이터 조각)

서로 다른 워커에 있는 태스크들은 Exchange를 통해 데이터를 주고받습니다. 코디네이터는 어떤 스플릿이 어떤 태스크에 배정되었는지, 각 스테이지의 진행도가 어떤지를 추적합니다.

이 계층 구조가 Trino의 확장성의 근거입니다. 어떤 단일 오퍼레이터(조인이든 집계이든)도 다수의 워커에 걸쳐 다수의 드라이버로 병렬화되며, I/O 비용은 그들 사이의 Exchange 단계에서만 발생합니다.

---

3. 커넥터 — 페더레이션 모델

Connector는 문서의 표현대로 "Trino의 service provider interface(SPI) 구현체로, Trino가 표준 API로 어떤 리소스와 상호작용할 수 있게 해 주는 것"입니다.

커넥터를 SQL에서 사용하려면 Catalog를 설정합니다. 카탈로그는 어떤 커넥터를 쓰고 어떤 접속 정보를 사용할지를 정의하는 작은 프로퍼티 파일입니다. 그 뒤로는:

catalog.schema.table
   │       │      │
   │       │      └── 소스 안의 객체
   │       └────────── 그루핑/네임스페이스
   └────────────────── 설정된 카탈로그 (커넥터 + 설정)

하나의 쿼리에서 여러 카탈로그의 테이블을 동시에 참조할 수 있습니다. 이것이 페더레이션이며, SQL 레벨에서 Trino가 가진 가장 특징적인 능력입니다.

현재 Trino 릴리스에서 제공되는 커넥터는 크게 다음과 같이 분류됩니다.

실무적 함의:

• 모든 데이터를 레이크로 옮길 필요가 없습니다. PostgreSQL이든 MongoDB든 카탈로그 파일 하나로 Trino에서 곧바로 쿼리됩니다.
• 커넥터가 가능한 Pushdown 범위를 결정합니다(아래 참고). 더 강한 푸시다운은 소스에서 더 많은 일을 처리하고 Trino로 보내는 데이터를 줄인다는 뜻입니다.
• 어떤 고급 기능(predicate pushdown, statistics, dynamic filtering, fault-tolerant execution)이 실제로 지원되는지도 커넥터가 정합니다.

---

4. SQL 표면 — ANSI SQL, 함수, UDF

Trino는 ANSI SQL의 폭넓은 부분을 구현하고, 그 위에 상당한 라이브러리를 더합니다. 공식 문서의 목차만 봐도 표면적이 가늠됩니다.

• 70여 종의 SQL 문 — SELECT, 조인, WITH(CTE), MERGE, CREATE TABLE AS, INSERT, DELETE, UPDATE, EXPLAIN, ANALYZE, SHOW, DESCRIBE, GRANT/REVOKE, Materialized View, Prepared Statement, 트랜잭션 등.
• 30여 종의 함수 카테고리 — 집계, 윈도우, 문자열, 날짜/시간, JSON, 배열, 맵, URL, 정규식, 변환, 수학, 지리 공간, 그리고 최근 릴리스에 포함된 AI 함수.
• 사용자 정의 함수(UDF) — CREATE FUNCTION 구문 기반의 SQL UDF와 Python UDF 모두 지원.

실제 워크로드에서 자주 활용되는 두 가지를 따로 짚어 둘 만합니다.

• 본격적인 ANSI 범위의 윈도우 함수 — 파티셔닝, 정렬, 프레이밍, ROWS/RANGE/GROUPS, 내비게이션 함수. 분석 워크로드 대부분이 여기에 살고 있습니다.
• JSON / 배열 / 맵 함수 — 오브젝트 스토리지의 반정형 데이터를 쿼리 전에 관계형으로 풀어 둘 필요 없이 1급 시민으로 다룰 수 있게 해 줍니다.

---

5. 쿼리 옵티마이저

10 TB짜리 Iceberg 테이블과 50 GB짜리 PostgreSQL 테이블을 페더레이션 쿼리로 조인했을 때, 결과가 "느리지만 가능"이 될지 "사실상 폭주"가 될지를 가르는 게 옵티마이저입니다.

비용 기반 옵티마이저 (CBO)

Trino는 ANALYZE(또는 커넥터가 제공하는 값)로 수집된 테이블 통계(row count, 컬럼 NDV, null 비율, min/max)를 사용해 조인 순서와 분배 전략을 선택합니다. 통계가 없으면 휴리스틱으로 폴백하고, 있으면 실질적으로 더 나은 계획을 만듭니다.

EXPLAIN을 읽으면 옵티마이저가 무엇을 선택했는지 보입니다. 문서는 EXPLAIN에 비용 표시를 명시적으로 제공해서, 나쁜 계획을 디버깅할 수 있게 합니다.

Pushdown (푸시다운)

푸시다운은 Trino가 할 일을 소스 시스템 쪽으로 이동시킵니다. 옵티마이저가 시도하는 형태는:

• Predicate Pushdown — WHERE 필터를 소스에서 평가.
• Aggregation Pushdown — 지원되는 경우 COUNT, SUM, GROUP BY를 소스에서 실행.
• Join Pushdown — 같은 소스에 있는 테이블끼리의 로컬 조인을 소스에서 처리(Trino 내부가 아니라).
• Limit / TopN Pushdown — LIMIT과 정렬 후 제한을 일찍 적용.

푸시다운 범위는 커넥터마다 다릅니다. JDBC 기반 커넥터(PostgreSQL, MySQL, Oracle, SQL Server 등)는 공격적으로 푸시다운하는 편이고, 오브젝트 스토리지 커넥터는 파일 프루닝과 컬럼 프로젝션까지 푸시다운합니다.

Dynamic Filtering (동적 필터링)

Dynamic Filtering은 Trino의 런타임 최적화 중 가장 영향력이 큰 기능 중 하나입니다.

"Dynamic Filtering 최적화는 조인 조건에 의해 걸러질 데이터의 읽기를 회피함으로써, 선택적 조인을 사용하는 쿼리의 성능을 크게 향상시킨다."

동작 방식:

1. 조인의 우측(보통 작은 dimension 테이블)이 먼저 처리됩니다.
2. Trino는 조인 조건을 통과하는 실제 값을 수집합니다.
3. 수집된 값이 **런타임 술어(predicate)**가 되어 좌측(probe) 스캔으로 푸시다운됩니다 — 코디네이터 차원의 파일/파티션 프루닝, 또는 워커 내 필터링으로.

스타 스키마 쿼리에서 이것은 곧 "팩트 테이블 전체를 스캔하는 것"과 "조인 가능한 파티션·파일만 스캔하는 것"의 차이입니다.

=, <, <=, >, >=, IS NOT DISTINCT FROM 조인 조건의 inner join, right join, 그리고 IN 조건의 semi-join에 적용됩니다. 커넥터 지원은 Hive와 Iceberg에서 가장 넓고, Memory 커넥터와 여러 JDBC 소스에서도 동작합니다.

Adaptive Plan Optimization (적응형 계획 최적화)

최근 Trino 릴리스는 실행 중에 관찰된 카디널리티와 Exchange 크기를 기반으로 물리적 실행 계획을 런타임에 조정합니다. 예를 들어 build 쪽이 실제로 작게 나오면 partitioned join을 broadcast join으로 전환하거나, 스큐를 보완하기 위해 재파티셔닝합니다. 옵티마이저는 더 이상 플래닝 시점에 계획에 완전히 못 박지 않습니다.

---

6. Fault-tolerant Execution

이전의 Trino는 워커 하나가 죽으면 진행 중이던 쿼리도 함께 죽었습니다. Fault-tolerant Execution은 이를 바꿉니다.

"Fault-tolerant Execution을 활성화하면, 중간 Exchange 데이터가 스풀링되어, 쿼리 실행 중 워커 장애 등의 결함이 발생했을 때 다른 워커가 이를 재사용할 수 있다."

두 가지 정책이 있습니다.

TASK 정책을 쓰려면 Exchange Manager가 필요합니다. 외부 스토리지(S3, ADLS, GCS, HDFS, Alluxio, 로컬 파일시스템)에 중간 Exchange 데이터를 실체화해 두는 스풀 위치이며, 이 스풀이 있어야 한 워커가 죽었을 때 다른 워커가 이어받을 수 있습니다.

재시도는 지수 백오프 — 기본값은 최대 4회 재시도, 시작 10초, 상한 1분입니다.

기억해 둘 두 가지 한계:

• Fault tolerance는 인프라 장애에 대한 것이지, 잘못된 SQL을 구해 주는 기능이 아닙니다. "Fault tolerance does not apply to broken queries or other user error."
• 커넥터 지원은 선별적입니다 — 명시적으로 Hive, Iceberg, Delta Lake, BigQuery, 그리고 여러 JDBC 커넥터.

Fault-tolerant Execution은 Trino를 "인터랙티브 전용"에서 배치 / ETL 엔진으로도 확장합니다. 플랫폼에서 Trino가 차지할 수 있는 역할의 폭이 의미 있게 넓어집니다.

---

7. 보안

Trino의 보안 표면적은 엔터프라이즈 SQL 엔진에서 기대할 만한 형태입니다. 문서는 다섯 영역으로 묶습니다.

인증(Authentication)

• Password file authentication
• LDAP authentication
• Salesforce authentication
• OAuth 2.0 authentication
• Kerberos authentication
• Certificate authentication
• JWT authentication

여러 방식을 동시에 설정할 수 있고, 코디네이터는 인입 연결마다 협상합니다.

인가(Authorization, 액세스 컨트롤)

• System access control — 플러그 가능한 상위 레이어. 아래의 것들은 그 구현체입니다.
• File-based access control — JSON 규칙으로 카탈로그/스키마/테이블 권한 정의.
• Open Policy Agent(OPA) access control — 정책 결정을 OPA로 외부화.
• Ranger access control — Apache Ranger 통합으로 fine-grained 정책.

전송과 내부 통신

• TLS와 HTTPS — 클라이언트 측 포트 암호화.
• Secure internal communication — 코디네이터와 워커 사이의 통신 암호화. 초기 배포에서 자주 누락되는 중요한 강화 단계입니다.
• 인증서 자료를 위한 PEM과 JKS 지원.

ID

• User mapping과 Group mapping — 인증된 주체(X.509 DN, JWT 클레임, Kerberos 프린시펄)를 Trino 사용자명과 그룹으로 변환.

시크릿

• Secrets 관리 — 자격 증명이 평문 카탈로그 프로퍼티 파일에 그대로 들어가지 않도록 합니다.

대부분의 엔터프라이즈 배포에서 현실적인 조합은 다음과 같습니다. 사용자에게는 OAuth2 또는 LDAP, 서비스 계정에는 mTLS 또는 JWT, 정책은 OPA 또는 Ranger, 그리고 내부 통신을 포함한 모든 경로에 TLS.

---

8. 운영과 관측성

Trino는 의외로 잘 갖춰진 운영 도구 세트를 가지고 있습니다.

• Web UI — 쿼리 이력, 진행 중인 쿼리 검사, 스테이지/태스크 드릴다운.
• Preview Web UI — 더 인터랙티브한 신형 오퍼레이터 콘솔.
• 로깅 — 구성 요소별 구조화된 로그.
• JMX 기반 모니터링 — 모든 내부 컴포넌트가 메트릭을 노출.
• OpenTelemetry 기반 관측성 — 분산 쿼리 실행에 대한 트레이스와 메트릭.
• OpenMetrics를 통한 Trino 메트릭 — Prometheus 스타일의 스크레이프 엔드포인트.
• Spill to disk — 큰 집계와 조인이 OOM 대신 디스크로 흘러갈 수 있습니다.
• Resource Group — 사용자/소스/그룹별 큐 정책과 자원 쿼터.
• Session Property Manager — 룰 기반으로 연결마다 세션 속성을 적용.
• 분산 정렬(Distributed Sort) — 큰 ORDER BY를 워커 전체로 병렬화.
• Graceful Shutdown — 진행 중인 쿼리를 죽이지 않고 워커를 drain. 오토스케일러가 필요로 하는 기반입니다.
• Event Listener — 쿼리 이벤트를 HTTP 엔드포인트, Kafka, MySQL, OpenLineage로 전달하는 플러그 가능한 훅.

Resource Group + Graceful Shutdown + OpenTelemetry/OpenMetrics의 조합이, Trino를 "개발자 친화적인 엔진"이 아니라 멀티 테넌트 운영 환경에서 굴릴 수 있는 엔진으로 만들어 줍니다.

---

9. 배포와 클라이언트

Trino는 배포 측면에서 의도적으로 단순합니다. 코디네이터 프로세스와 N개의 워커 프로세스로 구성된 JVM 애플리케이션입니다.

문서가 제공하는 배포 경로:

• Deploying Trino — 수동 설치.
• Trino in a Docker container — 공식 이미지.
• Trino on Kubernetes with Helm — 공식 차트.
• Plugins — 드롭인 확장 모델.
• Improve query processing resilience — 운영 튜닝 가이드.

클라이언트:

• Client protocol — 모든 클라이언트가 사용하는 HTTP 기반 REST 프로토콜.
• Command line interface(trino CLI).
• JDBC 드라이버 — BI 도구, IDE, JVM 애플리케이션용.

클라이언트 프로토콜이 평범한 HTTP이므로 Python(trino-python-client), Go, Node 등 다양한 언어 바인딩이 쉽게 만들어지고 널리 사용됩니다.

---

10. 확장성 — SPI

Trino는 Service Provider Interface(SPI) 위에 설계되었습니다. Developer Guide 챕터들이 확장할 수 있는 표면을 정리합니다.

• Connector — SPI를 구현해 새 데이터 소스를 카탈로그로 노출.
• Type / Function — 사용자 정의 타입과 SQL 함수 등록.
• Authenticator / Access Provider — 커스텀 인증·인가 플러그인.
• Event Listener — 감사, 리니지, 빌링용 쿼리 시작/종료 이벤트 수신.
• Client용 REST API — 공식 프로토콜 위에 자체 클라이언트 구현.

Trino에서 제공되는 모든 주요 데이터 소스가 곧 SPI 구현체이기 때문에, 커넥터 카탈로그가 지금처럼 성장할 수 있었고, 상용 배포판도 엔진을 포크하지 않고 추가 커넥터를 얹을 수 있는 것입니다.

---

11. 한눈에 보는 기능 맵

---

12. Trino가 잘 맞는 곳, 맞지 않는 곳

Trino의 강점은 몇 가지 패턴에 모입니다.

• 레이크하우스 SQL — 오브젝트 스토리지 위의 Iceberg / Delta / Hive를, 옵티마이저와 dynamic filtering이 무겁게 받쳐 줍니다. Trino가 가장 잘하는 영역입니다.
• 페더레이션 분석 — Iceberg의 팩트 테이블과 PostgreSQL의 dimension 테이블을 조인하거나, Snowflake의 CRM 테이블과 Kafka의 이벤트 데이터를 합치는 시나리오.
• 인터랙티브 분석과 BI — BI 도구에서 1분 미만의 동시성 쿼리.
• ETL / 배치 — Fault-tolerant Execution과 TASK 정책을 켜면 Trino도 배치 엔진의 역할을 할 수 있습니다.

의도적으로 맞지 않는 패턴:

• OLTP — 밀리초 예산의 포인트 읽기/쓰기, 로우 단위 트랜잭션 보장. 진짜 OLTP 데이터베이스를 쓰세요.
• 사용자 대면 앱을 받쳐 주는 운영 마이크로서비스 — 같은 이유입니다.
• 페더레이션이 필요 없는 단일 소스 워크로드 — Trino를 써도 되지만, 그 소스의 네이티브 엔진이 더 잘 맞을 수 있습니다.

---

13. 요약

• Trino는 분산 SQL 쿼리 엔진이지 데이터베이스가 아닙니다. 데이터가 있는 곳에서 커넥터를 통해 쿼리합니다.
• 코디네이터 + 워커 + 스플릿 + 태스크 + Exchange 모델이 확장의 근거입니다. 느린 쿼리를 디버깅할 때 스테이지 분해도를 읽을 수 있어야 합니다.
• 페더레이션이 헤드라인 기능입니다. 다수의 소스 위에 단일 SQL을 두고, 옵티마이저가 가능한 한 많은 일을 소스로 푸시다운합니다.
• 옵티마이저(CBO, pushdown, dynamic filtering, adaptive plan)가 Trino의 실 성능을 만듭니다. 통계가 중요합니다 — ANALYZE를 잊지 마세요.
• Fault-tolerant Execution은 Trino를 인터랙티브를 넘어 실용적인 배치 / ETL 엔진으로도 만들어 줍니다.
• 보안, 관측성, 운영 도구가 1급 시민입니다. Trino는 연구 프로젝트가 아니라 운영 엔진입니다.
• 모든 것이 SPI로 확장 가능합니다. 그래서 커넥터 생태계가 계속 자라고, 상용 배포판이 엔진을 포크하지 않고 그 위에서 만들어집니다.

오늘 레이크하우스나 페더레이션 분석 워크로드용 SQL 엔진을 고른다면, Trino가 기본 답인 데에는 이유가 있습니다. 도입한 다음의 일은 잘 운영하는 것이며, 위에서 정리한 기능 표면이 어디에 투자할지를 알려주는 지도입니다.

— Data Dynamics 팀