Merhabalar! Bugün sizlerle birlikte modern veri dünyasının en heyecan verici teknolojilerinden biri olan Apache Iceberg’i keşfedeceğiz. Veri gölleriniz kaosa dönüştü mü? Şema güncellemeleri başınızı ağrıtıyor mu? O halde doğru yerdesiniz! Gelin birlikte bu açık tablo formatının (open table format) ne olduğunu, nasıl çalıştığını ve neden bu kadar önemli olduğunu öğrenelim.

Önce Biraz Tarih: Veri Ambarlarından Veri Göllerine Yolculuk

Veri yönetimi dünyasını anlamak için yaklaşık 35-40 yıl geriye gidelim. O zamanlar veri ambarları (data warehouses) kraldı [1][12]. Bunlar, operasyonel veritabanlarındaki verileri bir araya getiren büyük sistemlerdi. Her gece ETL (Extract, Transform, Load – Çıkar, Dönüştür, Yükle) adı verilen bir süreçle veriler toplanır, işlenir ve veri ambarına yüklenirdi [1][17]. Yüklenirdi dememe bakmayın halen bir çok yer öyle. hatta bunu bile doğru düzgün beceremeyenler var. Ertesi gün bu veriler raporlar ve analizler için hazır halde olurdu.

Bu toplu iş (batch) yaklaşımı o zamanlar harika bir teknolojiydi ama zamanla yetersiz kalmaya başladı. İşte tam bu noktada, yaklaşık 15 yıl önce veri gölleri (data lakes) sahneye çıktı [1][12]. İlk başta Hadoop olarak bilinen bu sistem, büyük bir dağıtık dosya sistemi (distributed file system) üzerine kuruluydu [1].

Veri Gölleri Ne Getirdi?

Veri gölleri, veri ambarlarından farklı bir felsefe getirdi. Artık “önce dönüştür, sonra yükle” yerine “önce yükle, sonra dönüştür” mantığına geçildi – yani ETL yerine ELT (Extract, Load, Transform) [12][17]. Bütün veriler, yapılandırılmış olsun olmasın, önce veri gölüne atılıyor, sonra gerektiğinde işleniyordu [13][16].

Şema (schema) konusunda daha esnek bir yaklaşım getirildi. Hatta bir dönem şema neredeyse “kötü” bir şey olarak görülmeye başlandı [1]. Ancak gerçek hayatta şema önemlidir, çünkü verilerimizi anlamak ve SQL sorguları yazmak için hala tablolu yapılara ihtiyacımız var [1][3].

Günümüzde veri gölleri genellikle Amazon S3, Azure Blob Storage veya Google Cloud Storage gibi bulut blob depolama sistemlerinde konumlanıyor [2][5].

Iceberg Devrede

Veri göllerinde zamanla bazı problemler ortaya çıktı. Netflix’te bu sorunları yaşayan mühendisler, 2017 yılında Apache Iceberg projesini başlattılar [2][7]. Peki ne gibi sorunlar vardı?

Iceberg’in Çözdüğü Ana Problemler

1. Tutarlılık Sorunları (Consistency): Dağıtık bir dosya sisteminde farklı dosyalarda dağılmış tablo parçalarına sahip olduğunuzda, verilerde tutarlı bir görünüm elde etmek zordu [1][2].
2. Şema Yönetimi: Veri formatını bilmek, şema değişikliklerini yönetmek hala gerekliydi [1][3].
3. İşlemsellik (Transactionality): ACID garantilerine (Atomicity, Consistency, Isolation, Durability – Bölünmezlik, Tutarlılık, Yalıtım, Dayanıklılık) ihtiyaç vardı [5][6].
4. Performans: Bulut sistemlerinde dosya listeleme işlemleri maliyetliydi ve performansı etkiliyordu [2].

Iceberg, tabloların tüm dosyalarını ağaç yapısında (tree structure) takip ederek, yani verilerin takibini dosya seviyesinde (file level) yaparak bu sorunları çözdü [2]. Hive’ın klasör seviyesinde (folder level) takip yaptığı düşünülürse, bu büyük bir iyileştirmeydi.

Apache Iceberg’in Mimarisi: Nasıl Çalışıyor?

Şimdi gelin Iceberg’in mantıksal mimarisini (logical architecture) adım adım inceleyelim. Aşağıdan yukarıya doğru inşa edelim [1][6]:

1. Veri Katmanı (Data Layer)

En altta veri dosyalarımız var. Bunlar genellikle Parquet formatındadır [1][7]. Parquet, sütun bazlı (columnar) bir dosya formatı olduğu için analitik sorgular için mükemmeldir [5][10]. Iceberg ayrıca Avro ve ORC formatlarını da destekler [2][5].

📄 Parquet Dosya 1
📄 Parquet Dosya 2
📄 Parquet Dosya 3

