DuckLake - Birleşik veri gölü ve katalog formatı

 (ducklake.select)
13 puan yazan GN⁺ 2025-05-29 | 1 yorum | WhatsApp'ta paylaş
  • Veri gölü ile katalog formatını birleştiren yeni bir çözüm
  • Parquet dosyaları ve SQL veritabanları temelinde çalışır ve geleneksel lakehouse'lara göre daha sade bir veri gölü uygulaması sağlar
  • PostgreSQL, SQLite, MySQL, DuckDB gibi çeşitli veritabanları üzerinde meta veri kataloğu yönetimi mümkündür
  • Snapshot, time travel sorguları, şema değişikliği, partitioning gibi çeşitli özellikleri desteklerken sık sık compact etmeyi gerektirmeyen hafif snapshot işleme sunar
  • Birden fazla instance'ın aynı anda veriyi okuyup yazabildiği çok oyunculu DuckDB modelini destekler ve DuckDB'nin varsayılan olarak desteklemediği bir eşzamanlılık işleme modeli uygular
  • DuckLake; spesifikasyon, DuckDB eklentisi ve DuckLake formatında saklanan veri setlerini kapsayan bir kavramdır ve MIT lisansı ile yayımlanmıştır

DuckLake'e giriş

  • DuckLake, DuckDB ekibi tarafından geliştirilen açık bir formattır ve karmaşık lakehouse'lar olmadan gelişmiş veri gölü özellikleri sunar
  • Yalnızca bir SQL veritabanı ve Parquet dosyalarıyla kendi veri ambarınızı kurabilirsiniz.
  • Meta veri yönetimi için veritabanı kullanır: PostgreSQL, SQLite, MySQL, DuckDB

DuckLake'in başlıca özellikleri

  • Veri gölü operasyonları

    • Snapshot
    • Zamansal sorgulama (Time travel)
    • Şema evrimi
    • Partitioning

  • Hafif snapshot işleme

    • Snapshot sayısında sınır olmadan oluşturulabilir
    • Sık compact etmeden çalışabilir

  • ACID transaction'ları

    • Çoklu tablo işlemlerinde eşzamanlı erişim ve transaction garantisi

  • Performans odaklı tasarım

    • Filter pushdown için istatistiklerden yararlanır
    • Büyük veri setlerinde bile hızlı sorgulama mümkündür

