Apache Iceberg Nedir?

Selam data severler 👋

Bugün size o korkulu rüyanız olan, “nereye attığımı unuttum” köşesine dönen data lake’leriniz için bir super herodan bahsedeceğim: Apache Iceberg!

Şimdi dürüst olalım, data lake’ler harika fikir… kağıt üzerinde. “Atalım abi her şeyi oraya, sonra bakarız” dedik, ama sonra o “sonra” hiç gelmedi, değil mi? 😂 Binlerce dosya, farklı formatlar, kim kime dum duma bir ortam… Analiz yapmaya kalkınca saç baş yoluyoruz. İşte tam bu noktada “Bir saniye, burada daha akıllıca bir yol olmalı!” diye isyan bayrağını çekenler için Iceberg sahneye çıkıyor.

İşte bu kaosa “Dur!” diyenlerden biri de Netflix olmuş. Zamanında Hive’ın o eski, klasör tabanlı yapısıyla boğuşmaktan bıkmışlar (anlıyoruz sizi!) ve 2017’de Iceberg’i geliştirmişler. Sonra da “Böyle bir tablo formatı yaptık alın, siz de kullanın, sevaptır” diyerek 2018’de Apache Software Foundation’a bağışlamışlar. Sağ olsunlar, şimdi Apple’dan AWS’ye, LinkedIn’den Stripe’a kadar devler bu projeye omuz veriyor.

Peki, Nedir Bu “Table Format” Dedikleri Şey? Sihirli Değnek mi?

Iceberg’e dalmadan önce şu “table format” olayını bir netleştirelim. Neden lazım bu bize? Çünkü data lake’teki o dosya yığınını, sanki bildiğimiz, sevdiğimiz veritabanı tablolarıymış gibi kullanmak istiyoruz!

Normalde neyimiz var? Canımız ciğerimiz veritabanlarımız (hani şu her saniye veri ekleyip sildiğimiz operasyonel canavarlar) ve data warehouse’larımız (veriyi sütun sütun dizip analiz kastığımız yerler).

SQL yaz, tabloyla konuş, mis. Bunlar güzel, hoş ama bir sorunları da var: Her şeyi bizden saklıyorlar! Veri nerede, nasıl saklanıyor, hangi metadata takip ediliyor? Valla, kara kutu! Biz sadece SQL yazıp sorguluyoruz, gerisi Allah kerim.

Ama dünya değişti dostlar. Artık tek bir platform tüm dertlerimize deva olmuyor. Bir sürü farklı araç kullanmamız gerekiyor. Keşke verilerimizi tek bir yerde, düzgünce saklayabilsek dedik… İşte o yer data lake oldu. Ama gelin görün ki, data lake’e veri dökmek kolay da, oradan anlamlı bir şey çıkarmak tam bir işkenceydi. Veri gölü, analiz merkezinden çok, verilerin rastgele toplandığı bir “veri çöplüğüne” dönüşebiliyordu (itiraf edelim!).

İşte Iceberg gibi tablo formatları burada devreye giriyor. Diyor ki: “Durun yahu! O dağınık dosyaları sanki tek bir tabloymuş gibi görmenizi sağlayacak alengirli bir şeyler yapayım!” Bu alengirli dediğimiz şey aslında akıllıca tasarlanmış bir metadata katmanı.

Aslına bakacak olursak tablo formatına çok da uzak değiliz, çünkü Hive da aslında bir tablo formatı. Sadece modern tablo formatlarının yoğurt yiyişleri biraz farklı!

Bu katman sayesinde, data lake’teki yüzlerce Parquet dosyasını “Müşteriler” tablosu olarak görebiliyoruz. Ve işin güzeli, bu metadata sayesinde ACID işlemleri (hani şu veritabanlarının olmazsa olmazı), time travel (geçmişe dönüp “Eyvah ne yaptık biz?” deme lüksü) gibi havalı şeyleri data lake üzerinde yapabiliyoruz!