2. Metadata Katmanı (Metadata Layer)

Veri katmanının üstünde metadata katmanı bulunur. Bu katman birkaç seviyeden oluşur [1][4][6]:

Manifest Dosyaları (Manifest Files)

Her veri yükleme işlemi için bir manifest dosyası oluşturulur [1][6]. Bu dosyalar sadece Parquet dosyalarının listesini tutmaz, aynı zamanda:

• Sütun veri tipleri
• Min/max değerler
• Satır sayıları
• Partition değerleri gibi istatistikler de içerir [1][2]

Bu metadata bilgileri, sorguları optimize etmek için kullanılır ve tüm dosyaları taramak zorunda kalmadan hangi dosyaların sorguya dahil edilmesi gerektiğini hızlıca belirler.

Manifest Listeleri (Manifest Lists)

Birden fazla veri yükleme işleminiz olduğunda, her biri için farklı manifest dosyaları oluşur. Bunları bir araya getirmek için manifest listeleri kullanılır [1][6]. Avro formatında saklanan bu dosyalar, bir snapshot için tüm manifest dosyalarını listeler [6].

Metadata Dosyası (Metadata File)

En üstte metadata dosyası bulunur (genellikle metadata.json) [6][7]. Bu dosya:

• Tablonun şemasını (schema)
• Partition spesifikasyonlarını (partition specs)
• Snapshot listesini
• Mevcut snapshot’a işaretçiyi (pointer) içerir [1][6][7]

3. Snapshot Konsepti

Snapshot’lar Iceberg’in en önemli özelliklerinden biridir [2][9]. Her yazma ve commit işlemi için bir snapshot tutulur. Snapshot’ları, tablonun belirli bir zamandaki durumunun anlık görüntüsü olarak düşünebilirsiniz [2][11].

Bu sayede:

• Zaman yolculuğu (time travel) yapabilirsiniz – geçmişteki herhangi bir versiyona geri dönebilirsiniz [5][10][11]
• ACID işlemleri garantileyebilirsiniz [5][6]
• Şema değişiklikleri bile tablonun tutarsız duruma düşmesine sebep olmaz [1][3]

-- Belirli bir snapshot'a göre sorgu
SELECT count(*) FROM nyc.taxis 
FOR VERSION AS OF 2188465307835585443

4. Katalog (Catalog)

En üstte katalog bulunur [1]. Bu, tablo isimlerini metadata dosyalarına bağlayan bir arama servisidir. Katalog farklı sistemler olabilir ve ekosistem hızla gelişiyor [33][38]:

Klasik Kataloglar:

• Hive Metastore
• JDBC veritabanı (MySQL, PostgreSQL)
• Hadoop Catalog
• AWS Glue [1][4][11]

Modern/Yeni Nesil Kataloglar:

• Apache Polaris (incubating) – Snowflake tarafından açık kaynak olarak yayınlandı [32][33][37]
• Project Nessie – Git-style version control özellikli, Dremio tarafından geliştirilen açık kaynak katalog [33][34][35]
• Unity Catalog – Databricks tarafından geliştirilen, Delta Lake ve Iceberg desteği sunan katalog [32][33][36]
• Apache Gravitino – Federated metadata yönetimi sunan katalog [33]
• Lakekeeper – Hafif, Rust tabanlı katalog çözümü [33]

Bu modern kataloglar, klasik katalogların ötesinde özellikler sunar: Git-style branching, multi-table işlemler, gelişmiş governance ve credential vending [33][35][41].

Iceberg’in Fiziksel Altyapısı

Burası çok önemli: Iceberg bir sunucu değildir! [1] Iceberg aslında bir spesifikasyondur [1][11]. Yani:

• İndirebileceğiniz bir yazılım değil
• Çalıştıracağınız bir süreç yok
• Tamamen açık kaynaklı bir standarttır [5][11]

Bunun yerine, Iceberg kütüphanelerini Java, Python, Spark, Flink gibi araçlarla kullanırsınız [1][11]. Verileriniz S3 benzeri blob depolama sistemlerinde Parquet dosyaları ve JSON metadata dosyaları olarak saklanır [1].

Iceberg’in Süper Güçleri

1. Şema Evrimi (Schema Evolution)

Şema değişiklikleri artık kabusunuz olmayacak! Iceberg ile [2][3][5]:

• Sütun ekleyebilirsiniz
• Sütun isimlerini değiştirebilirsiniz
• Sütun sıralamasını değiştirebilirsiniz
• Sütun tiplerini genişletebilirsiniz

Ve tüm bunları tabloyu yeniden yazmadan yaparsınız! [1][10] Çünkü Iceberg stable column ID’ler kullanır, sadece isimler değil [9].

-- Kolay şema değişikliği
ALTER TABLE taxis ALTER COLUMN trip_distance TYPE double;

