DuckLake — SQL과 Parquet 기반 오픈 레이크하우스 형식

AI 요약

DuckLake는 SQL과 Parquet를 바탕으로 만든 오픈 레이크하우스 형식입니다. 테이블 데이터는 Parquet 파일에 저장하고, 파일 상태와 스냅샷 같은 메타데이터는 카탈로그 데이터베이스에서 관리합니다. DuckDB 확장을 설치하면 DuckDB에서 DuckLake를 직접 읽고 쓸 수 있습니다.

설치와 사용

DuckDB에서 INSTALL ducklake;을 실행해 확장을 설치합니다. 데이터베이스는 ATTACH 'ducklake:metadata.ducklake' AS my_ducklake (DATA_PATH 'file_path/');처럼 연결합니다. 이 예시에서는 metadata.ducklake 파일에 메타데이터를 저장하고 file_path/에 Parquet 파일을 둡니다. 연결한 뒤에는 CREATE TABLE, INSERT, UPDATE, ALTER TABLE 등 표준 SQL로 테이블을 만들고 수정합니다.

스냅샷과 변경 내역

예제는 값을 갱신한 뒤 AT (VERSION => 2)로 이전 스냅샷을 조회합니다. 갱신 전 값인 World가 반환됩니다. table_changes('my_table', 2, 2)를 호출하면 해당 스냅샷의 행 변경 내역을 확인합니다. 예제에서는 두 행이 insert로 표시됩니다. 컬럼 추가도 일반 SQL로 실행하며, 기존 행의 새 컬럼 값은 NULL로 나타납니다.

빌드와 테스트

저장소는 서브모듈을 초기화하고 갱신한 뒤 make로 빌드합니다. 여러 코어를 쓰려면 make GEN=ninja release를 실행합니다. 테스트는 전체 실행, 파일별 실행, 패턴별 실행이 가능하며 DuckLake의 카탈로그로 PostgreSQL이나 SQLite를 지정하거나 삭제 벡터를 켜는 설정도 제공합니다.

Hacker News 반응

• @smithclay — 널리 알려지거나 이해되지는 않은 것 같은데, DuckLake는 DuckDB가 없어도 됩니다. DuckDB에서 작동하는 좋은 데이터 레이크 명세입니다. DataFusion 생태계에서도 datafusion-ducklake라는 흥미로운 구현을 진행하고 있고, Quack 프로토콜도 여러 가능성을 열어줍니다. DuckLake를 어디에 쓸지 아이디어가 필요하다면 에이전트 추적 데이터를 전부 넣어보길 권합니다.
  • @eddietejeda — 언급해주셔서 감사합니다. 이전에는 특정 용도에 맞춘 카탈로그를 직접 만들었지만, 요구 사항이 바뀔 때마다 유지보수가 어려웠습니다. Apache Iceberg는 저희 저지연 작업에 비해 너무 무거웠습니다. DuckLake는 명세만 제공하므로 datafusion-ducklake를 구현했고, 저희가 만든 어떤 맞춤형 카탈로그나 특화 카탈로그만큼 성능이 나옵니다. 카탈로그 저장소로 PostgreSQL을 쓰는데, 트랜잭션 데이터를 트랜잭션 데이터베이스에 두니 더 간단할 수 없습니다. 타임 트래블이나 스냅샷 같은 복잡한 부분을 구현할 명확한 명세도 얻었습니다. 큰 도움이 됐습니다. 기여자를 환영합니다.
  • @prpl — 목표로 삼은 지연 시간은 어느 정도였나요?
  • @eddietejeda — 매우 높은 동시성에서 1초 미만 응답 시간이었습니다. DuckLake 블로그에 쓴 글이 있습니다.
  • @wodenokoto — 카탈로그가 DuckDB 파일일 필요는 없다는 걸 몰랐습니다. 데이터는 파티션된 Parquet 파일에 있고, 어떤 파일이 현재 유효한지 또는 소프트 삭제됐는지는 DuckDB 데이터 파일에서 관리한다고 생각했습니다. 사이트를 보니 카탈로그가 PostgreSQL에 있는 것 같아서 DuckLake라기보다 PostgreSQL Lake 아닌가 싶었습니다. 새로 알았네요.
  • @paragraft — 사이트는 탭 인터페이스이고 기본값이 PostgreSQL일 뿐입니다. SQLite와 DuckDB도 지원합니다.
• @engineeringwoke — 괜찮긴 하지만 꽤 초기 단계 소프트웨어입니다. v1.5.4에서는 카탈로그 필터링 개수가 잘못 나온다고 알고 있습니다. 고치려고 main/v2로 갔더니 DuckDB v2의 SQL 파서가 10배 느려져서 또 문제가 생겼습니다. 솔직히 쓰기가 꽤 까다로웠습니다.
  • @jauco — 맞습니다. 명세는 1.0이 됐지만 소프트웨어는 1.0이 아닙니다. 쓰기 전에 버그 목록을 살펴보세요. 잘 작동할 때는 정말 좋고, 다단계 Parquet 저장소를 직접 만드는 것보다는 낫습니다.
  • @engineeringwoke — 전적으로 동의합니다. 좋아하지만 당분간은 포크가 필요합니다.
• @snapetom — DuckDB를 SQL 엔진으로 내장한 Delta나 Iceberg 같은 테이블 형식인가요?
  • @Lucasoato — 제가 이해한 바로는 아닙니다. 어떤 데이터 파일이 유효한지 기록하는 델타 로그를 JSON이나 Parquet가 아니라 데이터베이스에 저장합니다. 더 빠르지만 의존성이 추가됩니다. 데이터베이스 기반 카탈로그를 쓰는 경우라면 어차피 추가했을 의존성이긴 합니다. 카탈로그 선택지가 그것만 있는 건 아닙니다.
  • @snapetom — 알겠습니다. 메타데이터를 데이터베이스에 두는 편이 더 견고해 보이네요.
• @tomwphillips — 우아한 설계이고 경쟁 제품보다 낫다고 생각합니다. 다만 레이크하우스는 공급업체들이 말하는 만큼 두루 유용하지는 않습니다. 접근 제어가 기반 버킷에서 가능한 범위에 한정됩니다. 행·열 접근 제어와 열 마스킹이 없으므로 일반적인 엔터프라이즈 BI 분석에는 레이크하우스가 나쁜 선택이라고 봅니다. 버킷과 카탈로그에 이 기능을 어떻게 추가할 수 있을지 모르겠습니다.
• @loufe — 2026년에 새로 시작하는 프로젝트를 왜 C++로 만들었나요? Rust가 밈인 건 알지만, 메모리 안전 언어를 쓰면 안 되나요?
  • @esafak — DuckDB는 2018년부터 있었으니 파생 프로젝트가 C++를 쓰는 건 자연스럽습니다.
  • @OutOfHere — Rust는 2010년부터 있었습니다. 2016년에는 이미 가장 사랑받는 언어로 꼽혔고, 2018년에는 시스템 프로그래머들이 채택했습니다.
  • @meredithbloom — x86_64에서 큰 프로젝트를 빌드할 때 컴파일러가 2023년까지 끔찍하게 느렸습니다.

원문: GitHub / 번역·요약: Trawling