Veri yönetimi ile veri mühendisliği arasındaki fark nedir?

Veri yönetimi politikalar, sahiplik, kalite, güvenlik gibi yönetişim odaklı disiplinleri kapsar. Veri mühendisliği ise bu politikaları işletecek teknik altyapıyı — pipeline, depolama, dönüşüm sistemlerini — kuran mühendislik pratiğidir. İlki ne yapılacağını, ikincisi nasıl yapılacağını tanımlar; ikisi birlikte çalışır.

Karanlık veri (dark data) tam olarak neyi ifade eder?

Kurumların topladığı ama analiz etmediği, çoğu zaman varlığından bile haberdar olmadığı veri kütlesidir. Log dosyaları, eski yedekler, terk edilmiş tablolar, kaydedilmiş ama hiç açılmamış formlar buna dahildir. IDC'ye göre kurumsal verinin %50-70'i karanlık veri kategorisindedir ve hem maliyet hem yasal risk yaratır.

Data lake mi data warehouse mi seçmeliyim?

İhtiyacınız yapılandırılmış BI raporlama ise warehouse, ham log ve ML için esnek depolama ise lake daha uygundur. Modern yaklaşımda iki dünyayı birleştiren lakehouse mimarisi (Delta Lake, Iceberg) tercih ediliyor. Karar; veri hacmi, sorgu profili ve ekibinizin SQL veya kod tabanlı çalışma alışkanlığına göre verilmelidir.

Data steward ile data owner aynı kişi olabilir mi?

Küçük ekiplerde olabilir ama önerilmez. Owner stratejik kararları (kim erişebilir, hangi amaçla kullanılabilir) verirken, steward günlük operasyonu (kalite kontrol, talep yönetimi, tanım güncelleme) yürütür. Rollerin ayrışması hesap verebilirliği güçlendirir ve owner'ın detayda boğulmasını engeller.

Veri lineage'ı manuel tutmak mümkün mü?

Teorik olarak evet ama pratikte 20-30 tablodan sonra sürdürülemez. Çünkü her pipeline değişikliği belgenin güncellenmesini gerektirir ve mühendislik akışında bu adım sürekli unutulur. OpenLineage, Apache Atlas, DataHub gibi otomatik lineage araçları kodu ve sorguları parse ederek bu haritayı kendi başlarına çıkarır.

KVKK kapsamında veri silme talepleri nasıl yönetilir?

Önce ilgili kişinin verisinin hangi tablolarda bulunduğunu lineage ve katalog araçlarıyla tespit etmeniz gerekir. Sonra audit'lenebilir bir silme süreci tetiklenir; yedekler dahil tüm kopyalarda silme veya anonimleştirme yapılır. Yasal saklama yükümlülüğü olan veriler (örn. fatura) silinmek yerine erişimden çıkarılır ve süre sonunda imha edilir.

Master Data Management (MDM) veri yönetiminin neresinde durur?

MDM; müşteri, ürün, lokasyon gibi temel iş varlıklarının kurum genelinde tek ve tutarlı bir tanımının olmasını sağlar. Veri yönetiminin alt disiplinlerinden biridir. CRM'de 'Ahmet Yılmaz', ERP'de 'A. Yılmaz' olarak görünen kayıtların aynı kişi olduğunu MDM çözer; raporlardaki tekrarları ve çelişkileri ortadan kaldırır.

Küçük bir şirketin veri yönetimine yatırım yapması mantıklı mı?

Evet, ama ölçeğe uygun biçimde. Beş kişilik bir ekibin Collibra lisansına ihtiyacı yok; Google Sheets'te tutulan bir veri sözlüğü, açıkça atanmış sahipler ve haftalık kalite kontrolü bile başlangıç için yeterlidir. Önemli olan disiplinin erken kurulması — şirket büyüdüğünde aynı pratikler araçlarla ölçeklenir.

VERİ YÖNETİMİ

Beş aşamalı dairesel veri yaşam döngüsü oklarla bağlı toplama saklama işleme paylaşma arşiv simgeleri

Forrester ve IDC araştırmalarına göre kurumların ürettiği verinin yalnızca %32'si gerçekten analiz ediliyor; geri kalan %68 ise "karanlık veri" olarak depolama maliyeti üretip rafta kalıyor. Aynı raporlar, data lake yatırımı yapan şirketlerin %73'ünün ilk iki yılda beklediği değeri elde edemediğini söylüyor. Sorun teknolojide değil — verinin sahibinin belirsiz olması, kaynağının izlenememesi ve kalitesinin ölçülememesi. Veri yönetimi tam da bu boşluğu kapatan disiplindir.

Veri Yönetimi Nedir?

Veri yönetimi (data management); verinin toplanması, depolanması, sınıflandırılması, korunması ve değere dönüştürülmesini kapsayan uçtan uca bir uygulamalar bütünüdür. Sadece DBA işi değildir: iş birimleri, hukuk, güvenlik ve mühendislik birlikte çalışır. DAMA-DMBOK çerçevesi bu alanı 11 ana bilgi alanına ayırır — mimari, modelleme, kalite, güvenlik, metadata, governance ve diğerleri.

Kurumların %68'lik karanlık verisinin neden okunmadığını anlamak için önce verinin yaşam döngüsünü tanımak gerekir.

Verinin Yaşam Döngüsü

Bir veri parçası kurumun içinde şu aşamalardan geçer: konunun teknik kaynakları konuya derinlemesine bir bakış sağlar.