2. Gizli Partitioning (Hidden Partitioning)

Geleneksel sistemlerde partition sütunlarını sorgularınıza manuel olarak eklemeniz gerekir. Iceberg’de ise partition mantığı otomatik olarak ele alınır [2][3][9]:

• Kullanıcıların partition yapısını bilmesine gerek yok
• Sorgu yazarken partition sütunlarını belirtmek zorunda değilsiniz
• Partition stratejisini zamanla değiştirebilirsiniz (örneğin aylıktan günlüğe) [2]
• Eski veriler eski partition’larda kalır, yeni veriler yeni partition’a gider

3. ACID Garantileri

Iceberg, atomik commit semantiği kullanarak tam ACID işlemleri sağlar [5][6][9]:

• Atomicity (Bölünmezlik): İşlemler ya tamamen gerçekleşir ya da hiç gerçekleşmez
• Consistency (Tutarlılık): Veriler her zaman tutarlı durumda kalır
• Isolation (Yalıtım): Eşzamanlı işlemler birbirini etkilemez
• Durability (Dayanıklılık): İşlemler kalıcıdır

4. Zaman Yolculuğu ve Versiyon Kontrolü

Snapshot’lar sayesinde [10][11]:

• Geçmişteki herhangi bir versiyonu sorgulayabilirsiniz
• Yanlış yapılan değişiklikleri geri alabilirsiniz (rollback)
• Tekrarlanabilir sorgular yapabilirsiniz (reproducible queries)

-- Belirli bir zamandaki veriyi sorgulama
SELECT count(*) FROM nyc.taxis 
FOR TIMESTAMP AS OF TIMESTAMP '2022-01-01 00:00:00.000000 Z'

5. Performans Optimizasyonları

Iceberg, manifest dosyaları ve metadata ağacı sayesinde maliyetli dosya listeleme işlemlerinden kaçınır [2][9]:

• Sorgu planlayıcı sadece gerekli manifest dosyalarını okur
• Gereksiz partition’lar ve dosyalar otomatik olarak atlanır
• Sütun pruning ve predicate pushdown gibi optimizasyonlar desteklenir [7]

Modern/Yeni Nesil Kataloglar: Git for Data

Iceberg ekosisteminde kataloğun rolü son yıllarda çok daha kritik hale geldi [33][35]. İşte yeni nesil katalogların getirdiği heyecan verici özellikler:

Project Nessie: Git for Data

Nessie, veri için Git benzeri bir version control sistemi getiriyor [33][34][35][40]:

Ana Özellikleri:

• Branch’ler: Dev, staging, production branch’leri oluşturabilirsiniz
• Commit History: Tüm değişiklikler izlenebilir, audit edilebilir
• Merge ve Rollback: Değişiklikleri merge edebilir veya geri alabilirsiniz
• Multi-table Transactions: Birden fazla tabloda atomic işlemler [40]
• Time Travel: Katalog seviyesinde zaman yolculuğu [35]

Nessie, Iceberg REST Catalog spesifikasyonunu destekler, bu da herhangi bir Iceberg uyumlu engine ile çalışabileceği anlamına gelir [34][40].

Kullanım Örneği:

# Nessie ile branch oluşturma ve değişiklik yapma
spark.sql("CREATE BRANCH dev IN nessie")
spark.sql("USE BRANCH dev IN nessie")
# Dev branch'inde değişiklikler yap
spark.sql("MERGE BRANCH dev INTO main IN nessie")

Unity Catalog: Çok Formatlu Governance

Unity Catalog, Databricks tarafından geliştirilen ve 2024’te açık kaynak olarak yayınlanan bir katalog sistemi [32][33][36]:

Güçlü Yanları:

• Multi-format Desteği: Delta Lake, Iceberg ve Hudi formatlarını destekler [33][36][41]
• Unified Governance: Veriler, ML modelleri, notebooks hepsi tek yerden yönetilir [38]
• Fine-grained Access Control: Satır ve sütun seviyesinde erişim kontrolü [36]
• Credential Vending: Temporary cloud storage credentials üretir [41]
• Multi-cloud: Azure, AWS, GCP desteği [41]

Unity Catalog, sadece bir metadata katalog değil, aynı zamanda:

• Machine learning model registry
• ML experiment tracking
• AI “functions” yönetimi sunar [33]

Apache Polaris: Snowflake’in Açık Kaynak Katalogu

Polaris, Snowflake tarafından Haziran 2024’te açık kaynak olarak yayınlandı [32][37][41]:

Öne Çıkan Özellikleri:

• Tamamen Açık Kaynak: Apache 2.0 lisansı altında [37]
• Iceberg-focused: Iceberg’e özel optimize edilmiş [36]
• Community-driven: 20+ vendor aktif olarak katkıda bulunuyor [37]
• Credential Vending: Secure table sharing [41]
• REST Catalog Spec: Full uyumluluk [33]

