Giriş

Apache Spark, on yılı aşkın süredir büyük veri işlemenin fiili standardı. Ama Spark’ın çekirdek çalışma zamanı hâlâ büyük ölçüde JVM üzerinde, satır bazlı (row-based) bir yürütme modeline dayanıyor — ve bu, modern donanımın sunduğu vektörel işlem gücünün önemli bir kısmının masada kalması anlamına geliyor.

Apache DataFusion Comet, tam olarak bu boşluğu dolduruyor: Spark’ın SQL/DataFrame API’sine hiç dokunmadan, motorun altını Rust ile yazılmış native bir çalışma zamanıyla değiştiriyor.

Özetle: Comet, Apache Software Foundation çatısı altında geliştirilen, Apache DataFusion sorgu motorunu kullanan, Spark için açık kaynaklı bir hızlandırıcıdır. TPC-DS 1TB testlerinde ~2x hızlanma ve buna bağlı olarak yaklaşık %50 maliyet tasarrufu rapor edilmiştir.

Comet Aslında Ne Yapıyor?

Comet’in temel fikri basit ama etkisi büyük: Spark sorgu planındaki operatörleri ve ifadeleri (expression’ları), mümkün olduğunca Apache Arrow columnar formatında, uçtan uca tutmak. Scan, filter, join, aggregate, shuffle, broadcast bunların hepsi Arrow formatında kalıyor ve JVM’in row-based dünyasına geri dönüşler minimize ediliyor.

Bu native yürütme iki şekilde gerçekleşiyor:

• Rust kodu olarak (Apache DataFusion sorgu motoru üzerinden) ana hızlanmanın geldiği yer burası
• JVM kodu olarak, ama doğrudan Arrow batch’leri üzerinde çalışacak şekilde optimize edilmiş

Sonuç: Spark’ın kendi API’si, SQL semantiği ve davranışı korunurken, altyapı katmanı çok daha verimli hale geliyor. Kullanıcı tarafında hiçbir kod değişikliği gerekmiyor bu, Comet’in en çok vurgulanan özelliklerinden biri.

Neden Sadece “Spark’ı Hızlandırmak” Değil de Bu Yaklaşım?

Spark’ın gücü dağıtık işlemede yatıyor veriyi binlerce node’a paralel dağıtabiliyor. Ama tek bir executor içindeki ham hesaplama verimliliği, JVM’in doğası gereği sınırlı kalıyor:

• Nesne oluşturma ve garbage collection duraklamaları
• Boxing/unboxing maliyetleri (örneğin int → Integer)
• Satır bazlı işlemenin CPU cache’ini verimsiz kullanması

Comet, bu sorunları native Rust yürütmesiyle çözüyor. Rust’ın garbage collector’ı yok, bu da öngörülemez duraklamaları ortadan kaldırıyor. Aynı zamanda Rust’ın bellek güvenliği garantileri (use-after-free, buffer overflow gibi hataların derleme zamanında engellenmesi), her executor içinde çalışan ve güvenilmeyen veri işleyen bir bileşen için ayrıca önemli bu güvenlik, ek bir çalışma zamanı maliyeti getirmeden sağlanıyor.

Comet’in Kapsadığı Ana Alanlar

Parquet Taramaları Spark’ın sorgu planlayıcısıyla entegre çalışan native bir Parquet okuyucu, dosya okuma ve decode aşamasını hızlandırıyor.

Apache Iceberg Desteği Comet, Spark üzerinden Iceberg tabloları okunurken Parquet taramalarını hızlandırıyor. Daha yakın zamanda REST Catalog desteği eklendi; bu sayede Apache Polaris gibi katalog servisleriyle native Iceberg entegrasyonu mümkün hale geldi.

Native Shuffle Shuffle, Spark’ta genellikle en maliyetli adımlardan biridir. Comet, bunu Arrow-IPC formatında native bir Rust implementasyonuyla gerçekleştiriyor; hash ve range partitioning destekleniyor, desteklenmeyen partition key tipleri için JVM fallback’i devreye giriyor.

Scala/Java UDF Desteği Comet, mevcut Scala/Java skaler UDF’lerin Spark’ın whole-stage codegen mekanizması üzerinden Comet pipeline’ı içinde kalmasına izin veriyor — yani özel fonksiyonlarınız olsa bile native hızlanmadan tamamen kopmuyorsunuz.

Otomatik Fallback Comet’in desteklemediği bir operatör veya ifadeyle karşılaşıldığında, sistem otomatik olarak o kısmı normal Spark motoruna devrediyor. spark.comet.explainFallback.enabled=true konfigürasyonuyla hangi kısımların fallback yaptığı loglanabiliyor bu, gerçek faydayı ölçmek için önemli bir araç.

Rakamlar Ne Diyor?

Proje sayfasında paylaşılan TPC-H (100GB, tek executor, 8 çekirdek) sonuçlarına göre, Comet ile toplam çalışma süresi 687 saniyeden 302 saniyeye düşüyor — yaklaşık 2.2x hızlanma. TPC-DS @ SF 1000 (1TB) ölçeğinde ise ~2x hızlanma ve buna bağlı ~%50 maliyet tasarrufu rapor ediliyor. Bu tasarruf iki şekilde değerlendirilebilir: aynı cluster’da işi yarı sürede bitirmek ya da aynı süreyi yarı kaynakla yakalamak.

Önemli bir not: Bu rakamlar belirli benchmark koşullarına ait ve her iş yükünde aynı oranda hızlanma beklenmemeli. Comet’in kendi belgelerinde de vurgulandığı gibi, gerçek kazanç sorgunun ne kadarının native olarak çalıştığına bağlı.

Comet vs. Gluten: Kısa Bir Karşılaştırma

Spark hızlandırma alanında bilinen bir başka proje de Gluten + Velox kombinasyonu. İkisi arasındaki temel fark, kullanılan native motor ve dil seçimi:

CometGluten + VeloxNative motorApache DataFusion (Rust)Velox (C++, Meta öncülüğünde)GovernanceApache Software FoundationÇoklu kuruluş, ağırlıklı MetaKatkı süreciStandart ASF süreciMeta CLA imzası gerekiyorANSI mode desteğiNative olarak destekleniyorVelox backend’inde desteklenmiyor, ANSI açıkken sorgu Spark’a düşüyorBellek güvenliğiRust (derleme zamanı garantisi)C++ (çalışma zamanı disiplinine bağlı)

Rust’ta UDF yazmak isteyenler için Comet, C++’ta yazmak isteyenler için Gluten daha uygun bir tercih olabilir. Spark 4.0 ve ANSI mode kullanan ekipler için bu fark özellikle önemli, çünkü ANSI açıkken Gluten/Velox tarafında iş yükünün önemli bir kısmı native yürütmeden düşebiliyor.

Kurulum ve Uyumluluk

Comet, Spark 3.4, 3.5, 4.0 ve 4.1'i destekliyor; Spark 4.2 için deneysel destek mevcut. Jar dosyaları Linux için amd64 ve arm64 mimarilerinde Maven Central üzerinden dağıtılıyor; macOS için şu an kaynaktan derleme gerekiyor.

Kurulum temelde üç adımdan oluşuyor:

1. Spark/Scala sürümünüze uygun Comet jar’ını classpath’e eklemek
2. spark.plugins=org.apache.spark.CometPlugin konfigürasyonunu etkinleştirmek
3. Shuffle hızlanması isteniyorsa spark.shuffle.manager ayarını Comet'in shuffle yöneticisine yönlendirmek

Bulut sağlayıcılarının kendi Spark forklarında (örneğin yönetilen servisler) Comet’in tam uyumlu çalışmayabileceği belgelerde ayrıca belirtiliyor — bu nedenle production’a almadan önce kendi ortamınızda doğrulama yapmak gerekiyor.

Pratikte Nelere Dikkat Etmeli?

• Kademeli geçiş yapın. Tüm pipeline’ı bir seferde Comet’e geçirmek yerine, önce tek bir job veya tabloyla test edin.
• Fallback loglarını izleyin. spark.comet.explainFallback.enabled=true ile hangi operatörlerin native çalışıp hangilerinin Spark'a düştüğünü görün.
• Native Parquet yazma özelliğine dikkat. Bu özellik hâlâ deneysel kabul ediliyor ve production kullanımı için önerilmiyor.
• Delta Lake / Iceberg gibi tablo formatlarıyla kombinasyonları ayrıca test edin, çünkü cast davranışı ve decimal/timestamp işleme gibi ince farklar sonuçları etkileyebilir.

Sonuç

Apache DataFusion Comet, “Spark zaten hızlı, buna neden ihtiyaç var” sorusuna net bir cevap veriyor: dağıtık işlemedeki hız ile tek node’daki yürütme verimliliği aynı şey değil. Comet, Spark’ın API yüzeyine dokunmadan, motorun altını Rust/Arrow tabanlı native bir çalışma zamanıyla değiştirerek bu ikinci kısmı iyileştiriyor.

Apache Software Foundation çatısı altında, aktif geliştirme sürecine sahip ve dröp-in (kod değişikliği gerektirmeyen) bir çözüm arayan Spark kullanıcıları için değerlendirilmeye değer bir proje. Ancak her hızlandırma aracında olduğu gibi, gerçek fayda iş yükünüzün doğasına bağlı kendi pipeline’ınızda ölçüm yapmadan genel rakamlara güvenmemek en sağlıklı yaklaşım.

Kaynak:

• GitHub - apache/datafusion-comet: Apache DataFusion Comet Spark Accelerator
• Apache DataFusion Comet - Apache DataFusion Comet documentation

Bir Big Data mühendisi için “Benim makinemde çalışıyordu” cümlesi, karmaşık bir cluster kurulumunun ardından gelen en büyük operasyonel hüsrandır. Spark job’larının aniden çökmesi, Kafka’nın bağlantı hataları vermesi veya Airflow container’larının sonsuz bir “restart” döngüsüne girmesi, çoğu zaman Docker’ın temel prensiplerindeki küçük ama kritik eksiklerden kaynaklanır.

