Hive나 Impala로 데이터 플랫폼을 운영하다가 Trino 전환을 검토하는 팀이 늘고 있습니다. 이 글은 그 검토에 필요한 세 가지를 한 페이지에 모았습니다.

1. Hive/Impala에서 Trino로 갈 때 실제로 무엇이 좋아지는지
2. 오픈소스 Trino와 상용 Starburst의 기능 비교 (엔진은 같고, 무엇이 더 얹히는지)
3. 성능·비용 벤치마크 — Hive 대비, 그리고 클라우드 웨어하우스 대비

핵심 전제부터 짚고 갑니다. Trino는 Hive·Impala의 "더 빠른 대체 엔진"에 그치지 않습니다. Compute와 Storage를 분리하고, 하나의 ANSI SQL로 여러 소스를 질의하며, Iceberg 같은 개방형 표준 위에서 동작하는 — 스택 현대화의 진입점입니다. 그리고 그 Trino 위에 성능·거버넌스·운영·보안 레이어를 얹은 상용 배포판이 Starburst입니다.

이 글에서 배우는 것

• Hive/Impala → Trino 전환 시 SQL·메타데이터·아키텍처·성능이 어떻게 달라지는지
• Hive+HDFS·Impala+HDFS·Trino+MinIO의 파일 읽기 절차·복잡도와 4개 엔진 종합 비교
• 디렉터리 파티셔닝의 한계와 Iceberg 히든 파티셔닝·파티션 진화가 만드는 차이
• 빅뱅 없이 진행하는 4단계 점진 전환 로드맵과 정직한 트레이드오프
• 오픈소스 Trino와 Starburst(SEP)의 기능 매트릭스와 고객 프로파일별 권장 선택
• Hive 대비·클라우드 웨어하우스 대비 성능·비용 벤치마크

---

Part 1. Hive/Impala에서 Trino로 — 무엇이 좋아지는가

1.1 지금 겪는 고통부터

Trino 전환을 고민한다면 대개 아래 고통을 이미 겪고 있습니다.

• Impala 메타데이터 관리 — 새 데이터가 들어올 때마다 INVALIDATE METADATA / REFRESH, catalogd·statestore 운영 부담.
• Hive의 느린 배치와 튜닝 — LLAP 튜닝, 스몰파일 누적, 스키마 변경의 취약함.
• Compute-Storage 강결합 — HDFS에 Compute가 묶여 있어, 쿼리 부하만 늘려도 Storage 노드까지 함께 증설해야 하는 경직된 확장.
• HDFS 3 Copy Replica 비용 — 저장 용량이 곧 3배로 소모되는 스토리지 오버헤드.
• 사일로와 데이터 이동 — 소스마다 따로 질의하고, 조인하려면 ETL로 미리 옮겨야 하는 구조.

Trino 전환은 "엔진 하나 교체"가 아니라 이 고통들의 구조적 원인을 바꾸는 일입니다.

1.2 전환 후 좋아지는 점 — Before / After

1.3 특히 크게 체감하는 두 가지

① 메타데이터에서 해방된다. Impala 사용자가 가장 먼저 체감하는 변화입니다. INVALIDATE METADATA/REFRESH로 catalog 상태를 손으로 맞추던 작업이, Iceberg 스냅샷 기반에서는 대부분 사라집니다. SQL dialect, 통계, 인증·인가까지 실제로 무엇이 달라지는지는 Impala에서 Trino로 마이그레이션 가이드에서 항목별로 다룹니다.

② 스토리지 접근 경로 자체가 빠르다. "매체가 빨라서"가 아니라 접근 경로의 구조가 다릅니다. 같은 플래시·같은 네트워크·같은 Iceberg인데도 Trino+오브젝트 스토리지가 Impala+HDFS보다 빠른 이유를 HDFS보다 MinIO가 빠른 진짜 이유에서 7가지로 분해합니다.