Polaris, Snowflake’in managed versiyonu olarak da sunuluyor ve Dremio gibi şirketler Polaris’i primary catalog olarak benimsemeyi planlıyor [37].

Katalog Savaşları ve Seçim Kriterleri

2024-2025 dönemi “katalog savaşları” yılı olarak adlandırılabilir [33][37]. Databricks Unity Catalog vs Snowflake Polaris vs Dremio Nessie rekabeti kızışıyor.

Hangi Katalogu Seçmeli?

Nessie kullanın eğer:

• Git-style workflows istiyorsanız [35]
• Multi-table atomic işlemler kritikse [40]
• Self-managed, açık kaynak tercih ediyorsanız [35]
• DataOps pratiklerine değer veriyorsanız [37]

Unity Catalog kullanın eğer:

• Databricks ekosistemindeyseniz [36]
• Multi-format desteği gerekiyorsa (Iceberg + Delta + Hudi) [33][36]
• ML ve AI governance önemliyse [33]
• Unified data + AI platformu istiyorsanız [38]

Polaris kullanın eğer:

• Tam Iceberg-focused bir çözüm istiyorsanız [36]
• Community-backed proje tercih ediyorsanız [37]
• Snowflake ekosistemiyle entegrasyon planlıyorsanız [32]
• Lightweight, modern bir katalog arıyorsanız [33]

Önemli Not: Modern katalogların hepsi Iceberg REST Catalog Specification‘ı destekler, bu da aralarında geçiş yapmanın görece kolay olduğu anlamına gelir [33][34][38].

Burası gerçekten heyecan verici! Streaming (akış) dünyasıyla Iceberg’in buluşması tam bir oyun değiştirici [22][23].

Geleneksel Yaklaşımın Problemi

Geleneksel olarak, veri gölleri şöyle beslenirdi:

1. Kafka gibi bir streaming platformdan veri gelir
2. Minimal stream processing yapılır
3. Veriler veri gölüne yazılır
4. Sonra Iceberg işlemleri yapılır

Bu yaklaşımda gereksiz kopyalama ve ETL süreçleri vardı [22][23].

Confluent Tableflow: Kafka Meets Iceberg

İşte tam burada Confluent Tableflow devreye giriyor! [22][23][24] Tableflow, Kafka topic’lerini doğrudan Iceberg tabloları olarak erişilebilir hale getirir:

• Topic’teki değişiklikler otomatik olarak Iceberg metadata’sına yansır [23][24]
• Schema Registry üzerinden şema değişiklikleri yönetilir [23][24]
• Eski “oradan buraya kopyalama” işine gerek kalmaz [22][24]
• Tek bir tıkla Kafka topic’leri Iceberg tablolarına dönüşür [22][24]

Bu yaklaşımla:

• Gerçek zamanlı veri analitiği yapabilirsiniz [27][28]
• Snowflake, Databricks, Amazon Athena gibi araçlarla doğrudan sorgulayabilirsiniz [22][25]
• ETL pipeline’ları ortadan kalkar [27][28]
• Maliyet ve karmaşıklık azalır [22][24]

Stream-Table Duality (Akış-Tablo İkiliği)

Iceberg harika bir konsepti hayata geçirir: stream-table duality [31]. Aynı veri seti:

• Bir tarafta sürekli akan bir stream olarak
• Diğer tarafta belirli bir zamandaki bounded table olarak görülebilir

Bu, operasyonel sistemlerle (microservices, OLTP) ve analitik sistemleri (OLAP, BI) birleştirir [31].

Iceberg vs. Diğer Çözümler: Data Lakehouse Üçlüsü

Modern veri dünyasında üç büyük açık tablo formatı (open table formats) rekabet ediyor: Apache Iceberg, Delta Lake ve Apache Hudi [42][43][44]. Bu “data lakehouse trifecta” (üçlüsü) farklı şirketler tarafından farklı ihtiyaçlar için geliştirildi [44][46]:

• Apache Iceberg: Netflix tarafından, S3 üzerinde büyük Hive tablolarının performans sorunlarını çözmek için [43][44][45]
• Delta Lake: Databricks tarafından, Spark workload’larına ACID garantileri getirmek için [43][44][47]
• Apache Hudi: Uber tarafından, near-real-time incremental processing için [43][44][48]

Detaylı Karşılaştırma

1. Mimari Yaklaşım

Apache Iceberg:

• 3-katmanlı metadata yapısı: metadata.json → manifest list → manifest files → data files [1][45]
• Snapshot-based versioning [2][45]
• File-level tracking ile optimal performans [2][43]
• Hidden partitioning – kullanıcılar partition detaylarını bilmek zorunda değil [2][3]

