Trino 캐싱 전략 — 파일시스템 캐시, 메타데이터 캐시, 그리고 한계

대시보드가 "왜 이렇게 느리지?"라는 말을 들을 때마다 원인을 파고들어 보면, 적지 않은 경우 같은 데이터를 네트워크로 반복해서 끌어오고 있거나, 메타스토어를 쿼리마다 왕복하는 장면이 나옵니다. Trino 는 데이터를 직접 소유하지 않고 오브젝트 스토리지(S3/GCS/Azure)나 외부 시스템에서 매번 읽어오는 구조거든요. 유연한 대신, 반복 I/O 와 메타스토어 왕복 지연이 쌓이면 대화형 분석의 응답성이 뚝 떨어집니다. 캐싱은 바로 이 두 비용을 줄이는 핵심 수단입니다.

이 글에서 배우는 것

• Trino 쿼리에서 시간이 어디서 새는지 구조적으로 파악하기
• 워커 로컬 SSD를 활용하는 파일시스템(데이터) 캐시 설정법
• Hive 메타데이터 캐시의 TTL 파라미터와 stale read 트레이드오프
• "왜 Trino 에는 쿼리 결과 캐시가 없는가"에 대한 명쾌한 답
• Materialized View 와 사전 집계 테이블로 결과 캐시를 대체하는 방법

1. 어디서 시간이 새는가

Trino 가 쿼리 하나를 실행할 때 내부적으로 거치는 단계를 따라가 보면, 지연이 발생하는 지점이 두 곳으로 압축됩니다. 아래 흐름도를 먼저 눈에 익혀 두면 이후 캐시 전략이 훨씬 직관적으로 이해됩니다.

2. 파일시스템 캐시 — 데이터를 워커 로컬에 캐싱

"원격에서 읽지 말고 가까운 곳에서 읽으면 되잖아?" — 바로 그 아이디어가 파일시스템 캐시입니다. Trino 의 파일시스템 캐시는 오브젝트 스토리지에서 읽은 데이터 파일(블록)을 워커의 로컬 디스크(SSD)에 캐싱합니다. 같은 데이터를 다시 읽을 때 원격 대신 로컬에서 읽어 지연과 네트워크 비용을 줄이는 거죠.

# etc/config.properties (또는 카탈로그별)
fs.cache.enabled=true
fs.cache.directories=/data1/trino-cache,/data2/trino-cache
fs.cache.max-sizes=200GB,200GB

왜 Iceberg 와 궁합이 좋은가

캐시를 쓸 때 가장 불안한 질문이 "내가 캐시한 파일이 원본과 달라지진 않았을까?"인데, Iceberg 를 쓰면 이 걱정이 사라집니다. Iceberg 의 데이터 파일은 불변(immutable) 입니다. 한 번 쓰인 파일은 바뀌지 않고, 변경은 새 파일 + 새 스냅샷으로 표현되거든요. 따라서 파일 경로가 같으면 내용도 반드시 같습니다. 이 불변성 덕분에 파일시스템 캐시가 안전하고 효과적으로 동작합니다.

한 문장으로: Iceberg 는 파일이 불변이라 캐시 무효화 걱정 없이 마음 놓고 캐싱할 수 있습니다.

노드 어피니티 (Soft Affinity)

파일시스템 캐시를 켜 놓기만 해도 효과가 있을까요? 한 가지 함정이 있습니다. 같은 파일을 가급적 같은 워커가 읽어야 합니다. 그렇지 않으면 모든 워커에 같은 데이터가 중복 캐싱되어 효율이 뚝 떨어지거든요. Trino 는 이 문제를 해결하기 위해 split 을 파일 기준으로 일관된 워커에 배정하는 soft affinity 스케줄링을 사용해 캐시 적중률을 높여 줍니다.

3. 메타데이터 캐시 — 메타스토어 왕복 줄이기

데이터 자체를 캐싱하는 것 못지않게 중요한 것이 메타데이터 캐싱입니다. 쿼리를 실행하기도 전에 메타스토어를 오가는 시간이 수백 밀리초씩 쌓이는 경우가 의외로 많거든요. 각 커넥터별로 어떻게 대응할 수 있는지 살펴봅시다.

3.1 Hive 커넥터 메타데이터 캐시

Hive 커넥터는 매 쿼리마다 Hive Metastore(HMS)에 스키마·파티션·통계를 조회합니다. 파티션이 많거나 HMS 가 멀면 이 RTT 가 쌓입니다. 아래 설정으로 캐시를 켜서 완화해 봅시다.

# etc/catalog/hive.properties
hive.metastore-cache-ttl=10m
hive.metastore-cache-maximum-size=10000
hive.metastore-refresh-interval=1m

트레이드오프: 편리함 뒤에는 대가가 따릅니다. TTL 이 살아 있는 동안 외부 도구가 메타데이터를 바꿔도 Trino 는 옛 정보를 그대로 볼 수 있습니다. 캐시를 강제로 비우려면 다음 명령을 실행하면 됩니다.

CALL system.flush_metadata_cache();

Cloudera/Impala 에서 넘어온 분들이 흔히 오해하는 지점이 있습니다. 이 캐시는 Impala 의 catalogd 캐시와 비슷한 "사람이 관리하는 캐시"입니다. 반면 Iceberg 커넥터는 스냅샷 모델이라 이런 TTL 캐시가 기본적으로 불필요합니다 — 커밋이 곧 가시성이거든요. Iceberg 로 마이그레이션하면 메타데이터 캐시를 신경 쓸 일 자체가 확 줄어드는 이유가 여기 있습니다.

3.2 Iceberg 의 메타데이터 모델

