Parquet, Iceberg ve Veri Lakehouse’larını Anlamak
(davidgomes.com)- Veri depolama teknolojileri tek bir bütün değildir; dosya formatı, bellek formatı, tablo meta veri katmanı ve lakehouse mimarisi gibi farklı katmanlara ayrılır
- Avro·Parquet·ORC·Arrow, verinin ikili yerleşimini belirleyen formatlardır; Parquet sütun tabanlı sıkıştırma ve analitik işlemlerde güçlüdür, Avro ise satır bazlı işleme daha uygundur
- Iceberg ve Delta Lake bir dosya formatı değil, Parquet gibi dosyalar üzerinde büyük ölçekli tablo yönetimini mümkün kılan üst düzey meta veri katmanlarıdır
- Veri lakehouse, S3 gibi depolardaki ham dosyaların üzerine SQL sorguları, batch işler ve yönetişim gibi veri ambarı işlevlerini ekleyen bir yaklaşımdır
- Snowflake ve BigQuery gibi veri ambarları da Iceberg gibi açık formatları desteklemeye başladıkça, veri ambarı ile lakehouse arasındaki sınır giderek belirsizleşiyor
Dosya formatı ile bellek formatı arasındaki fark
- Veri depolama ve erişimini verimli hale getiren açık kaynak formatlar, depolama biçimi ve kullanım yeri açısından birbirinden farklıdır
- Apache Avro: ikili, satır depolama (rowstore), dosya
- Apache Parquet: ikili, sütun depolama (columnstore), dosya
- Apache ORC: ikili, sütun depolama, dosya
- Apache Arrow: ikili, sütun depolama, bellek
- Protocol Buffers: dile bağımsız bir veri yapısı tanımlama dilidir; uygulamaya göre satır depolama veya sütun depolama değişebilir
- CSV: metin tabanlıdır ve yapısı oldukça basittir
- Apache Arrow DataFrame’lerini disk dosyası olarak kaydederken çoğunlukla Feather kullanılır; ayrıca Parquet gibi başka formatlara da dönüştürülebilir
- Snowflake, Redshift, Athena ve Hive gibi sistemler açık formatların ve kapalı depolama formatlarının okunup yazılmasını destekler; ancak açık format desteğinin kapsamı üründen ürüne değişebilir
Formatların gerçekte belirlediği şey
- Dosya formatı, verinin gerçek ikili yerleşimde nasıl düzenleneceğini tanımlayan bir spesifikasyondur
- Parquet sıkıştırmada güçlüdür; Avro ise satır depolama yapısı sayesinde belirli satır bloklarını okumaya daha uygundur
- Hem Parquet hem de Avro, şema evrimini destekler; böylece mevcut verinin tamamını yeniden yazmadan yeni verinin şeması değiştirilebilir
- Her iki format da dosya bölmeyi destekler ve bu, verinin paralel işlenmesi açısından önemlidir
- Apache Parquet deposu, gerçek dosya formatı spesifikasyonunu ve Java referans uygulamasını içerir
- Parquet birçok dil ve araçla okunup yazılabilir; Pandas’ta da DataFrame
to_parquetile yerel Parquet dosyası olarak kaydedilebilir - Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena ve Apache Drill, Parquet dosyalarını işleyebilen motorlara örnektir
Büyük ölçekli veri yönetiminde dosya formatının tek başına yetmemesi
- Tekil dosya formatları yalnızca tek bir dosya yerleşimini tanımladığı için, sürekli değişen büyük veri kümelerini yönetmekte yetersiz kalır
- Çok sayıda tablonun depolanması, tek tek tablolar için şema evrimi, belirli bir zamandaki durumu sorgulama, verimli bölümleme, harici araçların şemayı okuyabilmesi ve maliyet tabanlı sorgu optimizasyonu için istatistik saklama gibi ihtiyaçlar üst bir katman gerektirir
- Bu katman, tablo formatı ile birlikte şema kayıt defteri veya metastore içerir
- Confluent Schema Registry, Avro ve Protobuf’u destekler ve satır depolamaya eğilimli akış verileri için daha uygundur
Hive, Iceberg ve Delta Lake’in konumu
- Facebook, 2009’da Hive’ı kendi tablo meta veri formatıyla birlikte yayımladı; Hive zamanla birçok formatı destekler hale geldi
- Netflix, Hive’ın performans ve ölçeklenebilirlik sınırlarını aşmak için Iceberg’i geliştirdi
- Databricks, Iceberg’e alternatif olarak Delta Lake’i geliştirdi ve daha sonra açık kaynak olarak yayımladı
- Hem Iceberg hem de Delta Lake, tekil dosya formatı olarak Parquet kullanır
- Hive, Delta Lake ve Iceberg’in tümü, şema kayıt defteri veya metastore’e karşılık gelen kavramları destekler
- Hive’ın HMS’i (Hive MetaStore), fiilen herhangi bir RDBMS kullanabilir
- Iceberg’de Iceberg Catalogs bulunur
- Databricks’te Unity Catalog vardır
- Bu kataloglar ve metastore’lar, hangi ekip ya da kullanıcının hangi tabloya erişebileceğini yönetmek için veri yönetişiminde de kullanılabilir
Iceberg ve Delta Lake’in üstlendiği işlevler
- Delta Lake ve Iceberg, sorgu motoru ya da depolama motorunun kendisi değil; sorgu motorlarının çalışmasını mümkün kılan açık spesifikasyonlardır
- İkisi aynı problemi farklı şekillerde çözer; Delta Lake’in Iceberg’e kıyasla daha az çeşitli katkı sunucularına sahip olması nedeniyle açıklık düzeyi etrafında tartışmalar vardır
- Redshift, BigQuery, Snowflake, Athena ve Dremio gibi birçok veri ambarı ve lakehouse’ta Iceberg desteği hızla artıyor
- Iceberg ve Delta Lake, büyük ölçekli tablo işletimi için gerekli işlevleri sağlar
- bölümleme
- şema evrimi
- veri sıkıştırma
- şema değişiklikleri için ACID işlemleri
- sütun budama, koşul pushdown ve istatistik toplama yoluyla verimli sorgu optimizasyonu
- belirli bir zamandaki durumu görmek için time travel
- Iceberg, bölümleme evrimini destekler; böylece mevcut verinin tamamını yeniden yazmadan tablonun bölümleme biçimi veya shard key değiştirilebilir
- Netflix’te bölümleme değişiklikleri büyük bir sıkıntıydı ve bu da Iceberg’in geliştirilme nedenlerinden biriydi
Kapalı formatlar ve Iceberg desteği baskısı
- Iceberg spesifikasyonu, birçok sistem tarafından desteklenen bir format olarak hızla popülerlik kazanıyor
- Kapalı format kullanan ürünler, kendi formatlarında mümkün olan en yüksek performansı sunarken aynı zamanda Iceberg veya Delta Lake’i bir şekilde destekleme baskısı altında
- Iceberg, zamanla tüm veritabanı sistemlerinin desteklemesi gereken bir check-box özelliği haline gelebilir
- Performans nedenleriyle Iceberg’in kapalı veri formatlarının yerini tamamen alması zor olabilir
- Veri formatı yalnızca tek bir sorgu motoru için geliştirildiğinde, veritabanı geliştiricileri en yüksek verimi elde edip daha hızlı yenilik yapabilir
Veri gölü ve veri lakehouse
- Veri gölü, şirketlerin büyük miktarda veriyi Parquet ve CSV gibi ham dosyalar halinde depoladığı yerdir
- Veri ambarı ise veriyi şemalı SQL tabloları ve veritabanı şemaları gibi daha yapılandırılmış biçimlerde saklar
- Veri lakehouse, veri gölüne SQL sorgu çalıştırma, batch işler ve veri yönetişimi yapılandırması gibi yeteneklerin eklenmiş halidir
- Iceberg, sorgu motorları ve diğer ek bileşenler birlikte kullanıldığında veri gölü üzerinde bir veri lakehouse kurulabilir
- Geçmişte bu tür işlevler için veri ambarı veya daha geleneksel bir DBMS benimsemek gerekiyordu
- Veri lakehouse, tüm veriler için depolama konumu olarak HDFS ya da S3 gibi bulut blob store’ları kullanır ve sorgu motorlarını bu depolar üzerinde hızlı çalışacak şekilde optimize eder
- Databricks ve Dremio, veri lakehouse ürünlerine örnektir
- Snowflake ve BigQuery gibi veri ambarları Iceberg gibi açık veri formatlarını ekledikçe, veri ambarı ile veri lakehouse arasındaki ayrım daha da bulanıklaşıyor
2 yorum
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.
Hacker News yorumları
Apache Iceberg ve Delta Lake sık sık açık tablo formatları (Open Table Format) gibi birlikte anılsa da, gerçekte oldukça farklı görünüyorlar.
Iceberg belirtimi https://iceberg.apache.org/spec/ adresinde; veritabanı sistemlerini bilen biri buna bakarak Iceberg tablosu oluşturup sorgulayan bir uygulamayı çok zorlanmadan yapabilir gibi görünüyor.
Buna karşılık Delta Lake tarafında https://github.com/delta-io/delta/blob/master/PROTOCOL.md var; mevcut belirtimi eksiksiz uygulamak için gereken iş miktarını bile kestirmek zor, sürekli değişen bu devasa belirtimi takip etmek ise daha da göz korkutucu.
Açıkçası Delta Lake belirtimi, Databricks'in Hadoop'dan ağzı yanmış Fortune 1000 şirketleri için hızla lakehouse kurarken ortaya çıkan uygulama tavizlerinin tersine mühendislikle belgelenmiş hâli gibi okunuyor.
Delta Lake'i benimsemenin gerçekten açık bir ekosisteme girmek olduğuna hâlâ ikna olmuş değilim; bu konuda iç rahatlatacak bir dayanak olsa iyi olurdu.
Ek olarak GitHub geçmişi de pek güven vermiyor: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
Rastgele özellikler ve düzeltmeler Databricks mühendislerinin PR'ları olarak geliyor, Databricks kıdemli mühendisleri de hemen onaylıyor gibi görünüyor.
Ama bunu yaparken topluluk öncülüğünde açık bir format olduğunu iddia edemezler. Animal Farm'daki “bazı taraflar daha eşittir” versiyonuysa başka.
Hesaplanan sütunlar veya check constraint gibi özellikleri kullanmak için Spark SQL ifadelerini de desteklemek gerekiyor; o taraftaki dokümantasyon daha da zayıf.
Adı var kendi yok türünden açık kaynağa yakınlar; güvenilmemesi gerektiğini düşünüyorum.
Delta Lake'i de kullandım; gerçek kullanımda sinir bozucu sınırlamalar ve keskin köşeler çoktu. Sonunda o projeyi tamamen kapattık, o dönemde Iceberg'i de araştırmıştık.
Iceberg ve Hudi'nin özellik setleri daha tutarlı tasarlanmış gibiydi ama destekleri daha zayıftı; umarım bu taraf ileride daha iyi hâle gelir.
Son 6 ayda Iceberg'in JVM ekosistemi dışındaki kullanıcılar için araç sunmakta zorlandığı, Delta'nın ise önde olduğu izlenimini edindim. Bu açıdan Delta çok daha erişilebilir.
Karşılaştırma yapmak gerekirse SQL Server'da bu çok daha iyi uygulanmış. Sütun yönelimli depolama tabloları (columnstore indexes, motor içindeki Parquet/ORC karşılığı) değişmezdir; delta ise sıkıştırılabilirlik, erişilebilirlik ve hız için B-Tree'de saklanır.
Bir noktada sütun deposu kısmen veya tamamen birleştirilir/defrag edilir/yeniden oluşturulur; B-Tree silinir ve yeni değişiklikler birikmeye başlayınca baştan başlar.
Bunu JSON'la yapmak, yumuşak söylesek bile kötü bir çağın belirtisi.
Delta Lake yerine her şey daha iyi olur gibi; özellikle Iceberg daha iyi görünüyor.
Güzel yazı. S3 üzerindeki Parquet dosyalarıyla yıllardır uğraşıyorum ama Iceberg'in tam olarak ne olduğunu iyi bilmiyordum; yazı bunu iyi açıklamış.
Iceberg, alttaki veri kümesinin şemasını ve bölümlemesini vb. açıklayan bir veritabanı metadata formatı.
Çoğu kişi
/key3=000/key2=002/gibi Hive bölümleme geleneklerini kullanıyor; Iceberg ise sorgu motoruna daha fazla yapı sunması bakımından daha ileri gidiyor.Postgres gibi geleneksel DBMS'lerde şema, sorgu motoru ve depolama formatı tek bir paket olarak gelir.
Ama büyük veride veritabanı bileşenlerini sıfırdan birleştirebilir ve birbirleriyle karıştırıp kullanabilirsiniz. Metadata formatı olarak Iceberg'i, sorgu motoru olarak DuckDB'yi, depolama formatı olarak Parquet'i, depolama ortamı olarak S3'ü kullanabilirsiniz.
Veritabanı dünyası için büyük bir değişim. Çünkü Delta, Iceberg ve Hudi sayesinde veriler çoğunlukla S3 üzerinde açık kaynak biçimlerde saklanıyor.
Depolama ve işlemenin önemli bir kısmı standartlaşınca veritabanları arasında geçiş kolaylaşıyor; neredeyse tüm araçlar da sonunda aynı dosya kümesini işlem güvenliğiyle ele alabilir hâle geliyor.
Örneğin Snowflake dosyalara yazarken, bir veri bilimci Jupyter notebook içinde gerçek zamanlı sorgu çalıştırabilir; ClickHouse da aynı veri üzerinde tutarlılık garantilerini koruyarak kullanıcıya dönük analiz sunabilir.
Daha sonra şirket Snowflake’ten Databricks’e geçmeye karar verse bile bu artık o kadar büyük bir mesele olmuyor.
Şu anda bu biçimleri S3 üzerinde sorgulamak yerel yükleme kadar hızlı değil, ancak piyasa baskısı tüm veritabanı üreticilerini performans optimizasyonuna zorlayacak ve sonunda yerel yüklenmiş verinin performansına yaklaşılacak.
Açıklık ve açık kaynak açısından, ayrıca şirketlerin verilerini açık ve taşınabilir biçimlerde tutması açısından büyük bir kazanım.
Lakehouse da aynı anlama geliyor. Birçok şirket hem data lake hem de data warehouse bulunduruyor ve veriyi ikisi arasında kopyalamak zorunda kalıyor.
Aynı veri kümesini sorgulayıp yönetecek tek bir sisteme sahip olmak da aynı şekilde büyük etki yaratıyor.
Veri mühendisliği alanında olmak için çok heyecan verici bir dönem.
Gelecekte, sorgu çalıştırma sırasında yürütme planlarını yalnızca bulut genelindeki çeşitli motorlara değil, yerel makinelere de gönderebildiğimiz bir gelecek görünüyor.
Snowflake için belki de işi kapatıp yatırımcılara milyarlarca doları geri vermek daha iyi olurdu. Veriyi kendi ekosistemlerine kilitlemek onların tüm iş modeli.
Açık standartların şirketleri tescilli teknolojilerden vazgeçmeye zorladığı iyi bir örnek var mı merak ediyorum.
“Apache Arrow dataframe’lerini disk dosyası olarak saklamanın en iyi yolu Feather’dır; Apache Parquet gibi biçimlere de dönüştürülebilir” ifadesine kesinlikle katılmıyorum.
JVM dışı bir lakehouse’u doğrudan kurmak istiyorsanız en iyi yapılandırma metadata için Iceberg, veri için Parquet, sorgu motoru olarak DuckDB kullanmak ve Arrow tabloları üzerinden sorgulamaktır.
Parquet’i doğrudan Arrow’a okumanın maliyeti çok düşüktür; ardından Arrow→Pandas veya Polars’a aktarabilirsiniz. Bunu doğrudan ya da Arrow Flight tabanlı bir servis üzerinden yapabilirsiniz.
Buraya Feather’ı dahil ederseniz mevcut Python lakehouse stack’inin tamamı düzgün çalışmaz.
Şimdi değişmiş olabilir, ama hâlâ Parquet geleceğe en dayanıklı seçenek gibi geliyor.
Data lake’i duymuştum ama “data lakehouse” kulağa üst sınıf verilerin yazın veri teknesine binip veri balığı tutmaya gittiği yer gibi geliyor.
Birçok şirket verilerini data lake’te saklıyor, Tableau veya PowerBI gibi araçlara BI sağlamak için de warehouse kullanıyor. Sonra veriyi ikisi arasında kopyalamak zorunda kalıyorlar.
Lake’i doğrudan sorgularken transaction ve governance’ı tek bir veri kümesine uygulayan data lakehouse, stack’i ciddi biçimde sadeleştirip maliyeti de düşürebilir.
Her duyduğumda veya okuduğumda zihnimde epey tuhaf hissettiriyor.
Iceberg’den özellikle umutluyum. Çünkü açık kaynak.
Ancak en son baktığımda tek uygulama Spark kütüphanesiydi ve Trino’nun (eski Presto, SQL motoru) Iceberg connector’ı Hive’a güçlü biçimde bağımlıydı.
Sektör genelinin MapReduce, Hive ve hatta söylemeye cesaret edersem Spark mirasından boşanmakta zorlandığı hissine kapılmıştım.
O zamandan beri Iceberg’e tekrar bakmadım ama yakında bakmayı düşünüyorum; bu alanın gelişmesini gerçekten bekliyorum.
Artık eski teknolojiler olmadan da veriyi işleyecek araçlara ve hesaplama gücüne sahibiz; ayrıca her veri de big data değil.
Bu yüzden neyse ki veri mühendisliği giderek genel backend geliştirmeye benziyor ve sıradan geliştirme pratikleri de yerleşiyor.
Çok yakın gelecekte saf bir Python Iceberg kütüphanesi çıkmasını umuyorum.
Bu bağımlılığı kaldırmak için muazzam bir emek harcandı.
Databend’i bir saat içinde ayağa kaldırdım; Rust uygulaması ortaya çıktığında Java/Hive’a kıyasla taşınabilirliğin artacağını ve ileride düzgün kullanmanın daha kolaylaşacağını düşündüm.
Bütün bunları neden daha somut açıklayamadıklerini bilmiyorum.
Verinin nasıl saklandığını, nasıl bağlanıp sorgulandığını ve sorguların ne kadar hızlı olduğunu anlatmaları iyi olurdu. Örneğin transaction hızı ile analitik sorgu hızı arasındaki fark gibi.
Şu anda GCP’de yaklaşık 100 TB veriyle çalışıyoruz; sorgu motoru olarak BigQuery kullanıyor ve
/key3=000/key2=002/gibi basit Hive partitioning’den yararlanıyoruz.İstediğimiz tüm sorguları çalıştırabiliyoruz ve maliyet de inanılmaz düşük olduğu için memnunuz.
Ancak gecikme süresi epey yükseliyor; bizim için çok kritik değil. Yine de Iceberg’i devreye alırsak bunun iyileşip iyileşmeyeceğini merak ediyorum.
Bu konuda deneyimi olan var mı merak ediyorum; genel olarak da bu mimari gerçekten harika.
Bu teknolojilerin ana amacı büyük ölçekli veri yönetimi, ama Parquet gibi ham depolama formatlarının sunduğu özellikleri de genişletiyorlar. Bu yüzden yardımcı olabilir; fakat gerçekten gerekli olup olmadığını değerlendirmek gerekir.
BigQuery kullanmadım ama benzer özellikler olabilir.
Önce burada “gecikme süresi” ile neyin kastedildiğini ve “epey yüksek”in hangi seviye olduğunu tanımlamak gerekir.
Analitik veri depoları verimli toplu işleme için tasarlanmıştır; tekil bir kaydı bulmak bu mimarinin başlıca hedefi değildir. Hızlı arama için caching veya indexing gerekir.
Bazı durumlarda tekil kayıt aramasına sadece
limit 1eklemek bile çözüm olabilir.Parquet gibi verimli bir veri depolama formatı kullanıp kullanmadığınızı doğrulamak ve dosya boyutlarını kontrol ederek "small file problem" olup olmadığına bakmak gerekir.
Sonrasında ilgili BigQuery özelliklerini kullanıp kullanmadığınızı da kontrol etmelisiniz. Bu kontrollerden önce ve sonra sorguda
explainçalıştırın; partition key veya index sütunu kullanmıyorsanız hiçbir büyük veri sisteminde arama sonuçları anında gelmez.BigQuery tablolarını yüksek throughput’lu hesaplamanın girdisi olarak kullanmıyorsanız, BI aracını optimize etmeye veya son kullanıcı gecikmesini önleyen analitik tablolar oluşturmaya odaklanırdım.
Örneğin yakın zamanda fact/dimension tablo join’lerini ve
COALESCEişlemlerini materialize ederek analize özel büyük bir tablo oluşturduk.Kavramsal olarak normal veri ambarı düzeninin “dışında” olsa da dbt içinde yer aldığı için veri kalitesini ve lineage’ı korumaya devam edebildik.
Bu sayede Tableau fixed calculation’ları ortadan kaldırdık ve son kullanıcıların yükleme/gruplama süresini yaklaşık %95 azalttık.
GCS/S3 üzerinde federated query ise hızlanabilir.
“Bu yazı %100 kapsamlı değil ve çoğu insan için en iyi başlangıç noktası da muhtemelen değil. Çünkü kendim için yazıyorum. Yeni bir şey öğrenmenin en iyi yolunun, onu başkasına yeniden anlatmaya kendimi zorlamak olduğunu hissediyorum” şeklindeki tutumu gerçekten sevdim.
Ben de kâğıt üzerinde ve web sitemdeki notlarda bu yaklaşımı benimsemeye başladım.
Daha yönetilebilir Parquet depolarının Iceberg çağını derinlemesine incelemeyi çok bekliyordum.
Ancak hızlı GPU I/O (GPUDirect/cuFile) desteği hâlâ birkaç yıl geride.
Bu yüzden AI iş yükleri için müşterilere götürmeye çalıştığımız her seferinde o duvara çarpıyoruz.
Sonunda olacak gibi görünüyor; “mümkün mü”den çok “ne zaman” sorusuna yakın. İki hedefi birden tutturabilirsek gerçekten harika olacak.
Metin depolama için bugün Parquet yeterli.
PyTorch Data Loader ve TF Data, paralel olarak önceden okuyan, bellek buffer’ını dolduran ve GPU ile veri alışverişi yapan çok thread’li istemciler sunuyor.
S3’ün burada darboğaz olabileceğine katılıyorum. Bu yüzden biz S3’ün üzerine küresel olarak dağıtılmış tutarlı bir NVMe cache olarak HopsFS koyuyoruz.
Anyscale de S3 için yerel NVMe cache ile benzer bir iş yapıyor.
İlginç bir dosya formatı olarak Lance de var; Parquet’e benziyor ama görüntü verileri için. Dosya içinde görüntüleri bulmaya yönelik hızlı random I/O index’i de ek olarak var.