Veri Ambarı Mimarisi Katman Katman Nasıl Kurulur

Ambarı depo değil, üretim hattı gibi düşünmek

Bir işletmede veri hiçbir zaman tek yerde durmaz. Sipariş e-ticaret panelinde, cari hesap muhasebe programında, teklifler bir klasördeki tablolarda, müşteri notları ise birinin telefonunda birikir. Bu dağınıklığı tek bir raporda toplamaya karar verdiğinizde asıl soru ortaya çıkar: veri ambarı mimarisi katman katman nasıl kurulur? Bu sorunun karşılığı bir ürün adı değil, verinin kaynaktan rapora kadar izlediği yolun tasarımıdır. Her katman bir öncekinin çıktısını alır, kendi işini yapar ve bir sonrakine devreder. Katmanları atlayıp doğrudan gösterge paneli kurmaya çalışmak, üretim hattının ortasına makine koyup hammaddeyi unutmaya benzer.

Katmanlı düşünmenin en somut faydası şudur: bir rakam yanlış çıktığında nerede yanlış çıktığını bilirsiniz. Hata ya kaynak sistemde, ya veriyi alma adımında, ya dönüştürmede, ya da metriğin tanımındadır. Katmansız kurulmuş bir yapıda bu dört ihtimal birbirine karışır ve her tartışma "ben bu rapora güvenmiyorum" cümlesiyle biter. Aşağıdaki bölümler, veri ambarı mimarisi katmanlarının her birinin ne işe yaradığını, hangi kararın nerede verilmesi gerektiğini ve kurulumların pratikte nerelerde takıldığını sırayla anlatıyor.

Kaynak katmanı: veri nereden geliyor

İlk katman aslında sizin değil. Kaynaklar, ambardan bağımsız olarak çalışan sistemlerdir: muhasebe yazılımı, e-ticaret altyapısı, CRM, üretim takibi, ödeme sağlayıcısı, pazaryeri panelleri, çağrı kayıtları ve kaçınılmaz olarak elektronik tablolar. Kurulumun ilk işi bu kaynakların envanterini çıkarmaktır.

Envanter çıkarırken her kaynak için dört şeyi yazın: veriye nasıl erişiliyor (veritabanı, API, dosya aktarımı, elle dışa aktarma), veri ne sıklıkla değişiyor, kayıtları benzersiz kılan alan ne, ve bu sistemin sahibi kim. Dördüncü soru teknik görünmez ama en çok zamanı o kazandırır; bir alanın ne anlama geldiğini yalnızca o sistemi kullanan kişi bilir.

• Erişim biçimi alım katmanının nasıl kurulacağını belirler.
• Değişim hızı güncelleme sıklığını belirler; günde bir kez yeten veriyle dakikalık veriyi aynı boruya koymayın.
• Benzersiz alan olmadan iki kaynağı birleştiremezsiniz; müşteri eşleşmesi çoğu projede burada tıkanır.
• Sahiplik, tanım tartışmasını kimin kapatacağını belirler.

Kaynak envanteri çıkmadan araç seçmeyin. Elektronik tablolarla yürüyen süreçlerin nerede tıkandığını daha önce Excel ile iş takibinin sınırlarını anlatırken ayrıntılandırmıştık; ambar kurulumunda o tablolar da birer kaynaktır, yok sayılmaz.

Alım katmanı: kopyalamak mı, akıtmak mı

Alım katmanı, kaynaktaki veriyi ambara taşıyan mekanizmadır. Üç temel yöntem vardır ve seçim maliyeti doğrudan etkiler.

Tam yükleme: tabloyu her seferinde baştan çeker. Kurması en kolay, çalıştırması en pahalı yöntemdir. Küçük ve yavaş değişen tablolar için fazlasıyla yeterlidir; ürün kategorileri, şube listesi, personel tablosu gibi.

Artımlı yükleme: yalnızca son alımdan sonra değişen kayıtları çeker. Bunun için kaynakta güvenilir bir güncelleme zaman damgası veya artan bir kimlik alanı gerekir. Kaynak sistem güncellemede zaman damgasını tazelemiyorsa artımlı yükleme sessizce veri kaybettirir; bu yüzden ilk kurulumda mutlaka tam yüklemeyle karşılaştırıp doğrulama yapılır.

