151편 · 약 14분

CoddSpeed: Microsoft Fabric Data Warehouse의 GPU 가속 쿼리 실행 엔진 — TQP 연구에서 SIGMOD 2026 수상 프로덕션까지

요약

분석 데이터베이스에 GPU를 붙이는 시도는 오래됐다. 하지만 프로덕션 데이터 웨어하우스에서 안정적으로 작동하는 GPU 가속 SQL 엔진은 드물다. CoddSpeed는 Microsoft가 Fabric Data Warehouse에 내장한 GPU 가속 쿼리 실행 엔진으로, 이 어려운 목표를 달성한 사례다.

CoddSpeed는 Microsoft Research의 TQP(Tensor Query Processor) 프로토타입에서 출발했다. TQP는 관계형 연산자를 PyTorch 텐서 연산(matmul, scatter, gather)으로 표현해 AI 하드웨어 생태계를 그대로 활용하는 아이디어였다. 이 연구 프로토타입이 2026년 SIGMOD Companion에 최우수 산업 논문으로 선정되면서 프로덕션 엔진 CoddSpeed의 아키텍처가 공개됐다.

주요 성능 수치:

단일 A100, TPC-H SF=100: 워밍업 후 7.9×, 콜드 시작 4.7× 속도 향상
8×H100 단일 노드, TPC-H SF=1000: DAL 없이 2.1×, DAL(NVLink) 포함 27.1× 속도 향상
일부 프로덕션 시나리오에서 최대 30× 속도 향상
데이터가 GPU HBM을 초과해도 작동하는 파티션 실행 모델

SIGMOD Companion 2026 Best Industry Paper
Microsoft Fabric Data Warehouse Early Access Preview (2026년 7월)

배경: TQP — PyTorch로 SQL을 실행한다는 아이디어

왜 GPU가 OLAP에 맞는가

분석 쿼리(OLAP)는 GPU에 적합한 특성을 갖는다.

특성	CPU 처리	GPU 처리
데이터 병렬성	수십 코어	수천~수만 코어
메모리 대역폭	DDR5 ~100GB/s	HBM3 ~3.35TB/s
연산 패턴	분기 많음	선형 스캔, 집계 유리
활용 사례	범용 워크로드	대규모 그룹 집계, 조인

TPC-H 같은 분석 벤치마크는 수십억 행의 테이블에 대한 대규모 집계와 조인이 중심이다. 이런 워크로드는 GPU의 대규모 병렬 처리 능력과 고대역폭 메모리에서 이점을 얻는다.

TQP의 핵심 아이디어

기존 GPU 데이터베이스 연구는 각 SQL 연산자(스캔, 해시 조인, 집계)를 GPU 커널로 직접 구현하는 방식을 택했다. 이는 특정 GPU 아키텍처와 긴밀하게 결합된다. GPU 세대가 바뀌면 커널을 다시 작성해야 한다.

TQP는 다른 접근을 택했다. 관계형 연산자를 텐서 연산으로 변환한다.

SELECT a, SUM(b)
FROM t
GROUP BY a

→ [스캔] → [scatter/gather 텐서 연산] → [reduce 텐서 연산] → 결과

PyTorch 텐서 연산은 GPU 하드웨어 세대와 무관하게 최적화된다. Ampere, Hopper, Blackwell이 나와도 PyTorch가 최적화를 담당하기 때문에 TQP 코드를 다시 작성할 필요가 없다. 하드웨어 이식성이 핵심 설계 목표였다.

CoddSpeed 아키텍처: CAL과 DAL

TQP가 연구 프로토타입이라면, CoddSpeed는 프로덕션 Fabric DW에 통합되기 위해 두 가지 추상 레이어를 추가했다.

CoddSpeed 아키텍처: CAL·DAL·파티션 실행 모델

CAL: Coprocessor Abstraction Layer

CAL은 Fabric DW 쿼리 옵티마이저와 실제 GPU 실행 사이의 인터페이스다.

옵티마이저는 쿼리 실행 계획을 분석해 GPU에 오프로드할 수 있는 단편(fragment, sub-plan)을 식별한다. 이 단편들을 CAL의 하드웨어 독립적 API로 제출한다.

CAL이 중요한 이유는 GPU 세대 독립성 때문이다. Fabric DW는 데이터센터에서 여러 세대의 GPU와 함께 운영된다. Ampere A100, Hopper H100, 최신 Blackwell 아키텍처가 공존할 수 있다. CAL 덕분에 상위 레이어(옵티마이저, 실행 계획)를 변경하지 않고도 새로운 GPU 세대를 지원할 수 있다.

