Iceberg tablo formatı, iyi fikir - yanlış tanımlanmış bir spesifikasyon - 2/2

Iceberg spesifikasyonunun sorunları

• Iceberg spesifikasyonundaki ciddi sorun: Iceberg spesifikasyonu, büyük ölçekli veri göllerinin metadata sorununu çözmeye yönelik ciddi bir girişim değil.
• Tarihsel dersler: İlk bölümde geçmişin derslerini öğrenmek için tarihe dönüldü ve veritabanlarının çözmesi gereken "alan yönetimi problemi" tanıtıldı.
  • Problemin unsurları:
    1. Alan parçalanması
    2. İnce taneli eşzamanlılık denetimi
    3. Birden fazla nesne üzerinde atomiklik
    4. Satırlar ile dosyalar arasındaki empedans uyumsuzluğu
    5. Metadata'ya düşük gecikmeli ve yüksek verimli erişim
• Açık formatların önemi: Yığının her katmanında açık formatlar kullanılmasını %100 destekliyorum ve özellikle tablo yapısındaki veriler için ortak depolama formatı olarak Parquet kullanılmasından heyecan duyuyorum.
• Parquet dosyaları ile veritabanı tabloları arasındaki fark: Bir araya gelmiş Parquet dosyaları otomatik olarak bir veritabanı tablosu oluşturmaz. Veritabanı tablosu, basit bir satır kümesinden daha fazlasıdır.

Metadata problemi özeti

• Alan yönetimi problemi: Veritabanlarının çözmesi gereken çeşitli sorunlar yeniden vurgulandı.
• Metadata gereksinimi: Birden çok Parquet dosyasını bir veritabanı tablosu gibi gösterebilmek için şu metadata gerekir:
  1. Tabloyu oluşturan tüm dosya konumlarının listesi
  2. Her dosya için yaklaşık metadata
  3. Dosya ekleme veya kaldırmayı mümkün kılan bir transaction kontrol mekanizması
  4. Tablo şemasını evrimleştirmenin bir yolu
• Dosya konumlarını bulma: Bir Parquet dosyası kümesini tek bir tablo olarak ele almak için dosyaları bulmaya yarayan bir mekanizma gerekir.
• Metadata'nın önemi: Her dosya, ilgi çekici satırları hızlıca bulabilmek için ek metadata gerektirir.

Parquet dosyaları ve veritabanı tabloları

• Parquet dosyasının tanımı: Parquet, kendi kendini tanımlayan ve tablo biçimli bir veri formatı sunar.
• Veritabanı tablosunun tanımı: Veritabanı tablosu yalnızca bir satır kümesi değildir; çeşitli metadata ve transaction kontrolü gerektirir.
• Parquet dosyalarını tablo gibi kullanma koşulları:
  1. Dosya konumları listesi
  2. Her dosyanın metadata'sı
  3. Dosya ekleme ve kaldırma için transaction kontrol mekanizması
  4. Tablo şemasını evrimleştirmenin yöntemi
• Dosya ile tablo arasındaki fark: Parquet dosyalarının aynı sütun düzenine sahip olması, onların bir veritabanı tablosu gibi görünmesi için yeterli değildir.

Manifest dosyaları ve listeleri

• Veri ekleme süreci: Bir Iceberg istemcisinin tabloya veri eklemek için şu adımlardan geçmesi gerekir:
  1. Belirli bir konuma (ör. S3) bir veya daha fazla Parquet dosyası yazar.
  2. 1. adımda yazılan dosyaları işaret eden bir manifest dosyası yazar.
  3. Yeni bir manifest listesi yazar.
• Manifest dosyalarının formatı: Manifest dosyaları ve listeleri AVRO formatındadır; bu format sıkıştırılmıştır ve kendi kendini tanımlar.
• Manifest dosyalarının içeriği: Manifest dosyaları, Parquet dosyalarına işaretçiler ve her sütun için metadata içerir.
• Metadata boyutu sorunu: Metadata'nın bu şekilde saklanması, gerekenden daha büyük olmasına yol açar ve dosyalar arasındaki ortak string değerlerini fark edip sıkıştıramaz.

İstemci üzerindeki yükün artması

