1. GİRİŞ: VERİNİN ZAMANDA YOLCULUĞU – NEDEN BUGÜN KRİTİK?

Yazılım geliştirme dünyasında "Git" kullanmadan bir proje yönetmek bugün nasıl düşünülemezse, 2026 yılına geldiğimizde Data Versioning (Veri Versiyonlama) yapmadan bir veri projesi veya yapay zeka modeli yönetmek de aynı derecede imkansız hale gelmiştir. Yazılımda kodun versiyonlanması (Code Versioning), bir hatayla karşılaşıldığında geçmişe dönmemizi veya farklı özellikleri paralel geliştirmemizi sağlar. Ancak veri dünyası, koddan çok daha dinamik, hacimli ve karmaşıktır.

Geleneksel veri tabanlarında veri genellikle "üzerine yazılır" (overwrite). Bir müşteri adını güncellediğinde, eski isim uçar gider. Ancak modern veri mühendisliği ve özellikle makine öğrenmesi (Machine Learning) süreçlerinde, modelin hangi verilerle eğitildiğini bilmek, o modele güvenebilmenin tek yoludur. Bir modelin başarısı düştüğünde (model drift), sorunun kodda mı yoksa verideki bir değişimde mi olduğunu anlamak için veriyi "dondurabilmek" ve geçmişe bakabilmek gerekir.

Bu Teknoloji Neden Bu Kadar Çok Konuşuluyor?

Yapay zeka (AI) ve Büyük Veri (Big Data) projelerinin en büyük kabusu "Reproducibility" (Tekrar Üretilebilirlik) problemidir. Eğer bugünkü verinizle eğittiğiniz modeli yarın aynı sonuçlarla tekrar eğitemiyorsanız, o sisteme üretim ortamında güvenemezsiniz. Data versioning, veriyi statik bir dosyadan ziyade, tarihçesi olan canlı bir varlık olarak ele alır. Bu da yasal uyumluluk (audit), hata ayıklama (debug) ve hızlı deneyler (fast experimentation) yapma olanağı sağlar.

Kimler İçin Önemli?

Bu makale; Veri Bilimciler, ML mühendisleri, Veri Mühendisleri ve Data Architects için bir başvuru kaynağıdır. Özellikle MLOps süreçlerini otomatize etmek isteyen ve veri gölünde (Data Lake) kaybolmak istemeyen profesyoneller için temel stratejileri içerir.

Hangi Problemleri Çözüyor?

• Geri Alınabilirlik (Rollback): Hatalı bir veri yüklemesi yapıldığında sistemin bir saniyede eski sağlıklı haline döndürülmesini sağlar.
• Deney Yönetimi: Farklı veri setleri (training sets) üzerinde yapılan deneylerin birbiriyle tutarlı şekilde karşılaştırılmasını sağlar.
• İzlenebilirlik (Lineage): Bir karar verildiğinde, o kararın hangi veri noktalarına dayanarak verildiğinin ispatlanmasını sağlar.
• Veri Göçü (Collaboration): Birden fazla mühendisin aynı veri seti üzerinde birbirini bozmadan paralel dallarda (branching) çalışmasını sağlar.

2. KAVRAMSAL TEMELLER: VERİ VERSİYONLAMA MİMARİSİ

Veri versiyonlama, kodu versiyonlamaktan yapısal olarak farklıdır. Git, küçük metin dosyaları için tasarlanmıştır; ancak terabaytlarca veriyi Git içine gömmek depolama ve performans açısından bir faciadır.

2.1 Temel Kavramlar

• Immutable Data (Değişmez Veri): Verinin bir kez yazıldıktan sonra asla değiştirilmemesi, her değişikliğin yeni bir versiyon/log olarak kaydedilmesi prensibidir.
• Metadata-Based Versioning: Büyük veri dosyalarının kendisini değil, o dosyaları işaret eden küçük "pointer" (işaretçi) dosyalarının versiyonlanmasıdır.
• Zero-Copy Branching: Veriyi kopyalamadan, sadece metaveriler üzerinden sanal kopyalar oluşturma tekniğidir (LakeFS gibi araçların temelidir).
• Time Travel (Zaman Yolculuğu): Bir sorguyu "bu tablo 2026-03-15 tarihindeki haliyle nasıldı?" diyerek çalıştırabilme yeteneğidir.

2.2 İki Temel Yaklaşım: Git-Like vs Table Format

Veri versiyonlama dünyasında iki ana akım vardır:

1. Dosya Odaklı (Git-like): DVC (Data Version Control) ve LakeFS gibi araçlar, dosyalarınızı veya nesne depolama (S3, GCS) alanınızı bir Git reposu gibi yönetmenizi sağlar.
2. Tablo Odaklı (Database-like): Delta Lake, Apache Iceberg ve Apache Hudi gibi teknolojiler, veriyi tablo formatında saklarken arka planda o tabloya yapılan her işlemi (INSERT, UPDATE, DELETE) bir log olarak tutar.

3. NASIL ÇALIŞIR? TEKNİK DERİNLİK VE VERİ AKIŞI

Veri versiyonlama sistemleri, fiziksel veri ile ona erişen katman arasına bir "Abstraction Layer" (Soyutlama Katmanı) ekler.

3.1 DVC (Data Version Control) Mimari Mantığı

DVC, "çakma" bir Git gibi çalışır. Büyük verinizi (Örn: `train.parquet`) dışarıdaki bir bulut depolama biriminde (Amazon S3) saklar. Git içinde ise sadece o dosyanın hash değerini içeren küçük bir `.dvc` dosyası tutar. Veri Akışı: 1. Veriyi ekle (`dvc add`). 2. DVC, veriyi Hash'ler ve S3'e gönderir. 3. Git, hash dosyasını commitle'ler. Böylece kodunuz ve veriniz her zaman senkronize kalır.

3.2 LakeFS ve Nesne Depolama Mimarisi

LakeFS, S3 veya GCS gibi depolama alanlarının üzerine oturan bir "gateway"dir. Bir "branch" oluşturduğunuzda fiziksel hiçbir dosya kopyalanmaz. Sadece veritabanındaki metaveri kayıtları kopyalanır. Bir dosyayı değiştirdiğinizde, sistem sadece o değişen parçayı saklar (Copy-on-write). Bu sayede petabayt seviyesinde veride bir saniyede "branch" açıp test yapabilirsiniz.

3.3 Delta Lake / Iceberg: Transaction Log Mimari

Bu sistemler veriyi "Parquet" veya "Avro" dosyalarında saklarken, yanına bir de "Transaction Log" (İşlem Günlüğü) klasörü koyar. Bir sorgu geldiğinde; sistem önce loglara bakar, o andaki "aktif" dosyaları listeler ve sadece onları okur. Çalışma Mantığı: - **Commit:** Her yazma işlemi yeni bir JSON dosyasıdır. - **Checkpoint:** Performans için bu loglar periyodik olarak birleştirilir. - **Vacuum:** Eski versiyonların fiziksel olarak silinmesi işlemidir (Maliyet yönetimi için kritiktir).

4. GERÇEK DÜNYA KULLANIMLARI: ENDÜSTRİ DEVLERİNİN STRATEJİLERİ

Hangi teknolojinin nerede kullanılacağı ihtiyacın ölçeğine göre değişir.

4.1 Netflix: Apache Iceberg'in Doğuşu

Netflix, bulut üzerindeki devasa veri gölünde (S3) tabloların şemalarını güncellerken ve veri silerken (GDPR gereksinimleri) ciddi performans sorunları yaşıyordu. Apache Iceberg'i geliştirerek, nesne depolama üzerindeki dosya listelemek yerine metaveri dosyaları üzerinden doğrudan ilgili Parquet dosyalarına gitmeyi başardılar. Bu, Netflix'in veriyi on yıllar boyunca güvenilir şekilde versiyonlamasını sağladı.

4.2 Uber: Apache Hudi ve Anlık Veri

Uber, sürücü ve yolcu verilerini sürekli güncellerken (upsert), bu verilerin analitik sorgularda tutarlı versiyonlarla görünmesini sağlamak zorundaydı. Apache Hudi sayesinde "Incremental Processing" (Artımlı İşleme) yaparak, sadece değişen versiyonları işleyip maliyeti düşürdüler.

4.3 OpenAI: Büyük Model Eğitimleri

OpenAI gibi şirketler için bir modelin eğitimi aylar sürebilir ve milyonlarca dolar tutabilir. Eğer eğitim verisinde bir sızıntı veya bozulma fark edilirse, eğitimi "checkpoint" noktalarından (versiyonlanmış veri setlerinden) geri yüklemek hayati önem taşır. Veri versiyonlama, bu muazzam veri setlerinin takibinde tek güvenli limandır.

4.4 Stripe: Veri Ürünleri ve API Uyumluluğu

Stripe'ın kullanıcılarına sunduğu finansal dashboardlar, zaman içindeki veri değişimlerinden etkilenmemelidir. Stripe, veri ambarındaki versiyonlama stratejileriyle, bir API kullanıcısının veriyi her zaman beklediği formatta ve tarihsel tutarlılıkta görmesini garanti eder.