Yani özetle, tablo formatı = Data lake’teki dağınık dosya yığınını, sorgu motorlarımızın (Spark, Trino, Flink gardaşlarımızın) anlayabileceği, tek, tutarlı bir tablo gibi gösteren akıllı bir harita.

Eskiden Nasıldı Bu İşler? (Hive Amcanın Klasör Aşkı)

Ve Sahneye Iceberg Çıkar: “Dosyaları Sayın, Klasörleri Değil!”

Apache Iceberg: Nedir Bu Tam Olarak? (Ve Ne Değildir!)

Tamam tamam, geldik zurnanın zırt dediği yere. Apache Iceberg bir tablo formatı STANDARDIDIR. Altını çiziyorum, STANDART.

Amacı dünyayı kurtarmak değil, sadece tek bir şeyi çok iyi yapmak: Data lake üzerindeki tablolar için Metadatanin nasıl yönetileceğini tanımlamak.

Bu ne demek? Eğer bir araç (mesela Spark) Iceberg standardına uygun Metadata yazarsa, başka bir araç (mesela Trino) o Metadatayi okuyup tabloyu anlayabilir. Herkes aynı dili konuşur!

Iceberg projesi sadece standarttan ibaret değil tabii. Bu standardı kolayca kullanabilmemiz için bize API’lar ve kütüphaneler (Java, Python başta olmak üzere) sunuyor. Yani bir araç gelişticisiysen, Iceberg desteği eklemek için tekerleği yeniden icat etmene gerek yok, hazır kütüphaneyi kullanıyorsun.

ÖNEMLİ NOT: Apache Iceberg…

• Bir depolama DEĞİL! Verilerinizi hala S3, MinIO, ADLS gibi yerlerde saklarsınız. Iceberg sadece o verilerin haritasını tutar.
• Bir Execution Engine DEĞİLDİR! Sorgularınızı hala Trino, Spark gibi motorlar çalıştırır. Iceberg bu motorlara “hangi dosyaları okuyacağını” söyler.
• Bir Servis DEĞİLDİR! Yani “Hadi bir Iceberg server kuralım da 7/24 çalışsın” diye bir şey yok. Iceberg, kullandığınız araçların (Spark, Trino vs.) anlaması gereken bir kural setidir.

Peki bu nasıl çalışıyor? Iceberg’in Anatomisi!

Gelin şu Iceberg standardının içine bir dalalım. Korkmayın, o kadar karmaşık değil (yani, birazcık!).

1. Catalog (Rehberiniz): Her şey burada başlıyor. Katalog, tüm Iceberg tablolarınızın bir dizini. Tıpkı telefon rehberi gibi, tablonun adını ve onun asıl Metadata dosyasının nerede olduğunu söyler. “Tablo A’yı arıyorum?” dediğinizde, katalog size “Şu adresteki metadata.json dosyasına bak!” der.
   
2. Metadata File (JSON – Beyin): İşte bu tablonun ana kimlik kartı. İçinde ne var?
   • Tablonun şeması (hangi sütunlar var, tipleri ne?)
   • Tablonun nasıl partition edildiği (veriyi nasıl bölümlere ayırdığımız)
   • Tablonun mevcut anlık görüntüsü (snapshot) – yani şu anki hali.
   • Ve en güzeli: Tüm bunların geçmişi! Eski şemalar, eski partition’lar, eski snapshot’lar… Zaman makinesi gibi!
     
3. Manifest List (Avro – Anlık Görüntü): Metadata dosyası bizi tablonun belirli bir anlık görüntüsüne (genellikle en sonuncusuna) yönlendirir. Her anlık görüntü bir Manifest List dosyasıyla temsil edilir. Bu dosya, birden fazla Manifest dosyasının listesini tutar. Genellikle her Manifest dosyası, belirli bir partition içindeki dosyaları gruplar. Sorgu motoru buraya bakıp, “Hmm, ben sadece Ocak ayı verisini istiyorum, şu diğer manifestleri okumama gerek yok” diyerek işi hızlandırabilir (partition pruning dediğimiz olay).
   
