1. GİRİŞ

Veri altyapısı (data infrastructure), modern dijital ürünlerin, analitik süreçlerin ve yapay zekâ uygulamalarının temelidir. 2020'lerin ikinci yarısında veri hacimleri, çeşitliliği ve hızındaki artış; çoklu bulut, edge ve veri gizliliği gereksinimleri veri altyapısının tekrar tasarlanmasını zorunlu kılıyor. Doğru kurulan bir veri altyapısı, verinin güvenilir, erişilebilir, izlenebilir ve verimli kullanılmasını sağlar. Bu rehber mühendisler, veri mimarları ve teknik liderler için uygulamaya dönük, derin ve pratik bir bakış sunar.

Bu neden bugün önemli?

• Veri ürünleri (ML modelleri, dashboard'lar, real‑time features) işletme değerini doğrudan etkiliyor; altyapı hataları ürün kalitesini bozar.
• Gerçek zamanlı işleme, low‑latency uygulamalar ve büyük ölçekli batch işler aynı platform üzerinde birlikte çalışmak zorunda kalıyor.
• Veri gizliliği ve uyumluluk (GDPR, KVKK) altyapı tasarım kararlarını etkiliyor.

Kimler için önemli?

Veri mühendisleri, platform mühendisleri, SRE'ler, ML mühendisleri, veri bilimciler ve CTO/VP of Engineering gibi karar vericiler için veri altyapısı kritik bir alandır.

Hangi problemleri çözüyor?

• Verinin tek kaynakta toplanması ve tutarlılık (single source of truth).
• Verinin keşfedilmesi ve yeniden kullanılabilirliği (data discoverability).
• Gerçek zamanlı ve batch işlerin birlikte yönetimi.
• Veri kalitesi, versiyonlama ve lineage izlenmesi.

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• Data Lake: Ham veya yarı işlenmiş verilerin büyük ölçekli, genellikle obje depolama üzerinde tutulduğu katman.
• Data Warehouse: İlişkisel veya kolon‑store tabanlı, analitik sorgulara optimize edilmiş işlenmiş veri deposu.
• Streaming Platform: Gerçek zamanlı veri akışlarını taşıyan ve işlemeye/aboneliğe olanak veren sistemler (Kafka, Pulsar).
• Metadata Catalog: Verinin keşfedilmesi, owner, schema ve lineage bilgilerinin tutulduğu katalog.
• ETL/ELT: Verinin taşınması ve dönüştürülmesi süreçleri; modern yaklaşımlar ELT ve SQL‑on‑data‑lake modellerine yöneliyor.
• Feature Store: ML modelleri için hazırlanan ve tekrar kullanılabilir özelliklerin saklandığı hizmet.

2.2 Terminoloji

• Schema on read vs Schema on write
• Data contract: Veri üreten ve tüketen servisler arasında servis seviyesi anlaşmaları.
• Data product: Veri merkezli bir çıktının (API, dataset, model) ürün mantığıyla yönetilmesi.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi

İyi bir veri altyapısı, veri üreticilerinden tüketicilere kadar uçtan uca kontrol sağlar. Mimari genellikle şu katmanlardan oluşur: ingest (API, streaming), storage (lake + warehouse), processing (batch, stream), serving (BI, ML feature store, APIs), ve yönetim katmanı (metadata, governance, monitoring). Bu katmanlar birbirinden bağımsızca ölçeklenebilmeli ve birbirleriyle API/contract aracılığıyla iletişim kurmalıdır.

3.2 Bileşenler

• Ingest: Kafka, Kinesis, Pub/Sub; dosya tabanlı ingest için S3/Blob upload ve change data capture (CDC) araçları (Debezium).
• Storage: Data lake (S3/Blob), Delta/iceberg/hudi ile ACID özellikleri; data warehouse (BigQuery, Snowflake, Redshift) analitik için.
• Processing: Spark/Flink/Beam ile batch ve stream işleme; dbt ile transformasyon pipeline'ları.
• Serving: Query engines (Presto/Trino), OLAP cubes, feature stores (Feast, Tecton) ve realtime materialized views.
• Metadata & Governance: Data catalogs (Amundsen, DataHub), lineage, policy enforcement (Open Policy Agent) ve data quality (Great Expectations, Deequ).

3.3 Veri akışı

Veri üretiminden tüketimine tipik akış: event oluşturma → ingest → raw storage → transform → curated dataset → serve. CDC ile transactional veriler akıcı bir şekilde lake'e gelir; transform aşaması ELT yaklaşımıyla data warehouse'a veya delta lake tablolarına uygulanır. Streaming ve batch yolları birbirini tamamlar; stream düşük gecikmeli feature'lar için, batch ise ağır transformasyonlar ve toplu eğitim setleri için uygundur.

3.4 Data contracts ve bağımsız ekipler

Dağıtık takımlarda veri producers ile consumers arasında veri sözleşmeleri (schemas, retention, semantics) önemlidir. Contract değişiklikleri versiyonlanmalı ve geriye dönük uyumluluk sağlanmalıdır; schema registry (Avro/Protobuf/JSON Schema) ile bu süreç yönetilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix

Netflix veri altyapısı yüksek hacimli event ingestion, geniş telemetri ve gerçek zamanlı personalizasyon için tasarlanmıştır. S3 benzeri storage, Kafka tabanlı streaming, Flink/Spark işleme ve güçlü metadata sistemleriyle birleşir. Data product yaklaşımı ve platform mühendisliği Netflix'te merkezi rol oynar.

4.2 Uber

Uber gerçek zamanlı konum, dispatch ve faturalama verileri için yüksek dayanıklılık ve düşük gecikme gerektirir. Event sourcing, stream processing ve edge routing yöntemleri altyapının temel taşlarıdır.

4.3 Amazon

Amazon’da veri altyapısı müşteri telemetri, sipariş işleme ve lojistik optimizasyonunu destekleyecek şekilde geniş ölçekte dağıtılmıştır. Data lake + warehouse kombosu ve güçlü katalog sistemleri kullanılır.

4.4 OpenAI ve ML‑First platformlar

ML‑first firmalarda veri altyapısı model yaşam döngüsünü destekler: training datasets, feature stores, experiment tracking ve scalable serving. Veri doğruluğu ve provenance ML sonuçlarının güvenilirliği için kritik önemdedir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Tekrarlanabilirlik: İyi tasarlanmış pipeline'lar veri ürünlerinin tutarlılığını sağlar.
• Ölçeklenebilirlik: Lake + compute ayrımı ile depolama ve işlem bağımsız ölçeklenir.
• Hızlı inovasyon: Feature store ve self‑service veri platformları veri bilimcilerin hızını artırır.

Sınırlamalar

• Karmaşıklık: Çok sayıda araç ve entegrasyon operasyona yük getirir.
• Maliyet: Depolama, compute ve veri transfer maliyetleri hızla artabilir.
• Veri kalitesi: Zayıf veri kalite kontrolleri yanlış analitik ve hatalı modeller üretir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Farklı veri altyapısı yaklaşımlarının karşılaştırması:

7. EN İYİ PRATİKLER

Production kullanımı

• Data contracts ile producer/consumer sözleşmelerini zorunlu kılın; schema registry kullanın.
• Idempotent ve retry‑safe pipeline'lar yazın; checkpointing ve exactly‑once garantiye dikkat edin.
• Feature store ve kataloğu kurumsal hizmet olarak sunun; discoverability'yi artırın.

Performans optimizasyonu

• Partitioning, clustering, compaction ve Z‑order gibi optimize tekniklerini kullanın.
• Hot‑path için stream processing, cold‑path için batch processing ayrımı yapın.

Güvenlik

• Data encryption at rest/in transit, column‑level encryption ve fine‑grained access control uygulayın.
• Metadata ve lineage yalnızca keşif için değil, güvenlik ve uyumluluk denetimleri için de kullanılmalı.

Ölçeklenebilirlik

• Mikroservis ve event‑driven mimariler ile parçalanabilir veri pipeline'ları tasarlayın.
• Multi‑region replication, cross‑region failover ve disaster recovery planları oluşturun.

8. SIK YAPILAN HATALAR

• Metadata olmadan büyümek: katalog ve lineage olmadan veri kaotik hale gelir.
• Tek bir monolitik pipeline'a güvenmek: küçük parçalar halinde, test edilebilir pipeline'lar tercih edin.
• Veri sahipliği belirsizliği: owner'lar ve SLAs tanımlanmazsa sorun çözme yavaşlar.
• Ölçekleme kararlarını sonradan almak: mimari kararları erken planlayın.

9. GELECEK TRENDLER

9.1 Mesh ve data product odaklı platformlar

Data mesh yaklaşımıyla veri, domain ekipleri tarafından product olarak yönetilecek; federated governance ve self‑service platformlar bunun temelini oluşturacak.

9.2 Real‑time everywhere

Gerçek zamanlı fonksiyonlar (feature serving, alerting, personalization) artık sadece bazı uygulamalar için değil, geniş bir yelpaze için beklenen özellik haline gelecek.

9.3 AI‑assisted data engineering

AI araçları veri pipeline'larını otomatik önerilerle oluşturacak, schema drift tespit edecek ve veri kalite sorunlarını öngörecek; bu da mühendis verimliliğini artıracak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Data lake ile data warehouse arasındaki fark nedir?

   Data lake ham veriyi düşük maliyetle saklarken, data warehouse işlenmiş ve analiz için optimize edilmiş veri tutar. Günümüzde birçok kuruluş her ikisini de hibrit olarak kullanır.

2. Streaming mi yoksa batch mi tercih etmeliyim?

   Gecikme gereksinimleri ve veri hacmi belirleyicidir. Low‑latency feature'lar için streaming, ağır toplu analitik için batch uygundur; çoğu platform her ikisini de destekler.

3. Data mesh uygulamak riskli midir?

   Doğru governance olmadan data mesh kafa karıştırıcı olabilir; federated contracts, güçlü metadata ve platform desteği gerekir.

4. Feature store gerekli mi?

   ML üretime alınıyorsa feature store yeniden kullanılabilirlik, sürdürülebilirlik ve tutarlılık sağlar; küçük projelerde gereksiz olabilir.

5. Schema evolution nasıl yönetilir?

   Schema registry, versioning ve backward/forward compatibility kuralları ile yönetilir; contract testi CI'da zorunlu olmalıdır.

6. Veri kalitesi nasıl ölçülür?

   Completeness, accuracy, freshness, uniqueness gibi metrikler kullanılır. Data quality pipeline'ları ile otomatik testler ve alert'ler kurulmalıdır.

7. Storage maliyetleri nasıl optimize edilir?

   Cold/hot tiering, kompressiyon, lifecycle politikaları ve doğru partition stratejileri ile maliyetler düşürülebilir.

8. Veri altyapısı için ilk adım nedir?

   Veri ihtiyaçlarını, consumer'ları ve entegrasyon noktalarını belirleyip küçük bir MVP pipeline kurarak başlayın; metadata ve katalogtan ödün vermeyin.

Anahtar Kavramlar

Data Lake

Ham verinin saklandığı büyük ölçekli depolama katmanı.

Data Warehouse

Analitik sorgular için optimize edilmiş işlenmiş veri deposu.

Streaming Platform

Gerçek zamanlı veri akışlarını taşıyan altyapı (Kafka/Pulsar).

Feature Store

ML için tekrar kullanılabilir ve tutarlı feature'ların saklandığı hizmet.

Metadata Catalog

Veri keşfi, lineage ve ownership bilgilerini tutan sistem.

Öğrenme Yol Haritası

1. 0–1 ay: Temel veri mühendisliği (SQL, temel Linux, temel ETL kavramları).
2. 1–3 ay: Kafka, Spark/Beam, S3/Blob ve bir data warehouse (BigQuery/Snowflake) üzerine uygulamalı çalışmalar.
3. 3–6 ay: Delta/Iceberg/Hudi, dbt, feature store kavramları ve metadata kataloglarını öğrenin.
4. 6–12 ay: Gerçek zamanlı uygulamalar, CDC, schema registry ve data governance projeleri yapın.
5. 12+ ay: Data mesh, federated governance ve privacy‑preserving data engineering konularında uzmanlaşın.