Routing Multiple Query Engines with Iceberg

Author: Rob M (LakeOps) | Source: lakeops.dev | Published: 2026-05-23

한 줄 요약

공유 Iceberg 테이블 위에서 Trino·Spark·DuckDB·Athena·Snowflake 등 여러 엔진을 쿼리 셰이프·비용·지연·엔진 헬스에 따라 라우팅하는 SQL 프록시(QueryFlux/LakeOps) 아키텍처.

Iceberg의 multi-engine 약속에도, **“어떤 쿼리를 어떤 엔진이 실행할지” 결정(라우팅)**은 스택의 빈틈. 없으면 팀마다 아는 엔진만 써서 비용·지연 낭비(DuckDB $0.01 p o in tl oo k u p 이 S n o w f l ak e 에선$ 0.08)
각 엔진의 sweet spot: Spark(배치 ETL·write·Iceberg 유지보수), Trino(인터랙티브), DuckDB(단일 노드 sub-second), Athena(서버리스 scan-priced), Snowflake(BI), StarRocks(고동시성 MPP)
2단계 라우팅: group selection(라우팅 룰로 cluster group 선택) → member selection(group 내 round-robin/least-loaded/failover/weighted). 용량 초과 시 프록시에서 큐잉 또는 fallback group으로 spill
QueryFlux(Rust 오픈소스): 3단계 파이프라인(프로토콜 ingestion → 라우팅 룰 → dispatch + sqlglot dialect 변환). ~0.35ms p50 오버헤드
LakeOps 확장: table-health-aware 라우팅(Iceberg 메타데이터 기반, fragmented manifest면 Trino/Spark로), 쿼리 패턴 학습, 최적화 기반 엔진 확장(compaction 후 DuckDB 가능해짐)
에이전트 워크로드용 self-improving 라우팅: adaptive(통계, 0ms) → LLM(신규 셰이프, ~300ms 후 캐시) → semantic(임베딩 유사도) → default. + guardrail(ReadOnly/RowLimit/CostEstimate/PIIMask/HumanApproval)