요약
Ducklake는 표 메타데이터는 SQL 데이터베이스에, 데이터는 Parquet 파일에 두는 데이터 레이크 형식입니다.
DuckDB 팀이 GitHub에 공개한 저장소로, Ducklake 표를 DuckDB에서 읽고 쓰게 해 주는 확장 기능입니다. README는 Ducklake를 SQL과 Parquet로 만든 개방형 레이크하우스(파일로 쌓은 데이터를 데이터베이스 표처럼 다루는 구조) 형식으로 소개합니다.
왜 중요한가
- 어떤 파일이 현재 유효한지 같은 기록을 파일 대신 데이터베이스에 맡겨 레이크 구조가 단순해집니다.
- 형식 자체는 공개 사양이라 DuckDB가 아닌 엔진도 구현할 수 있고, 실제로 DataFusion용 구현이 나왔습니다.
핵심 내용
- 카탈로그(표를 이루는 파일과 버전을 기록하는 저장소)로 DuckDB 파일, PostgreSQL, SQLite를 쓸 수 있습니다.
- 표 데이터는 사용자가 지정한 경로에 Parquet 파일로 저장됩니다.
- DuckDB에서
INSTALL ducklake로 설치하고ATTACH로 연결한 뒤 일반 SQL로 표를 만들고 고칩니다. - 스냅샷 버전을 지정해 과거 상태를 조회하는 시간 여행, 열 추가 같은 스키마 변경, 스냅샷별 변경 내역 조회를 지원합니다.
- MIT 라이선스로 공개됐습니다.
HN 반응
- Ducklake가 DuckDB 전용이 아닌 사양이라는 점이 덜 알려졌다는 지적과 함께, DataFusion용 구현이 Iceberg보다 가볍다는 경험담이 나왔습니다.
- 사양은 1.0이지만 소프트웨어는 아직 불안정해 버그 목록부터 보라는 조언과, 잘 돌아가면 Parquet 저장 구조를 직접 짜는 것보다 낫다는 평가가 함께 나왔습니다.
널리 알려지거나 이해되고 있지는 않은 것 같은데, Ducklake는 duckdb가 필요하지 않습니다. duckdb에서 돌아가는 (좋은) 데이터 레이크 명세일 뿐입니다.
https://github.com/datafusion-contrib/datafusion-ducklake 에서는 rust/datafusion 기반의 또 다른 생태계 프로젝트도 진행되고 있고, Quack 프로토콜 덕분에 멋진 가능성이 많이 열릴 것 같습니다.
ducklake를 어디에 쓸지 아이디어가 필요하다면, 에이전트 트레이스를 전부 여기에 넣어 보시길 권합니다.
언급해 주셔서 감사합니다.
배경을 말씀드리면, 저희는 예전에 특정 용도에 맞춰 최적화한 커스텀 카탈로그를 직접 만들어 썼습니다. 그런데 유지보수가 어려웠고, 요구사항이 바뀔 때는 특히 더 그랬습니다. Apache Iceberg는 저희의 저지연 작업에는 너무 무거웠고요.
Ducklake는 명세일 뿐이라서 저희가 datafusion-ducklake를 구현했는데, 직접 만든 어떤 커스텀·특화 카탈로그와 견줘도 성능이 뒤지지 않습니다. 카탈로그 저장소로는 Postgres를 쓰는데, 이보다 단순하기도 어렵습니다. 트랜잭션 데이터에는 트랜잭션 데이터베이스를 쓰는 것입니다.
게다가 타임 트래블, 스냅샷처럼 복잡한 부분을 구현할 때 따를 명확한 명세가 있습니다.
정말 구세주 같은 존재였습니다.
기여자는 언제든 환영하고, 적극 권장합니다!
목표로 하신 지연 시간이 어느 정도였나요?
1초 미만의 응답 시간에서 극도로 높은 동시성을 처리하는 것입니다.
Ducklake 블로그에 정리한 글이 있습니다. https://ducklake.select/2026/07/29/bringing-ducklake-to-datafusion/
전혀 몰랐네요!
저는 카탈로그가 duckdb 파일인 줄로만 알았어요. 예를 들어 데이터는 파티션된 parquet 파일에 있고, 어떤 parquet 파일이 최신인지, 소프트 삭제됐는지 같은 정보는 duckdb 데이터 파일에서 관리하는 식으로요.
그런데 https://ducklake.select/ 를 보니 카탈로그가 PostgresSQL에 있는 것 같네요. 그러면 ducklake가 아니라 postgresslake잖아요.
살면서 하나 배웠네요.
사이트에 탭 인터페이스가 있는데 기본값이 postgres일 뿐이에요. SQLite와 duckdb도 지원합니다.
Motherduck이 DuckLake 웹 페이지에서 오라일리의 "DuckLake: The Definitive Guide" 책을 무료로 나눠 주고 있습니다.
https://motherduck.com/product/ducklake/
좋네요, 감사합니다!
나쁘지 않아요, 그래도 꽤 알파 단계 소프트웨어예요. 제가 알기로 v1.5.4에서는 카탈로그 필터 카운트가 망가져 있어요. 고치려고 main/v2로 갔더니 이번엔 duckdb v2의 SQL 파서가 10배 느려져서 또 발목을 잡더라고요. 솔직히 좀 고생스러웠어요.
맞습니다. 명세는 1.0으로 냈지만 소프트웨어는 1.0 수준이 아닙니다. 쓰기 전에 버그 목록을 훑어보세요.
잘 돌아갈 때는 정말 좋습니다. 여러 단계의 parquet 저장소를 직접 만드는 것보다는 확실히 낫고요.
맞아요. 저도 정말 좋아하지만, 지금은 포크를 써야 해요.
그런데 "Duckpond"가 바로 거기 있었잖아요!
다른 생에서라면 가능했겠죠.
우아한 설계이고 경쟁 제품보다 뛰어나다고 생각합니다. 다만 레이크하우스가 벤더들이 우리에게 믿게 하려는 만큼 범용으로 쓸모 있지는 않다고 봅니다. 접근 제어가 밑바탕 버킷에서 가능한 수준으로 제한되기 때문입니다.
예를 들어 일반적인 기업 BI 유형의 분석에는 레이크하우스가 나쁜 선택이라고 생각합니다. 컬럼이나 행 단위 접근 제어도, 컬럼 마스킹도 없으니까요. 이걸 버킷과 카탈로그 위에 나중에 덧붙일 수 있을 것 같지가 않습니다.
https://www.tomwphillips.co.uk/2026/08/the-benefits-of-data-lakehouses-are-overstated/
DuckDB는 1990년대 이후 세상에 나온 최고의 물건입니다.
https://duckdb.org/2025/05/19/the-lost-decade-of-small-data.html
SQLite를 빼먹으셨네요. 그래도 동의합니다.
이건 기본적으로 Delta/Iceberg 같은 테이블 포맷인데 DuckDB로 SQL 엔진이 내장된 것이라고 보면 되나요?
아니요, 제가 이해하기로는 델타 로그(어떤 데이터 파일이 실제로 유효한지 알려 주는 파일)를 json/parquet로 저장하지 않고 곧바로 데이터베이스에 저장합니다.
훨씬 빠르지만 의존성이 하나 늘어납니다. 다만 데이터베이스 기반 카탈로그(카탈로그가 그런 종류만 있는 것은 아닙니다)를 쓰면 어차피 생겼을 의존성입니다.
아, 그렇군요. 감사합니다. 메타데이터를 DB에 두는 쪽이 훨씬 견고할 것 같네요.
왜 새 프로젝트를 C++로 짜는 거죠? "Rust로 만들었다"가 밈인 건 알지만, 진지하게 2026년에 왜 메모리 안전 언어를 안 쓰는 거예요?
DuckDB는 2018년부터 있었습니다. 그 후속 프로젝트가 C++을 쓰는 건 당연합니다.
Rust는 2010년에 나왔습니다. 2016년에는 이미 "가장 사랑받는 언어"로 꼽혔고, 시스템 프로그래머들은 2018년이면 이미 도입한 상태였습니다.
게다가 컴파일러는 2023년까지 x86_84에서 큰 프로젝트를 빌드하기엔 끔찍하게 느렸어요.