Parquet, Iceberg ve veri lakehouse'unu anlamak

Anlamak: Parquet, Iceberg ve BroadIn'in veri lakehouse'u

• Veri depolama biçimleri (dosya içinde ve bellek içinde)

  • Veri erişimi ve depolama için çeşitli dosya biçimleri bulunur
  • Bazı sistemler ağırlıklı olarak kapalı veri biçimleri kullanır, ancak çoğu sistem açık veri biçimlerini destekler
  • Başlıca açık kaynak dosya biçimleri arasında Apache Avro, Parquet, ORC, Arrow, Feather ve Protobuf bulunur
  • Bu biçimler, verinin gerçek ikili düzende nasıl yerleştirileceğine dair spesifikasyonlar sağlar
  • Parquet sıkıştırmayı iyi destekler, Avro ise belirli satır bloklarını okumaya uygundur
  • Şema evrimi ve dosya bölmeyi destekleyerek paralel işleme için kritik hale gelirler
  • Çeşitli programlama dilleri ve araçlarla bu biçimlerle çalışılabilir

• Büyük ölçekli veri yönetimi - Iceberg ve Delta Lake

  • Farklı tabloları depolamak, her birinin şemasını geliştirmek, veriyi verimli şekilde bölümlemek ve harici araçların şemayı kolayca okuyabilmesini sağlamak için yöntemlere ihtiyaç vardır
  • Hive, Iceberg ve Delta Lake'in tümü şema kayıt defteri veya metastore desteği sunar
  • Iceberg ve Delta Lake, tekil dosya biçimi olarak Parquet kullanır
  • Iceberg ve Delta Lake bir sorgu ya da depolama motoru değil, sorgu motorlarının iş yapabilmesini sağlayan açık spesifikasyonlardır
  • Bölümleme evrimi, şema evrimi, veri sıkıştırma, ACID işlemleri, verimli sorgu optimizasyonu ve time travel gibi yetenekleri mümkün kılar

• Veri gölü ve veri lakehouse nedir?

  • Veri gölü, şirketlerin OCR, Parquet veya CSV dosyaları gibi ham biçimlerde büyük miktarda veriyi depoladığı yerdir
  • Veri lakehouse, veri gölünün üzerinde SQL sorguları çalıştırma, batch işleri kurma ve veri yönetişimi yapılandırma gibi yeteneklerin birleşimidir
  • Veri lakehouse, açık bir veri ambarı sürümü olarak görülebilir
  • Snowflake ve BigQuery gibi veri ambarları Iceberg gibi açık veri biçimlerini destekledikçe, veri ambarı ile veri lakehouse arasındaki sınır giderek belirsizleşiyor

GN⁺ görüşü

• Iceberg ve Delta Lake, büyük veri kümelerini yönetmek için bir metadata katmanı olarak önemli rol oynar. Verinin verimli yönetimini ve sorgu optimizasyonunu mümkün kıldıkları için veri bilimcileri ve mühendisler açısından faydalıdır.
• Veri lakehouse, veri gölü ile veri ambarının avantajlarını birleştirerek veri yönetimi ve analizi için yeni bir paradigma sunar. Bu, veriye dayalı karar almayı daha da güçlendirecek fırsatlar sağlar.
• Iceberg desteği arttıkça, veri yönetimi ve analiz sistemlerinin giderek daha standart ve birlikte çalışabilir hale gelmesi bekleniyor. Bu da veri platformu seçimi ve kullanımında daha fazla esneklik ve verimlilik getirecektir.

[happing94]

Iceberg ve Delta Lake’i karşılaştırıyordum; böyle derli toplu özetlenmiş olması güzel olmuş.
Benim baktığım görüş ve düşüncelerle neredeyse tamamen aynı.
Çevrim içi yapılan benchmark Spark kullanılarak gerçekleştirilmiş ve benchmark referans alınmaya değer olsa da çok büyük bir anlamı olmadığını Tabular’ın Head DevRel’i yazmış.
Açık kaynak olarak bir seçim yapılacaksa tek seçenek Iceberg gibi görünüyor.
Özet güzel ama başvurulan bağlantılar da olsaydı iyi olurdu.

[GN⁺]

Hacker News görüşü

• Apache Iceberg ve Delta Lake sık sık açık tablo formatları olarak anılsa da, aslında aralarında fark var.

  • Apache Iceberg tablo formatı spesifikasyonu o kadar nettir ki, veritabanı sistemlerine aşina biri Iceberg tablosu kurup sorgulamakta büyük zorluk yaşamaz.
  • Buna karşılık, Delta Lake spesifikasyonunda mevcut özellikleri tamamen uygulamak veya sürekli güncel tutmak için gereken çabayı kavramak zor.
  • Delta Lake spesifikasyonu, Databricks’in Hadoop’tan hayal kırıklığına uğramış Fortune 1000 şirketleri için lakehouse kurarken içeride verdiği uygulama kararlarının tersine mühendislikle çıkarılmış hali gibi görünüyor.
  • Delta Lake’in gerçekten açık bir ekosistem olarak değer taşıyıp taşımadığı konusunda emin değilim.