Değişiklik yakalama: veritabanının kendi kayıt günlüğünden ekleme, güncelleme ve silme işlemlerini okur. Silinen kayıtları da gördüğü için en doğru sonucu verir, ancak kaynak veritabanında yetki ve yapılandırma ister. Her işletmenin buna ihtiyacı yoktur.

Bu katmanda verilecek ikinci karar veriyi dönüştürmeden mi yoksa dönüştürerek mi taşıyacağınızdır. Klasik ETL süreci dönüşümü yolda yapar: veri kaynaktan çıkar, ara bir katmanda temizlenir, ambara temizlenmiş hâliyle girer. Bugün yaygınlaşan yaklaşımda ise sıra değişir; veri önce ham hâliyle ambara indirilir, dönüşüm ambarın içinde çalıştırılır. İkincisi, bir iş kuralı değiştiğinde geçmişi yeniden üretebilmenizi sağladığı için küçük ekiplerde belirgin biçimde daha kullanışlıdır.

Ham katman: hiçbir şeyi düzeltmeden saklayın

Ham katman, kaynaktan geleni geldiği gibi tutar. Sütun adı saçma olsa, tarih metin olarak gelse, aynı müşteri üç farklı yazımla kayıtlı olsa bile burada düzeltme yapılmaz. Amaç, kaynağın o andaki hâlinin sadık bir kopyasını elde tutmaktır.

Bu katman gereksiz görünür, ilk elenmek istenen odur ve kaldırıldığında maliyeti en yüksek olan da odur. Sebebi basit: dönüşüm kuralları zamanla değişir. Altı ay sonra "iade edilen siparişi ciroya sayma" kuralını eklediğinizde, geçmiş dönemi yeniden hesaplayabilmeniz için ham verinin durması gerekir. Ham katmanı atmışsanız geçmiş yeniden üretilemez; elinizde yalnızca eski kuralla hesaplanmış sonuçlar kalır.

Ham katmanda iki alışkanlık işe yarar: her satıra verinin ne zaman alındığını yazan bir alan eklemek ve yükleme partilerini ayırt eden bir parti kimliği tutmak. Bir gün rakamlar oynadığında, hangi yüklemenin neyi değiştirdiğini yalnızca bu iki alan sayesinde bulabilirsiniz.

Dönüştürme katmanı: temizlik ve iş kuralları

Asıl emek buraya gider. Dönüştürme katmanında ham veri kullanılabilir hâle getirilir ve işletmenin kuralları koda dökülür. Tipik olarak şu işler yapılır:

• Tip düzeltme: metin olarak gelen tarih ve tutarların gerçek tarih ve sayı tipine çevrilmesi.
• Tekilleştirme: aynı kaydın iki kez alınmış kopyalarının ayıklanması.
• Standartlaştırma: il adlarının, birim kodlarının, para birimlerinin tek yazıma indirilmesi.
• Eşleştirme: farklı sistemlerdeki aynı müşteriye tek bir iç kimlik verilmesi.
• İş kuralı: iptal, iade, indirim, komisyon ve vergi kalemlerinin ciroya nasıl yansıyacağının tanımlanması.

Son madde teknik değil, ticari bir karardır ve teknik ekip tek başına veremez. Kurulumların çoğu tam burada yavaşlar: iki departman ciroyu farklı sayıyordur ve ambar bu farkı ilk kez görünür kılar. Bu bir arıza değil, veri ambarı mimarisinin ilk faydasıdır.

Dönüşümleri elle çalıştırılan betiklerle değil, sürüm kontrolünde duran ve tekrar çalıştırılabilir adımlarla kurun. Bir dönüşüm adımının iki kez çalıştırıldığında aynı sonucu vermesi, gece yarısı yarım kalan bir yüklemeyi düzeltmenin tek pratik yoludur.

Model katmanı: olgu ve boyut tabloları

Temizlenmiş veri hâlâ kaynak sistemin mantığıyla düzenlenmiştir. Model katmanı onu raporlama mantığına çevirir. En yaygın ve en dayanıklı yöntem boyutlu modellemedir: ölçülen olayları olgu tablolarına, bu olayları tarif eden nitelikleri boyut tablolarına ayırırsınız.

