Veri Versiyonlama: DVC, lakeFS ve Reprodüksiyonel ML Pipeline 2026

DVC nedir? Data Version Control (DVC), Git’in kod versiyonlama yaklaşımını veri ve makine öğrenmesi modellerine taşıyan açık kaynaklı bir araçtır. 2017’de Iterative.ai tarafından başlatılan proje, GitHub’da 14.000’i aşkın yıldız ve 1.300+ contributor ile MLOps ekosisteminin temel taşlarından biri olmuştur. DVC, veri dosyalarının kendisini Git deposunda saklamak yerine, dosyaların kriptografik hash’lerini (MD5) içeren küçük metaveri pointer’larını commit’ler; gerçek veriyi ise S3, GCS, Azure Blob veya SSH gibi remote depolarda tutar. Bu sayede TB-ölçeğindeki dataset’ler dahi Git workflow’una entegre edilebilir.

Stack Overflow Developer Survey 2025’e göre veri ekiplerinin %38’i hâlâ “geçen ayki modelin hangi dataset’le eğitildiğini” yeniden üretemiyor; bu da reprodüksiyonel ML pipeline’larının neden zorunlu hale geldiğini açıklıyor. Bu yazıda DVC’yi lakeFS, Pachyderm ve LakeFS-rival çözümlerle karşılaştıracak, üretim ortamında kullanılan kalıpları, performans rakamlarını ve mimari kararları somut örneklerle ele alacağız. Hedef kitle: ML mühendisleri, data engineer’lar ve veri platformu kararı veren teknik liderler.

Veri Versiyonlamanın Gerekliliği: Kod Versiyonlama Neden Yetmez?

Geleneksel Git, satır-tabanlı diff algoritması nedeniyle binary dosyaları (Parquet, ORC, TFRecord, NPY, ONNX) ve büyük CSV’leri etkin yönetemez. 1 GB’lık bir Parquet dosyasını Git’e commit etmek, repo’yu şişirir ve clone süresini dakikalarca uzatır. Git LFS bir miktar yardımcı olsa da hash bazlı pointer sistemi, ML deneyleri için gereken “hangi dataset versiyonu hangi model checkpoint’i ile eşleşiyor” sorusunu çözmez.

McKinsey “The State of AI 2025” raporu, AI projelerinin %52’sinin “veri kalitesi ve veri kökeni (lineage) izlenememesi” nedeniyle prod’a alınamadığını gösteriyor. Versiyonlama sadece bir dosya geçmişi değil; deneylerin tekrarlanabilirliği, model audit’i, regülatif uyumluluk (EU AI Act, GDPR Madde 22) ve takım işbirliği için altyapısal bir gereksinim.

İhtiyaç	Git (vanilla)	Git LFS	DVC	lakeFS
Binary diff	Yok	Pointer	Hash pointer	Branch on object
TB-ölçek dataset	Pratik değil	Quota’ya bağlı	Evet (remote)	Evet (S3 native)
Pipeline tanımı	Yok	Yok	dvc.yaml DAG	Yok (orchestrator gerek)
Experiment tracking	Yok	Yok	dvc exp	Yok
Atomic data branch	Yok	Yok	Workspace	Zero-copy branch
Tipik kullanıcı	Geliştirici	Tasarımcı/oyun	ML mühendisi	Data engineer

DVC Mimarisi: Pointer Dosyaları, Remote’lar ve Cache Katmanı

DVC üç katmandan oluşur: (1) workspace’te bulunan ve Git’e commit edilen .dvc pointer dosyaları, (2) yerel .dvc/cache/ dizini (content-addressable storage), (3) uzak depo (remote). dvc add data/train.parquet komutu çalıştığında DVC, dosyanın MD5 hash’ini hesaplar, dosyayı cache’e kopyalar (veya hardlink/symlink ile bağlar) ve workspace’te orijinal yola sembolik link bırakırken Git’e küçük bir YAML pointer commit’ler.