여기에 더해 페더레이션(여러 소스를 한 SQL로 조인)과 아키텍처 단순화(코디네이터+워커)는 각각 Trino 페더레이션 실전과 Trino의 주요 기능 정리에서 자세히 확인할 수 있습니다.

1.4 파티션의 벽 — 디렉터리 파티셔닝 vs Iceberg 히든 파티셔닝

Hive·Impala로 대형 테이블을 오래 운영한 팀이 공통으로 부딪히는 벽이 파티션입니다. 두 엔진의 파티션은 곧 HDFS 디렉터리 구조(year=2026/month=07/day=03/…)라, 파티션 설계가 물리 레이아웃에 그대로 못박힙니다. 여기서 세 가지 구조적 한계가 나옵니다.

• 명시적 파티션 컬럼에 종속 — 쿼리가 파티션 컬럼을 그대로 걸어야만 프루닝됩니다. WHERE order_ts = '2026-07-03'처럼 원본 타임스탬프로 걸면 year/month/day 파티션과 매칭되지 않아 풀스캔으로 떨어집니다. 그래서 파티션 파생 컬럼을 따로 만들어 채워 넣는 우회가 관행이 됩니다.
• 카디널리티 폭발 → 스몰파일·메타데이터 병목 — 파티션 컬럼 카디널리티가 높으면 디렉터리와 스몰파일이 수백만 개로 불어나 NameNode에 부담을 줍니다. 게다가 파티션은 HMS(RDBMS)에 행으로, Impala는 catalogd 메모리 캐시에 통째로 올라가므로, 파티션이 많아질수록 플래닝 시 파티션 나열이 느려지고 INVALIDATE METADATA/REFRESH 비용이 커집니다.
• 레이아웃 고정 → 재파티셔닝은 전체 재작성 — 나중에 파티션 전략을 바꾸려면(예: 일 단위 → 시간 단위) 테이블을 통째로 다시 써야 합니다. MSCK REPAIR TABLE, 동적 파티션 인서트의 메모리·파일 폭증도 여기서 옵니다.

결국 과도 파티셔닝(메타데이터 오버헤드)과 과소 파티셔닝(프루닝 실패) 사이의 줄타기가 되고, 한번 잘못 잡으면 되돌리는 비용이 큽니다.

Trino + Iceberg는 이 결합을 끊습니다.

• 히든 파티셔닝 — 파티션을 디렉터리가 아니라 컬럼에 대한 transform(day(order_ts)·bucket(16, user_id)·truncate)으로 정의합니다. 사용자는 파티션 컬럼을 몰라도 되고, 원본 컬럼으로 필터만 걸면 엔진이 알아서 프루닝합니다. 불일치로 인한 풀스캔·파생 컬럼 관리가 사라집니다.
• 파티션 진화 — 데이터를 재작성하지 않고 파티션 스펙을 바꿉니다. 옛 데이터는 옛 스펙, 새 데이터는 새 스펙으로 둔 채 한 쿼리가 두 스펙을 투명하게 프루닝합니다.
• 매니페스트 기반 파일 단위 프루닝 — 파티션·파일 통계(min/max)가 오브젝트 스토리지의 매니페스트 파일에 있어, 단일 RDBMS 병목 없이 수백만 파일로 확장되고 파티션이 아니라 파일 단위로 걸러냅니다.

두 방식의 차이를 개념도로 보면 이렇습니다.

그리고 SEP는 여기서 한 발 더 나갑니다. 히든 파티셔닝·파티션 진화는 OSS Trino + Iceberg의 공통 이점입니다. 다만 파티션 설계가 좋아져도 스몰파일 누적·스냅샷 증가·통계 노후화라는 운영 숙제는 남습니다. SEP는 자동 테이블 유지관리로 optimize(컴팩션)·expire_snapshots(스냅샷 만료)·remove_orphan_files(오펀 파일 정리)·통계 수집을 스케줄 기반으로 자동 실행하고, 그 위에 Warp Speed(스마트 인덱싱·캐싱)로 파티션 프루닝 이후에도 파일·로우그룹 단위까지 스캔을 더 줄입니다(→ 3.3·3.4). 즉 파티션의 벽 자체는 Iceberg가, 파티션 이후의 운영·가속은 SEP가 메웁니다.