• İstemcinin sorumluluğu: Iceberg spesifikasyonu boyunca istemci, basit değişiklikler için bile çok büyük miktarda kayıt yönetimi yapmak zorundadır.
• Metadata doğruluğu sorunu: İstemci bir kısmını yanlış yazarsa, yeni snapshot commit'inin çok sıkı biçimde doğrulanması ve manifest verisinin doğru yazıldığının kontrol edilmesi gerekir.
• Güvenlik sorunu: İstemcinin tüm manifest dosyalarını işaret eden bir manifest listesi yazması gerektiğinden, tüm S3 dosyalarının konumları açığa çıkar.
• Veri güvenliğinin önemi: Verinin değeri bu kadar yüksekken, spesifikasyonun neden güvenliği en öncelikli konu olarak ele almadığı sorgulanmalıdır.

Satır güvenliğindeki kusurlar

• Satır güvenliği ihtiyacı: ABD gibi daha gevşek düzenlenen ülkelerde bile hassas verileri korumak için satır düzeyinde güvenlik gerekir.
• AB'nin GDPR'ı: Avrupa'da GDPR gibi yasalar nedeniyle veri erişimi konusunda çok daha hassas olmak gerekir.
• İstemcinin veri erişimi sorunu: İstemci tabloya veri ekleyebilir, ancak zaten var olan verilere erişimi kısıtlayamaz.
• Güvenlik sorununun ciddiyeti: Spesifikasyonun güvenliği önceliklendirmemesi, veri gölü bilgisinin değeri hakkında soru işaretleri yaratmalıdır.

Metadata dosyasının rolü

• Metadata dosyasının yazılması: İstemci Parquet dosyalarını yazdıktan sonra ilgili manifest dosyasını üretmeli, mevcut manifest listesini okumalı, yeni bir manifest listesi oluşturmalı ve ardından veriyi commit etmelidir.
• Commit süreci: Commit, metadata dosyası (<prefix>.metadata.json) yazılarak gerçekleştirilir.
• JSON formatı seçimi: Metadata dosyasının neden JSON formatında olduğu belirsizdir; bu, "komite tarafından tasarım" hissi veriyor.
• Metadata'nın tekrarlılığı: Metadata dosyası tüm snapshot'ları listeler ve bu, bilginin tekrarı nedeniyle alan israfına yol açar.

Commit sürecinin karmaşıklığı

• Atomiklik sorunu: Yeni metadata dosyasının en güncel dosya haline getirilmesi ve önceki metadata dosyasının onunla atomik olarak değiştirilmesi gerekir.
• Commit prosedürünün karmaşıklığı: Yeni metadata sürümü V+1'i commit etmek için şu adımlar izlenmelidir:
  1. Mevcut metadata'ya dayanarak yeni tablo metadata dosyasını oluştur.
  2. Yeni tablo metadata'sını benzersiz bir dosyaya yaz.
  3. Metastore'a istekte bulunarak tablonun metadata pointer'ını V'den V+1'e değiştir.
• Swap başarısız olduğunda yapılacaklar: Swap başarısız olursa, başka bir yazar zaten V+1'i üretmiş demektir; bu durumda istemci 1. adıma geri dönmelidir.
• Race condition sorunu: İstemciler yarıştığında, önceki istemcinin yazdığı metadata dosyası yeniden okunmalı ve manifest listesiyle metadata dosyası yeniden oluşturulmalıdır.

İyimser eşzamanlılık denetiminin sorunları

• Eşzamanlılığın gerçeği: Bir kaynak üzerinde rekabet beklenmiyorsa, hangi tür eşzamanlılığın kullanıldığının pek önemi yoktur.
• Rekabet beklenen durumlar: İki istemci aynı değeri değiştirmeye çalışıyorsa, bir kilitleme mekanizması kullanılmalıdır.
• İyimser eşzamanlılık denetiminin sınırları: Iceberg'de iki eşzamanlı yazma her zaman çakışır; bunun sebebi spesifikasyonun tasarım biçimidir.
• En kötü kilitleme semantiği: Metadata üzerinde mümkün olan en kötü kilitleme semantiği kullanılıyor; yalnızca veri eklemek isteniyorsa istemciler arasında koordinasyon gerekmemelidir.