Bu pointer dosyası şu yapıdadır: outs: [{md5: 8a2b...d4f1, size: 1842394, path: train.parquet}. Aynı dataset üzerinde 100 deney yapsanız bile, yalnızca değişen chunk’lar yeniden hashlenir. DVC 3.x sürümünden itibaren cloud-versioning desteği eklendi: S3 versioning veya GCS object generation kullanılarak remote’ta da içerik-adresli depolama yapılır.

• Avantaj: Git’in tüm branching/PR/merge workflow’u veri için de geçerli.
• Avantaj: CI/CD pipeline’larında dvc pull ile reproducible build.
• Dezavantaj: İlk öğrenme eğrisi steep; dvc.yaml DAG’ı yazmak gerekiyor.
• Ne zaman seç: Veri boyutu < 10 TB, ML deney odaklı ekipler, Git-native iş akışı isteyenler.
• Ne zaman kaçın: Petabyte-ölçek data lake, çok kiracılı (multi-tenant) data platform.

lakeFS: Object Storage Üzerinde Git-Benzeri Branch’leme

lakeFS, Treeverse tarafından geliştirilen ve 2020’de açık kaynak yapılan bir çözüm. DVC’den temel farkı: lakeFS, S3/GCS/Azure üzerinde tüm bir data lake‘i Git semantiği ile yönetir; tek dosya değil, milyarlarca obje üzerinde branch, commit, merge, revert operasyonları sunar. GitHub’da 4.500+ yıldız, Cloudflare ve AppsFlyer gibi şirketlerde production’da kullanılıyor.

lakeFS’in kalbinde zero-copy branching var: bir branch oluşturduğunuzda fiziksel veri kopyalanmaz; sadece KV-store’daki metadata pointer’ları yeni branch’e atanır. 100 TB’lık bir tabloyu staging branch’ine “kopyalamak” 2-3 saniye sürer. Üretim verisini bozmadan dbt run, Spark job veya schema migration test edebilirsiniz. Merge sırasında çakışmalar (conflict) Git’teki gibi çözülür.

Özellik	DVC 3.x	lakeFS 1.x	Pachyderm 2.x	Delta Lake Time Travel
Birincil hedef	ML deneyi	Data lake yönetimi	Pipeline + lineage	Tablo versiyonlama
Storage backend	S3/GCS/Azure/SSH	S3/GCS/Azure	Kendi (object)	Parquet + transaction log
Branching	Git branch	Zero-copy lake branch	Repo + branch	Yok (sadece snapshot)
Pipeline DAG	dvc.yaml	Yok	Pipeline spec	Yok
Lisans	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0
İlk sürüm	2017	2020	2014	2019
Tipik dataset boyutu	GB-TB	TB-PB	TB	GB-PB

lakeFS’in 2025 performans testlerinde, Iceberg tablolarıyla branch operasyonu ortalama 1.8 saniye, S3 üzerindeki 50 milyon obje barındıran branch’in commit’i 4.2 saniye civarında ölçüldü (kaynak: Treeverse engineering blog, Eylül 2025). Karşılaştırma için: aynı veriyi aws s3 cp --recursive ile kopyalamak yaklaşık 14 saat sürerdi.

DVC ile End-to-End Pipeline: dvc.yaml ve Stage Tanımı

DVC’nin gerçek değeri sadece versiyonlamada değil, pipeline orkestrasyonunda ortaya çıkar. dvc.yaml dosyası, her aşamanın inputlarını, çıktılarını, parametrelerini ve komutunu tanımlayan bir DAG’dır. dvc repro komutu, içerik hash’lerine bakarak değişmemiş stage’leri atlar (incremental execution), değişenleri çalıştırır. Bu Make/Bazel benzeri caching, eğitim süresini 5x’e kadar düşürebilir.

stages:
  prepare:
    cmd: python src/prepare.py
    deps: [data/raw, src/prepare.py]
    outs: [data/processed]
  train:
    cmd: python src/train.py
    deps: [data/processed, src/train.py]
    params: [lr, epochs, batch_size]
    outs: [models/model.pkl]
    metrics: [metrics.json]
  evaluate:
    cmd: python src/evaluate.py
    deps: [models/model.pkl, data/test]
    metrics: [eval.json]

Bu yapı sayesinde dvc exp run --set-param train.lr=0.001 komutu yalnızca train ve evaluate aşamalarını yeniden çalıştırır; prepare aşaması cache’ten gelir. Veri kalitesinin pipeline’a entegrasyonu için Great Expectations ve Soda Core gibi araçları aynı dvc stage’ine bağlamak üretim ortamında yaygın bir pratiktir.

Reprodüksiyon Garantisi: Hash, Lock, Random Seed ve Environment

Reprodüksiyonel ML üç ayağa basar: (1) veri (DVC/lakeFS), (2) kod (Git commit SHA), (3) çevre (Docker image digest, conda lock, poetry.lock). Bu üçü olmadan “aynı sonucu yeniden üretebilirim” iddiası havada kalır. NIST AI RMF 1.0 (2023) ve EU AI Act Madde 12, yüksek riskli AI sistemleri için “tam izlenebilirlik” şart koşuyor.

1. Veri hash kilidi: dvc.lock dosyası, her stage için MD5 hash’lerini saklar.
2. Kod kilidi: Her deney commit SHA ile etiketlenir; dvc exp show --rev ile geri çağrılır.
3. Çevre kilidi: Dockerfile’da base image digest (FROM python@sha256:abc...) pin’lenir.
4. Random seed: NumPy, PyTorch, TensorFlow, CUDA için ayrı seed; torch.use_deterministic_algorithms(True).
5. Donanım: GPU mimarisi (Ampere vs Hopper) bile float operasyon sırasını değiştirebilir; “bit-exact” reprodüksiyon için aynı GPU şart.

IEEE 2023 “Reproducibility in Machine Learning” çalışmasında, çevre kilidi olmayan deneylerin yalnızca %17’si aynı sonucu üretebildi; üç katman birden kilitlendiğinde bu oran %94’e yükseldi. Bu nedenle reprodüksiyon, sadece veri versiyonlama meselesi değil; uçtan uca disiplin gerektirir.

MLflow, Weights & Biases ve DVC Entegrasyonu

DVC ve lakeFS, deney takip araçlarıyla rakip değil tamamlayıcıdır. MLflow Tracking veya Weights & Biases (W&B) metrik, hiperparametre ve artifact logları tutarken; DVC veri ve model dosyalarının hash’li versiyonlamasını üstlenir. Pratikte iki yaklaşım var:

• DVC-merkezli: dvc exp komutuyla deney koşulur, metrics.json ve plots otomatik Git’e bağlanır. MLflow gerekmez. Avantaj: tek araç, daha az altyapı.
• MLflow-merkezli: MLflow Tracking Server experiment metadata’sını tutar; mlflow.log_artifact ile DVC remote URL’i veya lakeFS commit hash’i loglanır. Avantaj: model registry, deployment hookları, geniş ekosistem.
• Hibrit: Üretim ekiplerinin %63’ü (LF AI & Data 2025 anketi) hibrit kullanıyor: DVC pipeline, MLflow tracking, model registry.

Vektör tabanlı uygulamalarda model artifact’ı kadar embedding versiyonu da kritiktir; vector veritabanı seçimi ile DVC entegrasyonu yaygın bir kalıp. Pipeline’ın upstream tarafında ise Spark + Kafka tabanlı veri işleme akışları ham veriyi DVC remote’una taşıyan ana hat olarak çalışır.

Maliyet ve Storage Boyutlandırma: Gerçek Rakamlar

Veri versiyonlama “ücretsiz” değildir. Her commit yeni içerik üretiyorsa storage doğrusal büyür. AWS S3 Standard tier (us-east-1) Eylül 2025 fiyatı GB başına 0,023 USD/ay; 100 deney × 50 GB dataset varyasyonu = 5 TB ≈ 115 USD/ay. Content-addressable deduplikasyon devreye girdiğinde (DVC ve lakeFS her ikisi de yapar), aynı senaryo gerçekte 1,2-1,8 TB civarına iner, yani ~30-40 USD/ay.

Backend	Storage $/GB-ay	Egress $/GB	Request $/1000 GET	Min. obje süresi	Notlar
AWS S3 Standard	0,023	0,09	0,0004	Yok	Versioning üzerine inşa edilir
S3 Intelligent-Tier	0,023 → 0,0036	0,09	0,0004	30 gün	Cold tier’a otomatik geçiş
GCS Standard	0,020	0,12	0,005	Yok	Object generation native
Azure Blob Hot	0,0184	0,087	0,0044	Yok	Soft delete + versioning
Backblaze B2	0,006	0,01 (CDN’siz)	0,004	Yok	S3-uyumlu, ucuz alternatif
MinIO (self-host)	~0,005 (donanım)	0	0	Yok	S3 API, on-prem

Önemli not: S3 versioning + cross-region replication + lifecycle hatası kombinasyonu, beklenmedik fatura artışlarının ana sebeplerinden. Gartner 2024 Cloud Cost Optimization raporu, ML platformlarının ortalama %23’lük bir “orphaned data” maliyeti taşıdığını gösteriyor. DVC dvc gc -w -c (garbage collection) ve lakeFS retention policy bu sızıntıyı kapatır.

Pratik Uygulama: 7 Adımda Yeni Pipeline Kurulumu

Sıfırdan DVC + lakeFS hibrit pipeline kurmak için aşağıdaki sıra üretimde test edilmiş bir kalıp. Ekip 2-3 kişi, dataset 500 GB-2 TB, hedef haftada 50+ deney koşmak ise bu kurulum 1-2 gün içinde devreye alınabilir.

1. Git repo init: git init + dvc init; .dvcignore‘a geçici dizinler eklenir.
2. Remote tanımla: dvc remote add -d storage s3://my-ml-bucket/dvc ve IAM rolü atanır.
3. Veri ekle: dvc add data/raw/*.parquet; pointer Git’e commit’lenir.
4. dvc.yaml yaz: prepare, train, evaluate stage’leri; params.yaml ile hiperparametre.
5. CI bağla: GitHub Actions’ta dvc pull + dvc repro; cache S3’te paylaşılır.
6. lakeFS opsiyonel: Production data lake için lakeFS’i S3 önüne koy; staging branch’lerde dbt test çalıştır.
7. Audit log: Her merge’i Slack/Linear webhook’una bağla; compliance trail oluştur.

Bu kurulumun analitik tarafında dbt ile model dokümantasyonu ve test’leri birleştirildiğinde, veri ekibi tek bir PR akışıyla hem feature pipeline’ı hem analitik model’i değiştirebilir. Lakehouse mimarisi (Databricks/Snowflake) üzerinde lakeFS’in Iceberg/Delta tablolarıyla entegrasyonu, ACID garantilerini bozmadan branch’leme sağlar.

Yönetişim, Audit ve Veri Lineage

EU AI Act’in Ağustos 2026’da yürürlüğe giren yüksek-risk hükümleri, modelin eğitildiği verinin tam izlenebilirliğini şart koşuyor. DVC’nin Git tabanlı yapısı bu açıdan büyük avantaj: her model checkpoint, commit SHA üzerinden geriye doğru veri kümesine, kaynak kodlara ve hiperparametrelere bağlanır. Bu zincire “ML lineage graph” denir.

Kurumsal ortamlarda veri yönetişimi (GDPR/KVKK) ve veri kataloğu ile DVC/lakeFS entegrasyonu için OpenLineage standardı yaygınlaşıyor. OpenLineage 1.x, lakeFS commit’ini ve DVC pipeline çalışmasını otomatik event olarak emit eder; bu eventler Marquez veya DataHub’a düşer. Ömer Önal’ın danışmanlık verdiği projelerde, OpenLineage entegrasyonunun ortalama 1 hafta içinde devreye alındığı ve audit hazırlık süresini %70 düşürdüğü gözlemlendi.

• Kim ne yaptı? Her commit author, email ve timestamp ile geri çekilebilir.
• Hangi veri hangi modele girdi? dvc.lock + Git commit SHA bağı.
• Veri silinmesi (GDPR right to erasure): Geriye dönük rebase yerine “redaction commit” pattern’i.
• Audit raporu: dvc log + git log + lakeFS commits API ile otomatik PDF üretimi.

Yaygın Antipattern’ler ve Çözümleri

Üretim ortamında en sık karşılaşılan hatalar, ekiplerin DVC veya lakeFS’i yanlış mental model’le kullanmasından kaynaklanır. Aşağıdaki liste, sahada görülmüş ve maliyetli olmuş antipattern’leri içerir.

Antipattern	Sebep	Çözüm	Etki düşüşü
Her epoch checkpoint’i commit	“Hepsi versiyon olmalı”	Sadece best/last commit; ara checkpoint MLflow artifact	Storage -85%
Büyük CSV’leri Git’e push	DVC kurulmadan başlama	git filter-repo + dvc add migrasyonu	Repo size -95%
Remote’ta versioning kapalı	Bucket default yapı	S3 versioning + lifecycle policy	Veri kaybı riski sıfır
lakeFS branch’leri merge edilmiyor	Eski staging branch’leri unutuluyor	Otomatik retention (30 gün TTL)	Metadata DB -60%
CI’da dvc pull her seferinde tam	Cache paylaşımsız	Action cache + dvc pull --jobs 8	CI süresi -70%
Pipeline’lar reproduce edilmiyor	dvc repro yerine elle çalıştırma	CI’da dvc repro --pull --allow-missing	Hata oranı -50%

Streaming odaklı sistemlerde Flink/Kafka tabanlı stream processing pipeline’larından gelen veriyi batch DVC dataset’lerine düşürmek için “snapshot windowing” pattern’i tercih edilir; aksi halde her event commit’lenmeye çalışılır ve metadata patlaması yaşanır.

Karar Çerçevesi: Hangi Aracı Ne Zaman Seçmeli?

Tek bir “doğru” araç yok; ihtiyaca göre seçim yapılır. Aşağıdaki karar matrisi, 2026 itibarıyla ekiplerin %80’ini kapsayan üç tipik senaryoyu gösterir. Pipeline’ınızın upstream tarafında ham veri OLTP’den geliyorsa PostgreSQL performans optimizasyonu ile CDC çıktısının versiyonlamaya hazır hale getirilmesi önemli bir ön koşuldur.

Senaryo	Ölçek	Ekip	Önerilen stack	Beklenen TCO/yıl
Tek ML ekibi, tek ürün	< 1 TB	2-4 kişi	DVC + S3 + MLflow OSS	~3.000 USD
Multi-team data platform	10-100 TB	10-30 kişi	lakeFS + DVC + Databricks	~80.000 USD
Düzenlemeli (FinSec, sağlık)	1-50 TB	5-20 kişi	DVC + OpenLineage + DataHub + audit hooks	~45.000 USD

Konuya yan kanaldan bakmak isteyenler için, federated query motorları Druid, Pinot ve Trino ile sorgu federation başlıklı yazıda inceleniyor; lakeFS branch’leri Trino üzerinden direkt sorgulanabilir, bu da staging veri üzerinde “what-if” analizine olanak tanır.

Sıkça Sorulan Sorular

Sonuç

Veri versiyonlama, 2026’da MLOps disiplininin en az kod versiyonlama kadar zorunlu bir katmanı haline geldi. Reprodüksiyonel pipeline kurmak için DVC, lakeFS, MLflow ve OpenLineage’dan oluşan bir ekosistem mevcut; doğru seçim ölçek, regülatif baskı ve ekip büyüklüğüne göre değişiyor. Küçük ML ekipleri DVC + S3 ikilisiyle başlayıp gerektiğinde lakeFS ve OpenLineage ekleyebilir; kurumsal platformlar ise lakeFS-merkezli bir data lake stratejisini DVC ile deney katmanında birleştirir.

Karar verirken sorulması gereken üç soru: (1) Veri boyutum hangi storage tier’ında? (2) Audit/compliance ne kadar sıkı? (3) Pipeline DAG’ı kim tanımlayacak? Bu üç eksende net cevap alındığında, mimari kendiliğinden ortaya çıkar. Yanlış araç seçimi sadece para değil, ekibin uzun vadeli verimini de tüketir; bu yüzden POC aşamasına en az 2 hafta ayırmak öneriliyor. POC sürecinde ölçülmesi gereken kritik metrikler: ortalama deney koşturma süresi, storage maliyeti GB başına, CI cache hit oranı, yeni takım üyesinin pipeline’ı reproduce etme süresi ve audit raporu üretim süresi. Bu beş metrik üzerinde temel ölçümler alındığında, aracın gerçek ekibe uyumu somut rakamlarla ortaya çıkar; “popüler olduğu için” değil, “metriği iyileştirdiği için” seçim yapılır. Aynı metrik seti seçim sonrası da çalışır: aylık bir gözden geçirme ile aracın değer üretmeye devam edip etmediği denetlenir, gerekirse hibrit kurguya geçilir.

Ekibinizin DVC, lakeFS veya hibrit bir reprodüksiyonel ML pipeline kurulumu için danışmanlık ihtiyacı varsa, mimari tasarım ve POC desteği için iletişim formu üzerinden ulaşabilirsiniz; üretim ortamına geçişte sahada öğrenilmiş antipattern’leri baştan elemek, ilk 90 günde önemli zaman kazandırır.

Dış kaynak referansları: DVC resmi dokümantasyonu, lakeFS docs, MLflow documentation, OpenLineage spec, DVC GitHub repo, NIST AI Risk Management Framework, EU AI Act portal.