1.5 파일 읽기 절차와 복잡도 — Hive+HDFS · Impala+HDFS · Trino+MinIO

같은 "파일을 읽어 SQL로 답한다"라도 아키텍처마다 거치는 단계와 복잡도가 다릅니다. 세 구조의 읽기 경로를 나란히 보면 다음과 같습니다.

• Hive + HDFS — 쿼리를 MR/Tez 잡으로 컴파일해 YARN에 올리므로 잡 기동(콜드 스타트) 오버헤드가 큽니다. HMS·NameNode·DataNode를 거치는 다단계 경로라 대형 배치엔 견고하지만 인터랙티브 쿼리엔 느립니다.
• Impala + HDFS — 상시 떠 있는 MPP 데몬(impalad)이 YARN 없이 즉시 실행해 지연이 낮습니다. 대신 메타데이터를 수동(INVALIDATE/REFRESH)으로 맞춰야 하고 HDFS(NameNode·DataNode)에 강하게 묶입니다.
• Trino + MinIO(S3) — 상시 워커가 즉시 실행하고, 메타데이터는 Iceberg 매니페스트로 파일 단위 프루닝까지 합니다. NameNode가 없고 데이터는 S3 API로 원격 병렬 읽기합니다. 데이터 로컬리티가 없는 대신 대규모 병렬·range read·(SEP면 Warp Speed 로컬 SSD 캐시)로 상쇄합니다.

정리하면 Hive는 잡 실행 오버헤드, Impala는 HDFS 강결합·수동 메타데이터가 복잡도의 핵심입니다. Trino+MinIO는 NameNode를 없애고 Compute·Storage를 분리해 운영 경로가 단순해지며, 유일한 약점인 원격 IO는 파일 프루닝과 캐시(Warp Speed)로 메웁니다. 접근 경로가 왜 더 빠른지는 HDFS보다 MinIO가 빠른 진짜 이유에서 더 깊게 다룹니다.

1.6 Hive · Impala · Trino · SEP 종합 기능 비교

위 세 구조에 상용 SEP까지 더해, 네 엔진을 항목별로 요약하면 다음과 같습니다. (Trino와 SEP의 세부 차이는 Part 2에서 카테고리별로 더 깊게 다룹니다.)

한 줄로 요약하면 Hive=배치 견고성, Impala=HDFS 위 저지연 MPP, Trino=개방형 페더레이션 엔진, SEP=그 Trino에 보안·거버넌스·성능·지원을 더한 상용 플랫폼입니다.

1.7 빅뱅 없는 4단계 점진 전환

Trino의 가장 큰 실무적 장점은 기존 Hive 데이터를 그대로 질의할 수 있어 한 번에 갈아엎지 않아도 된다는 점입니다. 아래는 기존 Hive/Impala + HDFS 클러스터에서 신규 Trino + MinIO(S3) 클러스터로 데이터를 옮기는 구성도입니다.

• ① 데이터 복사 — HDFS의 Parquet/ORC 파일을 DistCp(HDFS→S3A)나 s5cmd·aws s3 sync로 MinIO 버킷에 복사합니다. 초기에는 원본 포맷 그대로 옮겨 즉시 질의하고, 이후 Iceberg로 재작성합니다.
• ② 메타데이터 이관 — 기존 스키마를 Trino의 카탈로그에 등록합니다. Hive Metastore를 그대로 재사용하거나, Iceberg REST Catalog로 옮기고 CREATE TABLE ... AS SELECT / migrate 프로시저로 Iceberg 테이블로 변환합니다.
• ③ 병행 운영 — 두 클러스터를 일정 기간 함께 돌리며 결과를 검증한 뒤, 기존 Hive/Impala를 단계적으로 폐기합니다.