Günümüzde Docker, sadece bir paketleme aracı değil; Spark, Kafka ve Airflow gibi araçların verimli çalışmasını sağlayan modern veri mühendisliğinin işletim sistemi haline gelmiştir. Bir Senior Big Data Mimarı gözüyle, production ortamlarında “Namespace isolation” ve “Immutable layers” gibi kavramları birer kolaylık değil, performans kaldıracı olarak kullanmanızı sağlayacak 6 altın kuralı inceliyoruz.

1. Katman (Layer) Optimizasyonu: 5 Dakikalık Bekleyişi 10 Saniyeye İndirmek

Docker image’ları, Dockerfile içindeki her bir komutun oluşturduğu "read-only" katmanlardan (layer) meydana gelir. Docker her katmanı bir SHA256 hash değeri ile takip eder. Değişmeyen katmanlar cache'den okunur, ancak bir katman değiştiğinde altındaki tüm katmanlar yeniden build edilir.

Big Data pipeline’larında build sürelerini dramatik şekilde düşürmek için en sık değişen katmanı (uygulama kodu) en sona bırakmak non-negotiable (tartışmaya kapalı) bir kuraldır:

• Yanlış Sıralama: Uygulama kodunu (COPY src/) bağımlılıklardan (pip install) önce kopyalarsanız, koddaki tek bir karakter değişimi bile tüm kütüphanelerin tekrar indirilmesine neden olur.
• Doğru Strateji:

1. Base Image (Örn: python:3.11-slim-bookworm)
2. Sistem bağımlılıkları (apt-get install)
3. Kütüphane listesi (COPY requirements.txt)
4. Bağımlılık kurulumu: Burada mutlaka RUN pip install --no-cache-dir -r requirements.txt kullanılmalıdır. --no-cache-dir kullanılmaması, image boyutunu gereksiz yere şişirir.
5. Uygulama kodu (COPY src/)

Sonuç: Doğru sıralama ile kodu her güncellediğinizde 5 dakika beklemek yerine, build işlemini 10 saniyenin altında tamamlayabilirsiniz. Layer verimliliğinizi analiz etmek için Dive gibi araçları kullanmanızı öneririm.

2. “Localhost” Tuzağı: Dual Listener ile Kafka Erişimi

Veri mühendislerinin en sık karşılaştığı networking hatası, container içindeki bir servise localhost üzerinden erişmeye çalışmaktır. Her container kendi izole network namespace'ine sahiptir. Kafka gibi dağıtık sistemlerde KAFKA_ADVERTISED_LISTENERS konfigürasyonunu sadece localhost olarak ayarlamak, dışarıdaki bir Spark container'ının Kafka'yı bulamamasına neden olur.

Production seviyesinde bir çözüm için hem iç (container-to-container) hem dış (host-to-container) erişimi ayıran Dual Listener kurulumu şarttır:

# Kafka — Senior Seviye Listener Konfigürasyonu
environment:
  KAFKA_LISTENERS: INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093
  KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:9092,EXTERNAL://localhost:9093
  KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT
  KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL

Bu kurulumda, Spark container’ı Kafka’ya kafka:9092 (Docker DNS) üzerinden ulaşırken, siz host makinenizden localhost:9093 ile bağlanabilirsiniz.

3. OOMKiller ile Mücadele: %75 Kuralı ve Swap Felaketi

JVM tabanlı servisler (Spark, Kafka, Flink) bellek yönetimi konusunda agresiftir. Eğer Docker memory limiti ile JVM Heap (-Xmx) ayarınız arasında boşluk bırakmazsanız, işletim sistemi container'ı aniden sonlandırır. Bu durum loglarda Exit Code 137 (OOMKiller) olarak görülür.

OOMKiller sadece Heap yüzünden değil; Metaspace, Thread Stack ve Off-heap (özellikle Spark’ta yoğun kullanılır) operasyonlarının toplamının container limitini aşmasıyla tetiklenir.

Kritik Kural: JVM Xmx = container_memory * 0.75

Örneğin, 4GB limitli bir container’da JVM Heap ayarını (-Xmx) en fazla 3GB yapmalısınız. Ayrıca Spark gibi performans odaklı araçlarda --memory-swap değerini memory limitine eşitleyerek swap'ı tamamen kapatın. Spark swap'a düştüğünde GC (Garbage Collection) duraksama süreleri dakikalara çıkabilir, bu da veri pipeline'ınız için tam bir performansa felaketidir.

4. Multi-Stage Build: Görüntü Boyutunda %67 Tasarruf

Production image’larınızda Maven, GCC veya build script’lerinin işi yoktur. Multi-Stage Build tekniği ile build araçlarını sadece ilk aşamada (builder) kullanıp, final image'a (runtime) sadece gereken binary'leri taşımalısınız.

Multi-Stage Build Kazanımı:

• Tek Aşamalı Build (Maven + JDK + Spark): ~850MB
• Multi-Stage Build (Sadece JRE + JAR): ~280MB
• Fayda: %67 daha küçük image boyutu.

Bu sadece depolama tasarrufu değil, aynı zamanda Kubernetes ortamında Pod Startup Latency (image pull süresi) değerini düşürür ve “attack surface” alanını daraltarak güvenliği artırır.

5. Veri Kaybını Önlemek: Stateful Servislerde Volume ve Permission Yönetimi

Container’lar doğası gereği “ephemeral” (geçici) yapılardır. Kafka logları veya Postgres verileri için Named Volume kullanımı verinin kalıcılığı için zorunludur. Ancak “Senior” bir mühendisin asıl dikkat etmesi gereken nokta Linux çekirdek izinleridir.

Big Data container’ları güvenlik gereği genellikle non-root kullanıcılarla çalışır. Örneğin, Airflow container’ı UID 50000 ile çalışır. Eğer host makinedeki bir dizini (Bind Mount) container'a bağlarsanız ve host dizininin sahibi root ise, Airflow yazma hatası alacaktır.

Senior Tavsiyesi: Bind mount kullanırken host üzerindeki dizinlerin sahipliğini container içindeki kullanıcının UID değeriyle eşitlemek standart bir çözümdür: sudo chown -R 50000:50000 ./logs ./dags

6. CI/CD’de “Latest” Etiketinden Kaçınmak: Immutable Infrastructure

Profesyonel veri pipeline’larında latest tag'ini kullanmak, operasyonel bir kumardır. Hangi versiyonun çalıştığının bilinmemesi, hata anında "rollback" (geri dönüş) hassasiyetini sıfıra indirir.

Güvenli Versiyonlama Stratejisi:

1. Semantic Versioning: Uygulama sürümleri için 1.2.3 gibi etiketler kullanın.
2. Git Commit Hash: Her image’ı ilgili Git commit’inin kısa özetiyle (git rev-parse --short HEAD) etiketleyin.
3. İzlenebilirlik: Belirli tag kullanımı, “Immutable Infrastructure” (Değişmez Altyapı) prensibini destekler ve hata ayıklama süreçlerinde spesifik bir job failure’ı o anki image versiyonuyla eşleştirmeyi sağlar.

Sonuç ve Öneriler

Docker’ı tüm katmanlarıyla kavramak, aslında modern veri yığınını (Modern Data Stack) anlamakla eşdeğerdir. İzolasyon, kaynak yönetimi ve taşınabilirlik gibi kavramlar sadece birer kolaylık değil; veri mimarinizin ölçeklenebilirliği için temel gerekliliklerdir.

Veri mimarinizi kurarken şu soruyu kendinize sorun: “Container izolasyonunu sadece bir paketleme yöntemi olarak mı, yoksa bir operasyonel güvenlik ve performans kaldıracı olarak mı kullanıyorsunuz?”

Kaynakça :

docs.docker.com Container fundamentals,

O’Reilly Media, 2023 Container ve image mimarisi, layer

Apress, 2023

docs.docker.com/scout

1. Büyük Veri Tabanlı Retrieval-Augmented Generation Sistemlerinin Kurumsal Uygulaması

Modern kurumsal ekosistemlerde veri, yalnızca depolanan bir varlık değil, yaşayan bir organizmadır. "Dokümanlarla konuşan AI asistanı" kavramı, teknik bir fantezinin ötesine geçerek kurumsal hafızanın milisaniyeler içinde aksiyona dönüştürülmesini temsil eder. Şirket politikaları, teknik spesifikasyonlar ve binlerce sayfalık akademik literatür arasında manuel arama yapmak (Eski Yöntem), günümüzün rekabet hızında kabul edilemez bir verimlilik kaybıdır.

Bu rehberde kurgulanan sistem, standart RAG (Retrieval-Augmented Generation) yaklaşımlarının "yükle ve unut" sığlığını aşarak; veri tutarlılığı, versiyonlama ve denetlenebilirliği merkeze alan bir Big Data mimarisi sunar. Bu altyapı, sadece bir chatbot değil, kurumsal verinin doğruluğunu ve izlenebilirliğini garanti altına alan bir mühendislik kalesidir.

2. Mimari Temeller: Tam Yığın (Full-Stack) Teknoloji Ekosistemi

Sistemin başarısı, SaaS çözümlerinin maliyet ve veri gizliliği risklerine karşın, açık kaynaklı teknolojilerin yüksek performanslı bir sinerjiyle bir araya getirilmesine dayanır. Bu "Modern Stack", yerel geliştirme esnekliğini üretim ortamı (production) ölçeğiyle birleştirir.

Teknoloji Stack Analizi

Mimari Sinerji ve Stratejik Tercih

Sistemin kalbinde, veriyi işleyen Spark ile bu veriyi SQL standartlarında sorgulanabilir kılan Trino arasındaki görev ayrımı yatar. Açık kaynak tercih edilmesi, kurumsal verinin tamamen kontrol altında tutulmasını sağlarken, S3 uyumlu MinIO kullanımı sistemin yarın bulut ortamına (AWS S3) taşınmasını "sıfır kod değişikliği" ile mümkün kılar.

3. Fark Yaratan Bileşen: Big Data Mimarisi ve Veri Yönetişimi

