Spotify 엔지니어링이 페타바이트 규모 데이터 레이크(GCS)에 저장된 Parquet 파일에서 한 자릿수 밀리초 레이턴시로 포인트 쿼리를 수행하는 RAP(Random Access Parquet) 방식을 공개했다. Trino·BigQuery 같은 분산 SQL 엔진은 단일 행 조회도 스케줄링·플래닝 비용으로 수 초가 걸리지만, RAP는 외부 인덱스로 키→(파일, 행 번호)를 직접 매핑해 의존적 read chain을 병렬화함으로써 이 문제를 해결했다. 기존 KV 스토어(Bigtable)와 달리 GB당 비용이 클라우드 스토리지 read 수준에 불과해 장기 이력 데이터나 롱테일 피처도 인터랙티브 조회 대상이 된다.
핵심 포인트- 전통적 Parquet 조회는 footer fetch → row group 파싱 → key 스캔 → page 위치 순서의 의존적 read chain으로 레이턴시가 누적된다.
- RAP는 키를 파일·행 번호에 직접 매핑하는 외부 인덱스로 이 chain을 끊고 인덱스 조회·페이지 매핑·ranged read를 병렬 실행한다.
- 정렬·해시 버켓팅·co-grouping으로 동일 키 데이터를 인접 배치해 읽는 바이트를 최소화한다.
- ZSTD frame reset과 스토리지 블록 정렬, 컬럼 인터리빙으로 read 횟수 자체를 줄인다.
- covering index(호이스트 값)로 소형 값을 인덱스 엔트리에 직접 저장해 스토리지 read를 완전히 제거한다.
- KV 스토어 대비 비용이 낮아져 AI 에이전트가 레이크의 수개월·수년치 데이터에 실시간 접근 가능해진다.
상세 정리- 문제 배경: Spotify는 온라인 서비스용 데이터를 Bigtable 같은 KV 스토어에, 분석용은 GCS 데이터 레이크에 이중으로 저장한다. 클라우드 스토리지 자체 레이턴시는 이미 한 자릿수 ms지만, 쿼리 엔진 오버헤드가 병목이었다.
- 핵심 병목: Parquet 파일 읽기는 footer → row group 메타데이터 → key 컬럼 스캔 → page 위치 순으로 의존적 read chain이 발생해 단계마다 레이턴시가 쌓인다.
- RAP 동작 원리: 외부 인덱스가 각 키를 file(딕셔너리 인코딩)과 row numbers에 직접 매핑한다. 인덱스 조회·캐시된 페이지 매핑·ranged read가 의존성 없이 병렬 실행된다.
- 인덱스 구조: 멀티맵 형태로 엔트리마다 key, file, row numbers, 선택적 value count(페이지네이션)를 저장한다. 페타바이트 인덱싱 시 테라바이트급 인덱스가 생성된다.
- 키 집중화: 키 기준 정렬로 동일 키 행을 연속 배치해 최소 페이지로 압축한다. 해시 버켓팅은 키를 특정 파일에 결정론적으로 매핑하고, co-grouping은 스키마를 user_id + ARRAY_AGG(값)로 재구성해 sort order 의존을 제거한다.
- 바이트 절감 - one page per key: 키 경계마다 page를 flush해 페이지 전체가 해당 키 소유가 되므로 row 추출이 불필요하다.
- 바이트 절감 - ZSTD frame reset: 각 키의 행을 독립 ZSTD 프레임으로 압축하고 바이트 오프셋과 크기를 인덱스에 저장해 별도 페이지 인덱스를 제거한다.
- 바이트 절감 - 스토리지 정렬: ZSTD skippable frame으로 키 사이를 스토리지 블록 경계(4KB/16KB)에 맞춰 패딩해 불필요한 블록 읽기를 방지한다.
- read 횟수 절감 - Blob/Variant: 필요 필드를 JSON·Protobuf·Parquet Variant 단일 컬럼으로 통합해 파일당 read를 1회로 줄인다.
- read 횟수 절감 - 컬럼 인터리빙: 여러 컬럼 데이터를 키 단위로 물리적 인접 배치한다(key1-colA, key1-colB, key2-colA, key2-colB 순). ZSTD skippable frame이 컬럼 간 브리지 역할을 하며 하위 호환성을 유지한다.
- covering index: 소형 값과 사전 계산된 집계(이벤트 수, 총 재생 시간)를 인덱스 엔트리에 직접 내장해 스토리지 read를 완전히 제거한다.
- 보조 인덱스: 구매자/판매자 ID처럼 복수 차원 조회 시 동일 인덱스 엔트리에 해시 테이블(O(1) 정확 조회)·정렬 인덱스(범위 쿼리)를 선택해 추가할 수 있다. 보조 인덱스 추가·제거는 서빙 레이어만 변경하면 된다.
- 경제적 임팩트: KV 스토어는 GB당 비용 때문에 저장 데이터를 선별해야 했지만, RAP는 클라우드 스토리지 read 비용만 발생해 장기 이력·롱테일·저빈도 피처도 인터랙티브 조회 대상이 된다.
왜 읽나대용량 데이터 레이크 위에서 인터랙티브한 포인트 쿼리를 구현해야 하는 데이터 엔지니어·백엔드 엔지니어에게 Parquet 구조 최적화부터 외부 인덱싱 설계까지 실전 레퍼런스를 제공한다.
Spotify Engineering·
여기어때 (GC컴퍼니)·
Pinterest Engineering·
AWS Architecture·