4. Manifest File (Avro – Dosya Dedektifi): Manifest List bizi ilgili Manifest dosyalarına yönlendirir. Her Manifest dosyası ise asıl veri dosyalarının (Parquet, ORC vs.) bir listesini tutar. Sadece listeyi değil, her dosya ve hatta dosya içindeki her sütun için istatistikleri (min/max değerler gibi) de içerir! Sorgu motoru bu istatistiklere bakıp, “Aradığım değer bu dosyada olamaz” diyerek daha da fazla dosyayı okumaktan kurtulur (file pruning).
   
5. The Data Files (Parquet, etc. – Askerler): Sonunda gerçek verinin olduğu yer! Ama Iceberg’in zekası sayesinde, buraya gelene kadar okunması gereken dosya sayısı çoktan azalmış oluyor.

Okuma Sırası: Catalog -> Metadata File -> Manifest List -> Manifest Files -> Data Files (Her adımda eleme yaparak!)

Yazma Sırası: Tam tersi! Data Files -> Manifest Files -> Manifest List -> Metadata File -> Catalog’u Güncelle!

Merak etmeyin, mimariyi bölüm II’de çok daha detaylı bir şekilde ele alacağız. Yine de aklınıza aşağıdaki gibi bazı sorular gelmiş olabilir, bunları açığa kavuşturalım!

“Bir dakika, yeni veri ekleyince veya silince ne oluyor? Eski dosyalar siliniyor mu?”

HAYIR, silinmiyor! Iceberg genellikle dosyaları silmez, sadece yeni metadata dosyaları, yeni manifest listeleri ve yeni manifestler oluşturarak tablonun yeni durumunu işaret eder. Eskiler yerinde durur. Bu yüzden time travel yapabiliyoruz! Tabii ki zamanla eski dosyaları temizlemek için (vacuum veya expire_snapshots gibi) işlemler yapmanız gerekecek, yoksa depolama maliyetiniz uzaya çıkar! Silmez dediysem öyle hemen korkmayın, tabloyu Trino’da drop edersek veriler gider!

“Katalog hep en son durumu mu gösterir?”

Aynen öyle! Bir yazma işlemi bittiğinde (yeni veri ekleme, silme, güncelleme), en son adım kataloğu güncelleyip “Hey, Tablo A’nın yeni durumu artık şu yeni metadata dosyasında!” demektir. Sorgu yaptığınızda, katalog sizi hep en güncel, geçerli duruma yönlendirir (tabii siz özellikle “geçmişe git” demezseniz).

Bu Kadar Uğraşa Değer mi? Apache Iceberg’in Faydaları Neler?

“İyi güzel anlatıyorsun da, bana ne faydası var?” dediğinizi duyar gibiyim. Sıkı durun:

Verimli Güncellemeler: Hive’da bir kaydı güncellemek için koca bir partition‘ı yeniden yazmak gerekirdi (Kabus!). Iceberg’de sadece ilgili veri dosyasını değiştirirsiniz. ÇOK daha hızlı ve ucuz!

ACID Uyumluluğu (Data Lake’te Veritabanı Disiplini!): Iceberg size tam teşekküllü ACID garantisi sunar:

• Atomicity (Bölünmezlik): İşlemler ya hep ya hiç! Yarım yamalak yazma derdi yok. Bir işlemde dosyalar eklenir veya silinir, hepsi tek adımda biter.
• Consistency (Tutarlılık): Aynı anda yazmaya çalışanlar birbirinin ayağına basmaz (Optimistic Concurrency sağ olsun!). Okuyucular hep tamamlanmış, tutarlı veriyi görür.
• Isolation (İzolasyon): Okuma ve yazma işlemleri birbirini etkilemez (snapshot’lar sayesinde). Herkes kendi işine bakar.
• Durability (Dayanıklılık): Başarılı bir işlemden sonra veri kalıcıdır. (Nesne depolamanın dayanıklılığı da cabası).
• Not: ACID garantilerinin gücü, seçtiğiniz Catalog‘a da bağlıdır. Güçlü garantiler sunan bir katalog (Nessie gibi) işleri daha da sağlamlaştırır.
  

