- Ortak zemin: analiz için düzenlenmiş veri
- Temel farklar ölçüt ölçüt
- Martın üç türü: bağımlı, bağımsız, karma
- Mimari yaklaşım: merkezden martlara mı, süreçlerden ambara mı?
- Örnek: perakendede ortak tanım sorunu
- Hangisi ne zaman, birlikte nasıl kullanılır?
- Mindset programlarında ambar ve mart tasarımı
- Sık sorulan sorular
Veri Ambarı mı Veri Martı mı? Kapsam, Kullanıcı ve Mimari Farkı
Veri martı küçültülmüş bir veri ambarı değil, kurumsal verinin belirli bir ekip ya da konu için biçimlendirilmiş bir dilimidir. Asıl tasarım kararı, martların ambardan mı beslendiği yoksa ondan bağımsız mı kurulduğudur.
Bir bakışta
- Veri ambarı kurumun birçok konusuna ait entegre veriyi, veri martı tek bir konuya ya da departmana ait seçilmiş veriyi tutar. Mart daha az tablo içerir, daha az kişiye hizmet eder ve şeması daha kolay değiştirilir.
- Bağımlı veri martı ambardan beslenir; bağımsız veri martı kaynak sistemlerden doğrudan yüklenir. Bağımsız martlar hızlı kurulur ama aynı metriğin birbirini tutmayan tanımlarını üretmeye açıktır.
- Kimball yaklaşımında süreç bazlı modelleri tek bir ambar yapan şey uyumlu boyutlardır. Müşteri, ürün ve tarih gibi boyutlar bir kez tanımlanır ve her iş sürecinde aynen kullanılır.
- Mart bugün çoğu zaman ayrı bir sunucu değil, ambarla aynı platformdaki bir şema ya da görünüm kümesidir. Kapsam ve kullanıcı ayrımı sürer; fiziksel ayrım bir tercih hâline gelmiştir.
Ortak zemin: analiz için düzenlenmiş veri
Veri ambarı da veri martı da günlük işlemleri yürüten operasyonel sistemlerden ayrı tutulan, analiz ve raporlama için düzenlenmiş veri depolarıdır. İkisinde de veri kaynak sistemlerden ETL ya da ELT süreçleriyle alınır, temizlenir, anlamlı adlarla düzenlenir ve geçmişiyle saklanır. İkisi de çoğunlukla olgu ve boyut tablolarından oluşan yıldız şema gibi okumaya uygun modellerle tasarlanır ve yazma işlemlerinden çok sorgulama için iyileştirilir.
Aradaki fark yöntemde değil, kapsamdadır. AWS'nin tanımıyla veri ambarı kurum genelinde birçok konuya ait veriyi içerir; veri martı ise bir iş birimine özgü, belirli bir konuyla yakından ilgili bilgiyi tutan daha küçük bir depodur. Türkçe kaynaklarda veri martı için "veri pazarı" adı da kullanılır.
Temel farklar ölçüt ölçüt
- Kapsam: Veri ambarı, satış, finans, stok, insan kaynakları gibi birçok konuyu kurum genelinde birleştirir / Veri martı, tek bir konuya, departmana ya da iş sürecine odaklanır.
- Kullanıcı: Veri ambarı, birçok ekip, analist ve veri ekibi tarafından kullanılır / Veri martı, belirli bir departmanın daha sınırlı bir kullanıcı grubuna hizmet eder.
- Kaynak: Veri ambarı, çok sayıda operasyonel sistemden beslenir / Veri martı, çoğunlukla ambardan beslenir; bağımsız kurulmuşsa birkaç kaynak sistemden doğrudan yüklenir.
- Büyüklük: Veri ambarı, çok sayıda tablo ve uzun bir geçmiş tutar / Veri martı, daha küçüktür ve daha az tablo içerir.
- Ayrıntı düzeyi: Veri ambarı, en ayrıntılı işlem düzeyindeki veriyi saklar / Veri martı, departmanın sorusuna göre ayrıntılı ya da özetlenmiş veri sunar.
- Değişiklik: Veri ambarı, birçok ekibi etkilediği için değişiklikleri yavaş ve kontrollü yapılır / Veri martı, şeması daha basit olduğu için daha kolay güncellenir.
- Erişim: Veri ambarı, geniş bir kullanıcı kitlesi için rol bazlı erişim gerektirir / Veri martı, departmana göre daha dar ve ince ayarlı erişim tanımlamayı kolaylaştırır.
Yöntem ortak; kapsam, kullanıcı ve değişiklik hızı ayrışır
| Veri ambarı | Veri martı | |
|---|---|---|
| Kapsam | Kurum geneli, birçok konu | Tek konu, departman ya da süreç |
| Kullanıcı | Birçok ekip ve veri ekibi | Belirli bir departmanın kullanıcıları |
| Kaynak | Çok sayıda operasyonel sistem | Çoğunlukla ambar; bağımsızsa kaynak sistemler |
| Büyüklük | Çok tablo, uzun geçmiş | Daha küçük, daha az tablo |
| Ayrıntı | En ayrıntılı işlem düzeyi | Soruya göre ayrıntılı ya da özet |
| Değişiklik | Yavaş ve kontrollü | Daha basit şema, daha hızlı |
Martın üç türü: bağımlı, bağımsız, karma
Veri martını ambardan ayıran asıl tasarım sorusu, martın verisini nereden aldığıdır. AWS bu açıdan üç tür tanımlar.
- Bağımlı veri martı, merkezi veri ambarındaki bilginin bir alt kümesiyle doldurulur. Veri bir kez temizlenip entegre edildiği için bütün martlar aynı tanımları paylaşır; yönetim ambarda kalır. Bedeli, ambardaki bir arızanın ona bağlı bütün martları etkilemesidir.
- Bağımsız veri martı, merkezi bir ambara ya da başka bir marta dayanmaz; kaynak sistemlerden doğrudan yüklenir. Kurulumu daha kolaydır ve tek bir ekibin acil ihtiyacını hızla karşılar. Ancak yönetimi zordur: her bağımsız mart kendi dönüşüm kurallarını yazar ve iyi bir veri kataloğu olmadan hangi martta neyin ne anlama geldiği izlenemez.
- Karma veri martı, veriyi hem ambardan hem dış kaynaklardan toplar. Ekiplerin yeni bir veri kaynağını, ambara taşımadan önce denemesine olanak verir.
Bağımlı mimaride akış tek yönlüdür: kaynaklardan ambara, ambardan martlara, martlardan rapora. Tek doğru kaynak ambardır; mart yalnız onu belirli bir ekibin ihtiyacına göre keser ve biçimlendirir.
Bağımlı mimaride mart, ambarı keser; yeni bir doğru kaynak yaratmaz
- Kaynak sistemlerKasa, e-ticaret, CRM, ERP ve insan kaynakları sistemleri
- Veri ambarıTemizlenmiş, entegre edilmiş, geçmişiyle saklanan kurumsal veri
- Veri martlarıSatış, finans, pazarlama gibi ekiplere göre seçilmiş alt kümeler
- Raporlar ve panolarDepartmanın kendi sorularına yanıt veren analizler
Mimari yaklaşım: merkezden martlara mı, süreçlerden ambara mı?
Veri ambarı tasarımında iki yerleşik yaklaşım, martın rolünü farklı tanımlar. Bill Inmon'un adıyla anılan yaklaşımda önce normalleştirilmiş, kurum genelinde tek bir ambar kurulur; departman martları bu merkezden türetilen bağımlı martlardır. Merkez güçlüdür, ama ilk sonuçlar geç gelir.
Ralph Kimball'ın adıyla anılan yaklaşım ise ambarı iş süreci bazında, adım adım kurar. Kimball Group'un tarifiyle bu "bus" mimarisi, kurumun temel iş süreçleri ve bunlara ait uyumlu boyutlar etrafında örgütlenir. Uyumlu boyutlar bir kez yönetilen ortak ana boyutlardır; birden fazla olgu tablosu onları yeniden kullanır, böylece süreçler arasında tutarlı karşılaştırma yapılabilir. Bus matrisi kurum genelinin yukarıdan aşağı planını verirken teslimat aşağıdan yukarı, her seferinde tek bir iş süreciyle ilerler. Bu gelenekte süreç bazlı boyutsal modellere sıkça mart denir; ambar, uyumlu boyutlarla birbirine bağlanmış bu modellerin bütünüdür.
Pratik sonuç şudur: Kimball yaklaşımında bir mart, uyumlu boyutları paylaştığı sürece bağımsız bir ada değildir. Ortak boyutlar olmadan kurulan süreç modelleri ise yeniden bağımsız mart dağınıklığına döner.
Örnek: perakendede ortak tanım sorunu
Bir perakende şirketinde pazarlama ekibi, kampanya sonuçlarını hızla görmek için CRM ve e-ticaret verisinden kendi veri martını kurar. Aynı dönemde finans ekibi gelir raporlarını kurumsal ambardan alır. Yönetim toplantısında iki ekip "aktif müşteri" sayısını farklı sunar: pazarlama martı son kampanyaya tıklayanları da aktif sayar, ambar ise yalnız alışveriş yapanları. İki rakam da kendi içinde doğrudur; ama aynı sözcük iki farklı tanıma bağlanmıştır.
Çözüm martı kaldırmak değildir. Müşteri boyutu ve aktif müşteri tanımı ambarda bir kez yazılır; pazarlama martı bu ortak boyutu kullanan bağımlı bir marta dönüştürülür ve kampanyaya özgü alanlar onun üzerine eklenir. Pazarlama ekibi yine kendi tablolarında hızlı çalışır, ama müşteri sayımı bütün raporlarda aynı kuraldan gelir. Bundan sonra eklenecek her yeni mart, işe ortak boyut listesine bakarak başlar.
Hangisi ne zaman, birlikte nasıl kullanılır?
Veri ambarı ile veri martı çoğu zaman birbirinin alternatifi değil, aynı mimarinin iki katmanıdır. Seçim, ihtiyacın kapsamına ve ambarın var olup olmadığına göre yapılır.
- Birden fazla departmanın aynı müşteri, ürün ve gelir verisini tutarlı görmesi gerekiyorsa kurumsal veri ambarı temel alınır.
- Ambar varsa ve tek bir ekip daha odaklı, hızlı bir çalışma alanı istiyorsa ambardan beslenen bağımlı bir mart kurulur.
- Ambar yoksa ve tek bir acil ihtiyaç bekliyorsa bağımsız bir mart başlangıç olabilir; ama ortak boyutlarla ve ileride ambara taşınacağı varsayımıyla tasarlanmalıdır.
- Yeni bir veri kaynağı denenecekse karma mart, kaynağı ambara almadan önce değerini görmeyi sağlar.
Sık yapılan hatalar da bu tablodan çıkar: her departmana ayrı bağımsız mart kurmak, martı ambarın birebir kopyası yapmak ve metrik tanımlarını her martta yeniden yazmak. Bulut veri platformlarında mart çoğu zaman ayrı bir sunucu değil, ambarla aynı platformdaki bir şema ya da görünüm kümesidir; bu, fiziksel kopyayı azaltır ama tanım birliği ihtiyacını ortadan kaldırmaz.
Seçimi ihtiyacın kapsamı ve ambarın varlığı belirler
- Birden fazla departman aynı veriyi tutarlı görmeliKurumsal veri ambarı
- Ambar var, tek bir ekip odaklı alan istiyorAmbardan beslenen bağımlı mart
- Ambar yok, tek bir acil ihtiyaç varBağımsız mart, ortak boyutlarlaİleride ambara taşınacak biçimde tasarlanır
- Yeni bir veri kaynağı denenecekKarma martKaynak, ambara alınmadan önce denenir
Mindset programlarında ambar ve mart tasarımı
Boyutsal Modelleme ve Kimball Metodolojisi, olgu ve boyut tablolarının tasarımını, tarihsel değişimin izlenmesini ve ileri modelleme tekniklerini ele alır; martları ortak boyutlarla tutarlı kurmak isteyen veri ambarı ve iş zekası geliştiricileri için en doğrudan programdır. Veri Mühendisliği Programı, "Veri Ambarı, Veri Gölü ve Lakehouse Mimarileri" bölümüyle ambarın daha geniş veri platformundaki yerini ve besleme süreçlerini kapsar.
Star Schema ve Snowflake Schema Tasarımı ise sunum katmanı ve iş zekası entegrasyonu üzerinden, martın raporlama araçlarına nasıl açıldığına odaklanır.
İlgili Mindset programı
Boyutsal Modelleme ve Kimball Metodolojisi
Sık sorulan sorular
Veri martı ile veri ambarı aynı veritabanında olabilir mi?
Evet. Mart mantıksal bir ayrımdır; ayrı bir sunucu gerektirmez. Aynı platformda departmana özel bir şema, ambar tablolarından türetilen görünümler ya da özet tablolar mart görevi görebilir. Bu düzen veri kopyasını ve taşıma işini azaltır. Ayrı fiziksel mart ise ağır sorguların ambarı yavaşlatması, farklı erişim kuralları ya da departmanın kendi aracına özel bir yapı gerektiğinde tercih edilir.
Veri martı ile OLAP küpü aynı şey mi?
Hayır. Veri martı, belirli bir konuya ait tabloları tutan bir veri deposudur. OLAP küpü ise ölçüleri boyutlara göre önceden hesaplayıp çok boyutlu biçimde sunan bir analiz yapısıdır; kullanıcı bölge, ürün ve dönem arasında hızla dilimleme yapabilir. Küp çoğu zaman bir martın ya da ambarın üzerine kurulur. Yani mart verinin nerede ve hangi kapsamda durduğunu, küp ise o veriyle nasıl hızlı gezinildiğini anlatır.
Veri martı ile veri gölü arasında nasıl bir ilişki var?
Veri gölü, ham ve çeşitli veriyi şema dayatmadan geniş ölçekte saklar; veri martı ise belirli bir ekip için düzenlenmiş, şeması belli bir alt kümedir. Modern mimarilerde göl ham katman olarak çalışabilir, ambar ya da lakehouse katmanı veriyi temizleyip entegre eder, martlar da bu katmanın üzerinde departmanlara açılır. Göl doğrudan bir ekibe mart gibi sunulduğunda tanım ve kalite sorunları kullanıcının üzerine kalır.
Bağımsız veri martı her zaman kötü bir seçim midir?
Hayır. Ambarı olmayan bir şirkette tek bir ekibin acil analiz ihtiyacını karşılamanın hızlı yolu olabilir ve değer kanıtladığında daha geniş bir ambar yatırımını gerekçelendirebilir. Sorun, bağımsız martların plansız çoğalmasıdır. Müşteri, ürün ve tarih gibi boyutlar baştan ortak tanımlanır ve veri kataloğuna işlenirse bağımsız başlayan bir mart sonradan ambara bağlanabilir.
İlgili rehberler
İlgili eğitimler
Kategori: Veri Mühendisliği ve MLOps, Veri Analitiği ve İş Zekası