Şirkette veri ambarı kurulumu hangi adımlarla yapılır?

Kuruluma teknolojiden değil sorulardan başla

Başarısız veri ambarı projelerinin ortak noktası, önce aracın seçilip sonra ne için kullanılacağının aranmasıdır. Kurulum, iş birimlerinin yanıtlanmasını istediği somut sorularla başlar: Hangi ürün hangi kanalda ne kadar satıyor? Müşteri kaybı hangi segmentte yoğunlaşıyor? Stok neden geç yenileniyor?

Bu soruları ilgili birimlerle birlikte listele ve her birinin hangi kaynak sistemlerdeki veriye dayandığını işaretle. Çıkan listeyi önceliklendir; ilk sürümde tamamlanabilecek küçük ama değerli bir iş süreciyle başla. Veri ambarını tek seferde bütün şirketi kapsayacak biçimde kurmaya çalışmak projeyi uzatır; Kimball yaklaşımında süreç süreç ilerlemek ve ortak boyutlarla süreçleri birbirine bağlamak bu yüzden önerilir.

Kaynak envanteri ve veri profili çıkar

Sonraki adım, soruları besleyecek kaynakların envanteridir: ERP, CRM, e-ticaret sistemi, web analitiği, tablo dosyaları. Her kaynak için sahibi kim, veriye nasıl erişilir (veritabanı, API, dosya), hangi sıklıkla güncellenir ve kişisel veri içeriyor mu bilgilerini kaydet.

Sonra veri profili çıkar: boş alan oranları, tekrarlayan anahtarlar, tutarsız kodlamalar, beklenmeyen değer aralıkları. Bu aşama genellikle iş birimlerinin güvendiği raporlar ile kaynak veri arasında fark bulunduğunu ortaya çıkarır. Farkın nedeni çoğunlukla tanım ayrılığıdır: satış rakamına iade dahil mi, tarih sipariş tarihi mi fatura tarihi mi. Bu tanımları kurulum öncesinde yazıya dök ve onaylat; sonradan değiştirmek çok pahalıdır.

Örneğin envanter tablosunda bir satır şöyle olabilir: Kaynak: sipariş yönetim sistemi. Sahip: satış operasyonları. Erişim: salt okunur veritabanı kopyası. Güncelleme: gün sonu. Hassas alan: müşteri iletişim bilgileri. Bu tablo, hangi kaynağın önce bağlanacağını ve hangi alanların maskeleneceğini baştan netleştirir.

Mimariyi ve katmanları belirle

Mimari karar şu konuları kapsar: platform (bulut veri ambarı, şirket içi veritabanı ya da lakehouse), veri akış biçimi (toplu, akış ya da karma) ve katman yapısı. Yaygın bir yerleşim, ham verinin olduğu gibi indiği bir hazırlık katmanı, temizlenmiş ve birleştirilmiş bir ara katman ve raporlamaya hazır, boyutsal modelle kurulmuş bir sunum katmanıdır. Ham katmanı saklamak, dönüşüm kuralı değiştiğinde veriyi kaynaktan yeniden çekmeden geçmişi yeniden işlemeyi mümkün kılar.

Platform seçerken şunlara bak: veri hacmi ve büyüme beklentisi, eşzamanlı kullanıcı yükü, mevcut ekibin yetkinlikleri, veri konumu ve güvenlik gereksinimleri, maliyetin kullanıma göre mi sabit mi olduğu. Ürünlerin güncel kapasite ve fiyat bilgisi hızlı değiştiği için karar anında satıcının güncel belgesine bak.

Modelleme: sunum katmanını boyutsal kur

Raporlayanın karşılaştığı katman olan sunum katmanı, iş süreci başına olgu tabloları ve ortak boyutlardan oluşur. Önce iş süreci, tane, boyutlar ve olgular belirlenir; sonra boyutların tarihsel değişimi nasıl izleyeceği alan bazında kararlaştırılır. Tarih, ürün, müşteri gibi boyutları baştan ortak ve tutarlı kurmak, sonraki süreçlerin aynı tanımlarla eklenmesini sağlar.

