Veri ambarı ile data lake arasındaki sınır 2026 itibarıyla iyice silikleşti. Bunun teknik sebebi tek başına bir teknoloji değil, üç açık tablo formatının yarışı: Apache Iceberg, Delta Lake ve Apache Hudi. Bunlardan Iceberg, son 18 ayda Snowflake, AWS, Google Cloud ve Microsoft Fabric'in ardı ardına yaptığı resmi destek duyurularıyla fiilî standart hâline geldi. Peki Iceberg neden bu kadar önemli ve kurumsal mimari için ne anlama geliyor?
Sorun: Vendor Lock-in ve Veri Kopyalama
Geleneksel veri ambarı (Snowflake, BigQuery, Redshift) kapalı bir tablo formatı kullanır. Bu, performans için harika ama iki büyük maliyet getirir: aynı veriyi farklı platformlarda kullanabilmek için kopyalamak gerekir, ve platformdan çıkış zorlu hâle gelir. Apache Iceberg bu sorunu Parquet dosyalarının üzerine açık bir metadata katmanı koyarak çözer — veri tek bir kopya olarak object storage'da (S3, ADLS, GCS) durur, birden fazla motor (Spark, Trino, Snowflake, Databricks) aynı tabloyu okuyabilir.
Iceberg'in Teknik Vaatleri
Iceberg'in benimsenmesini hızlandıran dört özellik:
- Snapshot izolasyonu: ACID işlem garantisi, schema evolution ve time travel — tıpkı bir veri ambarı gibi.
- Hidden partitioning: Sorgu yazarken partition kolonunu bilmek zorunda olmamak; Iceberg arka planda yönetir.
- Schema evolution: Sütun ekleme, silme, yeniden adlandırma geriye dönük tabloları kırmadan yapılabilir.
- Manifest tabanlı metadata: Trilyon satırlık tablolarda bile metadata sorgu süreleri saniyeler içinde kalır.
Açık Tablo Formatları Arasındaki Fark
- Iceberg: Apache vakfı, Netflix kökenli, tüm büyük bulutlarda destek. Vendor-neutral aday.
- Delta Lake: Databricks kökenli, Linux Foundation altında ama Databricks etrafında daha güçlü. Yüksek-performans senaryolarında iyi.
- Hudi: Uber kökenli, real-time upsert senaryolarında güçlü ama kurumsal kabul daha sınırlı.
2026 itibarıyla yeni greenfield projelerde Iceberg, Snowflake ve Databricks'in ortak desteği nedeniyle güvenli seçim hâline geldi.
Lakehouse Mimarisinde Pratik Etki
Tipik bir bankacılık DWH'ını (örneğin 50-100 TB ölçeğinde) Iceberg + Trino + Snowflake hibridine geçiren bir senaryoda gözlenen örüntüler:
- Snowflake compute maliyeti %38 azaldı (ad-hoc analitik Trino'ya alındı).
- Aynı tablo Spark'ta ML feature store olarak kullanıldı, kopyalama gerekmedi.
- Schema değişikliği üretimi durdurmadan yapıldı.
- Time travel sayesinde regülatör auditi 1 günden 2 saate düştü.
Geçiş Stratejisi: Big-Bang Değil, Aşamalı
Mevcut Snowflake/BigQuery'den Iceberg'e geçişte önerdiğimiz aşamalı yaklaşım:
- Faz 1: Yeni veri kaynaklarını Iceberg'e yazmaya başla, eski tabloları olduğu gibi bırak.
- Faz 2: En çok dış sistem tarafından okunan tabloları (export-heavy) Iceberg'e taşı.
- Faz 3: Analitik motorda Trino veya Athena gibi açık sorgu katmanı tanıt.
- Faz 4: Ölçü ve maliyet doğrulandıktan sonra geri kalan migrasyon.
