Apache Hudi ve Apache Iceberg: Upsert Ağırlıklı mı, Analitik Ağırlıklı mı?

İki projenin çıkış noktası

Hudi ve Iceberg aynı aileden iki açık tablo formatıdır: veri nesne deposundaki Parquet gibi kolon dosyalarında durur, üstteki metadata katmanı tabloya işlem desteği, zaman yolculuğu ve şema evrimi kazandırır. Ancak bu projeler farklı bir açıdan doğmuştur ve bu köken bugünkü güçlü yanlarını hâlâ belirler.

Hudi kendini, veri gölüne veritabanı işlevlerini getiren ve artımlı veri hatlarında hızlı yazma için tasarlanmış bir lakehouse platformu olarak tanımlar. Odağı, sürekli değişen kayıtları (upsert ve delete) verimli işlemek ve aşağı akıştaki işlere yalnızca değişen veriyi vermektir. Iceberg ise çok büyük analitik tablolar ve nesne depolarındaki doğruluk sorunları için tasarlanmıştır; belgelerinde kullanıcının bölümlemeyi bilmeden hızlı sorgu alabilmesini ve formatın motordan bağımsız bir açık standart olmasını öne çıkarır.

Yazma yolu: kayıt anahtarı ve tablo tipleri

Hudi'de her kaydın bir anahtarı vardır ve yazma sırasında bu anahtar bir indeks üzerinden aranarak kaydın hangi dosya grubunda durduğu bulunur. Böylece gelen bir değişiklik, tablonun tamamını taramadan doğru dosyaya yönlendirilir. Hudi iki tablo tipi sunar:

• Copy on Write: güncelleme, ilgili temel dosyanın yeniden yazılmasıyla yapılır. Günlük dosyası yoktur, okuma hızlıdır, yazma maliyeti daha yüksektir.
• Merge on Read: güncellemeler hafif günlük dosyalarına eklenir, periyodik sıkıştırma (compaction) bu değişiklikleri yeni bir temel dosyada birleştirir. Yazma gecikmesi düşer, okuma sırasında birleştirme yükü oluşur.

Iceberg'de satır düzeyi değişiklik iki yoldan yapılır: etkilenen veri dosyasını yeniden yazmak ya da format sürümü v2 ile gelen silme dosyalarıyla değişikliği işaretleyip okumada uygulamak; v3 ile ikili silme vektörleri de belirtime eklendi. Iceberg'de kaydın yerini bulan kalıcı bir kayıt indeksi yoktur; eşleşme MERGE sorgusunun motor tarafından çalıştırılmasıyla bulunur ve dosya ile bölüm istatistikleri taramayı daraltır.

Okuma yolu: artımlı sorgu ve değişiklik akışı

Hudi'nin ayırt edici yanı sorgu tipleridir. Anlık görüntü (snapshot) sorgusu tablonun en güncel halini verir; Merge on Read tablolarda yalnız temel dosyaları okuyan read-optimized sorgu daha hızlıdır ama son sıkıştırmadan sonraki değişiklikleri görmez. Artımlı sorgu, belirli bir andan bu yana değişen kayıtların son halini döndürür; CDC modunda ise her değişikliğin önceki ve sonraki görüntüsü ile işlem türü alınabilir. Hudi'de bütün bu işlemler zaman çizelgesi (timeline) adı verilen yapıda izlenir.

Iceberg'de her commit yeni bir snapshot üretir; iki snapshot arasındaki eklenen veriyi okumak (artımlı okuma) ve geçmiş bir snapshot'ı sorgulamak mümkündür. Ancak satır düzeyinde önceki ve sonraki değeri veren bir değişiklik akışı, kullanılan motorun bu özelliği sunmasına bağlıdır. Aşağı akışta yalnız değişen veriyle çalışan çok katmanlı hatlar kuracaksanız bu fark tasarımı doğrudan etkiler.

Ölçüt satırlarıyla karşılaştırma