구체적으로는 아래 4단계로 진행합니다.

1. 병행(Coexist) — 기존 Hive 메타스토어에 Trino를 연결해 읽기부터 시작. 데이터 이동 0.
2. 오프로드(Offload) — 무거운 애드혹/BI 쿼리를 Trino로 이관해 즉시 성능을 체감.
3. 현대화(Modernize) — 핵심 테이블을 Iceberg로 전환해 메타데이터·성능 이득을 극대화.
4. 정착(Consolidate) — Hive/Impala 비중을 줄이고 보안·거버넌스·오토스케일을 정착.

각 단계마다 성공 기준(KPI)과 롤백 포인트를 정해두면, 리스크를 통제하며 옮길 수 있습니다.

1.8 정직한 트레이드오프

세일즈가 아니라 판단을 돕는 자료이니 불리한 점도 먼저 짚습니다.

• SQL dialect 재작성 — HiveQL/Impala 전용 함수·DDL은 ANSI SQL로 손봐야 하는 구간이 있습니다.
• 초저지연 단건 조회 — 매우 짧은 포인트 쿼리처럼 Impala가 유리한 워크로드도 존재합니다. 워크로드별로 검증하세요.
• 보안·카탈로그 재설계 — Ranger/파일 기반 인가, 카탈로그 구성을 다시 설계해야 합니다.
• 운영팀 학습 곡선 — 새로운 튜닝·모니터링 감각이 필요합니다.

각 항목은 호환성 검증 단계와 병행 운영 기간으로 완화할 수 있고, 그래서 1.7의 점진 로드맵이 중요합니다.

---

Part 2. Trino vs Starburst — 기능 비교

Trino로 자리를 잡고 나면 자연스럽게 다음 질문이 옵니다. "오픈소스 Trino로 충분한가, 상용 Starburst가 필요한가?" 엔진은 같습니다. Starburst는 Trino를 대체하는 것이 아니라 그 위에 성능·거버넌스·운영·보안·AI 레이어를 얹은 상용 배포판이며, 2024년 Trino 코드 커밋의 약 84%를 담당하는 최대 Trino 전문가 조직입니다. 아래 표에서 "제공"은 기본 지원, "직접 관리/구현"은 오픈소스에서 스스로 구축·운영해야 함을 뜻합니다. (수치·항목 출처: Starburst 공식 — Starburst vs Trino)

2.1 성능 (Performance)

두 제품 모두 페타바이트 규모의 분산 쿼리라는 기본기는 동일합니다. 차이는 자주 쓰는 테이블을 얼마나 손쉽게 빠르게 만드느냐에 있습니다. 각 항목의 의미를 하나씩 보면 다음과 같습니다.