Üretim: Uygulama logu, IoT sensörü, form girişi, üçüncü parti API.
Toplama (ingestion): Batch veya streaming hatlarla merkezi depoya akış.
Depolama: İlişkisel veritabanı, data lake (S3, ADLS), data warehouse (Snowflake, BigQuery).
İşleme: Temizleme, dönüştürme, zenginleştirme — ELT veya ETL süreçleri.
Tüketim: BI panelleri, ML modelleri, operasyonel uygulamalar.
Arşivleme veya silme: Yasal saklama süresi sonrası imha (KVKK, GDPR).

Bu döngünün her halkasında veri kalitesi düşebilir. Gartner'ın 2024 raporuna göre kötü veri kalitesi şirketlere yıllık ortalama 12,9 milyon dolar maliyet bindiriyor — yanlış raporlardan hatalı modellere kadar her şey buna dahil.

Data Governance: Sahiplik ve Kurallar

Data governance; verinin kim tarafından, hangi yetkiyle, hangi amaçla kullanılacağını belirleyen yönetişim katmanıdır. Üç temel rol vardır:

Data Owner: İş birimi içinden veri setinin nihai karar vericisi. Genelde direktör seviyesi.
Data Steward: Günlük kalite, tanım ve erişim taleplerini yöneten uzman.
Data Custodian: Teknik altyapıyı işleten DBA veya veri mühendisi.

Governance olmadan en güçlü data lake bile "data swamp"e dönüşür — kim ne koymuş, hangi alan ne anlama geliyor, kimsenin bilmediği bir bataklık. McKinsey'nin yayımladığı bir karşılaştırmaya göre olgun governance yapısına sahip şirketler, veriden değer üretmede rakiplerine kıyasla 2,5 kat daha hızlı.

Data governance üç rol Owner Steward Custodian üç sorumluluk badge ağacı hiyerarşi diyagramı

Data Lineage: Verinin İzini Sürmek

Lineage; bir veri noktasının kaynağından son raporda görüldüğü hücreye kadar geçtiği tüm dönüşümlerin haritasıdır. Üretim CRM'inden çıkan "müşteri_ciro" alanı kaç tabloda kopyalanmış, hangi join'lerden geçmiş, hangi panelde gösteriliyor — lineage bunu anlatır.

Lineage'ın değerini en net hissettiren an, bir raporda yanlış sayı çıktığında başlar. Lineage yoksa hatayı geriye doğru izlemek günler sürer; varsa dakikalar. Apache Atlas, OpenLineage ve Collibra gibi araçlar bu görünürlüğü sağlar. Ekip kurmadan önce veri mühendisliği temellerini görmek için data engineering eğitim programı içeriğini inceleyebilirsiniz.

Data Lake, Warehouse ve Lakehouse

Üç farklı depolama paradigması karşılaştırıldığında:

Data Warehouse: Şemaya bağlı, yapılandırılmış, BI için optimize. Snowflake, Redshift, BigQuery.
Data Lake: Ham veri, şema sonradan (schema-on-read). Düşük depolama maliyeti, esnek format desteği (Parquet, ORC, JSON).
Lakehouse: Lake esnekliği + warehouse performansı. Delta Lake, Iceberg, Hudi gibi tablo formatları ACID garantisi getirir.

2024 itibarıyla Fortune 500'ün %42'si lakehouse mimarisine geçiş yapmış durumda — bunun nedeni, ML iş yükleri ile klasik analitik raporlamayı aynı katmanda tutma ihtiyacı.

Veri Kalitesi ve Metadata

Veri kalitesi altı boyutta ölçülür: doğruluk, bütünlük, tutarlılık, güncellik, benzersizlik ve geçerlilik. Bu boyutları SLA'lerle takip etmek için Great Expectations, Soda veya Monte Carlo gibi araçlar yaygınlaşıyor.

Metadata yönetimi ise verinin verisidir — tablo açıklamaları, sahip bilgileri, sütun tanımları, kullanım istatistikleri. DataHub, Amundsen ve Atlan gibi açık katalog araçları bu metadata'yı keşfedilebilir hale getirir. Bir analistin "müşteri_id" alanının iki sistemde aynı şeyi mi ifade ettiğini sorması, iyi bir katalogla saniyeler içinde yanıtlanır.

Data Lake ham havuz Warehouse düzenli çekmece Lakehouse hibrit yapı üç mimari karşılaştırma

Güvenlik, KVKK ve Erişim

Veri yönetiminin yasal yüzü ihmal edildiğinde maliyeti yüksektir. KVKK, GDPR ve sektör özel düzenlemeler (BDDK, EPDK) kişisel verinin işlenmesi, saklanması ve silinmesi için net kurallar koyar. Pratikte uygulanan kontroller:

Rol bazlı erişim (RBAC) ve öznitelik bazlı erişim (ABAC).
Maskeleme: PII alanlarının (TCKN, IBAN) raporlarda gizlenmesi.
Şifreleme: at-rest ve in-transit.
Audit log: kim ne zaman hangi veriye eriştiğini izleme.
Tokenizasyon: hassas alanların tersine çevrilebilir tokenlerle değiştirilmesi.

Nereden Başlamalı?

Sıfırdan bir veri yönetimi pratiği kurmak büyük bir adım gibi görünür ama başlangıç noktası küçüktür: en kritik 3-5 veri setini belirleyin, bu setlerin sahibini atayın, tanımlarını yazılı hale getirin, kalite metriği koyun. Bu döngüyü genişletmek bir sonraki yılın işidir. Veri mimarisi tarafında derinleşmek için veri mühendisliği eğitiminden yararlanabilirsiniz.

Karanlık verinin %68'lik kısmını aydınlatmak bir gecede olmaz. Ama doğru çerçeveyle başlayan kurumlar, üç yıl içinde bu oranı %40'ın altına düşürüyor — ve hangi verinin gerçekten karar destekleyici olduğunu net biçimde görüyor.