DAL: Data Abstraction Layer

DAL은 데이터 이동의 추상화 레이어다. GPU 간 데이터 이동은 물리적 연결에 따라 성능이 크게 달라진다.

NVLink: GPU 간 고속 직결 (NVIDIA NVLink, 최신 세대 900GB/s)
Infinity Fabric: AMD GPU 간 연결
InfiniBand: 노드 간 고속 네트워크 (NDR 400Gb/s)
PCIe: 표준 버스 (낮은 대역폭)
Ethernet: 클라우드 환경 네트워크

8×H100 벤치마크에서 DAL 없이 2.1× 속도 향상에 그쳤지만 DAL(NVLink) 포함 시 27.1×가 된 것은 데이터 이동 최적화가 멀티 GPU 분석 성능의 핵심이라는 것을 보여준다.

DAL은 이 이질적인 전송 레이어를 단일 키-값 API 뒤로 숨긴다. 상위 실행 엔진은 "이 데이터를 GPU B로 이동시켜라"라고 요청하면 되고, 실제 전송 방식은 DAL이 물리 토폴로지에 따라 최적 경로를 선택한다.

파티션 실행 모델: GPU HBM 한계를 넘는 방법

분석 쿼리는 종종 수백 GB 규모의 데이터를 처리한다. GPU HBM은 최신 H100 기준 80GB, A100은 40GB 또는 80GB다. TPC-H SF=1000은 약 1TB 규모다.

기존 GPU 데이터베이스의 공통 제약: 데이터가 GPU 메모리에 들어가지 않으면 처리할 수 없다. CoddSpeed는 파티션 실행 모델로 이 제약을 해결한다.

대용량 테이블 (예: 1TB)
    ↓
파티션 분할 (예: 10 × 100GB 또는 더 작게)
    ↓
GPU HBM에 들어가는 단위로 순차 처리
    ↓
파티션 결과 합산 → 최종 결과

파티션이 GPU 메모리를 초과하거나 특정 연산자가 GPU에서 지원되지 않으면, 해당 파티션은 CPU로 폴백된다. 나머지 파티션은 계속 GPU에서 처리된다. SQL 결과는 동일하고, 사용자는 이 과정을 볼 수 없다.

콜드 vs 워밍업 성능 차이의 원인

TPC-H SF=100 기준:

콜드 시작: 4.7×
워밍업: 7.9×

콜드와 워밍업의 차이(4.7 → 7.9)는 주로 두 가지 요인에서 온다.

HBM 캐싱: 이미 로드된 데이터가 HBM에 남아 있으면 다음 쿼리에서 I/O 없이 재사용된다.
JIT 컴파일 캐싱: 쿼리 단편의 GPU 커널이 처음 실행 시 컴파일되고 이후 캐싱된다.

성능 벤치마크 심층 분석

TPC-H 결과 요약

구성	SF	조건	속도 향상
단일 A100	100 (10GB)	워밍업	7.9×
단일 A100	100 (10GB)	콜드	4.7×
8×H100	1,000 (100GB)	DAL 없음	2.1×
8×H100	1,000 (100GB)	DAL(NVLink)	27.1×
프로덕션 시나리오	1TB+	최적 조건	최대 30×

논문에 따르면 CoddSpeed는 같은 GPU 하드웨어에서 측정한 기존 GPU 쿼리 프로세서 중 가장 빠르다고 주장하며, 비교 대상 HeavyDB(MapD 후속)보다 약 2배 빠른 것으로 보고한다.

가속 효과가 큰 쿼리 패턴

대규모 GROUP BY 집계: GPU 병렬 reduce 연산이 직접 적용됨
대규모 해시 조인: GPU 메모리 대역폭이 프로브 단계를 가속
필터링 후 집계: GPU 스캔 + 조건 필터 + 집계의 연속 파이프라인
윈도우 함수: 파티션 병렬 처리에 적합

가속 효과가 작거나 CPU 폴백이 필요한 경우

결과 집합이 작은 OLTP 형태 쿼리 (병렬화 이점 없음)
복잡한 중첩 서브쿼리 (실행 계획 단편화 어려움)
현재 미지원 연산자 포함 쿼리 (CPU 폴백)
데이터가 매우 작아 GPU 전송 오버헤드가 이득을 상쇄

