본문으로 건너뛰기

S3 Parquet를 DuckDB로 조회하기

· 약 4분

분석용 데이터를 별도 DB로 옮기지 않고, S3에 Parquet로 쌓아 DuckDB로 직접 SQL 조회하는 방법을 정리합니다.

결론부터 말하면, 분석용 데이터는 운영 DB로 옮기지 말고 S3에 Parquet로 쌓아 두고, DuckDB로 그 파일을 직접 SQL 조회합니다. 별도 분석 DB나 무거운 ETL 없이 읽기 전용 분석이 됩니다.

Parquet와 DuckDB란​

Parquet는 열(컬럼) 단위로 저장하는 파일 형식이고, DuckDB는 파일을 직접 읽어 SQL을 돌리는 가벼운 분석용 DB입니다. 둘을 합치면 S3에 올려 둔 Parquet 파일을 옮기지 않고 그대로 조회할 수 있습니다.

서류함에 비유할 수 있습니다. 행 단위 저장(CSV 등)이 서류를 통째로 묶어 두는 것이라면, Parquet는 항목별 칸으로 정리해 둔 서류함입니다. "이름 칸만 보고 싶다"면 그 칸만 꺼내면 됩니다.

왜 DB로 옮기지 않나​

운영 DB에 분석 쿼리를 직접 돌리면 무거운 집계가 서비스 트래픽과 자원을 다툽니다. 그렇다고 본격 데이터 웨어하우스를 두기엔 무겁고 비쌉니다.

그 중간이 S3 Parquet + DuckDB입니다. 데이터는 S3에 값싸게 쌓아 두고, 분석할 때만 DuckDB가 필요한 부분을 읽습니다. 운영 DB는 건드리지 않고, 상시 떠 있는 분석 서버도 필요 없습니다.

운영 DB에 분석 쿼리를 직접 돌리면 트래픽과 자원을 다투는 경우와, S3 Parquet에 쌓고 DuckDB로 필요할 때만 읽는 구조 비교

조회 방법 (S3 직접 쿼리)​

DuckDB에 S3 접근 확장(httpfs)을 올리면, S3 경로를 테이블처럼 바로 조회할 수 있습니다.

INSTALL httpfs; LOAD httpfs;
SET s3_region = 'ap-northeast-2';

-- S3 의 Parquet 를 직접 조회
SELECT count(*)
FROM read_parquet('s3://my-bucket/events/2026-06-19/*.parquet');

여러 파일은 글롭(*)으로 한 번에 읽습니다. 별도 적재(load) 단계가 없습니다.

빠르게 만드는 법 (파티셔닝)​

빠르게 만드는 핵심은 날짜 같은 기준으로 폴더를 나눠 저장(파티셔닝)하는 것입니다. 쿼리 조건에 그 기준이 들어가면, DuckDB는 해당 폴더만 읽고 나머지는 건너뜁니다(파티션 프루닝).

-- dt=YYYY-MM-DD 로 폴더가 나뉘어 있으면
SELECT user_id, count(*)
FROM read_parquet('s3://my-bucket/events/*/*.parquet', hive_partitioning = true)
WHERE dt = '2026-06-19'        -- 이 폴더만 읽음
GROUP BY user_id;

여기에 Parquet의 컬럼 저장 특성이 더해집니다. SELECT user_id만 하면 그 열만 읽고 나머지 열은 디스크에서 읽지도 않습니다. 파티션으로 파일 수를 줄이고, 컬럼으로 읽는 양을 줄이는 것이 핵심입니다.

파티션 프루닝으로 해당 날짜 폴더만 읽고, 컬럼 저장으로 필요한 열만 읽어 읽는 양을 줄이는 원리

흔한 함정​

  • 작은 파일이 너무 많음: 이벤트를 건건이 작은 파일로 쌓으면 파일이 수만 개가 됩니다. 파일 하나하나 여는 비용이 커집니다. 주기적으로 묶어 적당한 크기(수십~수백 MB)로 만듭니다(compaction).
  • 파티션을 안 타는 쿼리: WHERE에 파티션 기준(dt 등)이 없으면 전체를 스캔합니다. 조회는 가능한 한 파티션 조건을 겁니다.
  • 읽기 전용이라는 점: 이 방식은 분석 조회에 맞습니다. 잦은 갱신·트랜잭션이 필요한 데이터는 운영 DB에 둡니다.

Q&A​

  • 운영 DB 데이터를 어떻게 S3 Parquet로 보내나요?
    • 보통 이벤트나 변경분을 주기적으로 Parquet로 내보내(export) S3에 적재합니다. 실시간이 필요하면 스트리밍으로, 아니면 배치로 충분합니다.
  • DuckDB를 어디서 실행하나요?
    • 임베디드라 분석 코드 안에서 바로 띄웁니다. 상시 서버가 필요 없고, 조회할 때만 프로세스가 S3를 읽습니다.
  • 데이터가 아주 커지면요?
    • 파티셔닝과 compaction으로 상당히 버팁니다. 그 이상으로 커지고 동시 사용자가 많아지면, 그때 본격 데이터 웨어하우스를 검토합니다.

참고자료​

  • DuckDB Docs: httpfs / read_parquet / Hive Partitioning
  • Apache Parquet: 컬럼형 저장 형식