Otomatik İstatistikler: Veri yazılırken istatistikler (min/max, null sayısı vs.) otomatik olarak toplanır ve metadata’ya eklenir. Sorgu motorları bu istatistikleri kullanarak performansı optimize eder. Ekstra ANALYZE TABLE komutları çalıştırmaya gerek kalmaz (genellikle).

Schema Evolution (Şema Evrimi): Data lake’te şema değiştirmek kabustu. Iceberg ile sütun ekleyin, çıkarın, adını değiştirin, hatta tipini güncelleyin (int -> long gibi) tabloyu yeniden yazmadan! Metaveri her şeyi takip eder. Motor eski/yeni şemayı anlar. Müthiş esneklik!

Partition Evolution (Partition Evrimi – İŞTE BU EFSANE!): Belki de Iceberg’in en havalı özelliği! Tablonuzu başta aya göre partition ettiniz diyelim. Sonra baktınız veri acayip arttı, güne göre partition etmek daha mantıklı. Diğer formatlarda tüm tabloyu yeniden yazmanız gerekirken, Iceberg’de sadece Metadatayi güncellersiniz! Yeni gelen veriler yeni şemaya göre, eskiler eski şemaya göre partition edilir. Motor bunu anlar! İsterseniz eski verileri de zamanla yeni şemaya göre yeniden yazabilirsiniz, ama zorunlu değil! ES-NEK-LİK!

Bakın ne kadar kolay:

-- Önce ay'a göre partition ile tabloyu yaratalım
CREATE TABLE catalog.db.tableA (
  id bigint,
  data string,
  category string,
  ts timestamp  -- Partition için zaman damgası sütunumuz
)
USING iceberg  -- Motor! Iceberg kullanıyoruz!
PARTITIONED BY (month(ts)); -- 'ts' sütununu kullanarak AYLIK partition yap!

-- Sonra dedik ki "Günlük daha iyi olacak!" Hemen ALTER TABLE çekiyoruz:
ALTER TABLE catalog.db.tableA
ADD PARTITION FIELD days(ts); -- Mevcut 'ts' sütununa GÜNLÜK partition ekle! Bitti!

(Alkışlar) Bu kadar basit! Veriye dokunmadık bile!

Hidden Partitioning (Kullanıcıyı Yormayan Zeka!): Hive zamanında timestamp’e göre partition için genelde ayrı yil, ay, gun sütunları yaratır, sorguda da bunlara filtre eklerdik. Kullanıcı unutursa yandı gülüm keten helva! Iceberg diyor ki: “Sen timestamp sütununu ver, ben ondan ay, gün, saat çıkarıp gizlice partition yaparım (month(ts), days(ts) gibi dönüşümlerle). Sen sorgunda sadece timestamp’e filtre atsan yeter, ben arkada partition’ları kullanırım! (partition pruning)” Kullanıcı mutlu, sorgular hızlı!

Eski günler (Hive):

