1. GİRİŞ

Veri dönüşümü (data transformation), ham veriyi anlamlı, tutarlı ve analize hazır hale getiren merkezi bir faaliyettir. Veri platformları, veri bilim ekipleri ve iş analistleri için doğru dönüşümler güvenilir raporlar, etkin ML modelleri ve doğru işletme kararları sağlar. Bulut‑native altyapıların, gerçek zamanlı veri akışlarının ve ML uygulamalarının artmasıyla birlikte dönüşüm stratejileri de çeşitlenmiştir: batch ETL’den ELT’ye, monolitik transform job’lardan stream‑first, schema‑aware pipeline’lara geçiş görüyoruz.

Bu neden bugün önemli?

• Veri çeşitliliği ve hız artıyor — IoT, telemetri, transaction, event verileri farklı işleme ihtiyaçları getiriyor.
• ML uygulamaları için veri kalitesi ve feature engineering üretim güvenilirliği doğrudan model performansına yansır.
• Regülasyonlar ve veri yönetişimi veri dönüşümlerinin izlenebilir ve tekrarlanabilir olmasını gerektiriyor.

Kimler için önemli?

• Veri mühendisleri — pipeline tasarımı ve dönüşüm mantıkları için
• Veri bilimciler — feature engineering ve veri ön işleme için
• Platform mühendisleri ve SRE — performans ve operasyona hazır pipeline'lar için
• İş analistleri ve ürün ekipleri — güvenilir KPI ve raporlamalar için

2. KAVRAMSAL TEMELLER

2.1 Veri dönüşümünün temel kavramları

• Extract: Verinin kaynak sistemlerden çekilmesi (databases, APIs, event streams).
• Transform: Temizleme, normalizasyon, join, agregasyon, tip dönüşümleri, business rule uygulamaları.
• Load: Dönüştürülmüş verinin hedef sisteme (data warehouse, feature store, serving DB) yazılması.
• Schema evolution: Şema değişikliklerinin güvenli şekilde uygulanması ve geriye dönük uyumluluk stratejileri.

2.2 Terminoloji ve bileşenler

• ETL (Extract‑Transform‑Load): Transformasyonun kaynak tarafında gerçekleştiği, hedefe temizlenmiş verinin aktarıldığı klasik model.
• ELT (Extract‑Load‑Transform): Ham veriyi önce hedefe (data lake/warehouse) yükleyip sonrasında transformasyon yapan model; büyük veri ve lakehouse ile popüler.
• Streaming transformation: Event‑by‑event veya mikro‑batch modelinde anlık dönüşümler (Flink, Kafka Streams, Spark Structured Streaming).
• Batch transformation: Periyodik toplu işler (Spark, Databricks).
• UDF / UDAF: Özel dönüşümler için kullanıcı tanımlı fonksiyonlar ve agregasyonlar.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi ve dönüşüm katmanları

Veri dönüşümü genelde birkaç katmanda ele alınır: ingestion/landing (ham kayıt), staging (ilk temizleme), enrichment (referans verilerle zenginleştirme), business transformation (iş kuralları, KPI hesaplama) ve serving/curated layer (analitik tablolar, feature store). Bu katmanların her biri farklı SLA, veri hacmi ve erişim desenlerine sahiptir.

3.2 ETL vs ELT: Ne zaman hangisi?

• ETL: Kaynak sistemler üzerinde yoğun dönüşüm gereksinimi veya veri küçükken tercih edilir; veri hedefte temiz olduğundan sorgu maliyeti düşüktür.
• ELT: Ham veriyi önce depolamak ve farklı transformasyonları hedef ortamda (data warehouse/lakehouse) çalıştırmak gerekiyorsa; büyük veri ortamlarında esneklik sağlar.

3.3 Batch dönüşümler

Batch işlemler toplu veri işlemek için uygundur — günlük, saatlik veya saatlik altı periyotlar. Batch’in avantajı deterministik olması, kolay yeniden çalıştırma ve genelde daha basit hata izolasyonu sunmasıdır. Dezavantajı gecikmelidir; gerçek‑zaman gereksinimleri için uygun değildir.

3.4 Streaming dönüşümler

