Delta Lake ve Apache Iceberg: Lakehouse İçin Hangi Tablo Formatı?

Aynı sorunu çözen iki açık tablo formatı

Veri gölünde Parquet dosyaları tek başına bir tablo gibi davranmaz: iki iş aynı anda yazdığında okuyucu yarım kalmış bir sonucu görebilir, tek bir satırı silmek için klasörün tamamını yeniden yazmak gerekir, geçmiş bir durumu geri getirmek mümkün olmaz. Delta Lake ve Apache Iceberg bu sorunu aynı yoldan çözer: veri yine nesne deposundaki Parquet dosyalarında durur, üstüne hangi dosyanın tablonun hangi sürümüne ait olduğunu söyleyen bir metadata katmanı eklenir.

Bu ortak tasarım ikisine de benzer yetenekler kazandırır: ACID işlemler ve serileştirilebilir yalıtım, eski sürümlere zaman yolculuğu ve geri alma, şema denetimi ve evrimi, MERGE, UPDATE ve DELETE ile satır düzeyinde değişiklik. Bu yüzden seçim, "hangisi işlem desteği verir" sorusuyla değil, metadata'nın nasıl tutulduğu, bölümlemenin nasıl yönetildiği ve hangi motorların tabloya rahatça erişeceği sorularıyla yapılır.

Metadata nasıl tutuluyor?

Delta Lake'te tablonun gerçeği bir işlem günlüğüdür. Tablo klasöründeki günlük dizininde her commit sıralı bir sürüm dosyası olarak yazılır; dosya ekleme ve çıkarma eylemleri bu kayıtlarda tutulur ve günlük belirli aralıklarla kontrol noktası dosyalarında özetlenir. Okuyucu tablonun güncel halini bu günlüğü baştan ya da son kontrol noktasından itibaren okuyarak kurar.

Iceberg'de yapı ağaç biçimindedir. Tablo metadata dosyası şemayı, bölümleme tanımını, özellikleri ve snapshot listesini tutar. Her snapshot bir manifest listesine, manifest listesi de veri ve silme dosyalarını sıralayan manifest dosyalarına işaret eder. Commit, bir katalogdaki tablo işaretçisinin eski metadata dosyasından yenisine atomik olarak çevrilmesiyle gerçekleşir; Iceberg belirtimi serileştirilebilir yalıtımın temelini bu atomik değişim olarak tanımlar.

Pratik sonucu şudur: Iceberg bir katalog (Hive Metastore, REST katalog ya da bulut sağlayıcının kataloğu gibi) olmadan çalışmaz; katalog seçimi mimari kararın bir parçasıdır. Delta Lake'te tablo yolu kendi başına yeterlidir, katalog yönetişim ve keşif için eklenir.

Ölçüt ölçüt farklar

• Bölümleme: Delta Lake / bölümleme sütunları tabloda açıkça tanımlanır, sorgunun bu sütunlara filtre yazması budamayı kolaylaştırır. Iceberg / gizli bölümleme; bölüm değeri bir sütundan dönüşümle (örneğin olay zamanının günü) türetilir, kullanıcı ayrı bir tarih sütunu yönetmez.
• Bölümleme değişikliği: Delta Lake / bölüm düzenini değiştirmek genellikle tabloyu yeniden yazmayı gerektirir. Iceberg / bölümleme evrimi; yeni veri yeni düzenle yazılırken eski veri olduğu gibi kalır, sorgular bozulmaz.
• Satır düzeyi silme: Delta Lake / MERGE, UPDATE ve DELETE işlemleri; değişiklik dosya yeniden yazımı ya da silme işaretleriyle yapılır. Iceberg / v2 sürümüyle silme dosyaları, v3 ile ikili silme vektörleri belirtime eklendi.
• Akış: Delta Lake / aynı tablo hem toplu tablo hem akış kaynağı hem akış hedefi olarak kullanılabilir. Iceberg / Flink ve Spark ile akış yazımı ve artımlı okuma desteklenir.
• Motor ekosistemi: Delta Lake / Spark ile derin ve köklü entegrasyon; Flink, Hive ve Trino bağlayıcıları da var. Iceberg / tasarımı motordan bağımsız bir açık standart olarak kuruldu; Spark, Flink, Trino, Presto, Hive ve Impala entegrasyonları belgelenmiştir.
• Katalog: Delta Lake / tablo yolu yeterli, katalog isteğe bağlı. Iceberg / katalog zorunlu, commit katalog üzerinden yapılır.
• Yönetişim: İki projede de açık kaynak topluluk var; Delta Lake Linux Foundation altında, Iceberg Apache Software Foundation altında geliştirilir.

Hangi durumda hangisi?