Geleneksel RAG sistemlerinin en büyük zafiyeti "Data Lineage" (Veri İzlenebilirliği) eksikliğidir. Bir AI yanıtı hatalı olduğunda, bu hatanın kaynağını (Doküman versiyonu? Chunking hatası? Embedding bozulması?) bulmak standart sistemlerde imkansızdır.

Kritik Teknolojilerin Analizi

• Apache Iceberg: ACID garantisi ile veri yazma/silme işlemlerini yönetir. "Time Travel" özelliği sayesinde, sistemin 1 hafta önceki durumuna saniyeler içinde dönülebilir. Schema Evolution yeteneğiyle, doküman yapısı değişse bile sistem kesintiye uğramaz.
• Project Nessie: Veri dünyasına "Git" pratiklerini getirir. Bir branch açarak yeni doküman setlerini ana sistemi bozmadan test edebilir, doğruluğundan emin olduğunuzda merge yapabilirsiniz.

Veri İzlenebilirliği (Data Lineage)

Kurumsal denetim (audit) için sistem şu spesifik zinciri kayıt altında tutar: Document → Chunks → Embeddings. Hangi embedding'in hangi doküman snapshot'ından üretildiği bilgisi Iceberg metadata katmanında saklanır. Bu, "Bu cevap hangi dokümandan geldi?" sorusuna verilebilecek en kesin teknolojik yanıttır.

4. Adım Adım Uygulama ve Kurulum Stratejisi

Karmaşık sistemlerde "Önce Altyapı" (Infrastructure First) yaklaşımı, bağımlılıkların yönetilmesi için hayati önem taşır.

Kurulum ve Yapılandırma Prosedürü

1. Servislerin Başlatılması: Docker-compose yapılandırması başlatıldıktan sonra, projenin sunduğu Makefile içindeki make health komutu çalıştırılmalıdır. Bu komut, tüm servislerin sadece "çalışıyor" değil, "Healthy" (işlevsel) olduğunu teyit eder.
2. MinIO Kritik Ön Hazırlık: Sistem çalışmadan önce MinIO Console (Port 9001) üzerinden warehouse isimli bucket manuel olarak oluşturulmalıdır. Bu bucket, Iceberg tablolarının fiziksel evidir.
3. Namespace Gerekliliği: Tablo oluşturma aşamasında en sık yapılan hata direkt tabloya gitmektir. Önce şu komut Spark/Trino üzerinden çalıştırılmalıdır: CREATE NAMESPACE iceberg.rag_data_lake;
4. Spark JAR Entegrasyonu: Spark'ın ekosistemle konuşabilmesi için toplam ~474MB büyüklüğündeki JAR kütüphaneleri /opt/spark-jars/ dizinine yerleştirilmelidir. Özellikle AWS SDK yeteneklerini barındıran bundle-2.20.18.jar (443MB) dosyasının eksiksizliği kritik başarı faktörüdür.

5. RAG Pipeline: Verinin Bilgiye Dönüşüm Süreci

Ham dokümanın semantik bir zekaya dönüşmesi, hassas parametre optimizasyonları gerektiren bir mühendislik sürecidir.

• Chunking Stratejisi: 200 karakterlik parça boyutu ve 50 karakterlik örtüşme (overlap) kullanılır. Bu sayede hem bağlam (context) korunur hem de semantik arama için gerekli hassasiyet sağlanır.
• Embedding Katmanı: Performans/maliyet dengesi için all-MiniLM-L6-v2 modeli tercih edilmiştir.
• Benchmark: CPU üzerinde saniyede ~500 cümle işleme kapasitesi.
• Boyut Karşılaştırması: 384D (Hızlı/CPU dostu), 768D (Dengeli), 1536D (En yüksek kalite - OpenAI standardı). Mevcut sistem 384D ile kurumsal hız ihtiyacını optimize eder.
• Vektör Depolama (Qdrant): Üretilen vektörler Qdrant üzerinde saklanırken, Iceberg üzerindeki metadata ile eşleşen id yapıları kullanılır. Bu, hibrit arama (SQL + Vektör) için temel oluşturur.

6. Sorun Giderme ve Operasyonel "Battle Scars"

Gerçek dünya uygulamalarında karşılaşılan engeller, sistemin dayanıklılığını artırmak için birer fırsattır.

Kritik Sorun-Çözüm Matrisi

7. Sonuç ve Gelecek Vizyon (Roadmap)

Bu proje, klasik RAG uygulamalarının ötesine geçerek kurumsal veri platformu ile yapay zekâyı bütünleştiren üretim seviyesi bir mühendislik mimarisi ortaya koymaktadır. Sistem yalnızca dokümanlardan cevap üreten bir chatbot değildir; veri alımından saklamaya, versiyonlamadan denetlenebilirliğe kadar tüm yaşam döngüsünü yöneten bütüncül bir Big Data altyapısıdır.

Apache Iceberg’in sunduğu ACID transaction garantileri, time-travel yetenekleri ve schema evolution desteği sayesinde sistem; veri bozulmalarına, hatalı yüklemelere ve operasyonel risklere karşı yüksek dayanıklılık kazanmıştır. Project Nessie entegrasyonu ise kurumsal veri yönetimine yazılım mühendisliğinde kullanılan branch, test ve geri dönüş (rollback) pratiklerini kazandırarak RAG mimarisini gerçek anlamda kontrol edilebilir hale getirmiştir.

Bu yaklaşım sayesinde:

• AI yanıtlarının hangi veri sürümünden üretildiği izlenebilir
• Hatalı veri senaryoları saniyeler içinde geri alınabilir
• Denetim süreçleri (audit & compliance) teknik olarak kanıtlanabilir
• RAG sistemleri ilk kez kurumsal veri platformu standartlarına ulaşır

Bu mimari, prototip yaklaşımını geride bırakarak kurumsal ölçekte yüksek hacimli veriler üzerinde güvenilirlik, ölçeklenebilirlik ve sürdürülebilirlik sağlayan tam anlamıyla üretime hazır bir AI veri platformu sunmaktadır.

Kaynakça (References)

1. Apache Iceberg Community. Apache Iceberg Documentation — High-performance table format for huge analytic datasets.
   https://iceberg.apache.org
2. Project Nessie. Transactional Catalog for Data Lakes — Git-like version control for data.
   https://projectnessie.org
3. Apache Spark Community. Apache Spark — Unified Analytics Engine for Big Data Processing.
   https://spark.apache.org
4. Trino Community. Trino — Distributed SQL Query Engine for Data Lake Analytics.
   https://trino.io
5. MinIO Inc. MinIO High Performance Object Storage for AI & Data Lake Workloads.
   https://min.io
6. Qdrant Team. Qdrant Vector Database — High-performance similarity search engine.
   https://qdrant.tech
7. OpenAI. Retrieval-Augmented Generation (RAG) patterns for large language models.
   https://platform.openai.com/docs
8. Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Facebook AI Research.
   https://arxiv.org/abs/2005.11401
9. AWS Architecture Blog. Modern Data Lake Architecture with Iceberg, Spark, and Trino.

Projemin linki

Github Profile : https://github.com/Sulecs1/data_engineer_for_LLM

Veri Mimarisi Hakkında Bildiğinizi Sandığınız Her Şeyi Unutun: Modern Data Engineer’ların Uyguladığı 5 Temel Prensip

Veri mimarisi denince akla genellikle karmaşık şemalar, katı kurallar ve değişmez, büyük planlar gelir. Birçok organizasyon, veri dünyasını bu şekilde kontrol altına alabileceğine inanır. Ancak bu yaklaşım, günümüzün hızla değişen teknoloji ve iş dünyasında başarısızlığa mahkumdur. Statik planlar, değişimin hızına ayak uyduramaz ve kısa sürede inovasyonun önünde birer engele dönüşür.

Bu yazı, o katı planların ve fildişi kulelerden verilen kararların ötesine geçiyor. Bu zihniyet değişikliğinin sadece teknik bir tercih olmadığını, aynı zamanda ekipleri birer kapı bekçisinden yenilikçi güçlere dönüştüren insani bir felsefe olduğunu göreceğiz. En başarılı ve dayanıklı veri mimarilerinin temelini oluşturan, çoğu zaman şaşırtıcı ve karşı-sezgisel olan temel prensipleri ortaya çıkaracak. Eğer mimarinin sadece çizim yapmaktan ibaret olduğunu düşünüyorsanız, bildiklerinizi unutmaya hazır olun.

1. Mükemmellik Değil, Geri Alınabilirlik Peşinde Koşun

Mimarideki en önemli hedef, değiştirilemez, “mükemmel” ve son hali verilmiş bir sistem kurmak değildir. Aksine, en değerli hedef esnek, değişime açık ve geri alınabilir kararlar vermektir.

Amazon’un kurucusu Jeff Bezos, kararları “tek yönlü kapı” ve “iki yönlü kapı” olarak ikiye ayırır. Tek yönlü kapılar, geri alınması neredeyse imkansız olan, sonuçları ağır kararlardır. İki yönlü kapılar ise kolayca geri alınabilen, denemeye ve öğrenmeye olanak tanıyan kararlardır. İyi bir mimari, mümkün olduğunca “iki yönlü kapı” kararları alarak riskleri azaltır ve organizasyonun daha hızlı deneme yapmasına, veriye dayalı dersler çıkarmasına ve sürekli olarak kendini geliştirmesine olanak tanır.

Bunun pratikteki anlamı şudur: Bu yaklaşım, sadece teknik bir esneklik sağlamanın ötesinde, organizasyonların büyüme eğilimiyle birlikte ortaya çıkan doğal “kurumsal katılaşma” eğilimine karşı stratejik bir panzehirdir. Değişen iş gereksinimleri ve teknoloji karşısında katı bir mimari bir ayak bağına dönüşürken, geri alınabilir kararlar üzerine kurulu bir mimari, organizasyona muazzam bir rekabet avantajı sağlar.

Martin Fowler’ın da belirttiği gibi, bu fikir mimarinin özünü yeniden tanımlar:

“Bir mimarın en önemli görevlerinden biri, yazılım tasarımlarındaki geri döndürülemezliği ortadan kaldırmanın yollarını bularak mimariyi ortadan kaldırmaktır.”

2. “En İyi” Diye Bir Şey Yoktur, Sadece “En Az Kötü” Vardır

Teknoloji dünyasında sihirli bir “en iyi” çözüm arayışı yaygındır. Ancak bir stratejist olarak bilmeniz gereken gerçek şu ki, her mimari karar kaçınılmaz olarak bir dizi ödünleşmeyi (trade-off) beraberinde getirir. Mimarın görevi, bu ödünleşmeler arasında en uygun dengeyi bulmaktır.

Mühendislik, ister fiziksel ister dijital olsun, kısıtlamalarla çalışır. Gecikme süresi ve güvenilirlik gibi fiziksel limitlerin yanı sıra bütçe, zaman, mevcut yetenekler ve sistem karmaşıklığı gibi fiziksel olmayan kısıtlamalar da vardır. Bu pragmatik düşünce tarzı, ekipleri gerçekçi olmayan mükemmellik hedeflerinden korur. “En iyi” çözüm peşinde koşmak yerine, projenin gerçek ihtiyaçlarına ve kısıtlarına odaklanarak daha sürdürülebilir ve uygulanabilir çözümler üretilmesini sağlar. Bu, sihirli düşünceden kaçınarak sağlam mühendislik yapmaktır.

Yazılım mimarisi üzerine temel eserlerden birinin yazarları olan Mark Richards ve Neal Ford bu gerçeği çarpıcı bir şekilde özetler:

“Asla en iyi mimariyi hedeflemeyin, bunun yerine en az kötü mimariyi hedefleyin.”

3. Mimarlık Liderliktir, Diktatörlük Değil

Modern veri mimarının rolü, “fildişi kulesinden” teknolojileri dayatan bir diktatör olmaktan çıkmıştır. Artık mimar, ekibe mentorluk yapan, onların yeteneklerini geliştiren ve ortak hedeflere ulaşmayı kolaylaştıran bir liderdir.

Bu değişim, geçmişteki “komuta-kontrol” yaklaşımının başarısızlıklarına doğrudan bir yanıttır. Eskiden mimarların tüm ekipleri tek bir veritabanı teknolojisini kullanmaya zorladığı, inovasyonu boğan ve darboğazlar yaratan tek tipçi kararlar artık geçerliliğini yitirmiştir. İdeal bir mimar, derin teknik yetkinliğini; ekiplerin seviyesini yükseltmek, ortak bileşenleri akıllıca seçerek yeniden kullanımı teşvik etmek ve en iyi uygulamaları öğreterek kaliteyi artırmak için kullanır. Bu liderlik yaklaşımı, ekiplere kendi alanlarında en uygun araçları seçme özerkliği tanır ve bu da inovasyonu tetikler. Mimarın etkisi, verdiği kararlardan çok, geliştirdiği ekibin yetenekleriyle ölçülür.

Martin Fowler, ideal mimar arketipini Architectus Oryzus olarak tanımlarken bu liderlik rolünü mükemmel bir şekilde açıklar:

“Architectus Oryzus’un en önemli faaliyeti, geliştirme ekibine mentorluk yapmak, onların seviyesini yükselterek daha karmaşık konuları üstlenmelerini sağlamaktır. Geliştirme ekibinin yeteneğini artırmak, bir mimara tek karar verici olmaktan ve dolayısıyla mimari bir darboğaz olma riskini taşımaktan çok daha büyük bir etki gücü verir.”

4. Başarısızlık Bir Hata Değil, Bir Özelliktir

Dayanıklı ve sağlam sistemler inşa etmenin yolu, her şeyin her zaman mükemmel çalışacağını varsaymak değildir. Tam tersine, başarısızlığın kaçınılmaz olduğunu kabul edip, sistemleri bu gerçeğe göre tasarlamaktır. Modern donanımlar ne kadar güvenilir olursa olsun, yeterli zaman geçtiğinde her bileşen eninde sonunda arızalanacaktır.

İyi bir mimari, başarısızlık senaryolarını en başından planlar.

Bu planlama,

Kullanılabilirlik (Availability) gibi bir sistemin çalışır durumda olduğu sürenin yüzdesini;

Güvenilirlik (Reliability) gibi bir sistemin belirli bir süre boyunca hedeflenen işlevi doğru bir şekilde yerine getirme olasılığını;

Kurtarma Süresi Hedefi (RTO) gibi bir kesintide sistemin ne kadar sürede ayağa kalkması gerektiğini ;

Kurtarma Noktası Hedefi (RPO) gibi ne kadarlık veri kaybının kabul edilebilir olduğunu hesaba katmalıdır.

Başarısızlığı bir özellik olarak kabul edip planlamak, sistemleri daha dayanıklı hale getirir ve en önemlisi, iş sürekliliğini güvence altına alır.

Amazon CTO’su Werner Vogels’in bu prensibi ölümsüzleştiren ikonik sözü her şeyi özetliyor:

“Her şey, her zaman başarısız olur.”

5. Rolünüz Genişledi: Artık Güvenlik ve Finanstan da Sorumlusunuz

Bulut teknolojilerinin yükselişiyle birlikte veri mühendisinin ve mimarının sorumluluk alanı dramatik bir şekilde genişledi. Artık görevimiz sadece veri taşımak ve işlemek değil; inşa ettiğimiz sistemlerin güvenliğinden ve maliyetinden de doğrudan sorumluyuz.

Bu genişleme iki ana alanda kendini gösterir:

• Güvenlik: Geleneksel “sağlamlaştırılmış çevre” güvenlik modeli artık yetersiz kalıyor. Bu modelin zayıflığını anlamak için 1996 yapımı Görevimiz Tehlike (Mission Impossible) filmini düşünün. Ethan Hunt, CIA’in son derece güvenli bir odasına sızar ve içeri girdikten sonra, verileri nispeten kolayca dışarı çıkarabilir. Bu, içeriden gelen tehditlere karşı çevresel güvenliğin ne kadar kırılgan olduğunu gösterir. Bulutta ise “paylaşılan sorumluluk modeli” geçerlidir: Bulut sağlayıcısı altyapının güvenliğinden sorumluyken, kullanıcı olarak bizler o altyapının içindeki veriyi, uygulamaları ve erişim kontrollerini güvence altına almaktan sorumluyuz. Bu nedenle, her veri mühendisi kendini aynı zamanda bir güvenlik mühendisi olarak görmelidir.

• FinOps: Bulutun “kullandığın kadar öde” modeli, maliyet yönetimini tek seferlik bir bütçelemeden çıkarıp sürekli, dinamik bir sürece dönüştürmüştür. FinOps, mühendislik ve finans ekiplerini bir araya getirerek veri odaklı harcama kararları almalarını sağlayan kültürel bir pratiktir. Bu sadece bütçe takibi demek değildir; aynı zamanda sistemleri “maliyet saldırılarına” karşı korumak anlamına da gelir. Tıpkı bir DDoS saldırısının bir web sitesini erişilmez kılması gibi, S3 bucket’larından yapılan aşırı indirmeler de maliyetleri fırlatarak küçük bir startup’ı iflasla tehdit edebilir. Seçtiğiniz her servisin anlık bir finansal etkisi vardır ve bunu yönetmek görevinizin bir parçasıdır.

Bu rol genişlemesi, modern bir veri profesyoneli olmanın ne anlama geldiğini yeniden tanımlıyor. Artık verdiğimiz kararlar sadece teknik performansı değil, aynı zamanda güvenlik risklerini ve bütçe üzerindeki etkisini de doğrudan şekillendiriyor.

Sonuç

Gördüğünüz gibi, modern veri mimarisi katı ve değişmez planlar çizmekten çok daha fazlasıdır. Temelinde esneklik, gerçekçi bir pragmatizm, mentorluğa dayalı bir liderlik ve sürekli genişleyen bir sorumluluk anlayışı yatar. Bu prensipler, sadece daha iyi sistemler kurmanızı sağlamakla kalmaz, aynı zamanda organizasyonunuzun gelecekteki zorluklara ve fırsatlara daha hazır olmasına yardımcı olur.

Şimdi durup düşünme zamanı:

“Bugün, kendi organizasyonunuzdaki hangi ‘tek yönlü kapı’ kararını bir ‘iki yönlü kapı’ fırsatına çevirebilirsiniz?”

Teşekkürler :)

source:

Data Engineering Design Patterns

Fundamentals of Data Engineering Book

https://www.linkedin.com/in/suleakcay/

Veri Mühendisi için Yol Rehberi

1. Sistem Tasarımı ve Altyapı Orkestrasyonunun Kaosu

Modern yazılım dünyasında bir sistem inşa ederken asıl zorluk artık sadece algoritma yazmak değil, devasa bir veri yığınının içinde kaybolmadan doğru altyapı orkestrasyonunu kurgulamaktır. Birçok uygulama, ana darboğazın hesaplama gücü (compute-intensive) değil; verinin hacmi, karmaşıklığı ve değişkenliği olduğu “veri yoğun” (data-intensive) sistemler kategorisine girer.

Bugün bir Kıdemli Veri mühendisi için mesele, onlarca veritabanı ve işleme aracı arasından birini seçmek değil, bu araçların bir arada nasıl bir ekosistem oluşturacağını stratejik olarak belirlemektir. Bu yazı, “Büyük Veri” felsefesinin yarattığı illüzyonları dağıtacak ve modern mimarinin en etkili, bazen de sezgilere aykırı derslerini sunacaktır.

2. Mükemmel Çözüm Yoktur, Sadece Ödünler (Trade-offs) Vardır

Teknoloji seçimlerinde “en iyi” arayışı, genellikle mimari bir başarısızlıkla sonuçlanır. Veri mimarisinde gümüş kurşun yoktur; sadece bilinçli ödünler vardır.

