Bankacılıkta veri ambarı (DWH) projeleri, kurumun en kritik yatırımlarından biridir: regülatör raporları, risk hesaplamaları, müşteri 360, performans analizleri hep bu katmandan beslenir. Ancak proje başarısızlıklarının büyük çoğunluğu teknik seçimden değil, mimari disiplinden eksik kalmaktan kaynaklanır. Büyük ölçekli banka projelerinde sık karşılaşılan beş kritik karar.
1. Kaynak Sistem Entegrasyonu: Batch mı CDC mi?
Core banking veritabanından DWH'a veri akışında klasik gece batch job hâlâ yaygın. Ancak regülatör raporlama sıklığının günlük altına düşmesi (BDDK'nın bazı rapor tiplerinde), CDC (Change Data Capture) entegrasyonlarını zorunlu kıldı. Debezium/Kafka bazlı çözümler core sistemin performansını etkilemeden değişiklikleri akıtır.
2. Tarihsel Veri Modeli: SCD Type 2 Her Yerde Değil
Slowly Changing Dimension Type 2 (tarihsel koruma) her boyut için gerekli değil. Müşteri adres değişikliği için Type 2 şart; ama ürün kategorisi için Type 1 (üzerine yazma) yeterli olabilir. Aşırı Type 2 kullanımı depolamayı 3-4 katına çıkarır ve sorgu performansını düşürür. Her boyut için iş ihtiyacı ayrı değerlendirilmelidir.
3. Regülatör Raporu ile Analitik Rapor Ayrımı
BDDK, TCMB, MASAK raporları için veri değişmez olmalıdır: aynı raporu bir yıl sonra aynı parametrelerle üretebilmek zorundayız. Bu yüzden regülatör katmanı, analitik katmandan izole tutulmalıdır. Önerimiz: Fact tablolarının bir regulatory snapshot versiyonu, bir de analytics current versiyonu ayrı tutulur.
4. Performans: Partitioning ve Clustered Columnstore
SQL Server ve Azure Synapse tabanlı DWH'larda tarih bazlı partitioning + clustered columnstore index, özellikle 50M+ kayıt olan fact tablolarında sorgu süresini %90'a kadar düşürür. Bu konfigürasyon proje başında kurulmazsa, sonradan eklenmesi büyük bir yeniden yükleme ve downtime gerektirir.
5. İzin ve Erişim: Row-Level Security ve Veri Maskeleme
Müşteri TC kimlik numarası, hesap bakiyesi gibi kritik veriler DWH'ta durmak zorunda — ama her geliştirici ve analist bunlara erişmemeli. KVKK uyumu için hem row-level security (şube sorumlusu sadece kendi şube müşterilerini görür) hem column-level masking (analist TC'yi hash olarak görür) aynı anda kurulmalıdır.
