Impala 에서 Trino 로 — Cloudera 사용자를 위한 마이그레이션 가이드

Cloudera 를 오래 써 온 조직이 Trino(또는 Starburst)로 분석 엔진을 옮기는 일이 부쩍 늘었습니다. 이유는 대체로 비슷합니다 — Iceberg 중심의 Lakehouse 로 가고 싶고, 오브젝트 스토리지와 외부 RDBMS·웨어하우스를 한 SQL 표면에서 다루고 싶다는 것입니다.

그런데 막상 옮기려고 하면 "Impala SQL 이 Trino 에서 그대로 돌아가나?", "INVALIDATE METADATA 는 어떻게 되나?", "통계는?", "LDAP 인증은?" 같은 현실적인 질문이 쏟아집니다. 이 글은 Impala 를 쓰던 팀이 Trino 로 넘어갈 때 실제로 부딪히는 차이를 항목별로 정리하고, 무리 없는 전환 전략을 제안합니다.

1. 먼저 멘탈 모델부터 — Impala 와 Trino 는 같은 종류가 아니다

둘 다 "MPP SQL 엔진"이라는 점은 같지만, 설계 철학이 다릅니다.

핵심 차이는 카탈로그 모델입니다. Impala 에서는 "데이터베이스.테이블" 두 단계였지만, Trino 는 카탈로그.스키마.테이블 세 단계입니다. hive, iceberg, postgresql 같은 카탈로그가 각각 독립적으로 붙고, 한 쿼리에서 이들을 조인할 수 있습니다.

-- Impala
SELECT * FROM analytics.events;
 
-- Trino (카탈로그가 앞에 붙는다)
SELECT * FROM iceberg.analytics.events;
 
-- Trino: 카탈로그를 넘나드는 페더레이션 조인
SELECT e.*, u.name
FROM iceberg.analytics.events e
JOIN postgresql.crm.users u ON e.user_id = u.id;

2. REFRESH / INVALIDATE METADATA 가 사라진다

Impala 운영자가 가장 많이 겪는 고통이 메타데이터 동기화입니다.

-- Impala: 외부 도구가 파일을 떨어뜨린 뒤 반드시 호출해야 했던 명령들
INVALIDATE METADATA analytics.events;   -- 새 테이블/대규모 변경
REFRESH analytics.events;               -- 새 파일 추가 시
REFRESH analytics.events PARTITION (dt='2026-06-05');
COMPUTE STATS analytics.events;         -- 통계 갱신

NiFi·Spark·Sqoop 가 새 파일을 쓰면 catalogd 캐시가 모르기 때문에, 호출을 빠뜨리면 쿼리에서 데이터가 안 보였습니다.

Trino + Iceberg 에서는 이 개념 자체가 없습니다. Iceberg 테이블의 "현재 상태"는 메타데이터 파일이 가리키는 스냅샷으로 정의되고, 커밋이 곧 가시성입니다. 새 데이터가 커밋되면 다음 쿼리에서 즉시 보입니다. INVALIDATE METADATA, REFRESH 에 해당하는 명령이 필요 없습니다.

Impala 의 메타데이터 모델은 "캐시를 사람이 관리"하는 것이었고, Iceberg 는 "테이블 포맷이 일관성을 보장"하는 것입니다. 이 한 가지만으로도 운영 부담이 크게 줄어듭니다.

단, Hive 커넥터로 (Iceberg 가 아닌) 전통적 Hive 테이블을 읽을 때는 메타데이터 캐싱(hive.metastore-cache-ttl)을 켰을 경우 TTL 만큼 지연이 있을 수 있습니다. 기본값은 캐시 비활성이라 매 쿼리 시 메타스토어를 조회합니다. 이 경우에도 캐시를 비우는 명령은 CALL system.flush_metadata_cache() 정도로 단순합니다.

3. SQL 차이 — 자주 걸리는 것들

Impala SQL 과 Trino SQL 은 둘 다 ANSI SQL 기반이라 70~80% 는 그대로 동작하지만, 타입·함수·DDL 에서 차이가 있습니다.

3.1 데이터 타입

타임스탬프가 가장 자주 문제됩니다. Impala 의 TIMESTAMP 는 타임존 정보가 없고 UTC 처리에 옵션이 얽혀 있었지만, Trino 는 TIMESTAMP(6) 과 TIMESTAMP(6) WITH TIME ZONE 을 명확히 구분합니다. Iceberg 테이블이라면 타임존 인식 타입을 쓰는 편이 안전합니다.

3.2 자주 쓰는 함수 매핑

date_add/date_sub 의 인자 순서와 단위 표기가 다른 점, nvl 이 coalesce 로 바뀌는 점이 마이그레이션 스크립트에서 가장 흔한 수정 포인트입니다.

3.3 DDL 차이

