Apache Iceberg'in bakım açığı, yönetilen veri göllerinin asıl hikayesi

Iceberg formatı çözdü, operasyonları değil

dev.to'da yayımlanan, 2027'nin yönetilen veri gölüne ileriye dönük bir bakış olarak çerçevelenen bir rehber, sert bir öncülle açılıyor: Apache Iceberg artık üretim veri gölleri için standart tablo formatı, tüm büyük motorlar onu doğal olarak okuyup yazabiliyor, katalog ekosistemi REST üzerinde standardize olmuş durumda ve veri, sahibinin kontrolündeki standart object storage üzerinde tutuluyor. Yani format sorunu çözülmüş — geriye kalan sorun operasyonel.

Rehberde açıklandığı üzere Iceberg, tablo formatını tabloları sağlıklı tutan sistemden kasıtlı olarak ayırıyor. Bakım prosedürleriyle birlikte geliyor — rewrite_data_files, expire_snapshots, remove_orphan_files, rewrite_manifests — ama bunların ne zaman, hangi sırada ve ne kadar agresif çalıştırılacağına dair bir mantık içermiyor. Yazar, kendi haline bırakıldığında her Iceberg tablosunun bozulduğunu savunuyor: küçük dosyalar birikiyor, snapshot metadata'sı şişiyor, fiziksel sıralama düzeni sorguların gerçekten filtrelediği biçimden uzaklaşıyor, yetim dosyalar depolama maliyetlerini şişiriyor ve performans, görünür bir şey kırılana kadar düşüyor.

Yönetilmeyen göller nasıl bozuluyor

İlk arıza modu küçük dosyalar. Flink, Spark Structured Streaming, Kafka Connect, RisingWave ve CDC connector'ları gibi streaming yazarları, çıktıyı verimli okuma boyutuna göre değil checkpoint aralığına göre boyutlandırıyor. Rehberdeki somut örnek: 60 saniyede bir commit yapan ve 100 aktif partition'a yayılan bir Flink job'ı, günde yaklaşık 144.000 dosya üretiyor; her biri kabaca 1–5 MB, oysa verimli okuma hedefi 128–512 MB. Her dosya dosya başına ek yük getiriyor — binde 0,0004 dolara S3 GET istekleri, Parquet footer ayrıştırması, motor task slot'ları — dolayısıyla sorgu hesaplama gücü veri hacmiyle değil dosya sayısıyla ölçekleniyor. Batch tabloları aylar içinde bozulur; yüksek throughput'lu bir streaming tablosu canlıya alındıktan sonra birkaç saat içinde bozulabilir.

Sıradaki birikim snapshot'larda. Her commit bir snapshot oluşturur; time travel ve rollback'i mümkün kılan da budur, ama beş dakikada bir commit yapan bir tablo günde yaklaşık 288 snapshot ekler. Kabaca 1.000–2.000 saklanan snapshot'ın ötesinde planlama belirgin şekilde yavaşlar ve rehber, üretimde metadata.files boyutunun 400 MB'ı aştığını raporluyor. Tipik analitik iş yükleri için 3–7 gün, regüle sektörler için 30–90 gün saklama öneriyor ve planlama süresi ödünü açıkça ortaya koyuyor.

Manifest parçalanması planlama maliyetini katlıyor. Her commit en az bir manifest kaydı ekler ve aylarca süren streaming yazımları, planlayıcıların herhangi bir veriyi açmadan önce okuması gereken yüzlerce ya da binlerce küçük manifest bırakır. Rehber, ekiplerin bunu rutin olarak bir motor sorunu olarak yanlış teşhis ettiğini savunuyor — belleği ayarlıyor, coordinator'ları ölçekliyor, sürüm yükseltiyorlar — oysa manifestleri daha az ve daha büyük dosyalara yeniden yazmak, az ekip tarafından otomatikleştirilen yüksek etkili bir operasyon. Iceberg 1.11 ile gelen sunucu tarafı scan planning, yalın manifestleri daha da değerli kılıyor.

Yetim dosyalar ise sessiz bütçe kalemi. Başarısız Spark stage'leri, yarıda kesilen compaction, iptal edilen yazımlar ve büyük yeniden yazma işlemleri sırasındaki OOM kill'leri, hiçbir snapshot'ın referans vermediği dosyalar bırakıyor. Bunlar sorgulara, Iceberg metadata'sına ve veri kalitesi kontrollerine görünmezdir; yalnızca storage prefix'lerini listeyip katalogla karşılaştırarak bulunabilirler. Rehbere göre üretim ortamındaki yetim dosya temizlikleri, bir gölün depolamasının yüzde 20–40'ını rutin olarak geri kazanıyor; GB başına ayda 0,023 dolarlık S3 Standard fiyatıyla 100 TB'lık bir göl için bu, aylık 460–920 dolar ölü ağırlık demek.

Sıralama düzeni kayması son parça. Bin-pack compaction küçük dosyaları birleştirir ama düzen için hiçbir şey yapmaz. transaction_id sırasına göre eklenen ama customer_id ve event_date ile sorgulanan bir işlem tablosu, Parquet min/max istatistikleriyle dosya atlayamaz; tek müşterilik bir sorgu her şeyi tarar. Aynı veri filtrelenen sütunlara göre yeniden sıralandığında, motorlar tarama hacminin yüzde 95'ini veya daha fazlasını eleyebiliyor. Sorgu desenleri yeni tüketiciler geldikçe değiştiği için, manuel sıralama ayarı yüzlerce tabloya ölçeklenmez.

Control plane öncülü

Rehber, bu sorunu çözmenin tam maliyetini ödemiş iki şirkete işaret ediyor. Netflix dört dahili servis inşa etti — compaction stratejisi seçimi için Autotune, katalog yönetimi için Polaris, çöp toplama için janitor servisleri ve servisler arası gözlemlenebilirlik için Metacat — her biri yıllar boyunca özel ekipler tarafından bakıldı. Google ise otomatik compaction ve çöp toplamayı doğrudan BigLake'in içine mühendislikle yerleştirdi; böylece yönetilen Iceberg tabloları, yazma hacimleri ve sorgu desenleri nasıl değişirse değişsin sağlıklı kalıyor. Rehberin 2027 için önerisi şu: bu yatırımın artık tekrarlanması gerekmiyor; "yönetilen" artık tam olarak bu control plane'i kiralamak anlamına geliyor — bir ekip ister 50 tablo ister 5.000 tablo çalıştırsın.

Neden önemli

Iceberg artı REST katalogları, lakehouse modelinin vaat ettiği taşınabilirliği sunuyor: tek veri kopyası, çok sayıda motor, format kilidi yok. Ama bu rehber, bir gölün gerçek işletme maliyetini bakımda konumlandırıyor — planlama gecikmesi, tarama hacmi ve depolama faturalarının hepsi compaction, snapshot expiry, manifest hijyeni ve sıralama düzenine kadar izlenebilir; hiçbirini format kendi başına ele almıyor. Platform değerlendiren bulut veri ekipleri için kontrol listesi somut: hangi bakım döngüleri otomatik çalışıyor, varsayılan olarak hangi snapshot saklama süresi geliyor, yetim dosya taramaları depolamayı katalogla ne sıklıkla karşılaştırıyor ve sorgu desenleri değiştikçe sıralama düzenleri uyum sağlıyor mu. Ucuz bir göl ile pahalı bir göl arasındaki fark artık tablo formatı değil. Bakımı kimin ya da neyin yürüttüğü.