“Çözüm yok, sadece ödünler var… Elde edebileceğiniz en iyi ödünü vermeye çalışıyorsunuz ve umabileceğiniz tek şey de bu.” — Thomas Sowell

Veri sistemleri tasarlanırken bu felsefe her kararın merkezinde yer almalıdır. Mühendislik dünyasında polyglot persistence (çok dilli süreklilik) kavramının yükselmesi, tek bir veritabanının her sorunu çözemeyeceğinin kanıtıdır. Mimari karar verme süreci, teknik bir üstünlük yarışından ziyade, uygulamanın özel ihtiyaçlarına (hız, tutarlılık, ölçeklenebilirlik) en uygun “ödünler kümesini” bulma sanatıdır. Unutmayın: Veri mimarisinde sihirli bir değnek yoktur, sadece rasyonel tavizler vardır.

3. Operasyonel ve Analitik Dünyaların Stratejik Ayrımı

Veri sistemlerinde iki ana kutup vardır: Operasyonel (OLTP) ve Analitik (OLAP). Bu iki dünyanın ayrılması teknik bir tercih değil, operasyonel bir zorunluluktur.

• OLTP (Çevrimiçi İşlem İşleme): Genellikle Point Query (anahtar kullanarak tek bir kayda erişim) üzerine kuruludur. Düşük gecikme süresiyle bireysel kayıtları okur ve günceller.

• OLAP (Çevrimiçi Analitik İşleme): Milyonlarca satır üzerinde Aggregation (toplama, ortalama, sayma) işlemleri gerçekleştirir.

Bir iş analistinin çalıştırdığı ağır bir SQL sorgusu, üretim ortamındaki (production) bir müşterinin sipariş işlemini yavaşlatmamalıdır. Bu performans çakışmasını önlemek ve yüzlerce mikroservisin içine hapsolmuş Veri Siloları (Data Silos) sorununu çözmek için Veri Ambarları (Data Warehouse) doğmuştur. ETL (Çıkarma-Dönüştürme-Yükleme) süreçleri, operasyonel sistemlerdeki veriyi temizleyip analitik amaçlar için optimize edilmiş ayrı bir alana taşıyarak kurumsal kararlar için “tek bir doğruluk kaynağı” oluşturur.

4. Bulut Devrimi: Depolama ve Hesaplamanın Boşanması

Geleneksel mimarilerdeki yerel RAID yapıları ve disk bağımlılığı, yerini bulut tabanlı (cloud-native) sistemlerin getirdiği en büyük devrime bıraktı: Depolama (storage) ve hesaplamanın (compute) ayrılması (decoupling).

Geleneksel sistemlerde Amazon EBS gibi “Sanal Blok Depolama” (Virtual Block Storage) yapıları diskleri taklit etmeye çalışırken ağ gecikmesi (network latency) gibi sorunlar yaratır. Oysa Amazon S3 gibi Nesne Depolama (Object Storage) servisleri, fiziksel makine arızalarını soyutlayan ve veriyi otomatik olarak dağıtan tamamen farklı bir yaklaşımdır. Bu ayrım sayesinde:

• Esneklik ve Elastisite: Veri miktarınız artsa bile sadece depolama için ödeme yaparsınız; işlemci gücünü sadece sorgu anında devreye alarak sorgu başına ödeme (pay-per-query) modeline geçebilirsiniz.

• Çoklu Kiracılık (Multi-tenancy): Aynı altyapı üzerinde kaynakları dinamik olarak yönetebilir ve maliyet optimizasyonunu en üst seviyeye çıkarabilirsiniz.

5. Prematüre Dağıtımdan Kaçının: Tek Düğümün (Single-Node) Dönüşü

Günümüzde birçok ekip, verileri henüz tek bir sunucunun RAM kapasitesine bile ulaşmamışken “Google ölçeğinde” dağıtık sistemler kurmaya çalışarak gereksiz mühendislik (over-engineering) tuzağına düşüyor.

Dağıtık sistemler ağ gecikmesi, karmaşık arıza olasılıkları ve ciddi yönetim yükü demektir. Oysa modern donanımlar artık inanılmaz derecede güçlüdür. Modern bir CPU ve yüksek kapasiteli bellekler ile terabaytlarca veri tek bir makinede işlenebilir. DuckDB, SQLite veya modern grafik veritabanı KùzuDB gibi tek düğümlü çözümler; birçok iş yükü için dağıtık bir kümeden (cluster) daha hızlı, daha ucuz ve daha stabildir. Ağ üzerinden veri aktarmanın maliyeti, yerel disk ve işlemci arasındaki iletişimden her zaman daha yüksektir.

“Büyük Veri”den “Veri Tasarrufuna”: Bir Risk Faktörü Olarak Veri

Yıllarca “ne bulursan sakla” diyen Büyük Veri mantrası, yerini yasal ve etik bir zorunluluğa bıraktı. GDPR ve CCPA gibi düzenlemelerle birlikte veri, sadece teknik bir varlık (asset) değil, aynı zamanda bir yükümlülük (liability) haline gelmiştir.

Almanca “Datensparsamkeit” (Veri Minimizasyonu) kavramı, modern mimarinin yeni anayasasıdır. Veriyi saklamak sadece bir depolama maliyeti değil; olası bir siber saldırıda güvenlik riski, yasal süreçlerde ise tazminat yüküdür. Değiştirilemez (immutable) loglar üzerine kurulu mimariler, yasal bir zorunluluk olan “Unutulma Hakkı” (Right to be Forgotten) ile doğrudan çatışır. Bu nedenle mimarlar, hangi verinin gerçekten saklanmaya değer olduğunu sorgulamalıdır. Veri minimizasyonu, modern sistem tasarımında bir kısıt değil, bir güvenlik stratejisidir.

Sonuç: Sosyoteknik Bir Disiplin Olarak Mimari

Modern veri mimarisi artık sadece kod ve altyapıdan ibaret değildir; hukuk, etik ve operasyonel ödünlerin dengelendiği sosyoteknik bir disiplindir. Bir sistem tasarlarken sadece teknik performansı değil, verinin yaşam döngüsünü ve toplumsal etkilerini de hesaba katmak kıdemli bir stratejistin temel görevidir.

Mimarınızın başarısını ölçmek için şu kritik soruyu sorun:

“Sisteminizdeki veriler birer varlık (asset) mı, yoksa birer yükümlülük (liability) mü?”

Kaynakça :

https://www.linkedin.com/in/suleakcay/

• Review — Is Designing Data intensive Applications by Martin Kleppman Worth it?
• Designing Data-Intensive Applications - Book Review + Notes

1. Milyon Dolarlık Kararların Temelindeki Çatlak

Hayal edin: Şirketinizin yönetim kurulu, önlerine gelen göz alıcı bir dashboard’daki verilere dayanarak 10 milyon dolarlık kritik bir yatırım kararı alıyor. Ancak aylar sonra, o kararın temelindeki “büyüme” verisinin aslında mükerrer kayıtlardan veya yanlış işlenen bir veri kaynağından beslendiği ortaya çıkıyor. Yanlış veri; yanlış analizlere, yanlış analizler ise telafisi imkansız mali ve prestij kayıplarına yol açar.

Veri kalitesi (Data Quality), modern bir veri mimarisinde sadece teknik bir detay değil; verinin doğru, eksiksiz, tutarlı, zamanında ve kullanılabilir olduğunu garanti altına alan bir mühendislik disiplinidir. Bugünün dünyasında sormamız gereken asıl soru şudur: Veri gerçekten iş kararlarında kullanılabilir mi, yoksa sadece bir yığın mı tutuyorsunuz?

2. “Null Check” Sadece Buzdağının Görünmeyen %5’idir

Sektördeki en büyük yanılgılardan biri, veri kalitesini sadece “boş değer” (null) kontrolü yapmaktan ibaret sanmaktır. Oysa kıdemli bir veri mühendisi için null check, toplam kalite yönetiminin yalnızca %5’ini oluşturur. Manuel olarak yapılan kontroller ise büyüme aşamasındaki bir şirket için “çöp” hükmündedir; ölçeklenemez ve güven veremez.

Gerçek bir veri kalitesi stratejisi; verinin iş kuralları, teknik standartlar ve zaman boyutu arasındaki güvenilirliğini sağlayan, yaşayan bir sistemdir.

Data Quality = “Veri gerçekten iş kararlarında kullanılabilir mi?” sorusunun cevabı

3. Kaostan Altın Seviyeye: Veri Kalitesi Olgunluk Seviyeleri

Bir organizasyonun veriye ne kadar güvenebileceği, bulunduğu olgunluk seviyesiyle doğru orantılıdır. Büyük şirketlerin izlediği bu 6 seviyeli hiyerarşide siz neredesiniz?

• Level 0 — Kaos: Hiçbir kontrolün olmadığı, sadece “veri bir şekilde gelmiş mi?” diye bakılan seviye. Startup’ların %90’ı burada başlar ve günleri “yangın söndürmekle” geçer.

• Level 1 — Temel Teknik Kontroller: Null check, tip kontrolü ve satır sayısının izlendiği, Primary Key (PK) bazlı temel kontrollerin başladığı aşama.

• Level 2 — Şema ve Tutarlılık (Schema & Consistency): Şema değişimlerinin (Schema Drift) izlendiği, Iceberg veya Delta metadata seviyesinde versiyonlamanın yapıldığı, dün ile bugün arasındaki yapısal uyumun sorgulandığı seviye.

• Level 3 — İş Kuralları (Altın Seviye): Veri mühendisi ile iş biriminin ortaklığıyla kuralların yazıldığı en kritik aşamadır. Örneğin; “Sipariş tutarı negatif olamaz”, “Sipariş durumu sadece CREATED, SHIPPED veya CANCELLED olabilir” gibi mantıksal kontroller burada devreye girer.

• Level 4 — İstatistiksel Analiz ve Anomali Tespiti: Basit kuralların ötesine geçilir. Makine öğrenmesi (ML) ve istatistiksel modellerle trend kırılmaları izlenir. “Son 30 günün ortalaması 100 bin iken bugün neden 10 bin?” sorusu otomatik alarmları tetikler.

