DuckLake - Format Danau Data dan Katalog Terpadu

 (ducklake.select)
13 poin oleh GN⁺ 2025-05-29 | 1 komentar | Bagikan ke WhatsApp
  • Solusi baru yang mengintegrasikan data lake dan format katalog
  • Berjalan berbasis file Parquet dan database SQL, serta memungkinkan implementasi data lake yang lebih ringkas dibanding lakehouse tradisional
  • Mendukung pengelolaan katalog metadata di atas berbagai database seperti PostgreSQL, SQLite, MySQL, DuckDB
  • Mendukung beragam fitur seperti snapshot, kueri time travel, perubahan skema, partisi, sekaligus menyediakan pemrosesan snapshot ringan yang tidak perlu sering dikompaksi
  • Mendukung model DuckDB multiplayer di mana beberapa instance dapat membaca dan menulis data secara bersamaan, serta mengimplementasikan model konkurensi yang tidak didukung oleh DuckDB bawaan
  • DuckLake adalah konsep yang mencakup spesifikasi, ekstensi DuckDB, dan dataset yang disimpan dalam format DuckLake, dan dirilis dengan lisensi MIT

Pengenalan DuckLake

  • DuckLake adalah format terbuka yang dibuat oleh tim DuckDB, yang menyediakan fitur data lake tingkat lanjut tanpa lakehouse yang kompleks
  • Hanya dengan database SQL dan file Parquet, Anda dapat membangun data warehouse sendiri.
  • Menggunakan database untuk pengelolaan metadata: PostgreSQL, SQLite, MySQL, DuckDB

Fitur utama DuckLake

  • Operasi data lake

    • Snapshot
    • Kueri titik waktu (Time travel)
    • Evolusi skema
    • Partisi

  • Pemrosesan snapshot ringan

    • Dapat dibuat tanpa batas jumlah snapshot
    • Dapat berjalan tanpa perlu sering melakukan kompaksi

  • Transaksi ACID

    • Menjamin akses bersamaan dan transaksi untuk operasi multi-tabel

  • Desain berorientasi performa

    • Memanfaatkan statistik untuk filter pushdown
    • Memungkinkan kueri cepat bahkan pada dataset berukuran besar

