데이터 레이크에서 저지연 포인트 쿼리가 왜 어려운가
전통적인 데이터 레이크 아키텍처에서 Apache Parquet 파일은 OLAP(분석용) 워크로드에 최적화되어 있다. 컬럼 기반 저장 방식 덕분에 대규모 집계 쿼리는 빠르지만, 특정 레코드 하나를 꺼내는 **포인트 쿼리(point query)**는 구조적으로 불리하다. Parquet 파일 전체 또는 상당 부분을 스캔해야 하기 때문이다.
이 문제를 해결하는 기존 방식은 대부분 데이터를 운영 DB(PostgreSQL, DynamoDB 등)로 복제하는 것이었다. 분석 레이크와 온라인 서비스용 DB를 별도로 관리하면 데이터 이중화, 싱크 지연, 운영 비용이 모두 증가한다. Spotify는 이 근본적인 구조적 문제를 다른 방향으로 접근했다.
Spotify의 외부 인덱싱 아키텍처
Spotify가 도입한 핵심 아이디어는 Parquet 파일 자체는 건드리지 않고, 조회 키 → Parquet 파일 경로 + 행(row) 위치를 매핑하는 외부 인덱스를 별도로 관리하는 것이다. 클라이언트가 특정 키로 조회 요청을 보내면, 인덱스에서 해당 레코드가 어느 파일의 몇 번째 행에 있는지를 먼저 확인하고, 클라우드 오브젝트 스토리지에서 그 부분만 정밀하게 읽어온다.
[클라이언트 요청: userId=12345]
↓
[외부 인덱스 조회]
→ file: s3://lake/part-00042.parquet
→ row offset: 8192
↓
[S3 Range Read: 해당 row group만 fetch]
↓
[응답 반환]
이 방식의 핵심은 Parquet의 row group 단위로 범위 읽기(range read)를 수행한다는 점이다. 클라우드 스토리지의 HTTP Range 요청을 활용하면 수백 MB짜리 파일 전체를 내려받지 않고도 필요한 수 KB~수십 KB만 가져올 수 있다. 외부 인덱스의 정확도가 곧 I/O 효율과 지연 시간을 결정한다.
단일 레이크로 OLAP와 온라인 서비스를 통합하는 실무적 의미
이 아키텍처가 실무적으로 중요한 이유는 동일한 데이터셋을 분석, ML, 온라인 서비스가 공유할 수 있다는 점이다. 기존에는 ML 학습용 데이터는 레이크에, 서빙용 피처는 피처 스토어나 운영 DB에 따로 적재해야 했다. 데이터 파이프라인이 분기되면 일관성 유지 비용이 커진다.
Spotify의 접근법은 이 분기를 제거한다. 인덱스만 잘 관리된다면 레이크에 있는 Parquet 파일이 곧 서빙 레이어의 데이터 소스가 될 수 있다. 이는 아래와 같은 실무 이점으로 이어진다.
- 데이터 이중화 제거: 운영 DB로의 복제 파이프라인 불필요
- 일관성 보장: 단일 소스에서 분석·서빙이 동시에 읽으므로 싱크 이슈 없음
- 운영 비용 절감: 별도 운영 DB 인프라 유지 비용 감소
- ML/AI 서빙 통합: 학습에 쓴 데이터를 그대로 온라인 추론에 활용 가능
Java 백엔드 관점에서 보면, 이런 아키텍처는 서비스 레이어에서 데이터 소스 추상화가 중요해짐을 의미한다. 인덱스 조회와 오브젝트 스토리지 range read를 감추는 레포지토리 계층을 잘 설계해야 한다.
public interface TrackRepository {
Optional<Track> findById(String trackId); // 내부: 외부 인덱스 → S3 range read
}
정리
- Parquet 외부 인덱스는 조회 키를 파일 경로·행 위치에 매핑해 클라우드 스토리지 range read로 저지연 포인트 쿼리를 실현한다.
- 데이터를 운영 DB로 복제하지 않아도 분석·ML·온라인 서비스가 단일 레이크를 공유할 수 있어 이중화와 싱크 문제를 근본적으로 해소한다.
- 실무 적용 시 인덱스 정확도와 row group 크기 튜닝이 성능의 핵심 변수이며, 서비스 레이어에서는 데이터 접근 방식을 추상화하는 설계가 중요하다.