Bir önceki yazımda VERİ VAULT'un temellerinden bahsetmiş, VERİ VAULT'un ana unsurlarını ve amaçlarını anlatmıştım. VERİ VAULT'un konusunun bitmiş olduğu söylenemez, VERİ VAULT'un evrimindeki sonraki adımlardan bahsetmek gerekiyor.
Ve bu yazıda VERİ VAULT'un geliştirilmesine ve İŞ VERİ VAULT'a veya kısaca İŞ VAULT'a geçişe odaklanacağım.
İŞ VERİLERİ KASASININ ortaya çıkma nedenleri
VERİ VAULT'un belirli güçlü yanları olsa da dezavantajlarının da olduğunu belirtmek gerekir. Bu dezavantajlardan biri de analitik sorgu yazmanın zorluğudur. Sorgularda önemli sayıda JOIN bulunur, kod uzun ve hantaldır. Ayrıca VERİ VAULT'a giren veriler herhangi bir dönüşüme uğramaz, bu nedenle iş açısından bakıldığında VERİ VAULT'un saf haliyle mutlak bir değeri yoktur.
VERİ VAULT metodolojisi bu eksiklikleri ortadan kaldırmak için aşağıdaki gibi unsurlarla genişletildi:
- PIT (zamandaki nokta) tabloları;
- KÖPRÜ tabloları;
- ÖNCEDEN TANIMLANMIŞ TÜREVLER.
Bu unsurların amacına daha yakından bakalım.
PIT tabloları
Tipik olarak, bir ticari varlık (HUB) farklı güncelleme oranlarına sahip veriler içerebilir; örneğin, bir kişiyi karakterize eden verilerden bahsediyorsak, bir telefon numarası, adres veya e-posta hakkındaki bilgilerin, şunu söylemekten daha yüksek bir güncelleme oranına sahip olduğunu söyleyebiliriz: tam ad, pasaport bilgileri, medeni durum veya cinsiyet.
Bu nedenle uyduları belirlerken güncelleme sıklığını da göz önünde bulundurmalısınız. Neden önemlidir?
Farklı güncelleme oranlarına sahip özellikleri aynı tabloda saklıyorsanız, en sık değiştirilen özelliğin her güncellenmesinde tabloya bir satır eklemeniz gerekecektir. Sonuç, disk alanında bir artış ve sorgu yürütme süresinde bir artıştır.
Artık uyduları güncelleme sıklığına göre ayırdığımıza ve bağımsız olarak veri yükleyebildiğimize göre, güncel veri alabildiğimizden emin olmalıyız. Gereksiz JOIN'leri kullanmadan daha iyi.
Mesela şöyle anlatayım, güncel (son güncelleme tarihine göre) bilgileri farklı güncelleme hızlarına sahip uydulardan almanız gerekiyor. Bunu yapmak için, yalnızca bir JOIN yapmanız değil, aynı zamanda maksimum güncelleme tarihi MAX (Güncelleme Tarihi) seçimiyle (bilgi içeren her uydu için) birkaç iç içe sorgu oluşturmanız gerekecektir. Her yeni JOIN ile bu tür kodlar büyür ve anlaşılması çok hızlı bir şekilde zorlaşır.
PIT tablosu bu tür sorguları basitleştirmek için tasarlanmıştır; PIT tabloları, VERİ KASASINA yeni verilerin yazılmasıyla eş zamanlı olarak doldurulur. PIT tablosu:
Böylece, zamanın her noktasında tüm uydulara ilişkin verilerin uygunluğu hakkında bilgi sahibi oluyoruz. PIT tablosuna JOIN'leri kullanarak, PIT'in her gün ve boşluksuz doldurulması koşuluyla doğal olarak iç içe sorguları tamamen ortadan kaldırabiliriz. PIT'te boşluklar olsa bile, en son verileri yalnızca PIT'in kendisine yönelik iç içe geçmiş bir sorgu kullanarak alabilirsiniz. İç içe geçmiş bir sorgu, her uyduya yönelik iç içe sorgulardan daha hızlı işlenir.
KÖPRÜ
BRIDGE tabloları analitik sorguları basitleştirmek için de kullanılır. Ancak PIT'ten farklı olan, çeşitli hub'lar, bağlantılar ve bunların uyduları arasındaki istekleri basitleştirme ve hızlandırma aracıdır.
Tablo, sorgularda sıklıkla kullanılan, tüm uydular için gerekli tüm anahtarları içerir. Ayrıca analiz için anahtar adlarına ihtiyaç duyulması halinde, hashed iş anahtarlarına metin biçiminde anahtarlar eklenebilir.
Gerçek şu ki, BRIDGE'i kullanmadan, farklı hub'lara ait uydularda bulunan verileri alma sürecinde, yalnızca uyduların değil, aynı zamanda hub'ları birbirine bağlayan bağlantıların da JOIN'ini yapmak gerekli olacaktır.
BRIDGE'in varlığı veya yokluğu, depolama yapılandırmasına ve sorgu yürütme hızının optimize edilmesi ihtiyacına göre belirlenir. BRIGE'in evrensel bir örneğini bulmak zordur.
ÖNCEDEN TANIMLANMIŞ TÜREVLER
Bizi İŞ VERİLERİ VERİLERİ'ne yaklaştıran bir diğer nesne türü de önceden hesaplanmış göstergeleri içeren tablolardır. Bu tür tablolar işletmeler için gerçekten önemlidir; belirli kurallara göre bir araya getirilmiş bilgileri içerirler ve erişimi nispeten kolaylaştırırlar.
Mimari olarak, ÖNCEDEN TANIMLANMIŞ DERIVASYONLAR, belirli bir merkezin başka bir uydusundan başka bir şey değildir. Normal bir uydu gibi, bir iş anahtarı ve uydudaki kaydın oluşturulma tarihini içerir. Ancak benzerliklerin bittiği yer burasıdır. Böyle bir "özel" uydunun özelliklerinin daha fazla bileşimi, iş kullanıcıları tarafından en popüler, önceden hesaplanmış göstergelere dayanarak belirlenir.
Örneğin, bir çalışan hakkında bilgi içeren bir merkez, aşağıdaki gibi göstergelere sahip bir uydu içerebilir:
- Asgari ücret;
- Azami maaş;
- Ortalama maaş;
- Tahakkuk eden ücretlerin kümülatif toplamı vb.
ÖNCEDEN TANIMLANMIŞ TÜREVLERİ aynı merkezin PIT tablosuna dahil etmek mantıklıdır, böylece bir çalışanın özel olarak seçilmiş bir tarihteki veri dilimlerini kolayca elde edebilirsiniz.
SONUÇLAR
Uygulamada görüldüğü gibi, VERİ VAULT'un iş kullanıcıları tarafından kullanımı çeşitli nedenlerden dolayı biraz zordur:
- Sorgu kodu karmaşık ve hantaldır;
- JOIN'lerin çokluğu sorguların performansını etkiler;
- Analitik sorgular yazmak, olağanüstü depolama tasarımı bilgisi gerektirir.
Veri erişimini kolaylaştırmak için DATA VAULT ek nesnelerle genişletildi:
- PIT (zamandaki nokta) tabloları;
- KÖPRÜ tabloları;
- ÖNCEDEN TANIMLANMIŞ TÜREVLER.
Sonraki Bana göre BI ile çalışanlar için en ilginç olanı anlatmayı planlıyorum. DATA VAULT'a dayalı olarak olgu tabloları ve boyut tabloları oluşturmanın yollarını sunacağım.
Makalenin materyalleri aşağıdakilere dayanmaktadır:
- Üzerinde Ayrıntılı bir açıklamanın yanı sıra model şemalarını da içeren Kenta Graziano;
- Kitap: “DATA VAULT 2.0 ile Ölçeklenebilir Bir Veri Ambarı Oluşturmak”;
- Makale .
Kaynak: habr.com