Bir depolama tesisi geliştirmek uzun ve ciddi bir girişimdir.
Bir projenin ömrünün büyük kısmı nesne modelinin ve temel yapısının başlangıçta ne kadar iyi düşünüldüğüne bağlıdır.
Genel olarak kabul edilen yaklaşım, yıldız şemasını üçüncü normal formla birleştirmenin çeşitli varyantları olmuştur ve olmaya devam etmektedir. Kural olarak, şu prensibe göre: ilk veriler - 3NF, vitrinler - yıldız. Zamanla test edilen ve çok sayıda araştırmayla desteklenen bu yaklaşım, analitik bir veri havuzunun nasıl görünmesi gerektiğini düşünürken deneyimli bir DWH uzmanının aklına gelen ilk (ve bazen tek) şeydir.
Öte yandan, genel olarak iş ve özel olarak müşteri gereksinimleri hızla değişme eğilimindedir ve veriler hem "derinlemesine" hem de "genişliğine" büyüme eğilimindedir. Ve bir yıldızın ana dezavantajının ortaya çıktığı yer burasıdır - sınırlı esneklik.
Ve eğer bir DWH geliştiricisi olarak sessiz ve rahat hayatınızda aniden:
- görev "en azından hızlı bir şekilde bir şeyler yapmak ve sonra göreceğiz";
- yeni kaynakların bağlanması ve iş modelinin haftada en az bir kez yeniden çalışılmasıyla hızla gelişen bir proje ortaya çıktı;
- Sistemin neye benzemesi gerektiği ve nihai olarak hangi işlevleri yerine getirmesi gerektiği hakkında hiçbir fikri olmayan, ancak denemeye ve istenen sonucu sürekli olarak iyileştirirken buna sürekli olarak yaklaşmaya hazır olan bir müşteri ortaya çıktı;
- Proje yöneticisi iyi haberi verdi: "Ve artık çevikliğimiz var!"
Veya depolama tesislerini başka nasıl inşa edebileceğinizi öğrenmek istiyorsanız - kesime hoş geldiniz!
"Esneklik" ne anlama geliyor?
Öncelikle bir sistemin “esnek” sayılabilmesi için hangi özelliklere sahip olması gerektiğini tanımlayalım.
Ayrı olarak, açıklanan özelliklerin özellikle aşağıdakilerle ilgili olması gerektiğini belirtmekte fayda var: sistem, değil işlem onun gelişimi. Bu nedenle Agile'ı bir geliştirme metodolojisi olarak okumak istiyorsanız diğer makaleleri okumanız daha iyi olur. Örneğin, tam orada, Habré'de pek çok ilginç materyal var (örneğin и Ve ).
Bu, geliştirme süreci ile veri ambarının yapısının tamamen ilgisiz olduğu anlamına gelmez. Genel olarak, çevik bir mimari için Çevik bir depo geliştirmek önemli ölçüde daha kolay olmalıdır. Bununla birlikte, pratikte, Kimbal ve DataVault'a göre klasik DWH'nin Çevik gelişimi ile - Waterfall'a göre - tek bir projede iki formda esnekliğin mutlu tesadüflerinden daha sık seçenekler vardır.
Peki esnek depolama hangi yeteneklere sahip olmalıdır? Burada üç nokta var:
- Erken teslimat ve hızlı geri dönüş - bu, ideal olarak ilk iş sonucunun (örneğin, ilk çalışma raporlarının) mümkün olduğu kadar erken, yani tüm sistem tamamen tasarlanıp uygulamaya konulmadan önce elde edilmesi gerektiği anlamına gelir. Ayrıca, sonraki her revizyonun da mümkün olduğunca az zaman alması gerekir.
- Yinelemeli iyileştirme - bu, sonraki her iyileştirmenin ideal olarak zaten çalışmakta olan işlevselliği etkilememesi gerektiği anlamına gelir. Büyük projelerde genellikle en büyük kabus haline gelen an budur - er ya da geç, bireysel nesneler o kadar çok bağlantı edinmeye başlar ki, yakındaki bir kopyada mantığı tamamen tekrarlamak, mevcut bir tabloya alan eklemekten daha kolay hale gelir. Ve eğer iyileştirmelerin mevcut nesneler üzerindeki etkisini analiz etmenin iyileştirmelerin kendisinden daha fazla zaman alabileceğine şaşırıyorsanız, büyük olasılıkla bankacılık veya telekomünikasyon sektöründeki büyük veri ambarlarıyla henüz çalışmamışsınızdır.
- Değişen iş gereksinimlerine sürekli uyum sağlamak - Genel nesne yapısı, yalnızca olası genişlemeyi hesaba katarak değil, aynı zamanda bir sonraki genişlemenin yönünün tasarım aşamasında hayal bile edilemeyeceği beklentisiyle tasarlanmalıdır.
Ve evet, tüm bu gereksinimlerin tek bir sistemde karşılanması mümkün (tabii ki bazı durumlarda ve bazı çekincelerle).
Aşağıda veri ambarlarına yönelik en popüler çevik tasarım metodolojilerinden ikisini ele alacağım: Çapa modeli и Veri Kasası. Parantez dışında bırakılanlar, örneğin EAV, 6NF (saf haliyle) ve NoSQL çözümleriyle ilgili her şey gibi mükemmel tekniklerdir - bir şekilde daha kötü oldukları için değil, hatta bu durumda makale satın alma tehdidinde bulunacağı için bile değil. ortalama tezin hacmi. Tüm bunlar biraz farklı bir sınıftaki çözümlerle ilgilidir - ya projenizin genel mimarisine bakılmaksızın (EAV gibi) belirli durumlarda kullanabileceğiniz tekniklerle ya da küresel olarak diğer bilgi depolama paradigmalarıyla (grafik veritabanları gibi) ve diğer seçenekler NoSQL).
“Klasik” yaklaşımın sorunları ve esnek metodolojilerdeki çözümleri
"Klasik" yaklaşımla, eski güzel yıldızı kastediyorum (altta yatan katmanların özel uygulamasına bakılmaksızın, Kimball, Inmon ve CDM'nin takipçileri beni affedin).
1. Bağlantıların katı önemi
Bu model, verilerin açık bir şekilde bölümlere ayrılmasına dayanmaktadır. Boyut и gerçekler. Ve bu, kahretsin, mantıklı - sonuçta, vakaların ezici çoğunluğunda veri analizi, belirli bölümlerdeki (boyutlardaki) belirli sayısal göstergelerin (gerçeklerin) analizine iniyor.
Bu durumda nesneler arasındaki bağlantılar, yabancı anahtar kullanılarak tablolar arasındaki ilişkiler şeklinde kurulur. Bu oldukça doğal görünüyor, ancak hemen esnekliğin ilk sınırlamasına yol açıyor - bağlantıların önem derecesinin kesin tanımı.
Bu, tablo tasarımı aşamasında ilgili nesne çiftlerinin çoktan çoğa mı, yoksa sadece 1'e çok mu ve "hangi yönde" ilişki kurabileceklerini doğru bir şekilde belirlemeniz gerektiği anlamına gelir. Bu, hangi tablonun birincil anahtara, hangisinin yabancı anahtara sahip olacağını doğrudan belirler. Yeni gereksinimler alındığında bu tutumun değiştirilmesi büyük olasılıkla temelin yeniden çalışılmasına yol açacaktır.
Örneğin, “nakit makbuz” nesnesini tasarlarken satış departmanının yeminlerine dayanarak eylem olasılığını ortaya koydunuz birden fazla kontrol pozisyonu için bir terfi (ama tam tersi değil):
Ve bir süre sonra meslektaşları aynı pozisyonda hareket edebilecekleri yeni bir pazarlama stratejisini uygulamaya koydular. aynı anda birden fazla promosyon. Şimdi ilişkiyi ayrı bir nesneye ayırarak tabloları değiştirmeniz gerekiyor.
(Artık terfi kontrolünün birleştirildiği tüm türetilmiş nesnelerin de iyileştirilmesi gerekiyor).
Veri Kasası ve Bağlantı Modelindeki İlişkiler
Bu durumdan kaçınmanın oldukça basit olduğu ortaya çıktı: Bunu yapmak için satış departmanına güvenmenize gerek yok. tüm bağlantılar başlangıçta ayrı tablolarda saklanır ve bunu çoktan çoğa olarak işleyin.
Bu yaklaşım önerildi Dan Linstedt paradigmanın bir parçası olarak Veri Kasası ve tamamen destekleniyor Lars Rönnbäck в Çapa Modeli.
Sonuç olarak esnek metodolojilerin ilk ayırt edici özelliğini elde ediyoruz:
Nesneler arasındaki ilişkiler üst varlıkların özniteliklerinde depolanmaz, ayrı bir nesne türüdür.
В Veri Kasası bu tür bağlantı tablolarına denir LinkVe içinde Çapa Modeli - Kravat. İlk bakışta çok benzerler, ancak farklılıkları isimle bitmiyor (aşağıda tartışılacaktır). Her iki mimaride de bağlantı tabloları bağlantı kurabilir herhangi bir sayıda varlık (mutlaka 2 olması gerekmez).
Bu yedeklilik, ilk bakışta, değişiklikler için önemli bir esneklik sağlar. Böyle bir yapı, yalnızca mevcut bağlantıların önem derecesindeki değişikliklere değil, aynı zamanda yenilerinin eklenmesine de toleranslı hale gelir - eğer artık bir çek pozisyonunun, onu kıran kasiyerle de bir bağlantısı varsa, böyle bir bağlantının ortaya çıkışı basitçe basit olacaktır. Mevcut nesneleri ve süreçleri etkilemeden mevcut tablolar üzerinde bir eklenti haline gelir.
2. Veri çoğaltma
Esnek mimarilerin çözdüğü ikinci sorun daha az belirgindir ve her şeyden önce içseldir. SCD2 tipi ölçümler (ikinci türün yavaş yavaş değişen boyutları), ancak sadece onlar değil.
Klasik bir depoda, boyut genellikle ayrı sütunlarda bir yedek anahtar (PK olarak) ve bir dizi iş anahtarı ve öznitelik içeren bir tablodur.
Bir boyut sürüm oluşturmayı destekliyorsa, standart alan kümesine sürüm geçerliliği sınırları eklenir ve kaynaktaki bir satır için, depoda birkaç sürüm görünür (sürümlendirilmiş niteliklerdeki her değişiklik için bir tane).
Bir boyut, sık sık değişen en az bir sürümlendirilmiş öznitelik içeriyorsa, böyle bir boyutun sürüm sayısı etkileyici olacaktır (kalan öznitelikler sürümlendirilmemiş veya hiç değişmemiş olsa bile) ve bu tür birden fazla öznitelik varsa, sürüm sayısı etkileyici olacaktır. sayıları katlanarak artıyor. Bu boyut önemli miktarda disk alanı kaplayabilir, ancak depoladığı verilerin çoğu diğer satırlardaki değişmez öznitelik değerlerinin kopyalarıdır.
Aynı zamanda çok sık kullanılmaktadır. denormalizasyon — bazı nitelikler, bir referans kitabına veya başka bir boyuta bağlantı olarak değil, kasıtlı olarak bir değer olarak saklanır. Bu yaklaşım, bir boyuta erişirken birleştirme sayısını azaltarak veri erişimini hızlandırır.
Tipik olarak bu şuna yol açar: aynı bilgiler aynı anda birkaç yerde saklanır. Örneğin, ikamet bölgesi ve müşterinin kategorisine ilişkin bilgiler aynı anda “Müşteri” boyutları ve “Satın Alma”, “Teslimat” ve “Çağrı Merkezi Çağrıları” bilgilerinin yanı sıra “Müşteri - Müşteri Yöneticisi”nde de saklanabilir. ” bağlantı tablosu.
Genel olarak, yukarıda açıklananlar normal (versiyonlandırılmamış) boyutlar için geçerlidir, ancak versiyonlanmış olanlarda farklı bir ölçeğe sahip olabilirler: bir nesnenin yeni bir versiyonunun ortaya çıkması (özellikle geçmişe bakıldığında) yalnızca ilgili tüm boyutların güncellenmesine yol açmaz. ancak ilgili nesnelerin yeni sürümlerinin basamaklı görünümüne - Tablo 1, Tablo 2'yi oluşturmak için kullanıldığında ve Tablo 2, Tablo 3'ü oluşturmak için kullanıldığında vb. Tablo 1'ün oluşturulmasında Tablo 3'in tek bir özelliği yer almasa bile (ve diğer kaynaklardan elde edilen Tablo 2'nin diğer özellikleri de dahil olsa), bu yapının versiyonlanması, minimum düzeyde ek yüke ve maksimumda ekstra maliyete yol açacaktır. Tablo 3'teki versiyonlarla hiçbir ilgisi yoktur ve zincirin daha aşağısındadır.
3. Yeniden çalışmanın doğrusal olmayan karmaşıklığı
Aynı zamanda, bir diğeri temel alınarak inşa edilen her yeni vitrin, ETL'de değişiklik yapıldığında verilerin "farklılaşabileceği" yerlerin sayısını artırır. Bu da sonraki her revizyonun karmaşıklığının (ve süresinin) artmasına yol açar.
Yukarıdakiler nadiren değiştirilen ETL süreçlerine sahip sistemleri tanımlıyorsa, böyle bir paradigmada yaşayabilirsiniz; yalnızca ilgili tüm nesnelerde yeni değişikliklerin doğru şekilde yapıldığından emin olmanız gerekir. Eğer revizyonlar sık sık yapılıyorsa, birden fazla bağlantının yanlışlıkla "eksik" olma olasılığı önemli ölçüde artar.
Ayrıca "versiyonlu" ETL'nin "versiyonsuz" ETL'den önemli ölçüde daha karmaşık olduğunu hesaba katarsak, tüm bu tesisin sık sık güncellenmesi sırasında hatalardan kaçınmak oldukça zor hale gelir.
Veri Kasası ve Bağlantı Modelinde nesneleri ve nitelikleri depolama
Esnek mimarilerin yazarları tarafından önerilen yaklaşım şu şekilde formüle edilebilir:
Değişenleri aynı kalanlardan ayırmak gerekir. Yani anahtarları özniteliklerden ayrı olarak saklayın.
Ancak kafa karıştırmamak lazım versiyonlandırılmamış ile nitelik değişmedi: birincisi değişikliklerin geçmişini saklamaz ancak değişebilir (örneğin, bir giriş hatasını düzeltirken veya yeni veri alırken); ikincisi asla değişmez.
Veri Kasası ve Sabitleme Modelinde tam olarak neyin değişmez olarak kabul edilebileceğine ilişkin bakış açıları farklılık gösterir.
Mimari açıdan Veri Kasasıdeğişmemiş sayılabilir tüm anahtar seti - doğal (kuruluşun TIN'si, kaynak sistemdeki ürün kodu vb.) ve vekil. Bu durumda geri kalan nitelikler, değişikliklerin kaynağına ve/veya sıklığına göre gruplara ayrılabilir ve Her grup için ayrı bir masa bulundurun bağımsız bir versiyon seti ile.
Paradigmada Çapa Modeli değişmemiş sayılır yalnızca yedek anahtar öz. Diğer her şey (doğal anahtarlar dahil) niteliklerinin yalnızca özel bir durumudur. burada tüm özellikler varsayılan olarak birbirinden bağımsızdıryani her özellik için bir ayrı masa.
В Veri Kasası varlık anahtarlarını içeren tablolar çağrılır Hubami. Hub'lar her zaman sabit bir alan kümesi içerir:
- Doğal Varlık Anahtarları
- Vekil anahtarı
- Kaynağa bağlantı
- Ekleme süresini kaydedin
Hub'lardaki Gönderiler asla değişmez ve versiyonları yoktur. Harici olarak hub'lar, bazı sistemlerde vekiller oluşturmak için kullanılan kimlik haritası türü tablolara çok benzer; ancak Veri Kasasında vekil olarak bir dizi iş anahtarından bir karma kullanılması önerilir. Bu yaklaşım, kaynaklardan ilişkilerin ve niteliklerin yüklenmesini basitleştirir (vekil almak için merkeze katılmanıza gerek yoktur, yalnızca doğal anahtarın karma değerini hesaplamanız gerekir), ancak başka sorunlara (örneğin çarpışmalarla ilgili) neden olabilir , büyük/küçük harf ve dize anahtarlarındaki yazdırılamayan karakterler vb. .p.), bu nedenle genel olarak kabul edilmez.
Diğer tüm varlık nitelikleri adı verilen özel tablolarda saklanır. Uydular. Bir hub, farklı nitelik kümelerini depolayan birden fazla uyduya sahip olabilir.
Niteliklerin uydular arasındaki dağılımı şu prensibe göre gerçekleşir: ortak değişiklik - bir uyduda sürümlendirilmemiş nitelikler saklanabilir (örneğin, bir kişinin doğum tarihi ve SNILS), diğerinde - nadiren değişen sürümler (örneğin, soyadı ve pasaport numarası), üçüncüsünde - sık sık değişenler (örneğin teslimat adresi, kategori, son sipariş tarihi vb.). Bu durumda, versiyonlama bir bütün olarak varlık değil, bireysel uydular seviyesinde gerçekleştirilir, bu nedenle niteliklerin, bir uydu içindeki versiyonların kesişimi minimum olacak şekilde dağıtılması tavsiye edilir (bu, depolanan versiyonların toplam sayısını azaltır). ).
Ayrıca veri yükleme sürecini optimize etmek için çeşitli kaynaklardan elde edilen nitelikler genellikle bireysel uydulara dahil edilir.
Uydular Hub ile iletişim kurar. yabancı anahtar (1'den çoğa kardinaliteye karşılık gelir). Bu, birden fazla özellik değerinin (örneğin, bir istemci için birden fazla iletişim telefon numarasının) bu "varsayılan" mimari tarafından desteklendiği anlamına gelir.
В Çapa Modeli Anahtarların saklandığı tablolara denir Çapalar. Ve şunu saklıyorlar:
- Yalnızca yedek anahtarlar
- Kaynağa bağlantı
- Ekleme süresini kaydedin
Çapa Modeli açısından doğal anahtarlar dikkate alınır sıradan nitelikler. Bu seçeneğin anlaşılması daha zor görünebilir ancak nesnenin tanımlanması için çok daha fazla kapsam sağlar.
Örneğin, aynı varlığa ilişkin veriler, her biri kendi doğal anahtarını kullanan farklı sistemlerden gelebiliyorsa. Veri Kasasında bu, birkaç hub'ın (kaynak başına bir + birleştirici ana sürüm) oldukça hantal yapılarına yol açabilirken, Anchor modelinde her kaynağın doğal anahtarı kendi özniteliğine düşer ve bağımsız olarak yüklenirken kullanılabilir. diğer hepsi.
Ancak burada sinsi bir nokta da var: Farklı sistemlerden gelen nitelikler tek bir varlıkta birleştirilirse, büyük ihtimalle bazı özellikler vardır. "yapıştırma" kuralları, sistemin farklı kaynaklardan gelen kayıtların varlığın bir örneğine karşılık geldiğini anlaması gerekir.
В Veri Kasası bu kurallar büyük ihtimalle oluşumu belirleyecek Ana varlığın “vekil merkezi” ve doğal kaynak anahtarlarını ve bunların orijinal niteliklerini saklayan Hub'ları hiçbir şekilde etkilemeyin. Bir noktada birleştirme kuralları değişirse (veya birleştirmenin gerçekleştirildiği özellikler güncellenirse), yedek hub'ları yeniden biçimlendirmek yeterli olacaktır.
В Çapa modeli böyle bir varlık büyük olasılıkla depolanacak tek çapa. Bu, hangi kaynaktan gelirse gelsin tüm niteliklerin aynı vekile bağlı olacağı anlamına gelir. Hatalı bir şekilde birleştirilen kayıtların ayrılması ve genel olarak böyle bir sistemde birleştirmenin uygunluğunu izlemek, özellikle kuralların oldukça karmaşık olması ve sık sık değişmesi durumunda ve aynı özelliğin farklı kaynaklardan elde edilebildiği durumlarda (her ne kadar kesinlikle geçerli olsa da) çok daha zor olabilir. mümkündür, çünkü her özellik sürümü kaynağına bir bağlantı bulundurur).
Her durumda, sisteminizin bu işlevselliği uygulaması gerekiyorsa veri tekilleştirme, kayıtları birleştirme ve diğer MDM öğeleriÇevik metodolojilerde doğal anahtarların saklanması hususlarına özellikle dikkat etmek önemlidir. Daha hacimli Veri Kasası tasarımının birleştirme hataları açısından birdenbire daha güvenli hale gelmesi muhtemeldir.
Çapa modeli ayrıca adı verilen ek bir nesne türü sağlar Düğüm aslında özel dejenere tip çapa, yalnızca bir öznitelik içerebilir. Düğümlerin düz dizinleri (örneğin cinsiyet, medeni durum, müşteri hizmetleri kategorisi vb.) depolamak için kullanılması gerekiyor. Çapanın aksine Düğüm ilişkili özellik tablosu yokve onun tek niteliği (isim) her zaman anahtarla aynı tabloda saklanır. Düğümler, Çapaların birbirine bağlanmasıyla aynı şekilde bağlantı tabloları (Bağlantı) aracılığıyla Çapalara bağlanır.
Node’ların kullanımına ilişkin net bir görüş bulunmamaktadır. Örneğin, Rusya'da Çapa Modelinin kullanımını aktif olarak destekleyen, tek bir referans kitabı için bile bunun kesin olarak ifade edilemeyeceğine inanıyor (makul olmayan bir şekilde değil). daima statik ve tek seviyeli olacaktır, bu nedenle tüm nesneler için hemen tam teşekküllü bir Çapa kullanmak daha iyidir.
Data Vault ile Anchor modeli arasındaki bir diğer önemli fark da kullanılabilirliktir. bağlantıların özellikleri:
В Veri Kasası Bağlantılar, Hub'larla aynı tam kapsamlı nesnelerdir ve kendi nitelikleri. Çapa modeli Bağlantılar yalnızca Bağlantıları bağlamak için kullanılır ve kendilerine ait niteliklere sahip olamazlar. Bu farklılık önemli ölçüde farklı modelleme yaklaşımlarına yol açmaktadır. gerçeklerinBu daha ayrıntılı olarak tartışılacaktır.
Gerçek depolama
Bundan önce ağırlıklı olarak ölçüm modellemeden bahsetmiştik. Gerçekler biraz daha az açıktır.
В Veri Kasası gerçekleri depolamak için tipik bir nesne BağlantıUydularına gerçek göstergelerin eklendiği.
Bu yaklaşım sezgisel görünüyor. Analiz edilen göstergelere kolay erişim sağlar ve genel olarak geleneksel veri tablosuna benzer (yalnızca göstergeler tablonun kendisinde değil “komşu” tabloda saklanır). Ancak aynı zamanda tuzaklar da var: Modelin tipik değişikliklerinden biri olan olgu anahtarının genişletilmesi, Link'e yeni bir yabancı anahtar ekleme. Bu da modülerliği “bozuyor” ve potansiyel olarak diğer nesnelerde değişiklik yapma ihtiyacına neden oluyor.
В Çapa modeli Bir bağlantının kendi nitelikleri olamaz, dolayısıyla bu yaklaşım işe yaramayacaktır; kesinlikle tüm nitelikler ve göstergeler belirli bir çapaya bağlanmalıdır. Buradan çıkan sonuç basit: Her olgunun aynı zamanda kendi çapasına ihtiyacı vardır. Gerçek olarak algılamaya alıştığımız bazı şeyler için bu doğal görünebilir - örneğin, bir satın alma gerçeği mükemmel bir şekilde "sipariş" veya "makbuz" nesnesine, bir siteyi bir oturuma ziyaret etmeye vb. indirgenebilir. Ancak böylesine doğal bir "taşıyıcı nesne" bulmanın o kadar kolay olmadığı gerçekler de var - örneğin, her günün başında depolardaki mal kalıntıları.
Buna göre, Çapa modelinde bir olgu anahtarını genişletirken modülerlikle ilgili sorunlar ortaya çıkmaz (ilgili Çapaya yeni bir İlişki eklemek yeterlidir), ancak gerçekleri gösterecek bir model tasarlamak daha az açıktır; "yapay" Çapalar ortaya çıkabilir iş nesnesi modelini belirsiz bir şekilde gösteren.
Esneklik nasıl sağlanır?
Her iki durumda da ortaya çıkan yapı şunları içerir: önemli ölçüde daha fazla tablogeleneksel ölçümden daha iyidir. Ama gerekebilir önemli ölçüde daha az disk alanı geleneksel boyutla aynı versiyonlanmış nitelikler kümesine sahiptir. Doğal olarak burada sihir yok; her şey normalleşmeyle ilgili. Nitelikleri Uydular (Veri Kasasında) veya ayrı tablolar (Çapa Modeli) arasında dağıtarak, azaltıyoruz (veya tamamen ortadan kaldırıyoruz) diğerlerini değiştirirken bazı niteliklerin değerlerinin kopyalanması.
için Veri Kasası Kazançlar, niteliklerin Uydular arasındaki dağılımına bağlı olacaktır ve Çapa modeli — ölçüm nesnesi başına ortalama versiyon sayısıyla neredeyse doğrudan orantılıdır.
Bununla birlikte, yerden tasarruf, nitelikleri ayrı ayrı saklamanın önemli ama asıl avantajı olmayan bir avantajıdır. İlişkilerin ayrı depolanmasıyla birlikte bu yaklaşım, mağazayı Modüler tasarım. Bu, böyle bir modele hem bireysel özelliklerin hem de tamamen yeni konu alanlarının eklenmesinin şuna benzediği anlamına gelir: üstyapı Mevcut bir nesne kümesi üzerinde onları değiştirmeden. Tanımlanan metodolojileri esnek kılan da tam olarak budur.
Bu aynı zamanda parça üretiminden seri üretime geçişi de andırıyor; geleneksel yaklaşımda modelin her tablosu benzersizse ve özel dikkat gerektiriyorsa, esnek metodolojilerde bu zaten bir dizi standart "parça"dır. Bir yandan daha fazla tablo var ve veri yükleme ve alma süreçleri daha karmaşık görünmeli. Öte yandan onlar haline geliyorlar. tipik. Bu da olabileceği anlamına geliyor otomatik ve meta veri odaklı. Cevabı iyileştirmelerin tasarlanması çalışmasının önemli bir bölümünü kapsayabilecek "nasıl döşeyeceğiz?" Sorusu artık buna değmez (aynı zamanda model değişikliğinin çalışma süreçleri üzerindeki etkisi hakkındaki soru). ).
Bu, böyle bir sistemde analistlere hiç ihtiyaç duyulmadığı anlamına gelmez; birisinin yine de niteliklere sahip nesneler kümesi üzerinde çalışması ve bunların hepsinin nereye ve nasıl yükleneceğini bulması gerekir. Ancak iş miktarı, hata olasılığı ve maliyeti önemli ölçüde azalır. Hem analiz aşamasında hem de ETL'nin geliştirilmesi sırasında, önemli bir kısmı meta verileri düzenlemeye indirgenebilir.
Karanlık tarafı
Yukarıdakilerin tümü, her iki yaklaşımı da gerçek anlamda esnek, teknolojik açıdan gelişmiş ve yinelemeli iyileştirmeye uygun hale getirir. Tabii bir de “merhemin içinde varil” var ki bunu zaten tahmin edebileceğinizi düşünüyorum.
Esnek mimarilerin modülerliğinin temelinde yatan veri ayrıştırma, tablo sayısının artmasına ve buna bağlı olarak genel gider Örnekleme sırasında katılmak için. Bir boyutun tüm niteliklerini basitçe elde etmek için klasik bir mağazada tek bir seçim yeterlidir, ancak esnek bir mimari bir dizi birleştirme gerektirecektir. Üstelik tüm bu raporlar için birleştirmeler önceden yazılabiliyorsa, SQL'i elle yazmaya alışkın olan analistler iki kat zarar görecektir.
Bu durumu kolaylaştıran birkaç gerçek var:
Büyük boyutlarla çalışırken, boyutların tümü neredeyse hiçbir zaman aynı anda kullanılmaz. Bu, modelde ilk bakışta göründüğünden daha az birleştirme olabileceği anlamına gelir. Veri Kasası, öznitelikleri uydulara tahsis ederken beklenen paylaşım sıklığını da hesaba katabilir. Aynı zamanda, Hub'lara veya Anchor'lara öncelikli olarak yükleme aşamasında vekillerin oluşturulması ve eşlenmesi için ihtiyaç duyulur ve sorgularda nadiren kullanılır (bu özellikle Anchor'lar için geçerlidir).
Tüm birleştirmeler anahtarla yapılır. Ek olarak, verileri depolamanın daha "sıkıştırılmış" bir yolu, ihtiyaç duyulan yerlerde (örneğin, nitelik değerine göre filtreleme yaparken) tabloların taranma yükünü azaltır. Bu, bir dizi birleştirme içeren normalleştirilmiş bir veritabanından örneklemenin, satır başına birçok sürüm içeren ağır bir boyutu taramaktan daha hızlı olacağı gerçeğine yol açabilir.
Örneğin, burada Makale, Anchor modelinin performansının bir tablodan alınan bir örnekle ayrıntılı bir karşılaştırmalı testini içermektedir.
Çoğu şey motora bağlıdır. Birçok modern platformun dahili birleştirme optimizasyon mekanizmaları vardır. Örneğin, MS SQL ve Oracle, verileri diğer birleştirmeler dışında herhangi bir yerde kullanılmıyorsa ve son seçimi (tablo/birleştirme eleme) etkilemiyorsa tablolara birleştirmeleri "atlayabilir" ve MPP Vertica Sorgu planının manuel optimizasyonu göz önüne alındığında, Bağlantı Modeli için mükemmel bir motor olduğu kanıtlanmıştır. Öte yandan Anchor Modelini örneğin katılım desteği sınırlı olan Click House'da saklamak henüz pek iyi bir fikir gibi görünmüyor.
Ayrıca her iki mimari için de özel hareketler, verilere erişimi kolaylaştırır (hem sorgu performansı açısından hem de son kullanıcılar için). Örneğin, Zaman İçinde Nokta tabloları Veri Kasasında veya özel masa fonksiyonları Çapa modelinde.
Toplam
Ele alınan esnek mimarilerin temel özü, “tasarımlarının” modülerliğidir.
Aşağıdakilere izin veren bu özelliktir:
- Meta veri dağıtımı ve temel ETL algoritmalarının yazılmasıyla ilgili bazı ön hazırlıklardan sonra, Müşteriye hızlı bir şekilde ilk sonucu sağlayın yalnızca birkaç kaynak nesneden veri içeren birkaç rapor biçiminde. Tüm nesne modelini tamamen düşünmek (en üst düzeyde bile) gerekli değildir.
- Bir veri modeli yalnızca 2-3 nesneyle çalışmaya başlayabilir (ve faydalı olabilir) ve ardından yavaş yavaş büyümek (Çapa modeli Nikolai ile ilgili olarak miselyum ile güzel bir karşılaştırma).
- Konu alanının genişletilmesi ve yeni kaynakların eklenmesi de dahil olmak üzere çoğu iyileştirme mevcut işlevselliği etkilemez ve halihazırda çalışan bir şeyin bozulması riski oluşturmaz.
- Standart öğelere ayrıştırma sayesinde bu tür sistemlerdeki ETL süreçleri aynı görünür, yazımı algoritmaya uygundur ve sonuçta otomasyon.
Bu esnekliğin bedeli performans. Bu, bu tür modellerde kabul edilebilir performansa ulaşmanın imkansız olduğu anlamına gelmez. Çoğu zaman, istediğiniz ölçümlere ulaşmak için daha fazla çabaya ve ayrıntılara dikkat etmeniz gerekebilir.
Uygulamalar
Varlık türleri Veri Kasası
Veri Kasası hakkında daha fazla bilgi:
Varlık türleri Çapa Modeli
Çapa Modeli hakkında daha fazla ayrıntı:
Ele alınan yaklaşımların ortak özelliklerini ve farklılıklarını içeren özet tablo:
Kaynak: habr.com