• Level 5 — Modern Zirve (Data Contracts): Veri üreten (Producer) ve tüketen (Consumer) taraflar arasında kesin sözleşmelerin yapıldığı seviyedir. Great Expectations, Soda veya Monte Carlo gibi araçlarla veri kalitesi bir CI/CD disiplinine ve kurumsal bir “ürüne” dönüşür.

4. Devlerin Oyun Planı: Uber, Amazon ve Netflix Nasıl Başarıyor?

Veri ölçeği devasa boyutlara ulaştığında, bu şirketler statik kontrolleri tamamen terk ederek “Veri Gözlemlenebilirliği” (Data Observability) yaklaşımına geçerler.

• Uber: Geliştirdikleri “Data Quality Monitor” (DQM) ile binlerce tabloyu istatistiksel modellerle izliyorlar. Basit kurallar yerine geçmiş trendlere dayalı “kalite puanları” (DQ Score) üreterek sorunları henüz raporlara yansımadan tespit ediyorlar.

• Amazon: ML destekli sistemleriyle sadece anomalileri tahmin etmekle kalmıyor, aynı zamanda büyük ölçekli veri kümeleri için otomatik olarak anlamlı doğrulama testleri oluşturuyorlar. Amazon’da kalite, kural tabanlı sistemlerden model tabanlı dinamik sistemlere evrilmiş durumda.

• Netflix: Odak noktası pipeline sağlığı ve sistem davranışıdır. Veri kalitesini sistem performansıyla bir bütün olarak ele alıp, davranış odaklı bir gözlemlenebilirlik altyapısı kurarak “veri platformuna duyulan güveni” bir KPI olarak yönetiyorlar.

Bu devlerin ortak kuralı basittir: Kalite kontrolünden geçmeyen veri, asla rapora veya üretim ortamına sızamaz.

5. Sessiz Veri Bozulması (Silent Data Corruption) Tehlikesi

Bir veri mühendisinin en büyük kabusu, her şey yolunda görünürken verinin derinden bozulması ve bu hatanın aylar sonra fark edilmesidir. “Sessiz Veri Bozulması” riskini yönetmek için bazı kontroller kritik (critical) olarak işaretlenmelidir.

Özellikle Primary Key (PK) kontrolleri (Null veya Duplicate kontrolü) bir tablonun tüm bütünlüğünü temsil eder. Eğer bir PK null geliyorsa veya mükerrer kayıt oluşmuşsa, o veri seti artık tamamen güvenilmezdir. Modern bir mimaride bu tür bir hata tespit edildiği an, bozuk verinin “Gold” (Yayın) katmanına sızmasını engellemek için süreç derhal durdurulmalıdır (stop-pipeline). Hatalı veriyi raporlara taşımaya devam etmek, bir şirketin en büyük sermayesi olan “veriye güveni” kalıcı olarak zedelemektir.

Sonuç: Veriye Güvenmek Bir Tercih mi, Bir Zorunluluk mu?

Günümüzde veri platformlarına duyulan güven, bir şirketin bilançosunda görünmeyen en büyük sermayesidir. Veri kalitesi sadece teknik bir kontrol listesi değil; organizasyonun tamamını yanlış kararlardan koruyan bir kalkan, başlı başına bir veri ürünüdür. Otomatikleştirilmiş, iş kurallarıyla harmanlanmış ve sürekli izlenen bir yapı kurmak artık bir lüks değil, rekabetin ön koşuludur.

Şu soruyu kendinize sormanızı istiyorum:

Şu an kullandığınız en kritik dashboard’un altındaki veriye gerçekten %100 güveniyor musunuz, yoksa sadece öyle olduğunu mu umuyorsunuz?

Teşekkürler :)

https://www.linkedin.com/in/suleakcay/

kaynaklar:

• 12 Best Data Quality Tools for 2025
• Detailed Explanation of Data Quality

https://medium.com/data-science/what-is-data-quality-f2c0274a6404

Herhangi bir veri mühendisine iş akışını çizmesini isterseniz, size muhtemelen oklarla birbirine bağlı düzgün kutucuklardan oluşan bir diyagram çizecektir. Ancak hepimiz biliriz ki gerçek, bundan çok daha karmaşıktır. Gece 3'te bir pipeline çöktüğünde, bunun nedeni nadiren o düzgün kutucuklardan birinin bozulmasıdır; asıl sebep, verinin karmaşık ve döngüsel gerçeğinin kendini dayatmasıdır.

Bu yazıda, veri mühendisliği yaşam döngüsü hakkındaki yaygın varsayımlara meydan okuyan beş şaşırtıcı ve etkili gerçeği ortaya çıkaracağız. Bu gerçekler, modern veri sistemlerinin nasıl çalıştığını ve başarılı veri mühendislerinin neden sadece araçları değil, aynı zamanda bu işin temelindeki prensipleri de anlaması gerektiğini gösteriyor.

1. Veri Yaşam Döngüsü Düz Bir Çizgi Değil, Dağınık Bir Döngüdür

Veri mühendisliği yaşam döngüsü genellikle

Üretim -> Depolama -> Alım -> Dönüşüm -> Sunum

şeklinde düzenli ve doğrusal bir akış olarak tasvir edilir. Bu model, süreci anlamak için yararlı bir başlangıç noktası olsa da, sahadaki gerçekliği tam olarak yansıtmaz.

Gerçekte, orta aşamalar olan depolama, alım ve dönüşüm biraz “dağınık” olabilir. Bu aşamalar kendilerini tekrar edebilir, sırasız gerçekleşebilir veya beklenmedik şekillerde iç içe geçebilir. Bu zihniyet, sizi kırılgan pipeline’lar inşa etmekten kurtarır. İdempotent görevler ve verinin sırasız gelmesini tolere edebilen sistemler kurmanızı teşvik eder ki bu bir istisna değil, gerçek dünyanın bir senaryosudur.

2. Depolama Bir Adım Değil, Üzerinde Yürüdüğünüz Zemindir

Depolama, genellikle yaşam döngüsündeki ayrı bir aşama olarak görülür; verinin bir sonraki adıma geçmeden önce durduğu bir istasyon gibidir. Ancak bu bakış açısı eksiktir. Depolamayı, yaşam döngüsünün diğer tüm aşamalarını destekleyen temel bir zemin olarak görmek gerekir. Zira “veri baştan sona akarken yaşam döngüsü boyunca depolama gerçekleşir.”

Bu perspektif değişikliği kritik öneme sahiptir, çünkü depolama teknolojisi seçimi, veri alımından dönüşüm yeteneklerine ve verinin nihai olarak nasıl sunulup kullanılacağına kadar her şeyi etkiler. Modern bulut veri ambarları gibi sistemler, geleneksel sınırları bulanıklaştırarak aynı anda veri depolayabilir, işleyebilir ve sunabilir.

3. “Ters ETL”: Artık Bir Antipattern Değil, Modern Bir Gereklilik

Ters ETL (Reverse ETL), yaşam döngüsünün çıkış tarafından işlenmiş veriyi alıp CRM veya SaaS platformları gibi kaynak sistemlere geri besleme sürecidir. Bu akış bir zamanlar bir “antipattern” olarak görülüyordu ve konuşulmasından pek hoşlanılmayan bir pratikti.

Ancak bugün, bu süreç faydalı ve genellikle gerekli bir akış olarak benimsenmektedir. Örneğin, bir veri ambarından hesaplanan metrikleri bir CRM sistemine veya Google Ads gibi bir reklam platformuna aktarmak, Ters ETL’in güçlü bir kullanım alanıdır. Bu gelişme, analitik ve makine öğrenmesi modellerinden elde edilen içgörülerin, insanların her gün kullandığı iş araçlarında doğrudan operasyonel hale getirilmesine olanak tanıyarak döngüyü kapatır ve veri ambarının değerini artırır.

4. Veri Mühendisliği “Kurumsallaşıyor”: Eski Kurallar Yeni Süper Gücünüz Oluyor

Veri araçları basitleştikçe ve soyutlama seviyesi arttıkça, veri mühendisliğinin odağı “değer zincirinde yukarıya” kaymaktadır. Modern araçlar düşük seviyeli karmaşıklığı soyutladığı için, odak noktamız da değişmek zorunda. Artık sadece altyapı yönetmiyoruz; veri kalitesinin, yönetişimin ve güvenin koruyucuları olmak için gereken zaman ve sorumluluğa sahibiz.

Veri yönetimi, veri yönetişimi, ana veri yönetimi (MDM) ve veri kalitesi gibi geleneksel “eski usul” kurumsal pratikler, artık her ölçekteki şirketteki veri mühendisleri için kritik hale gelmektedir.

“Eski olan yine yeni.”

Onlarca yıldır büyük kurumlarda uygulanan veri yönetimi prensipleri, şimdi bulut tabanlı modern veri yığınlarının temel taşı haline geliyor. Bu olgunlaşma, alanın sadece teknolojiye odaklanmaktan çıkıp veri varlıklarından güven, kalite ve uzun vadeli değer oluşturmaya yöneldiğini gösteren pozitif bir gelişmedir.

5. Gerçek Soru “Batch mi, Streaming mi?” Değil, “Neden Streaming?”

“Streaming-first” (öncelikli akış) yaklaşımı modern ve çekici olsa da, her zaman doğru seçim değildir. Ancak bu tartışmaya daha stratejik bir açıdan bakmak gerekir: uğraştığımız neredeyse tüm veriler doğası gereği akış halindedir ve yığın (batch) işleme, bu akışı büyük parçalar halinde ele almanın “özelleşmiş ve kullanışlı bir yoludur.”

Buradaki pratik tavsiye nettir: gerçek zamanlı akış (streaming) mimarisini, yalnızca daha basit bir yığın yaklaşımına kıyasla getireceği ek zaman, para, bakım, kesinti süresi ve fırsat maliyetini haklı çıkaran net bir iş senaryosu belirledikten sonra benimsemelisiniz. Bu, mühendisleri en yeni teknolojiyi sırf popüler olduğu için benimsemek yerine, pragmatik ve iş odaklı mimari kararlar almaya teşvik eden değerli bir derstir.