Delta Lake:

• Transaction log (Delta Log) tabanlı [43][45][47]
• JSON formatında log dosyaları [45]
• Optimistic concurrency control [43]
• Databricks ile sıkı entegrasyon [43][49]

Apache Hudi:

• Timeline-based architecture – tüm değişiklikler bir timeline üzerinde [44][45]
• Copy-on-Write (COW) ve Merge-on-Read (MOR) storage types [42][48]
• Built-in indexing mekanizması [49]
• Incremental processing odaklı tasarım [42][46]

2. Engine ve Tool Desteği

Iceberg – En Geniş Multi-Engine Desteği:

• Spark, Flink, Trino, Presto, Hive, Dremio, Athena, Impala, StarRocks [7][43][44]
• Vendor-agnostic approach [5][11]
• REST Catalog API standardı ile herhangi bir engine kullanabilirsiniz [34]

Delta Lake – Spark Ecosystem Lideri:

• Spark ile derin entegrasyon [43][49]
• Databricks managed service’de gelişmiş özellikler [43]
• Presto, Athena, Redshift Spectrum (symlink.txt ile) [43]
• Flink desteği OSS versiyonda sınırlı [44]

Hudi – Streaming ve CDC Şampiyonu:

• Spark ve Flink için güçlü destek [42][43]
• Kafka entegrasyonu [43]
• Hive, Impala, Presto read desteği [43]

3. Şema Evrimi (Schema Evolution)

Iceberg ⭐ En Esnek:

• Stable column IDs kullanır [9]
• İsim, tip, sıralama değişiklikleri kolay [1][10]
• Tablo yeniden yazılmadan şema değişikliği [1][49]
• Geriye dönük uyumluluk garantisi [3][5]

Delta Lake:

• Schema enforcement odaklı – veri kalitesi için strict [47][49]
• Schema evolution desteklenir ama daha az esnek [49]

Hudi:

• Schema evolution desteklenir [47]
• Avro schema registry ile entegrasyon [42]

4. Partition Yönetimi

Iceberg ⭐ Hidden Partitioning:

• Partition logic otomatik handle edilir [2][3][9]
• Partition spec değiştirebilirsiniz (month → day) [2]
• Eski data eski partition’da kalır, sorgu otomatik optimize edilir [2]

Delta Lake:

• Manual partition specification gerekir [43]
• Partition değişiklikleri için tablo yeniden yazılması gerekebilir

Hudi:

• Flexible partitioning stratejileri [42]
• Dynamic partitioning desteği [48]

5. ACID ve Concurrency

Hepsi ACID garantisi sunar, ama implementasyon farklı:

Iceberg:

• Snapshot isolation ile tam ACID [5][6][9]
• Optimistic concurrency [43]
• S3’te multi-writer desteği ✅ [43]

Delta Lake:

• Optimistic concurrency control [43]
• S3’te OSS versiyonunda multi-cluster writes problematik ❌ [43]
• Databricks managed version’da external sync server ile çözülmüş ✅ [43]

Hudi:

• File-level locking mekanizması [43]
• Concurrency için daha fazla manual konfigürasyon gerekir [43]

6. Incremental Processing ve CDC

Hudi ⭐ Incremental Pipeline Öncüsü:

• Ground-up incremental design [42][46]
• Change streams out-of-the-box [42]
• Record-level indexes ile efficient CDC [42]
• Appends, updates, deletes hepsi change stream’de [42]

Iceberg:

• Incremental read desteği var ama sadece appends için [42]
• Updates ve deletes için incremental okuma sınırlı [42]

Delta Lake:

• Change Data Feed (CDC) – önce proprietary, sonra Delta Lake 2.0’da açık kaynak [42]
• Streaming desteği güçlü [47]

7. Time Travel

Hepsi time travel destekler:

Iceberg:

• Snapshot ID veya timestamp ile [10]
• Sınırsız snapshot geçmişi [2]

Delta Lake:

• Version number veya timestamp ile [47]
• Transaction log tabanlı [45]

Hudi:

• Timeline-based time travel [45]
• Point-in-time queries [48]

8. Performance

Benchmark’lar tartışmalı [42][50], ancak:

• Iceberg: Metadata-driven query planning ile büyük tablolarda mükemmel [2][9]
• Hudi: Incremental workload’larda çok hızlı [42]
• Delta Lake: Spark ecosystem’inde optimize edilmiş [43]

Her format kendi use case’inde parlar. Gerçek performans workload’unuza bağlı [42].

9. Community ve Governance

Iceberg:

• Apache Software Foundation projesi [7][44]
• Vendor-neutral governance [5]
• Netflix, Apple, LinkedIn, Adobe aktif contributor [7]

Delta Lake:

• Linux Foundation projesi (Databricks lead) [44]
• Open-source ama Databricks ağırlıklı [46]