Sık sorulan sorular

  • Neden DuckLake kullanmalıyım?

    • Veri gölü ile kataloğu birleştiren hafif bir çözüm gerektiğinde uygundur
    • Birden fazla DuckDB instance'ının aynı veri setini okuyup yazdığı çok oyunculu ortamlar mümkündür
      • Bu, mevcut DuckDB'de desteklenmeyen bir eşzamanlılık modelidir
    • Yalnızca DuckDB kullanarak bile zamansal sorgulama, partitioning ve çoklu dosya depolama yapısı gibi avantajlardan yararlanabilirsiniz

  • DuckLake nedir?

    • DuckLake şu üç şeyi ifade eder:
      1. DuckLake formatı spesifikasyonu (specification)
      2. DuckLake'i destekleyen DuckDB eklentisi (ducklake extension)
      3. DuckLake formatında saklanan veri setinin kendisi

  • DuckLake'in lisansı nedir?

    • MIT lisansı ile yayımlanmıştır

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-29
Hacker News yorumu

  • Parquet ile ilgili hep eksik bulduğum bir nokta var: çeşitli “data lake / lakehouse” sistemlerinin uyumsuz biçimde ayrı ayrı çözdüğü ‘ranged partitioning’ konusu. Benim uygulamam Parquet’e neredeyse kusursuz uyuyor ama zaman damgalarının eşit dağılmadığı zaman serisi logları gibi verilerle çalışıyor. Partition column, Hive partitioning’i izliyor ama aynı zamanda zaman damgalarına göre doğal olarak bölünüyor. Sorun şu ki Hive partitioning bunu desteklemiyor; bu yüzden başlıca sorgu araçları veri yapımı düzgün şekilde içe aktaramıyor. Tarih bazlı kolonlar gibi gereksiz yöntemler eklemek ya da dosyaları olduğu gibi yığmak gerekiyor; bu da performans ve maliyet açısından sorunlu. Iceberg, Delta Lake vb. ranged partitioning destekliyor ama benim böyle bir karmaşıklığa ihtiyacım yok; daha basit dosya adı veya dizin adı kurallarının standartlaşmasını tercih ederdim. Ayrıca Parquet row, Arrow row, Thrift, protobuf gibi formatlar neredeyse aynı ama tamamen aynı değil; tekil row veya row stream için eşlik eden bir binary format olsa, farklı araçlar arasında birlikte çalışabilirlik daha iyi olurdu diye düşünüyorum

    • Parquet dosyasının footer metadata’sı gerekli bilgiyi almak için zaten yeterli değil mi diye merak ediyorum. Metadata’da ilgili kolonun minimum/maksimum zaman damgası var; dolayısıyla sorgu sırasında araç sadece bu metadata’yı okuyup dosyanın okunup okunmayacağına karar vererek gereksiz okumaları engelleyebilir

    • Zaman verisiyle çalışmak zordur ama yaklaşıma göre bundan kaçınılabilir de. Ham zaman serisini doğrudan sorgulamak yerine, event işleme aşamasında zaman damgalarını normalize edip saklamak faydalı olabilir. Sliding window tabanlı olarak event başlangıç noktasını bulup offset ayarlayarak, zaman serisinin referans noktaya (0) geri döndüğü yeri tespit edip bunu event birimi olarak kullanabilirsiniz

    • Hive, injected ve dynamic olmak üzere iki tür partitioning destekliyor. Partition key olarak UNIX zamanına göre hour kolonu kullanılabilir; yani epoch’tan itibaren 3600 saniye artan bir tamsayı. Sorgu motorunda hangi partition aralığının taranacağını belirtmek gerekebilir ama sorguda datepartition >= a AND datepartition < b biçiminde kullanılabilir. Iceberg bunu çok daha basit hale getirip doğrudan zaman damgası aralığıyla çalıştırıyor ve metadata gerektirmeyen partition’ları otomatik dışarıda bırakıyor

    • arrow/parquet düşük seviye kütüphanelerinde row group ve data page’leri doğrudan kontrol edebilirsiniz. arrow-rs crate’i kullanarak dosya sorgu hızını 10 kattan fazla artırdığım oldu. Bazen row group sayısı az, bazen çok fazla oluyor ama istediğiniz row group’ları hızlıca atlayabildiğiniz için skew sorun olmuyor. Yalnız dosya başına row group sayısının 2^15 ile sınırlı olduğuna dikkat etmek gerekir

    • Bu daha çok Parquet’in değil, Hive’ın sınırlaması gibi görünüyor. Kolonun min/max bilgisini görmek için Parquet dosyasını açmak gerekiyor ama veri aralık dışındaysa sonrasında ek istek yapılmıyor. Böyle metadata’yı daha üst katmanda, örneğin DuckLake gibi bir yerde değerlendirmek verimli olabilir

  • Iceberg’de (Delta Lake de benzer ama bana göre Iceberg biraz daha zor) en rahatsız edici şeylerden biri, bunu notebook veya yerel ortamda denemenin zor olmasıydı. Delta Lake’in birkaç Python implementasyonu var ama parçalı durumda; Iceberg tarafında ise JVM cluster kurulumu gibi uğraşlar var. Ben sqlite/postgres + duckdb + parquet kombinasyonunu blob storage üzerinde kullanmak istedim ama epey zahmetliydi. DuckDB tarafı ise böyle uğraştırmadan hemen çalışıyor ve makul büyüklükte veri setlerine kadar doğal şekilde ölçekleniyor. DuckDB ekibinin bu alanı iyi anladığını düşünüyorum ve gerçekten heyecan verici buluyorum

    • PyIceberg’i denediniz mi diye merak ediyorum. Tamamen Python ile yazılmış bir implementasyon ve oldukça iyi çalışıyor. SQL Catalog ve SQLite tabanlı in-memory catalog da destekliyor
      https://py.iceberg.apache.org/

    • S3 ve RDS kullanan adım adım bir kurulum rehberi var. Bunu yerel sqlite’a uyarlamak da zor olmaz
      https://www.definite.app/blog/cloud-iceberg-duckdb-aws

    • Yerelde gerçekten çok kolay denemek mümkün. marimo notebook içinde birkaç satır kodla yapılabiliyor (not: ben marimo geliştiricisiyim)
      https://www.youtube.com/watch?v=x6YtqvGcDBY

    • k3s ile iyi çalışan bir Helm chart hazırlamayı düşünüyorum. datapains kullanınca trino’yu da kolayca ayağa kaldırabiliyorsunuz; biraz daha uğraşıp hivemetastore da çalıştırılabilir. Iceberg connector’ü trino ile bağlayıp tüm akışı denedim. Veriyi hive’a yükleyip trino’nun aynı tabloyu göstermesini sağladıktan sonra, select ile iceberg’e insert yapmak yeterli oluyor. DuckDB tarafı gerçekten zahmetsiz çalışan bir ortam sunarsa, sektör liderliğini de alabilir gibi görünüyor

    • delta-io (deltalake-r tabanlı) yerelde çok kolay çalışıyor. pip ile kurup hemen catalog ve dosya yazımı yapabilirsiniz
      https://delta-io.github.io/delta-rs/

  • Iceberg’e yönelik keskin eleştiriyi iyi yakalıyor: Sonuçta veritabanı kullanıyorken metadata’yı neden dosyaların içine koyup ayrıca yönetiyoruz? DuckLake’in DuckDB dışına taşıp geniş ölçekte başarı yakalaması kolay olmayabilir ama sonunda catalog’un metadata’yı da üstlendiği bir yapıya geçebiliriz ve mevcut Iceberg formatı zamanla tarihte kısa bir dönem olarak kalabilir

  • Mevcut lakehouse sistemleri (Iceberg vb.), schema/dosya listesi gibi önemli tablo bilgilerini S3 benzeri object storage üzerinde küçük metadata dosyalarına dağınık halde saklıyor. Bu yüzden query planning ve tablo güncellemeleri sırasında çok sayıda network call gerekiyor; sonuç olarak ya yavaş oluyor ya da sık sık çakışma yaşanıyor. DuckLake ise tüm metadata’yı hızlı ve transactional bir SQL veritabanında tutuyor; böylece tek bir sorguyla gereken her bilgi alınabildiği için verimlilik ve güvenilirlik ciddi biçimde artıyor

  • DuckLake manifestosu: https://ducklake.select/manifesto/

  • Ben de şirket içinde deltalake-rs Python binding’leri ile duck db kullanarak bir “poor man’s datalake” geliştiriyorum. Yapı, parquet dosyalarını blob storage’da tutuyor. Ancak concurrent write tarafında sürekli sorun yaşıyorum. Belirli aralıklarla bir cloud function’ın API’den veri çekmesi sorun değil. Ama backfill’i birkaç kez çalıştırınca timer function ile aynı anda devreye girip çakışma riski oluşuyor. Özellikle backfill kuyruğuna yüzlerce iş atıp worker’lar dolunca daha da kötüleşiyor

    • Dosya adının sonuna rastgele bir suffix ekleme yöntemi var

    • Write işleminden önce json dosyası üzerinde geçici bir lease tutup write isteklerini kuyrukta yönetirseniz çakışmaları önleyebilirsiniz

  • Iceberg’in sınırlamalarını, özellikle metadata yönetimi tarafını çözmeye çalışan rakip bir çözüm (ör. Snowflake metadata yönetimi için FoundationDB kullanırken Iceberg blob storage’a kadar iniyor)
    https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

    • Ben de benzer bir izlenim edinmiştim ama videoyu izleyince DuckLake’in doğrudan rakip olmadığı anlaşılıyor
      https://youtu.be/zeonmOO9jm4?t=4032
      DuckLake yalnızca gerektiğinde Iceberg için manifest/metadata dosyaları yazıp senkronize ediyor ve mevcut Iceberg verisini okumayı da destekliyor. Yani Iceberg’in temel sorunlarını iyileştiriyor; ayrı bir rakip üründen çok, Iceberg ile temiz biçimde çift yönlü entegre olan bir yapı gibi

    • Metadata şişmesi duruma göre gayet yönetilebilir

      • Snapshot sayısı
      • Sık ve büyük schema değişiklikleri
      • Sık row düzeyi güncellemeler / çok sayıda küçük dosya
      • İstatistik bilgileri vb.
        Eskiden büyük schema’larda son madde sorun oluyordu. Çoğu engine bunu compaction, snapshot export gibi araçlarla yönetmeyi destekliyor ama sorumluluk yine kullanıcıda. S3 Tables bazı yönetim özellikleri sunuyor. Metadata 1–5MB ise aslında mesele değil. Commit hızı ise metadata boyutu ve writer sayısına bağlı. 1GB’ı aşan metadata’yı bile elle yazdığım script’lerle çözdüğüm oldu—genelde eski snapshot’ları temizlemek (asıl dosya silmeyi bucket policy’ye bırakmak) ya da eski schema sürümlerini kaldırmak yetiyor

  • Sonuçta gerçekten düzgün bir veritabanı yapmak istiyorsanız, onu gerçekten veritabanı gibi inşa etmeniz gerekiyor. DuckDB ekibine hayran kaldım

  • Mother Duck(https://motherduck.com/) ile ilişkisinin ne olduğunu merak ediyorum. “DuckDB-powered data warehousing” yapan bir şirket ve DuckLake’ten daha önce başlamıştı

    • MotherDuck ile DuckLake çok iyi entegre olacak. MotherDuck verisi DuckLake üzerinde saklanacak; böylece ölçeklenebilirlik, eşzamanlılık ve tutarlılık artacak, ayrıca alttaki veriye üçüncü taraf araçlarla da erişilebilecek. Son birkaç aydır bunun üzerinde çalışıyoruz ve yakında daha fazla bilgi paylaşacağız

    • MotherDuck, verinizi yüklediğinizde sizin yerinize organize edip DuckDB üzerinden veri arayüzü sağlıyor. Daha lakehouse benzeri özellikler, blob storage entegrasyonu, DuckLake ile ek bütünleşme veya metadata’yı MotherDuck’ta tutma ihtiyacınız varsa DuckLake kullanabilirsiniz

    • MotherDuck, duckdb’yi bulutta barındıran bir hizmet; DuckLake ise çok daha açık bir sistem. DuckLake ile S3 veya EC2 gibi ortamlarda, birden fazla instance ve petabyte ölçekli warehouse yapıları kurabilir; birden çok reader/writer ile tüm bunları transactional olarak çalıştırabilirsiniz. MotherDuck tarafında aynı anda yalnızca tek bir writer mümkün, read replica’larda yaklaşık 1 dakikalık gecikme var ve transactional değil. Birden fazla instance aynı anda farklı tablolara yazamıyor. DuckLake ise storage ile compute’un ayrılmasını ve yüksek transaction kabiliyetli bir metadata katmanını da sağlıyor

  • duckDB’yi seviyorum ve DuckLake de gerçekten harika görünüyor. Merak ettiğim şey şu: Eğer bunu şimdi kullanmaya başlasam ve şirkette zaten Snowflake çalışıyor olsa, analistlerin her birinin yerelde duckdb + extension kurup blob store’a ve datalake extension için bir veritabanına (örneğin bir VM’de çalışan duckdb) işaret etmesi mi gerekecek? Sorgu çalıştırıldığında compute tam olarak nerede gerçekleşiyor, daha büyük işler için ne yapmak gerekiyor? Herkesin devasa bir duckdb VM’ine ssh ile bağlanıp sorgu çalıştırdığı bir yapı mı gerekiyor? Bu tarafın biraz daha açıklanmasını isterim

    • duckdb’yi yerelde çalıştırırsanız compute kullanıcının kendi bilgisayarında gerçekleşir. Daha fazla compute gerekirse bir VM ayağa kaldırıp onun üzerinde kullanabilirsiniz. İkisi de mümkün: küçük işler için yerel, daha büyük workload’lar için VM üzerinde ölçekleme yapılabilir