5. AVANTAJLAR VE SINIRLAMALAR: AÇIK VE DÜRÜST ANALİZ

Veri versiyonlamanın her derde deva olmadığını anlamak gerekir.

Avantajlar

• Reproducibility: Deneylerin %100 tekrarlanabilir olması.
• Güvenlik ve Yanlış Veri Engelleme: Geri alma (revert) butonu artık veri için de var.
• GDPR/KVKK Uyumluluğu: Verinin ne zaman silindiği veya değiştiğinin kanıtlanması.
• Veri Ambarında CI/CD: "Branch" açıp veriyi test edip sonra ana tabloya (production) birleştirme (merge) imkanı.

Dezavantajlar ve Sınırlamalar

• Depolama Maliyeti: Her versiyonu saklamak (özellikle immutability tam uygulanırsa) bulut faturasını şişirebilir.
• Operasyonel Karmaşıklık: Metaveri yönetim araçlarını (DVC, LakeFS) öğrenmek ve yönetmek zaman alır.
• Eski Sistemlerle Uyumluluk: Bazı eski biyometrik veya veri görselleştirme araçları "time travel" yeteneğini anlamaz.
• Performans Overhead: Metaveri katmanı eklemek, sorgu sürelerine (milisaniyeler seviyesinde olsa da) ek yük bindirebilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA: DOĞRU ARACI SEÇMEK

İhtiyacınıza göre hangi araç setini seçmelisiniz? İşte karşılaştırma tablosu:

7. EN İYİ PRATİKLER: ÜRETİM ORTAMINDA VERİ VERSİYONLAMA

Sadece bir araç kurmak yetmez; şu prensipleri kültüre entegre etmelisiniz:

Production Kullanımı

• Sıkı İmmutability Uygulayın: Üretim ortamındaki ana veri setlerine "Update" yetkisi vermeyin. Sadece "Append" (ekleme) ve yeni versiyon oluşturma üzerinden gidin.
• Otomatik Versiyonlama: Pipeline'larınız her başarılı işleyişin ardından otomatik olarak bir "snapshot" veya "tag" oluşturmalıdır.

Performans Optimzasyonu

• Z-Order ve Compaction: Küçük versiyon dosyalarını (small file problem) periyodik olarak büyük dosyalarla birleştirin.
• Partitioning ile Versiyonlama: Veriyi tarihe veya coğrafyaya göre partisyonlayarak sadece ilgili versiyonların taranmasını sağlayın.

Güvenlik ve Uyumluluk

• Access Control List (ACL): Hangi versiyonlara kimlerin erişebileceğini metaveri seviyesinde tanımlayın.
• Veri Silme Politikası: "Vacuum" veya "Clear History" işlemlerini yasal saklama sürelerinize (Retention policy) göre planlayın.

8. SIK YAPILAN HATALAR: GELİŞTİRİCİLERİN DÜŞTÜĞÜ TUZAKLAR

• Fiziksel Veriyi Git'e Atmak: 100MB üzerindeki dosyaları Git'e atmaya çalışmak, repo performansını sonsuza dek bozar. Mutlaka DVC veya LFS kullanın.
• Versiyon Temizliğini Unutmak: Yıllar boyu biriken "çöp" versiyonlar, depolama maliyetlerinizi astronomik seviyelere çıkarabilir.
• Anlamsız İsimlendirme: 'v1', 'v2_fixed', 'v2_fixed_final' gibi isimlendirmelerden kaçının. Semantik versiyonlama (Örn: `2026-03-15-prod`) veya Git commit hash değerlerini kullanın.
• Kod ve Veri Senkronizasyonunu Bozmak: Model kodunu v2'ye güncelleyip veriyi v1'de bırakmak, hatalı çıkarımlara (inference) yol açar.
• Versiyonlamayı Bir "Yedekleme" (Backup) Sanmak: Versiyonlama bir değişim yönetimidir; felaket kurtarma (disaster recovery) için hala geleneksel yedeklere ihtiyacınız vardır.

9. GELECEK TRENDLER: 2026 VE ÖTESİNDE VERİ VERSİYONLAMA

Veri versiyonlama, önümüzdeki yıllarda daha "akıllı" ve "otonom" hale gelecek.

9.1 AI Destekli Otonom Versiyonlama

Makine öğrenmesi modelleri, verideki anomalileri fark edip otomatik olarak bir "sorunlu versiyon" etiketi atayabilecek ve sistemi otomatik olarak bir önceki sağlıklı versiyona döndürebilecek.

