Pg_lake - Postgres'te Iceberg ve veri gölü erişimini destekleyen uzantı

 (github.com/Snowflake-Labs)
3 puan yazan GN⁺ 2025-11-05 | 1 yorum | WhatsApp'ta paylaş
  • pg_lake, Postgres tabanlı olarak Iceberg tablolarını ve veri gölü dosyalarını doğrudan entegre eden, işlemler ve yüksek hızlı sorguları destekleyen bir uzantıdır
  • S3 gibi nesne depolamadaki Parquet, CSV, JSON ve Iceberg dosyalarını doğrudan sorgulama·içe aktarma·dışa aktarma imkanı sunar
  • İçeride DuckDB sorgu motorunu kullanarak Postgres ortamında hızlı yürütme performansı sağlar
  • Iceberg tablosu oluşturma, harici dosyalar için otomatik şema çıkarımı, COPY komutu üzerinden S3 giriş/çıkışı gibi veri lakehouse işlevlerini tek bir SQL arayüzüyle sunar
  • Snowflake, 2025'te Crunchy Data'yı satın aldıktan sonra bunu açık kaynak olarak yayımladı; bu da Postgres ekosisteminde veri gölü entegrasyonunu genişleten bir temel oluşturuyor

pg_lake genel bakış

  • pg_lake, Iceberg ve veri gölü dosyalarını Postgres'e entegre eden bir uzantıdır; böylece Postgres bağımsız bir lakehouse sistemi olarak kullanılabilir
    • Iceberg tabloları için işlem garantisi ve hızlı sorgu desteği
    • S3 gibi nesne depolamadaki ham veri dosyalarına doğrudan erişim
  • Başlıca özellikler
    • Iceberg tabloları oluşturma·değiştirme ve diğer motorlardan sorgulayabilme
    • Parquet, CSV, JSON ve Iceberg biçimlerindeki veri dosyalarını sorgulama ve içe aktarma
    • COPY komutuyla sorgu sonuçlarını Parquet, CSV ve JSON biçimlerinde nesne depolamaya dışa aktarma
    • GDAL'ın desteklediği GeoJSON, Shapefile gibi coğrafi veri biçimlerini okuma
    • Yarı yapılandırılmış veriler için yerleşik map türü sağlama
    • heap, Iceberg ve harici dosyaları tek bir SQL sorgusunda birleştirebilme
    • Harici veri kaynaklarından kolonları ve türleri otomatik çıkarma
    • DuckDB motoru üzerinden yüksek hızlı yürütme