• 페타바이트 규모 쿼리 — 둘 다 제공. 코디네이터-워커 구조로 데이터를 수많은 스플릿으로 나눠 병렬 처리하는 Trino 엔진의 기본 역량입니다. 엔진이 동일하므로 순수 대규모 분산 쿼리 성능은 차이가 없습니다.
• 스마트 인덱싱·캐싱(Warp Speed) — Trino는 부분, Starburst는 제공. 오브젝트 스토리지(Hive·Iceberg·Delta) 위에 인덱스·캐시 레이어를 자동으로 얹어 원격 IO를 줄이고 쿼리를 가속하는 기능입니다. Trino에도 기본 파일시스템 캐시나 dynamic filtering은 있지만, 블록별 자동 인덱싱(bitmap·dictionary·tree)과 자율 캐싱은 Starburst 전용입니다. 동작 원리는 아래 3.4 Warp Speed는 어떻게 동작하고, 왜 빨라지는가에서 자세히 다룹니다.
• 강화된 내결함 실행(최대 60TB) — Starburst만 제공. 내결함 실행(FTE)은 쿼리 중 워커가 죽어도 중간 결과를 스풀에 저장했다가 재시도해 대형 배치·ETL이 통째로 실패하지 않게 합니다. Trino에도 FTE가 있지만, Starburst는 수십 TB(최대 60TB) 규모까지 엔터프라이즈급으로 하드닝·검증하고 SLA로 지원합니다.
• Iceberg 자동 데이터 최적화 — Starburst만 제공. Iceberg 테이블은 쓰기가 쌓이면 작은 파일이 늘고 스냅샷·매니페스트가 비대해져 느려집니다. compaction(작은 파일 병합), 스냅샷 만료, 고아 파일 정리 같은 유지보수를 Starburst는 자동으로 돌립니다. Trino에서도 OPTIMIZE·expire_snapshots 등을 수동/스케줄로 실행할 수 있지만 직접 운영해야 합니다.
• 스트리밍 인제스트·파일 로더 — Starburst만 제공. Kafka 등에서 들어오는 데이터를 Iceberg 테이블로 연속 적재하거나 파일을 대량 로드하는 관리형 파이프라인입니다. 순수 쿼리 엔진인 Trino에는 없어, 보통 별도 인제스트 도구(Spark, Flink, NiFi 등)를 붙여야 합니다.

요약하면 오픈소스 Trino에서도 내결함 실행(fault-tolerant execution)과 테이블 최적화는 가능하지만, 튜닝과 운영을 직접 책임져야 합니다. Starburst는 이 성능 작업들을 관리형·자동화로 제공한다는 것이 이 카테고리의 핵심 차이입니다.

2.2 확장성·운영 (Scalability & Operations)

리소스 그룹을 통한 워크로드 격리는 오픈소스에서도 되지만, 비용과 직결되는 운영 자동화(오토스케일링, 유휴 자동 종료, 자동 일시중지)는 Starburst가 관리형으로 제공합니다. 24/7 전문가 지원 역시 오픈소스에는 없는 상용의 핵심 가치입니다.

2.3 데이터 탐색·관측성 (Data Discovery & Observability)

이 카테고리는 순수 쿼리 엔진인 Trino와 데이터 플랫폼을 지향하는 Starburst의 차이가 가장 크게 드러나는 영역입니다. 데이터 프로덕트, 리니지, 품질 규칙, 자동 분류는 모두 거버넌스·디스커버리 레이어로, 오픈소스 Trino에는 존재하지 않아 별도 도구(카탈로그, 데이터 옵저버빌리티 솔루션)를 붙여야 합니다.

2.4 보안·접근 제어 (Security & Access Control)

인증(Kerberos)은 양쪽 다 되지만, 세밀한 인가에서 갈립니다. Trino에서도 RBAC/ABAC를 파일 기반이나 Ranger 연동으로 구성할 수 있으나 정책을 직접 작성·관리해야 합니다. Starburst는 이를 UI 기반으로 자동화하고, 컬럼 마스킹·로우 레벨 필터링·종단 간 암호화 관리를 기본 제공합니다. 규제 산업(금융·의료·공공)에서 특히 무게가 실리는 항목입니다.

2.5 AI 기능 (AI Capabilities)

AI 관련 기능은 Starburst에서도 아직 프라이빗 프리뷰 단계로, 즉시 프로덕션에 쓸 수 있는 성숙 기능이라기보다 로드맵 신호에 가깝습니다. SQL에서 직접 호출하는 LLM 함수, 벡터 검색, 모델 거버넌스를 엔진 레벨에서 묶으려는 방향성입니다. 오픈소스 Trino에서도 UDF/커넥터로 유사 구성이 가능하나 통합·거버넌스는 직접 책임져야 합니다.

2.6 Starburst가 강조하는 차별점

공식 페이지는 표 외에도 다음을 근거로 상용의 가치를 설명합니다.

