Pg_lake - Postgres에서 Iceberg 및 데이터 레이크 접근을 지원하는 확장

(github.com/Snowflake-Labs)

3P by GN⁺ 4일전 | ★ favorite | 댓글 1개

pg_lake은 Postgres를 기반으로 Iceberg 테이블과 데이터 레이크 파일을 직접 통합해 트랜잭션과 고속 쿼리를 지원하는 확장
S3 등 객체 스토리지의 Parquet, CSV, JSON, Iceberg 파일을 직접 조회·가져오기·내보내기 가능
DuckDB 쿼리 엔진을 내부적으로 활용해 Postgres 환경 내에서 빠른 실행 성능 확보
Iceberg 테이블 생성, 외부 파일 자동 스키마 추론, COPY 명령을 통한 S3 입출력 등 데이터 레이크하우스 기능을 단일 SQL 인터페이스로 제공
Snowflake가 2025년 Crunchy Data 인수 후 오픈소스로 공개, Postgres 생태계에서 데이터 레이크 통합을 확장하는 기반

pg_lake 개요

pg_lake은 Iceberg 및 데이터 레이크 파일을 Postgres에 통합하는 확장 기능으로, Postgres를 독립형 레이크하우스 시스템으로 활용 가능
- Iceberg 테이블에 대한 트랜잭션 보장 및 빠른 쿼리 지원
- S3 등 객체 스토리지의 원시 데이터 파일 직접 접근 가능
주요 기능
- Iceberg 테이블 생성·수정 및 다른 엔진에서 쿼리 가능
- Parquet, CSV, JSON, Iceberg 형식의 데이터 파일 조회 및 가져오기
- COPY 명령으로 쿼리 결과를 Parquet, CSV, JSON 형식으로 객체 스토리지에 내보내기
- GDAL이 지원하는 GeoJSON, Shapefile 등 지리공간 데이터 형식 읽기
- 반정형 데이터용 내장 map 타입 제공
- heap, Iceberg, 외부 파일을 단일 SQL 쿼리에서 결합 가능
- 외부 데이터 소스에서 컬럼과 타입 자동 추론
- DuckDB 엔진을 통한 고속 실행

설치 및 구성

설치 방법
- Docker를 이용한 간편 실행
- 소스 빌드를 통한 수동 설치 또는 개발 환경 구축
확장 생성 예시
```
CREATE EXTENSION pg_lake CASCADE;  
```
- 관련 확장: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
pgduck_server
- Postgres 와이어 프로토콜을 구현한 독립 프로세스로, 내부적으로 DuckDB를 사용
- 기본 포트 5332에서 동작하며 psql로 직접 접속 가능
- 주요 설정
  - --memory_limit: 메모리 제한 (기본 시스템 메모리의 80%)
  - --init_file_path: 시작 시 실행할 SQL 파일 지정
  - --cache_dir: 원격 파일 캐시 디렉터리 지정
S3 연결 설정
- DuckDB의 secrets manager를 사용해 AWS/GCP 자격 증명 자동 인식
- Iceberg 테이블 저장 위치 지정 예시
```
SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake">s3://testbucketpglake';  
```

사용 예시

Iceberg 테이블 생성
```
CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;  
```
- 생성 후 SELECT count(*) FROM iceberg_test; 결과 100
- Iceberg 메타데이터 위치 확인 가능

S3로 COPY 입출력

COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet">s3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet">s3://.../iceberg_test.parquet';

Parquet, CSV, JSON 형식 지원

S3 파일을 외부 테이블로 생성

CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet">s3://.../*.parquet');

컬럼 자동 추론, 쿼리 가능 (SELECT count(*) FROM parquet_table; → 100)

아키텍처

구성 요소
- PostgreSQL + pg_lake 확장
- pgduck_server (DuckDB 실행 및 Postgres 프로토콜 구현)
동작 방식
- 사용자는 Postgres에 접속해 SQL 실행
- 쿼리 일부는 DuckDB를 통해 병렬·컬럼 지향 방식으로 실행
- DuckDB를 Postgres 프로세스 내부에 임베드하지 않아 스레드·메모리 안전성 문제 회피
- 표준 Postgres 클라이언트를 통해 DuckDB 엔진에 직접 접근 가능

