▲

DuckLake - 통합 데이터 레이크 및 카탈로그 포맷

 (ducklake.select)
13P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • 데이터 레이크와 카탈로그 포맷을 통합한 새로운 솔루션
  • Parquet 파일과 SQL 데이터베이스를 기반으로 동작하며, 전통적인 레이크하우스보다 간결한 데이터 레이크 구현을 가능하게 함
  • PostgreSQL, SQLite, MySQL, DuckDB 등 여러 데이터베이스 위에서 메타데이터 카탈로그 관리가 가능함
  • 스냅샷, 타임 트래블 쿼리, 스키마 변경, 파티셔닝 등 다양한 기능을 지원하면서도 자주 컴팩트하지 않아도 되는 가벼운 스냅샷 처리를 제공함
  • 여러 인스턴스가 동시에 데이터를 읽고 쓰는 멀티플레이어 DuckDB 모델을 지원하며, 기본 DuckDB가 지원하지 않는 동시성 처리 모델을 구현함
  • DuckLake는 사양, DuckDB 확장, DuckLake 형식으로 저장된 데이터셋을 포괄하는 개념이며, MIT 라이선스로 공개됨

DuckLake 소개

  • DuckLake는 DuckDB 팀이 만든 오픈 포맷으로, 복잡한 레이크하우스 없이도 고급 데이터 레이크 기능을 제공함
  • SQL 데이터베이스와 Parquet 파일만 있으면 자체 데이터 웨어하우스를 구축할 수 있음.
  • 메타데이터 관리를 위해 데이터베이스를 사용 : PostgreSQL, SQLite, MySQL, DuckDB

DuckLake의 주요 기능

  • 데이터 레이크 오퍼레이션

    • 스냅샷
    • 시점 조회 (Time travel)
    • 스키마 진화
    • 파티셔닝

  • 가벼운 스냅샷 처리

    • 스냅샷 개수에 제한 없이 생성 가능
    • 자주 컴팩트할 필요 없이 동작 가능

  • ACID 트랜잭션

    • 멀티 테이블 연산에 대해 동시 접근과 트랜잭션 보장

  • 성능 지향 설계

    • 필터 푸시다운을 위한 통계 활용
    • 대용량 데이터셋에서도 빠른 쿼리 가능

자주 묻는 질문

  • 왜 DuckLake를 사용해야 하나요?

    • 데이터 레이크와 카탈로그를 통합한 가벼운 솔루션 필요 시 적합
    • 여러 DuckDB 인스턴스가 동일 데이터셋을 읽고 쓰는 멀티플레이어 환경 가능
      • 이는 기존 DuckDB에서는 지원되지 않는 동시성 모델
    • DuckDB만 사용해도 시점 조회, 파티셔닝, 멀티 파일 저장 구조 등의 이점을 누릴 수 있음

  • DuckLake란 무엇인가요?

    • DuckLake는 다음 세 가지를 지칭함:
      1. DuckLake 포맷의 사양 (specification)
      2. DuckLake를 지원하는 DuckDB 확장 기능 (ducklake extension)
      3. DuckLake 포맷으로 저장된 데이터셋 자체

  • DuckLake의 라이선스는?

    • MIT 라이선스로 공개됨