Modellemeyi belgelemek için bir veri sözlüğü tut: her tablo ve sütunun iş tanımı, kaynağı ve dönüşüm kuralı yazılsın. İş birimi bir rakama itiraz ettiğinde cevap bu sözlükte aranır. Modelleme ayrıntıları için yıldız şema tasarımı ve yavaş değişen boyut sayfaları ayrı ayrı ele alır.

Küçük bir kontrol: sunum katmanındaki her olgu tablosunun taneyi tek cümleyle anlatan bir açıklaması var mı ve iş birimi örnek sorularını yalnızca bu tablolarla yanıtlayabiliyor mu? Cevap hayırsa modelleme tamamlanmış sayılmaz.

Veri hattını kur: yükle, dönüştür, zamanla

Veri hattı kaynağı ham katmana yükleyen, ardından dönüşümlerle sunum katmanını besleyen sürecidir. Birçok modern ambarda yükleme önce, dönüşüm sonra yapılır (ELT); dönüşümler SQL ile ambarın içinde çalışır ve sürüm kontrolünde tutulur. Her hat için şunları tasarla: • Artımlı yükleme: yalnızca değişen kayıtları almak için bir değişiklik işareti ya da tarih alanı. • Tekrar çalıştırılabilirlik (idempotency): aynı yükleme yeniden çalışsa sonuç bozulmamalı. • Hata yönetimi: başarısız adım bildirim üretmeli, kısmi veri sunum katmanına geçmemeli. • Zamanlama ve bağımlılık: boyutlar olgulardan önce yüklenmeli, bunu bir iş akışı orkestrasyon aracı yönetmeli.

İlk sürümde hatları basit ve gözlemlenebilir tut; ölçekleme ve optimizasyon gerçek kullanım verisi geldikten sonra yapılır.

Test, güvenlik ve işletime alma

Canlıya almadan önce üretilen rakamları kaynak sistemin raporlarıyla karşılaştır. Satır sayıları, toplam tutarlar ve örnek kayıtlar üzerinden mutabakat yap; farkları iş birimiyle birlikte aç. Otomatik testler ekle: anahtar tekrarı yok, zorunlu alanlar dolu, değer aralıkları makul, veri belirlenen saatte güncellenmiş. Veri kalitesi izlemesi sonradan eklenecek bir süs değil, kurulumun parçasıdır.

Erişimi rol bazlı kur, kişisel veri içeren sütunları maskele ya da kısıtla ve KVKK kapsamındaki veriler için kimlerin neye eriştiğini kaydet. İşletime alırken kullanıcı eğitimi, destek kanalı ve değişiklik talebi süreci tanımla. Ambar bir kez kurulup bırakılan bir ürün değil, yeni süreçler ve değişen tanımlarla büyüyen bir ürün olarak yönetilmelidir.

İlk haftalarda kullanıcıların hangi tablolara baktığını ve hangi sorguların yavaş kaldığını izle. Kullanım verisi, hangi tabloların özet haline getirileceğini ve hangilerinin hiç kullanılmadığını gösterir; ölçekleme kararlarını bu veriye dayandır.

Mindset programlarında nerede çalışılır?

Bu yol, bir kurumda veri altyapısını sahiplenecek veri mühendisleri, BT ve analitik ekip liderleri için yazılmıştır. Veri Mühendisliği Programı; veri ambarı, veri gölü ve lakehouse mimarilerini, toplu ve akış tabanlı veri alımını, ELT tasarımını, orkestrasyonu ve veri kalitesi ile testi modül modül işler; bitirme projesi bulut üzerinde ölçeklendirme ve güvenlikle birleşir.

Sunum katmanını kurmakla görevli ekipler için Boyutsal Modelleme ve Kimball Metodolojisi eğitimi olgu ve boyut tablolarının tasarımına odaklanır.