Sonuç

Bu gerçekler, modern veri mühendisliğinin artık katı süreçler yerine akışkan bir yaşam döngüsünü yönetmek olduğunu gösteriyor; burada depolama temel bir katmandır, operasyonel sistemlere geri besleme kritik bir döngüdür ve eski kurumsal bilgelik en büyük rekabet avantajımızdır. Güvenlik, yönetişim ve sağlam yazılım mühendisliği gibi temel prensipler bu yaklaşımı destekler.

Araçlar karmaşıklığı soyutlamaya devam ettikçe, şu soruyu düşünmekte fayda var: Yeni nesil büyük veri mühendislerini hangi yeni beceriler tanımlayacak?

Teşekkürler :)

kaynak:

Fundamentals of Data Engineering Book

https://www.linkedin.com/in/suleakcay/

Bu yazıda, veri mühendisliğinin bu derinliklerine inecek ve en tecrübeli profesyonelleri bile şaşırtabilecek birkaç önemli gerçeği ortaya çıkaracağız. Bu kavramlar, sadece teknik birer detay olmanın ötesinde, daha dayanıklı, ölçeklenebilir ve etkili veri sistemleri kurmanın anahtarını sunuyor.

1. En Büyük Risk: Kaynak Sistemlerin “Başkasının Sorunu” Olduğuna İnanmak

Veri mühendisleri arasında yaygın olan tehlikeli bir varsayım vardır: kaynak sistemlerin yönetimi ve sağlığı, kendi sorumluluk alanlarının dışındadır. Bu zihniyet, çoğu zaman başarısızlığa giden bir yoldur. Çünkü veri akışının ilerleyen aşamalarındaki tüm çalışmaların kalitesi ve başarısı, tamamen kaynağı anlamaya bağlıdır.

Bu noktada diplomasi, iletişim ve kaynak sistemleri yöneten yazılım mühendisleri ve uygulama geliştiricileriyle iş birliği yapmak, genellikle hafife alınan ancak kritik öneme sahip becerilerdir. Veri üreticileri ve tüketicileri arasındaki beklentileri yönetmek ve olası sorunları en başından önlemek için “veri sözleşmesi” (data contract) gibi resmi anlaşmalar yapmak, en iyi uygulamalardan biridir. Bu işbirliği, yalnızca riskleri azaltmakla kalmaz, aynı zamanda daha kaliteli veriye, daha başarılı sonuçlara ve nihayetinde daha iyi veri ürünlerine giden yolu açar.

Veri mühendisleri, kaynak sistemlere “başkasının sorunu” gibi davranma eğilimindedir — bunu yaparsanız başınız belaya girer! Kaynak sistemleri kötüye kullanan veri mühendisleri, üretim sistemi çöktüğünde kendilerine başka bir iş aramak zorunda kalabilirler.

2. “NoSQL” Devrimi Neredeyse Kazara İsimlendirildi

“NoSQL” terimi, kulağa resmi ve iyi tanımlanmış bir standart gibi gelse de aslında geleneksel ilişkisel modeli terk eden çok çeşitli veritabanları için kullanılan oldukça belirsiz bir şemsiye terimdir. Bu ismin kökeni ise veri dünyasındaki inovasyonun ne kadar organik ve plansız gelişebileceğinin en iyi örneklerinden biridir.

Terimin modern kullanımı, 2000'lerde Eric Evans tarafından popülerleştirilmiştir. Evans’ın anlattığına göre, bir meetup (toplantı) için isim aranırken IRC (İnternet Aktarmalı Sohbet) üzerinden “hiç düşünmeden” önerdiği birkaç isimden biri “NoSQL” idi. Bu rastgele öneri, kısa sürede tüm bir teknoloji kategorisinin adı haline geldi. Bu anekdot, veri alanındaki yeniliklerin genellikle katı bir şekilde planlanmak yerine, ihtiyaçlar doğrultusunda dağınık ve doğal bir şekilde geliştiğini gösterir. Bu ismin belirsizliği, başlangıçta bir eksiklik gibi görünse de, aslında alanın en büyük gücü haline geldi. İlişkisel olmayan her türlü veri depolama çözümüne kapı açarak doküman, graf, anahtar-değer ve zaman serisi gibi sayısız özel veritabanının doğmasına ve veri mimarilerinde bir “Kambriyen patlaması” yaşanmasına olanak tanıdı.

Johan [Oskarsson] ilk meetup fikrini ortaya attığında, aklında Büyük Veri ve doğrusal olarak ölçeklenebilir dağıtık sistemler var gibiydi, ancak isim o kadar belirsizdi ki, kelimenin tam anlamıyla veri depolayan ve bir RDBMS (İlişkisel Veritabanı Yönetim Sistemi) olmayan her şey için sunum başvurularına kapı açtı.

3. Kritik Fark: “Mesaj” Kaybolur, “Akış” Hatırlar

Teknik tartışmalarda “mesaj kuyruğu” (message queue) ve “olay akış platformu” (event-streaming platform) terimleri sık sık birbirinin yerine kullanılır, ancak bu ikisi arasında temel bir fark vardır. Bu farkı anlamak, doğru aracı doğru görev için seçmenin anahtarıdır.

Mesaj, bir yayıncıdan bir tüketiciye gönderilen tekil bir veri parçasıdır.

En temel özelliği şudur: mesaj teslim edilip onaylandıktan sonra kuyruktan kaldırılır. Bu, onu anlık ve geçici iletişim kanalları için ideal hale getirir. Örneğin, bir IoT cihazından gelen sıcaklık verisini işleyip bir eylemi tetiklemek için kullanılabilir.

Buna karşılık akış, olay kayıtlarının sıralı ve yalnızca sona ekleme (append-only) yapılabilen bir günlüğüdür (log). Onun en temel özelliği ise kayıtların uzun bir süre saklanmasıdır. Bu kalıcılık, tüketicilerin geçmişteki olayları yeniden oynatmasına (replay) veya zaman içindeki veriler üzerinde karmaşık analizler yapmasına olanak tanır. Akışlar, olayların bir geçmişini oluşturur ve bu geçmişin kendisi değerlidir.

Sonuç olarak, bu ayrım kritik öneme sahiptir. Eğer basit, geçici bir iletişim kanalına ihtiyacınız varsa mesaj kuyruğu yeterlidir. Ancak olayların dayanıklı ve analiz edilebilir bir geçmişini oluşturmak istiyorsanız, bir olay akış platformu doğru seçimdir.

4. Paradoks: Modern Veritabanları Neden Bazen “Tutarsız” Olacak Şekilde Tasarlanır?

Veritabanlarından geleneksel beklentimiz, her zaman mükemmel bir şekilde tutarlı olmalarıdır. İlişkisel veritabanlarının ACID (Atomicity, Consistency, Isolation, Durability — Atomiklik, Tutarlılık, İzolasyon, Dayanıklılık) garantileri bu beklentiyi karşılamak üzere tasarlanmıştır. Tutarlılık, bir veriye yapılan her okuma işleminin, o verinin en son yazılmış versiyonunu döndürmesini garanti eder.

Ancak birçok modern NoSQL veritabanı, bu katı tutarlılık kurallarını kasıtlı olarak esnetir. Bu yaklaşımın adı “nihai tutarlılık” (eventual consistency) olarak bilinir ve temelde büyük ölçekli dağıtık sistemlerin getirdiği zorluklara bir yanıttır. Verinin birden çok sunucuya veya coğrafi bölgeye yayıldığı bu tür sistemlerde, her bir kopyayı anlık olarak mükemmel bir şekilde senkronize tutmak neredeyse imkansız ve aşırı maliyetlidir. Nihai tutarlılık, bu imkansızlığa karşı tasarlanmış akıllıca bir ödünleşimdir.

Bunu bir hata olarak değil, bilinçli bir trade-off olarak düşünmek gerekir. Bilginin gerçek dünyada yayılmasına benzetilebilir: bir haberin herkese ulaşması zaman alır, ancak sonunda herkes aynı mesajı alır. Bu model, sosyal medya akışları veya anlık ve mükemmel tutarlılıktan ziyade ölçek ve erişilebilirliğin daha kritik olduğu IoT verileri gibi kullanım durumları için mükemmeldir. Nihai tutarlılık, sistemin genelinin yüksek performansta ve kesintisiz çalışmasını sağlar.

Sonuç: Veri Mühendisinin Gelişen Rolü

Bu örneklerin de gösterdiği gibi, veri mühendisliği artık veriyi bir yerden bir yere taşıyan basit bir “tesisatçılık” görevinin çok ötesine geçmiştir. Bu alan artık mimari ödünleşimlerin, farklı teknolojilerin inceliklerinin ve insan iş birliğinin derinlemesine anlaşılmasını gerektiriyor; hatta analitik sistemlerdeki veriyi tekrar operasyonel CRM sistemlerine besleyen “ters ETL” (reverse ETL) akışları gibi yeni köprüler kurmayı zorunlu kılıyor. Kaynak sistemlerin dinamiklerini anlamaktan, teknolojilerin arkasındaki felsefeyi kavramaya kadar, modern veri mühendisi hem bir teknoloji uzmanı hem de bir stratejist olmalıdır. Bu gerçekler, alanın ne kadar karmaşık ve heyecan verici bir hale geldiğinin kanıtıdır.

Öyleyse kendimize şu soruyu sormalıyız:

Otomasyon, veri taşıma gibi temel görevleri basitleştirdikçe, yeni neslin harika veri mühendislerini gerçekten ne gibi beceriler tanımlayacak?

Teşekkürler :)

Bir sonraki yazımda görüşmek üzere,

kaynak:

Fundamentals of Data Engineering Book

https://www.linkedin.com/in/suleakcay/