Metadata swap'inin sınırları

• Metadata'nın merkezileştirilmesi: Tablo metadata'sını tek bir dosyada merkezileştirerek tüm yazmalar için tek bir rekabet noktası yaratılmıştır.
• Yeniden denemelerde istemci yükü: İstemci başarısız olursa, önceki istemcinin yazdığı veriyi okumalı ve manifest listesiyle metadata dosyasını yeniden oluşturmalıdır.
• Metadata swap'inin hızı: Metadata swap'ini yapan servis, yeniden denemeleri de yönetmek zorundadır; bu da performans düşüşüne yol açar.
• Sınırlı commit sayısı: Basit eşzamanlılık uygulaması nedeniyle commit sayısı sınırlıdır; bu sınır, metadata dosyasının atomik değiştirilme süresi tarafından belirlenir.

Veritabanı gerekliliği

• Metadata dosyasının konumunu bulma: Iceberg tablo snapshot'ı tamamen metadata.json dosyasıyla tanımlanır.
• Fikrin çelişkisi: Iceberg yalnızca dosyalarla bir metadata formatı tanımlamaya çalışsa da, sonunda yine bir veritabanına ihtiyaç duyar.
• Veritabanının avantajları: Modern veritabanları yüz binlerce yazmayı işleyebilir ve dağıtık biçimde ölçeklenebilir.
• Dosya sistemi ve veritabanı karşılaştırması: Metadata'yı dosyalarda saklamak yerine veritabanında saklamak daha verimlidir.

Parçalanma ve metadata şişmesi

• metadata.json dosyasının büyümesi: metadata.json dosyası en güncel snapshot'a işaret eder ve her metadata dosyası önceki snapshot'lara geri işaretçiler içerir.
• Metadata'nın sürekli artışı: Metadata sürekli büyür; bu da veri gölünün performansını olumsuz etkiler.
• Düzenli metadata temizliği ihtiyacı: Veri gölüne sürekli veri ekleniyorsa metadata'nın temizlenmesi gerekir.
• HTTP istek maliyeti: Metadata dosyalarını silme sürecinde HTTP istekleri oluşur ve bu da maliyet yaratabilir.

Veri okuma ve sorgu planlama

• Manifest dosyalarının rolü: Manifest dosyaları, Parquet dosyaları hakkında metadata içerir.
• Sorgu planlamasının karmaşıklığı: Bir sorguyu çalıştırmak için manifest listeleri ve manifest dosyaları sırayla okunmalıdır.
• Maliyet sorunu: S3 üzerinden okuma maliyeti oluşur ve bu da sorgu yürütme hızını etkiler.
• Metadata parçalanması sorunu: Metadata parçalanırsa sorgu planlaması karmaşıklaşır ve veriye erişim zorlaşır.

Önbellekleme ve sorgu planlamadaki zorluklar

• Manifest önbellekleme: Manifest'ler önbelleğe alınabilir, ancak metadata boyutunun büyümesi nedeniyle bu verimsizdir.
• Önbelleğin geçerliliğini koruma: Önbelleğin güncel kaldığının doğrulanması gerekir; bu da ek maliyet ve karmaşıklık doğurur.
• İstemci üzerindeki yük: Tüm istemciler metadata'yı önbelleğe almak zorundadır ve bu da milyonlarca HTTP isteği yaratır.
• Karmaşıklığın artması: Veri gölü kullanımı daha karmaşık hale gelir ve bunu çözmek için ek çözümler gerekir.

Fikrin vardığı sonuç

• Fikre yönelik eleştiri: Iceberg spesifikasyonu, veri gölü metadata'sı için ciddi bir spesifikasyon değil ve birçok sorun barındırıyor.
• Sorunların özeti: Iceberg, metadata eklemek için O(n) iş kullanıyor, tablolar arası commit'leri ele alamıyor ve metadata şişmesi sorununu çözemiyor.
• Ölçekleme sınırları: Iceberg ölçeklenmeye uygun değil ve aşırı karmaşıklığı istemcilere yüklüyor.
• Sektöre yönelik soru: BT sektöründe bu tür sorunların neden ortaya çıktığı sorusunu gündeme getiriyor.