Pertanyaan yang sering diajukan

  • Mengapa harus menggunakan DuckLake?

    • Cocok saat membutuhkan solusi ringan yang mengintegrasikan data lake dan katalog
    • Memungkinkan lingkungan multiplayer di mana beberapa instance DuckDB membaca dan menulis dataset yang sama
      • Ini adalah model konkurensi yang tidak didukung di DuckDB sebelumnya
    • Bahkan hanya dengan DuckDB, Anda bisa mendapatkan manfaat seperti kueri titik waktu, partisi, dan struktur penyimpanan multi-file

  • Apa itu DuckLake?

    • DuckLake merujuk pada tiga hal berikut:
      1. Spesifikasi format DuckLake (specification)
      2. Ekstensi DuckDB yang mendukung DuckLake (ducklake extension)
      3. Dataset itu sendiri yang disimpan dalam format DuckLake

  • Apa lisensi DuckLake?

    • Dirilis dengan lisensi MIT

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-29
Komentar Hacker News

  • Ada satu hal yang selalu terasa kurang dari Parquet, yaitu soal ranged partitioning yang ditangani secara terpisah dan tidak saling kompatibel oleh berbagai “data lake / lakehouse”. Aplikasi saya hampir sepenuhnya cocok dengan Parquet, tetapi menangani data seperti log deret waktu yang distribusi timestamp-nya tidak merata. Kolom partisi mengikuti partisi Hive, namun pada saat yang sama juga terbagi secara alami berdasarkan timestamp. Masalahnya, partisi Hive tidak mendukung ini, sehingga alat kueri utama tidak bisa mengimpor struktur data saya dengan benar. Pilihannya jadi harus menambahkan cara-cara yang tidak perlu seperti kolom berbasis tanggal, atau sekadar menumpuk file yang berujung pada masalah performa dan biaya. Iceberg, Delta Lake, dan lainnya mendukung ranged partitioning, tetapi saya tidak butuh kompleksitas seperti itu dan berharap ada standarisasi aturan penamaan file atau direktori yang lebih sederhana. Selain itu, format seperti row Parquet dan row Arrow, Thrift, protobuf, dan lainnya sangat mirip tapi tidak sepenuhnya sama, jadi menurut saya interoperabilitas antartool akan jauh lebih baik jika ada format biner pendamping untuk satu row atau stream row

    • Saya penasaran apakah metadata footer pada file Parquet saja tidak cukup untuk mendapatkan informasi yang dibutuhkan. Metadata itu berisi timestamp minimum/maksimum untuk kolom terkait, jadi saat kueri, alat kueri bisa cukup membaca metadata tersebut untuk memutuskan apakah file perlu dibaca atau tidak, sehingga menghindari pembacaan yang tidak perlu

    • Data waktu memang sulit ditangani, tetapi tergantung caranya, hal itu bisa dihindari. Alih-alih mengueri deret waktu mentah secara langsung, akan berguna jika timestamp dinormalisasi dan disimpan pada tahap pemrosesan event. Dengan basis sliding window, kita bisa mencari titik awal event dan menyesuaikan offset untuk mengidentifikasi posisi saat deret waktu kembali ke titik acuan (0), lalu menggunakannya sebagai unit event

    • Hive mendukung dua jenis partisi: injected dan dynamic. Kita bisa memakai kolom hour berbasis waktu UNIX sebagai kunci partisi, yaitu bilangan bulat yang bertambah setiap 3600 detik sejak epoch. Mesin kueri mungkin mengharuskan rentang partisi yang akan dibaca dinyatakan secara eksplisit, tetapi itu bisa dipakai dalam kueri berbentuk datepartition >= a AND datepartition < b. Iceberg membuatnya jauh lebih sederhana untuk dipakai sebagai rentang timestamp, dan secara otomatis mengecualikan partisi yang tidak memerlukan metadata

    • Pada library tingkat rendah arrow/parquet, row group dan halaman data bisa dikendalikan secara langsung. Saya pernah memakai crate arrow-rs dan meningkatkan kecepatan kueri file lebih dari 10x. Kadang row group-nya sedikit, kadang sangat banyak, tetapi row group yang diinginkan bisa dilewati dengan cepat sehingga skew tidak menjadi masalah. Namun perlu diperhatikan bahwa jumlah row group per file dibatasi sampai 2^15

    • Masalah ini tampaknya lebih dekat ke keterbatasan Hive daripada masalah Parquet. Memang file Parquet harus dibuka untuk melihat informasi min/max kolom, tetapi setelah diketahui datanya tidak berada dalam rentang yang diminta, tidak ada permintaan tambahan. Akan efisien jika metadata seperti ini dimanfaatkan di lapisan yang lebih tinggi, misalnya di tempat seperti DuckLake

  • Salah satu hal yang paling tidak nyaman dari Iceberg (Delta Lake juga mirip, tetapi menurut saya pribadi Iceberg sedikit lebih sulit) adalah sulit untuk dicoba di notebook atau lingkungan lokal. Delta Lake punya beberapa implementasi Python, tetapi terfragmentasi, dan Iceberg merepotkan karena perlu setelan klaster JVM dan sebagainya. Saya ingin memakai kombinasi sqlite/postgres + duckdb + parquet dan menyimpannya di blob storage, tetapi ternyata cukup merepotkan. Sisi DuckDB justru langsung bekerja tanpa perlu perjuangan seperti itu dan meluas secara alami sampai ukuran data yang lumayan besar. Tim DuckDB benar-benar memahami bidang ini, dan saya sangat antusias

    • Apakah Anda pernah mencoba PyIceberg? Itu implementasi Python murni dan bekerja cukup baik. Mendukung SQL Catalog dan katalog in-memory berbasis SQLite
      https://py.iceberg.apache.org/

    • Ada panduan setup bertahap menggunakan S3 dan RDS. Menggantinya ke sqlite lokal juga seharusnya tidak sulit
      https://www.definite.app/blog/cloud-iceberg-duckdb-aws

    • Di lokal benar-benar bisa dicoba dengan sangat mudah. Di notebook marimo, cukup beberapa baris kode (catatan: saya pengembang marimo)
      https://www.youtube.com/watch?v=x6YtqvGcDBY

    • Saya sedang mempertimbangkan membuat Helm chart yang bekerja baik dengan k3s. Dengan datapains, trino juga bisa dijalankan dengan mudah, dan dengan sedikit penyesuaian hivemetastore pun bisa dinaikkan. Saya menguji keseluruhan alur dengan menghubungkan Iceberg connector ke trino. Strukturnya adalah memuat data ke hive, membuat trino menunjuk ke tabel yang sama, lalu melakukan insert ke iceberg lewat select. Jika DuckDB merilis lingkungan yang benar-benar bekerja sesederhana itu, mereka mungkin juga bisa mengambil kepemimpinan industri

    • delta-io (berbasis deltalake-r) bekerja sangat mudah di lokal. Instal lewat pip dan langsung bisa menulis katalog dan file
      https://delta-io.github.io/delta-rs/

  • Ini mengena sebagai kritik tajam terhadap Iceberg—kalau toh tetap memakai database, kenapa metadata harus dimasukkan ke file dan dikelola di sana? DuckLake mungkin tidak akan mudah berhasil secara luas di luar DuckDB, tetapi pada akhirnya strukturnya bisa menjadi katalog yang juga menangani metadata, dan format Iceberg yang ada sekarang mungkin perlahan hanya akan menjadi satu momen dalam sejarah

  • Sistem lakehouse yang ada saat ini (seperti Iceberg) menyimpan informasi tabel penting seperti skema/daftar file sebagai file metadata kecil yang tersebar di object storage seperti S3. Akibatnya, ada banyak network call untuk hal seperti perencanaan kueri dan pembaruan tabel, sehingga menjadi lambat atau sering bentrok. DuckLake menaruh semua metadata di database SQL yang cepat dan transaksional, sehingga semua informasi yang diperlukan bisa diambil dengan satu kueri dan efisiensi serta keandalannya jauh lebih baik

  • Manifesto terkait DuckLake: https://ducklake.select/manifesto/

  • Di internal perusahaan, saya sedang mengembangkan “poor man’s datalake” dengan memanfaatkan binding Python dari deltalake-rs dan duck db. Strukturnya menyimpan file parquet di blob storage. Namun saya selalu mengalami masalah pada concurrent write. Tidak ada masalah jika fungsi cloud secara berkala menarik data dari API. Tetapi jika backfill dijalankan berkali-kali, ada risiko ia berjalan bersamaan dengan fungsi timer dan menimbulkan bentrokan. Ini makin parah terutama saat ratusan job ditumpuk di antrean backfill dan worker menjadi jenuh

    • Ada cara dengan menambahkan suffix acak di akhir nama file

    • Konflik bisa dicegah dengan memasang lease sementara pada file json sebelum write lalu mengelola permintaan write lewat antrean

  • Solusi pesaing yang menyelesaikan keterbatasan Iceberg, khususnya masalah pengelolaan metadata (misalnya Snowflake memakai FoundationDB untuk mengelola metadata, sedangkan Iceberg bahkan memakai blob storage)
    https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

    • Saya juga mendapat kesan serupa, tetapi jika melihat videonya, DuckLake bukan pesaing langsung
      https://youtu.be/zeonmOO9jm4?t=4032
      DuckLake menulis file manifest/metadata untuk Iceberg hanya saat diperlukan untuk sinkronisasi, dan juga sudah mendukung pembacaan data Iceberg. Jadi ini lebih merupakan perbaikan atas masalah inti Iceberg, bukan produk pesaing yang terpisah, melainkan struktur yang terhubung dua arah dengan rapi ke Iceberg

    • Pembengkakan metadata sebenarnya bisa dikelola sesuai situasi

      • jumlah snapshot
      • perubahan skema besar yang sering
      • pembaruan level row yang sering / banyak file kecil
      • informasi statistik, dll.
        Dulu item terakhir menjadi masalah karena skemanya besar. Kebanyakan engine mendukung pengelolaan lewat alat seperti compaction, export snapshot, dan sebagainya, walaupun sebagian tetap menjadi tanggung jawab pengguna. Tabel S3 juga menyediakan beberapa fungsi pengelolaan. Jika metadata hanya 1~5MB, sebenarnya itu bukan masalah. Kecepatan commit ditentukan oleh ukuran metadata dan jumlah writer. Saya bahkan pernah menangani metadata di atas 1GB dengan skrip sendiri—biasanya cukup dengan membersihkan snapshot yang sudah tertimpa (penghapusan file aktual diserahkan ke bucket policy) atau membersihkan versi skema lama

  • Pada akhirnya, jika ingin membangun database dengan benar, memang harus dibangun seperti database sungguhan. Salut untuk tim DuckDB

  • Saya penasaran apa hubungan dengan Mother Duck(https://motherduck.com/). Itu perusahaan yang menyediakan "DuckDB-powered data warehousing" dan memulainya lebih dulu daripada DuckLake

    • MotherDuck dan DuckLake akan terintegrasi dengan sangat baik. Data MotherDuck akan disimpan di DuckLake sehingga skalabilitas, konkurensi, dan konsistensinya meningkat, dan tool pihak ketiga juga bisa mengakses underlying data. Bagian ini sedang dikembangkan dalam beberapa bulan terakhir dan lebih banyak informasi akan segera diumumkan

    • MotherDuck adalah layanan yang otomatis merapikan data saat Anda mengunggahnya dan menyediakan antarmuka data lewat DuckDB. Jika Anda menginginkan karakteristik yang lebih mirip lakehouse, integrasi blob storage, integrasi tambahan dengan DuckLake, atau ingin metadata disimpan di MotherDuck, maka Anda bisa memakai DuckLake

    • MotherDuck adalah layanan yang meng-host duckdb di cloud, sedangkan DuckLake adalah sistem yang jauh lebih terbuka. Di DuckLake, Anda bisa membangun warehouse berskala petabyte dengan banyak instance dan banyak reader/writer secara transaksional di berbagai lingkungan seperti S3 atau EC2. Di MotherDuck, hanya satu writer yang dimungkinkan pada satu waktu, read replica memiliki latensi sekitar 1 menit dan juga tidak transaksional. Banyak instance juga tidak bisa menulis ke tabel yang berbeda secara bersamaan. DuckLake juga menyediakan pemisahan storage dan compute, serta lapisan metadata yang sangat transaksional

  • Saya suka duckDB dan merasa DuckLake juga sangat keren. Pertanyaan saya: kalau mulai memakainya sekarang, misalnya perusahaan sudah menjalankan Snowflake, maka para analis harus memasang duckdb + extension secara lokal dan mengarahkannya ke blob store serta database untuk ekstensi datalake (misalnya duckdb yang dijalankan di VM). Saat kueri dijalankan, komputasinya terjadi di mana, dan bagaimana jika ingin menjalankan pekerjaan yang lebih besar? Apakah strukturnya semua pengguna harus SSH ke VM duckdb besar untuk menjalankan kueri? Saya ingin penjelasan soal bagian ini

    • Jika duckdb dijalankan secara lokal, komputasi terjadi di PC masing-masing. Jika butuh komputasi lebih besar, cukup jalankan di VM. Keduanya memungkinkan—lokal untuk pekerjaan kecil, dan diperluas ke VM untuk workload yang lebih besar