• Trino 전문성 — 2024년 Trino 코드 커밋의 약 84%를 Starburst가 기여. 사실상 Trino를 가장 잘 아는 조직.
• 검증된 성과(고객 사례)
  • El Toro — 쿼리 성능 300% 향상
  • Talkdesk — 에러율 150배 감소
  • Kovi — 애드혹 쿼리 85% 단축
• 엔터프라이즈 초점 — 24/7 지원, 강화된 안정성, 관리형 서비스 등 오픈소스 Trino가 제공하지 않는 프로덕션급 요소.

물론 이 수치는 Starburst의 자사 마케팅 자료이므로, 우리 워크로드에서의 실제 이득은 PoC로 직접 검증하는 것이 원칙입니다. 보안(BIAC·Ranger), 전용 커넥터, Warp Speed, Insights, 배포·지원 모델까지 더 깊은 기술 비교는 Trino vs Starburst Enterprise (SEP) 비교 글에서 카테고리별로 다룹니다.

2.7 OSS Trino vs SEP — 상세 기능 매트릭스

앞의 5개 카테고리가 Galaxy를 포함한 상용 전반의 그림이라면, 아래는 자체 배포 관점에서 OSS Trino와 Starburst Enterprise Platform(SEP) 을 항목별로 비교한 매트릭스입니다. SEP는 OSS Trino 위에 보안·거버넌스·성능·지원·데이터 제품 기능을 더한 인증 배포판입니다.

정리하면 엔진의 최신성·개방성·비용은 OSS Trino, 보안·거버넌스·데이터 제품·지원 SLA는 SEP가 우위입니다.

2.8 고객 프로파일별 권장 선택

2.9 최종 요약 — 언제 무엇을 선택할까

OSS Trino를 선택해야 할 때 — 완전한 제어권, 라이선스 비용 없음

• 강력한 내부 플랫폼 엔지니어링 팀 보유
• 비용 최적화가 최우선 과제
• 엔터프라이즈 거버넌스 의무사항 없음
• 커뮤니티 속도의 지원으로 충분
• 최신 기능을 가장 빠르게 도입하고 싶을 때

SEP를 선택해야 할 때 — 엔터프라이즈 기능 + SLA 기반 지원

• Cloudera CDP 또는 유사 플랫폼 교체 시
• 보안·거버넌스·감사 요건 존재
• 데이터 제품/데이터 메시 아키텍처 구축 시
• 24×7 엔터프라이즈 SLA 지원 필요
• 완전 관리형(Galaxy) 배포 옵션을 원할 때

---

Part 3. 성능·비용 벤치마크

Starburst가 공개한 벤치마크 자료 두 건을 차트로 정리했습니다. 둘 다 Starburst 자사 벤치마크이므로 절대 수치보다는 상대적 경향으로 읽는 것이 안전합니다.

3.1 Hive 대비 — Trino는 Iceberg의 결정적 SQL 엔진

Hive/Impala 전환을 검토하는 팀에 가장 직접적인 근거입니다. 같은 데이터를 Hive 엔진과 Starburst Enterprise(=엔터프라이즈 Trino)로 각각 실행한 벤치마크로, Iceberg 테이블에서 TPC-H 12배 · TPC-DS 22배, Hive 테이블에서도 TPC-H 8배 · TPC-DS 6배 빠릅니다. 즉 지금 당장 엔진만 Trino로 바꿔도 이득을 보고, 이후 Iceberg로 이관하면 이득이 더 커진다는 논리입니다(= Part 1.7의 점진 전환).

테스트 조건: 1TB 원본 데이터(S3, Parquet), TPC-H 클러스터 9노드 / TPC-DS 클러스터 17노드(각 32 vCPU·128GB), Starburst 476-e vs Hive 3.1.3, Apache JMeter 4회 순차 루프. 출처: Concurrency Labs 벤치마크 리포트(2025-09).