Streaming dönüşümler, event tabanlı veya mikro‑batch yaklaşımlarla düşük gecikme sağlar. Ancak state management, windowing, tekrar eden event'ler, exactly‑once semantics ve late arrival problemleri gibi karmaşıklıkları içerir. Yine de gerçek zamanlı analytics ve modele besleme için vazgeçilmezdir.

3.5 Common transformation patterns

• Cleansing: Null handling, trimming, invalid format rejection.
• Normalization: Tarih saat formatları, birim dönüşümleri, canonicalization.
• Deduplication: Idempotency keys, watermarking ve stateful dedupe.
• Enrichment: Lookup join (reference tables), geo‑IP, third‑party data augmentation.
• Aggregation: Rollup, tumbling/window aggregates, precomputed metrics.
• Windowing: Event time vs processing time yaklaşımları, watermark ve lateness yönetimi.

3.6 Schema evolution ve contract testing

Şema değişiklikleri veri pipeline'larını kırabileceği için versioning, schema registry (Avro/Protobuf/JSON Schema) ve contract tests zorunludur. Backward/forward compatibility stratejileri, default değerler ve consumer‑driven changes politikaları belirlenmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — event cleansing ve sessionization

Netflix gibi platformlar kullanıcı event'lerini toplar, sessionization ile oturumları oluşturur ve playback/quality metriklerini hesaplar. Streaming dönüşümler ile real‑time metrikler ve batch ile detaylı analizler birlikte kullanılır.

4.2 Uber — enrichment ve geo dönüşümleri

Uber, lokasyon verilerini anlık enrich ederek routing ve dispatch kararlarını verir. Geo hashing, tile mapping ve reverse geocoding gibi dönüşümler gerçek zamanlı olarak yapılır.

4.3 Amazon — catalog transformations ve attribution

Katalog verileri normalize edilir, kategori mappingleri uygulanır, fiyat ve kampanya verileri ile birleştirilir. Attribution modelleri için event transformation ve join'ler kritik rol oynar.

4.4 OpenAI / ML pipelines — feature engineering

ML için dönüşümler, feature extraction, normalization, missing value strategies ve label generation adımlarını içerir. Feature store'lar offline ve online tutarlılığı sağlamada dönüşümlerin merkezi bir parçasıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Doğru dönüşümler iş kararlarına güven sağlar; hatalı veri riski azalır.
• Reusable transform library ve UDF'ler, geliştirme hızını artırır.
• ELT + lakehouse kombinasyonu esneklik ve maliyet verimliliği sunar.

Sınırlamalar

• Transform complexity: Çok sayıda özel UDF ve stateful işlemler bakım maliyetini artırır.
• Operational cost: Stream state store'lar, checkpoints ve retention maliyetleri var.
• Data lineage zorluğu: Transformasyonların izlenebilir, açıklanabilir olması ekstra metadata gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo yaygın dönüşüm yaklaşımlarını karşılaştırır:

7. EN İYİ PRATİKLER

7.1 Production kullanımı

• Transformations as code: Tüm dönüşümler versiyonlanmış kod olarak saklanmalı ve review sürecinden geçmeli.
• Test as code: Unit/integration ve golden dataset tabanlı acceptance testleri CI'da çalıştırın.
• Idempotency: Transform ve load adımları tekrar çalıştırılabilir ve yan etki yaratmayacak şekilde tasarlanmalı.
• Schema registry & contract testing: Şema değişiklikleri PR sırasında otomatik testlerden geçmeli.

7.2 Performans optimizasyonu

• Partitioning ve bucketing stratejilerini sorgu desenlerine göre tasarlayın.
• Filtrelemeyi mümkün olan en erken aşamada uygulayın (predicate pushdown).
• UDF kullanımını sınırlandırın; mümkünse native SQL veya veritabanı optimizasyonlarını tercih edin.

7.3 Güvenlik ve yönetişim

• PII maskleme, field-level encryption ve access control uygulayın.
• Lineage ve audit loglarını otomatik toplayın; dönüşümlerin kim tarafından, ne zaman değiştiği izlenebilir olmalı.
• Data quality SLO'ları belirleyip monitör edin; otomatik eskalasyon ve runbook'lar hazırlayın.