-- Impala: STORED AS, 디렉터리 기반 파티션
CREATE TABLE analytics.events (
  event_id BIGINT,
  user_id  BIGINT,
  ts       TIMESTAMP
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET;
 
-- Trino + Iceberg: WITH 절, hidden partitioning (transform)
CREATE TABLE iceberg.analytics.events (
  event_id BIGINT,
  user_id  BIGINT,
  ts       TIMESTAMP(6) WITH TIME ZONE
)
WITH (
  format = 'PARQUET',
  partitioning = ARRAY['days(ts)']
);

가장 큰 사고 방식 전환은 파티션입니다. Impala 는 dt STRING 같은 별도 파티션 컬럼을 스키마에 두고 INSERT/SELECT 마다 명시해야 했지만, Iceberg 는 days(ts) 같은 transform 으로 원본 컬럼에서 파티션을 자동 유도합니다. 사용자가 파티션 컬럼을 빠뜨려 풀스캔이 나는 문제 자체가 사라집니다. (이 주제는 별도 글 "Trino + Iceberg 는 파티션 문제를 어떻게 해결하는가"에서 자세히 다뤘습니다.)

3.4 INSERT / UPSERT

Impala 는 Kudu 가 아니면 UPDATE/DELETE 가 사실상 불가능했지만, Trino + Iceberg 는 행 단위 변경을 지원합니다.

-- Trino + Iceberg: MERGE 로 UPSERT
MERGE INTO iceberg.analytics.users AS t
USING staging.users_delta AS s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET name = s.name, updated_at = s.updated_at
WHEN NOT MATCHED THEN INSERT (id, name, updated_at) VALUES (s.id, s.name, s.updated_at);
 
-- DELETE / UPDATE 도 정상 동작
DELETE FROM iceberg.analytics.events WHERE ts < TIMESTAMP '2025-01-01 00:00:00 UTC';

4. 통계(Statistics) — COMPUTE STATS 의 대체

Impala 의 COMPUTE STATS 는 Trino 에서 ANALYZE 에 해당합니다.

-- Impala
COMPUTE STATS analytics.events;
COMPUTE INCREMENTAL STATS analytics.events PARTITION (dt='2026-06-05');
 
-- Trino
ANALYZE iceberg.analytics.events;
-- 특정 컬럼만
ANALYZE iceberg.analytics.events WITH (columns = ARRAY['user_id', 'event_type']);

차이점:

• Iceberg 테이블은 데이터 파일 수준 통계(min/max, null count, row count)를 manifest 에 항상 들고 있습니다. 즉 기본적인 프루닝은 ANALYZE 없이도 동작합니다.
• ANALYZE 는 추가로 NDV(distinct 값 추정) 같은 비용 기반 옵티마이저(CBO)용 통계를 채웁니다. 조인 순서 최적화 품질에 영향을 주므로, 큰 테이블은 정기적으로 돌려주는 것이 좋습니다.
• "incremental stats" 라는 개념은 없지만, 새로 쓰인 파일의 통계는 자동 반영되므로 운영 부담이 적습니다.

5. 인증·인가 — LDAP 은 그대로, Apache Ranger 는 다시 설계

Cloudera 환경의 보안 자산은 대부분 Trino 로 옮길 수 있습니다.

LDAP 인증은 Impala JDBC 에서 쓰던 사용자 디렉터리를 그대로 연결할 수 있어 전환이 수월합니다. 반면 Ranger 권한 정책은 그대로 이식되지 않으므로 다시 설계해야 합니다. Ranger 를 계속 쓴다면 Trino 용 Ranger 플러그인으로 정책을 옮기고, 정책을 단순화할 기회로 삼는 것이 좋습니다. (Trino 보안 상세는 별도 글에서 다룹니다.)

6. 운영 모델의 차이 — 메모리와 동시성

Impala 에서 가장 흔한 사고는 "큰 쿼리 하나가 메모리를 다 먹고 클러스터를 마비"시키는 것이었습니다(물론 Impala도 admission control을 사용하면 제어는 가능). Trino 는 이를 다르게 다룹니다.

• Spill-to-disk: Impala 도 일부 spill 을 지원하지만, Trino 는 조인·집계·정렬 전반에서 디스크로 흘릴 수 있어 OOM 으로 죽는 대신 느려지는 쪽을 택할 수 있습니다.
• Resource Groups: Impala 의 Admission Control(리소스 풀)에 대응합니다. 사용자/소스별로 동시성·메모리·큐 한도를 정의합니다.
• Fault-tolerant Execution(FTE): 장시간 ETL 배치에서 워커가 죽어도 태스크 단위로 재시도합니다. Impala 에는 없던 안전망입니다.

Impala Admission Control (리소스 풀)  ≈  Trino Resource Groups
Impala mem_limit (쿼리별)             ≈  Trino query.max-memory-per-node 등
Impala 큐 대기                         ≈  Trino maxQueued / hardConcurrencyLimit

(메모리 모델과 Resource Groups 상세는 별도 글 "Trino 메모리 관리와 Resource Groups"에서 다룹니다.)

7. 단계적 전환 전략 — 빅뱅은 피하라

검증된 순서는 다음과 같습니다.

7.1 병행 운영 (Coexistence)

Trino 의 Hive 커넥터로 기존 Hive Metastore 와 HDFS/S3 를 그대로 가리키게 하면, 데이터를 옮기지 않고도 Impala 와 Trino 가 같은 테이블을 동시에 조회할 수 있습니다. 이 상태에서 쿼리 호환성을 검증합니다.

# etc/catalog/hive.properties
connector.name=hive
hive.metastore.uri=thrift://metastore-host:9083
fs.native-s3.enabled=true
s3.endpoint=...

7.2 워크로드 분류와 SQL 검증

• BI 대시보드, 정기 리포트, 임시 분석 쿼리를 목록화합니다.
• 3장의 방언 차이를 기준으로 SQL 을 점검합니다. 대량 쿼리는 정규식·매핑 표로 일괄 변환한 뒤, 샘플을 양쪽 엔진에서 돌려 결과를 대조합니다.

7.3 Iceberg 로 마이그레이션

병행 검증이 끝나면 핵심 테이블을 Iceberg 로 전환합니다. 두 가지 경로가 있습니다.

-- 경로 A: 기존 Hive 테이블을 그 자리에서 Iceberg 로 마이그레이션 (데이터 재작성 없음, Hive 커넥터 procedure)
ALTER TABLE hive.analytics.events SET PROPERTIES table_type = 'ICEBERG';
-- (배포/버전에 따라 system.migrate 프로시저 사용)
 
-- 경로 B: CTAS 로 새로 적재하며 파티션·정렬 전략을 재설계
CREATE TABLE iceberg.analytics.events
WITH (format='PARQUET', partitioning=ARRAY['days(ts)'], sorted_by=ARRAY['user_id'])
AS SELECT * FROM hive.analytics.events;

경로 A 는 빠르지만 파일 레이아웃이 기존 그대로이고, 경로 B 는 비용이 들지만 파티션·정렬·파일 크기를 한 번에 정리할 수 있습니다. 자주 쓰는 핵심 테이블은 B 를 권장합니다.

7.4 클라이언트 전환

• JDBC/ODBC 드라이버를 Trino 용으로 교체합니다. (드라이버 URL, 포트 8443 등)
• BI 도구·스케줄러의 접속 정보를 바꿉니다.
• 일정 기간 양쪽을 운영하며 결과를 모니터링한 뒤, 트래픽이 0 이 되면 Impala 를 내립니다.

전환 체크리스트

• Hive 커넥터로 기존 테이블 병행 조회 확인
• 핵심 쿼리 SQL 방언 변환 및 결과 대조
• 통계(ANALYZE) 수집 및 CBO 동작 확인
• LDAP 인증 연결, 인가 정책(Ranger/파일/OPA) 재설계
• Resource Groups 로 동시성·메모리 한도 설정
• 핵심 테이블 Iceberg 전환(경로 A 또는 B)
• BI/스케줄러 드라이버 교체
• 병행 모니터링 후 Impala 폐기

8. 자주 묻는 질문

Q. Impala 보다 Trino 가 항상 빠른가? 아닙니다. 작은 데이터에 대한 짧은 대화형 쿼리는 Impala 의 catalogd 캐싱·코드 생성 덕에 빠를 수 있습니다. Trino 의 강점은 페더레이션, Iceberg 기반 프루닝, 대규모·복잡 쿼리, FTE 안정성입니다. 워크로드로 판단해야 합니다.

Q. Kudu 테이블은 어떻게 하나? Trino 에도 Kudu 커넥터가 있어 계속 읽을 수 있습니다. 다만 실시간 upsert 가 필요했던 이유가 분석용이라면, Iceberg 의 MERGE/행 단위 변경으로 대체 가능한지 검토하는 것이 장기적으로 단순합니다.

Q. 오픈소스 Trino 와 Starburst 중 무엇을 고르나? 보안·관리 UI·전용 커넥터·24/7 지원이 필요하면 Starburst(SEP), 그렇지 않으면 오픈소스 Trino 로 충분합니다. 별도 글 "Trino vs Starburst Enterprise"를 참고하세요.

9. 정리

Impala 에서 Trino 로의 전환은 "엔진 교체"라기보다 Lakehouse 아키텍처로의 이동에 가깝습니다. Hive 커넥터로 병행 운영을 시작해 호환성을 검증하고, 핵심 테이블을 Iceberg 로 옮기면서 파티션·통계·보안을 재설계하는 단계적 접근이 위험을 가장 잘 통제합니다.

이 글은 Trino 440번대 기준으로 작성되었습니다.

— Data Dynamics 엔지니어링 팀