운영 관점: Fabric DW GPU 가속 사용하기

배포 방식

2026년 7월 Early Access Preview 기준, CoddSpeed는 Fabric Data Warehouse에 통합돼 있다.

인프라 프로비저닝 불필요: 별도 GPU 서버를 구성하거나 관리할 필요 없다.
워크스페이스 수준 설정: 관리자가 워크스페이스 설정에서 GPU 가속을 켜고 끌 수 있다.
SQL 변경 없음: 기존 쿼리를 그대로 사용하면 된다. 옵티마이저가 GPU 오프로드 여부를 자동으로 결정한다.
투명한 폴백: 특정 쿼리나 파티션이 GPU에서 처리되지 않으면 자동으로 CPU가 처리하고 결과를 합산한다.

운영 고려사항

실제 환경에서 GPU 가속 Fabric DW를 쓸 때 염두에 둘 사항:

예측 가능성: 쿼리가 GPU에서 처리될지, CPU로 폴백될지 사전에 알기 어렵다. 폴백이 발생하면 일부 쿼리는 기대 성능을 내지 못할 수 있다.

비용 모델: GPU 컴퓨팅은 CPU보다 단위당 비용이 높다. Microsoft가 어떤 비용 모델을 적용할지는 GA 시점에 명확해질 예정이다. 빠른 쿼리가 반드시 저렴한 쿼리는 아니다.

워밍업 효과: 대시보드나 정기 보고서처럼 동일 쿼리를 반복 실행하는 워크로드에서 워밍업 효과(7.9×)를 최대로 얻을 수 있다. 임시 분석(ad-hoc)은 콜드 성능(4.7×)이 기준이 된다.

멀티 GPU 스케일링: DAL이 멀티 GPU 성능의 핵심이라는 것이 벤치마크에서 확인됐다(2.1× → 27.1×). Fabric 서비스 내부에서 이 멀티 GPU 구성이 어떻게 노출될지는 서비스 아키텍처에 따라 달라진다.

TQP에서 CoddSpeed로: 연구→프로덕션 전환의 과제

이 논문이 SIGMOD Best Industry Paper를 받은 것은 단순히 성능 때문만이 아니다. 연구 프로토타입을 프로덕션 서비스로 전환하는 과정을 상세히 기술했기 때문이다.

TQP(PyTorch 텐서 연산)와 CoddSpeed(CAL + DAL + 파티션 실행) 사이의 격차는 컸다.

TQP 프로토타입	CoddSpeed 프로덕션
단일 GPU 가정	멀티 GPU (DAL)
모든 데이터가 HBM에 들어간다고 가정	파티션 실행 모델
특정 쿼리 패턴만 지원	지원 범위 확장 + 폴백
실험용 환경	Fabric DW 옵티마이저와 통합
단일 GPU 세대	멀티 세대 (CAL 추상화)

특히 DAL의 영향이 벤치마크에서 극적으로 드러난다. 멀티 GPU 시스템에서 GPU 간 데이터 이동을 최적화하지 않으면 스케일아웃 이점을 거의 얻을 수 없다(2.1× vs 27.1×). 이는 GPU 데이터베이스 설계에서 컴퓨팅 커널 못지않게 데이터 이동 레이어가 중요하다는 일반적 교훈이기도 하다.

요점 정리

CoddSpeed는 세 가지 설계 원칙으로 GPU 가속 OLAP의 프로덕션 진입 장벽을 낮췄다.

첫째, 하드웨어 추상화(CAL): GPU 세대마다 엔진을 다시 짜는 대신, 하드웨어 독립적 API 하나로 여러 세대를 지원한다.

둘째, 데이터 이동 최적화(DAL): 멀티 GPU 성능을 결정하는 것은 커널 속도가 아니라 GPU 간 데이터 이동이다. NVLink로 27.1× vs PCIe 수준의 2.1×는 이를 명확히 보여준다.

셋째, 투명한 부분 가속(파티션 실행 + 폴백): 모든 데이터와 모든 연산자를 GPU에서 처리할 필요가 없다. 처리 가능한 부분만 GPU에서, 나머지는 CPU에서 처리하고 결과를 합산하면 충분하다.

SQL을 바꾸지 않고 워크스페이스 설정 하나로 GPU 가속을 얻을 수 있다는 것이 Fabric DW GPU 가속의 운영 매력이다. GA 이후 비용 모델과 지원 연산자 범위가 어떻게 정해지느냐가 실제 채택의 관건이 될 것이다.