가장 극적인 항목은 TPC-DS · Iceberg로, Hive의 37,901초(약 10.5시간)가 Trino에서는 1,737초(약 29분)로 줄어듭니다. 대규모 분석 워크로드일수록 격차가 벌어지는 경향을 보여줍니다.

3.2 클라우드 데이터 웨어하우스 대비 — 가격과 성능

Starburst Galaxy는 오픈 테이블 포맷에서 SQL을 실행할 때 최대 6.3배 빠른 쿼리와 최대 12.7배의 비용 절감을 주장합니다. 아래는 주요 클라우드 웨어하우스와의 Runtime·Cost 비교로, 낮을수록 좋습니다.

테스트 조건: TPC-DS sf1000, 동시성 5, 모든 벤더 Iceberg 테이블(단 Databricks는 Delta Lake), 2024-06-26 기준. 표의 Runtime·Cost 값은 원본 차트에서 읽은 근사치입니다.

Starburst Galaxy 하나만 놓고 보면 Runtime과 Cost가 둘 다 최하위권입니다. Databricks SQL Serverless가 Runtime은 근소하게 빠르지만, 비용까지 함께 보면 Galaxy가 가장 균형 잡힌 조합이라는 것이 이 차트의 메시지입니다.

3.3 OSS Trino 대비 SEP — Warp Speed 효과

"OSS Trino와 Starburst Enterprise(SEP)를 직접 붙이면 얼마나 빠른가?"는 사실 애매한 질문입니다. 엔진이 같아서 가속 기능을 끄면 숫자가 동일하기 때문입니다. 따라서 의미 있는 성능 차이는 곧 SEP 전용 가속 기능의 효과이고, 그 핵심이 오브젝트 스토리지(Hive·Iceberg·Delta) 위에서 스마트 인덱싱·캐싱을 자동 적용하는 Warp Speed입니다. 아래 차트의 기준선인 "표준 실행 모드"는 Warp Speed를 끈 상태 — 사실상 OSS Trino 엔진과 동일한 실행이므로, 이 값이 "OSS Trino → SEP(Warp Speed)"에 가장 근접한 비교입니다.

이 밖에 Starburst가 공개한 Warp Speed 수치는 다음과 같습니다.

모두 Starburst 자사 벤치마크이며, 이득은 워크로드 성격에 크게 좌우됩니다. Warp Speed는 오브젝트 스토리지 + 반복적·선택적(selective) 조회에서 효과가 크고, 이미 파티션이 잘 잡힌 대형 스캔형 쿼리에서는 이득이 작을 수 있습니다. 출처: Starburst Warp Speed 문서, Announcing Warp Speed in Starburst Galaxy.

정리하면, 순수 엔진 성능은 OSS Trino와 SEP가 동일하고, SEP의 성능 우위는 거의 전적으로 Warp Speed 같은 가속 레이어에서 나옵니다. 우리 워크로드가 여기에 해당하는지는 PoC로 직접 검증하는 것이 원칙입니다.

3.4 Warp Speed는 어떻게 동작하고, 왜 빨라지는가

Warp Speed는 Hive·Iceberg·Delta 커넥터 위에 투명하게 얹히는 인덱싱·캐싱 레이어입니다. 쿼리 패턴을 보고 자율적으로 인덱스와 캐시를 만들고 유지하며, 데이터 엔지니어가 인덱스를 손으로 설계할 필요가 없습니다.

동작 원리

• 블록 단위 스마트 인덱싱 — 데이터를 블록으로 나눈 뒤 블록별로 가장 효과적인 인덱스 타입(bitmap · dictionary · tree)을 자동 선택해 생성합니다. 조인·필터·검색을 가속합니다.
• 자율 캐싱 — 자주 접근하는 데이터를 캐시하고, 워크로드 빈도·우선순위에 따라 캐시를 동적으로 갱신합니다.
• 3단계 스토리지 계층 — Hot(각 워커에 붙은 NVMe SSD, 기본 활성) → Warm(모든 워커가 공유하는 전용 오브젝트 스토리지 버킷, 스케일업 시 재인덱싱 최소화·복원력 확보) → Cold(원본 S3/MinIO).
• 머티리얼라이제이션 흐름 — 처음 접근하는 데이터는 SSD에 없으므로 원격 오브젝트 스토리지에서 읽어 응답하고, 인덱스·캐시는 비동기로 생성합니다. 이후 같은 데이터는 원격 스토리지 대신 로컬 인덱스·캐시에서 바로 서빙됩니다.

