2026'da Delta Lake vs Apache Iceberg: Lakehouse Mimarisi ve Mülakat Soruları

Delta Lake ve Apache Iceberg, 2026 yılında modern data lakehouse mimarilerini güçlendiren iki baskın açık tablo formatını temsil etmektedir. Her ikisi de aynı temel sorunu çözer—bulut nesne depolamaya ACID işlemleri, şema evrimi ve zaman yolculuğu getirme—ancak üretim iş yükleri için önemli olan farklı mimari yaklaşımlar benimser.

Delta Lake vs Iceberg: Temel Mimari Farklılıklar

Her iki format da verileri nesne depolamada Parquet dosyaları olarak saklar, ancak meta veri katmanları önemli ölçüde farklıdır.

Delta Lake, her değişikliği kaydeden JSON dosyaları içeren bir işlem günlüğü (_delta_log/) kullanır. Her commit yeni bir JSON dosyası oluşturur ve periyodik kontrol noktaları bunları daha hızlı okuma için Parquet formatına birleştirir. Delta Lake protokol spesifikasyonu, ileri uyumluluk için versiyonlanmış okuyucu/yazıcı özellikleri tanımlar.

Apache Iceberg, bir meta veri dosyaları hiyerarşisi tutar: manifest listelerine işaret eden bir meta veri JSON dosyası, bu listeler de dosya düzeyinde istatistikler içeren manifestlere işaret eder. Bu tasarım, planlama aşamasında predicate pushdown'ı mümkün kılar—sorgu motoru herhangi bir veri okumadan önce tüm dosyaları atlar.

| Özellik | Delta Lake | Apache Iceberg | |---------|------------|----------------| | İşlem Günlüğü | JSON + Parquet kontrol noktaları | Meta veri JSON + manifest dosyaları | | Bölüm Evrimi | Yeniden yazma gerektirir | Yeniden yazma olmadan yerinde | | Motor Desteği | Spark, Trino, Flink | Spark, Trino, Flink, Dremio, Athena | | Zaman Yolculuğu | Versiyon tabanlı | Branch/tag ile snapshot tabanlı | | Şema Evrimi | Sütun ekleme/yeniden adlandırma | Sütun ekleme/yeniden adlandırma/sıralama/genişletme |

Gizli Bölümler: Iceberg'in Temel Avantajı

Geleneksel Hive tarzı bölümleme, bölüm sütunlarını sorgularda gösterir (WHERE year=2026 AND month=7), fiziksel düzeni SQL sözdizimine bağlar. Iceberg'in gizli bölümleri bu endişeleri ayırır.

# iceberg_partition_example.py
from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import StringType, TimestampType, LongType, NestedField
from pyiceberg.partitioning import PartitionSpec, PartitionField
from pyiceberg.transforms import MonthTransform

# Şema tanımı
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "event_time", TimestampType(), required=True),
    NestedField(3, "user_id", StringType(), required=True),
    NestedField(4, "event_type", StringType(), required=False),
)

# event_time'dan çıkarılan ay üzerinde gizli bölüm
partition_spec = PartitionSpec(
    PartitionField(
        source_id=2,  # event_time alanı
        field_id=1000,
        transform=MonthTransform(),
        name="event_month"
    )
)

catalog = load_catalog("glue", **{"type": "glue"})
catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=partition_spec
)

Sorgular doğrudan event_time üzerinden filtreleme yapar—motor, WHERE cümlesinde bölüm sütununu göstermeden otomatik olarak bölüm budamayı uygular. Bölüm evrimi, tablonun mevcut verileri yeniden yazmadan aylık bölümlemeden günlük bölümlemeye geçmesini sağlar.

Delta Lake ACID İşlemleri ve İyimser Eşzamanlılık

Delta Lake, iyimser eşzamanlılık kontrolü kullanarak serileştirilebilir izolasyon uygular. Yazıcılar, çakışmaları tespit etmek için commit öncesinde işlem günlüğünü kontrol eder.

# delta_concurrent_writes.py
from delta import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", 
            "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# Otomatik çakışma çözümlemeli eşzamanlı MERGE işlemi
delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# Gelen batch'i mevcut verilerle birleştir
delta_table.alias("target").merge(
    source=incoming_df.alias("source"),
    condition="target.event_id = source.event_id"
).whenMatchedUpdateAll() \
 .whenNotMatchedInsertAll() \
 .execute()

# Çakışma tespiti commit sırasında otomatik olarak gerçekleşir
# Başarısız işlemler güncellenmiş snapshot ile yeniden denenir

Delta Lake'in çakışma çözümleme kuralları, eşzamanlı eklemelerin başarılı olmasına izin verirken aynı bölüme yapılan çakışan güncellemeleri serileştirir.

Zaman Yolculuğu ve Veri Versiyonlama Karşılaştırması

Her iki format da zaman yolculuğunu destekler, ancak farklı semantiklerle.

-- Delta Lake: Versiyon numarasına göre sorgu
SELECT * FROM events VERSION AS OF 42;

-- Delta Lake: Zaman damgasına göre sorgu
SELECT * FROM events TIMESTAMP AS OF '2026-07-15 10:00:00';

-- Iceberg: Snapshot ID'ye göre sorgu
SELECT * FROM analytics.events FOR SYSTEM_VERSION AS OF 8823749234;

-- Iceberg: Zaman damgasına göre sorgu
SELECT * FROM analytics.events FOR SYSTEM_TIME AS OF TIMESTAMP '2026-07-15 10:00:00';

Iceberg 1.5+ dallanma ve etiketleme ekler—izole deneyler için adlandırılmış dallar oluşturun, ardından birleştirin veya atın. Delta Lake, sığ klonlar aracılığıyla benzer iş akışları elde eder.

-- Iceberg: Test için dal oluştur
ALTER TABLE analytics.events CREATE BRANCH experiment;

-- Ana dalı etkilemeden dala yaz
INSERT INTO analytics.events.branch_experiment 
SELECT * FROM staging.events WHERE event_type = 'test';

-- Dalı ana dalla birleştir
CALL system.fast_forward('analytics.events', 'main', 'experiment');

Sorgu Motoru Uyumluluk Matrisi

Motor uyumluluğu, birçok organizasyon için format seçimini yönlendirir.

| Motor | Delta Lake Desteği | Iceberg Desteği | |-------|-------------------|------------------| | Apache Spark | Native (Databricks, OSS) | Native | | Trino/Presto | Connector | Native | | Apache Flink | Connector | Native (1.16+) | | Dremio | Salt okunur | Native | | AWS Athena | Sınırlı | Native | | Snowflake | Harici tablolar | Native (Iceberg tabloları) | | BigQuery | Harici tablolar | BigLake Iceberg |

Sadece Spark ortamları için Delta Lake'in daha sıkı entegrasyonu daha iyi performans sunar. Çok motorlu mimariler, Iceberg'in daha geniş uyumluluğundan yararlanır—Iceberg REST Catalog, katalog işlemleri için satıcıdan bağımsız bir API sağlar.

Performans Optimizasyon Teknikleri

Her iki format da optimum sorgu performansı için bakım işlemleri gerektirir.

# delta_optimize.py
from delta import DeltaTable

delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# Küçük dosyaları sıkıştır (bin-packing)
delta_table.optimize().executeCompaction()

# Çok sütunlu predicate'ler için Z-order
delta_table.optimize().executeZOrderBy("user_id", "event_time")

# Eski versiyonları kaldır (vacuum)
delta_table.vacuum(retentionHours=168)  # 7 gün tut

-- Iceberg: Sıkıştırma için veri dosyalarını yeniden yaz
CALL catalog.system.rewrite_data_files(
  table => 'analytics.events',
  strategy => 'binpack',
  options => map('target-file-size-bytes', '134217728')
);

-- Iceberg: Eski snapshot'ları süresi dolmuş olarak işaretle
CALL catalog.system.expire_snapshots(
  table => 'analytics.events',
  older_than => TIMESTAMP '2026-07-01 00:00:00',
  retain_last => 10
);

Z-ordering, ilgili verileri bir arada gruplar ve predicate pushdown etkinliğini artırır. Her iki format da akış kaynaklarından birçok küçük dosya alırken dosya sıkıştırmasından faydalanır.