Kurulum ve yapılandırma

  • Kurulum yöntemleri
    • Docker ile kolay çalıştırma
    • Kaynaktan derleme ile manuel kurulum veya geliştirme ortamı hazırlama
  • Uzantı oluşturma örneği 
    CREATE EXTENSION pg_lake CASCADE;
    • İlgili uzantılar: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Postgres wire protocol'ünü uygulayan bağımsız bir süreçtir ve içeride DuckDB kullanır
    • Varsayılan olarak 5332 portunda çalışır ve psql ile doğrudan bağlanılabilir
    • Başlıca ayarlar
      • --memory_limit: bellek sınırı (varsayılan olarak sistem belleğinin %80'i)
      • --init_file_path: başlangıçta çalıştırılacak SQL dosyasını belirtir
      • --cache_dir: uzak dosya önbellek dizinini belirtir
  • S3 bağlantı yapılandırması
    • DuckDB'nin secrets manager özelliğini kullanarak AWS/GCP kimlik bilgilerini otomatik algılar
    • Iceberg tablo depolama konumunu belirtme örneği 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

Kullanım örnekleri

  • Iceberg tablosu oluşturma 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • Oluşturduktan sonra SELECT count(*) FROM iceberg_test; sonucu 100 olur
    • Iceberg metadata konumu doğrulanabilir
  • S3'e COPY giriş/çıkışı 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Parquet, CSV ve JSON biçimleri desteklenir
  • S3 dosyasını harici tablo olarak oluşturma 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • Kolonlar otomatik çıkarılır ve sorgulanabilir (SELECT count(*) FROM parquet_table; → 100)

Mimari

  • Bileşenler
    • PostgreSQL + pg_lake uzantısı
    • pgduck_server (DuckDB yürütme ve Postgres protokolü uygulaması)
  • Çalışma şekli
    • Kullanıcılar Postgres'e bağlanıp SQL çalıştırır
    • Sorguların bir kısmı DuckDB üzerinden paralel ve kolon odaklı şekilde yürütülür
    • DuckDB, Postgres süreci içine gömülmediği için thread ve bellek güvenliği sorunlarından kaçınılır
    • Standart Postgres istemcileri üzerinden DuckDB motoruna doğrudan erişilebilir

Bileşenlerin ayrıntılı listesi

  • pg_lake_iceberg: Iceberg spesifikasyonunun uygulanması
  • pg_lake_table: nesne depolama dosyaları için FDW uygulaması
  • pg_lake_copy: veri gölüne COPY giriş/çıkış desteği
  • pg_lake_engine: ortak modül
  • pg_extension_base: diğer uzantılar için temel bileşen
  • pg_extension_updater: uzantı otomatik güncelleme özelliği
  • pg_lake_benchmark: lake table benchmark çalıştırma
  • pg_map: genelleştirilmiş map türü üreticisi
  • pgduck_server: DuckDB'yi yükleyip Postgres protokolüyle açığa çıkaran sunucu
  • duckdb_pglake: DuckDB'ye Postgres uyumlu işlevler ekler

Geliştirme ve yayımlanma geçmişi

  • 2024 başında Crunchy Data, Iceberg'i Postgres'e getirmek için geliştirmeye başladı
  • İlk aşamada DuckDB entegrasyonu ve Crunchy Bridge müşterilerine yönelik özellikler sağlandı
  • Sonrasında Iceberg v2 protokolü ve işlem desteği uygulandı
  • 2024 Kasım'da Crunchy Data Warehouse olarak yeniden piyasaya sürüldü
  • 2025 Haziran'da Snowflake, Crunchy Data'yı satın aldı, 2025 Kasım'da ise pg_lake açık kaynak olarak yayımlandı
    • İlk sürüm 3.0'dır (önceki iki nesil dahil)
    • Mevcut Crunchy Data Warehouse kullanıcıları için otomatik yükseltme yolu sağlandı

Lisans ve bağımlılıklar

  • Apache 2.0 lisansı
  • Apache Avro ve DuckDB projelerine bağımlıdır
    • Derleme sırasında Avro ve DuckDB uzantılarına patch uygulanır

İlgili okumalar

1 yorum

 
GN⁺ 2025-11-05
Hacker News görüşleri
  • Acaba sadece Ducklake kullanmamak için bir sebep var mı diye düşünüyorum
    Böylece karmaşıklık azaltılabilir. Gereken tek şey DuckDB ve PostgreSQL(pg_duckdb)
    Bu arada Prof. Hannes Mühleisen'in sunum videosu da var: DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us
    • DuckLake oldukça harika bir proje. Bizim ekip de DuckDB'yi seviyor. Aslında pg_lake'in mümkün olmasını sağlayan da DuckDB oldu
      DuckLake, Iceberg tabanlı pg_lake'in yapamadığı şeyleri yapabiliyor; tersine, Postgres de DuckDB'nin yapamadığı şeyleri yapabiliyor. Örneğin saniyede 100 binden fazla tek satırlık eklemeyi işleyebiliyor
      İşlem yönetimi bedavaya gelmiyor. Motoru kataloğun içine koymak yerine kataloğu motorun içine koyarsanız, analitik ve operasyonel tablolar arasında işlem yapmak mümkün hale geliyor
      Postgres, kalıcılık ve sürekli işleme açısından da daha doğal. pg_cron ve PL/pgSQL ile orkestrasyon kurulabiliyor
      Ayrıca Iceberg'in bir diğer güçlü yanı da birden fazla sorgu motoruyla birlikte çalışabilmesi
    • Sonuçta bu bir tasarım kararı meselesi. İlgili tartışmayı bu başlıkta görebilirsiniz
    • Ben de Ducklake'i gerçekten sevmeye çalıştım ama pratikte bakım sorunları yaşadım. Özellikle pg catalog ile ilgili olarak, Ducklake'in kendi oluşturduğu dosyalarda HTTP 400 hatası verdiği durumlar oldu
      Bunun benim veri yazma desenimden mi kaynaklandığından (Polars DataFrame'den Ducklake tablosuna ekleme), yoksa bölümlemeli tablo yapısından mı emin değilim
      Geliştirme/test ortamında idare ediyordu ama ekip genelinde sorun oldu. Bu yüzden sonunda Hive bölümlemeli Parquet dosyaları ve DuckDB görünümleri kombinasyonuna geri döndük
      Daha sonra örneklerle bir issue açmayı düşünüyorum ama şu an başka işlerden dolayı zamanım yok
  • Bu gerçekten büyük bir değişim
    Eskiden Postgres pazarında “açık kaynak Snowflake” olmadığını söylerdik
    Crunchy'nin Postgres eklentisi şu anda piyasadaki en ileri çözüm. Snowflake'i ve Crunchy ekibini bunu açık kaynak yapmaları için tebrik ederim
    • Dürüst olmak gerekirse, bence doğrudan Snowflake'e para ödeyip o harika veritabanını ve ekosistemi kullanmak daha mantıklı. Altyapı müşteri değerinin çekirdeği değilse, o kısmı başkalarına bırakıp harika şeyler yapmaya odaklanmak gerekir
  • Ben veri gölü ve SQL benzeri sorgu dillerini seviyorum. Bu, “her şey dosyadır” felsefesinin evrimleşmiş bir hali gibi geliyor
    Linux'ta dosya sistemi üzerinden sistem ayarlarını okuyup yazabilirsiniz (cat /sys/..., echo ... > /sys/...)
    FUSE ile kullanıcı alanında dosya sistemi sürücüsünü kendiniz uygulayabilirsiniz. Örneğin SSH veya Google Drive'ı bağlayıp cp komutuyla kopyalama yapabilirsiniz
    Ama dosya sistemleri yalnızca hiyerarşik verilere uygun. Gerçek dünyadaki verilerin çoğu ise ilişkisel yapıdadır
    Veri gölleri, SQL gibi zarif bir soyutlama sayesinde farklı veri kaynaklarını tek bir ilişkisel veritabanı gibi ele almayı sağlar
    Sonuçta birçok uygulama CRUD odaklıdır, dolayısıyla bu yaklaşım çok daha verimlidir
  • Veri göllerini nasıl kullanıyorsunuz? Benim için sadece bir depolama alanı değil, öngörülemez analiz işleri için bir alan
    Bu durumda Postgres'in sınırları var. Daha fazla CPU ve RAM gerekiyor ve sonunda dağıtık bir motor gerekiyor
    • Veri göllerinin özü, işlem gücü ile depolamanın ayrılmasıdır. Postgres burada işlem katmanı değil, erişim katmanıdır
      İşlem katmanı Postgres'e “bu anahtarların güncel verisi nedir?” ya da “2 hafta önceki verisi neydi?” diye sorar; asıl analiz sorguları ise doğrudan Parquet dosyaları üzerinde çalışır
  • Snowflake, Crunchy Data'yı satın aldığında böyle bir yönetilen sürüm sunmasını beklemiştim
    Bunu yerel Docker'da çalıştırabilmek güzel ama AWS üzerinde Snowflake hesabıyla entegre faturalandırma şeklinde yönetilebilse daha da iyi olurdu
  • Şu an gerçekten PostgreSQL'in altın çağı gibi hissettiriyor
  • Veri mühendisi değilim ama ilgili bir alanda çalışıyorum. Bunun hangi problemi çözdüğünü basitçe açıklayabilecek biri var mı diye merak ediyorum
    • Örneğin bir servis S3'e Parquet dosyaları olarak log verisi biriktiriyorsa ve siz bu veriyi Postgres'ten doğrudan sorgulamak istiyorsanız, pg_lake faydalı olur
      Parquet verisini Postgres'e alıp sorgulayabilir ve mevcut tablolarla join da yapabilirsiniz
  • İki sorum var
    (1) Iceberg yerine Ducklake spesifikasyonunu kullanacak bir uyumluluk planı var mı? Ducklake, kataloğu dosyalar yerine SQL tablolarında tuttuğu için eşzamanlı yazma ve anlık görüntü yönetimi daha kolay
    (2) pg_duckdb zamanla aynı işlevi sunacak hale gelebilir mi?
    • (1) Bunu değerlendirdik ama şu anda planımız yok. Ducklake'i olduğu gibi kullanmak yerine bunu doğrudan Postgres içinde uygulayıp işlem sınırlarını korumak istiyoruz
      Ancak satır içi veri işleme gibi ek karmaşıklıklar var. Bunları çözersek yüksek işlem performansı elde edebiliriz
      (2) pg_duckdb, Ducklake uygulamasını yeniden kullanma açısından daha kolay olabilir ama kaynak yönetimi ve kararlılık bakımından bu yapının daha az uygun olduğunu düşünüyoruz
  • S3 Table Buckets, Cloudflare R2 Data Catalog ve bu projeye bakınca Iceberg'in kazandığı hissi oluşuyor
  • Veriyi Postgres Wire uyumlu bir DB'ye kolayca yüklemek istiyorsanız sling-cli öneririm
    CLI, YAML ve Python ile ETL işleri çalıştırabilirsiniz