▲
GN⁺ 7일전  [-]
Hacker News 의견

  • Parquet에서 항상 아쉬웠던 점이 있는데, 다양한 “data lake / lakehouse”들이 호환되지 않게 따로 해결한 ‘ranged partitioning’ 관련 부분에 아쉬움이 있음. 내 애플리케이션은 Parquet에 거의 완벽하게 들어맞지만, 시계열 로그처럼 타임스탬프가 고르게 분포하지 않는 데이터를 다룸. 파티션 컬럼은 Hive 파티셔닝을 따라가는데, 동시에 타임스탬프로 자연스럽게 나누어짐. 문제는 Hive 파티셔닝이 이걸 지원하지 않아 주요 쿼리 툴들이 내 데이터 구조를 제대로 임포트하지 못함. 날짜 기준 컬럼 등 쓸데없는 방법을 도입하거나, 그냥 파일을 쌓으면 성능 문제와 비용이 큼. Iceberg, Delta Lake 등은 ranged partitioning이 되지만, 난 이런 복잡성은 필요치 않고 더 간단한 파일명이나 디렉토리 명 규칙이 표준화되면 좋겠다는 바람이 있음. 그리고 Parquet row와 Arrow row, Thrift, protobuf 등 포맷이 거의 비슷하지만 완전히 같지는 않아, 단일 row 또는 row 스트림에 대한 바이너리 포맷이 동반된다면 다양한 툴 간 상호운용성이 더 좋아질 거라 생각함

    • Parquet 파일의 footer metadata만으로 필요한 정보를 얻기에 충분하지 않은지 궁금함. 메타데이터에는 해당 컬럼의 최소/최대 타임스탬프가 들어있으니, 쿼리 시 퀴리 툴이 그 메타데이터만 읽고도 파일을 읽을지 말지 결정해서 쓸데없는 읽기를 막을 수 있음

    • 시간 데이터는 다루기 어렵지만, 방법에 따라 피할 수도 있음. 원본 시계열을 직접 쿼리하지 말고 이벤트 처리 단계에서 타임스탬프를 정규화해 저장하면 유용함. 슬라이딩 윈도우 기반으로 이벤트 시작점을 찾아 offset을 조정해, 시계열이 기준점(0)에 돌아가는 위치를 식별해서 그것을 이벤트 단위로 쓸 수 있음

    • Hive는 injected, dynamic 두 가지 파티셔닝을 지원함. 파티션 키로 UNIX 시간 기준의 hour 컬럼(에포크부터 3600초씩 증가하는 정수)을 사용 가능함. 쿼리 엔진에서 조회할 파티션 범위를 명시해야 할 수 있지만, datepartition >= a AND datepartition < b 형태로 쿼리에서 활용 가능함. Iceberg는 훨씬 단순하게 타임스탬프 범위로 사용하게 하며, 메타데이터가 필요 없는 파티션을 자동으로 제외함

    • arrow/parquet 저수준 라이브러리에서는 row group 및 데이터 페이지를 직접 제어할 수 있음. arrow-rs crate를 써서 파일 쿼리 속도를 10배 이상 개선한 경험이 있음. row group이 적은 경우도 있고, 아주 많은 경우도 있지만, 원하는 row group만 빠르게 건너뛸 수 있어 skew가 문제되지 않음. 다만, 파일당 row group이 2^15개로 제한된다는 점은 주의가 필요함

    • 이 문제는 Parquet의 문제라기보다는 Hive의 한계에 가까움. 컬럼의 min, max 정보를 보기 위해 Parquet 파일을 열어야 하지만 일단 범위 내 데이터가 아니면 추가 요청이 없음. 이런 메타데이터를 더 상위에, 예를 들어 DuckLake 같은 곳에서 활용하면 효율적임

  • Iceberg(Delta Lake도 유사하지만 개인적으로 Iceberg 쪽이 좀 더 어려움)에서 가장 불편했던 점 중 하나는 노트북이나 로컬 환경에서 써 보기 어렵다는 것임. Delta Lake는 파이썬 구현이 여러 개이지만 파편화돼 있고, Iceberg는 JVM 클러스터 셋업 등 번거로움이 많음. 나는 sqlite/postgres + duckdb + parquet 조합으로 blob storage에 저장하려 했지만 꽤 번거로웠음. DuckDB 쪽은 이렇게 고생 없이 바로 작동하고 적당한 크기의 데이터까지 자연스럽게 확장됨. DuckDB 팀이 이 분야를 잘 이해하고 있고, 정말 기대감이 큼

    • PyIceberg를 써본 적 있는지 궁금함. 순수 파이썬 구현이고 꽤 잘 작동함. SQL Catalog와 SQLite 기반 인메모리 카탈로그도 지원함
      https://py.iceberg.apache.org/

    • S3와 RDS를 쓰는 단계별 셋업 가이드가 있음. 로컬 sqlite로 바꾸는 것도 어렵지 않을 것임
      https://www.definite.app/blog/cloud-iceberg-duckdb-aws

    • 로컬에서 정말 쉽게 시도해볼 수 있음. marimo notebook에서는 코드 몇 줄로 가능함 (참고: 나는 marimo 개발자)
      https://www.youtube.com/watch?v=x6YtqvGcDBY

    • k3s와 잘 동작하는 헬름 차트를 만들까 고민 중임. datapains를 쓰면 trino도 쉽게 올릴 수 있고, 조금만 손보면 hivemetastore도 띄울 수 있음. Iceberg connector를 trino와 연동해서 전체 동작을 실험해봄. hive에 데이터를 로드해서 trino로 똑같은 테이블을 가리키게 한 뒤, select로 iceberg에 insert하면 되는 구조임. DuckDB 쪽이 정말 간단하게 동작하는 환경을 내놓으면, 업계 주도권도 가져갈 수 있을 것 같음

    • delta-io(deltalake-r 기반)는 로컬에서 매우 쉽게 동작함. pip로 설치하고 바로 카탈로그와 파일 작성 가능
      https://delta-io.github.io/delta-rs/

  • Iceberg에 대한 날카로운 비판을 잘 짚음—어차피 데이터베이스를 쓰는데 왜 메타데이터를 파일에 넣고 다뤄야 하는지 의문임. DuckLake가 DuckDB에서 벗어나 광범위하게 성공하긴 쉽지 않겠지만, 결국 카탈로그가 메타데이터까지 담당하는 구조가 되고, 기존 Iceberg 포맷은 점차 역사의 한 순간으로 사라질 수도 있다는 생각임

  • 기존 Lakehouse 시스템들(Iceberg 등)은 스키마/파일 목록 같은 중요한 테이블 정보를 S3 같은 오브젝트 스토리지에 작은 메타데이터 파일로 분산 저장함. 이 때문에 쿼리 계획, 테이블 업데이트같이 네트워크 콜이 많아져 느리거나 충돌이 잦음. DuckLake는 모든 메타데이터를 빠르고 트랜잭션성 높은 SQL 데이터베이스에 담아, 단일 쿼리로 필요한 모든 정보를 받아 효율성과 신뢰성이 훨씬 좋아짐

  • DuckLake 관련 선언문: https://ducklake.select/manifesto/

  • 나는 사내에서 deltalake-rs의 파이썬 바인딩과 duck db를 활용해 “poor man’s datalake”를 개발 중임. parquet 파일을 blob storage에 저장하는 구조임. 그러나 concurrent write에서 항상 문제가 발생함. 특정 주기마다 클라우드 함수가 API에서 데이터를 당겨오는 건 문제없음. 하지만 백필을 여러 번 돌리면 타이머 함수와 동시에 실행돼 충돌이 날 위험이 큼. 특히 백필 큐에 수백 개 작업을 쌓고 워커가 포화되면 더함

    • 파일명 끝에 무작위 suffix를 추가하는 방법이 있음

    • write 전에 json 파일에 임시 lease를 걸고 write 요청을 큐에 관리하면 충돌을 막을 수 있음

  • Iceberg의 한계, 특히 메타데이터 관리 문제를 해결하는(예: Snowflake는 FoundationDB를 사용해 메타데이터 관리, Iceberg는 blob storage까지 씀) 경쟁 솔루션
    https://quesma.com/blog-detail/…

    • 나도 비슷한 인상을 받았으나, 영상을 보면 DuckLake가 직접적인 경쟁자는 아님
      https://youtu.be/zeonmOO9jm4?t=4032
      DuckLake는 필요할 때만 Iceberg용 manifest/metadata 파일을 써서 동기화하고, 이미 Iceberg 데이터 읽기도 지원함. Iceberg의 핵심 문제를 개선한 것이지, 별도의 경쟁제품이라기보다는 Iceberg와 깔끔하게 양방향 연동되는 구조임

    • 메타데이터 뻥튀기는 상황에 따라 얼마든지 관리 가능함

      • 스냅샷 개수
      • 잦은 대규모 스키마 변경
      • 잦은 row 수준 업데이트/작은 파일이 많은 경우
      • 통계 정보 등
        예전에는 큰 스키마로 인해 마지막 항목이 문제였음. 대부분의 엔진들이 compaction, snapshot export 등 도구로 관리 지원, 다만 유저 책임인 점도 있음. S3 테이블이 일부 관리 기능을 제공함. 메타데이터가 1~5MB면 사실 문제 아님. 커밋 속도는 메타데이터 크기와 writer 수에 따라 좌우됨. 1GB 넘는 메타데이터도 직접 스크립트로 해결한 적 있음—보통은 덮어쓴 snapshot만 정리(실제 파일 삭제는 bucket policy에 위임)하거나 오래된 스키마 버전 정리해서 해결함

  • 결국 데이터베이스를 제대로 만들기 위해선 진짜 데이터베이스처럼 구축해야 함. DuckDB 팀에 감탄함

  • Mother Duck(https://motherduck.com/)과는 어떤 관계인지 궁금함. "DuckDB-powered data warehousing"을 하는 회사로, DuckLake보다 먼저 시작함

    • MotherDuck과 DuckLake는 매우 잘 통합될 예정임. MotherDuck 데이터가 DuckLake에 저장돼 확장성, 동시성, 일관성이 올라가고, 제3의 도구에서도 underlying data 접근 가능함. 최근 몇 달간 이 부분을 개발 중이며 곧 더 많은 정보를 공개할 예정임

    • MotherDuck은 여러분이 데이터를 올리면 자동 정리해주며, DuckDB로 데이터 인터페이스를 지원해줌. 더 lakehouse 같은 특징이나 blob storage 연동, DuckLake와의 추가 통합, 메타데이터 저장을 MotherDuck에 두고 싶으면 DuckLake 사용 가능함

    • MotherDuck은 duckdb를 클라우드에서 호스팅하는 서비스고, DuckLake는 훨씬 더 열린 시스템임. DuckLake에서는 S3나 EC2 등 다양한 환경에서 여러 인스턴스와 Petabyte급 웨어하우스를, 여러 리더/라이터까지, 모두 트랜잭션성으로 구축 가능함. MotherDuck에는 한 번에 한 Writer만 가능하고, 리드 레플리카는 1분 가량 레이턴시가 있고 트랜잭션성도 없음. 여러 인스턴스가 동시에 각기 다른 테이블에 쓸 수 없음. DuckLake는 저장과 컴퓨팅의 분리, 트랜잭션성 높은 메타데이터 계층도 제공함

  • duckDB를 사랑하고 DuckLake도 정말 멋지다고 느낌. 궁금한 점: 만약 지금부터 쓴다면, 회사에서 Snowflake를 운영 중일 때 애널리스트들은 각자 duckdb + 확장 기능을 로컬에 설치하고 blob store 및 datalake 확장용 데이터베이스(가령 VM에 띄운 duckdb)에 포인팅해야 함. 쿼리 실행 시 컴퓨팅은 어디서 일어나는지, 그리고 더 큰 작업을 하려면 어떻게 해야 하는지 궁금함. 모든 사용자가 거대한 duckdb VM에 ssh해서 쿼리를 돌리는 구조여야 하는지, 그런 부분 설명을 요청함

    • duckdb를 로컬로 실행하면 컴퓨팅은 각자의 PC에서 이뤄짐. 더 많은 컴퓨팅이 필요하면 VM을 띄워 사용하면 됨. 둘 다 가능함—작은 작업엔 로컬, 대규모 워크로드엔 VM으로 확장 가능함
답변달기