Benchmarks against Gluten and DataFusion Comet (Xonai FuseCore)
Author: Leandro Vaz (Xonai) | Source: Medium | Published: 2026-08-17
한 줄 요약
Spark 가속기 확산의 가장 큰 장벽은 성능이 아니라 SQL 호환성이었고, MLIR 기반 컴파일러 엔진을 만들되 Parquet 리더는 경쟁 프로젝트(Comet)의 것을 가져다 쓰는 선택이 Gluten·Comet을 앞서게 했다.
핵심 주장/내용
- 가장 큰 허들은 SQL 호환성이었다: 데이터 인프라 전반에 가속기 사용을 확장할 때 가장 흔한 장애물이 SQL 호환성이어서 최우선으로 삼았다. 2025년 초 약 130개 가속 SQL 함수에서 현재 약 275개로 성장했고, decimal·interval 타입 완전 지원, ANSI 지원, 중첩 데이터 타입 부분 지원으로 데이터 타입 커버리지도 확대. compatibility radar — Spark 로그를 대규모로 ingest해 어떤 Spark 잡이 FuseCore로 얼마나 가치를 얻을지 추정하는 도구 — 를 도입해 호환 워크로드 식별을 사소하게 만들었다
- MLIR 기반 엔진 — 왜 이 접근인가: 2020년 말 대규모 데이터 처리의 비효율을 end-to-end로 장기적으로 더 근본적으로 풀 방법을 연구하다, Spark의 검증된 아키텍처를 활용하되 Spark의 JVM 기반 catalyst 엔진을 대체하는 MLIR 기반의 새로운 컴파일러를 만들기로 했다. 애플리케이션 실행 성능을 결정하는 세 기둥 — ① 아키텍처와 그 제작이 의도한 유스케이스를 얼마나 잘 지원하는가 ② 컴파일러가 사람이 읽는 소스 코드를 선택된 실행 하드웨어로 얼마나 잘 번역하는가 ③ 실행할 하드웨어가 애플리케이션에 얼마나 잘 맞는가
- 빅데이터 처리에 은탄환은 없다. 많은 실세계 비즈니스 케이스 요구를 충족하려 쓰인 애플리케이션 설계의 다양성은 모든 유스케이스를 최적으로 서빙할 “올바른” 하드웨어가 없다는 뜻이고, 최근 몇 년의 새 하드웨어 아키텍처 폭발은 그 “올바른” 하드웨어가 움직이는 표적일 수도 있다는 뜻이다
- 그래서 두 가지를 만들었다: 하드웨어와 독립적으로 데이터 계산을 표현하는 DSL(Fuse) 과 선택된 하드웨어 타겟을 향한 커스텀 MLIR dialect와 최적화 pass 파이프라인. MLIR 없이는 불가능했고, 수년의 컴파일러 인프라를 재발명하지 않을 유일한 선택지였다
- DSL은 SQL 함수를 추론하기 쉽고 자동으로 fuse되는 canonical 루프 형태로 표현하고, 집계 같은 복잡하고 컴퓨트 집약적 연산에 특화된 자동 코드 변환을 적용한다. FFI 메커니즘으로 이 DSL 범위 밖의 계산(regex, 날짜·시간 표현식)에 대해 외부 함수를 호출할 수 있다
- 주류 C++ 네이티브 해석과 근본적으로 다르다: 그쪽은 많은 SQL 연산에 대해 빠른 SIMD 기반 커널을 손으로 쓰고 인덱스로 접근하는 컬럼 데이터 위로 파이프라이닝하는 데 의존한다. 이 접근은 데이터 파이프라인 최적화를 극대화하는 해법으로서 본질적으로 덜 일반적인데, 고정된 SQL 연산 시퀀스마다 손으로 쓴 특정 템플릿이 많이 필요하고 가능한 조합이 많으면 할 수 있는 것에 한계가 있기 때문
- Xonai의 접근은 (대부분의 경우) full loop fusion의 직접적 결과로 인덱싱을 제거해 처리량을 극대화하고, 많은 외부 함수조차 컴파일러가 패턴 매칭해 컴파일 파이프라인 아주 초기에 기계어로 lowering하므로 이미 훨씬 빠른 코드 경로에서 co-designed 최적화의 기회가 생긴다
- decimal 구현이 좋은 예이자 벤치마크가 앞서는 이유 중 하나: 2025년 중반 Arrow decimal 라이브러리로 시작해 완전한 decimal 커버리지·호환성을 달성했다(빠르게 움직일 수 있었고 Comet의 decimal 구현으로 Arrow가 견고한 선택임이 이미 입증되었으므로 합리적). 두 번째 단계로 가능한 곳에서 decimal 함수를 패턴 매칭해 자체 중간 표현으로 직접 번역했는데, 손으로 쓴 C++ 함수를 호출하는 것보다 훨씬 빠른 경로였고 각 단계에서 극적인 성능 이득을 측정했다. 코드 inlining처럼 작동하되 추가 최적화가 있고 결정적이고 통제 가능한 방식으로
- Comet Parquet 리더 활용 — 자체 개발보다 검증 우선: 올해 초 1TB 데이터셋 TPC 벤치마크에서 데이터 스캔이 총 실행 시간을 지배함을 발견했다 — TPC-H에서 약 50%, TPC-DS에서 약 75%. Gluten과 Comet을 같은 조건에서 벤치마크해 그들이 스캔에 훨씬 적은 비율을 쓰는 것을 검증하자 Parquet 리더(stock Parquet 리더의 수정판)를 교체해야 한다는 것이 명확해졌다
- 여러 가속기를 돌려 얻은 새 데이터가 MLIR 기반 엔진이 얼마나 잘 하고 있는지에 대한 통찰도 주었다 — TPC-DS 총 실행 시간의 18%에 불과했고, 그들의 네이티브 Parquet 리더 중 하나를 쓰면 Gluten과 Comet을 앞설 것이라고 예측할 수 있었다. 자체 개발을 이미 시작했지만 가정을 검증하기 위해 서드파티 네이티브 Parquet 리더로 실험하는 것이 필요하다고 느꼈다. Gluten과 Comet 중 Comet을 고른 이유는 ① Spark 플러그인 구현과 아키텍처적으로 더 정렬되어 있고 ② Gluten Parquet 리더와 대략 비슷하게 경쟁력 있어서
- 첫 실험에 일주일밖에 걸리지 않았고 결과가 스스로 말했다 — FuseCore 런타임 23% 개선, Gluten v1.6.0 대비 13% 빠른 런타임. 초기 실험은 Arrow에서 자체 proprietary 컬럼 포맷으로 데이터를 변환하는 오버헤드가 있었지만 이후 3주 만에 대부분의 TPC 파생 벤치마크 데이터 스캔에서 Arrow 컬럼 포맷과 자체 포맷 사이의 near zero-copy를 달성했다. 추가로 Comet Parquet 리더의 호환성을 JDK 1.8과 추가 Spark 버전으로 확장(사전 빌드된 Comet JAR가 JDK 11과 Spark 3.5.X만 지원하는 제약이 있었으므로)
주요 수치 / 사실
- TPC-DS 3TB 벤치마크 (AWS Labs의 Gluten+Velox vs Comet 벤치마크와 거의 동일한 조건 + 비파티션 데이터를 추가해 벤치마크 매트릭스 확장):
- FuseCore v26.2가 파티션 데이터에서의 Gluten+Velox를 제외한 모든 벤치마크에서 Gluten+Velox v1.6.0과 Comet v0.16.0을 앞선다 (그 케이스는 Gluten에 유리한 17초 차이로 노이즈로 간주)
- 다른 모든 경우 Gluten+Velox 대비 20.7%, Comet 대비 6.1% 나은 런타임. 파티션 데이터에서는 Comet 대비 13.4% 나은 런타임
- Spark 대비 1.8배 TPC-DS 속도 향상
- shuffle partition 기본값 차이 주의: FuseCore v26.2는 1000이 기본(테라바이트 수준 워크로드에 높은 파티션 수가 대체로 유리)이고 Gluten+Velox와 Comet은 200이 기본. 셋 다 1000으로 맞춰 벤치마크하면 Gluten baseline이 약 4.5% 개선(최대 1.37배)되고 Comet은 약 5% 저하(1.43배로 하락) 해 FuseCore가 shuffle partition 설정이 같아도 일관된 또는 오히려 더 나은 리드를 유지
- 성능 분포: 비파티션 데이터에서 FuseCore가 지배적 — 20%+ 버킷만으로 103개 TPC-DS 쿼리 중 55개에서 Gluten보다 나은 성능을 달성하고, 런타임이 6% 나은데도 Comet에 대해서는 균형 잡힌 분포. 파티션 데이터에서는 모든 가속기가 균형 잡혀 있고 Gluten과 Comet이 20%+ 버킷에서 약간 우위
- floating-point(double) 데이터로도 추가 벤치마크해 같은 TPC-DS 파생 벤치마크에서 Gluten v1.6.0 대비 21% 빠른 런타임(81.3분 vs 98.3분). TPC-H는 여전히 뒤처져 Gluten이 23% 빨랐지만 성능 최적화 후 Gluten v1.6.0 성능에 맞춰 격차를 좁혔다
- 오픈 인프라에 대한 감사: stock 기반 Parquet 리더를 넘어서지 않았다면 현재 벤치마크 결과는 불가능했을 것이고, MLIR과 LLVM 없이는 이 여정을 시작하는 것 자체가 불가능했을 것이다. 오픈 인프라가 우리 같은 작은 팀이 체급 이상으로 싸우게 해준다 — DataFusion, Arrow, Comet, LLVM Foundation 커뮤니티에 감사. compatibility radar 도구를 오픈소스화하며 되돌려주기 시작
관련 위키
- Columnar Execution Engine
- Spark at Scale
- Open Source Data Stack
- Query Optimization
- Data Engineering FinOps
Source: 원문 보기