Hudi:

• Apache Software Foundation projesi [44]
• Uber ve diğer contributor’lar [44]

Hangisini Seçmeli?

Iceberg kullanın eğer:

• Multi-engine flexibility istiyorsanız [7][11]
• Vendor lock-in’den kaçınmak istiyorsanız [5]
• Schema evolution kritikse [3][9]
• Hidden partitioning önemliyse [2]
• Büyük ölçekli analytics (petabyte+) yapıyorsanız [2][5]

Delta Lake kullanın eğer:

• Databricks ekosistemindeyseniz [43][49]
• Spark-centric workload’larınız varsa [43]
• Strong schema enforcement istiyorsanız [47][49]
• Streaming + batch birlikte kullanıyorsanız [47]

Hudi kullanın eğer:

• Near-real-time updates kritikse [42][46]
• CDC ve incremental processing öncelikse [42]
• Streaming ingestion ağırlıklıysa [48]
• Record-level indexing gerekiyorsa [49]

Apache XTable: Format Interoperability

Seçim yapamıyor musunuz? Apache XTable (Incubating) – eski adıyla OneTable – formatlar arası seamless interoperability sağlar [42]. Microsoft, Google ve Onehouse tarafından co-launched, şimdi Apache projesi [42].

XTable ile aynı veriye Hudi, Delta ve Iceberg olarak erişebilirsiniz – format lock-in yok! [42]

Hive Metastore’dan Farkları

Üç format da Hive’dan çok daha gelişmiş:

• Hive: Klasör bazında tanımlama, snapshot yok, ACID garantisi zayıf [2][6][44]
• Modern Formatlar: Dosya bazında tracking, snapshot geçmişi, tam ACID [2][6][43]

Veri Ambarlarından Farkları

• Veri Ambarları: Kapalı, tescilli sistemler, vendor lock-in [11]
• Açık Tablo Formatları: 100% açık kaynak, vendor-agnostic, multi-engine [5][11][43]

Gerçek Dünya Kullanım Senaryoları

1. Veri Mahremiyeti ve GDPR

Sık sık silme gerektiren tablolar için idealdir (örneğin GDPR compliance) [5]. Record-level silme yapmak artık kolay!

2. Sürekli Güncellenen Veriler

Müşteri iade işlemleri gibi sonradan değişebilecek satış verileri için mükemmel [5]. Tüm veri setini yeniden publish etmek yerine sadece ilgili kayıtları güncellersiniz.

3. Machine Learning Feature Store’lar

Zaman yolculuğu sayesinde tekrarlanabilir training setleri oluşturabilirsiniz [9]. Model eğitimi için hangi versiyonu kullandınız? Iceberg biliyor!

4. Gerçek Zamanlı Analitik

Streaming ve batch işlemleri tek bir tabloda birleştirebilirsiniz [9][20]. CDC (Change Data Capture) pipeline’ları için harika!

5. Veri Lakehouse Mimarisi

Iceberg, data lakehouse konseptinin temel taşlarından biridir [9][15][20]. Veri gölünün esnekliği + veri ambarının güvenilirliği = Lakehouse!

Kimler Kullanıyor?

Iceberg, dünya devleri tarafından production’da kullanılıyor [7][11]:

• Netflix (Iceberg’i yaratan şirket)
• Apple
• Airbnb
• LinkedIn
• Adobe
• Lyft
• Expedia
• Ve daha nice Fortune 500 şirketleri…

Desteklenen Araçlar ve Platformlar

Iceberg geniş bir ekosistem desteğine sahip [5][7][11]:

Query Engine’ler:

• Apache Spark
• Apache Flink
• Trino (eski adıyla Presto)
• Dremio
• Impala
• StarRocks

Cloud Platform’lar:

• AWS (Athena, EMR, Glue)
• Google Cloud (BigQuery)
• Azure (Synapse)
• Snowflake
• Databricks

Programlama Dilleri:

• Java API
• Python (PyIceberg)
• Spark SQL
• Flink SQL

Başlangıç İçin Pratik Öneriler

Iceberg’e geçmeyi düşünüyorsanız [18]:

1. İş gereksinimlerinizi tanımlayın: Hedeflerinizi, veri ihtiyaçlarınızı netleştirin
2. Ölçeklenebilir mimari kurun: Artan veri hacimlerine hazır olun
3. Veri yönetişimi uygulayın (Data Governance): Veri kalitesi, sürüm kontrolü, lineage takibi yapın
4. İzleme ve bakım: Sürekli performans takibi yapın
5. Küçük başlayın: Kritik olmayan bir use case ile pilot yapın

Dikkat Edilmesi Gerekenler

Her teknolojinin olduğu gibi Iceberg’in de bazı zorlukları var [8]:

• Öğrenme eğrisi: Ekibinizin şema evrimi ve tablo yönetimi konularında eğitime ihtiyacı olabilir
• Performans overhead’i: ACID garantileri ve metadata yönetimi bazı durumlarda performans maliyeti getirebilir
• Tooling desteği: Kullandığınız araçların Iceberg’i yeterince desteklediğinden emin olun
• Migrasyon planlaması: Mevcut sistemlerden geçiş trivial değildir, dikkatli planlama gerekir [9]

Sonuç: Geleceğe Giden Yol

Apache Iceberg, modern veri mimarisinin vazgeçilmez bir parçası haline geliyor [9][11]. Özellikle:

• AI ve ML workload’ları için fresh, trustworthy data gerekiyorsa [22][27]
• Gerçek zamanlı analitik yapmanız gerekiyorsa [23][24]
• Büyük ölçekli veri yönetiyorsanız (petabyte seviyesi) [2][5]
• Multi-engine ortamda çalışıyorsanız (Spark + Flink + Trino) [7][11]

Iceberg tam size göre!

Veri gölleri artık “veri bataklığına” (data swamp) dönüşmek zorunda değil. Iceberg ile veri gölünüze güvenilirlik, performans ve yönetilebilirlik getirebilirsiniz. ACID garantileri, zaman yolculuğu, şema evrimi ve hidden partitioning gibi özellikler, Iceberg’i modern veri platformlarının olmazsa olmazı haline getiriyor.

Confluent Tableflow gibi yeniliklerle, streaming ve analitik dünyaları arasındaki duvarlar yıkılıyor. Artık Kafka topic’lerinizi doğrudan Iceberg tabloları olarak kullanabilir, gerçek zamanlı verilerinizi hiç beklemeden analiz edebilirsiniz.

Hatırlatma: Bu yazıda bahsedilen Tim Berglund’un videosu, Iceberg’in temellerini anlamak için mükemmel bir kaynak. Video’da Iceberg’in mantıksal mimarisini lightboard üzerinde görsel olarak açıklıyor ve Tableflow’un neden “son 40 yılda analitik alanında gördüğü en heyecan verici şey” olduğunu paylaşıyor.

Umarım bu yazı sizin için faydalı olmuştur. Iceberg ile mutlu veri yolculukları! 🚀

Kaynaklar

[1] Confluent – Tim Berglund (2024). Apache Iceberg Explained. YouTube Video Transcript. https://youtu.be/TsmhRZElPvM

[2] Bentego (2025). Apache Iceberg. https://bentego.com/apache-iceberg/

[3] Leonidasgorgo (2024). Apache Iceberg Nedir? Medium. https://leonidasgorgo.medium.com/apache-iceberg-nedir-3acae7ca9c7a

[4] Emre Evcimen (2024). Apache İceberg Nedir? Medium. https://emreevcimen.medium.com/apache-i%CC%87ceberg-ee1bcb06935b

[5] AWS (2025). Apache Iceberg Nedir? https://aws.amazon.com/what-is/apache-iceberg/

[6] Dinesh Shankar (2025). Apache Iceberg Explained: A Modern Open Table Format. Medium. https://dishanka.medium.com/apache-iceberg-explained-a-modern-open-table-format-f178334c36ec

[7] Wikipedia (2025). Apache Iceberg. https://en.wikipedia.org/wiki/Apache_Iceberg

[8] Solix (2024). Apache Iceberg. https://www.solix.com/kb/apache-iceberg/

[9] Sider AI. Is Apache Iceberg the Future of Data Lakes? https://sider.ai/blog/ai-tools/is-apache-iceberg-the-future-of-data-lakes-an-in-depth-iceberg-review

[10] Apache Software Foundation. Apache Iceberg™ Official Website. https://iceberg.apache.org/

[11] Dremio (2024). What Is Apache Iceberg? Features & Benefits. https://www.dremio.com/resources/guides/apache-iceberg/

[12] Doğuş Blog (2022). Data Lake, Data Warehouse ve Database Arasındaki Fark. https://dogus.com.tr/data-lake-data-warehouse-ve-database-arasindaki-fark-nedir/

[13] Qlik. Data Lake vs Data Warehouse: 6 Key Differences. https://www.qlik.com/us/data-lake/data-lake-vs-data-warehouse

[14] Exasol (2025). Data Lake vs Data Warehouse: Full Comparison Guide. https://www.exasol.com/hub/data-warehouse/vs-data-lake/

[15] Monte Carlo Data (2025). Data Warehouse Vs Data Lake Vs Data Lakehouse. https://www.montecarlodata.com/blog-data-warehouse-vs-data-lake-vs-data-lakehouse-definitions-similarities-and-differences/

[16] Coursera (2025). Data Lake vs. Data Warehouse: What’s the Difference? https://www.coursera.org/articles/data-lake-vs-data-warehouse