-- Zavallı 'month' sütunu... Elle doldur, sorguda unutma...
CREATE TABLE tableB (
  event_id bigint,
  event_name string,
  ts timestamp,
  month int -- Ekstra partition sütunu :(
)
PARTITIONED BY (month);

-- Sorguda hem 'ts' hem 'month' filtresi... Ne gerek var?
SELECT * FROM CATALOG.db.tableA
WHERE ts >= '2023-01-01' AND ts <= '2023-04-01'
AND month >=1 AND month <=4; -- Unutsan tam tarama!

Iceberg ile Hayat:

-- Sadece 'ts' var, partition'ı ondan türetiyoruz!
CREATE TABLE catalog.db.tableA (
  event_id bigint,
  event_name string,
  ts timestamp
)
USING iceberg
PARTITIONED BY (month(ts)); -- 'ts'den AY türetip partition yap! Oh be!

-- Sorgu ne kadar temiz! Sadece 'ts' yeterli!
SELECT * FROM CATALOG.db.tableA
WHERE ts >= '2023-01-01' AND ts <= '2023-04-01'; -- Iceberg gerisini halleder!

İşte bu! Sezgisel ve hataya daha az açık!

Time Travel (Geçmişe Dönüş!): Her yazma işlemi değişmez (immutable) bir snapshot oluşturduğu için, “Dün gece saat 03:00’teki verilere bakmam lazım” diyebilirsiniz. Raporlama için veri kopyalamaya, ML modellerini eski veriyle yeniden çalıştırmaya son! Zaman makinesi emrinizde! 🕰️

Satır Seviyesi İşlemler (COW vs MOR): Sık sık satır güncelliyor veya siliyorsanız, Iceberg size iki strateji sunar:

• Copy-on-Write (COW): Bir satır değişince, o satırın bulunduğu tüm veri dosyasını kopyalayıp yenisini yazar. Okuması hızlıdır ama yazması (özellikle büyük dosyalarda tek satır değişince) biraz maliyetli olabilir.
• Merge-on-Read (MOR): Sadece değişen/silinen satırlar için küçük “delta” dosyaları yazar. Yazması çok hızlıdır. Okuma sırasında bu delta dosyalarını ana veriyle birleştirir (okuma biraz yavaşlayabilir). Yoğun yazma işlemleri için harikadır. Seçim sizin iş yükünüze bağlı!

Gelişmiş Performans (Hız ve Tasarruf!): Iceberg’in akıllı metadata’sı sayesinde sorgu motorları gereksiz dosyaları taramaktan kurtulur (partition ve dosya istatistikleri ile eleme yapar). Daha az dosya tarama = Daha hızlı sorgular + Daha az işlem gücü = CEBİNİZDE KALAN PARA! 💰 Paralel işlemlerde instance’lar daha çabuk kapanır, maliyet düşer.

Esnek Dosya Yerleşimi (Compatibility Mode): Iceberg dosyaların illa belirli bir klasör yapısında olmasını zorunlu kılmaz (Hive gibi). Dosyaları farklı klasörlere (ön eklere) dağıtabilir. Bu, özellikle S3 gibi nesne depolamalarda aynı ön eke (klasöre) çok fazla istek gittiğinde yaşanan performans düşüşlerini (throttling) engellemeye yardımcı olur.

Geniş Ekosistem: Iceberg’i destekleyen araç (Spark, Trino, Flink, Dremio, Starburst, Snowflake, BigQuery vs.) sayısı giderek artıyor. Bu da farklı araçlarla aynı veriye sorunsuzca erişebilmek demek.

Data as Code (Nessie ile): Nessie gibi kataloglarla birleşince, data üzerinde Git benzeri işlemler (branch, merge, commit, rollback) yapabiliyorsunuz. Tüm data pipeline’ınızı versiyonlamak mümkün hale geliyor!

Açık ve Şeffaf Proje: Iceberg’in gelişimi tamamen açık kaynak topluluğu tarafından yönlendiriliyor. E-posta listeleri, Slack kanalı, halka açık toplantılar… Her şey şeffaf. Sürpriz özellikler pek olmaz, neyin ne zaman geleceğini takip edebilirsiniz.

Son Sözler: Iceberg’e Geç Kalmayın!

Evet arkadaşlar, Apache Iceberg data lake dünyasında oyunun kurallarını değiştiren bir teknoloji. Başlangıçta biraz karmaşık gibi görünse de, sunduğu faydalar (performans, esneklik, tutarlılık, time travel, schema/partition evolution) o kadar büyük ki, data lake ile ciddi işler yapan herkesin mutlaka değerlendirmesi gerekiyor.

O dağınık dosya yığınlarına bir düzen getirmek, sorgularınızı hızlandırmak, maliyetleri düşürmek ve data operasyonlarınızı daha güvenilir hale getirmek istiyorsanız, Iceberg’e bir şans verin. Pişman olmayacaksınız!