Iceberg 는 파티션·파일 통계를 HMS RPC 가 아니라 manifest 파일(스토리지)에서 읽습니다. HMS 왕복 자체가 없으니 메타데이터 병목이 구조적으로 훨씬 작습니다. 따라서 Iceberg 테이블에서는 별도의 메타데이터 TTL 캐시를 고민하기보다, 파일시스템 캐시(manifest 파일도 포함)만 켜 두는 것으로 충분한 경우가 많습니다.

한 문장으로: Iceberg 는 메타데이터도 파일로 관리하기 때문에, 파일시스템 캐시 하나로 데이터와 메타데이터 I/O 를 동시에 줄일 수 있습니다.

4. 결과 캐시 — 왜 Trino 에는 없는가

"같은 쿼리를 또 던지면 결과를 캐시에서 바로 주면 안 되나?" — 이 질문은 Trino 를 처음 접하는 분들이라면 한 번쯤 떠올리게 되는 자연스러운 의문입니다. 결론부터 말씀드리면, Trino 는 기본적으로 쿼리 결과 캐시를 제공하지 않습니다. 왜 그럴까요?

• Trino 는 페더레이션 엔진입니다. 소스 데이터가 외부 시스템에서 언제든 바뀔 수 있어, "캐시된 결과가 아직 유효한가"를 엔진이 일반적으로 보장하기 어렵습니다.
• 결과 정합성(stale read) 위험을 엔진 차원에서 떠안기보다, 일관성 보장을 데이터 계층에 맡기는 설계 철학을 따르고 있습니다.

대신 여러분이 활용할 수 있는 실용적인 대안이 있습니다.

Materialized View

대안 중에서 가장 강력한 선택지가 Materialized View 입니다. 아래처럼 정의해 두면 됩니다.

CREATE MATERIALIZED VIEW iceberg.analytics.daily_active_users AS
SELECT date(event_time) AS d, count(DISTINCT user_id) AS dau
FROM iceberg.analytics.events
GROUP BY date(event_time);
 
-- 주기적 갱신 (스케줄러에서)
REFRESH MATERIALIZED VIEW iceberg.analytics.daily_active_users;

Iceberg 커넥터의 materialized view 는 결과를 실제 테이블로 저장하고, 원본이 갱신되면 stale 상태를 추적합니다. 대시보드처럼 "같은 무거운 집계를 반복"하는 패턴이라면, 이것이 결과 캐시의 실질적이고 안전한 대안이 됩니다.

5. 캐싱이 효과 없는/역효과인 경우

캐싱은 만능이 아닙니다. 오히려 잘못 켜 두면 디스크만 낭비하거나 stale read 를 유발하는 경우도 있습니다. 어떤 상황이 그런지 미리 알아 두면 좋습니다.

캐시는 "반복 접근되는 핫 데이터/메타데이터"가 있을 때 빛납니다. 반대로 워크로드가 매번 새로운 데이터를 훑는다면 캐시는 비용만 늘리니, 켜기 전에 워크로드 패턴을 먼저 확인해 보세요.

6. 구성 가이드 — 워크로드별 권장

이제 여러분의 워크로드에 어떤 캐시 조합이 적합한지 빠르게 판단할 수 있도록 표로 정리해 드립니다.

7. 정리

지금까지 살펴본 Trino 캐싱 전략을 한 눈에 비교해 봅시다.

Trino 캐싱의 핵심 원칙은 두 가지입니다. 첫째, 데이터 I/O 는 파일시스템 캐시로, 메타데이터 RTT 는 메타데이터 캐시로 줄이되, 반복 접근이 있는 워크로드에서만 켜는 것. 둘째, 결과 캐시가 없다는 사실을 받아들이고, 반복되는 무거운 집계는 Materialized View 나 사전 집계 테이블로 대체하는 것. Iceberg 의 불변 파일·스냅샷 모델은 이 캐싱 전략을 더 단순하고 안전하게 만들어 줍니다.

마치며 — 핵심 요약

• 파일시스템 캐시는 워커 로컬 SSD 에 데이터 블록을 저장해 반복 원격 I/O 를 줄여 줍니다. 핫 데이터가 있는 대화형 워크로드에서 가장 효과적입니다.
• soft affinity 스케줄링을 함께 써야 캐시 적중률이 올라갑니다. 같은 파일을 같은 워커가 담당하게 해 중복 캐싱을 방지하는 거죠.
• Hive 메타데이터 캐시는 TTL 파라미터로 HMS 왕복을 줄여 주지만, stale read 가능성을 항상 염두에 두고 flush_metadata_cache() 절차를 준비해 두세요.
• Iceberg 를 쓰면 불변 파일 덕분에 파일시스템 캐시가 훨씬 안전해지고, 메타데이터 TTL 캐시 고민도 줄어듭니다.
• Trino 에 결과 캐시는 없습니다. 대신 Materialized View 와 사전 집계 테이블로 반복되는 무거운 집계를 대체하면 됩니다.
• 일회성 대용량 ETL 처럼 재사용이 없는 워크로드에서는 캐시를 굳이 켜지 않는 것이 더 효율적입니다.

캐싱 전략은 "켜면 무조건 좋다"가 아니라 여러분의 워크로드 패턴을 먼저 이해하고 선택하는 것이 핵심입니다. 이 글이 그 판단에 도움이 됐으면 합니다.

이 글은 Trino 440번대 기준으로 작성되었습니다. 대화형 분석의 응답성 개선이나 캐싱·사전집계 설계가 필요하시면 언제든 문의해 주세요.

— Data Dynamics 엔지니어링 팀