Bir satış olgusu tablosunda tarih, müşteri, ürün, kanal gibi anahtarlar ile adet, tutar, indirim gibi ölçüler bulunur. Müşterinin adı, sektörü, şehri ise müşteri boyutundadır. Rapor yazan kişi böylece "hangi şehirde hangi üründen ne kadar satmışız" sorusunu tek bir birleştirmeyle sorabilir.

Değişen bilgiyi nasıl saklarsınız

Boyutlardaki bilgi zamanla değişir: müşteri şehir değiştirir, ürün kategorisi yeniden adlandırılır, satış temsilcisi değişir. Burada bilinçli bir karar vermeniz gerekir. Bilgiyi üzerine yazarsanız geçmiş raporlar bugünkü hâliyle görünür; eski değeri ayrı bir satırda tarihiyle saklarsanız geçmiş, o günkü hâliyle korunur. İkisi de doğrudur, ama hangisini seçtiğinizi bilmeden rapor yorumlamak yanıltıcıdır. Kurulumda genellikle küçük bir boyut kümesi için tarihçe tutulur, gerisi için üzerine yazılır.

Model katmanının bir başka görevi tarih tablosudur. Mali yıl, hafta numarası, tatil günleri ve çalışma günü sayısı gibi bilgileri tek bir tarih boyutunda tutmak, her raporda yeniden hesaplanan tarih mantığından kurtarır.

Sunum katmanı: metriğin tek tanımı

Sunum katmanı, iş birimlerinin doğrudan kullandığı görünümlerdir. Buradaki asıl mesele hız değil, tanımdır. "Aktif müşteri" tanımı satışta ve finansta farklıysa iki panel aynı veriden farklı sayı üretir ve güven biter. Bu yüzden metrikler tek bir yerde, adı, formülü ve sahibiyle birlikte tanımlanır; panel araçları kendi içlerinde formül türetmez, buradan okur.

Küçük yapılarda bu katman birkaç görünümden ibaret olabilir. Büyüdükçe departman bazlı veri pazarlarına ayrılır: satış, finans, operasyon. Ayırma kararını kullanıcı sayısına göre değil, tanım çatışmasına göre verin. Aynı metriği iki departman farklı tanımlıyorsa iki ayrı görünüm, tek karışık görünümden iyidir.

Erişim katmanı: kim neyi görebilir

Veriyi tek yerde toplamak, riski de tek yerde toplar. Erişim katmanı bu yüzden veri ambarı mimarisinin isteğe bağlı parçası değildir. En az şu üç ayrım kurulur: satır bazlı yetki (bölge müdürü yalnız kendi bölgesini görür), sütun bazlı gizleme (kişisel veriler ve maaş bilgileri sınırlı role açılır) ve okuma-yazma ayrımı (rapor kullanıcısı hiçbir koşulda yazma yetkisi almaz).

Kişisel veri içeren alanlarda saklama süresi de bu katmanda tanımlanır. Ambar, kaynak sistemde silinen bir kaydı yıllarca taşımaya devam edebilir; bunun farkında olarak bir silme veya maskeleme kuralı yazmak gerekir.

Veri Ambarı Mimarisini Ayakta Tutan Üç Dikey Sütun

Yukarıdaki katmanlar yatay akışı anlatır. Üçü ise akışa dik olarak her katmana dokunur ve genellikle en son düşünüldükleri için sorun çıkarırlar.

Orkestrasyon: hangi adımın hangisinden sonra çalışacağını, bir adım başarısız olursa ne olacağını yöneten katmandır. Zamanlanmış görevlerle kurulan sıralar, bağımlılık büyüdükçe dağılır; adımlar arasında gerçek bağımlılık tanımlayabilen bir yapı gerekir.

Veri kalitesi testleri: her yüklemeden sonra otomatik çalışan kontrollerdir. Boş olmaması gereken alan boş mu, benzersiz olması gereken anahtar tekrarlamış mı, bugünkü satır sayısı dünkünden anlamsız biçimde sapmış mı. Testi olmayan ambarda hatayı raporu okuyan kişi bulur ve o noktadan sonra ambara güven zordur.