구성 요소 세부 목록

pg_lake_iceberg: Iceberg 스펙 구현
pg_lake_table: 객체 스토리지 파일용 FDW 구현
pg_lake_copy: 데이터 레이크로 COPY 입출력 지원
pg_lake_engine: 공통 모듈
pg_extension_base: 다른 확장의 기반 구성요소
pg_extension_updater: 확장 자동 업데이트 기능
pg_lake_benchmark: 레이크 테이블 벤치마크 수행
pg_map: 일반화된 map 타입 생성기
pgduck_server: DuckDB를 로드해 Postgres 프로토콜로 노출하는 서버
duckdb_pglake: DuckDB에 Postgres 호환 함수 추가

개발 및 공개 이력

2024년 초 Crunchy Data에서 Iceberg를 Postgres에 도입하기 위해 개발 시작
초기에는 DuckDB 통합 및 Crunchy Bridge 고객 대상 기능 제공
이후 Iceberg v2 프로토콜과 트랜잭션 지원 구현
2024년 11월 Crunchy Data Warehouse로 재출시
2025년 6월 Snowflake가 Crunchy Data 인수, 2025년 11월 pg_lake 오픈소스 공개
- 초기 버전은 3.0 (이전 두 세대 포함)
- 기존 Crunchy Data Warehouse 사용자는 자동 업그레이드 경로 제공

라이선스 및 의존성

Apache 2.0 라이선스
Apache Avro 및 DuckDB 프로젝트에 의존
- 빌드 시 Avro 및 DuckDB 확장에 패치 적용

▲

GN⁺ 4일전 [-]

Hacker News 의견

그냥 Ducklake을 쓰면 안 되는 이유가 있을까 하는 생각임
그렇게 하면 복잡도 감소가 가능함. 필요한 건 DuckDB와 PostgreSQL(pg_duckdb)뿐임
참고로 Prof. Hannes Mühleisen의 발표 영상 DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us도 있음
- DuckLake은 꽤 멋진 프로젝트임. 우리 팀도 DuckDB를 좋아함. 사실 pg_lake가 가능해진 것도 DuckDB 덕분임
  DuckLake이 Iceberg 기반의 pg_lake가 못 하는 걸 할 수 있고, 반대로 Postgres는 DuckDB가 못 하는 걸 할 수 있음. 예를 들어 초당 10만 건 이상의 단일 행 삽입을 처리할 수 있음
  트랜잭션 처리는 공짜가 아님. 엔진을 카탈로그 안에 넣는 대신 카탈로그를 엔진 안에 넣으면 분석용과 운영용 테이블 간 트랜잭션이 가능해짐
  Postgres는 지속성(persistence)과 연속 처리 측면에서도 자연스러움. pg_cron과 PL/pgSQL을 이용해 오케스트레이션을 구성할 수 있음
  또한 Iceberg는 여러 쿼리 엔진과의 상호운용성도 강점임
- 결국 설계 결정의 문제임. 관련 논의는 이 스레드에서 볼 수 있음
- 나도 Ducklake을 정말 좋아하려고 노력했지만, 실제로 써보면 유지보수 문제가 있었음. 특히 pg catalog 관련해서 Ducklake이 자체 생성한 파일에 대해 HTTP 400 오류를 던지는 경우가 있었음
  내 데이터 쓰기 패턴(Polars DataFrame에서 Ducklake 테이블로 삽입) 때문인지, 파티션 테이블 구조 때문인지는 확실치 않음
  개발/테스트 환경에서는 괜찮지만 팀 전체에서는 어려움이 있었음. 그래서 결국 Hive 파티션된 Parquet 파일과 DuckDB 뷰 조합으로 돌아감
  나중에 이슈로 예시를 올릴 생각이지만, 지금은 다른 일들로 시간이 부족함