왜 빨라지는가

1. 원격 IO 제거(데이터 로컬리티) — 스플릿을 원격 S3/MinIO가 아니라 워커의 로컬 NVMe SSD에서 읽습니다. 데이터 레이크 쿼리에서 가장 큰 병목인 네트워크 왕복·원격 IO 지연이 사라집니다 → Wall-clock time(체감 실행 시간, 쿼리 시작부터 결과까지의 실제 경과 시간)이 크게 감소(3.3의 약 5배).
2. 인덱스 기반 블록 프루닝 — bitmap/dictionary/tree 인덱스로 조건에 맞지 않는 블록·행을 건너뜁니다. 풀스캔을 피하고 읽고 처리하는 데이터 자체가 줄어 CPU 작업이 급감합니다 → CPU 시간이 더 크게 감소(3.3의 약 10배).
3. 반복·인터랙티브 캐시 히트 — BI 대시보드·드릴다운처럼 유사 쿼리가 반복되면 캐시에 적중해 일관된 저지연과 높은 동시성을 냅니다.
4. 워크로드 적응 — 실제 쿼리 패턴을 따라 핫 데이터가 자동으로 최적화되어, 수동 튜닝 없이 이득이 유지됩니다.

즉 3.3에서 본 "CPU 10배 · 시간 5배"의 비대칭은 우연이 아닙니다. 인덱스 프루닝이 처리할 일 자체를 줄여 CPU를, 로컬 SSD가 원격 IO를 없애 Wall-clock time(체감 실행 시간)을 각각 줄이기 때문입니다.

한계와 전제

• 콜드(첫 접근) 쿼리는 아직 이득이 없습니다. 워밍업이 비동기라, 처음 도는 쿼리는 원격 스토리지 속도 그대로입니다.
• 이미 파티션이 잘 잡힌 대형 풀스캔은 인덱스 프루닝 여지가 작아 이득이 제한적입니다.
• SSD 용량·워밍업 오버헤드를 고려해야 합니다. 선택적(selective) 필터가 많은 반복 워크로드일수록 효과가 큽니다.

---

Part 4. 정리 — 어떻게 판단할까

• Hive/Impala → Trino — SQL 표준화, 메타데이터 해방, Compute·Storage 분리, 페더레이션, 대규모 분석 성능까지 구조적으로 좋아집니다. 무엇보다 기존 Hive 데이터를 그대로 질의할 수 있어 빅뱅 없이 점진 전환이 가능합니다. 첫걸음은 워크로드 인벤토리와 고객 데이터 기반 PoC입니다.
• Trino vs Starburst — 엔진 그 자체(SQL 시맨틱·옵티마이저·대규모 쿼리)는 차이가 없습니다. 엔지니어링 인력이 보안·오토스케일·거버넌스를 직접 운영할 수 있으면 오픈소스 Trino로 충분하고, 세밀한 보안·거버넌스·운영 자동화·24/7 지원 같은 엔진을 둘러싼 플랫폼에 값을 치를 준비가 됐다면 Starburst가 유리합니다.

Trino를 엔진으로, Starburst를 그 엔진을 둘러싼 관리형 플랫폼으로 보는 멘탈 모델이 정확합니다.

출처: Starburst 공식 — Starburst vs Trino, Concurrency Labs 벤치마크 리포트(2025-09). 기능 구성·프리뷰 상태·벤치마크 수치는 시점과 조건에 따라 달라질 수 있습니다.