• Tasarım odağı: Hudi / hızlı upsert, artımlı hatlar, akış alımı. Iceberg / büyük analitik tablolar, motordan bağımsız açık standart.
• Kayıt bulma: Hudi / kayıt anahtarı ve yazma sırasında kullanılan indeksler. Iceberg / indeks yok; dosya ve bölüm istatistikleriyle budama.
• Güncelleme stratejisi: Hudi / tablo düzeyinde Copy on Write ya da Merge on Read seçimi. Iceberg / dosya yeniden yazımı ya da silme dosyaları, işlem bazında seçilebilir.
• Değişen veriyi okuma: Hudi / artımlı ve CDC sorgu tipleri yerleşik. Iceberg / snapshot'lar arası artımlı okuma; satır düzeyi değişiklik akışı motora bağlı.
• Bölümleme: Hudi / bölüm yolları kayıt anahtarıyla birlikte tasarlanır. Iceberg / gizli bölümleme ve sorguları bozmadan bölümleme evrimi.
• Bakım işleri: Hudi / sıkıştırma, kümeleme ve temizlik gibi tablo hizmetleri; yazma işinin içinde ya da ayrı çalıştırılabilir. Iceberg / snapshot sona erdirme, veri dosyası yeniden yazma ve metadata temizliği motor üzerinden ayrı işler olarak çalıştırılır.
• Ekosistem: Hudi / Spark ve Flink ile yazma, birçok sorgu motoruyla okuma. Iceberg / Spark, Flink, Trino, Presto, Hive ve Impala dahil geniş motor ve katalog desteği.

Hangi iş yükünde hangisi?

Örneğin bir e-ticaret şirketi, sipariş veritabanındaki değişiklikleri değişen veri yakalama (CDC) ile sürekli veri gölüne aktarıyor olsun. Aynı sipariş gün içinde defalarca güncelleniyor, raporlama katmanı ise her saat yalnız değişen siparişleri işlemek istiyor. Bu senaryoda Hudi'nin Merge on Read tablosu yazma gecikmesini düşük tutar, artımlı sorgu aşağı akıştaki işin tüm tabloyu yeniden okumasını önler.

Aynı şirketin tıklama olayları ise yalnız eklenir, neredeyse hiç güncellenmez, veri bilimciler Spark ile, analistler Trino ile sorgular. Burada güncelleme verimliliğinin önemi azalır; motorlar arası uyum, gizli bölümleme ve katalog tabanlı yönetişim öne çıkar ve Iceberg daha doğal bir seçimdir.

Kısaca: güncelleme ve silme yoğunluğu yüksek, değişen veriyi zincir halinde işleyen hatlar Hudi'ye; ekleme ağırlıklı, büyük ve çok motorlu analitik tablolar Iceberg'e yakındır. İki iş yükü aynı platformdaysa ikisini birlikte kullanmak ya da Apache XTable gibi metadata çeviri araçlarıyla tek kopyayı iki formattan okumak değerlendirilebilir.

Sık yapılan işletim hataları

Hudi tarafında tipik bir hata, Merge on Read tabloda sıkıştırmayı ihmal etmektir; günlük dosyaları biriktikçe anlık görüntü sorgusu yavaşlar, read-optimized sorgu ise bayat veri döndürür. Hudi belgeleri, son bölümleri eski bölümlere göre daha sık sıkıştırmayı önerir. Diğer hata, kayıt anahtarını ve indeksi veri dağılımını düşünmeden seçmektir; yanlış anahtar yazma sırasında gereksiz dosyaların taranmasına yol açar.

Iceberg tarafında küçük dosya birikimi ve eski snapshot'ların temizlenmemesi tipik sorunlardır. Akışla sık commit yapılan tablolarda dosya sayısı hızla artar; düzenli yeniden yazma ve snapshot sona erdirme işleri planlanmazsa sorgu planlama süresi ve depolama maliyeti yükselir. Katalog seçiminin sonradan değiştirilmesi de zahmetlidir, bu karar baştan verilmelidir.

Mindset programlarında Hudi ve Iceberg

Apache Hudi ile Artımlı Veri İşleme programı, CDC ve akış verisiyle beslenen veri gölleri işleten veri mühendisleri için tablo tipleri, yazma işlemleri ve anahtar tasarımı, indeksleme ve bakım işleri üzerine kuruludur; değişen veriyi verimli işleme sorununu doğrudan ele alır.

Apache Iceberg ile Açık Tablo Formatı Yönetimi programı ise bölümleme ve şema evrimi, artımlı okuma ve motor entegrasyonu başlıklarıyla birden çok sorgu motorunu aynı tabloya bağlayan platform ekiplerine yöneliktir. Format kararını kurumsal düzeyde verecek mimarlar için Lakehouse Tablo Formatları Karşılaştırması ve Seçimi programı iş yükü bazlı karşılaştırmaya odaklanır.