9.2 Real-Time Data Versioning

Streaming sistemlerinde (Kafka, Flink) anlık versiyonlama yetenekleri artacak. Veri akarken, her mikro-batch'in hangi dönüşümden geçtiği metaveri olarak üzerine mühürlenecek.

9.3 Cloud-Native Table Formats (Iceberg 3.0 ve Ötesi)

Bulut sağlayıcıları (AWS, Google), veri versiyonlamayı doğrudan depolama katmanına entegre edecek. Nesne depolama alanları, versiyonlama yeteneğini bir API parametresi olarak değil, doğal bir dosya sistemi özelliği olarak sunacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Veri versiyonlama veritabanı yedeğinden farklı mıdır?

   Evet. Yedekleme tüm verinin bir kopyasıdır ve geri dönmek saatler sürebilir. Versiyonlama ise değişiklikleri takip eder ve metaveri üzerinden anında geçmişe dönmeyi (time travel) sağlar.

2. Küçük bir şirketiz, bu karmaşıklığa değer mi?

   Eğer yapay zeka modelleri eğitiyorsanız veya veriniz sürekli raporlama için kullanılıyorsa, basit bir DVC kurulumu bile ileride yaşayacağınız kaosun önüne geçer.

3. Hangi araç en kolayıdır?

   Mühendislik odaklı takımlar için DVC, daha kurumsal ve data lake odaklı takımlar için Delta Lake başlangıç için daha uygundur.

4. Veri silme (deletion) versiyonlama ile nasıl çalışır?

   Bir veriyi sildiğinizde, o "yeni bir versiyon" olarak kaydedilir. Ancak veri fiziksel olarak depolama alanından "Vacuum" işlemi yapılana kadar silinmez. GDPR için Vacuum şarttır.

5. Versiyonlama performansı düşürür mü?

   Çok fazla küçük dosya (small file problem) oluşturursanız okuma hızı düşer. Bu yüzden periyodik olarak "Compaction" (birleştirme) yapılmalıdır.

6. Git LFS (Large File Storage) yeterli değil mi?

   LFS sadece dosya saklar. Oysa DVC ve benzeri araçlar veri hattını (pipeline), çıktılar arası bağımlılıkları ve veri bilimi iş akışlarını da yönetir.

7. SQL tabanlı sistemlerde versiyonlama nasıl yapılır?

   Delta Lake veya Iceberg gibi formatlar kullanıyorsanız, `SELECT * FROM table VERSION AS OF 10` gibi SQL komutlarıyla yapılır.

8. Model versiyonlama (Model Versioning) ile farkı nedir?

   Model versiyonlama, eğitilmiş ağırlıkları (.bin, .h5) saklar. Data versioning ise o ağırlıkları oluşturan ham veriyi saklar. İkisi birleşince "Full Lineage" oluşur.

Anahtar Kavramlar

Hash (SHA-256)

Verinin parmak izidir. Veri bir bit bile değişse hash değişir, böylece versiyon takibi yapılır.

Branching (Dallanma)

Ana veri setini bozmadan üzerinde deney yapabileceğiniz sanal ver yolu.

Merge (Birleştirme)

Test edilmiş ve onaylanmış yeni verilerin ana tabloya güvenle dahil edilmesi.

Copy-on-Write

Bir veri değişmediği sürece kopyalanmaz, sadece değişen kısımlar yeni bir dosya olarak yazılır.

Data Lineage

Verinin kaynağından çıkıp son raporlama noktasına gelene kadar geçirdiği tüm aşamaların izi.

Öğrenme Yol Haritası (Data Versioning Profesyoneli Olmak)

1. 1. Ay: Geleneksel Git ve Data Bilinci. Git komutlarına hakim olun ve büyük verinin neden Git'e atılamayacağını anlayın.
2. 2. Ay: DVC ile Tanışma. Yerel bir makine öğrenmesi projesinde veriyi ve modelleri DVC ile versiyonlamayı öğrenin.
3. 3. Ay: Modern Table Formats. Delta Lake veya Iceberg üzerinde "Time Travel" ve "Schema Evolution" pratikleri yapın.
4. 4. Ay: Scale-up ve LakeFS. Petabayt seviyesinde veride sıfır kopya branching (Zero-copy branching) kavramını ve LakeFS kurulumunu öğrenin.
5. 5. Ay: MLOps Entegrasyonu. MLflow veya Kubeflow gibi araçlarla veri versiyonlamayı bir boru hattı (pipeline) olarak birleştirin.