• Veritabanı dünyasında Delta, Iceberg ve Hudi’nin veriyi S3 gibi depolamalarda açık kaynak formatlarla saklaması büyük bir değişim anlamına geliyor.

  • Bu sayede depolama ve işlemenin büyük kısmı standartlaşıyor, veritabanları arasında geçiş kolaylaşıyor ve çoğu araç işlemsel olarak güvenli bir biçimde aynı dosya kümesi üzerinde çalışabiliyor.
  • Örneğin Snowflake dosyalara yazarken bir veri bilimci Jupyter notebook içinde aynı anda veriyi sorgulayabilir ve ClickHouse da aynı veri üzerinde kullanıcı odaklı analiz sunabilir.
  • Bir işletme Snowflake’ten Databricks’e geçmeye karar verse bile bu büyük bir sorun olmaz.
  • Şu anda S3 üzerinde bu formatları sorgulamak, native ingestion kadar hızlı değil; ancak piyasa baskısı tüm veritabanı sağlayıcılarını performansı optimize etmeye zorlayacaktır.
  • Bu, açık kaynak ve açıklık açısından büyük bir kazanım; işletmelerin verilerini açık ve taşınabilir formatlarda tutabilmesini sağlıyor.
  • Lakehouse da benzer bir etki yaratıyor. Birçok şirketin hem veri gölü hem de veri ambarı var ve iki sistem arasında veriyi kopyalamak zorunda kalıyorlar. Aynı veri kümesini sorgulamak ve yalnızca tek bir sistemi yönetmek de aynı derecede önemli.

• Yıllardır S3 üzerinde Parquet dosyalarıyla çalışıyorum ama Iceberg’in tam olarak ne olduğunu anlamamıştım. Bu makale ise Iceberg’i iyi açıklıyor.

  • Iceberg, temel veri kümesi için şema, partitioning ve benzeri unsurları tanımlayan bir veritabanı metadata formatıdır.
  • Geleneksel DBMS’lerde şema, sorgu motoru ve depolama formatı tek bir paket olarak gelir.
  • Ama big data dünyasında veritabanı bileşenlerini sıfırdan kurabilir, karıştırıp eşleştirebilirsiniz. Metadata formatı olarak Iceberg, sorgu motoru olarak DuckDB, depolama formatı olarak Parquet ve depolama ortamı olarak S3 kullanılabilir.

• Apache Arrow dataframe’lerini diskte dosya olarak saklamanın en iyi yolu Feather kullanmaktır, ancak bunları Apache Parquet formatına dönüştürmek de mümkündür.

  • Kendi JVM dışı lakehouse’unuzu kurmak istiyorsanız metadata için Iceberg, veri için Parquet kullanabilir; DuckDB ile sorgulamak için Arrow tablolarından yararlanabilir ve veriyi Arrow->Pandas veya Polars üzerinden işleyebilirsiniz.
  • Araya Feather karıştırırsanız mevcut Python lakehouse stack’i çalışmaz.

• Veri gölünü duymuştum ama "veri lakehouse" kulağa üst sınıf verilerin yazın veri teknesiyle veri avına çıktığı bir yer gibi geliyor.

• GCP’de yaklaşık 100 TB veriyle çalışıyorum, sorgu motoru olarak BigQuery ve basit Hive partitioning kullanıyorum. Tüm sorguları çalıştırabiliyor olmak ve maliyetin çok düşük olması hoşuma gidiyor, ancak gecikme oldukça yüksek olabiliyor (şirket için büyük bir sorun değil).

  • Iceberg uygularsam bunu iyileştirip iyileştiremeyeceğimi merak ediyorum. Iceberg kullanan var mı?

• Iceberg konusunda çok heyecanlıyım ama en son baktığımda tek gerçek implementasyon Spark kütüphaneleriydi ve Trino’nun Iceberg connector’ü Hive’a ciddi biçimde bağımlıydı.

  • Tüm sektör MapReduce, Hive ve Spark gibi legacy teknolojilerden boşanmakta zorlanıyor.
  • Iceberg’e yeniden bakmayı planlıyorum ve bu alanın gelişmesini umuyorum. Bugün legacy teknoloji olmadan veriyi işleyebilecek araçlara ve işlem gücüne sahibiz; ayrıca her veri big data değil.
  • Sonuç olarak "data engineering" giderek sıradan backend geliştirmeye daha çok benziyor ve genel geliştirme pratikleri uygulanıyor.
  • Saf Python bir Iceberg kütüphanesi çok yakında gelir umarım.

• Birinin neden tüm bunları daha somut fikirlerle açıklamadığını merak ediyorum. Verinin nasıl saklandığını, nasıl bağlanılıp sorgulandığını ve sorgu hızının nasıl olduğunu (işlem hızıyla "analitik" hız arasındaki fark dahil) anlatmaları gerekirdi.

• İnternette gördüğüm tüm benchmark’larda Delta Lake formatı, Iceberg’den çok daha iyi performans gösteriyor.

  • Bunun spesifikasyona içkin bir şey olup olmadığı ya da Iceberg’in bu farkı kapatma şansı bulunup bulunmadığı soruluyor.

• Blog yazısının %100 kapsamlı olmayacağını veya çoğu insan için en iyi başlangıç noktası olmayacağını kabul ediyorum.

  • Yeni bir şeyi öğrenmenin en iyi yolunun onu başkalarına yeniden açıklamak olduğu yaklaşımını seviyorum; ben de bunu kendi web sitemdeki notlara uygulamaya başladım.