Yaygın Data Lakehouse Mülakat Soruları

Veri mühendisliği mülakatlarında sıkça sorulan sorulara hazırlanma.

S: Iceberg'i Delta Lake'e ne zaman tercih edersiniz?

Iceberg şu durumlarda daha uygundur: (1) birden fazla sorgu motoru aynı tablolara erişiyorsa (Spark, Trino, Flink), (2) bölüm şemalarının veri yeniden yazılmadan evrilmesi gerekiyorsa, (3) organizasyon satıcıdan bağımsız açık standartları tercih ediyorsa. Delta Lake, Databricks merkezli mimarilerde veya Unity Catalog'un yönetişim sağladığı saf Spark ortamlarında öne çıkar.

S: Iceberg veri yeniden yazma olmadan bölüm evrimini nasıl başarır?

Iceberg, bölüm spesifikasyonlarını meta veri olarak saklar. Spesifikasyon değiştiğinde, yeni veriler yeni bölümlemeyi kullanırken mevcut veriler orijinal düzenini korur. Sorgu planlayıcısı tüm bölüm spesifikasyonlarını okur ve her dosya grubu için doğru budama mantığını uygular.

S: Delta Lake'in checkpoint mekanizmasını açıklayın.

Delta Lake, varsayılan olarak her 10 commit'te bir checkpoint dosyası oluşturur. Bir checkpoint, daha hızlı okumalar için işlem günlüğünü tek bir Parquet dosyasına birleştirir. _last_checkpoint dosyası en son checkpoint'e işaret eder ve okuyucular checkpoint'i artı sonraki JSON commit'leri okuyarak durumu yeniden oluşturur.

S: Copy-on-write ve merge-on-read nedir?

Copy-on-write (COW), güncellemelerde tüm dosyaları yeniden yazar—daha yüksek yazma maliyeti ama daha hızlı okumalar. Merge-on-read (MOR), deltaları ayrı ayrı yazar ve sorgu zamanında birleştirir—daha düşük yazma gecikmesi ama okuma yükü. Iceberg her ikisini de destekler; Delta Lake, son versiyonlarda yumuşak silmeler için deletion vectors ile ağırlıklı olarak COW kullanır.

Mülakatlardan önce anlayışı pekiştirmek için SharpSkill'in veri mühendisliği mülakat sorularında bu kalıpları pratik yapabilirsiniz.

Geçiş Yolu: Formatlar Arası Dönüşüm

Organizasyonlar bazen formatlar arasında geçiş yapması gerekir. Her ikisi de dönüşüm yardımcı programlarını destekler.

# Spark kullanarak Delta'yı Iceberg'e dönüştür
spark.sql("""
    CALL catalog.system.snapshot(
        source_table => 'delta.`s3://bucket/delta_events`',
        table => 'analytics.events_iceberg'
    )
""")

# Iceberg'i Delta'ya dönüştür
from delta.tables import DeltaTable

iceberg_df = spark.read.format("iceberg").load("catalog.analytics.events")
iceberg_df.write.format("delta").save("s3://bucket/delta_events")

Tam geçiş, şema türlerinin, bölümleme semantiğinin ve downstream tüketici uyumluluğunun dikkatli doğrulanmasını gerektirir.

Sonuç

• Spark-native iş yükleri, Databricks ortamları ve Unity Catalog yönetişiminin organizasyonel ihtiyaçlara uyduğu durumlarda Delta Lake tercih edilmelidir
• Çok motorlu mimariler, bölüm evrimi gereksinimleri ve buluttan bağımsız dağıtımlar için Iceberg tercih edilmelidir
• Her iki format da ACID işlemleri, zaman yolculuğu ve şema evrimi sunar—doğru seçim mevcut altyapıya ve sorgu motoru çeşitliliğine bağlıdır
• Mülakat hazırlığı, işlem günlüğü iç yapısını, bölüm budama optimizasyonunu ve COW vs MOR ödünleşimlerini kapsamalıdır
• Dosya sıkıştırma ve snapshot süresi dolma, format seçiminden bağımsız olarak kritik bakım görevleri olmaya devam eder