· kaynak Hacker News – Front Page (native)
DuckDB'nin DuckLake eklentisi, SQL ve Parquet üzerine kurulu açık bir lakehouse'u okuyup yazıyor
Yeni bir DuckDB eklentisi, DuckLake'i ekliyor; meta veriyi SQL katalog veritabanında, veriyi ise Parquet dosyalarında tutan bu açık lakehouse formatı, güncelleme, zaman yolculuğu ve değişiklik akışları sunuyor.
DuckDB, yerleşik bir lakehouse formatına kavuştu
DuckDB projesi, veritabanının açık bir lakehouse formatını doğrudan okuyup yazmasını sağlayan DuckLake adlı eklentiyi yayımladı. duckdb/ducklake deposu Hacker News'in ana sayfasına çıktı. Proje dokümantasyonuna göre DuckLake, tanıdık iki katmandan oluşuyor: meta veri bir katalog veritabanında yaşarken, tablo verisi Parquet dosyaları olarak saklanıyor.
Eklenti tek bir INSTALL komutuyla — ya da en son geliştirme sürümü için FORCE INSTALL ducklake FROM core_nightly ile — kurulduktan sonra bir lake attach edilip kullanılabiliyor:
ATTACH 'ducklake:metadata.ducklake' AS my_ducklake (DATA_PATH 'file_path/');
Bu noktadan itibaren tablolar sıradan SQL ile oluşturuluyor, değiştiriliyor ve sorgulanıyor. README, attach edilen veritabanı üzerinde CREATE TABLE, INSERT, UPDATE ve düz SELECT işlemlerini adım adım gösteriyor. Özellikle UPDATE satır düzeyinde çalışıyor ve örnekte tek bir değeri yeniden yazıyor — bunu düz Parquet dosyaları kendi başlarına sağlamıyor.
Meta veri nereye gidiyor
Kataloğu veriden ayırmak, formatın temel tasarım kararı. Kullanım örneğinde katalog, metadata.ducklake adlı bir DuckDB veritabanı dosyasında tutuluyor ve DATA_PATH bir Parquet dizinine işaret ediyor; böylece iki katman farklı yerlerde durabiliyor. Test yapılandırmaları, kataloğun DuckDB'ye bağlı olmadığını doğruluyor: test paketi PostgreSQL veya SQLite'ın katalog veritabanı olarak çalıştığı yapılandırmayla da koşabiliyor ve ayrıca deletion vectors etkinleştirilmiş bir yapılandırma da mevcut.
Test ağacı ayrıca ekibin önemli bulduğu kapsam alanlarını da gösteriyor — işlem (transaction) çakışması yönetimi, partitioning ve DuckDB'nin kendi çekirdek test paketini DuckLake depolama arka ucu olarak attach ederek çalıştıran bir mod.
Snapshot'lar, zaman yolculuğu ve değişiklik akışları
Değişiklikler katalogda kayıt altına alındığı için DuckLake, sürüm odaklı sorgulama sunuyor:
- Zaman yolculuğu: FROM my_ducklake.my_table AT (VERSION => 2) şeklinde sorgulamak, tabloyu önceki bir snapshot'taki haliyle döndürüyor. README'deki anlatımda bu, bir UPDATE değeri değiştirdikten sonra bile eski değeri geri getiriyor.
- Şema evrimi: ALTER TABLE my_ducklake.my_table ADD COLUMN new_column VARCHAR; sorunsuz çalışıyor ve mevcut satırlar yeni sütunda NULL ile geri geliyor.
- Change Data Feed: table_changes fonksiyonu, table_changes('my_table', 2, 2) biçiminde çağrıldığında, sütun değerlerinin yanında snapshot_id, rowid ve change_type içeren her değişiklik için bir satır üretiyor; böylece tüketiciler snapshot'lar arasındaki insert ve update'leri yeniden oynatabiliyor.
Derleme ve katkıda bulunma
Herkes eklentiyi kaynaktan derleyebilir: git submodülleri başlatılıp güncellenir ve make çalıştırılır. Submodule'ler, CI'ın derleme yaptığı sürümün .github/duckdb-version dosyasında kayıtlı olduğu DuckDB sürümüne sabitlenmiş durumda; make pull hedefi ise bunları dallarının en uç noktalarına taşıyor ve bu durumda derleme başarısız olabilir. Dış katkılara açığız ve katkılar main dalına yapılmalı. Testler ./build/release/test/unittest üzerinden koşuyor; tek bir dosyaya veya desene filtreleme, PostgreSQL, SQLite veya deletion-vector yapılandırmalarına geçme ve DuckDB'nin çekirdek testlerini DuckLake depolaması üzerinde çalıştırma seçenekleri de mevcut.
Neden önemli
DuckDB gömülü (embedded) bir analitik motor ve lakehouse formatları çoğunlukla daha büyük dağıtık sistemlerin alanı olageldi. DuckLake sayesinde tek süreçli bir veritabanı bir lake'i attach edebiliyor, üzerinde standart SQL çalıştırabiliyor, satırları değiştirebiliyor, şemaları evrimleştirebiliyor ve geçmiş snapshot'ları okuyabiliyor — kritik yolda ayrı bir compute cluster'ına ya da özel yapım bir meta veri servisine ihtiyaç duymadan.
Yapı taşlarının seçimi de önemli. Katalogu sıradan bir SQL veritabanında, veriyi ise Parquet'te tutarak format, diğer motorların zaten konuşabildiği teknolojilere yaslanıyor; test paketinin PostgreSQL ve SQLite kataloglarıyla da çalışıyor olması, tasarımın bilinçli olarak motor bağımsız olduğunu ve yalnızca DuckDB'ye özel bir kolaylık olmadığını gösteriyor. DuckDB'nin kendi çekirdek test paketini DuckLake'i depolama arka ucu olarak çalıştırmaksa belki de en güçlü niyet sinyali: bu, Parquet dosyalarına sonradan eklenmiş bir okuyucu değil, DuckDB için birinci sınıf depolama olarak konumlanıyor.
- #duckdb
- #parquet
- #lakehouse
- #open-source
- #data-engineering