Delta Lake'i öne çıkaran durumlar: • Veri platformunuz ağırlıkla Spark üzerinde ya da Spark tabanlı bir yönetilen platformda çalışıyor. • Toplu işler ile akış işlerini aynı tablo üzerinde birleştirmek istiyorsunuz (bronze, silver, gold katmanlı medallion düzeni gibi). • Ekip ayrı bir katalog hizmeti işletmeden tablo yoluyla çalışmayı tercih ediyor.

Iceberg'i öne çıkaran durumlar: • Aynı tabloya Spark ile yazıp Trino, Flink ya da başka bir sorgu motoruyla okuyacak, motor bağımlılığını azaltmak istiyorsunuz. • Tablolarınız çok büyük ve bölümleme düzeni veri hacmi büyüdükçe değişecek; gizli bölümleme ve bölümleme evrimi bu işi kolaylaştırır. • Merkezi bir katalog üzerinden erişim denetimi ve keşif kurgulamak istiyorsunuz.

Örneğin bir perakende şirketi, kasa işlemlerini Spark ile her saat tabloya yazıyor, analistler ise aynı tabloyu Trino üzerinden sorguluyor olsun. İlk yıllarda günlük bölümleme yeterliyken hacim büyüyünce saatlik bölümlemeye geçmek gerekirse Iceberg'de bu değişiklik eski veriyi yeniden yazmadan yapılır. Aynı şirket bütün işlerini tek bir Spark platformunda yürütüyorsa Delta Lake'in akış ve toplu iş birleşimi daha az parça ile çalışan bir yapı sunar.

Birlikte çalışabilirlik: ikisini birden okumak

Formatlar arasındaki sınır keskin değildir, çünkü üçü de (Delta Lake, Iceberg ve Hudi) veriyi Parquet dosyalarında tutar ve yalnızca metadata katmanında ayrışır. Delta Lake'in UniForm özelliği, her Delta commit'inden sonra Iceberg metadata'sını da üretir; resmî belgeye göre böylece Delta tabloları Iceberg istemcileriyle okunabilir. Bu erişim Iceberg tarafı için salt okumadır, yazma yine Delta üzerinden yapılır.

Apache XTable (eski adıyla OneTable) ise bir format değil, Hudi, Delta Lake ve Iceberg metadata'sını birbirine çeviren bir projedir ve Apache Software Foundation'da kuluçka aşamasındadır. Bu araçlar, bir formatı seçtikten sonra diğer formatı bekleyen bir motoru tamamen dışarıda bırakmamanızı sağlar. Ancak iki metadata'nın senkron tutulması bir işletim yükü getirir; yazma tarafında tek bir formatta karar kılmak yine gereklidir.

Karar öncesi kontrol listesi

Seçimi belgeye bakarak değil, kendi iş yükünüzle bir pilotta doğrulamak daha sağlıklıdır. Pilotta şu soruları cevaplayın:

• Tabloya hangi motorlar yazacak, hangileri yalnız okuyacak?
• Katalog olarak ne kullanılacak, erişim yetkileri nerede yönetilecek?
• Günlük MERGE ve silme işlemlerinin hacmi ne, küçük dosya sorunu nasıl giderilecek (sıkıştırma, eski snapshot ve dosyaların temizlenmesi)?
• Bölümleme düzeni ileride değişecek mi?
• Kişisel verilerin silinmesi gibi uyum gereklilikleri zaman yolculuğu ve eski dosya saklama süresiyle nasıl dengelenecek?

Sık yapılan hata, bakım işlerini unutmaktır. Her iki formatta da eski sürüm dosyaları ve snapshot'lar temizlenmezse depolama büyür ve sorgular yavaşlar; Delta Lake'te tablo bakım komutları, Iceberg'de snapshot sona erdirme ve veri dosyası yeniden yazma işlemleri düzenli işler olarak planlanmalıdır.

Mindset programlarında iki formatı çalışmak

Delta Lake ile Güvenilir Veri Gölü programı, veri mühendisleri ve platform ekipleri için işlem günlüğü mimarisi, MERGE ile yazma desenleri, zaman yolculuğu ve akış ile toplu işlemenin birleşimi üzerinden ilerler; Spark tabanlı bir platformda güvenilir tablolar kurmak isteyen ekiplere yöneliktir.

Apache Iceberg ile Açık Tablo Formatı Yönetimi programı ise bölümleme ve şema evrimi, bakım ve maliyet ile motor entegrasyonu başlıklarıyla çok motorlu bir veri gölü işleten ekiplere hitap eder. Seçim aşamasındaki mimarlar için Lakehouse Tablo Formatları Karşılaştırması ve Seçimi programı, iş yükü bazlı karşılaştırma ve risk ile karar adımlarını kurumsal bir karar sürecine dönüştürmeye odaklanır.