If you work in data or technology, you have probably noticed how often the term data engineering is mentioned today. In the past, it stayed in the shadow of data science, but now it has become a star on its own. However, many people are still confused about what data engineering really means and what a data engineer actually does. This field is often very different from what people imagine and includes many surprising facts. In this article, we look behind the scenes of data engineering and share five important truths. Let’s begin.

1. The “Big Data” Trend Is Over — The Focus Has Changed

In the mid-2010s, there was a popular buzzword in technology: Big Data. Companies invested heavily in complex tools like Hadoop to manage large amounts of data. Google Trends shows that interest in this term reached its peak at that time and then started to decline.

So, what changed? The answer is simple: simplicity. Companies moved away from complex and expensive systems and started to use simpler, managed, and easier solutions. Managing big data platforms required a lot of money and effort. Engineers spent too much time maintaining systems instead of creating value. Today, working with large data is much easier, so the term “big data” is no longer special. Big data engineers now simply call themselves data engineers. The main goal is no longer the size of data, but how to turn data into business value.

This idea is well described by a famous quote from Dan Ariely:

“Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.”

2. Data Scientists Spend 80% of Their Time Not Doing Data Science

Here is a surprising fact: data scientists spend 70–80% of their time not on machine learning or deep analysis, but on collecting, cleaning, and preparing data. It is like a chef spending most of the time cleaning the kitchen instead of cooking.

This situation is explained by Monica Rogati’s Data Science Hierarchy of Needs. At the bottom of this hierarchy are tasks like collecting, storing, moving, and transforming data. This is exactly where data engineering becomes important. Data engineers build and manage this foundation so data scientists can focus on more valuable work.

In an ideal setup, thanks to strong data engineering, data scientists can spend most of their time on analysis, experiments, and machine learning. This shows that behind impressive AI projects, there is usually invisible but critical data engineering work.

3. The Unexpected Comeback of SQL

At the beginning of the big data era, technologies like MapReduce became popular, and SQL was seen as an old language from the 1970s that would disappear. But the opposite happened. SQL made a strong comeback and became the common language of the data world again.

With tools like Spark SQL, Google BigQuery, and Snowflake, SQL is now very powerful and can handle huge datasets efficiently. Today, a good data engineer is expected to know SQL very well and use it in almost every stage of the data pipeline.

Of course, SQL is not the solution for everything. For example, Python is better for complex text processing. But when it comes to team productivity and simplicity, SQL is still essential.

4. The Most Important Skill May Not Be Technical

If you think a data engineer’s success depends only on skills like SQL, Python, or cloud tools, that is not completely true. Technical skills are necessary, but what really makes a difference is non-technical skills.

Communication, understanding business needs, working well with different teams, controlling costs, and continuous learning are just as important as writing code. A data engineer who does not understand business goals may build technically perfect systems that are not useful.

This idea is clearly explained in the following statement:

“The success of data teams often depends on communication with other stakeholders; success or failure is rarely about technology.”

5. The Road to AI Starts with a Strong Data Foundation

Many companies want to jump directly into machine learning and artificial intelligence. But this is like trying to build a skyscraper without a foundation. There is a concept called the Data Maturity Model. Companies should first build basic data systems, then scale them, and only after that use data to lead and innovate.

When companies skip these steps, AI projects often fail. They do not have high-quality data or a stable infrastructure to run models in production. This problem is so common that some professionals jokingly call themselves “survivors of data science.” This clearly shows that the path to AI always goes through strong and well-built data engineering.

Conclusion

As you can see, data engineering is much more than code and databases. The end of the big data hype, its role in unlocking the real power of data science, the comeback of SQL, the importance of soft skills, and its key role in AI success all show one thing clearly: data engineering is the invisible but essential foundation of the modern data world.

Thank you :)

source:

Fundamentals of Data Engineering Book

https://www.linkedin.com/in/suleakcay/

Birçok ekip belkide data lake yatırımı yaptı; altyapı kuruldu, veriler akmaya başladı.
Başlangıçta her şey yolundaydı: depolama maliyetleri düşüktü, veri hacmi büyüyordu ve esneklik yüksekti.

Ancak sistemler ölçeklendikçe şu sorular kaçınılmaz hale geldi:

• Aynı tabloya eşzamanlı yazımlar nasıl yönetilmeli?
• Hatalı bir yükleme sonrası güvenli bir geri dönüş mümkün mü?
• Veri büyüdükçe sorgu performansı neden öngörülemez hale geliyor?
• Fiziksel klasör yapısı mı tabloyu tanımlar, yoksa tablo soyut bir kavram mı olmalı?

Bu sorular, tekil problemler değil;
geleneksel Data Lake mimarilerinin büyüme ve üretim yüklerine dayanıklı olmadığının göstergesidir.

Lakehouse yaklaşımı ve Apache Iceberg, tam olarak bu kırılma noktasında ortaya çıkar:
Veri göllerine güvenilirlik, tutarlılık ve sürdürülebilirlik kazandırmak için.

Data Warehouse ve Data Lake Neden Tek Başına Yetmedi?

Data Warehouse dünyası düzenlidir.
ACID vardır, SQL güçlüdür, raporlar tutarlıdır.
Ama esnek değildir. Yeni veri türleri, büyük hacimler ve ML iş yükleri için pahalı ve yavaştır.

Data Lake ise özgürdür.
Ham veri saklanır, her şey mümkündür.
Ama kurallar yoktur. Zamanla dosya yığınları artar, performans düşer, güven kaybolur.

Gerçek ihtiyaç şuydu:

Warehouse güvenilirliği + Lake esnekliği

Bu ihtiyacın mimari karşılığı: Lakehouse

Iceberg Ne Yapar? Aslında Çok Basit Bir Şey

Apache Iceberg’in getirdiği temel fikir şudur:

Tabloyu dosya dizininden ayır.

Iceberg’de:

Tablo = metadata

Dosyalar = sadece veri parçaları

Gerçek tablo durumu = snapshot

Yani artık:

Klasör silinmez

Dosyaya “doğrudan” yazılmaz

Her değişiklik kontrollü ve izlenebilir olur

Bu tek karar, onlarca problemi aynı anda çözer.

Atomic Commit: “Ya Hep Ya Hiç”

Iceberg’de yazma işlemi şu şekilde çalışır:

Yeni veri dosyaları yazılır

Yeni manifest’ler oluşturulur

Yeni metadata dosyası hazırlanır

Tek bir atomic commit ile tablo güncellenir

Bu sayede:

Yarım yazılmış tablo olmaz

Concurrent write güvenlidir

Okuyanlar ya eskiyi ya yeniyi görür

Bu davranış, klasik Data Lake’lerde yoktur.

Okuma Performansı: Iceberg Neden Daha Hızlı?

Iceberg “her dosyaya bakmaz”.

Metadata katmanında:

Hangi dosyada hangi değerler var

Min / max istatistikleri

Partition bilgisi

saklanır.

Sonuç:

Gereksiz dosyalar hiç okunmaz

I/O dramatik şekilde azalır

Büyük tablolar bile hızlı sorgulanır

Bu, özellikle Spark / Trino / Flink gibi motorlarda fark edilir.

Gizli Bölümleme (Hidden Partitioning)

Iceberg’in en sevilen özelliklerinden biri.

Kullanıcı şunu yazar:

SELECT *
FROM events
WHERE event_ts BETWEEN '2025-05-01' AND '2025-05-07'

Ama arkada:

event_ts → day(event_ts)

Fiziksel partition otomatik bulunur

Kullanıcı partition mantığını bilmez

Avantaj:

Partition stratejisi değiştirilebilir

Eski sorgular bozulmaz

“Yanlış partition yazdık” kabusu biter

Schema Evolution: Kırılmadan Değişmek

Iceberg’de:

Kolon isimleri değil ID’ler takip edilir

Şema değişiklikleri metadata seviyesindedir

Yapılabilenler:

ADD COLUMN

DROP COLUMN

RENAME COLUMN

TYPE WIDENING (int → long)

Üstelik:

Veri yeniden yazılmadan

Okuyan işler bozulmadan

Bu, üretim ortamında büyük bir konfor sağlar.

Time Travel: Geçmişe Dönebilmek

Her commit bir snapshot demektir.

Iceberg sayesinde:

• “Dünkü tabloyu” okuyabilirsin
• Hatalı update’i geri alabilirsin
• ML eğitiminde geçmiş veriyle çalışabilirsin

Örnek:

SELECT *
FROM products
FOR TIMESTAMP AS OF '2025-05-20 10:00:00'

Bu özellik, sadece hata kurtarma değil:

Denetim

Test

Analiz

Güven

demektir.

Bakım Yoksa Performans da Yok

Iceberg “kur ve unut” değildir.

Düzenli olarak:

• Snapshot expire
• Orphan file temizliği
• Data compaction
• Manifest rewrite

yapılmalıdır.

Ama fark şu:

Bu işlemler kontrollü, güvenli ve standarttır.

Neden Apache Iceberg Önemli?

Apache Iceberg’in asıl değeri, yeni bir teknoloji sunmasından değil;
veri göllerinde yıllardır çözülemeyen problemleri kalıcı şekilde ele almasından gelir.

Iceberg ile birlikte:

• Veri artık dosya yığınları değil, kontrollü tablolar olarak yönetilir
• Okuma ve yazma işlemleri öngörülebilir ve güvenilir hale gelir
• Performans, veri büyüdükçe düşen değil ölçeklenen bir karakter kazanır
• Şema değişiklikleri riskli operasyonlar olmaktan çıkar
• Hatalar geri döndürülebilir, geçmiş her zaman erişilebilirdir

En kritik nokta ise şudur:

Iceberg, veri gölünü “saklanan veri alanı” olmaktan çıkarır,
üzerine güvenle analitik, raporlama ve makine öğrenmesi inşa edilebilen bir platforma dönüştürür

Bugün modern veri mimarilerinde aranan şey;
daha fazla araç değil, daha az belirsizliktir.

Apache Iceberg tam olarak bunu sağlar.

Veri platformlarını büyüten şey hacim değil,
üzerinde güvenle karar alınabilen veridir.

Kaynakça :

Kasun Indrasiri