8. SIK YAPILAN HATALAR

• Transformasyonları "kutuya" sokmamak: Tekrarlanabilir, test edilebilir modüller tasarlamamak.
• UDF ve custom code spagetti: Çok sayıda özel kod, bakım maliyetini arttırır ve performansı bozar.
• Schema evolution'ı planlamamak: Hızlı schema değişiklikleri downstream kırılmalara neden olur.
• Observability eksikliği: Checkpoint, watermark ve job metrikleri olmadan production triage zorlaşır.

9. GELECEK TRENDLER

9.1 AI‑assisted feature engineering ve transformasyon

AI, dönüşüm önerileri, otomatik feature generation ve anomaly detection ile pipeline geliştiricilere öneriler sunacak; tekrarlayan dönüşümler otomatikleştirilebilecek.

9.2 Declarative transformation languages

SQL/DSL tabanlı deklaratif dönüşüm dilleri (dbt, Pyspark DSL'leri, SQLX) ile dönüşümler daha okunabilir, test edilebilir ve yeniden kullanılabilir olacak.

9.3 Streaming first architectures

Gerçek zamanlı analitik ve ML için streaming‑first yaklaşımlar, state store'ların ve stream processing özelliklerinin olgunlaşmasıyla daha erişilebilir hale gelecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. ETL mi ELT mi tercih etmeli?

   İhtiyaçlarınıza göre: küçük veri ve kaynak dönüşümlerinde ETL; büyük ham veri, esneklik ve farklı transformasyon denemelerinde ELT tercih edilir.

2. 2. Streaming dönüşümler için hangi motorlar uygundur?

   Apache Flink, Kafka Streams, Spark Structured Streaming ve Beam ekosistemi sık kullanılan seçeneklerdir. Seçim state, windowing ve operational yetkinliklere bağlıdır.

3. 3. UDF kullanımından kaçınmalı mıyım?

   UDF'ler fonksiyonellik sağlar ama performansı düşürebilir ve portability sorunları yaratabilir. Mümkünse native SQL, built‑in functions veya vectorized işlemler tercih edin.

4. 4. Schema evolution nasıl yönetilmeli?

   Schema registry, default değerler, backward/forward compatibility kuralları ve contract tests en temel önlemlerdir.

5. 5. Late arrival verileri nasıl ele almalıyım?

   Watermarks, lateness windows ve retraction/upsert stratejileri ile semantik doğruluğu koruyun. Ayrıca history‑aware aggregation ve correction job'ları planlayın.

6. 6. Golden dataset nedir?

   Golden dataset, dönüşümlerin doğruluğunu kontrol etmek için kullanılan küçük, deterministik ve versiyonlanmış referans veri setidir.

7. 7. Transformations as code ne demek?

   Tüm dönüşümlerin kod olarak versiyonlanması, PR review, test ve CI süreçleriyle yönetilmesini ifade eder; production güvenilirliğini artırır.

8. 8. Dönüşümlerde izlenebilirliği nasıl sağlarım?

   Lineage, audit log, job metrikleri, trace ve data quality sonuçlarını merkezi bir katalogda toplayarak izlenebilirlik sağlanır.

Anahtar Kavramlar

• ELT: Extract, Load, Transform; ham veriyi önce hedefe koyup sonra dönüştürme yaklaşımı.
• Watermark: Event time bazlı window processing'de lateness kontrolü sağlayan zaman işareti.
• Golden dataset: Referans doğrulama için kullanılan küçük ve deterministik veri seti.
• Idempotency: Tekrar çalıştırmalarda yan etki oluşturmama garantisi.

Öğrenme Yol Haritası

1. 0–1 ay: SQL, temel veri modelleme ve ETL kavramlarını öğrenin.
2. 1–3 ay: Spark veya Flink ile temel dönüşüm job'ları, partitioning ve Parquet/ORC formatları üzerinde pratik yapın.
3. 3–6 ay: Streaming concepts, windowing, watermarks ve state management üzerinde uygulama yapın; schema registry ve contract testing öğrenin.
4. 6–12 ay: Production readiness: testing, monitoring, lineage, encryption ve data governance ile ilgili projeler gerçekleştirin.