이건 정말 큰 변화임
예전엔 Postgres 시장에서 “오픈소스 Snowflake”가 없다고 말하곤 했음
Crunchy의 Postgres 확장은 현재 시장에서 가장 앞선 솔루션임. Snowflake와 Crunchy 팀이 오픈소스로 공개한 걸 축하함
- 솔직히 말하면, 그냥 Snowflake에 돈을 내고 그 훌륭한 DB와 에코시스템을 활용하는 게 낫다고 생각함. 인프라가 고객 가치의 핵심이 아니라면 그 부분은 맡기고 멋진 걸 만드는 데 집중해야 함
나는 데이터 레이크와 SQL 유사 쿼리 언어를 좋아함. “모든 것은 파일이다” 철학의 진화된 형태처럼 느껴짐
Linux에서는 파일 시스템을 통해 시스템 설정을 읽고 쓸 수 있음 (cat /sys/..., echo ... > /sys/...)
FUSE를 이용하면 사용자 공간에서 파일 시스템 드라이버를 직접 구현할 수 있음. 예를 들어 SSH나 Google Drive를 마운트해서 cp 명령으로 복사 가능함
하지만 파일 시스템은 계층적 데이터에만 적합함. 현실 세계의 데이터는 대부분 관계형 구조임
데이터 레이크는 SQL이라는 우아한 추상화를 통해 서로 다른 데이터 소스를 하나의 관계형 데이터베이스처럼 다룰 수 있게 함
결국 많은 애플리케이션이 CRUD 중심이므로, 이런 접근은 훨씬 효율적임
당신은 데이터 레이크를 어떻게 쓰는가? 나에게는 단순 저장소가 아니라 예측 불가능한 분석 작업을 위한 공간임
이런 경우 Postgres는 한계가 있음. 더 많은 CPU와 RAM이 필요하고, 결국 분산 엔진이 필요함
- 데이터 레이크의 핵심은 컴퓨트와 스토리지의 분리임. Postgres는 컴퓨트 계층이 아니라 접근 계층임
  컴퓨트는 Postgres에 “이 키들의 현재 데이터는?” 혹은 “2주 전의 데이터는?”을 묻고, 실제 분석 쿼리는 Parquet 파일에서 직접 수행함
Snowflake가 Crunchy Data를 인수했을 때, 이런 매니지드 버전을 제공하길 기대했음
로컬 Docker로 실행할 수 있는 건 좋지만, AWS에서 Snowflake 계정으로 통합 청구되는 형태로 운영할 수 있으면 좋겠음
지금은 정말 PostgreSQL의 황금기라고 느껴짐
나는 데이터 엔지니어는 아니지만 관련 분야에서 일함. 이게 어떤 문제를 해결하는지 쉽게 설명해줄 수 있는 사람이 있을까 궁금함
- 예를 들어 어떤 서비스가 S3에 Parquet 파일로 로그 데이터를 쌓는다고 하자. 이 데이터를 Postgres에서 바로 쿼리하고 싶을 때 pg_lake가 유용함
  Parquet 데이터를 Postgres로 불러와 쿼리할 수 있고, 기존 테이블과 조인도 가능함
두 가지 질문이 있음
(1) Iceberg 대신 Ducklake 스펙을 사용하도록 호환 계획이 있는가? Ducklake은 카탈로그를 파일이 아닌 SQL 테이블로 관리해 동시 쓰기나 스냅샷 관리가 더 간단함
(2) pg_duckdb가 시간이 지나면 같은 기능을 하게 될 가능성이 있는가?
- (1) 고려는 했지만 현재 계획은 없음. Ducklake을 그대로 쓰기보다는 Postgres 내부에서 직접 구현해 트랜잭션 경계를 유지하고 싶음
  다만 인라인 데이터 처리 등 복잡성이 있음. 이를 해결하면 높은 트랜잭션 성능을 얻을 수 있음
  (2) pg_duckdb는 Ducklake 구현을 재사용하기 더 쉽지만, 리소스 관리나 안정성 측면에서는 그 구조가 덜 적합하다고 봄
S3 Table Buckets, Cloudflare R2 Data Catalog, 그리고 이번 프로젝트까지 보면 Iceberg가 승리하는 분위기임
Postgres Wire 호환 DB로 데이터를 쉽게 적재하고 싶다면 sling-cli를 추천함
CLI, YAML, Python으로 ETL 작업을 실행할 수 있음

답변달기