Apache Iceberg V3: Silme Vektörleri Veri Ekonomisini Değiştirdi
Apache Iceberg'de satır silmenin neden zor olduğunu, v2'nin silme dosyalarını ve v3'ün silme vektörlerinin bu maliyeti nasıl dönüştürdüğünü inceliyoruz.
Object storage üzerine kurulu veri göllerinde tek bir satırı silmek göründüğünden çok daha zordur, çünkü S3 gibi sistemler dosyaların içeriğini yerinde değiştirmeye izin vermez. Apache Iceberg bu kısıtı iki temel stratejiyle çözer: copy-on-write, yani etkilenen dosyayı baştan yazmak, ve merge-on-read, yani eski dosyayı olduğu gibi bırakıp ayrı 'silme kayıtları' tutmak. Iceberg v2, bu ikinci yaklaşımı konum tabanlı (position) ve değer tabanlı (equality) silme dosyalarıyla üretime taşıyarak CDC ve hedefli silme senaryolarını mümkün kıldı.
Ancak ölçek büyüdükçe v2'nin konum tabanlı silme dosyalarında ciddi bir birikim sorunu ortaya çıktı. Sık güncellenen bir veri dosyası, her commit ile onlarca küçük silme dosyası biriktirebiliyor; okuma sırasında motorun bunların hepsini bulup açması, birleştirmesi ve bellek üzerinde çözmesi gerekiyor. AWS'nin analitik ekibinin de belirttiği gibi bu durum, çok sayıda küçük dosya okuması ve pahalı bellek içi dönüşümler yüzünden motorlara ağır bir yük bindiriyor.
Iceberg v3'ün getirdiği silme vektörleri, tam olarak bu sorunu hedefliyor: dağınık pamphlet yığınları yerine daha stabil ve hızlı uygulanabilen tek bir silme temsili sunarak okuma tarafındaki maliyeti önemli ölçüde azaltıyor. Bu değişim, yalnızca bir depolama detayı değil; lakehouse mimarilerinin CDC, streaming güncellemeler ve hedefli silme gibi sık değişen iş yüklerini ne kadar sağlıklı destekleyebileceğini doğrudan belirleyen bir mühendislik kararı.