Bankda veri anbarı (DWH) layihələri müəssisənin ən kritik investisiyalarından biridir: tənzimləyici hesabatlar, risk hesablamaları, müştəri 360 və performans analizləri hamısı bu qatdan qidalanır. Lakin layihə uğursuzluqlarının böyük əksəriyyəti texniki seçimdən deyil, arxitektura disiplininin çatışmazlığından qaynaqlanır. Böyük ölçülü bank DWH layihələrində sıxlıqla qarşılaşılan beş kritik qərar.
1. Mənbə Sistem İnteqrasiyası: Batch yoxsa CDC?
Core banking verilənlər bazasından DWH-a məlumat axınında klassik gecə batch job hələ də geniş yayılıb. Lakin tənzimləyici hesabat sıxlığının gündəlikdən aşağı düşməsi (BDDK bəzi hesabat tiplərində tələb edir) CDC (Change Data Capture) inteqrasiyalarını məcburi etdi. Debezium/Kafka əsaslı həllər core sistemin performansına təsir etmədən dəyişiklikləri axıdır.
2. Tarixi Veri Modeli: SCD Type 2 Hər Yerdə Deyil
Slowly Changing Dimension Type 2 (tarixi qoruma) hər dimension üçün tələb olunmur. Müştəri ünvanı dəyişikliyi üçün Type 2 şərtdir; lakin məhsul kateqoriyası üçün Type 1 (üstündən yazma) kifayət edə bilər. Həddindən artıq Type 2 istifadəsi saxlama həcmini 3-4 dəfə şişirdir və sorğu performansını azaldır. Hər dimension üçün biznes ehtiyacı ayrıca qiymətləndirilməlidir.
3. Tənzimləyici Hesabat ilə Analitik Hesabat Ayrımı
BDDK, TCMB, MASAK hesabatları üçün məlumat dəyişməz olmalıdır: eyni hesabatı bir il sonra eyni parametrlərlə istehsal edə bilmək məcburdur. Bu səbəbdən tənzimləyici qat analitik qatdan izolə edilməlidir. Tövsiyəmiz: fact cədvəllərinin bir regulatory snapshot versiyası, bir də analytics current versiyası ayrı saxlanılır.
4. Performans: Partitioning və Clustered Columnstore
SQL Server və Azure Synapse əsaslı DWH-larda tarix əsaslı partitioning + clustered columnstore index, xüsusilə 50M+ qeydi olan fact cədvəllərində sorğu müddətini 90%-ə qədər azaldır. Bu konfiqurasiya layihə başlanğıcında qurulmadıqda, sonradan əlavə edilməsi böyük bir yenidən yükləmə və downtime tələb edir.
5. İcazə və Giriş: Row-Level Security və Veri Maskalama
Müştəri vergi kimliyi, hesab balansı kimi kritik məlumatlar DWH-da olmalıdır — lakin hər tərtibatçı və analitik onlara baxmamalıdır. KVKK uyğunluğu üçün həm row-level security (filial müdiri yalnız öz filialının müştərilərini görür) həm də column-level masking (analitik vergi kimliyini hash kimi görür) eyni vaxtda qurulmalıdır.