[17] LinkedIn. Veri Gölü ve Veri Ambarı Arasındaki Fark. https://tr.linkedin.com/pulse/veri-gölü-data-lake-dl-ve-ambarı-warehouse-dwh-fark-kapukaya

[18] ELEKS (2025). Data Lake vs Data Warehouse: Key Differences. https://eleks.com/blog/data-lake-vs-data-warehouse/

[19] Ahmet Sayar. Data Lake – Data Mart – Data Warehouse – Database. https://www.ahmetsayar.com/data-lake-data-mart-data-warehouse-database/

[20] DataCamp (2025). Data Lakehouse vs. Data Warehouse. https://www.datacamp.com/blog/data-lakehouse-vs-data-warehouse

[21] TechTarget. Data Lake vs. Data Warehouse: Key Differences. https://www.techtarget.com/searchdatamanagement/feature/Data-lake-vs-data-warehouse-Key-differences-explained

[22] Confluent. Tableflow: Convert Kafka topics to Iceberg and Delta tables. https://www.confluent.io/product/tableflow/

[23] Confluent Blog. Introducing Tableflow: Unifying Streaming and Analytics. https://www.confluent.io/blog/introducing-tableflow/

[24] Confluent Blog (2025). Inside Tableflow GA: Real-Time Kafka to Iceberg. https://www.confluent.io/blog/tableflow-ga-kafka-snowflake-iceberg/

[25] Confluent Documentation. Query Iceberg Tables with Snowflake and Tableflow. https://docs.confluent.io/cloud/current/topics/tableflow/how-to-guides/query-engines/query-with-snowflake.html

[26] Confluent Blog. Quickly Visualize Kafka Data With Tableflow/Iceberg, Trino and Jupyter. https://www.confluent.io/blog/integrating-confluent-tableflow-trino-apache-iceberg-jupyter/

[27] Sean Falconer (2025). Unifying Streaming and Analytics: Confluent Tableflow, Iceberg, and Snowflake. Snowflake Builders Blog. https://medium.com/snowflake/unifying-streaming-and-analytics-how-confluent-tableflow-iceberg-and-snowflake-simplify-267dca9f20f2

[28] Snowflake Quickstarts. Stream Kafka Data to Snowflake via Confluent Tableflow and Iceberg. https://quickstarts.snowflake.com/guide/snowflake-confluent-tableflow-iceberg/

[29] Orchestra (2024). Confluent Tableflow: Kafka Streaming & Iceberg. https://www.getorchestra.io/guides/confluent-tableflow-kafka-streaming-iceberg

[30] Confluent Documentation. Tableflow Quick Start with Managed Storage. https://docs.confluent.io/cloud/current/topics/tableflow/get-started/quick-start-managed-storage.html

[32] BigDataWire (2024). Dremio Goes Hybrid with Nessie-Based Metadata Catalog. https://www.bigdatawire.com/2024/10/29/dremio-goes-hybrid-with-nessie-based-metadata-catalog/

[33] e6data (2025). Iceberg Catalogs 2025: Exploring Emerging Metadata Solutions. https://www.e6data.com/blog/iceberg-catalogs-2025-emerging-catalogs-modern-metadata-management

[34] Dremio (2024). Nessie REST Catalog for Apache Iceberg Tables. https://www.dremio.com/blog/use-nessie-with-iceberg-rest-catalog/

[35] lakeFS (2025). Nessie Catalog: Key Features, Use Cases & How to Use. https://lakefs.io/blog/nessie-catalog/

[36] Kyle Weller (2024). Unity Catalog vs Apache Polaris. Medium. https://medium.com/@kywe665/unity-catalog-vs-apache-polaris-522b69a4d7df

[37] SiliconANGLE (2024). Dremio throws its support to Polaris data catalog. https://siliconangle.com/2024/10/29/dremio-throws-support-polaris-data-catalog-expands-deployment-options-iceberg-lakehouse/

[38] lakeFS (2024). Apache Iceberg Catalogs: Types & How to Choose. https://lakefs.io/blog/iceberg-catalog/

[39] Dremio (2024). An In-Depth Exploration on the World of Data Lakehouse Catalogs. https://www.dremio.com/gnarly-data-waves/an-in-depth-exploration-on-the-world-of-data-lakehouse-catalogs-iceberg-polaris-nessie-unity-etc-what-are-data-lakehouse-catalogs/

[40] Apache Iceberg Documentation. Nessie Integration. https://iceberg.apache.org/docs/1.5.1/nessie/

[41] Douglas Moore (2024). Unity Catalog as the center of the Open Data Ecosystem. Medium. https://medium.com/databricks-unity-catalog-sme/unity-catalog-as-the-center-of-the-open-data-ecosystem-4d810da898b1