널리 알려지거나 이해된 것 같지는 않지만, DuckLake는 DuckDB를 필수로 요구하지 않음. DuckDB에서 사용할 수 있는 잘 만든 데이터 레이크 명세일 뿐임.
Rust/DataFusion 생태계에서도 https://github.com/datafusion-contrib/datafusion-ducklake라는 흥미로운 대안 구현이 진행 중이며, Quack 프로토콜도 여러 가능성을 열어준다고 봄.
DuckLake를 어디에 쓸지 고민이라면 에이전트 실행 추적 기록을 전부 저장해 보길 추천함.
이전에는 특정 용도에 최적화된 자체 카탈로그를 만들었지만, 요구사항이 바뀔 때마다 유지보수가 어려웠고 Apache Iceberg는 우리의 저지연 작업에 쓰기에는 너무 무거웠음.
DuckLake는 명세일 뿐이므로 직접 datafusion-ducklake를 구현했고, 기존에 만든 맞춤형·특수 목적 카탈로그 못지않은 성능을 내고 있음. 카탈로그 저장소로 Postgres를 사용하는데, 트랜잭션 데이터에 트랜잭션 데이터베이스를 쓰니 이보다 단순하기도 어려움.
과거 시점 조회와 스냅샷 같은 복잡한 기능에도 명확한 구현 명세가 생겨 정말 큰 도움이 됨. 기여도 적극 환영함!
나쁘지는 않지만 아직 알파 수준의 소프트웨어임. 내가 알기로 v1.5.4에서는 카탈로그에서 필터를 적용한 개수 집계가 제대로 작동하지 않음.
이를 해결하려고 main/v2로 옮겼더니 이번에는 DuckDB v2의 SQL 파서가 10배 느려져 또 발목을 잡힘. 솔직히 꽤 고생하는 중임.
명세가 1.0이지 소프트웨어가 1.0 수준인 것은 아님. 사용 전에 버그 목록을 살펴보길 권함.
잘 작동할 때는 정말 좋고, 여러 계층의 Parquet 저장소를 직접 구현하는 것보다는 나음.
기본적으로 Delta/Iceberg 같은 테이블 포맷에 DuckDB를 통한 SQL 엔진이 내장된 구조인가?
아님. 내가 이해하기로는 어떤 데이터 파일이 유효한지 나타내는 델타 로그를 JSON/Parquet 파일이 아니라 데이터베이스에 직접 저장하는 구조임.
훨씬 빠르지만 의존성이 추가됨. 다만 데이터베이스 기반 카탈로그를 쓸 거였다면 어차피 생겼을 의존성임. 물론 모든 카탈로그가 데이터베이스 기반인 것은 아님.
왜 신규 프로젝트를 C++로 개발하는 걸까? “Rust로 만들었음”이 밈인 건 알지만, 정말로 2026년에 메모리 안전 언어를 쓰지 않는 이유가 뭘까?
DuckDB는 2018년부터 개발되어 온 프로젝트임. 그 파생 프로젝트도 자연스럽게 C++를 쓰게 됨.