Metaveri ve izlenebilirlik: hangi alanın nereden geldiğini, hangi dönüşümden geçtiğini ve hangi raporu beslediğini gösteren kayıttır. Bir kaynak sütunu değiştiğinde hangi raporların etkileneceğini bu kayıt olmadan tahmin edemezsiniz.

Veri Ambarı Mimarisi Katman Katman Nasıl Kurulur Sorusunda En Sık Yapılan Dört Hata

Kurulumları geriye dönüp incelediğimizde aynı dört hata tekrar eder. Birincisi, ham katmanı atlayıp veriyi alırken temizlemektir; kural değiştiğinde geçmiş kurtarılamaz. İkincisi, metrik tanımını panel aracının içine gömmektir; araç değişince tanım da kaybolur. Üçüncüsü, kalite testlerini "sonra ekleriz" diye ertelemektir; ertelenen test hiç eklenmez. Dördüncüsü ve en pahalısı, kaynak sistemin sahibini sürece katmadan model kurmaktır; alanın gerçek anlamı yanlış varsayılır ve hata modelin en altına gömülür.

Gerçekçi bir kurulum sırası

Bütün katmanları aynı anda kurmaya çalışmak, projeyi ilk raporu görmeden bitirmenin en kestirme yoludur. Uygulamada veri ambarı mimarisi katman katman nasıl kurulur, en iyi dar bir iş sorusuyla başlayıp o sorunun cevabını uçtan uca üreterek görülür. İşleyen sıra şudur:

• Tek bir iş sorusu seçin. "Aylık ciro kanal kırılımıyla" gibi dar ve tartışmasız bir soru olsun.
• O soruyu cevaplamak için gereken en az sayıda kaynağı bağlayın; genellikle iki tanedir.
• Ham katmanı ve alım işlerini kurun, birkaç gün boyunca yükleme günlüklerini izleyin.
• Dönüşümü ve tek bir olgu tablosunu yazın, yanına iki üç boyut ekleyin.
• İlk raporu çıkarın ve kaynak sistemin kendi ekranıyla karşılaştırın. Fark varsa sebebini bulmadan devam etmeyin.
• Kalite testlerini ekleyin, sonra ikinci iş sorusuna geçin.

Bu sıra, her adımda çalışan bir çıktı bırakır. İkinci ve üçüncü soru geldiğinde katmanlar zaten kuruludur; eklenen yalnızca yeni kaynak ve yeni modeldir. Ambarın ne zaman gerçekten gerektiğini, hangi eşiklerin bu yatırımı haklı çıkardığını daha önce veri ambarının hangi eşikte gerektiğini anlatan yazıda ele almıştık; buradaki katman sırası, o eşiği geçtikten sonrası içindir.

Kurulumdan sonra ambarın bakımı

Ambar biten bir iş değildir. Kaynak sistemler sürüm değiştirir, alan adları değişir, yeni bir pazaryeri eklenir, bir metriğin tanımı güncellenir. Bu yüzden kurulumun son adımı bir sahiplik tanımıdır: yükleme hatasına kim bakacak, yeni kaynak talebini kim karşılayacak, metrik tanımı değiştiğinde kim onaylayacak.

Kurumsal veri ambarı projelerinde bu roller yazılı olarak dağıtılır; küçük ekiplerde ise çoğu zaman dışarıdan alınır. Önemli olan rolün boş kalmamasıdır. Sahipsiz ambar birkaç ay içinde sessizce eskir ve kimse fark etmeden yanlış rakam üretmeye başlar. Katmanlı kurulan bir veri ambarı mimarisinde bakım da katman katman yapılabilir: bozulan yeri değiştirirsiniz, bütünü yeniden kurmazsınız.

Kendi yapınızı kurarken hangi katmanda olduğunuzu görmek isterseniz veri ambarı danışmanlığı ve iş zekâsı hizmetimizin kapsamına bakabilir, kaynak sayısı ve rapor ihtiyacınıza göre kapsam bazlı bir teklif isteyebilirsiniz. Kaynak sistemlerinizden biri hazır bir ürünle karşılanmıyorsa özel çözüm geliştirme tarafı da aynı mimarinin içine bağlanabilir.